Advanced Restart Functionality

Use the casout or the cassub command with the /jrestart parameter to restart a job with specifications that let you identify or change steps, procs, conditions, MF_UCC11 values, and so on.

Notes:

You can substitute a dash character (-) as an alternative to the forward slash (/).
Most parameters are case sensitive. For example, step and procstep names must be specified in upper cases.

When a job is restarted, the stored cond codes for each step within the range are updated using its corresponding the step result. For example, say you run a four-step job. The system records the result for each of the four steps. However, when you restart the job, you set the range to run only steps 2 and 3. The cond codes for steps 2 and 3 are updated, but the cond codes for steps 1 and 4 are not. Instead, they retain the results recorded the first time you ran the job.[9]

Identify the step or procstep on which to restart a job

To restart a job at a specified step, and optionally a procstep, use the following form:

casout /r<Servername>
/jrestart:<job-number>#f<step-name(instance-number)>[:
<proc-step-name>]

For example, to restart job 1051 at step 20:

casout /rTST /jrestart:1051#fSTEP20

To restart the job from the first step in the job, use $FIRST in place of the step specification. For example, to restart job number 1006 at the first step:

casout /rTST /jrestart:1006#f$FIRST

Note: On UNIX platforms, ensure you escape the $ character using a backslash (\) on the casout, cassub, and mfbsijcl command lines when specifying $FIRST available in enhanced restart mode . For example:

casout /rTST /jrestart:1006#f\$FIRST

Identify the step on which to restart in a job that contains duplicate step names

When a job contains duplicate step names, you can specify which step to start by using the #f parameter with <step-name> and optionally <proc-step-name> in the following form:

casout /r<Servername>
/jrestart:<job-number>#f<step-name(instance-number)>[:
<proc-step-name(instance-number)>]

For example, to restarts the job at the third instance of STEP2 and first instance of PSTEP within that step:

casout /rTST /jrestart:1006#fSTEP2(3):PSTEP(1)

Change the value of the MF_UCC11 environment variable on restart

Use the #m parameter to change the value of MF_UCC11 on each restart. For example:

casout /rTST /jrestart:1006#fSTEP2(3):PSTEP(1)#mY

Valid values for #m are:

Y: Switch on MF_UCC11 processing, this is the same as MF_UCC11=Y
N: Switch off MF_UCC11 processing, this is the same as MF_UCC11=N
M: Set MF_UCC11 processing to MOD, this is the same as MF_UCC11=M

See Enabling Job Restart Functionality and MF_UCC11 for more information on this environment variable.

Identify the step on which to end

Use the #t parameter to identify the step on which to end a restarted job using the following form:

casout /r<Servername>
/jrestart:<job-number>#f<step-name(instance-number)>[:
<proc-step-name(instance-number)>]#t<step-name(instance-number)>[:
<proc-step-name(instance-number)>]

For example, to restarts job 1006 at the third instance of STEP2 and the first instance of PSTEP within that step, and finishes running after the first instance of STEP4 and the second instance of PSTEP within that step:

casout /rTST /jrestart:1006#fSTEP2(3):PSTEP(1)#tSTEP4(1):PSTEP(2)

The end step is included in the run.

Restart using condition and abend codes from a previous run

Abend and Cond Code Recovery (ACR) enables you to use step COND and ABEND codes from a previous run when restarting a job by using the #k parameter.

The #k parameter has two fields - the first to indicate use of previous ABEND codes, and the second to indicate use of previous COND codes:

#k<abend-field><condition-field>

Acceptable values for both fields are:

Y: Yes, use previous codes.
N: No, do not use previous codes.
R: Reset to RC=0.
D: Default. This is the same as Y.

Default value is Y.

For example, to reset steps that abended in the previous run to RC=0, and other steps maintain the COND code from the previous run:

casout /rTST /jrestart:1006#fSTEP2(3):PSTEP(1)#tSTEP4(1):PSTEP(2)#kRY

Restart using step-specific condition codes

As a supplement to, or independent of the ACR option, you can use the #c parameter to specify individual COND codes, or to specify use of all previous COND codes. These options enable you to rerun a job and change a step COND code that is used later in a conditional evaluation. The #c parameter identifies the step name, proc name, and optionally, the instance of the step together with the value to use:

#c{<step-name(instance-number)>[:
<proc-step-name(instance-number)>] | $ALL}:value}[...]

where value is any number from 1 to 255, which is the maximum number of steps in a job.

For example, to set the COND code of the second instance of PSTEP10 in the third instance of proc STEP20 to a value of 1:

#cSTEP20(3):PSTEP10(2):1

The following example shows the #c parameter in use with the casout /jrestart and other options:

casout /rTST /jrestart:1006#fSTEP2(3):PSTEP(1)
#tSTEP4(1):PSTEP(2)#c$ALL:5#cSTEP20(1):4
#cSTEP20(3):10

All steps are set to a COND code of 5, but the first instance of STEP20 is set to a value of 4, and the third instance of STEP20 is set to a value of 10.

