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, and suppr. 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

Dependency resolution criteria define 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. Because the plan allows the inclusion of multiple instances of the same job or job stream, you can identify the instance that resolves the external follows dependency based on the following resolution criteria:
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.
Regardless of which matching criteria are used, if multiple instances of potential predecessor job streams exist in the specified time interval, the rule used by the product to identify the correct predecessor instance is the following:
  1. HCL Workload Automation 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.
  2. If there is no preceding instance, HCL Workload Automation 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. Since Version 8.3, unlike in previous versions, 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

The following example specifies to not launch job stream skedc until the closest preceding job stream instance sked4 on workstation site1 has completed successfully: 
schedule skedc  on fr  follows site1#sked4 previous
The following example specifies to not launch job stream 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
The following example specifies not to launch job stream 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
Do not launch sked6 until jobx in the job stream skedx on network agent cluster4 has completed successfully: 
sked6 follows cluster4::site4#skedx.jobx
The following example specifies not to launch jobd until joba in the same job stream, and job3 in job stream skeda have completed successfully: 
jobd follows joba,skeda.job3
The following example specifies to launch the job 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