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 sbal...@us.ibm.com ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
