follows
Defines the other jobs and job streams that must complete successfully before a job or job stream is launched.
Comments
Use the following syntax for job streams:
[follows {[netagent::][workstation#]jobstreamname
[previous|sameday|relative from [+/-] time to [+/-] time|from time [+/-n day[s]] to time [+/-n day[s]]
Use the following syntax for jobs:
[follows {[netagent::][workstation#]jobstreamname{.jobname}
[previous|sameday|relative from [+/-] time to [+/-] time | from time [+/-n day[s]] to time [+/-n day[s]] [if <condition> [| <condition>...]]
Arguments
- netagent
- The name of the network agent where the internetwork dependency is defined.
- [folder/]workstation
- The workstation on which the job or job stream that must have completed runs. The default is the
same workstation as the dependent job or job stream.
If a workstation is not specified with netagent, the default is the workstation to which the network agent is connected.
Network agent workstations do not support folders, therefore neither the network agent nor the jobs or job streams running on them can be defined in folders. Folders are supported on all other workstation types, as follows:[follows {[folder/][workstation#] [folder/]jobstreamname[.jobname]
- [folder/]jobstreamname
- The name of the job stream that must have completed. For a job, the default is the same job stream as the dependent job.
- time
- Specifies a time of day. Possible values range from 0000 to 2359.
- [folder/]jobname
- The name of the job that must have completed. An
at
sign (@) can be used to indicate that all jobs in the job stream must complete successfully. - previous|sameday|relative from [+/-] time to [+/-] time | from time [+/-n day[s]] to time [+/-n day[s]]
- Defines how the job stream or job referenced by an external follows dependency is matched to a specific job stream or job instance in the plan. See Comments for a detailed explanation of these options.
- [if <condition> [| <condition>...]]
- Conditional dependencies are used
when you need a successor job or job stream to start only after certain conditions are satisfied by
the predecessor job or job stream. They can also be used to specify alternative flows in a job
stream starting from a predecessor job or job stream. The successor job is determined by which
conditions the predecessor job or job stream satisfies. The jobs in the flow that do not run,
because the output conditions were not satisfied, are put in SUPPR state which is different from
regular dependencies where jobs are put in Hold until the predecessor is in SUCC state.
The conditions expressed by [if <condition> [| <condition>...]] can be of different types: based on the job execution status of the predecessor job or job stream, the job status, and other conditions based on the output or outcome of the predecessor job or job stream. You can specify more than one condition, separated by the pipe (|) symbol but, you cannot specify a combination of types, one type only. For example,
IF ABEND | FAIL | SUPPR
.When the predecessor is a job stream, the conditional dependency is only a status condition, as follows:
abend
,succ
, andsuppr
. The successor job runs when the predecessor job stream status satisfies the job status specified using these arguments. You can specify one status, a combination of statuses, or all statuses. When specifying more than one status or condition name, separate the statuses or names by using the pipe (|) symbol.- if Condition_Name
- Where, Condition_Name can represent both a status or an actual name that you
assign to a condition that you define.
- if exec
- The successor job runs when the predecessor job has started.
- if fail|abend|succ|suppr
- The successor job runs when the predecessor job status satisfies the job status specified using these arguments. You can specify one status, a combination of statuses, or all statuses. When specifying more than one status, separate the statuses by using the pipe (|) symbol.
- if Condition_Name]
- The successor job runs when the predecessor job satisfies the output conditions defined for the Condition_Name specified. You can specify one condition name, or a combination of names. When specifying more than one condition name, separate the names by using the pipe (|) symbol. These output conditions are initially defined in the job definition.
Comments
- previous
- Closest Preceding: The job or job stream instance that resolves the dependency is the closest preceding the instance that includes the dependency.
- sameday
- Same Day: The job or job stream instance that resolves the dependency is the closest one in time scheduled to start on the day when the instance that includes the dependency is scheduled to run.
- relative from [+/-] time to [+/-] time
- Within a Relative Interval: The job or job stream instance that resolves the dependency is the closest one in a time interval of your choice, which is defined relatively to the scheduled start time of the dependent instance.
- from time [+/-n day[s]] to time [+/-n day[s]
- Within an Absolute Interval: The job or job stream instance that resolves the dependency is the closest one in a time interval of your choice. The time interval is not related to the scheduled start time of the dependent instance.
- IBM Workload Scheduler searches for the closest instance that precedes the depending job or job stream start time. If such an instance exists, this is the predecessor instance.
- If there is no preceding instance, IBM Workload Scheduler considers the correct predecessor instance as the closest instance that starts after the depending job or job stream start time.
The scheduler classifies follows dependencies as internal when they are specified only by their job name within the job stream. It classifies them as external when they are specified in the workstation#/folder/jobstreamName.jobName format.
When a job stream includes a job with a follows dependency that shares the same job stream name
(for example, job stream schedA
includes a job named job6
that
has a follows dependency on schedA.job2
), the dependency is added to the plan
as an external follows dependency. Because the scheduler uses the
sameday
matching criteria to resolve external dependencies, dependencies
originated in this way are never added the first time the object is submitted.
For more information and examples on how external follows dependencies are resolved in the plan refer to Managing external follows dependencies for jobs and job streams.
Examples
skedc
until the closest
preceding job stream instance sked4
on workstation site1
has
completed successfully: schedule skedc on fr follows site1#sked4 previous
skedc
until the job
stream instance of sked4
, contained in the payroll
folder, on
workstation site1
that run between 12:00 of 3 days before to 3:00 of the day after
have completed successfully:
schedule skedc on fr follows site1#PAYROLL/sked4 from 1200 –3 days to 0300 1 day
skedc
until
job stream sked4
on workstation site1
and
job joba
in job stream sked5
on
workstation site2
have completed successfully: schedule skedc on fr
follows site1#sked4,site2#sked5.joba
sked6
until jobx
in
the job stream skedx
on network agent cluster4
has
completed successfully: sked6 follows cluster4::site4#skedx.jobx
jobd
until joba
in
the same job stream, and job3
in job stream skeda
have
completed successfully: jobd follows joba,skeda.job3
LOADDATA_INFO
after the job CHECKJOB
in
the CHECKDATA
job stream, only if job CHECKJOB
completes
in FAIL or ABEND state, and if job CHECKJOB1
in
the CHECKDATA1
job stream satisfies the condition STATUS_OK
defined
in the CHECKJOB1
job definition:WK1#LOADDATA_INFO
FOLLOWS WK2#CHECKDATA.CHECKJOB IF FAIL|ABEND
FOLLOWS W32#CHECKDATA1.CHECKJOB1 IF STATUS_OK