Handling recovery using conditional dependencies

Using conditional dependencies, the error status of a job can be used as a criteria for starting a successor, when this successor is used as a recovery job.

By setting to Y the COND RECOVERY JOB option for an operation, you define that the operation is used as the recovery job for a conditional predecessor.

Any conditional predecessor that Ended-in-Error, with a status or error code matching a condition dependency defined for the job, does not prevent the daily plan process from removing the occurrence to which the predecessor belongs. To check if the status E (Ended-in-error) can be ignored at occurrence removal phase, the daily plan process uses a field automatically set by the scheduler, corresponding to the Recovered by COND output field in the browsing operation flow.

Note: As soon as a recovery job becomes ready, the scheduler checks the predecessors in error status at that time. Any predecessor that ends in error after the recovery job runs cannot be flagged as Recovered by COND.
The daily plan process removes the occurrence in the following cases:
  • The occurrence status is C (Completed).
  • The occurrence status is E (Ended-in-error), and includes only operations in one of the following statuses:
    • C
    • X (Suppressed by condition)
    • E, with the Recovered by COND field set to Y.
For example, suppose that either JOBR1 or JOBR2 must run when JOBB ends with an error. You can specify JOBB as their conditional predecessor, according to Basic example of condition dependencies for recovery jobs:
Figure 1. Basic example of condition dependencies for recovery jobs

Example of condition dependencies network

When defining JOBR1 and JOBR2 and specifying JOBB as conditional predecessor, you can also set the COND RECOVERY JOB option to Y in the AUTOMATIC OPTIONS of JOBR1 and JOBR2, so that the daily plan process removes the occurrence containing JOBB, because it ended with an error code matching one of the defined condition dependencies.