GDG resolution considerations

GDG resolution is slightly different depending on the type of JCL:

Expanded JCL:
Data store gets the information about GDG data sets from the JOBLOG of the last run only. All the GDG data sets for which information is directly available (SYSMGS contains a GnnnnVxx expansion message), are resolved immediately with the use of such information. The GDG data sets for which information is not directly available (such as GDG in flushed steps) are resolved with the following DIFF mechanism: If a resolved GDG data set exists with the same GDG root data store, calculate the difference between the two relative numbers to obtain the absolute value. For example, if data set GDGRoot(+1) was resolved as GDGRoot.G0025V00, the unresolved GDG data set GDGRoot(+2) will be resolved as GDGRoot.G0026V00.

This might cause numbers to wrap around. For example, if the resolved GDG data set is GDGRoot(+1)↔GDGRoot.G9999V00, the unresolved GDG data set GDGRoot(+2) will be resolved as GDGRoot.G0001V00. As a consequence, if there are skipped GDG generation numbers, the resolution might be incorrect.
The DIFF mechanism implies also that different versions (such as V00 and V01) could lead to incorrect resolutions: GDG resolution is not supported for this kind of JCL. For example, suppose you run the following JCL having GDGROOT(0) = GDGROOT.G0004V00 before the first job run:
```
//JOB XXX 
//STEP1 EXEC PGM=IEFBR14
//DD1  DD DSN=GDGROOT(+1),DISP=(NEW,CATLG)
//STEP2 EXEC PGM=IEFBR14
//DD2  DD DSN=GDGROOT.G0005V01,DISP=(NEW,CATLG) 
//STEP3 EXEC PGM=IEFBR14
//DD3  DD DSN=GDGROOT(+1),DISP=OLD
//STEP4 EXEC PGM=IEFBR14
//DD4  DD DSN=GDGROOT(+2),DISP=OLD
```
The result of the first run will be:
```
  STEP1 ==> allocates GDGROOT.G0005V00
  STEP2 ==> allocates GDGROOT.G0005V01
  STEP3 ==> refers    GDGROOT.G0005V01
  STEP4 ==> refers    GDGROOT.G0006V00
```
Now execute a second run, restarting from STEP3 and excluding STEP4. The result will be:
```
STEP3 ==> refers via GDG simulation GDGROOT.G0005V01
```
Now execute a third run, restarting from STEP1. The result will be a JCL error due to incorrect GDG resolution. This happens because the JOBLOG of the last run had information only about:
```
STEP3 GDGROOT(+1) = GDGROOT.G0005V01
```
and the DIFF mechanism is not able to distinguish when to use V01 and when to use V00.
Normal JCL:
Same as in expanded JCL with an additional iteration of the resolution process using information from all the previous job runs whenever unresolved GDGs still exist. Resolution is performed by the Controller and not by Data store.