JCLadvanced
Checkpoint/Restart and Job Recovery
Understand how long-running batch jobs use checkpoints to resume from a mid-point after failure instead of rerunning from the beginning.
A batch job that fails at hour eight of nine should not start again from the beginning. Two mechanisms avoid that, at different granularities.
Checkpoint/restart is a video game's save-point system — without it, dying at the final boss means replaying the entire level from the start; with periodic saves, you resume from the last checkpoint instead of losing hours of progress.
Key Concepts
1
RESTART= restarts at a step boundary.
//MYJOB JOB ...,RESTART=STEP4RESTART=
2
Steps one to three are skipped entirely. Their output must still exist and still be valid, which is why
DISP matters so much: a step whose output was DELETEd on abend has to be rerun, and one that was
catalogued can be reused.
DISPDELETE
3
//MYJOB JOB ...,RESTART=STEP3.COMP restart inside a PROC4
This is coarse. If step four is a nine-hour program that failed at hour eight, restarting the step
reruns all nine.
5
Checkpoints restart inside a step. The program periodically writes a marker to a checkpoint dataset
recording how far it got:
6
//SYSCHK DD DSN=PROD.CHECKPOINT,DISP=(NEW,KEEP)7
On restart, processing resumes from the last checkpoint instead of from the start of the step. On a long
run that is the difference between eight hours lost and twenty minutes.
8
It is not free, and the requirements are the real answer. A program only restarts correctly if it was
designed to:
9
- *Idempotent work.* Records processed since the last checkpoint will be processed again. If that means
posting a payment twice, the restart is worse than the rerun.
- *Coordinated files.* Output written after the checkpoint must be backed out or overwritten, so the
file position and the checkpoint have to agree.
- *Checkpoint frequency.* Too often and the checkpointing dominates the runtime; too rarely and there is
little to save.10
So you cannot add restart to an existing program with a JCL parameter. RESTART= is JCL; checkpointing
is a property of how the program was written. That distinction is what the question is usually checking.
RESTART=
11
And the operational side. In a real incident the question is not only "can we restart" but "from where,
and is the data consistent". Production support teams keep restart instructions per job for exactly that
reason — which step to restart from given which failure, and what to clean up first. A job with no restart
documentation is one where somebody works that out at 3 a.m.
12
What the interviewer is probing.1. "Why does checkpoint restart matter?" Probing: the operational driver. Stalls: "Safety."
Moves up: a long batch job that fails near the end can resume from the last checkpoint instead of
rerunning for hours inside a fixed batch window.
13
2. "What makes a job restartable?" Probing: the design requirement. Stalls: "Checkpoints."
Moves up: it must be idempotent from the restart point — committed database work and
already-written output have to be accounted for, not just repeated.
14
3. "What is the simplest practical alternative?" Probing: judgement. Stalls: "None." *Moves
up:* splitting the job into smaller steps with intermediate datasets, so a failure only costs the
one step.
15
4. "What does a restart need from the operator?" Probing: the process. Stalls: "Nothing."
Moves up: the correct restart step and checkpoint id, plus care with GDG relative numbers and
DISP, which is where restarts usually go wrong.