EXPANDED JCL
When you use expanded JCL, the same steps (together with the ones in the called procedures and INCLUDE) are re-executed exactly as they were in the previous run.
GDG resolution is performed by data store while it builds the expanded JCL from the JOBLOG: all the GDG data sets names are replaced with their equivalent expanded form (GDGRoot.GnnnnVnn). For this reason, if you rerun a JCL that contains GDGs more than once, and you do not use the expanded JCL in all the re-executions, the name substitution might not be complete.
=========
RUN1
=========
//GDGSAMPL JOB
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=MYGDG.ROOT(+1),DISP=(NEW,CATLG)
//STEP2 EXEC PGM=MYPGM2
//STEP3 EXEC PGM=MYPGM3
//STEP4 EXEC PGM=IEFBR14
//DD4 DD DSN=MYGDG.ROOT(+1),DISP=OLD
and that the job
fails
in step2, which ends with RC=12:
STEP1 RC=0 --> allocated MYGDG.ROOT.G0001V00
STEP2 RC=12
STEP3 RC=FLUSH
STEP4 RC=FLUSH
The JOBLOG provides information only about
the
GDG allocated in STEP1. Data store is able to resolve the GDG and
build the expanded JCL correctly. At this point, you fix the error
in MYPGM2 and run a Step restart beginning from STEP2 and using normal
JCL:
=========
RUN 2
=========
//GDGSAMPL JOB
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=MYGDG.ROOT(+1),DISP=(NEW,CATLG)
//STEP2 EXEC PGM=MYPGM2
//STEP3 EXEC PGM=MYPGM3
//STEP4 EXEC PGM=IEFBR14
//DD4 DD DSN=MYGDG.ROOT(+1),DISP=OLD
Now, the job fails
in
STEP3, which ends with RC=12:
STEP1 RC=0 --> simulated step
STEP2 RC=0
STEP3 RC=12
STEP4 RC=FLUSH
The JOBLOG contains no information about
the GDG
because data store was no longer able to resolve it in the expanded
JCL (because the previous Step restart was run using normal JCL).
You now fix the error in MYPGM3 and run a Step restart beginning from
STEP3 and using expanded JCL:
=========
RUN 3
=========
//GDGSAMPL JOB
//STEP1 EXEC PGM=IEFBR14
//DD1 DD DSN=MYGDG.ROOT(+1),DISP=(NEW,CATLG)
//STEP2 EXEC PGM=MYPGM2
//STEP3 EXEC PGM=MYPGM3
//STEP4 EXEC PGM=MYPGM4
//DD4 DD DSN=MYGDG.ROOT(+1),DISP=OLD
In this
way,
even when the data store is unable to resolve a GDG, the necessary
changes are nevertheless contained in the submitted JCL.Expanded JCL is not stored in the JS after a Job or Step restart, because it is always built by data store from the last JOBLOG run.
- Stepname.Procstep is used: linear JCL cannot contain this kind of step because calls to procedures have been removed. The reference to the step and the step will usually be changed to Procstep only. This might not be enough if Procstep is not unique in the JCL (see the next bullet).
- When Stepname is used and the Stepname is
not unique in the JCL.
For example, if STEP2 in a procedure has a COND=(0,NE,STEP1), and
STEP1 is the first step in the procedure and a previous step of the
original JCL, the COND is resolved incorrectly by JES if the step
name from STEP1 is not made unique. When these conditions exist, data
store generates the required unique step name in the format
JJJnnnnn
(where nnnnn is a number) and adds a comment line just before the changed EXEC statement in the format://*OLDStep=(xxx) OLDProcStep=(yyy) NEWStep=zzz
where xxx.yyy is the old step name, and zzz is the new one.
To see which steps have changed name in the expanded JCL use the STEP command on the EQQMERSL panel.
- The change of proc/step names might affect external products that identify with these values.
- JJJnnnnn step names cannot be used in the JCLs, because this might cause incorrect step name substitution.
- Procedures submitted by HCL Workload Automation for Z must contain the PEND statement.
- Nested external procedures must contain the PEND statement.
- Nested inline procedures cannot
be ambiguous. For example, the
following nesting is clear:
On the other hand, the following nesting is ambiguous and might not work properly:step1 exec pgm=PGM1 step2 exec PRO1 step1 exec pgm=PGM2 step2 exec PRO2 step1 exec pgm=PGM3 step2 exec PRO23 step1 exec pgm=PGM4 step3 exec pgm=PGM5
In addition, consecutive inline procedures can cause problems, for example:step1 exec pgm=PGM1 step2 exec PRO1 step1 exec pgm=PGM2 step2 exec PRO2 step1 exec pgm=PGM3 step2 exec PRO23 step1 exec pgm=PGM4 step3 exec pgm=PGM5 step3 exec pgm=PGM6 step3 exec pgm=PGM7
To avoid problems, insert a dummy step as follows:step2 exec PRO1 step3 exec PRO2
step2 exec PRO1 stepD exec pgm=iefbr14 step3 exec PRO2
//EXAMPLE JOB
//STEP1 EXEC PGM=IEFBR14
//STEP2 EXEC PROC1
where PROC1 is the following:
//PROC1 PROC
//STEP1 EXEC PGM=IEFBR14
//STEP2 EXEC PGM=IEFBR14,COND=(0,NE,STEP1)
// PEND
If you select Expanded JCL=N
, you will
see the following values for the StepName
and ProcStep
fields
in the step list of EQQMERSL panel:
… Step StepName ProcStep PgmName …
… No
… 0001 STEP1 IEFBR14 …
… 0002 STEP2 STEP1 IEFBR14 …
… 0003 STEP2 STEP2 IEFBR14 …
If
you select Expanded JCL=Y
, you will see:
… Step StepName ProcStep PgmName …
… No
… 0001 STEP1 IEFBR14 …
… 0002 JJJ00001 IEFBR14 …
… 0003 STEP2 IEFBR14 …
This
is consistent with the nature of expanded JCL. As mentioned before,
an expanded JCL is a linear JCL, in which all the procedure calls
are expanded and made ‘flat’. Therefore, if you want Expanded
JCL=Y
, the step name (which is the procedure invocation step
name) will always be blank and the procedure name will always be evaluated
with the step name in the JCL procedure (or the job step name, if
the step does not invoke a procedure), possibly changed to JJJxxxxx to
univocally identify the step tested by
the COND parameter.