Condition dependencies (z/OS)

In HCL Workload Automation for z/OS, you can specify that jobs are dependent on other jobs. For example, if job A1 must complete before job A2 can start, then A1 is a predecessor of A2, and A2 is a successor of A1. These relationships between jobs are called dependencies.

When specifying dependencies, you can also define work flows with alternative branches based on conditions, specifically to achieve the same results as using IF/THEN/ELSE statements in the job JCL. You can use both job return code and job status as conditional logic elements to determine the start of a successor job. The following example shows how this works.

A condition dependency relationship is set up by using a condition.

You can define condition dependencies at the following levels:

Job level: By conditioning the start of the successor to the check on job return code or status of the predecessor.
Step level: By conditioning the start of the successor to a specific step return code of the predecessor.

How condition dependencies work

A condition dependency is a specific check of the status or return code of a predecessor job or of the return code of a job step.

The job processing flow is affected by the conditions set and their final status.

The status of a condition is set based on the rule defined and on the statuses of its condition dependencies.

The condition dependency is evaluated only when a path in the plan exists, otherwise the condition dependency remains Undefined until a manual intervention or a rerun is done.

A possible path for the conditional predecessor exists when at least one of the following conditions occurs:

The job has status Completed and a normal successor exists.
There is at least one conditional successor that has all the subsets of conditions, referencing that conditional predecessor, set to true, according to the condition rules.

For example:

A conditional predecessor (Job A) has several conditional successors (Jobs B, C, D)
Each conditional successor has a set of condition dependencies, relating to job A, that must be satisfied to make it possible for the successor to start.
Job A runs and changes its status.
If at least one subset of conditions between job A and one of its successors is true, the path in plan exists and all the successors' condition dependencies related to job A are evaluated. Otherwise all condition dependencies are left undefined.

When specifying predecessors in the database, you can define a list of conditions by combining single condition dependencies on predecessor job status or return code. You cannot define a job both as a conditional and as a normal predecessor of another job. For each condition you can specify one of the following rules:

At least n number of conditions out of all the condition dependencies must be satisfied. This rule corresponds to the OR operator in Boolean logic.
All the condition dependencies in the list must be satisfied. This rule corresponds to the AND operator in Boolean logic.

At run time, the scheduler evaluates the condition status resulting from the condition dependencies statuses, based on the selected rule. The condition status can be:

True

When ALL condition dependencies are true.

If the rule is set to AND: When ALL condition dependencies are true.
If the rule is set to OR (at least n condition dependencies must be true): When at least n condition dependencies are true.

False

The condition was not satisfied.

If the rule is set to AND: When at least one condition dependency is false.
If the rule is set to OR (at least n condition dependencies must be true): When at least n condition dependencies cannot be true.

Undefined

When the rule cannot be evaluated yet.

A set of conditions results as satisfied if all the conditions are satisfied, according to the logic of the AND operator.

When a predecessor ends, the successor job status changes to one of the following statuses:

Waiting: Undefined, until the scheduler evaluates all the defined conditions. At least one normal predecessor is not in Completed or Suppressed by Condition status or at least one condition is U (Undefined). The scheduler processes all subsequent statuses as usual, up to a final status.
Ready: Ready, when all the defined conditions are satisfied. Job normal predecessors are in Completed or Suppressed by Condition status and all its conditions are True. The scheduler processes all subsequent statuses as usual, up to a final status.
Suppressed by Condition: Suppressed by condition, when the defined condition dependency is not satisfied. At least one condition is False.
Note: When evaluating conditional successors status, predecessor jobs in status Suppressed by Condition are considered equal to predecessor operations in status Completed.

Examples of condition dependencies

Use a job-level condition dependency when you want a successor job to start depending on a combination of one or more return codes or statuses of predecessor jobs.

Figure 1 shows the two different types of job level conditions, one based on the predecessor return code and the other based on the predecessor job status. For example, using the return code as condition type, you can define that job OP2 is dependent on job OP1, specifying that OP2 must run when OP1 ends with a return code in the range from 1 to 3. Similarly, using job status as condition, you can define job OP4 as dependent on job OP3, specifying that OP4 must run if OP3 ends with status Error.

Figure 1. Example of a condition dependency definition

In this example, OP1 is a conditional predecessor of OP2 and OP3 is a conditional predecessor of OP4.

In the previous example, if OP1 ends with return code of 8, the scheduler sets OP2 to status Suppressed by Condition, because the condition is not satisfied.

Figure 2. Example of a condition dependency at run time

For further information about conditional logic, see IBM Workload Scheduler for z/OS Managing the Workload.

Step level dependency

If you configured HCL Workload Automation for z/OS to track step-end events, then the step dependencies are checked at step-end time when the return code value is available.

This section contains an example showing how job processing flow is affected when using step-level conditions.

If the predecessor job is associated to a job comprising several steps, you can specify a dependency on step return codes. Figure 3 shows an example of conditional dependency logic at job step level, to obtain auto-recovery applications with recovery jobs that can start without waiting for the end of predecessor jobs, depending on the result of specific steps.

Figure 3. Auto-recovery job stream with step level dependency

In this example:

JOBB can start if STEP100, belonging to JOBA, ends with RC=4.
JOBC is a normal successor of JOBA and therefore starts if JOBA status is Completed.

Handling recovery using condition dependencies

Using condition 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 specifying the conditional recovery job option, you can define that the job 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 Ended-in-error can be ignored at occurrence removal phase, the daily plan process uses a field automatically set by the scheduler, corresponding to Recovered by condition.

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 condition. The daily plan process removes the occurrence in the following cases:

The occurrence status is Completed.
The occurrence status is Ended-in-error , and includes only jobs in one of the following statuses:
- Completed
- Suppressed by condition
- Ended-in-error with the Recovered by condition option specified.

For example, suppose that either JOBR1 or JOBR2 must run when JOBB ends with an error. You can specify JOBB as their conditional predecessor, as shown in Figure 4.

Figure 4. Example of recovery job with condition dependencies

When defining JOBR1 and JOBR2 and specifying JOBB as conditional predecessor, you can also set the Conditional recovery job option to have the daily plan process remove the occurrence containing JOBB, because it ended with an error code matching one of the defined condition dependencies.