-- snip -- I have a task that allocates a few GDG files during its running instance.
I allocated one instance of a GDG and got the G0207V00 extension. 4 seconds later, I allocated another instance (different DDNAME) and got the very same G0207V00. It would appear that the first 207 instance was "deferred.". And that before it could be 'rolled in', we had allocated another instance of the GDG. . . . The same program is doing the allocation in all instances. The program issues a step level exclusive ENQ on a resource that covers... 1. allocation of file. 2. open of the file. 3. first record write of file. I then release the ENQ, to allow other instances in the region to do the same. I have a task that allocates a few GDG files during its running instance. . . . Is there something behind the scenes in SMS that might be tripping me up? Would a non-SMS managed GDG eliminate this problem? Perhaps I should add a delay as step 4 in my comments above to wait say about 3 to 6 seconds or so before allowing the next allocation request to start? -- snip -- I hate it when I find code waiting for a fixed time, hoping it will be long enough for some action to finish. It will always bite you some time in the future. Back to your problem. If you look at the description for IGD107I, it says - IGD107I dsname ROLLED IN, DDNAME=ddname Explanation: At the time of the step ending, the SMS managed generation data set associated with the DDNAME became a permanent part of the generation data group (GDG). I would say that it is working as designed. Can you use different GDGs within the same step? John ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
