EXPANDED JCL

For example, suppose you run the following JCL:

=========
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.

To decide whether or not to use the expanded form for a specific JCL, consider that expanded JCL is built from the JOBLOG by removing all calls to procedures: as a result, all the references to steps, such as COND or IF THEN REFDD, are changed by data store if the following conditions occur:

• 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 following limitations also occur when you use expanded JCL:

• 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:

  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

  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
             step3 exec pgm=PGM6
  step3 exec pgm=PGM7

  In addition, consecutive inline procedures can cause problems, for example:

  step2 exec PRO1
  step3 exec PRO2

  To avoid problems, insert a dummy step as follows:

  step2 exec PRO1
  stepD exec pgm=iefbr14
  step3 exec PRO2

//EXAMPLE JOB 
//STEP1 EXEC  PGM=IEFBR14
//STEP2 EXEC  PROC1   

//PROC1 PROC 
//STEP1  EXEC  PGM=IEFBR14                  
//STEP2  EXEC  PGM=IEFBR14,COND=(0,NE,STEP1)
// PEND

…    Step     StepName     ProcStep       PgmName …
…    No                             
…    0001                   STEP1           IEFBR14 …
…    0002    STEP2          STEP1           IEFBR14 …
…    0003    STEP2          STEP2           IEFBR14 …

…    Step     StepName     ProcStep       PgmName …
…    No                             
…    0001                   STEP1          IEFBR14 …
…    0002                   JJJ00001       IEFBR14 …
…    0003                   STEP2          IEFBR14 …