SWG - TIVOLI Tivoli Workload Scheduler for z/OS ... file1.Introduction Conditional logic feature...

SWG - TIVOLI Tivoli Workload Scheduler for z/OS Conditional and Step dependencies:

When and How to use them to shorten workload execution time

orto automatically handle branching scenarios

IBM Rome Tivoli Lab

Via Sciangai, 53 00144, Rome – Italy

Rossella DonadeoTivoli Workload Scheduler development

Version: 20111217

© Copyright IBM Corp. 2011

Table of Content1. Introduction ............................................................................................................................... 3 2. Step dependency scenario ...................................................................................................... 4 3. Branching scenarios ................................................................................................................ 6

3.1 Recovery job example (with NOERROR) ............................................................................ 6 3.2 Recovery Job example (without NOERROR) ...................................................................... 9 3.3 Alternate branch example (with Status X propagation) ..................................................... 13

4. Troubleshooting .................................................................................................................... 18 5. Appendix A – Some few key concepts ................................................................................ 19

5.1 Some things to know about “Normal” dependencies ......................................................... 19 5.2 What is a “Conditional” dependency? ................................................................................ 20 5.3 What is a “Step” dependency? .......................................................................................... 20 5.4 A key concept: “Conditional” like “External” dependencies ............................................... 20 5.5 When and how is a Condition evaluated? ......................................................................... 20 5.6 Considerations about “Started” status ............................................................................... 20 5.7 Suspended evaluation (unexpected RC handling) ............................................................ 21 5.8 Some terminology .............................................................................................................. 21

1.Introduction

Conditional logic feature makes the planning more flexible allowing real-time processing decisions.

It can also shorten workload execution time allowing Step dependencies.

The addressed scenarios are of two kinds:

Automatic handling of Branching ==> Conditional dependencies You can automate the flow execution to follow alternative branches when a combination of specific criteria at operation level are met.

Workload Time Execution shortening ==> Step dependenciesFor long duration jobs you can anticipate successors start at a specific Step end avoiding to wait whole jobcompletion.

Purpose of this document is to provide some examples to understand when and how to use Conditionaland Step dependencies.For a detailed explanation of all Conditional logic feature we remand to the specific chapter dedicated tothis argument in the TWS for z/OS Managing the Workload manual.

Anyway a summary of some few key concepts used in Conditional logic can be found in Appendix A.

2.Step dependency scenario

z/OS Jobs can be made of many Steps whose Return Codes could condition the start of other jobs.

The complete execution of the whole job could take a long time while the other jobs could start as soon asa specific step ends. The JCL IF/THEN ELSE logic can help in this scenario but forces the user to put allthe logic inside the JCL of one single Job. In case of complex networks this should be avoided.

Conditioning a JOB start to the Step End result of another JOB and monitoring this with no need to lookat produced JOBLOG, simplifies complex network planning and monitoring.

USER SCENARIO DEFINITION:

Job1 is made by many steps but only the first one completion is really needed to start Job2 execution.

Job1 takes a long time to be executed mainly due too the steps following the first one.

The JCL is something like the following:

//JOB1 JOB,,NOTIFY=USER1

//PROC1 PROC1

//Z1 EXEC PGM=MYPGMZ1

// PEND

//STEP1 EXEC PGM=MYPGM1


....


When Job1 STEP1.Z1 ends successfully Job2 can start.

If STEP1.Z1 is not executed or fails Job2 must not run until problem is debugged and appropriaterecovery actions are taken.

WHAT TO DEFINE IN TWS Z/OS TO REALIZE THIS SCENARIO:

JOB2

JOB1

Condition:JOB1 STEP1 Z1 RC=0

• Job2 has a step dependency checking that Job1 STEP1 (STEPNAME) Z1 (PROCSTEP) RC is 0

• Event Writer initial parameter (EWTROPTS) has been changed to add SDEPFILTER(20,Z) toindicate that if the character at position 20 in JOB card programmer name is Z step end events must begenerated for the job.

• Job1 JCL has been changed to set the character at position 20 in programmer name equal to Z //JOB1 JOB,'Programmer name Z',NOTIFY=USER1

note that SDEPFILTER and JCL changes were defined to reduce the amount of produced step end events.

SCENARIO 1: JOB1 STEP1.Z1 ends with RC=0. Job2 step dependency is evaluated true at step end time so that Job2 status is set to ready independentlyfrom next steps execution and RC, reducing the time needed for Job2 start.

