Making an operation dependent on another operation step return code

In HCL Workload Automation for Z, jobs can comprise several steps whose return codes might condition the start of successor jobs.

In some instances the business logic might mean that a successor to a long running job could, in theory, actually start on the completion of a step part way through the long running job, instead of waiting for the entire predecessor job to complete. Traditional dependencies force you to wait for the entire job to complete, thereby incurring extra time that could be saved if the successor could start in parallel part way through the long running job.

With job-level condition dependencies, it is possible to split the long running JCL into smaller jobs, thereby allowing more parallel processing, and a more granular visibility of the workflow. In some cases though, it is not possible to split a large job into smaller components.

If the long running job cannot be split, a successor job can be made dependent on a step within a long running job using step-level condition dependencies. This means that the successor is allowed to start, if the named step completes with stated return codes, before the entire long running job completes, shortening overall processing time.

Step-level condition dependencies apply only to operation step-end return codes and, if a possible path for progression exists in the plan, are evaluated as soon as that step-end return code is generated.

As for job-level condition dependencies, step-level conditional dependencies can be added in the plan at run time and monitored from the ISPF panels and from the Dynamic Workload Console.