1. IBM Workload Scheduler
Conditional Dependencies
© 2015 IBM Corporation

2. Conditional Dependency Introduction
Conditional Dependencies allow you to define workflows with alternative branches based on conditions.
IBM

3. Conditional Dependency Basic Concepts
The conditions can be:
- Status conditions
- Output conditions
IBM

4. Job Definition Dynamic Workload Console
The mapping expression can be:
Return code (FTA and DA)
Job Status (FTA and DA)
Output variables (only DA)
Job log content (only DA)
The conditions are evaluated in OR
IBM

5. Job Definition composer
$JOBS
RENOIR#ABSENCES
DOCOMMAND “exit 1"
STREAMLOGON twsuser
TASKTYPE UNIX
SUCCOUTPUTCOND STATUS_OK "RC=0"
OUTPUTCOND DB_FAIL "RC=1"
OUTPUTCOND TEMP_FULL "RC=2"
RECOVERY CONTINUE
The syntax for composer is:
Key : SUCCOUTPUTCOND or OUTPUTCOND
Label name
Mapping expression
The conditions will be evaluate in OR
IBM

6. Job Definition Dynamic Workload Console
The Conditional Dependency panel is dynamically built and handles external and internal conditional dependencies
The predecessor can be a job or a job stream
IBM

7. Job Stream Conditional Dependency composer
SCHEDULE RENOIR#PAYROLL_PROC
ON RUNCYCLE RULE1 "FREQ=DAILY;"
FOLLOWS RENOIR_1#PAYROLL_PROC1.JOB1 ON FAIL :
RENOIR#CDABSENCES_DB_FAIL AS ABSENCES
RENOIR#CDTEMP_CLEANUP AS TEMP_CLEANUP
FOLLOWS ABSENCES ON TEMP_FULL
RENOIR#CDRESTART_DB AS RESTART_DB
FOLLOWS ABSENCES ON DB_FAIL
FOLLOWS PICASSO_1#PAYROLL1.JOB_OK ON STATUS_OK
RENOIR#CDDB_BACKUP AS DB_BACKUP
FOLLOWS ABSENCES ON SUCC
END
The syntax is similar to define internal and external depencencies but with the keyword:
ON <Condition>
To define multiple conditions use the « |» character:
FOLLOWS ABSENCES ON TEMP_FULL |DB_FAIL
IBM

8. A Join contains a set of dependencies.
IBM

9. The conditions in the join are evaluated in AND
The Join dependency is satisfied if <n> dependencies are satisfied
The conditions in the join are evaluated in AND
IBM

10. Job Stream Conditional Dependency composer
SCHEDULE RENOIR#PAYROLL_PROC
ON RUNCYCLE RULE1 "FREQ=DAILY;"
RENOIR#CDABSENCES_DB_FAIL AS ABSENCES
RENOIR#CDABSENCES_RETRY AS ABSENCES_RETRY
JOIN PROBLEM_SOLVING 1 OF
FOLLOWS RESTART_DB ON SUCC
FOLLOWS RESTART_WAS ON SUCC
FOLLOWS TEMP_CLEANUP ON SUCC
ENDJOIN
END
Join section can contain conditional dependencies but
also «classic» dependencies
IBM

11. Job Stream Conditional Dependency conman
The info provided by conman is similar to the syntax used by composer command line
IBM

12. Workflow execution
If the DB_FAIL condition is satisfied, the jobs of the alternate flows are changed in a new state: SUPPRESS
IBM

13. Backup

14. IBM Workflow execution
Conditional dependencies are supported only for dependencies when the predecessor is a job or a jobstream. They are not supported on internetwork dependencies.
An old dependency is any dependency that is not conditional (job, jobstream, file, etc…)
Old dependencies work as previously. Furthermore when the predecessor is in SUPPR state, the old dependency on that predecessor is released.
The conditional dependencies are evaluated (at the end) only when all the old dependencies are satisfied.
When an internal/external conditional dependency is satisfied (match the status or output condition of the job predecessor or the status condition of the job stream predecessor) the conditional dependency is flagged as satisfied, and if all the conditions are satisfied (or at least the quantity is reached into join), the job or the job stream is put in ready state.
When an internal/external conditional dependency is not satisfied (it does not match the status or output condition of the job predecessor or the status condition of the job stream predecessor), if it’s not contained in a join, the relative successor job or jobstream is put on SUPPR state. When instead the conditional dependencies are contained in a join, the job or jobstream (that has as dependency that join) is put on SUPPR state when all the conditional dependencies in that join are evaluated and the quantity (for satisfied conditions) is not reached.
The SUPPR state is not propagated in case of old dependencies. When the predecessor is in SUPPR state, the old dependency on that predecessor is released. To propagate SUPPR condition, you need e.g. to define a conditional predecessor on SUCC.
IBM

15. IBM Workflow execution
When no output conditions are satisfied at the end of a job execution, any conditional dependencies on an output condition of that job (as predecessor) is considered not assessable, and therefore the job/job stream remains in hold state. The same consideration is valid when the predecessor is in SUPPR state (no output condition is evaluated), and the conditional dependency is on output conditions.
In case of job rerun, on all the conditional dependencies the SATISFIED flag is cleared (like the old dependencies), so at the end of job execution they are re-evaluated.
Changes on Jobstream status calculation:
The job stream is put on SUPPR state when at least one conditional dependency is not satisfied;
When a job inside the jobstream is in SUPPR state, it’s considered like a cancelled job for the jobstream status calculation. If all jobs inside the jobstream are in SUPPR state, the jobstream state is SUCC (as already happen for canceled jobs)
When a jobstream is put on SUPPR state, all the containing jobs that have not a final state (READY, HOLD), are put on SUPPR state.
To calculate the jobstream final status, the job in ABEND is considered as previously, even if it has released a conditional dependency. Therefore, if it has recovery stop, and a conditional dependency is released, the final status of the jobstream is ABEND. If instead, the job in ABEND has a recovery continue option, and a conditional dependency is released, the final status of the jobstream is SUCC. This behavior is the same for old and conditional dependencies.
IBM

16. Thank you
© Copyright 2015 IBM Corporation. IBM, and the IBM logo are trademarks of IBM Corporation, registered in many jurisdictions worldwide.
© 2015 IBM Corporation