An introduction to cross dependencies
A cross dependency is, from a logical point of view, a dependency that a local job has on a job instance that is scheduled to run on a remote engine.
Use cross dependencies to integrate the workload running on different engines, which can be IBM Workload Scheduler for z/OS engines (controller) or HCL Workload Automation engines (master domain manager and backup master domain manager).
The following objects and terms are used to describe and implement
cross dependencies:
- Remote engine workstation
- A new type of workstation that represents locally a remote HCL Workload Automation engine, either distributed or z/OS. This type of workstation uses a connection based on HTTP or HTTPS protocol to allow the local environment to communicate with the remote environment.
- Remote job
- A job scheduled to run on a remote HCL Workload Automation engine.
- Shadow job
- A job defined locally, on a remote engine workstation, which is used to map a remote job. The shadow job definition contains all the information necessary to correctly match, in the remote engine plan, the remote job instance.
- Bind
- The process to associate a shadow job with a remote job instance scheduled in the remote HCL Workload Automation engine plan.
From a logical point of view in the local environment:
- The remote engine workstation is used to map the remote HCL Workload Automation engine.
- The shadow job, defined on that remote engine workstation, is used to map a remote job instance scheduled to run on that remote HCL Workload Automation engine.
You define a cross dependency when you want that a local job (running on your local engine) depends on a remote job (running on a remote engine).
To do it, you must do as follows:
- Create a shadow job that runs on your local engine.
- Define a normal dependency that makes your local job dependent on the shadow job.
When you create the shadow, consider that
- It must be defined on a workstation of remote engine type, which points to the remote engine (that is the engine where the remote job is scheduled to run).
- You must make it point to the remote job with which you are creating the cross dependency.
Figure 1 shows the logical flow
implementing cross dependencies:
- In the bind process, the shadow job is associated to the remote job instance.
- After the bind is established, the shadow job status is updated according to the remote job status transition.
- When the shadow job status becomes SUCC the normal dependency of the local job is released, and so also the cross dependency of that local job on the remote job is also released.
Figure 1. Cross dependency
logic