Defining dependencies

When you define job streams and manage your plan, you can enforce a precise processing order across your environment by configuring dependencies.

A dependency functions as a prerequisite condition that the scheduling environment must completely satisfy before a specific job or job stream can proceed with processing.

To build a reliable and automated workflow, you can classify these prerequisites into distinct local, cross-boundary, and cross-platform architectural scopes—including internal, external, internetwork, and cross dependencies.

Depending on your specific automation requirements, the system evaluates and triggers these connections based on diverse dependency types, such as:

Standard completion dependencies
Resource dependencies
File dependencies
Prompt dependencies

IBM Workload Scheduler then resolves these relationships at run time by identifying the correct predecessor instance in the plan using exact resolution criteria, such as closest preceding times, matching scheduled calendar dates, or defined absolute and relative time intervals. The sections below describe each of these dimensions in deeper technical detail to help you map, configure, and manage your workload path.

Dependency types

Within your IBM Workload Scheduler distributed scheduling environment you can choose from the following different types of dependencies:

Follows 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.
  For more information, see follows.
- On satisfaction of specific conditions by 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 met one, all, or a subset of specific conditions that can be related to the status of the job or job stream, the return code, output variables, or job log content. When the conditions are not met by the predecessor, then any successor jobs with a conditional dependency associated to them are put in suppress state. Successor jobs with a standard dependency are evaluated as usual.
  For more information, see Applying conditional branching logic, follows, and join.
You can define up to 40 dependencies for a job or job stream. If you need to define more than 40 dependencies, you can group them in a join dependency.
Join dependencies: You can join or aggregate conditional dependencies related to different predecessors into a single join dependency. A join contains multiple dependencies, but you decide how many of those dependencies must be satisfied for the join to be considered satisfied. You can define an unlimited number of conditional dependencies, standard dependencies, or both in a join.
Note: This dependency type is not supported on Limited Fault-Tolerant Agent IBM i.
For more information about join dependencies, see Joining or combining conditional dependencies and join.
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.
Internetwork dependencies: Dependencies on jobs or job streams that run in an entirely separate IBM® Workload Scheduler network. Use this type of dependency when:
- The local IBM 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 IBM 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.

Scope of dependencies

You can classify dependencies in a distributed or z/OS environment into different categories.

When the predecessor and successor run within the same local environment, you can choose between two categories:

Internal dependencies: Dependencies that you establish between jobs that belong to the same job stream.
External dependencies: Dependencies that you establish between different job streams, between job streams and individual jobs in other job streams, or between jobs in separate job streams.

In an IBM Workload Scheduler network, dependencies can cross workstation boundaries. For example, you can make job1, which runs on your IBM Workload Scheduler local environment site1, dependent on the successful completion of job2, which runs on a remote IBM Workload Scheduler environment site2. The remote scheduling environment can be either IBM Workload Scheduler engines (controller) or another IBM Workload Scheduler engines (master domain manager). You can implement such requirement in two ways:

Using Internetwork dependencies.
Creating cross dependencies: Dependencies that you use to integrate your workload across different engines, such as between distributed engines and z/OS controllers. Use this type of dependency when:
- Your local IBM 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 IBM 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.

Resolution criteria

IBM Workload Scheduler uses these specific evaluation criteria to identify the correct predecessor instance in the plan:

Closest preceding: IBM Workload Scheduler targets the closest instance in time that precedes the scheduled start time of the successor. If no preceding instance exists, the system targets the closest instance that starts after the successor.
Same scheduled date: IBM Workload Scheduler targets the predecessor instance planned to run on the exact same calendar day.
Within a relative interval: IBM Workload Scheduler searches for the closest preceding instance within a relative time window that you specify. If the plan does not contain a preceding instance, the system evaluates the closest following instance within that same relative window.
Within an absolute interval: IBM Workload Scheduler evaluates instances within a fixed, absolute time window using the same preceding-to-following fallback logic.