|
View previous topic :: View next topic
|
| Author |
Message |
jdeeponline
New User
Joined: 08 Sep 2009
Posts: 27
Location: Charlotte
|
|
|
|
| I am planning to run a job with a GDG file. In case, half way through the job, a newer generation of the GDG is created, will my job abend? |
|
| Back to top |
|
 |
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
The system places an enqueue on the GDG base name when a job that will be creating a new generation is started. Therefore, the scenario you describe won't happen -- the newer generation cannot be built while your job is running since the system will prevent the other job from starting.
Note, however, that this applies only to relative generation processing -- the (+1) construct. If you use absolute generation numbers, no enqueue is done and you have to ensure you don't do anything to mess yourself up. Your job may or may not abend depending upon what is being done and how. |
|
| Back to top |
|
|
jdeeponline
New User
Joined: 08 Sep 2009
Posts: 27
Location: Charlotte
|
|
|
|
Hi Robert
The scenario to be exact is that Job 1 uses GDG(0) to process. Meanwhile, JOB 2 may or may not have started running (output file --> GDG(+1)).
Now half way through JOB 1 , JOB 2 completes and hence, now GDG(0) has actually changed.
Though I realise that the relative version number isn't significant once the job starts, I just want to check what sort of an impact would it be, if any. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
When your job uses generation(0), it is resolved to the absolute generation.
For the duration, that dataset will be used, not a new (+1) created in "job 2" (job 2 will not create a new +1 while job 1 is running). |
|
| Back to top |
|
|
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
Robert,
and PeterHolland was complaining about being ignored! |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
| Under your scenario, jdeeponline, job 2 cannot start until job 1 has completed. Job 2 will require exclusive access to the GDG base and it cannot get exclusive access until all jobs using the GDG have completed. If job 2 starts before job 1, job 2 will complete before job 1 starts. In no case will both jobs be running simultaneously. |
|
| Back to top |
|
|
PeterHolland
Global Moderator
Joined: 27 Oct 2009
Posts: 2481
Location: Netherlands, Amstelveen
|
|
|
|
| dbzTHEdinosauer wrote: |
Robert,
and PeterHolland was complaining about being ignored! |
LOL  |
|
| Back to top |
|
|
jdeeponline
New User
Joined: 08 Sep 2009
Posts: 27
Location: Charlotte
|
|
|
|
Hi Robert,
Do you mean to say that no job can run to create a GDG generation if any other GDG version of the base is being used by another job? |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8697
Location: Dubuque, Iowa, USA
|
|
|
|
The manuals link has the JCL Language Reference manual, which lays it out explicitly in chapter 12.19 on the DISP parameter:
| Quote: |
DISP and ENQ: Before starting the first step of a job, the initiator requests control of all of the data sets in that job by issuing an ENQ for each of them, using the value specified for DISP to determine the kind of ENQ issued. The initiator issues the ENQ for each data set at the highest level required for that data set by any step of the job. For example, if all steps of the job request shared control of a specific data set (DISP=SHR) then the ENQ for that data set is requested as SHR. If, on the other hand, any step of the job requests exclusive control of a specific data set (DISP=NEW, DISP=MOD, or DISP=OLD), then the ENQ for that data set is requested EXCL.
The ENQ for each dataset is released at the end of the last step of the job referencing it. Since ENQs cannot be downgraded from EXCL to SHR, if one step needs the ENQ EXCL and a following step only needs it SHR, the ENQ is still issued as EXCL and held until the end of the last step which references that data set, at which point the ENQ is released entirely.
DISP and ENQ for generation data sets: The way the initator issues an ENQ to control generation data sets can be different than with other data sets. The initiator only issues the ENQ for the GDG base name for a generation data set that is referenced by either:
* Their relative GDG names (for example, DSN=TEST.GDG.DATASET(0)).
* As GDG ALLs (for example, DSN=TEST.GDG.DATASET)
For example, the initiator issues the ENQ for the GDG base name, TEST.GDG.DATASET for the generation data sets shown in the list above . Generation data sets referenced by either their relative GDG names or as GDG ALLs are processed this way because the initiator does not know which specific absolute generation names will be required. This is because the conversion from relative generation name to absolute generation name is done during the allocation for the step referencing the data set. The ENQ for the specific, absolute, generation (G0000V00) data set name or names is issued at the start of the step requesting the relative GDG or GDG ALL.
Note that the initiator does not issue an ENQ for the GDG base name for a generation data set that is referenced by its absolute GDG name. Instead it issues an ENQ for that specific G0000V00 data set name. |
Note that a (+1) generation is DISP=NEW by definition so exclusive control is required -- and note that the GDG base name is being controlled (not a specific generation), so that puts a reserve on the entire GDG. |
|
| Back to top |
|
|
|
|
