IBM Workload Scheduler Conditional Dependencies © 2015 IBM Corporation

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

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

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

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

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

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

A Join contains a set of dependencies. IBM

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

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

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

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

Backup

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

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

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