JCL Restart Strategy for Batch Support: Safe PROCSTEP Restarts, GDG Handling, and Return Codes

Learn a safe JCL restart approach for production batch support, including PROCSTEP restarts, GDG handling, return codes, and restart checklists.

Short introduction

JCL restart is one of the most practical skills for mainframe batch support. In a real batch cycle, a job may fail because of a data issue, missing dataset, space problem, DB2 contention, file enqueue, or a temporary infrastructure issue. The support team must decide whether to rerun the full job, restart from a failed step, skip completed processing, or involve application teams for data correction.

A restart looks simple when we say RESTART=STEP010, but production support requires more thinking. Some steps create output files, some update DB2 tables, some create GDG generations, and some send downstream trigger files. Restarting blindly can duplicate updates, overwrite valid output, or send the same file twice. This article explains a safe restart approach using JCL concepts, PROCSTEP naming, GDG checks, return codes, and basic operational discipline.

Real-world production use case

Consider a nightly healthcare claims batch job. The job reads validated claim input, sorts it, applies COBOL business rules, updates a DB2 claim status table, writes an exception report, and creates a GDG extract for a downstream reporting system.

A simplified flow may look like this:

• STEP010 validates input file availability.
• STEP020 sorts claim records by member and claim number.
• STEP030 runs a COBOL program to apply business rules.
• STEP040 updates DB2 status and writes an audit report.
• STEP050 creates a GDG extract for downstream reporting.
• STEP060 sends a trigger or notification file.

Now assume STEP050 fails with a space abend after STEP040 completed successfully. A full rerun may repeat DB2 updates or create duplicate audit entries if the application is not designed for idempotent processing. Restarting from the wrong point may also reuse an old sort output or overwrite an existing report. The safer path is to understand what completed, what was committed, and what outputs must be cleaned up or preserved before restart.

Step-by-step explanation

### 1. Read the job log before touching the restart

Start with the JES output, not with assumptions. Confirm the exact abend code, failed step name, PROCSTEP name if a procedure was used, return codes from prior steps, dataset allocation messages, and any application messages from COBOL or DB2. A restart decision should be based on facts visible in the spool.

Important items to capture:

• Job name and job ID.
• Failed step and, if inside a PROC, the procedure step.
• Abend code or condition code.
• Last successful business checkpoint, if the program prints one.
• Input and output dataset names used by the failed step.
• Whether DB2 commits happened before failure.

### 2. Identify whether the job uses direct steps or PROC steps

For direct JCL steps, restart syntax may be straightforward:

//CLAIMJOB JOB (ACCT),'CLAIM BATCH',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,RESTART=STEP050

If the failed step is inside a cataloged or in-stream procedure, you often need both the JCL step that invokes the PROC and the PROC step name:

//CLAIMJOB JOB (ACCT),'CLAIM BATCH',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,RESTART=RUNPROC.STEP050
//RUNPROC  EXEC PROC=CLAIMPRC

The exact naming depends on how the job and PROC are structured. The key point is to restart the same logical unit that failed, not a nearby step chosen by guesswork.

### 3. Check condition code logic

Many production jobs use COND, IF/THEN/ELSE, or scheduler return-code rules. During restart, earlier steps are not executed, so later condition logic may behave differently than in a full run. If a later step expects a dataset created in a skipped step, verify that the dataset still exists and contains the correct cycle data.

Example condition style:

//STEP040 EXEC PGM=CLAIMUPD
//SYSOUT  DD SYSOUT=*
//INFILE  DD DSN=DBALA.CLAIM.SORTED(+0),DISP=SHR
//AUDIT   DD DSN=DBALA.CLAIM.AUDIT(+1),DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(5,2)),DCB=(RECFM=FB,LRECL=120)
//STEP050 EXEC PGM=IEBGENER,COND=(4,LT,STEP040)
//SYSUT1  DD DSN=DBALA.CLAIM.EXTRACT.WORK,DISP=SHR
//SYSUT2  DD DSN=DBALA.CLAIM.EXTRACT(+1),DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(20,10)),DCB=(RECFM=FB,LRECL=200)
//SYSPRINT DD SYSOUT=*
//SYSIN   DD DUMMY

