Although the RERUNMEM parameter can be used to specify the name of a JCL member to use for automatic rerun, note the following points:
The DO FORCEJOB parameter provides a more flexible alternative to the RERUNMEM parameter.
Control-M/Restart users can use the DO IFRERUN parameter to restart the failed job instead of using RERUNMEM to rerun the job.
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, or no MAXRERUN value was specified, 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 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 specified in the MEMNAME parameter.
Rules applying to the MEMNAME parameter also apply to the RERUN parameter.
The member name can be the same as, or different from, the job name.
The member specified in RERUNMEM must be in the library specified in the MEMLIB parameter.
The RERUNMEM parameter overrides the MEMNAME value in the JCL, and the MEMNAME value becomes irrelevant for reruns.
The RERUNMEM parameter cannot be specified for cyclic jobs and cyclic started tasks.
The RERUNMEM parameter cannot be specified if a DO IFRERUN statement is specified.
