Are you using GDGBIAS = STEP or GDGBIAS = JOB? On Thu, Nov 30, 2023 at 13:17 Mike Schwab <mike.a.sch...@gmail.com> wrote:
> Can downgrade from Exclusive (NEW,MOD,OLD) to Shared (SHR) within a job. > Cannot upgrade from Shared to Exclusive within a job.. > Since the first job was SHR, another system / job / task may be browing the > data, and prevents a Shared enque being upgraded to Exclusive enque. This > is documented for within a job. > I am guessing the Exclusive enque process requires no one be using the DSN > at the time of the attempt, but that is not documented on > https://www.ibm.com/docs/en/zos/3.1.0?topic=statement-disp-parameter > > > On Thu, Nov 30, 2023 at 9:24 AM Schmitt, Michael <michael.schm...@dxc.com> > wrote: > > > We had a production job enqueue failure on z/OS 2.4, that it seemed to me > > should have worked. I've been in communication with IBM; they say it is > as > > expected. But I don't understand why this is normal. Does it make sense > to > > you? Has it always worked this way? > > > > Here's the scenario: > > > > We have a job where the first step has DD DSN=data.set.name(0),DISP=SHR. > > The second step has the same data set, but as exclusive: DD DSN= > > data.set.name(0),DISP=OLD. > > > > Someone was browsing the data set when the job started, so they were > > holding a shared enqueue. > > > > The first step ran, and then the second step failed with the IEF211I - > > DATA SET RESERVATION UNSUCCESSFUL error. > > > > > > My understanding is that JES acquires the enqueues at the highest level > > before starting the job, to prevent deadlocks. IBM says that because it > is > > a relative GDG, it is unable to acquire the enqueue on the *absolute* > > generation before the job started. > > > > > > Contrast it with this case: > > 1st step: DD DSN=data.set.name(0),DISP=OLD > > 2nd step: DD DSN=data.set.name(0),DISP=SHR > > And again, a user is browsing the data set. > > > > In this case, the job waits until the user's enqueue is released. Which > > means that JES tried to get the exclusive enqueue before starting the > job, > > so waits. Or it means that it stated the job, couldn't get the enqueue, > but > > waits instead of failing with the IEF211I error. > > > > So why is the second case different than the first? > > > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > -- > Mike A Schwab, Springfield IL USA > Where do Forest Rangers go to get away from it all? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
