• There should be a narrative at the beginning of each JCL member containing the following:
o A detailed description explaining the processing
o The project number, date written and author.
o A list of all inputs and outputs used. This should include files, databases, report names, etc.
o For procedures (procs), what JCL member submits the procedure.
 
• There should always be a change log and an entry in that log for each significant change made to any JCL containing the following:
o A detailed description explaining the processing.
o The project number, date written and author.
 
• The change log and list of inputs/outputs should be updated with each change implemented to production.
 
• There should be a comment box above each step containing the following:
o A brief description of explaining the processing for that step
o Restart instructions with the following format:
//****************************************************************
//*  RESTART INSTRUCTIONS                    **
//*  IF JOB ABENDS IN STEP0010 ADD THE FOLLOWING PARAMETER      **
//*  TO THE JOB CARD:                                           **
//*  RESTART=JOBXXXXX.STEP0010                    **
//*  AND RESUBMIT THE JOB.                                      **
//****************************************************************
•   The RESTART parameter must specify the name of the step which has the EXEC PGM=xxxx.
•   If EXEC PGM=xxxx exists in the JCL, the restart parameter will only contain the JCL step name.
•   If EXEC PGM=xxxx exists in a PROC executed by a JCL member, the restart parameter will contain the JCL step name followed by the PROC step name.
•   If EXEC PGM=xxxx exists in a PROC A which is executed by PROC B, the restart paramter will contain PROC B step name followed by PROC A step name. 
 
• Examples of restart instructions:
Restart Description
jclstep Restart JCL step from Job
jclstep.procstep Restart step from a procedure
jclstep.SAS Restart JCL step from Job executing SAS procedure

File Considerations
• DISP=SHR should be used for all files being read.  This allows multiple jobs/users to access the data.
• DISP=OLD should only be used for files being updated.  The data set will be unavailable for all other jobs/users.
• DISP=MOD should not be used.  Restarting jobs with DISP=MOD and ensuring data integrity is very difficult.
• Work data sets are cataloged data sets used by only one job.  They are used in place of temporary data sets (&&dsname).  They are to be deleted and re-allocated for each job.
• Work data sets are deleted either at the beginning of the job, or at the end of the job.
 
• A SECURITY step should be used to copy sequential files. 
o An unlimited number of input files and output files can be copied in one SECURITY step. 
o Generic control cards should be used for the SYSIN of SECURITY steps. 
o The syntax for a SECURITY step is as follows:
//STEP0010 EXEC PGM=SECURITY
//STEPLIB  DD DSN=D.SYSPROGS,DISP=SHR
//SYSPRINT DD SYSOUT=(,),OUTPUT=*.RMDSJCL
//INPUT01  DD …
//OUTPUT01 DD …
//SYSIN    DD DSN=B79.D953.HP%GIOxxyy..CONTROL.CARDS(GIOxxyy),DISP=SHR

• An IDCAMS step should be used to copy VSAM files.
o An unlimited number of input files and output files can be copied in one SECURITY step. 
o Generic control cards should be used for the SYSIN of SECURITY steps. 
o The syntax for a SECURITY step is as follows:
//STEP0010 EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=(,),OUTPUT=*.RMDSJCL
//INFILE01 DD …
//OUTFIL01 DD …
//SYSIN DD DSN=B79.D953.HP%GRPxxyy..CONTROL.CARDS(GRPxxyy),DISP=SHR
 
• Data sets where the data needs to be accessed from two centers needs to be analyzed to determine if the file should be a tape file cataloged at both centers, or a disk file equalized between two centers when updated.  Option S.7.1 on TSO can help with the decision by showing the cost of each storage device.  
• Temporary data sets (&&dsname) should not be used.  Temporary data sets generally make a job non-restartable.
• Alternative:  Use work data sets instead.
• See also Tape File Considerations.

GDG Considerations
• GDG’s should be defined through TSO option S.8.
 
• The number of generations of a GDG should be altered through TSO option S.8.
 
• GDG bases can be deleted through IDCAMS.  The SYSIN should have the following format:
DELETE gdg data set name GENERATIONDATAGROUP
 
• The following TSO command can be used to view information about a GDG:
LISTCAT ENTRIES (‘gdg data set name’) ALL
 
• New generations of GDG’s should be created in the very last step of the JOB.  This is to make JOBs more easily restartable.
o Alternative:  Write the data to a work data set.
 
• GDG generation numbers are updated when the JOB completes.
 
• Restart instructions need to be considered for new generations of GDG’s created before the last step of the JOB.
 
• In procedures, the generation number should be a symbolic parameter for each new generation of a GDG created before the last step of the JOB. 
 
IMS Considerations
 
• IMS BMP’s should never contain database DD cards.
• Use DFSVSAMP DD DSN=IMS20.PROCLIB(DFSVSM00)’ for generic.
• BMP steps require all files to be pre-allocated.
• PSB names should match program names.
 
 
Inter-Center Equalization
 
• Disk Sequential file
• Disk Partitioned Data Sets 
• Tape Files  (hyper link to the Tape File Considerations page: JCL-Tape File Considerations
 
Warning:  Disk files have a limit as to the number of records that can be equalized.  Files with 300,000 or more records have the chance of being canceled by computer operations.
 
Recommendation when equalizing a tape catalog:

If tape GDG’s are utilized during the equalization process, the need to delete the tape file on the receiving center is eliminated.

See Tape File Considerations and GDG Considerations for more information.
 
 
Note: 
SYSPRINT from the receiving job will always print.  To send SYSPRINT to RMDS would require  to maintain a copies