In this example, the restart must consider whether STEP040 already created a new audit GDG generation. If STEP040 is skipped during restart, STEP050 must still point to the correct input and should not depend on a missing temporary dataset.

### 4. Validate GDG generation handling

GDGs are common in batch processing, but they can be dangerous during restart. (+1) means create a new generation. If a failed attempt already cataloged a generation before abending, a restart that again uses (+1) may create a second generation. That may be correct in some cases and wrong in others.

Before restart, verify:

• Did the failed step catalog the output GDG?
• Is the cataloged generation complete or partial?
• Should the partial generation be deleted before restart?
• Should the restart use (+1) again or consume an existing (+0)?
• Are downstream jobs expecting exactly one generation for the business date?

Never delete a generation just because it was created by a failed job. First confirm with the runbook, application owner, or established support procedure. Some failed outputs are needed for investigation.

### 5. Confirm application restart behavior

JCL restart only controls where the operating system begins execution. It does not automatically roll back business effects already committed by application programs. A COBOL-DB2 step may commit every 1,000 records. If it abends after 80,000 records, restarting the same step without application checkpoint logic may reprocess records unless the program is designed to skip completed work.

Look for indicators such as:

• Restart control table.
• Checkpoint dataset.
• Commit count messages.
• Audit count messages.
• Program parameters for restart mode.
• Runbook notes for partial DB2 updates.

Example JCL restart pattern

Below is a simplified educational example showing restart from a PROC step and temporary adjustment of space for a failed extract step. Site standards vary, so validate before using any pattern in a real environment.

//CLMEXTJB JOB (ACCT),'CLAIM EXTRACT',CLASS=A,MSGCLASS=X,
//             NOTIFY=&SYSUID,RESTART=CLMPROC.EXTRACT
//* Restart reason: previous run failed in EXTRACT with SB37.
//* Prior steps VALIDATE, SORTCLAIM, APPLYBUS completed RC=0000.
//* Confirmed DB2 update step was not part of this restart path.
//CLMPROC EXEC PROC=CLMEXTP
//EXTRACT.SYSUT2 DD DSN=DBALA.CLAIM.EXTRACT(+1),
//             DISP=(NEW,CATLG,DELETE),
//             SPACE=(CYL,(100,50),RLSE),
//             DCB=(RECFM=FB,LRECL=200,BLKSIZE=0)

This example documents the reason for restart and overrides the failing PROC step DD statement. In a production shop, comments like this help the next support person understand why the restart was submitted.

Common mistakes

• Restarting from the failed step without checking whether prior steps committed DB2 updates.
• Forgetting that PROC restarts may need jobstep.procstep syntax.
• Recreating GDG (+1) outputs and sending duplicate downstream files.
• Deleting partial output without preserving evidence for problem analysis.
• Ignoring condition-code logic that changes during restart.
• Assuming a space abend is always safe to rerun without checking catalog status.
• Restarting a job after fixing JCL but leaving stale temporary or work datasets.
• Not documenting the restart reason in the ticket or operations notes.

Practical checklist

Before submitting a restart, use this checklist:

• Confirm the failed step, PROCSTEP, abend code, and return codes from spool.
• Read application messages and count displays from COBOL programs.
• Check whether DB2 updates, MQ messages, or downstream triggers already happened.
• Validate all input datasets required by the restart step still exist.
• Review GDG generations created during the failed run.
• Decide whether partial outputs must be kept, deleted, renamed, or bypassed according to the runbook.
• Confirm JCL overrides are limited to the restart need, such as space or dataset correction.
• Add clear comments or ticket notes explaining what is being restarted and why.
• After restart, compare read, written, rejected, and updated counts with expected values.
• Confirm downstream dependencies receive only the intended output.

Summary

A good JCL restart is not just a syntax change. It is a controlled recovery action. The safest support approach is to read the job log, understand completed business work, review GDG and dataset status, confirm DB2 or application checkpoint behavior, and then restart from the correct step. For batch support teams, this discipline prevents duplicate processing, protects downstream systems, and makes production recovery more reliable.

When learning JCL, practice restart syntax. When supporting production, practice restart thinking. That difference is what turns a simple rerun into a safe operational decision.

← Back to all articles