JOB2

JOB1


T

S

R

SCENARIO 2: JOB1 STEP1.Z1 abends. Job2 step dependency is checked at step end but there is no path for this RC in the plan so the Conditionis left not evaluated in status undefined.

Job2 is left in waiting status.

JOB2

JOB1


U

E

W

HOW TO DETECT THIS KIND OF PROBLEM:Looking at the error list we find Job1 flagged with unexpected RC. This means that there are probablyconditional successors waiting with conditions in undefined status due to this unexpected situation.

We can be alerted as soon as this situation occurs monitoring on Controller log the EQQE142Wmessages.

3.Branching scenarios

What do we mean by Branching?

• Return Codes from successful jobs are used to indicate what branch of batch to process

• Any jobs failing should cause processing to halt until restart and successful completion

• Branching may rejoin at some point: from this point batch is unconditional and should run every day,when all predecessors have either run or successfully been excluded

• Conditionally branches are typically short, usually 1 or 2 jobs per branchLet's see some branching scenarios examples.

3.1 Recovery job example (with NOERROR)


When Job1 ends successfully Job2 can start. Job3 can start when Job2 ends successfully

Anyway some kinds of failures can be recovered:

• if Job1 ends with RC=4 the Job1A must run and if it completes successfully Job2 can start.• if Job1 ends with RC=8 the Job1B must run and if it completes successfully Job2 can start.


JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

• Job1 has a NOERROR statement allowing RC=4 and RC=8.• Job2 has 3 “Normal” predecessors: Job1, Job1A and Job1B

• Job3 has one “Normal” predecessor: Job2

• Job1A has the Condition made by only one Condition dependency checking that Job1 RC is 4 (rule canbe all or or)

• Job1B has the Condition made by only one Condition dependency checking that Job1 RC is 8 (rule canbe all or or)

SCENARIO 1: JOB1 ends successfully. Job1 runs and ends with RC=0 and is set to Complete.

Job1 has a normal successor (Job2) so that a possible path exists in the plan for its completion.

The check “Job1 RC=4” is false so that Job1A Condition is set to False too.

Job1A has its condition set to false: for this reason it is set to X status (suppressed by condition) and willnot be executed (like noped)The check “Job1 RC=8” is false so that Job1B Condition is set to False too.

Job1B has its condition set to false: for this reason it is set to X status (suppressed by condition) and willnot be executed (like noped)

At this point Job2 has 3 “Normal” predecessors in status C, X and X: this is equivalent to have allpredecessors completed so it is set to ready and flow can continue.

At next Daily Plan batch run the X status jobs will be eligible for removal as they will be considered ascompleted jobs.

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

F F

X X

R

W

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

F F

X X

R

W

SCENARIO 2: JOB1 ends with RC=4. Job1A ends successfully Job1 runs and ends with RC=4 and it is set to Complete (NOERROR applies).

Job1 has a conditional successor (Job2) that will run due to this RC so that a possible path exists in theplan for its error.

The check “Job1 RC=4” is True so that Job1A Condition is set to True too.

Job1A has its condition set to true: this is equivalent to have a predecessor completed and it is set toReady. Job1A starts and completes.

The check “Job1 RC=8” is false so that Job1B Condition is set to False too.

Job1B has its condition set to false: for this reason it is set to X status (suppressed by condition) and willnot be executed (like noped)

At this point Job2 has 3 “Normal” predecessors in status C, C and X: this is equivalent to have allpredecessors completed so it is set to ready and flow can continue.

At next Daily Plan batch run the X status jobs will be eligible for removal as they will be considered ascompleted jobs.

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

T F

C X

R

W

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

T F

C X

R

W

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

T F

R X

W

W

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

T F

R X

W

W

SCENARIO 3: JOB1 ends with RC=4. Job1A fails The difference respect to SCENARIO 2 is that Job1A is set to Error so that Job2 remains in Wait statushaving 3 “Normal” predecessors in status E, C and X.

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

T F

E X

W

W

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

T F

E X

W

W

HOW TO DETECT THIS KIND OF PROBLEM:Looking at the error list we find Job1A and recognize this is a real problem.

SCENARIO 4: JOB1 abends Job1 runs and abends so it is set to Error status.

Job1 has no successor (normal or conditional) that will run due to this abend so that no possible pathexists in the plan for this error: an unexpected RC situation occurs and Job1 is flagged for this.

