Restart after partial output risks duplicate posting

Troubleshooting guide for Restart after partial output risks duplicate posting. 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

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 after partial output risks duplicate posting — 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.