On Wed, 13 Sep 2017 07:18:13 +0200, Peter Hunkeler wrote: > >>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. > In this thread, (too) much of the discussion has focused on batch JCL, whereas the original question concerned dynamic allocation (see "Subject:" line). If a program allocates a GDG only dynamically, not mentioning it in JCL:
o When are the various ENQs dequed? o Does relative generation 0 refer to the same absolute DSN in every exec in every step even though intervening steps may have dynamically added generations? o What control block holds the anchor(s) needed to do this? o Is any execution environment created by fork() counted as a separate job? o How may a program which allocates generation +1 dynamically discover the absolute DSN? >- 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. > Does opening for output cause an EXC ENQ even when allocated DISP=SHR? -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
