I wonder how this plays with the new (z/OS 2.2?) enqueue demotion? -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Peter Hunkeler Sent: Wednesday, September 13, 2017 12:18 AM To: [email protected] Subject: AW: GDG +1 dynamic allocation collision between two concurrent jobs
Sorry, sending out too early. I repost with the full list of guidelines >Is there a way around this? > >Even with SMS-managed GDGs, where the generation is cataloged at >allocation, two jobs that dynamically allocate +1 generations (with >GDGNT) will collide. Not according to the FM "DFSMS Using Data Sets", which says under "Submitting Multiple Jobs to Update a Generation Data Group": Submitting Multiple Jobs to Update a Generation Data Group This topic provides guidelines that you can use when you submit multiple jobs that update a particular GDG: - No two jobs running concurrently can refer to the same GDG. - For batch or dynamic allocation jobs that specify relative generation numbers, the system enqueues the GDG base name as shared or exclusive, depending on the highest disposition that is used in the job. The GDG base name is exclusive if the highest job disposition is NEW or MOD. The GDG base name is shared if the highest job disposition is SHR. This safeguard prevents concurrent users from updating the GDG by adding or deleting generation data sets while other users are using the GDG. - For batch or dynamic allocation jobs that use absolute generation data setnames, the system does not enqueue the GDG base. Multiple users are able to update the GDG by deleting or adding generation data sets at the same time. This situation does not affect the integrity of the GDG or generation data sets. However, jobs that use relative generation numbers might obtain the wrong generation, because the numbers can change. Even if you use absolute generation numbers, a job might accidentally replace a generation data set that another job is using. The only time that you can use absolute generation numbers is when you need to run concurrent jobs that use the same GDG and at least one of the jobs uses a disposition of NEW or MOD. Ensure that the jobs do not accidentally overlay a generation data set that another job is using. Restriction: Be careful when you update GDGs because two or more jobs can compete for the same resource and accidentally replace the generation data set with the wrong version in the GDG. To prevent two users from allocating the same absolute generation data set, take one of the following actions: o Specify DISP=OLD. o Specify DISP=SHR and open the data set for output. -- Peter Hunkeler ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
