John Ticic wrote:
-- 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
I use SVC99 requests to handle my allocations thru an IBM supplied
module. I most likely will allocate multiple (if not hundreds) of
instances of this GDG during any given run of the job/region. Some
allocations can be within seconds of each other on separate subtasks,
using the same program. I wish this were not the case.
We do use absolute DSN name for allocation of new GDG entries. We first
do a LOCATE of the old GDG GooVoo value, increment it and allocate the
next one. I guess this only works right if the catalog has the latest
GooVoo value in it when I make the next request. I may have to keep
track of my GDG allocations for the entire region. This will be fraught
with perils too.
I too hate putting code to delay processing hoping the system will catch
up with my processing needs. I may have to though. I'll make it user
configurable so that it can be changed as needed.
The files are most typically DASD, since tape is too slow for my
processing needs.
Alas, I cannot run the process serially such that I'd allocate, write,
close each file before starting the next.
I have no doubt that the ROLL IN of the GDG is normal these days.
Though I do suspect it is somewhat recent. My older releases of IDCAMS
manuals do not mention a ROLL IN function for ALTER GDG commands. So it
would seem to me that IBM has introduced a DEFERRED feature to 'delay'
the catalog (I'm not sure that catalog and GDG information data store
are one and the same.) in recent years. If I had my druthers, I
would like to get the system to finish all the catalog and GDG
administrivia before returning back from my SVC99 request.
I can't see myself trying to allocate +1, +2, etc., but I'll look into
this if I have no other choice.
I certainly appreciate everyone's feedback. If anyone thinks of
anything else, please share. I'm taking the ideas you have share with
us, and looking to see if I can get one of them to solve my problem.
Thanks,
Mark Vollmer
----------------------------------------------------------------------
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
