When a job is first run, the MAXRERUN field in the Active environment, that is, in the Zoom screen, contains the same value as the MAXRERUN parameter in the job scheduling definition. However, in the Active environment MAXRERUN works as a "reverse-counter" of automatic reruns. Each time the job is automatically rerun, the value is decreased by one until the field contains a value of zero.
The automatic rerun process works as follows:
The Control-M monitor determines that automatic rerun is possible only if the job ENDS NOTOK and a specified DO RERUN statement is activated during post-processing. If the monitor determines that automatic rerun is possible, it sets the status of the job to ENDED NOTOK – RERUN NEEDED.
The monitor then checks the value of MAXRERUN in the Active environment. If the value is zero, automatic rerun is not possible and the job is not submitted for rerun. If the value is greater than zero, rerun is possible and the monitor submits the job for rerun when all runtime criteria are satisfied. Runtime criteria include not only criteria in the Runtime Scheduling parameters, but also the INTERVAL parameter, which specifies the minimum allowable interval between runs of the same job.
The JCL for the rerun job is taken from the member specified in the RERUNMEM parameter. If no RERUNMEM value is specified, the JCL for the rerun is taken from the regular JCL member of the job that is specified in the MEMNAME parameter.
MAXRERUN applies only to automatic reruns. The MAXRERUN counter is not affected by reruns performed manually using the Rerun option in the Active Environment screen.
If a job is defined as cyclic by setting the TASKTYPE parameter to CYC, the MAXRERUN parameter can be used to specify the number of iterations. This number includes the initial run of the job.
