SWG - TIVOLI
Tivoli Workload Scheduler for z/OS
Conditional and Step Dependencies
Troubleshooting
IBM
Rome Tivoli Lab
Via Sciangai, 53 00144, Rome – Italy
Rossella Donadeo
Tivoli Workload Scheduler development
Version: 20111217
© Copyright IBM Corp. 2011
Table of Content
1.
2.
3.
4.
Introduction...............................................................................................................................3
More frequent user errors / questions.................................................................................. 3
How to detect Step dependencies problems....................................................................... 4
How to detect Conditional Dependencies problems...........................................................6
1.Introduction
Purpose of this document is to provide help in understanding more frequent user errors.
Hints to detect and debug problems in this area are provided too.
A knowledge of Conditional Logic feature is needed to read this document: for a complete and detailed
explanation of Conditional logic feature we remand to the specific chapter dedicated to this argument in
the TWS for z/OS Managing the Workload manual.
2. More frequent user errors / questions
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 the
Event 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 the
step 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 involved
predecessor 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 other
words when the conditional predecessor was set to C or E, there was no successor to be executed: in
this case the condition dependency is left undefined. Another way to check this situation is to look
on 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 a
step 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. A Conditional or Step Dependencies is in undefined status: they should be false and unexpected
flag is off, Why?
•
Probably the Unexpected RC flag was reset by an unsuccessful Automatic Operinfo retrieval that
caused predecessor error setting to CLNO. Check the unexpected RC looking at EQQE141 or
EQQE142 messages on Controller log.
3. How to detect Step dependencies problems
The typical problem with Step Dependencies is that they are still not evaluated at the end of the job
running the JCL containing the step to be evaluated.
This can happen for three kind of problems:
1. Step End event never arrived
2. Step End event arrived but it did not match the Step Dependency definition
3. Step End event arrived, matched the Step Dependency definition but “unexpected RC” occurred
HOW TO RECOGNIZE WICH KIND OF PROBLEM OCCURRED?
First of all look at Controller Message Log. There is always a message for all 3 kind of problems.
These messages are issued also on the System log so it possible the triggering of a Netview alert
mechanism.
STEP END MISSING OR NOT RECOGNIZED:
Situation 1) and 2) can always be recognized by the issuing of message EQQE127W both on Controller
and System log:
EQQE127W MISSING STEP END EVENT FOR OPERATION ApplicationName
InputArrival OpNumber JOB NAME JobName. CONDITION DEPENDENCY
Dependency IN CONDITION ConditionId
DEFINED ON OPERATION ApplicationName
InputArrival OpNumber WILL REMAIN UNDEFINED
where Dependency is in expressed in the format:
StepName ProcStep RC operator (one of GE/GT/LT/LE/EQ/NE) RetCode
or
StepName ProcStep RC RG Retcode1 RetCode2
From this message you can identify both the operations in the plan having
•
the JCL containing the missing step
•
the conditional successor with the Condition containing the not evaluated Step Dependency
You can also detect that the Step Dependency has not been evaluated for this reason by browsing it and
checking the Missing Step info flag.
At this point, to understand if the Step is really missing or did not match our Step Dependency you must:
•
Check if the Step was really executed: for example if the Job ended in JCLI or Abended in a previous
Step our Step End event was not produced:
•
•
If so you can decide how to solve this situation: you can force the Step Dependency top False or
True or you can rerun the occurrence after having fixed the error in the JCL.
Check if the Step Dependency definition is correct. If the Step was really executed the Step End
Event could be received but not recognized as the one indicated in our Step Dependency due to:
•
A typo error
•
A misunderstanding in StepName and ProcStep meaning: they could be inverted
If so, fix the error, than you can decide how to solve this situation:
you can force the Step Dependency top False or True or you can rerun the occurrence.
•
Check if Event Writer Configuration is wrong. If the Step was really executed the Step End Event
was not received probably for a configuration error. So check all the Trackers EWTROPTS
STEPEVENT definitions, they must be STEPEVENTS(ALL) or you must have SDEPFILTER
keyword: check SDEPFILTER value against JCL programmer name:
•
If you find EWTROPTS configuration errors fix them, then stop restart Trackers rebuilding the
SSX.
•
If you find a JCL programmer name error fix it in the JCL.
•
In any case for the current JCL problem you can decide how to solve this situation: you can force the
Step Dependency to False or True or you can rerun the occurrence after having fixed the error in the
JCL.
STEP END RECEIVED BUT NOT EVALUATED:
Situation 3) can always be recognized by the issuing of message EQQE142W both on Controller and
System log:
EQQE127W UNEXPECTED RC OCCURRED FOR OPERATION:
ADID=ApplicationName, IA=InputArrival, OPNO=OpNumber, WS=WsName
JOBNAME=Jobname, JOBID=JobId, DEST= Destination
WHEN CHECKING END OF STEP: StepName ProcStep
From this message you can identify the operation for which the Step End arrived and which was the Step.
What happened is that a conditional successor with a Step dependency pointing to the specified Step was
found but the Return code was not the expected one and there was no possible path in the plan.
So an “unexpected RC” situation occurred and the Step Dependency was not evaluated.
You can verify this by browsing the predecessor operation and checking the Unexpected RC flag: it
should be set unless an unsuccessful Operinfo retrieval was executed caubing predecessor status change to
Error with error code CLNO.
In any case at this point you can decide how to solve this situation: you can force the Step Dependency to
False or True or you can rerun the occurrence after having fixed the problem (adding a new path or
making the Step run and end with the expected RC)
4. How to detect Conditional Dependencies problems
The typical problem with Conditional Dependencies is that they are not evaluated at the end of the
predecessor job.
Usually this happen when an “Unexpected RC” situation occurs, that is when the predecessor job ends
does not allow the start of any path in the plan.
If this is the reason of the missing evaluation you can find on the Controller an System log the message
EQQ141W:
EQQ141W
UNEXPECTED RC OCCURRED FOR OPERATION:
ADID=ApplicationName, IA=InputArrival, OPNO=OpNumber, WS=WsName
JOBNAME=JobName, JOBID=JobId, DEST=Destination
WHEN SET TO STATUS Status.
From this message you can identify the involved predecessor operation and its new Status.
What happened is that a conditional successor with a dependency pointing to this operation was found
but the Status / Return code was not the expected one and there was no possible path in the plan.
So an “unexpected RC” situation occurred and the Dependency was not evaluated.
You can verify this by browsing the predecessor operation and checking the Unexpected RC flag: it
should be set unless an unsuccessful Operinfo retrieval was executed causing predecessor status change to
Error with error code CLNO.