Note: If ACR is not set and step-specific condition codes are not set, then step condition codes from the last run are loaded. However, step COND checks are performed only against steps starting at the restart step. Steps prior to the restart step are considered not having been executed and, therefore, evaluated to FALSE. However, IF/THEN/ELSE tests use the step results from the previous run. This is equivalent to the existing Micro Focus restart processing.

Restart using a combination of condition codes

You can use a combination of COND and ABEND codes from a previous run (#k) and step-specific condition codes (#c). In this case, consider the following:

Setting ACR to any value (Y, N, R, or D) using the #k parameter, and/or setting step-specific condition codes using the #c parameter causes the step COND and IF/THEN/ELSE checks to be performed against all steps.
To provide simulation of running the job from the start but actually starting at a specified step the ACR and step-specific condition codes parameters enable detailed control of evaluation of step COND and IF/THEN/ELSE tests.
If ACR = YY, then step CCs are loaded from the last run, and COND and IF tests are performed against all steps as though a full job run had taken place.
If ACR = NN, then step CCs are not loaded, and all steps are marked as not executed. COND and IF conditions evaluated against steps that did not execute evaluate to FALSE, so steps prior to the restart step are ignored.
ACR values for Abend and Cond Code recovery can be mixed, so it is possible, for example, to reset Abends to 0 and load the existing condition codes for the steps that did not abend using #kRY.
If step COND codes are given, using the #c parameter, for example, #cSTEP(1):10, then evaluation of step COND and IF conditions take place against all steps, as when ACR is set to a value.
Setting a step CC value causes that step to be marked as executed with the result of the CC value. For example, if ACR = NN and the step CC code is set, then all steps are marked as not executed except for the steps with COND CODES set on the restart parameter. Checks are made against all steps but if a step is marked as not executed then the test is evaluated as FALSE.
Using the legacy casout /j<job number> restart functionality results in existing step COND codes to be loaded and overwritten with those from the newly restarted run. Using the Advanced Restart Functionality uses the step COND codes from the job run and does not overwrite these at the end of the newly restarted run, so that step COND codes are always those from the original job run. Micro Focus recommends that you do not mix legacy and new job restart calls against the same job.

Restart using Micro Focus Batch Scheduler Integration (MFBSI)

You can restart JCL jobs with the Micro Focus Batch Scheduler mfbsijcl command using either the original or modified JCL.

Original JCL

The following example shows the restart of a job using the mfbsijcl command and the original JCL, with some sample standard options for /jrestart:

mfbsijcl /jrestart:1234567#fSTEP2:PSTEP(1)

Modified JCL

To restart a job with modified JCL using the mfbsijcl command, use the following syntax:

mfbsijcl {/j<modified-JCL-file> | <basejcl>} /jrestart:<standard-parms>

where:

modified-JCL-file: The full or relative path to and filename of the modified JCL file.
basejcl: The JCL base that is resolved using JCL-Submit and JCL-Exit found in the mfbsi.cfg file.
standard-parms: Any valid parameters for the /jrestart option as documented elsewhere in this topic.

For example:

mfbsijcl  /jC:\Temp\modified.jcl /jrestart:1234567#fSTEP2:PSTEP(1)
mfbsijcl  /j/tmp/modified.jcl /jrestart:1234567#fSTEP2:PSTEP(1)
mfbsijcl basejcl /jrestart:1234567#fSTEP2:PSTEP(1)

When restarting a job using modified JCL:

A new job number is assigned to the job.
The JESYSMSG and associated MFELX*.dat file of the initial JOB number (specified in /jrestart:nnnnnnn) must be available.

Notes: When using the mfbsijcl command:

Most errors related to Advanced Restart are returned with the OS Rc 220 code.
If you need to re-execute the mfbsijcl substitution phase (standard or Control-M), use the modified JCL syntax even no change has been made to the JCL itself.

Restart with changed JCL code

You can edit the JCL code for a job and then resubmit it using both the /j and /jrestart parameters with the cassub command.

When you resubmit the edited job, you must specify the original job number on which you have based your edits. The COND codes and GDG information from the original job are used when running the changed job. For example, to submit TEST1.JCL as a restart of job 1006 with execution starting at STEP3:

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

Auto-adjust restart

The restart step is adjusted automatically to account for datasets that would have been created in an earlier bypassed step, but that are required in a later step. The #a parameter determines whether or not to use auto-adjust. The default value, Y, turns on auto-adjust and N turns off auto-adjust. For example, to look for datasets used at or after STEP2(3):PSTEP(1) to determine where they are defined, and adjusts the restart step and procstep accordingly:

casout /rTST /jrestart:1006#fSTEP2(3):PSTEP(1)#aY

Because #aY is the default, omission of the #a parameter yields the same behavior. When #aN is used, no auto-adjustment is performed.

Note: Syntax for both casout and cassub can be specified using either a forward slash (/) or a hyphen to indicate the start of a parameter. For example:

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

is equivalent to:

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