The Job1A and Job1B conditions are left not evaluated in undefined status.

Job1A , Job1B and Job2 are all left in waiting status

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

E

U U

W W

W

W

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

E

U U

W W

W

W

UNEXPECTED RC

HOW TO DETECT THIS KIND OF PROBLEM:

Looking at the error list we find Job1 flagged with unexpected RC. This means that there are probablyconditional successors waiting with conditions in undefined status due to this unexpected situation.

We can be alerted as soon as this situation occurs monitoring on Controller log the EQQE141Wmessages.

3.2 Recovery Job example (without NOERROR)


The same scenario previously described in Recovery Job Example (with NOERROR).The difference is that this time we do not want to use the NOERROR feature.


This time to realize the same user scenario without using NOERROR feature, we will change the normaldependency between Job1 and Job2 with a conditional one, defining on Job2 a Condition that will becometrue when at least one of the following occurs: Job1 is set to C, Job1 RC=4 or Job1 RC=8.

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

Condition: rule = ORJOB1 ST=CJOB1 RC=4JOB1 RC=8

Let's see what happens in the same scenarios described below:

SCENARIO 1A: JOB1 ends successfully.

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

C

F F

X X

R

W


T

Job1 runs and ends with RC=0 and is set to Complete.

Job2 condition is True (Job1 ST=C is true) so a possible path exists in the plan for Job1 completion.

Job1A and Job1B conditions are false so that Job1A and Job1B are set to X status (suppressed bycondition)

Job2 has 2 “Normal” predecessors in X status and a Condition True: it can be set to ready status

SCENARIO 2A: JOB1 ends with RC=4. Job1A ends successfully

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

E

T F

X

R

W


T

RECOVERED BY COND

C

Job1 runs and ends with RC=4 and it is set to Error.

Job1A condition is true so that Job1A is set to ready, then starts and completes

Job1B condition is false so that Job1B is set to X statusJob2 Condition is true (Job1 RC is 4) and has two normal predecessors in C and X status: it can be set toready

Note that in order to remove at next Daily Plan batch run Job1 even if in error status, we have definedJob1A and Job1b as recovery jobs. In this way, when job1A has been set to Ready status Job1 has beenflagged as recovered by COND and Daily Plan batch can remove it.

HOW TO DETECT ERROR STATUS THIS TIME IS NOT A PROBLEM:

Looking at the error list we find Job1 flagged as recovered by COND. This means that a conditionalsuccessor was set to ready and we have to check it to be sure recovery actions were completed

SCENARIO 3A: JOB1 ends with RC=4. Job1A fails The difference respect to SCENARIO 2A is that Job1A is set to Error so that Job2 remains in Wait statushaving one condition true and 2 “Normal” predecessors in status E and X.

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

E

T F

E X

W

W


T

RECOVERED BY COND


Looking at the error list we find Job1 and Job1A.

Job1 is flagged as recovered by COND so we can think this is not really a problem.

Anyway looking at Job1A we see it flagged as a COND recovery job so we know that Job1A is a problembecause it failed while it was supposed to recover the failure of another job (Job1)

SCENARIO 4A: JOB1 abends Job1 runs and abends so it is set to Error status. Job1A Job1B and Job2 conditions are false so that nopossible path exists in the plan for Job1 error: an unexpected RC situation occurs and Job1 is flagged forthis. The Job1A and Job1B and Job2 conditions are left not evaluated in undefined status. Job1A , Job2Aand Job2 are all left ion waiting status

JOB1A

Condition:JOB1 RC=8

JOB1B

JOB1

Condition:JOB1 RC=4

JOB2

JOB3

E

U U

W W

W

W

UNEXPECTED RC


U


Looking at error list we see that Job1 ended in error (this is a problem).

We see that Job1 is also flagged as unexpected RC: this means that there are conditional successors inwaiting status with Conditions in undefined status due to this unexpected situation.We can be alerted on this kind of problem from specific message in Controller log (EQQ141W)

3.3 Alternate branch example (with Status X propagation)


According to Job1 Return Code value 3 different alternate flows can start:

• When RC=0 then JobA1, JobA2 flow must be executed

• When RC=1 then JobB1, JobB2 flow must be executed .

• When RC=2 then JobC1, JobC2 flow must be executed • Any other Job1 RC should cause processing to halt until restart and successful completion

• When one of the 3 alternate branch is successfully executed flow can continue with Job2


