Cross dependencies
Using cross dependencies and shadow jobs.
A cross dependency is a dependency of a local job on a remote job running in a different scheduling environment. It is achieved by using a shadow job, which runs in the same environment as the local job and maps the remote job processing.
Cross dependencies help you integrate workload running on more than one engine. They can be both HCL Workload Automation for z/OS engines (controller) and HCL Workload Automation engines (master domain manager).
The following objects allow you to define and manage cross dependencies:
- Remote engine
- A workstation that represents locally a remote HCL Workload Automation engine. It is a workstation used to run only shadow jobs. A shadow job is a job that runs locally and is used to map another job running on a remote engine. This relationship between the two jobs is called a cross dependency. You define a remote engine workstation if you want to federate your environment with another HCL Workload Automation environment, either distributed or z/OS, to add and monitor dependencies on jobs running in the other scheduling environment. This type of workstation uses a connection based on HTTP protocol to allow the two environments to communicate.
- Shadow job
- A job running locally that is used to map a job running on the remote engine. This job is called a remote job. Shadow jobs can run only on remote engine workstations. The shadow job definition contains all the information needed to correctly match the remote job in the plan of the remote engine. The status transition of the shadow job reflects the status transition of the remote job.
- Remote job
- A job that runs on a remote scheduling environment and is mapped by a shadow job to become a dependency for a job that runs in a local environment.
- Points to the remote job on which you want to create the cross dependency
- Is defined on a local workstation of remote engine type, that points to the engine where the remote job is defined.
To do this, you must
- Create a remote engine workstation where the shadow job runs.
- Create a shadow job pointing to a specific job instance defined
on a remote engine.
Shadow jobs can be added to the plan by the plan creation process or dynamically at run time. The shadow job scheduled time identifies the remote job instance in the remote engine plan.
The bind process is the process to associate a shadow job with a job instance in the remote engine plan.
As soon as the bind is established, the remote engine sends back an HTTP notification containing the status of the bind and, if the bind was successful, the information to identify the remote job instance bound. This information is saved in the shadow job instance details.
- Add the shadow job as a dependency of the local job.
The resolution of the cross dependency depends on the status of the shadow job, which reflects at any time the status of the remote job. Because the remote job status transition is mapped into the shadow job status transition, the status of the cross dependency is represented by the status of the normal dependency.
The key attributes to identify the remote job instance and the matching criteria depend on the type of remote engine where the remote job instance is defined. z/OS engines support only closest preceding matching criteria. Distributed shadow jobs, instead, support the four matching criteria available for external dependencies. See Dependencies for more details.
The scheduled time of the job stream containing the shadow job is used to find the match.
To avoid incongruence, at plan creation or extension time, consistency checks are performed to ensure that no mismatch has occurred in between the definition of jobs and workstations in the database and their inclusion in the current plan.
For more information about cross dependencies, see the sections about defining and managing cross dependencies in HCL Workload Automation User's Guide and Reference and in HCL Workload Automation for Z: Managing the Workload.