The daily edition.

Scope: Rocket Enterprise Developer/Enterprise Server 12.0 for Eclipse on Linux/UNIX; Enterprise Server JCL support.

Enterprise Server can restart a completed JCL job at a selected step and, optionally, a procedure step. The completed job must remain on the Output Hold queue. When restart is requested through ESCWA, casout, or the callable API, Enterprise Server returns it to the Input queue, reschedules it, and begins execution at the requested step/procstep. This is unavailable after a hard kill, because the job no longer retains the information required for restart. Restarting Jobs

Restart support is disabled by default. Setting:

ES_JES_RESTART=Y

adds the restart controls to jobs on Output Hold and changes cleanup behavior: the job’s MFELX*.DAT lexical files are retained after completion and removed only when the job itself is deleted. These files are therefore part of the restart state, not disposable output. Advanced restart parameters take precedence over the ordinary Step and P.Step fields when both are supplied. Enabling Job Restart Functionality

Dataset disposition requires a separate decision through MF_UCC11, which operates independently of the JCL RESTART parameter:

• Y prevents a restarted job’s DISP=(NEW,CATLG) dataset from failing merely because it is already cataloged.
• YA applies that treatment to normal execution as well as restart.
• M, MA, or MR cause cataloged datasets to be treated as initially MOD during restart, so new data is appended.
• With N, an existing dataset whose initial disposition is NEW can still cause the restarted job to fail.

Thus, choosing a restart step does not by itself define safe output-dataset behavior. Enabling Job Restart Functionality

Advanced restart can also use changed JCL while retaining condition-code and GDG information from the original job. Rocket’s documented example restarts job 1006 at STEP3 using edited JCL:

cassub /rTST -jTEST1.JCL /jrestart:1006#fSTEP3

Advanced Restart Functionality

GDGs add an important limitation. Relative references normally resolve to the same physical generation used by the original run, but that cannot happen if the generation has since been rolled off, scratched, or deleted. Intervening jobs that create newer generations can also make the required generation unavailable; the restarted step can then fail with “dataset not found.” GDG Processing during Restart

Takeaway: A restart plan must preserve the original job metadata and explicitly account for dataset disposition and GDG retention; selecting the correct step alone is insufficient.