• Job1 has a HIGHRC = 2 • JobA1 has a condition on Job1 checking RC=0

• JobA2 has a condition on JobA1 checking ST=C to allow X status propagation

• JobB1 has a condition on Job1 checking RC=1

• JobB2 has a condition on JobB1 checking ST=C to allow X status propagation

• JobC1 has a condition on Job1 checking RC=1

• JobC2 has a condition on JobC1 checking ST=C to allow X status propagation• Job2 has three “Normal” predecessor: JobA2, JobB2 and JobC2

SCENARIO 1: JOB1 ends with RC=1 and JOBB1, JOBB2 run successfully

Condition:JOB1 RC=2

JOBB1

JOB1

Condition:JOB1 RC=0

JOB2

C

F

C

R

Condition:JOB1 RC=1

F

JOBA1

JOBA2

JOBC1

Condition:JOBA1 ST=C

Condition:JOBB1 ST=C

Condition:JOBC1 ST=C

JOBB2 JOBC2

X

X XC

F FT

T

X

Job1 ends with RC=0 and is set to complete.

JobB1 Condition is true so that JobB1 is set to ready status and a path in the plan exists: consequentlyJobA1 and JobC1 conditions are evaluated and set to false and JobA1and JobC1 are set to X status.

Conditions on X status are always evaluated (independently from next path in the plan) so that JobA2 andJobC2 conditions are evaluated false and JobA2 and JobC2 are set to X status (X status propagation).

JobB1 run successfully so that JobB2 condition is true and JobB2 is set ready status and can run.

JobB2 run successfully.

At this point Job2 is set to ready because all normal predecessors are in X or C status.JobA1 flow and JobC1 flow are correctly nullified by means of X status propagation.

SCENARIO 2: JOB1 ends with RC=1 and JOBB1 fails

Condition:JOB1 RC=2

JOBB1

JOB1

Condition:JOB1 RC=0

JOB2

C

F

E

W

Condition:JOB1 RC=1

F

JOBA1

JOBA2

JOBC1




JOBB2 JOBC2

X

X XW

F FU

T

X

The difference respect to the previous scenario is that this time JobB1 fails and is set in error status.

As a consequence no path exists in the plan for this situation so that JobB2 condition is left not evaluatedin undefined status and JobB1 is flagged as “unexpected RC” . Processing is correctly halted (JobB2 is in wait status and consequently also Job2) until some manualaction is done.

JobA1 flow and JobC1 flow are correctly nullified by means of X status propagation.


Looking at error list we find JobB1 set in error status and flagged as unexpected RC. This means thatthere are conditional successors waiting with undefined Conditions due to this unexpected situation.

We can be alerted as soon as this problem occurs by monitoring on Controller log message EQQ141W.

SCENARIO 3: JOB1 ends with RC=1 and JOBB2 failsThe difference respect to the previous scenario is that this time there is no unexpected RC but Job2 isprevented to run from its normal dependency from Jobb1 that is set in Error status.

Processing is correctly halted until some manual action is done.

JobA1 flow and JobC1 flow are correctly nullified by means of X status propagation.

Condition:JOB1 RC=2

JOBB1

JOB1

Condition:JOB1 RC=0

JOB2

C

F

C

W

Condition:JOB1 RC=1

F

JOBA1

JOBA2

JOBC1




JOBB2 JOBC2

X

X XE

F F

T

X

T


Looking at error list we see that JobB2 ended in error (this is a problem).

We can be alerted as soon as this problem occurs by monitoring on Controller log message EQQ141W.

SCENARIO 4: JOB1 ends with RC=8 Job1 ends with RC=8 and is flagged as “Unexpected RC” because no path exists in the plan for this RC.

As a consequence all the related conditions are left undefined and processing is halted until some manualaction is done. JobA1 , JobB1 and JobC1 are left in waiting status.

Condition:JOB1 RC=2

JOBB1

JOB1

Condition:JOB1 RC=0

JOB2

E

U

W

W

UNEXPECTED RC

Condition:JOB1 RC=1

U

JOBA1

JOBA2

JOBC1




JOBB2 JOBC2

U U

W

U

U

W

WWW

HOW TO DETECT THIS KIND OF PROBLEM:Looking at error list we see that Job1 ended in error and that it is flagged as unexpected RC.

This means that there are conditional successors in waiting status with Condition in undefined status dueto this unexpected RC.

4. Troubleshooting

