At 15:54 -0500 on 07/18/2007, Mark wrote about Dyn Alloc gives 2nd
instance of same GDG name:
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.
This is not an isolated instance. It seems to happen a handful of
times over several hours.
The time distance between 1st and 2nd instance of same dsn
allocation appears to be about 3 to 5 seconds.
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 many copies of the program doing the same allocation. All
instances should be serialized as above.
[snip]
Does anyone know what I'm missing here?
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?
Any help would be appreciated.
regards,
Mark Vollmer
As others have told you, the relative GDG number is relative to the
start of the job and all the datasets finally get cataloged (and the
GDG base gets rolled) at step termination. What I would suggest is at
startup do a locate on GDG(0) to find the last GDG number. Add 1 and
store this in a shared area. After you do your ENQ, do your allocate
with an absolute file name (GDG.G0207V00) and bump the saved 0207 to
0208. When you DEQ and the next task does its allocate it will then
allocate G0208V00 and bump the saved GDG number to 0209. When you go
to Step End, all the datasets will finally get cataloged and the
correct number of old generations will roll off (just make sure that
the max number of generations is more than you can create in one
execution of your job so that you do not accidentally delete one of
the files you just created [due to race conditions it is possible
that they will be added out-of-order and you might roll a high
numbered generation while keeping a lower numbered one]).
----------------------------------------------------------------------
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
