In a recent note, Robert A. Rosenberg said: > Subject: Re: sysdsn enq > > Unfortunately due to a poor design in the ENQ support code it can be > forced to hold the ENQ longer than should be needed. The situation I > am talking about is when step 1 has an exclusive ENQ (DISP=OLD) while > step 2 needs only a shared ENQ (DISP=SHR). Since the designers of ENQ > didn't bother to support the capability to downgrade the ENQ from EXC > to SHR (ie: Keep the ENQ but allocate it to any other task that was > waiting for SHR access), step 2 maintains the EXC ENQ even though it > only needs SHR access. For some reason, the ENQ code DOES allow a SHR > to be altered to EXC if/when no other task has the QNAME/RNAME > allocated (although I can not think of a situation where this is of > any use). > Indeed. And that poor design forced even worse design decisions on later developers, with the ultimate consequence that I once populated every storage pack we have with uncatalogued data sets. It seems that DYNALLOC will sometimes create a data set while SYSDSN ENQ is SHR; catalog fails because of duplicate entry, then DYNALLOC can't scratch it because another job also has a SHR ENQ. Next time I ran the job, it tried a different volume with the same result. Etc.
-- 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
