JCL Troubleshooting
RESTART skips required setup step
Troubleshooting guide for RESTART skips required setup step. Restarts are where batch jobs cause real business damage: rerunning work that already posted creates duplicates that are hard to unwind.
What it means
- RESTART=stepname reruns the job from that step — every step from there on executes again, including ones that already completed.
- Checkpoint restart (RESTART with CHKPT) resumes inside a step, but only if the program takes checkpoints.
- The danger is partial output: a step that wrote half its file before failing will write it again on restart.
Common causes
- RESTART=STEP3 skips STEP1/STEP2 setup, but STEP3 needs a work file that STEP2 created — the work file is gone or stale.
- Checkpoint restart duplicates records because the program commits every 1000 records but checkpoints every 5000.
- Restart after partial output: the output dataset was DISP=MOD or reused, so rerun appends a second copy of the first-half records.
- A step that posted to a database is rerun without backing out the first attempt — double posting.
- Automatic restart (scheduler) resubmits the whole job while the operator manually restarted one step — two copies run concurrently.
- GDG (+1) on restart creates a second new generation instead of reusing the failed one.
How to diagnose
- Before any restart, list what each step already produced: which datasets were created, which tables were updated, which generation was cataloged.
- Check whether the failed step is restartable: does it take checkpoints? does it use DISP=NEW outputs it can recreate?
- Compare record counts: input count vs output count so far tells you how far the failed step got.
- For GDG: check whether the (+1) generation from the failed run was cataloged — rerunning creates (+2) and orphans (+1).
How to fix it
- Delete or back out partial outputs before restart: uncatalog the failed (+1) generation, empty the half-written file.
- Restart from the failed step only after its inputs are intact — rerun the setup step too if its work files are gone.
- Make programs checkpoint-aware: checkpoint and commit at the same frequency so restart never reprocesses committed work.
- For database updates, back out the unit of work (or run the undo job) before rerunning the step.
- Coordinate with scheduling: cancel the automatic retry before doing a manual restart.
Example: Restart-safe JCL: fresh outputs per run
//STEP1 EXEC PGM=LOADPROG,RESTART=STEP2
//OUT DD DSN=APP.OUTPUT(+1),
// DISP=(NEW,CATLG,DELETE)
//*
//* Before restart: delete the failed (+1) generation,
//* then resubmit starting at the failed step.
DISP=(NEW,CATLG,DELETE) means a rerun recreates the file cleanly — but only after you delete the failed generation first.
Interview tip
- Q: A job failed at STEP5 of 8 after writing half its output. RESTART skips required setup step — what do you do before restarting?
- A: I inventory what STEP5 already produced — partial output dataset, any database updates, the GDG generation it cataloged. I back out or delete the partial work first, then restart at STEP5, because rerunning blindly would duplicate everything STEP5 already wrote.
Prevention checklist
- Design every step to be rerunnable: clean outputs, committed checkpoints, no hidden state.
- Checkpoint and COMMIT at the same interval.
- Document the restart procedure per job: what to delete, what to back out, where to restart.
- Never let automatic scheduler retry and manual restart run at the same time.
