TWA 8.6 Feature:
"Support for cross dependencies among jobs running on different scheduling engines"
See the link in which you can find a detailed whitepaper on this feature!
This feature enables Scheduling team to integrate workload running on different engines, which can be a mix of Tivoli Workload Scheduler for z/OS engines (Controller) and Tivoli Workload Scheduler engines (Master Domain Manager and Backup Master Domain Manager).
Scheduling business comprises multiple activities; some of which runs at different sites or involve different organizational units; others require different skills to be run. For these reasons users must keep your scheduling environments separate.
Nevertheless, even if most of the batch workload is managed locally, none of these environments is completely isolated from the others, because they frequently need to interoperate to exchange or to synchronize on data and activities.
Scheduling users need is to have the capability to federate your different heterogeneous scheduling environments in an easy way so that users could:
- Define in one scheduling environment dependencies on batch activities that are managed by another scheduling environment,
- Control the status of these dependencies by navigating from a unique user interface across the different scheduling environments
A cross dependency is, from a logical point of view, a dependency of a local job on a job instance that is scheduled to run on a remote engine plan. To implement a cross dependency, you need to define the following objects:
Remote engine workstation
A new type of workstation that represents locally a remote Tivoli Workload Scheduler 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.
A job scheduled to run on a remote Tivoli Workload Scheduler engine.
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.
Detailed documentation can be found at: