Re: AW: GDG +1 dynamic allocation collision between two concurrent jobs
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
Re: AW: GDG +1 dynamic allocation collision between two concurrent jobs
On Wed, 13 Sep 2017 07:29:43 +0200, Peter Hunkeler wrote: >I think the main problem here is dynamic allocation (SVC99) is not allowing >the unauthorized caller to specify it should enqueue uncondtionally. For that >reason BPXWDYN, TSO ALLOCATE, etc return with "data set in use" instead of >offering the option to wait until it becomes available. > That's allowed if the request specifies S99WTDSN. That, in turn, requires APF authorization, assuming an authorized program can be trusted to circumvent deadlocks. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: GDG +1 dynamic allocation collision between two concurrent jobs
I think the main problem here is dynamic allocation (SVC99) is not allowing the unauthorized caller to specify it should enqueue uncondtionally. For that reason BPXWDYN, TSO ALLOCATE, etc return with "data set in use" instead of offering the option to wait until it becomes available. --Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
AW: GDG +1 dynamic allocation collision between two concurrent jobs
>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": 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. - ... -- Peter Hunkeler -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
