RESTART Parameter

Purpose

The RESTART parameter in JCL allows you to restart a job from a specific job step rather than from the beginning. This is particularly useful for recovering from failures in long-running jobs, saving processing time by skipping steps that have already completed successfully.

Syntax

jcl
1
2
3
//jobname JOB (accounting-information),programmer-name,RESTART=stepname
                       
//jobname JOB (accounting-information),programmer-name,RESTART=(stepname,checkid)

Format

The RESTART parameter can be specified in two formats:

  • RESTART=stepname - Restarts from the beginning of the specified step
    • All steps before the specified step are bypassed
    • The specified step and all following steps will be executed
  • RESTART=(stepname,checkid) - Restarts from a checkpoint within the specified step
    • All steps before the specified step are bypassed
    • The specified step is restarted from the checkpoint ID
    • All following steps will be executed

Examples

Basic Restart

jcl
1
//PAYROLL JOB (ACCT123),'JOHN SMITH',RESTART=STEP3

Restarts the job from STEP3, bypassing STEP1 and STEP2

Restart with Checkpoint

jcl
1
//REPORT  JOB (ACCT456),'JANE DOE',RESTART=(STEP2,CKPT0012)

Restarts STEP2 from checkpoint CKPT0012, bypassing STEP1

Restart First Step

jcl
1
//BATCH   JOB (ACCT789),'OPS TEAM',RESTART=STEP1

Restarts the job from the first step (STEP1)

Restart in a Procedure

jcl
1
//PROCJOB JOB (ACCT321),'PROC USER',RESTART=STEP2.PROCSTEP

Restarts the job at a step called PROCSTEP within a procedure called by STEP2

Restarting Different Types of Jobs

Restart TypeSyntaxUsage
Simple step restartRESTART=stepnameStandard restart at beginning of step
Checkpoint restartRESTART=(stepname,checkid)Restart from a checkpoint within a step
Procedure stepRESTART=stepname.procstepRestart at a specific step within a procedure
Checkpoint in procedureRESTART=(stepname.procstep,checkid)Restart from a checkpoint within a procedure step

Checkpoint/Restart Facility

Checkpoint/restart is a recovery facility that allows programs to record their progress at specific points (checkpoints) and later be restarted from those points rather than from the beginning.

  • Automatic Checkpoint/Restart - System automatically restarts a job step from the latest checkpoint if it fails
  • Deferred Checkpoint/Restart - Operator or user explicitly requests restart from a checkpoint by specifying RESTART parameter
  • Requirements for checkpoint/restart:
    • Program must issue CHKPT macro to establish checkpoints
    • JCL must include a SYSCHK DD statement
    • Restart JCL must specify RESTART=(stepname,checkid)

System Considerations

  • When you restart a job, all steps before the specified restart step are bypassed
  • RESTART overrides any COND parameters for steps that are bypassed
  • RESTART does not override COND parameters for the step being restarted or subsequent steps
  • Restarted jobs need access to the same data sets as the original job
  • DD statements with status of NEW in prior steps may need to be changed to OLD or MOD for restart
  • Generation data groups (GDGs) may need special handling for restart
  • Using the RD (restart definition) parameter with RESTART can control automatic restart capabilities

Considerations for GDG Datasets

Generation Data Groups (GDGs) require special consideration when restarting jobs:

  • Relative generation numbers may have changed between original run and restart
  • Current generation (+0) may be different from when the job first ran
  • Consider using absolute generation numbers for restart situations
  • May need to manually adjust generation numbers in restarted jobs

Notes

  • RESTART is optional - if omitted, the job starts from the beginning
  • Restarted jobs need the same JCL structure as the original job
  • RESTART can be used with RD parameter to control automatic restart options
  • Temporary datasets created in bypassed steps won't be available in restarted steps
  • SYSCHK DD statement is required for checkpoint restart operations
  • Be careful with disposition (DISP) parameters when restarting a job
  • Check for data set integrity issues when restarting a job
  • Consider using restart management products for complex restart scenarios

Best Practices

  • Design jobs with restart capability in mind, especially long-running jobs
  • Include checkpoint logic in programs that process large amounts of data
  • Break large jobs into logical steps that can be restarted independently
  • Consider data set dispositions carefully for restart scenarios
  • Document restart procedures for critical jobs
  • Test restart procedures regularly as part of disaster recovery planning
  • Use generation data sets with caution in jobs that may need to be restarted

Common Mistakes

  • Restarting a job without considering data set dispositions
  • Omitting the SYSCHK DD statement when using checkpoint restart
  • Incorrect specification of checkpoint IDs
  • Not accounting for generation data set changes during restart
  • Assuming temporary datasets from bypassed steps will be available
  • Restarting at a step that depends on output from bypassed steps

Related Concepts

Related Pages