Hereafter more common users errors / questions follow:

1. I added an occurrence in the plan but Conditions were lost. Why?• When you add an occurrence via ISPF you must specify automatic dependency resolution to yes like

you do for external dependencies resolution in order to have conditions added to the plan

2. I defined a step dependency but it remains hanging in undefined status, Why?• StepName and ProcStep were probably inverted in the step dependency definition: check it.

• If this is not the case check that the A3S events were correctly generated. To do this checks that theEvent Writer initial parameter statement specifies STEPEVENTS(ALL) or SDEPFILTER(startpos,string). If SDEPFILTER is used check that the programmer name of the job for which thestep dependency has been defined is coherent with the SDEPFILTER values.

3. I have conditional dependencies in the plan hanging in undefined status even if the involvedpredecessor have already run. Why?• Probably an unexpected RC situation occurred. Check if the conditional predecessors have the

unexpected RC flag on (directly browsing them or filtering the operations with this flag on). In otherwords when the conditional predecessor was set to C or E, there was no successor to be executed: inthis case the condition dependency is left undefined. Another way to check this situation is to lookon Controller log for related messages (EQQE141W, EQQE142W, EQQM125W)

4. A job failed and I want to rerun it but I'm not allowed to change the status to ready or execute astep restart even if no external dependencies exist. Why?• Probably the job has conditional predecessors or successors. In this situation status can change only

within an occurrence rerun because conditions are like external predecessors..

5. Appendix A – Some few key concepts

5.1 Some things to know about “Normal” dependencies

Before TWSz 8.5.0 you could define only “Normal” dependencies.

A “Normal” dependency conditions the starting of an operation on the successful completion of all itspredecessors operations.

The relationship is 1 to 1: a “Normal” dependency is considered satisfied when the predecessor operationis completed. The successor can start when all its normal dependencies are satisfied.The normal status change flow is the following:

W ==> (R,*,A) ==> S ==> C or E

(W) WAIT The Job has some predecessor not completed.

(R,*, A) READY The Job has no predecessors or all predecessors are completed.

(S) STARTED The Job has been submitted by the Scheduler to be executed

(E) ERROR The Job ended in error

(C) COMPLETED The Job ended successfully

The logical sequence of statuses is constantly checked by TWS for z/OS that does not allow incongruenceand makes some status changes possible only in particular scenarios.If you try to change the status of a job in a way not congruent with the predecessors and successors status,TWS for z/OS adjusts the predecessors and successors statuses only if:

• No external dependency is involved: changes are all within the same occurrence.

Or

• You are executing an Occurrence Rerun so that the list of required external operations status changes isshown in order to be reviewed and confirmed before to proceed.

If you are not in the above described situations TWS for z/OS stops you issuing the appropriate errormessage:

EQQM218E EXTERNAL PREDECESSOR FOUND, STATUS CANNOT BE CHANGED:

You cannot change the status of an operation if it has external predecessor not completed

EQQM208E THE STATUS CANNOT BE CHANGED - EXTERNAL SUCCESSOR S, C, OR E:You cannot change the status of an operation if external successors with status Complete, Error or Startedare found

In conclusion:

External dependencies have more restrictions about status changes respect to internal dependencies. Thereason for this is to avoid an uncontrolled rerun of external successors due to a predecessor status change.On the contrary when you are in an occurrence rerun path all involved status changes are shown so thatrestriction is no more needed.

5.2 What is a “Conditional” dependency?

From TWSz 8.5.0 it is possible to define also “Conditional” dependencies.Anyway consider that Conditional logic has been re-designed in TWSz 8.5.1 to improve its usabilitymaking it “logically” different from TWSz 8.5.0 respect to the X status propagation. In this document from here on we refer always to the TWSz 8.5.1 logic.

You can condition the start of an operation to a specific combination of Status and Return Codes values ofone or more operations in the plan.The relationship is 1 to N: a “Conditional” dependency is considered satisfied when the specifiedcombination of operations Status and Return Codes occurs.The successor can start when all its dependencies (“Normal” and “Conditional”) are satisfied.

5.3 What is a “Step” dependency?

From TWSz 8.5.1 it is possible to define also “Step” dependencies.

You can Condition the start of an operation to a specific step return code.

To do this you can define a “Conditional” dependency that references a specific step of a predecessor job.So a “Step” dependency is a sub-type of “Conditional” dependency.

