Thank you very much for that explanation. The documented exception to WAITALLOC(YES) waiting is if:
1. This job (plus possibly others) have the data set as SHR, AND 2. This job is trying to upgrade from SHR to OLD I'm guessing the reason for this exception is because it would lead to deadlocks. And the lesson here is that if you have a job that requires a DISP=OLD on a relative GDG in some step, then the only way to avoid the IEF211I is for the FIRST use of the same relative GDG to also be DISP=OLD. -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Scott Ballentine Sent: Friday, December 1, 2023 11:27 AM To: [email protected] Subject: Re: IEF211I - DATA SET RESERVATION UNSUCCESSFUL on relative GDG [Some people who received this message don't often get email from [email protected]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] It's pretty complicated, but yes, this is the way it has worked for a very long time. Apologies in advance for what's going to be a long read.... First, job initiator processing (it's not really JES) at the beginning of the job grabs all of the data set enqueues for those DDs in the JCL for all of the steps. Things like GDGs and aliases haven't been resolved yet, so it's only serializing using the names exactly as coded at this point. It grabs that resource at the highest level needed by the job. So in both your examples, it gets the data.set.name resource exclusive (since OLD was coded in at least one of the steps.) If some other job has those enqueues held, the job will wait for them to become available. Next, Allocation gets control for the first step, and it starts resolving data set names for that step only. That's when we figure out that data.set.name(0) translates to data.set.name.G0017V00 (or whatever absolute data set it is). We then go get the enqueue for data.set.name.G0017V00, based on what's specified in the JCL for this particular step. The run the job step program, and after it completes, go back to Allocation for the second step, etc. But... there is an ALLOCxx parmlib setting that matters here, called SDSN_WAIT WAITALLOC. The default is NO, and that tells Allocation that if it can't get the enqueue, cancel the job and issue IEF211I. If it's set to YES, it will wait - with an exception, and that exception is what you're seeing. See the documentation of this parameter for details: https://www.ibm.com/docs/en/zos/3.1.0?topic=defaults-statements-parameters-allocxx So let's walk through the two scenarios, assuming SDSN_WAIT WAITALLOC is set to YES: 1. First step has DISP=OLD,second has DISP=SHR. Job initiator gets the data.set.name enqueue exclusive, because some step needs it exclusive. At beginning of step 1, Allocation resolves data.set.name(0) to data.set.name.GxxxxVxx and requests that enqueue exclusive. We wait because somebody else holds it shared, and when they free it, we obtain it exclusive and move on. At beginning of step 2, Allocation resolves data.set.name(0) to data.set.name.GxxxxVxx, and we have that enqueue exclusive, so nothing changes. Everything runs successfully. 2. First step has DISP=SHR, second has DISP=OLD. Job initiator gets the data.set.name enqueue exclusive, because some step needs it exclusive. At beginning of step 1, Allocation resolves data.set.name(0) to data.set.name.GxxxxVxx and gets that enqueue shared, which works because the other holder has it shared too. At beginning of step 2, Allocation resolves data.set.name(0) to data.set.name.GxxxxVxx, and needs that enqueue exclusive but we only hold it shared. We try to upgrade it, but since somebody else holds it shared, we are not able to. (When upgrading, waiting isn't allowed, so we can only upgrade it if we are the only shared holder of the resource, otherwise the request fails.) Cancel the job. By the way, to clarify something from one of the responses - upgrading enqueues is allowed (with limitations, and that's why we try to obtain serialization the way we do), and downgrading is also allowed if you request it (see the DSENQSHR parameter on the JOB statement.) -Scott Ballentine, IBM z/OS Device Allocation [email protected] ---------------------------------------------------------------------- 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
