Defining dependencies

A dependency is a prerequisite that must be satisfied before processing can proceed. You can define dependencies for both jobs and job streams to ensure the correct order of processing. Within your Tivoli® Workload Scheduler distributed scheduling environment you can choose from four different types of dependencies:

• On completion of jobs and job streams: a job or a job stream, named successor, must not begin processing until other jobs and job streams, named predecessor, have completed successfully. For more information, see follows.
• Resource: a job or a job stream needs one or more resources available before it can begin to run. For more information, refer to needs.
• File: a job or a job stream needs to have access to one or more files before it can begin to run. For more information, refer to opens.
• Prompt: a job or a job stream needs to wait for an affirmative response to a prompt before it can begin processing. For more information, refer to Prompt definition and prompt.

You can define up to 40 dependencies for a job or job stream.

In a Tivoli Workload Scheduler network, dependencies can cross workstation boundaries. For example, you can make job1, which runs on your Tivoli Workload Scheduler local environment site1, dependent on the successful completion of job2, which runs on a remote Tivoli Workload Scheduler environment site2. The remote scheduling environment can be either Tivoli Workload Scheduler for z/OS engines (controller) or another Tivoli Workload Scheduler engines (master domain manager). Two types of dependencies implement such requirement:

Internetwork dependency

It is a simple and distributed based implementation. Use this type of dependency when:

• The local Tivoli Workload Scheduler environment is distributed.
• You want to search for a remote predecessor job instance only in the plan currently running (production plan) on the remote environment.
• You need to match a predecessor instance in the remote plan, not that specific predecessor instance.
• You can wait for the polling interval to expire before being updated about the remote job status transition.
• You do not mind using different syntaxes and configurations based on whether the remote Tivoli Workload Scheduler environment is distributed rather than z/OS.
• You do not mind using a proprietary connection protocol for communicating with the remote engine.

For more information, see Managing internetwork dependencies.

Cross dependency

It is a more comprehensive and complete implementation. Use this type of dependency when:

• Your local Tivoli Workload Scheduler environment can be either distributed or z/OS.
• You want to search for the remote predecessor instance also among the scheduled instances that are not yet included in the plan currently running on the remote engine.
• You want to match a precise remote predecessor instance in the remote engine plan. To do this you can use different out-of-the-box matching criteria.
• You want your dependency to be updated as soon as the remote job instance changes status. To do this the product uses an asynchronous notifications from the remote engine to the local engine.
• You want to use the same syntax and configuration regardless of whether the local Tivoli Workload Scheduler environment is distributed or z/OS.
• You want to use HTTP or HTTPS connections for communicating with the remote engine.

For more information, see Defining and managing cross dependencies.