5.4 A key concept: “Conditional” like “External” dependencies

Conditional dependencies can connect operations belonging all to the same occurrence or to differentoccurrences, but they are always considered as external ones. Same rules of external dependencies applies to them.

5.5 When and how is a Condition evaluated?

Conditions dependencies (and therefore Conditions) are evaluated at job end time (manually or via event)when the predecessor status becomes one of the allowed ones: S, C, E or X.

The only exceptions are Step dependencies that are evaluated at step end time

At evaluation time checks are done against status (ST) and Return Code (RC).The checked Return Code is the original one, that is before NOERROR or HIGHRC processing.

Status check can use only the logical operators EQ and NE, except status S for which NE is notapplicable.

5.6 Considerations about “Started” status

By default the check on started status is executed only when the job is really started, that is when the jobstart event has been reported by the tracker.

Anyway, if you do not need to wait the real submission of the job and it is sufficient the setting of thestatus value to S, you can do it by setting the JTOPTS CONDSUB parameter value to YES.

5.7 Suspended evaluation (unexpected RC handling)

Condition dependency status (and consequently Condition status) is not changed at evaluation timewhenever none of the normal and Conditional successors will be executed, that is when an “unexpectedRC” Condition occurs.In other words when the Condition dependency should be set to false it is instead left undefined when inthe plan there is no alternate path to be executed.

The reason for this is to leave to the user the decision on how to proceed in the plan when somethingreally unexpected occurs. Consider that when a Condition is false the Conditional successor is set to Xstatus (suppressed by Condition): if there are normal successors of the operation just set in X status theywill start. This suspension does not apply if the check to be done is against the status X: in this case the Conditiondependency is always evaluated. This is done in order to allow the X status propagation whenever wished.

Unexpected RC situation can be detected / monitored by:

• checking into the Controller Log the related messages issuing (EQQE141W, EQQE142W,EQQM125W)

• Filtering on operation Unexpected RC flag (predecessors causing this situation are flagged)

5.8 Some terminology

Conditional dependency:A relationship between two operations realized by means of a Condition

Condition: A combination of predecessor status and Return codes (Condition / Step dependencies) aggregatedby a rule:

(AND) All must be true

(OR) At least n must be true (n value is from one to all)

We can say it is a set of Condition dependencies aggregated by a rule

Condition dependency: A dependency from the Status or Return code of another job It is defined by:

The Predecessor Id: Application Name, Input Arrival time, operation number

The Predecessor info to be checked: Return Code (RC) or Status (ST)

The logical Operator: EQ (Equal to) NE (Not equal to) GT (Greater than)

LT (Less than) LE (Less equal) RG (In this range)

RC values: nnnn 4 digit integerSxxx System Abend, 3 digit for hexadecimal abend value

Uxxx User Abend, 3 digit for hexadecimal abend value

cccc 4 characters

ST values: S, C, E and X

Step dependency: (a subtype of Condition dependency)A particular Condition dependency: the Return code refers to a specific step of another job.

Conditional PredecessorA job A is a Conditional Predecessor of job B if on job B is defined a Condition dependencyincluding A as a predecessor to be checked.

Conditional SuccessorA job B is a Conditional Successor of job A if on job B is defined a Condition dependencyincluding A as a predecessor to be checked.

Condition dependency Status: A Condition dependency has its own status that can be:

• Undefined ==> The specific check has not yet evaluated

• True ==> The specified check has been evaluated and it is true

• False ==> The specific check has been evaluated and is false

Condition Status: A Condition has its own status derived by its own Condition dependencies statuses.It that can be:

• Undefined ==> Condition has not yet evaluated

• True ==> Condition has been evaluated.

The specified combination of status and RC occurred

• False ==> Condition has been evaluated.

The specified combination of status and RC did not occur.

Suppressed by Condition status (X)A job having at least one Condition evaluated false assumes the X status.

Job in X status are handled like noped operations: they are not executed but their normal successors can start.

To propagate X status to a successor (e.g. to nullify a whole branch) this must be defined as a Conditional successor with the Condition dependency ST EQ C.

You can define more Conditions based on predecessors final status and Return Codes

If you define more Conditions they must all be true to allow successor starting.

Date post:	01-Nov-2018
Category:	Documents
Upload:	vucong
View:	221 times
Download:	0 times

SWG - TIVOLI Tivoli Workload Scheduler for z/OS ... file1.Introduction Conditional logic feature...

Documents