I learned early on as a programmer trainee the effects of DISP=NEW for GDG(+1). My first assignment was to analyze existing data in this GDG. +1 was always 'in creation' by an online system. In order to read a previous version, it was not sufficient to specify DISP=SHR for an older generation; the exclusive ENQ blocked any allocation by GDG base name. I had to specify an older data set by fully qualified name. Same restriction for batch and TSO.
. . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW [email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Scott Ballentine Sent: Wednesday, September 13, 2017 6:45 AM To: [email protected] Subject: (External):Re: GDG +1 dynamic allocation collision between two concurrent jobs I'll confirm what several others have suggested. In job 1, Allocation gets the ENQ on the GDG base name (MANAGED.TEST.GDG in this case) before allocating the generation data set. Since NEW was specified, the ENQ is obtained exclusive. We'll also get the ENQ for the GDS (MANAGED.TEST.GDG.GxxxxV00) exclusive, and we hold both until you unallocate it. Job 2 also tries to get the ENQ on the GDG base name, and since Job 1 holds it exclusive, you get S99ERROR 0210 (data set unavailable.) Holding both ENQs keeps things somewhat "sane" - if multiple jobs are trying create or delete generations at the same time, then generations might not get rolled in properly or duplicate data sets can occur or "holes" can be created where some generations are missing. Batch JCL will wait for ENQs, so if these DDs were coded in JCL, job 2 would end up waiting for job 1 to unallocate the GDG. Batch allocation has more information to work with when it comes to deadlock prevention than dynamic allocation, so dynamic allocation is a little different - you can wait if you ask for it (and are an authorized program), but waiting isn't the default. I'm not sure if BPXWDYN supports waiting for data sets, but I suspect it doesn't. There's a few tricks you can try. Job 2 can have its own wait and retry logic (like others have already suggested.) Allocating the GDS using the ...GxxxxV00 name does not get the ENQ for the base name, so you could do something like allocate the (+1), get the ...GxxxxV00 name, unallocate it, and then reallocate with the GxxxxV00 name and write your data. That doesn't eliminate the window where the base name is held, but it could significantly shrink it. (There is a chance that somebody could play with your data set in the window where it is unallocated, so this might not be a viable option - that's for you to decide based on what your application is doing.) -Scott Ballentine ([email protected]) z/OS Device Allocation Development ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
