Evaluating and processing a conditional dependency flow
After you submit your jobs or job streams, HCL Workload Automation adds
them to the production plan and evaluates them.
Conditional dependencies increase the flexibility of your workload
by choosing which job to run as a result of the job status or of the
output of a previous job.
Conditional dependencies are
evaluated after any standard dependencies in the job or job stream are satisfied.
If you rerun a job or
job stream, the evaluation of the conditional dependency flow is cleared
and all dependencies are evaluated again.
If a predecessor job or job stream is
cancelled, and the predecessor is in a final state, then the output
condition or status condition is evaluated and may or may not be satisfied,
or may not be assessable. If the predecessor is not in a final state
and has not evaluated any conditions, then the successor remains in
HOLD and the job or job stream remains in STUCK.
Follows dependency
A follows dependency is satisfied when the job on which the dependency is defined completes
successfully. In this example, the DB_BACKUP job can start only after the ABSENCES job completes
successfully. If the ABSENCES job does not complete successfully, the DB_BACKUP job remains in HOLD
status.
Conditional dependencies on job status
You can use conditional dependencies to make your workload more flexible and automate some
recurring tasks. For example, you can decide that a certain job must run when a predecessor
completes successfully and a different job must run when the predecessor fails.In this example, if the ABSENCES job completes successfully, the DB_BACKUP job runs and the
OPERATOR_INTERVENTION job is suppressed. On the contrary, if the ABSENCES job ends in ABEND status,
the OPERATOR_INTERVENTION job runs and the DB_BACKUP job is suppressed.
If you have a standard follows dependency on the DB_BACKUP
job, for example, and the job is suppressed, the follows dependency is released and the successor
job can run. If you want to propagate the SUPPR status from
the DB_BACKUP job, for example, to a successor job, you define a conditional dependency on the SUPPR
status on the DB_BACKUP job. This dependency causes the successor of the DB_BACKUP job to go into
SUPPR status when the DB_BACKUP job ends in SUPPR status
If
all the conditional dependencies defined in the job stream are satisfied,
the job or job stream goes into READY status. If
a conditional dependency is not satisfied, the related successor job
or job stream goes into SUPPR status.
Conditional dependencies on job output conditions
You can also condition the behavior of your workload based on the job return code and automate a
set of responses based on the problems encountered by the predecessor job. There are a number of
reasons why the ABSENCES job might fail and some of them can be easily anticipated and solved. The
job might fail because the database is down, because WebSphere Application Server Liberty Base is down, and so on, or an unexpected
problem might arise, which requires the intervention of an operator.When defining the ABSENCES job, you associate a specific return code to the problems that
might arise, so that a specific job is started to try and solve the problem. For example, a return
code of 1 indicates that the database cannot be reached and causes the DB_RESTART job to start,
which starts the database; a return code of 2 indicates that WebSphere Application Server Liberty Base cannot be reached and causes the
WAS_RESTART job to start, which starts the WebSphere Application Server Liberty Base, and so on. Any return code greater
than 3 indicates that an unexpected error has occurred and starts the OPERATOR_INTERVENTION job,
which alerts the operator.
If the ABSENCES job fails
with one of the return codes defined in the output conditions, the
corresponding job is started, while the remaining jobs are suppressed.
When
no output conditions are satisfied, the job or job stream remains
in HOLD status.
Join conditional dependencies
You can also
combine a set of dependencies into a join dependency and specify how
many of them must be met for the join dependency to be satisfied.
For
example, consider this portion of the PAYROLL job stream: In this case, the PROBLEM_SOLVING
join dependency contains three dependencies on SUCC status on three
different jobs. This means that when at least one of the RESTART_DB,
RESTART_WAS or TEMP_CLEANUP jobs completes successfully, the join
dependency is satisfied and the ABSENCES_RETRY job can start.
If
none of the predecessor jobs completed successfully, the PROBLEM_SOLVING
join dependency is not satisfied and the ABSENCES_RETRY job is suppressed.
If
the number of conditional dependencies defined in the join dependency
is satisfied, the job or job stream goes into READY status. If
the specified number of conditional dependencies in a join dependency
is not satisfied, the job or job stream goes into SUPPR status.
Evaluating conditional dependencies in job streams
The
evaluation of conditional dependencies in job streams depends on several
factors, as described in the following examples.
When
a job within the job stream is in SUPPR status, its status is evaluated
as CANCELLED. If all jobs within the job stream are in SUPPR status,
the job stream goes into SUCC status. This is the same behavior that
causes a job stream containing only CANCELLED jobs to go into SUCC
status.
When you change
a job stream status to SUPPR, all the jobs in the job stream that
have not reached a final status are changed into SUPPR status. This
applies, for example, to jobs that are in READY or HOLD status.
NON-SATISFIED
STATUS CONDITION AND RECOVERY STOP SETTING CAUSING THE JOB STREAM
TO COMPLETE IN ABEND STATUS
The PERFORMANCE job has a conditional
dependency on the SALES job completing in SUCC status. However, the
SALES job completes in ABEND status. The conditional dependency on
the SALES job is evaluated as unsatisfied and the PERFORMANCE job
is suppressed. The job stream completes in ABEND status because the
abended SALES job is set to recovery stop, and the suppressed
status of the PERFORMANCE job is considered as a CANCELLED status.
NON-SATISFIED
STATUS DEPENDENCY CAUSING THE JOB STREAM TO COMPLETE IN SUCC STATUS
The
OPERATOR_CALL job has a conditional dependency on the DB2_BACKUP job
completing in ABEND status. However, the DB2_BACKUP job completes
in SUCC status. The conditional dependency on the DB2_BACKUP job is
evaluated as not being satisfied and the OPERATOR_CALL job is suppressed.
The job stream status is evaluated in SUCC status because the suppressed
status of the OPERATOR_CALL job is considered as a cancelled status.
UNSATISFIED STATUS DEPENDENCY CAUSING THE
JOB STREAM TO COMPLETE IN STUCK STATUS
The PERFORMANCE job
has a conditional dependency on the SALES job completing with the
STATUS_OK output condition. However, the SALES job ends in ABEND status
and no output condition is satisfied. As a result, the conditional
dependency on the SALES job is not evaluated and the job stream completes
in STUCK status.
SATISFIED OUTPUT CONDITION
AND RECOVERY STOP SETTING CAUSING THE JOB STREAM TO COMPLETE IN ABEND
STATUS
The OPERATOR_CALL job has a conditional dependency
on the DB2_BACKUP job completing with the ERROR output condition.
The DB2_BACKUP ends in ABEND and the ERROR output condition is satisfied.
As a result, the conditional dependency on the DB2_BACKUP job is evaluated
as satisfied. The OPERATOR_CALL job completes in SUCC status. However,
the job stream completes in ABEND status because it contains at least
one job in ABEND status set to recovery stop. To have the job
stream complete in SUCC status, set the DB2_BACKUP job to recovery
continue.
NON-SATISFIED
OUTPUT CONDITION AND RECOVERY STOP SETTING CAUSING THE JOB STREAM
TO COMPLETE IN ABEND STATUS
The PERFORMANCE job has a conditional
dependency on the SALES job completing with the STATUS_OK output condition.
However, the SALES job completes in ABEND status and the STATUS_OK
output condition is not satisfied. As a result, the conditional dependency
on the SALES job is evaluated as not satisfied and the PERFORMANCE
job is suppressed. The job stream completes in ABEND status because
the abended SALES job is set to recovery stop and the suppressed
status of the PERFORMANCE job is considered as a CANCELLED status.