Look into ALOCxx parmlib option - "SDSN_WAIT WAITALLOC(YES)"
Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html On Thu, 30 Nov 2023 23:17:48 +0000, Schmitt, Michael <[email protected]> wrote: >JOB. If we were starting new we'd use STEP. > >-----Original Message----- >From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >Don Leahy >Sent: Thursday, November 30, 2023 5:12 PM >To: [email protected] >Subject: Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG > >[You don't often get email from [email protected]. Learn why this is >important at https://aka.ms/LearnAboutSenderIdentification ] > >Are you using GDGBIAS = STEP or GDGBIAS = JOB? > >On Thu, Nov 30, 2023 at 13:17 Mike Schwab <[email protected]> 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 <[email protected]> >> 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 [email protected] 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 [email protected] with the message: INFO IBM-MAIN >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN > > > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
