MVSFORUMS.com

jim haire · Beginner Joined: 30 Dec 2002 Posts: 140 Topics: 40

Scenario:

Multiple jobs are running. Each job creates a +1 version of the same GDG. Will there be contention issues if one job is writing to its version of the GDG while another job starts and tries to write to its version of the GDG?

I didn't think there would be contention in this case, since each version of the GDG is essentially a different file. However, we had a job abend because of this condition.

Can someone clarify whether there should be a contention issue or not.

Thanks!

kolusu · Posted: Wed Apr 27, 2022 9:42 am Post subject: Re: GDG Contention

jim haire · Beginner Joined: 30 Dec 2002 Posts: 140 Topics: 40

We found a workaround for this, but I want to follow up so I understand.

I misspoke about what the condition was. There was not an abend as I stated.

One long running job was writing to the +1 generation of a GDG. All other jobs which were going to be writing to new generations of this GDG were held up until this job finished. This could have caused certain job flows to not meet their SLAs.

I had always thought that if there were multiple jobs running and all writing to the (+1) version of the GDG, the first job in would be creating g0001v00, the 2nd job would be creating g0002v00, the third job would be creating g0003v00, etc and they could all run concurrently. That doesn't seem to be the case.

We ended up removing the step from each job which was creating each generation of the GDG and putting these in a different job. These datasets are still in contention, but the steps that create the GDG was not what was causing the "long running" job to run long. The creation of each generation of the GDG is very quick, so the contention is for a very short period now that it is in a separate job. [/u]

kolusu · Posted: Thu Apr 28, 2022 2:18 pm Post subject:

jim haire,

Thanks for the clarification. The gdg absolute generation ( G000nV00) is resolved at STEP initiation, using the information from Current Catalog at the time the step starts. This will allow the relative number (+0, -1 -n) to be resolved to the right entries.

In general updates to the GDG base must be serialized as you can't have multiple jobs updating it concurrently. since a +1 reference is specified with DISP=NEW, the ENQ will be held on the base.

I think you just did that by modifying the long running job.
_________________
Kolusu - DFSORT Development Team (IBM)
DFSORT is on the Web at:
www.ibm.com/storage/dfsort

www.linkedin.com/in/kolusu