1 / 72

Storyboard - TWS for z/OS 8.5.0 Conditional logic IBM Tivoli Software

Storyboard - TWS for z/OS 8.5.0 Conditional logic IBM Tivoli Software. Rossella Donadeo. TWS for z/OS 8.5.0 Storyboard – Conditional logic Overview. Disclaimer:

Download Presentation

Storyboard - TWS for z/OS 8.5.0 Conditional logic IBM Tivoli Software

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Storyboard -TWS for z/OS 8.5.0Conditional logic IBM Tivoli Software Rossella Donadeo

  2. TWS for z/OS 8.5.0 Storyboard – Conditional logic Overview Disclaimer: The purpose of this storyboard is to gather customer feedback on the Conditional Logic feature developed with TWS for z/OS 8.5.0 Release. The content of this storyboard is not committed by IBM and may change over the course of time based on gathered feedback and product requirements.

  3. TWS for z/OS 8.5.0 Storyboard – Conditional logic Overview 1 2 3 This presentation will focus on: Customer value of Conditional logic feature Description of Conditional Logic feature implementation Scenarios that illustrate main usage of the feature Note: Slides marked with the symbol have associated slides notes.

  4. TWS for z/OS 8.5.0 Storyboard – Conditional logic Customer value • Current Behavior: With TWS for z/OS you can specify dependency between operations in order to condition the starting of an operation on the completion of all its predecessors operations. • New Behavior: You will have the possibility to define more conditions on predecessors based on their final status and Return Code. • Customer value: • An easy driven way to define workflows with alternative branches mapped directly on the Current Plan. • An easy way to monitor Conditional work execution. • A general way to define conditional dependency independently from z/OS environment (not JCL oriented) Current alternative for z/OS users is to use the IF/THEN/ELSE JCL statements that cannot be easily monitored via ISPF/WEB UI dialogue (they are step dependencies defined within the JCL)

  5. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • It will be possible to define a new kind of dependency: the Condition • Defined in AD database at operation level based on logical combinations of conditional dependencies on predecessor operations status or return codes • Tracked in the Current Plan as a condition defined on operations, either created at plan creation time or added dynamically • Checked by Scheduler to decide if an operation is eligible to be submitted or not • A new status, suppressed by condition, (X) will be introduced to identify dead branch path in the Plan.

  6. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Condition definition • It can be considered a combination of condition dependencies. A condition dependency is a condition defined for a specific operation Status / Retun code value: Application Operation Condition Check Type (RC / STATUS) Logical Operator (GE,GT,LE,LT,EQ,NE,RG) Condition Check value (Rc value / Status value) E.g.: ApplA_001 RC GE 0004 • Allowed status value are Error, Complete, Suppressed by condition or Started • Allowed Return Code values are the ones possible for the existing operation field Error Code (4 chars)

  7. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Condition status /evaluation • The Condition Dependency has its own status that can be: True, False or Undefined • The Condition status is the result of the condition dependencies statuses combination • Scheduler will evaluate the Condition status each time an operation, involved in the condition dependencies, changes its status, until it assumes the final value: True or False. • An operation having a Condition Dependency will have the status set to: • W Waiting (Condition dependency is undefined, that is not yet evaluated) • R Ready (Condition dependency is True) • X Suppressed by condition (Condition dependency is False)

  8. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description A1 A2 A3 A1 A2 A1 A2 A3 A4 A3 or or or and B N out M and and B B At least one of A1, A2 A3 Cond deps must be true All of A1, A2 A3 cond deps must be true At least 2 out of 4 A1, A2, A3, A4 cond deps must be true • Condition types • Three types of Conditional dependecies combination can be defined: • At least one of: cond deps list • At least n out of : cond deps list • All of: cond deps list

  9. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Condition definition rules • You cannot have mixed combination of AND and OR within the same Condition definition But ... • You can define more Conditions (of different kind) on a single operation • You can ‘chain’ Conditions via dummy operations • You can use range operator for more common scenarios This guarantees the coverage of the major part of user Scenarios. For example, suppose we have the following four operations: • A1: Application A, operation 001 • B1: Application B, operation 001 • C1: Application C, operation 001 • D1: Application D, operation 001

  10. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description A1 B1 C1 D1 and and All must be true: C1 rc GE 8 D1 rc GE 8 All must be true: A1 rc GE 4 B1 rc GE 4 Y1 Y2 or Z1 At least one must be true: Y1 Status = C Y2 status = C • Condition definition rules Suppose you want to start operation Z1 when the following Condition is true: ((A1 RC >= 4) and (B1 RC >= 4)) or ((C1 RC >= 8) and (D1 RC >= 8)) You can do this by defining: Y1 and Y2 are DUMMY operations

  11. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description C1 A1 Z1 At least one must be true: A1 RC range 0-12 C1 RC range 0-12 • Condition dependency definition rules Suppose now you want to start operation Z1 when the following Condition is true: ((A1 RC > 0) and (A1 RC <= 12)) or ((C1 RC >0) and (C1 RC <= 12)) You do not need dummy operations: you can simply use the range operator:

  12. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Condition definition Rules • You cannot define an operation both as a conditional predecessor and a normal predecessor of the same operation: This means that if you want to define only conditional dependencies within the same Application you need a bypass (All operation within the same Application must be chained by normal dependency) The bypass is add a FOP dummy operation as normal predecessor of all conditional operation.

  13. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Condition definition rules • You can define a condition on an E2E operation only if it is with centralized script: The reason for this is that TWS support of Conditional Logic is not available at TWS z/OS 8.5 GA time. This support is required to handle the required changes in the Symphony.

  14. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Removal rules for operations with conditions • The new status X has been defined for the monitoring of Conditional workflow in order to display the dead branches that will never be executed • This leads to have a new meaning for the occurrence status C: it will be set when the operations belonging to the occurrence are all in C or X status • Conditional workflows imply the need to remove automatically from the plan also the occurrences in error status when the ended in error operations have been handled by their recovery jobs (no changes about completed occurrences).

  15. TWS for z/OS 8.5.0 Storyboard – Conditional logic Brief Description • Removal rules for operations with conditions • You can handle an error condition of an operation by a condition dependency on a job defined as recovery job (job option in the AD) • When a job ends in error, if the error code matches the condition defined on a recovery job, then the operation will be flagged as removable from the plan • Thus an occurrence will be removed from next plan if: • Its status is C • Its status is E and all its operations ended in error have been handled by recovery jobs

  16. TWS for z/OS 8.5.0 – Scenarios Persona and Goals • The following TWS for z/OS personas will be the main exploiters of the TWS z/OS Conditional Logic feature: • Kevin – TWS z/OS Application Manager • Experience Goals • Too much implementation effort to workaround product behavior • Tivoli Workload Scheduler for z/OS is the most scalable scheduler on the market and the company needs it, but it should be improved with the requested enhancements, to save the extra implementation effort for fulfilling business scenarios • End Goals • Deploy TWS for z/OS solutions to automate business processes and reduce the Total Cost of Ownership. • Solutions must be simple, consistent and, overall, reliable.

  17. TWS for z/OS 8.5.0 – Scenarios Persona and Goals Kevin currently uses JCL statements like COND of IF/THEN/ELSE to implement workflows with alternative branches. This definitions are done at step/ level and have some disadvantages: Their status cannot be monitored via TWS for z/OS unless you edit the JCL and check it against the resulting joblog They cannot be defined across different operations in the plan as they are JCL step/job card specific The definitions are z/OS specific. This means that alternative branches cannot be extendend to distributed jobs or other kind of operations (e.g. general workstation)

  18. TWS for z/OS 8.5.0 – Scenarios Outline • Handle Conditions in AD database • Define an operation as recovery job in AD • Handle Conditions in Long Term Plan • Handle Conditions in Current Plan

  19. Scenario 1 • Focus on: Handle Conditions in database • Define Conditions • Modify Conditions • Display Conditions

  20. Scenario 1 – Handle Conditions in database • Kevin wants to define one Application (APPLA), made by 4 operations • CPU1 001 JOBA • CPU1 002 JOBR1 • CPU1 003 JOBR2 • CPU1 004 JOBB • JOBB must be run after successful completion of JOBA or after an appropriate recovery job is run to handle JOBA error conditions. • JOBR1 is the recovery jobs that handles JOBA operation RC value less than 4. • JOBR2 is the recovery jobs that handles JOBA operation RC values greater than 4. • To obtain this Kevin first of all defines via ISPF the application adding a dummy operation (DMY 099) that is predecessor of all the others operations: • Ws No. Jobname Int Pred • DMY 099 • CPU1 001 JOBA 099 • CPU1 002 JOBR1 099 • CPU1 003 JOBR2 099 • CPU1 004 JOBB 099

  21. Scenario 1 – Handle Conditions in database Kevin defines all the operations in the application and to display the number of conditions in the panel issue the command TEXT: EQQAMOPL ------------------------ OPERATIONS ----------------- Row 1 to 5 of 5 Command ===> Scroll ===>PAGE Enter/Change data in the rows, and/or enter any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete S - Select operation details, J - Edit JCL Enter the PRED command above to include predecessors in this list, or, enter the GRAPH command to view the list graphically. Application : APPLA Row Oper Duration Job name Operation text Number of cmd ws no. HH.MM.SS Conds '''' GENN 099 00.00.01 ________ ________________________ 0 '''' CPU1 001 00.00.01 JOBA____ ________________________ 0 '''' CPU1 002 00.00.01 JOBR1___ ________________________ 0 '''' CPU1 003 00.00.01 JOBR2___ ________________________ 0 '''' CPU1 004 00.00.01 JOBB____ ________________________ 0 ******************************* Bottom of data ********************************

  22. Scenario 1 – Handle Conditions in database Kevin at this point go to modify the existing operation CPU1 002 (JOBR1) in order to define a condition dependency and enter option 1 to select predecessor option: EQQAMSDP --------------------- OPERATION DETAILS ----------------------------- Option ===> 1 Select one of the following: 1 PREDECESSORS - List of predecessors 2 WS RES AND SERVERS - Work station resources and servers 3 SPECIAL RESOURCES - List of special resources 4 AUTOMATIC OPTIONS - Job, WTO, and print options 5 FEEDBACK - Feedback options 6 TIME - Time specifications 7 OP INSTRUCTIONS - Operator instructions 8 JCL EDIT - Edit JCL 9 CLEANUP OPTIONS - Cleanup Options 10 EXTENDED INFO - Operation extended info 11 AUTOMATION INFO - System Automation operation info Application : APPLA Operation : CPU1 002 Duration : 00.00.01 Jobname : JOBR1 Number of int preds : 1 Number of ext preds : 0 Number of conds : 0

  23. Scenario 1 – Handle Conditions in database Kevin issues the COND command to go to define the condition dependency EQQAMPDL ----------------------- PREDECESSORS ---------------- Row 1 to 1 of 1 Command ===>CONDScroll ===>PAGE Enter the COND command to view list of Conditions. Enter/Change data in the rows, and/or enter any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete S - Description of external dependency Application : APPLA Operation : CPU1 002 JOBR1 Number of Conds : 0 Row Oper Transport time Application id Jobname cmd ws no. HH.MM (for ext pred only) '''DMY099 _____ ________________________ ******************************* Bottom of data ********************************

  24. Scenario 1 – Handle Conditions in database The new panel EQQAMCCL is shown: Kevin identifies the condition with Id 001 and select it to describe it in details NEW EQQAMCCL ------------- CONDITIONS DEFINITIONS ---------------- Row 1 to 1 of 1 Command ===> Scroll ===>PAGE Enter/Change data in the rows, and/or enter any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete S - Conditions details Application : APPLA Operation : CPU1 002 JOBR1 Row Cond Condition Description Dep Condition Rule cmd no. No. S'' 001JOBA 0 < RC <=4________ 0 ******************************* Bottom of data ********************************

  25. Scenario 1 – Handle Conditions in database The new panel EQQAMCCP is shown: Kevin adds two simple conditions with Rule “All must be true” to say: JOBR1 must be run if JOBA RC is > 0 and <= 4: NEW EQQAMCCP ------------- CONDITION DETAILS ---------------- Row 1 to 1 of 1 Command ===>Scroll ===>PAGE A Condition is made by a list of condition dependencies related by a rule. Each Dependency is defined on a Status or Return Code value through operators: EQ, NE, GE, GT, LE, LT, RG. To define a Dependency enter/change data in the rows, using any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete Application : APPLA Operation : CPU1 002 JOBR1 Condition Rule: > At least a subset of following list must be true: N Subset 000 > All in following list must be true: Y Row Oper Application Id Jobname Cond Cond Status Return Code cmd ws. no. (for ext Adid only) Type OP Value Value1 Value2 ‘’’ CPU1 001 ________________ JOBA___ RC RG _ 00010004 ******************************* Bottom of data ********************************

  26. Scenario 1 – Handle Conditions in database Kevin goes back to condition list panel and check that now the defined dependency is 1, than go back to previous panel to add a condition to JOBR2 job: NEW EQQAMCCL ------------- CONDITIONS DEFINITIONS ---------------- Row 1 to 1 of 1 Command ===> Scroll ===>PAGE Enter/Change data in the rows, and/or enter any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete S - Conditions details Application : APPLA Operation : CPU1 002 JOBR1 Row Cond Condition Description Dep Condition Rule cmd no. no. ''' 001JOBA 0 < RC <=4______ 1 All ****************************** Bottom of data ********************************

  27. Scenario 1 – Handle Conditions in database The new panel EQQAMCCL is shown: Kevin identifies the condition with Id 001 and select it to describe it in details NEW EQQAMCCL ------------- CONDITIONS DEFINITIONS ---------------- Row 1 to 1 of 1 Command ===> Scroll ===>PAGE Enter/Change data in the rows, and/or enter any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete S - Conditions details Application : APPLA Operation : CPU1 003 JOBR2 Row Cond Condition Description Dep Condition Rule cmd no. No. S'' 001JOBA RC > 4 ____________ 0 All ******************************* Bottom of data ********************************

  28. Scenario 1 – Handle Conditions in database The new panel EQQAMMCP is shown: Kevin adds only one dependency with Rule “All must be true” to say: JOBR2 must be run if JOBA RC > 4: NEW EQQAMCCP ------------- CONDITION DETAILS ---------------- Row 1 to 1 of 1 Command ===>Scroll ===>PAGE A Condition is made by a list of condition dependencies related by a rule. Each Dependency is defined on a Status or Return Code value through operators: EQ, NE, GE, GT, LE, LT, RG. To define a Dependency enter/change data in the rows, using any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete Application : APPLA Operation : CPU1 003 JOBR2 Condition Rule: > At least a subset of following list must be true: N Subset 000 > All in following list must be true: Y Row Oper Application Id Jobname Cond Cond Status Return Code cmd ws. no. (for ext Adid only) Type OP Value Value1 Value2 ‘’’ CPU1 001 ________________ JOBA___ RC GT _ 0004____ ******************************* Bottom of data ********************************

  29. Scenario 1 – Handle Conditions in database Finally Kevin define the condition for JOBB: NEW EQQAMCCL ------------- CONDITIONS DEFINITIONS ---------------- Row 1 to 1 of 1 Command ===> Scroll ===>PAGE Enter/Change data in the rows, and/or enter any of the following row commands: I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete S - Conditions details Application : APPLA Operation : CPU1 004 JOBB Row Cond Condition Description Dep Condition Rule cmd no. no. S'' 001JOBA or JOBR1 or JOBR2 __ 0 ******************************* Bottom of data ********************************

  30. Scenario 1 – Handle Conditions in database This time the needed rule is “at least on of” (OR) to say that JOBB must be run if at least one among JOBA, JOBR1 and JOBR2 completes. The simple conditions are 3: NEW • EQQAMCCP ------------- CONDITION DETAILS ---------------- Row 1 to 1 of 1 • Command ===>Scroll ===>PAGE • A Condition is made by a list of condition dependencies related by a rule. • Each Dependency is defined on a Status or Return Code value through operators: EQ, NE, GE, GT, LE, LT, RG. • To define a Dependency enter/change data in the rows, using any of the following row commands: • I(nn) - Insert, R(nn),RR(nn) - Repeat, D(nn),DD - Delete • Application : APPLA • Operation : CPU1 004 JOBB • Condition Rule: • > At least a subset of following list must be true: Y Subset 001 • All in following list must be true: N • Row Oper Application Id Jobname Cond Cond Status Return Code • cmd ws. no. (for ext Adid only) Type OP Value Value1 Value2 • ‘’’CPU1 001 ________________ JOBA___ ST EQ C • ‘’’CPU1 002 ________________ JOBR1__ ST EQ C • ‘’’CPU1 003 ________________ JOBR2__ ST EQ C • ******************************* Bottom of data ********************************

  31. Scenario 1 – Handle Conditions in database DMY 99 CPU1 1 CPU1 2 CPU1 3 CPU1 4 Cond 1 All true: CPU1 001 RC: 1-4 Cond 1 Cond 1 All true: CPU1 001 RC > 4 At least one of: CPU1 001 ST = C CPU1 002 ST = C CPU1 003 ST = C At this point Kevin has added in AD database the Application APPLA with one Condition for operation 002 003 and 004:

  32. Scenario 1 – Handle Conditions in database To check the just defined conditions Kevin goes to the BROWSE Operation panel, then select CPU1 004 JOBB to check Condition definition: EQQABOPL -------------------- BROWSING OPERATIONS ------------ Row 1 to 5 of 5 Command ===> Scroll ===>PAGE Enter the PRED command above to include predecessors in this list, or, enter the GRAPH command above to view operations graphically. Enter the row command S to select the details of an operation. Enter the row command J to browse the JCL Application : APPLA Row Oper Duration Job name Operation text Number of cmd ws no. HH.MM.SS Conds '''' GENN 099 00.00.01 0 '''' CPU1 001 00.00.01 JOBA 0 '''' CPU1 002 00.00.01 JOBR1 1 '''' CPU1 003 00.00.01 JOBR2 1 S''' CPU1 004 00.00.01 JOBB1 ******************************* Bottom of data ********************************

  33. Scenario 1 – Handle Conditions in database The operation detail panels show that we have only one condition defined on JOBB. Selecting option 1 Kevin go to BROWSING PREDECESSORS panel EQQABSDP ---------------- BROWSING OPERATION DETAILS -------------------------- Option ===> 1 Select one of the following: 1 PREDECESSORS - List of predecessors 2 WS RES AND SERVERS - Work station resources and servers 3 SPECIAL RESOURCES - List of special resources 4 AUTOMATIC OPTIONS - Job, WTO, and print options 5 FEEDBACK - Feedback options 6 TIME - Time specifications 7 OP INSTRUCTIONS - Operator instructions 8 JCL BROWSE - JCL browse 9 CLEANUP OPTIONS - Cleanup Options 10 EXTENDED INFO - Operation Extended Info 11 AUTOMATION INFO - System Automation Operation Info Application : APPLA Operation : CPU1 4 Duration : 00.00.01 Jobname : JOBB Number of int preds : 1 Number of ext preds : 0 Number of conds : 1

  34. Scenario 1 – Handle Conditions in database To display the Defined Conditions Kevin issues the COND command: EQQABPDL ------------------- BROWSING PREDECESSORS ----------- Row 1 to 1 of 1 Command ===> COND Scroll ===>PAGE Enter COND command to list the existing Conditions. Enter the row command S to select the description of an external predecessor. Application : APPLA Operation : CPU1 004 JOBB Row Oper Transport Application id Jobname cmd ws no. time (for ext pred only) 'GENN 099 ******************************* Bottom of data ********************************

  35. Scenario 1 – Handle Conditions in database The COND command lead to panel EQQABCCL where Kevin can see the list of Conditions defined on JOBB: Selecting the only one defined Kevin goes to display the Condition details NEW EQQABCCL ------------------- BROWSING CONDITIONS ----------- Row 1 to 1 of 1 Command ===> Scroll ===>PAGE Enter the row command S to select the description of a Condition: Application : APPLA Operation : CPU1 004 JOBB Row Cond Condition Descriptions Dep Condition Rule cmd no. no. S001JOBA or JOBR1 or JOBR23 At least one of ******************************* Bottom of data ********************************

  36. Scenario 1 – Handle Conditions in database Kevin check that the Browse Condition correctly shows 3 Simple conditions chained in OR (At least one of … is the rule) NEW • EQQABCCP ----------- BROWSING CONDITION DETAILS --------------- Row 1 to 1 of 1 • Command ===>Scroll ===>PAGE • A Condition is made by a list of condition dependencies related by a rule. • Each Dependency is defined on a Status or Return Code value through operators: EQ, NE, GE, GT, LE, LT, RG. • Application : APPLA • Operation : CPU1 004 JOBB • Condition Rule: At least one of following list must be true • Oper Application Id Jobname Cond Cond Status Return Code • ws. no. (for ext Adid only) Type OP Value Value1 Value2 Oper CPU1 001 JOBA ST EQ C • CPU1 002 JOBR1 ST EQ C • CPU1 003 JOBR2 STEQ C • ******************************* Bottom of data ********************************

  37. Scenario 2 • Focus on: • Define an operation as ‘recovery job’ in database

  38. Scenario 2 – Define an operation as ‘recovery job’ • Kevin has defined APPLA as we have just seen in previous slides. • Now he has a problem: • how to automate the removal of an instance of APPLA in the current plan whenever JOBA ends in error but a recovery job (e.g. JOBR1) fixes the problem so that JOBB can be run successfully? • SCENARIO 1 • JOBA runs and completes • JOBR1 is set to suppressed by condition because its condition is false. • JOBR2 is set to suppressed by condition because its condition is false. • JOBB runs and completes as its condition become true as soon as JOBA completes. • Final statuses of operations are: • DMY 099 C Complete • CPU1 001 JOBA C Complete • CPU1 002 JOBR1 X Suppressed by condition • CPU1 003 JOBR2 X Suppressed by condition • CPU1 004 JOBB C Complete • The occurrence is set to C status and will be removed from the plan at next extension.

  39. Scenario 2 – Define an operation as ‘recovery job’ • SCENARIO 2 • JOBA fails with RC = 4 • JOBR1 runs and completes because its condition becomes true. • JOBR2 set to suppressed by condition because its condition becomes false. • JOBB runs and completes as its condition become true as soon as JOBA completes. • Final statuses of operations would be: • DMY 099 C Complete • CPU1 001 JOBA E Error RC = 4 • CPU1 002 JOBR1 C Complete • CPU1 003 JOBR2 X Suppressed by condition • CPU1 004 JOBB C Complete • The occurrence is set to E status and for this reason is not removed from plan at next extension. • But from Kevin point of you the JOBA failure has been recovered so that the occurrence could be removed. • To obtain this Kevin can define JOBR1 and JOBR2 as ‘recovery jobs’, meaning: • If JOBA ends with an error code matching the condition defined for a • recovery job, ignore the error for occurrence removal.

  40. Scenario 2 – Define an operation as ‘recovery job’ Kevin set the recovery job field to Y to say: if JOBA ends in error and is recovered by JOBR1, JOBA can be removed from the plan EQQAMJBP ---------------- JOB, WTO, AND PRINT OPTIONS ------------------------- Command ===> Enter/Change data below: Application : APPLA Operation : CPU1 002 JOBR1 JOB CLASS ===>_ Job class of corresponding job ERROR TRACKING ===>Y Y means error automatically tracked HIGHEST RETURNCODE ===>____ Highest return code not in error EXTERNAL MONITOR ===> N Job monitored by external product (Y/N) CENTRALIZED SCRIPT ===>N Centralized script Y/N (for FTW only) RECOVERY JOB ===>Y Recovery job for a cond predecessor (Y/N) CRITICAL ===>N Critical job: N P W POLICY ===> _ CLASS ===> ________ WLM Policy and Service Class Job release options: Answer Y or N for options below: SUBMIT ===>Y Automatically submitted HOLD/RELEASE ===>Y Automatically held and released TIME DEPENDENT ===>N Run the job at specified time SUPPRESS IF LATE ===>N Suppress the job if not on time DEADLINE WTO ===>N Deadline WTO, Y or N WS fail options: RESTARTABLE ===>_ Operation is restartable REROUTEABLE ===>_ Operation is eligible for reroute Print options: FORM NUMBER ===>________SYSOUT CLASS ===>_

  41. Scenario 2 – Define an operation as ‘recovery job’ Kevin browse the operation after the setting of new field: EQQABJBP ----------- BROWSING JOB, WTO, AND PRINT OPTIONS --------- Command ===> View data below: Application : APPLA Operation : CPU1 2 Job name : JOBR1 Job class : Error tracking : Yes Highest return code : External monitor : No Centralized script : No Recovery job : Yes Critical : No WLM Class : WLM Late Job Policy : Deadline WTO : No Job release options: Submit : Yes Hold/release : Yes Time dependent : No Suppress if late : No WS fail options: Restartable : Rerouteable : Print options: Form number : Sysout class :

  42. Scenario 3 • Focus on: • Handle condition dependencies on Long Term Plan.

  43. Scenario 3 – Handle condition dependencies on LTP ADID=ZA ADID=ZR1 ADID=ZR2 CPU1 1 ADID=ZB CPU1 2 CPU1 3 CPU1 4 Cond 1 All true: Z1 CPU1 001 RC > 0 Z1 CPU1 001 RC >= 4 Cond 1 Cond 1 All true: Z1 CPU1 001 RC > 4 At least one of: Z1 CPU1 001 ST = C ZR1 CPU1 002 ST = C ZR2 CPU1 003 ST = C LTP shows only the external dependencies. For this reason our previous example with APPLA having all internal dependencies has no impact on LTP. But suppose to define a cloned situation using all different applications (ZA, ZR1, ZR2 and ZB):

  44. Scenario 3 – Handle condition dependencies on LTP ZR1 and ZR2 have 1 succ and 1 pred, both conditional ZA has 3 conditional successors: the Cond Pre and Cond Suc columns show the number of conditional predecessors and successors Kevin run an LTP extend with AD containing APPLA, ZA, ZR1, ZR2 and ZB with run cycle saying that they must run every day at 10.00. APPLA has no PRED and SUCC as expected: EQQLSTOL ----------- LONG TERM PLAN OCCURRENCES (left part) - row 1 to 10 of 10 Command ===> Scroll ===>CSR Enter the CREATE command above to create a new occurrence or enter the GRAPH command above to view occurrences graphically, or, enter any of the commands below: B - Browse, D - Delete, J - Job setup, M - Modify, RG - Remove from Group Row Application id Input arrival Deadline P C Pre Suc Cond Cond cmd date time date time Pre Suc ''' APPLA 08/04/29 10.00 08/04/29 23.45 1 N 0 0 0 0 ''' ZA 08/04/29 10.00 08/04/29 23.45 1 N 0 0 0 3 B'' ZB 08/04/29 10.00 08/04/29 23.45 1 N 0 0 3 0 ''' ZR1 08/04/29 10.00 08/04/29 23.45 1 N 0 0 1 1 ''' ZR2 08/04/29 10.00 08/04/29 23.45 1 N 0 0 1 1 ''' APPLA 08/04/29 10.00 08/04/29 23.45 1 N 0 0 0 0 ''' ZA 08/04/29 10.00 08/04/29 23.45 1 N 0 0 0 3 ''' ZB 08/04/29 10.00 08/04/29 23.45 1 N 0 0 3 0 ''' ZR1 08/04/29 10.00 08/04/29 23.45 1 N 0 0 1 1 ''' ZR2 08/04/29 10.00 08/04/29 23.45 1 N 0 0 1 1 ******************************* Bottom of data ********************************

  45. Scenario 3 – Handle condition dependencies on LTP Kevin issue the row command B to browse ZB Occurrence and EQQLBOCP panel is shown were the details about conditional one is displayed. At this point Kevin select option 2 to check Application dependencies: EQQLBOCP ------------------- BROWSING AN OCCURRENCE --------------------------- Option ===> 2 Select one of the following: 1 OPERATIONS - Browse operations 2 APPLICATION DEP - Browse dependencies (application level) 3 OPERATION DEP - Browse dependencies (operation level) Application : ZB Input arrival : 08/03/29 10.00 Deadline : 08/03/29 23.45 Owner : KEVIN Priority : 1 Error code : Variable table : Successors : 0 Conditional Succ: 0 Predecessors : 0 Conditional Pred: 3 Manually created : No Group Definition :

  46. Scenario 3 – Handle condition dependencies on LTP PC or SC indicate conditional pred and succ Kevin issues the row command B to browse ZB Occurrence and EQQLBOCP panel is shown were the details about conditional one is displayed. At this point Kevin select option 2 to check Application dependencies: EQQLBBDL ------------------- BROWSING DEPENDENCIES ----------- Row 1 to 1 of 1 Command ===> Scroll ===>CSR View data below: Application : ZB Input arrival : 08/04/29 10.00 Deadline : 08/04/29 23.45 Dep Application id Input arrival Complete Manually Deleted Type date time created PC ZA 08/04/29 10.00 N N N PC ZR1 08/04/29 10.00 N N N PC ZR2 08/04/29 10.00 N N N ******************************* Bottom of data ********************************

  47. Scenario 3 – Handle condition dependencies on LTP Kevin can delete/add normal predecessor or successors but cannot do this on conditional ones: EQQLCDPL ------------------- MODIFYING DEPENDENCIES ----------- Row 1 to 1 of 1 Command ===> Scroll ===>CSR Enter the CREATE command above to create a new dependency or enter any of the commands below: B - Browse, D - Delete Conditional predecessors/ successors cannot be created. Application : ZB Input arrival : 08/04/29 10.00 Deadline : 08/04/29 23.45 Row Dep Application id Input arrival Complete Manually Deleted cmd Type date time Created ' PC ZA 08/04/29 10.00 N N N ' PC ZR1 08/04/29 10.00 N N N ' PC ZR2 08/04/29 10.00 N N N ******************************* Bottom of data ********************************

  48. Scenario 4 • Focus on: Handle Conditions in CP • For a specific operation in Current Plan: • Display Conditional Predecessors / Successors • Display Defined Conditions • Add / Modify / Delete a Condition

  49. Scenario 4 – Handle Conditions in CP Kevin browses the operation APPLA CPU1 004 and from EQQSOPSP select option 4 to check related dependency info (conditional or not) EQQSOPSP SELECTING APPLICATION OCCURRENCE AND OPERATION INFORMATION ---------- Option ===>4 Select one of the following: 1 APPLICATION - Detailed application occurrence information 2 OPERATION - Detailed operation information 3 OPERATION LIST - Operations of the application occurrence 4 DEPENDENCIES - Immediate predecessor and successor information 5 RESOURCES - List of resources used by the operation 6 JCL - Browse the JCL 7 OPERATOR INSTR - Operator instructions 8 EXTERNAL DEPS - Immediate external dependencies of the occurrence 9 ALL DEPS - All dependencies of this operation 10 CLEANUP OPTIONS - Cleanup options 11 EXTENDED INFO - Operation extended info 12 AUTOMATION INFO - System automation operation info Application : APPLA Operation : CPU1 004 Jobname and jobid : JOBB JOB00245 Status of operation : Completed on Work Station : Priority of operation : 5 Planned input arrival : 08/04/28 11.11 Actual input arrival : 08/04/28 11.20

  50. Scenario 4 – Handle Conditions in CP X is the new status for suppressed by condition PC or SC indicate conditional pred and succ Kevin can see that JOBB has 3 conditional PRED and one normal PRED (GENN 099). APPLA run successfully: GENN 099 completed, JOBA run ok, JOBR1 and JOBR2 were consequently set to dummy complete (X) and JOBB finally run ok. EQQSPP1L -- PREDECESSORS AND SUCCESSORS TO AN OPERATION (left Row 1 to 4 of 4 Command ===> COND Scroll ===>PAGE Issue command COND to show list of defined Conditions. Scroll right or enter the row command S to select an operation for details. Application : APPLA Operation : CPU1 4 Jobname : JOBB Row Type Operation Jobname Application id Status cmd ws no. text ''' P GENN 099APPLA C ''' PC CPU1 001APPLA C ''' PC CPU1 002APPLA X '''PC CPU1 003APPLA X ******************************* Bottom of data ********************************

More Related