Interactions with other functions

This section contains useful information if you use any of the following functions:
Automatic Recovery
If an operation has conditional successors defined, check that the related JCL does not contain automatic recovery statements that cause the job to be restarted.
Restart and cleanup
The same restrictions apply as for changing the operation status to ready by selecting option 6 (GENERAL) from the MODIFYING AN OPERATION IN THE CURRENT PLAN panel. See also MCP consistency rules.

In particular, a step or job restart request might result in a request to change to ready the status of an operation with conditional successors already started, completed, suppressed by condition, or ended in error. In this case the scheduler issues message EQQM208E. Only when rerunning an occurrence might you indirectly have this kind of change.

NOERROR or highest return code
If you use the NOERROR or highest return code capabilities, the scheduler saves the original return code when setting an operation to complete. It then uses the original return code to evaluate a condition dependency.

You can display the original return code when listing operations interactively, by using the ISPF dialog or Dynamic Workload Console, or through batch programs, by using a PIF application or BCIT.

Critical path handling
When processing a critical path, the scheduler considers that a job, with any conditional predecessor defined, breaks the critical path. Therefore avoid using critical jobs with conditional predecessors.

However, given a critical job, the scheduler updates the related hot list with any critical job predecessor ended in status X (Suppressed by condition).