In a recent note, Bruce Black said: > Date: Fri, 28 Jul 2006 10:56:40 -0400 > > I should have mentioned one exception: GDGs. > > the initiator acquires an ENQ on the GDG base name at job initiation, > SHR or EXCL but the full name of the absolute generation (the .GnnnnV00) > is not resolved until step initiation, at which point the genertaion is > ENQed. Normally this works fine, but if some program has ENQed a > generation without ENQing the base name, it can get a ENQ failures at > step initiation. This used to cause a JCL error but some years ago IBM > implemented the SDSN_WAIT option in the ALLOCxx member of PARMLIB to > allow you to specify what to do. > JCL Error or deadlock? You pays your money and you gets your choice.
Possibly another -- ALIASes. I believe I observed that if one job identifies a data set by an ALIAS and another job by the RELATED name, the two jobs run concurrently until the step containing the DD statement for the ALIAS. At this point, the initiator resolves the ALIAS and detects the ENQ conflict, and the job fails with a (JCL?) error. I don't know whether SDSN_WAIT affects this. AFAICT, IDCAMS neither issues nor respects any ENQ on the ALIAS. I believe I was able to delete an ALIAS and create a new one with a different RELATED data set name while another batch job had it ENQued. A JES3 partisan once told me, as I whined about a job spewing ENQ messages into SYSLOG while another job held an ENQUE for the same DSN on a different volume, "That wouldn't happen with JES3." Perhaps he merely meant that JES3 would hold the second job from initiation until all resources it needed were immediately available. -- gil -- StorageTek INFORMATION made POWERFUL ---------------------------------------------------------------------- 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
