Zeke

ASG-Zeke for z/OS Users Guide
Version 5.4 Publication Number: AZM0200-54 Publication Date: March 2007
The information contained herein is the confidential and proprietary information of Allen Systems Group, Inc. Unauthorized use of this information and disclosure to third parties is expressly prohibited. This technical publication may not be reproduced in whole or in part, by any means, without the express written consent of Allen Systems Group, Inc. Copyright 2007 Allen Systems Group, Inc. All rights reserved. All names and products contained herein are the trademarks or registered trademarks of their respective holders. ASG Worldwide Headquarters Naples Florida USA | asg.com | info@asg.com 1333 Third Avenue South, Naples, Florida 34102 USA Tel: 239.435.2200 Fax: 239.263.3692 Toll Free: 800.932.5536 (USA only)
Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
About this Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Publication Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi Worldwide Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Intelligent Support Portal (ISP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii ASG Documentation/Product Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
Chapter 1:
Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
What is Zeke? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Zeke Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Zeke Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Processing Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 SMP/E Install Tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Online Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Calendars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 JCL Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 User JCL Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Dispatching Dependencies (WHEN conditions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Resource Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Condition Code Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Copying JCL and Documentation into the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . 12 Import/Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Work Center Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Forecasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Schedule Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 PolyZeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Continuous Tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Electronic Vaulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Audit Trail Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 How Zeke Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Day. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PolyZeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeke Interfaces to Other ASG Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-Zeke AgentsCross-Platform Schedule Download . . . . . . . . . . . . . . . . . . . . . . . ASG-Zeke Plug-ins for ASG-OpsCentral. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-ZaraAutomated Tape Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-ZebbRestart/Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-ZenaCross-Platform Job Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-IMPACTProblem Tracking Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-Cortex-Pdb Plug to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-JCLPREPJCL Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-JOB/SCANJCL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-PRO/JCLJCL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-Workload AnalyzerJob Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-Workload PlannerJob Planning When Scheduling . . . . . . . . . . . . . . . . . . . . . . Zeke Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version 5.3.1 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version 5.3.0 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version 5.2.0 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Version 5.1.0 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 18 18 21 21 22 22 22 22 23 23 23 24 24 24 25 25 26 26 33 35 39
Chapter 2:
Starting Zeke and Using the Online Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Starting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 Restarting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Starting OASIS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Starting Multiple Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 Terminating OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Terminating Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 ISPF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISPF Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Screen Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 57 58 59
ii
Contents
Chapter 3:
Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Calendar Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64 Accessing the Calendar Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Standard Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Special Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 User Accounting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Calendar Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Maintaining Scratch Pad or Note Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
Chapter 4:
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Defining Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Event Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Primary Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Accessing the Event Master Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 Defining an Event Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Creating an Event From a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Copying an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Maintaining a Job Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Routing a Job Event to Another System or Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 98 Downloading Jobs to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Maintaining a Message Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Maintaining Command Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Maintaining a REXX Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 Defining a Recurring or Permanent Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OCCURS Clause Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling Events on Holidays and Weekends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an OCCURS Clause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Job and Program WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WHEN Conditions for Multiple Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extended Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WEAK Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Started Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generic Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multiple WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeke Variables as WHEN Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOTDURING Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-platform Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WHEN Condition Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 118 126 130 132 135 135 135 136 137 138 138 139 140 142 144 145
iii
Defining a WHEN Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150 Viewing WHEN Conditions for All Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 151 Condition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154 Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variables in Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Completing Work Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 161 163 166
Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171 Maintaining Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Displaying, Enabling, or Disabling Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Maintaining JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Setting JCL Source Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176 Retrieving JCL from the Zeke Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Scratch Pad or Note Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Dataset Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181 181 184 185 186
Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Chapter 5:
Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 191

Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Day (48-hour Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the Zeke Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Zeke to Schedule Itself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Events to the Schedule As They Are Created . . . . . . . . . . . . . . . . . . . . . . . . . Schedules Downloaded to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How Zeke Determines Dispatching Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Forecasting and Simulating the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule View Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Other Online Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refreshing the Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sorting Schedule View Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Selecting Fields to Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the Date Display Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing and Maintaining WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Event Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Resources for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the ZOOM Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192 192 194 196 197 197 198 199 202 211 217 219 220 222 224 225 227 229 230
Maintaining JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Zeke PDS JCL Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

iv
Contents
Validating JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoking ASG-JCLPREP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Invoking JOB/SCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using ZSCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
236 237 239 241
Creating Your Own Line Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 ZCOM Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243 PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244 Manually Adding Events to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the ZADD Operator Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the ADD Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Events By Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250 250 252 255
Chapter 6:
Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261
Resource Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 Physical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How Initiator Processing Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activating Initiator Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Initiators to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Pools to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Logical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a Logical Resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Resources for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Resources for an Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262 263 267 269 272 274 275 277 281
Chapter 7:
Maintaining Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Changing Zeke Operating Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Accessing Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activating Variable Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dispatching Messages and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recognizing NOT-CAT2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Retaining Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Triggering Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pending Messages and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Schedule Download Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Loading the Work Center to SQT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calculating Tape Drive Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Checking the Dispatch Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining the Job Restart Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Networking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Inter-product Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 288 288 290 291 293 297 300 301 303 304 305 306 306 307 309
v
Using Shared Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dispatching Events After Zeke Start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Building EDB Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Obtaining Operating Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing ISPF Color Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
311 312 312 314 316
Using the Audit Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318 Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating the Zeke Databases (Primary and Vault) . . . . . . . . . . . . . . . . . . . . . . . . . . . . Backing Up the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Restoring the Zeke Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Moving the Vault Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Recovery Using Electronic Vaulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continuous Job Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating Zeke Using ZKILL TRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMF Recording Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMF Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320 320 323 324 326 328 331 331 332 335 335
Chapter 8:
Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Zeke Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Variable Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting OASIS Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Temporary OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338 338 338 343 347 348 349 350
System-Dependent Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 How Variables Are Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Variables to Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Variables to Control Jobstream Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Variables to Restart a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Substituting Variable Values in JCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . IF Clauses On SET Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variable Substitution in SCOM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351 352 353 354 356 359 359
Chapter 9:
Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361
Preparing for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362 Objects and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363 Security Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364 Security Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365 Processing Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367
vi
Contents
Tracing Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368 Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online Access: Logging On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Function Access: Class Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Record Access: Operator Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Batch Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Up Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeke External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Resource Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 370 370 371 371 372 382 383 386 387
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395
vii
viii
Preface
This ASG-Zeke for z/OS Users Guide explains the procedures for using ASG-Zeke (herein called Zeke) to schedule your system. This guide assumes that the appropriate components have been installed at your site.
About this Publication

This publication consists of these chapters:

Chapter 1, Introducing Zeke, introduces you to the basic concepts of using Zeke. Chapter 2, Starting Zeke and Using the Online Facility, explains how to start and log on to Zeke. Chapter 3, Calendars, describes the various types of calendars and how to use them. Chapter 4, Events, explains the components of an event master record (EMR) and how to create and modify them. Chapter 5, Creating and Monitoring the Schedule, provides sample JCL for creating the daily schedule and explains how to monitor the schedule with Schedule View or using the /ZCOM function, and intervene, if necessary. Chapter 6, Resources, explains the differences between physical and logical resources and how to use both for more efficient job processing. Chapter 7, Maintaining Zeke, explains how to create and maintain the Zeke database, as well as providing procedures for the most commonly changed generation options. Chapter 8, Variables, describes the different types of variables and provides examples. Chapter 9, Security, provides conceptual and procedural information for both internal and external security.
ix
Related Publications
The documentation library for Zeke consists of these publications (where nn represents the product version number):
ASG-Zeke for z/OS Enhancement Summary (AZM1000-nn) describes new Zeke features, updated functions, and performance improvements. ASG-Zeke for z/OS Users Guide (AZM0200-nn) explains the procedures for using Zeke to schedule your enterprise. ASG-Zeke for z/OS Installation Guide (AZM0300-nn) defines Zeke system requirements, provides instructions for installing Zeke, and explains the optional features you can activate after installing. ASG-Zeke for z/OS Reference Guide (AZM0400-nn) provides a reference for using Zeke batch programs and operator commands and for generating reports. ASG-Zeke Messages and Codes Guide (AZM1200-nn) lists the Zeke messages, describes their meanings, causes, and resolutions, and provides return code explanations. ASG-OASIS for z/OS Installation Guide (AZO0300-nn) provides information on installing ASG-OASIS (herein called OASIS), the framework for the ASG enterprise workload management products. ASG-OASIS for z/OS Reference Guide (AZO0400-nn) provides information on OASIS commands, options, and other functions.
Note:
To obtain a specific version of a publication, contact ASG Customer Support.
Preface
Publication Conventions
ASG uses these conventions in technical publications:
Convention Arrow ( Usage Used in a procedure to indicate commands within menus. Also used to denote a one-step procedure. Bold Indicates that case-sensitive usage is required for a directory, path, file, dataset, member, database, program, command, or parameter name. Verify the settings in the asg.conf file. Capitalization For system element names, this varies according to the product interface and its operating environment. Mainframe file names use uppercase, for example: Allocate a JSOPTEM member in the JLRCL library. Windows file names use mixed case, for example: Create a text file named SECLIST.txt in the C:\Program Files\ASG\config directory. UNIX file names use mixed case, for example: Edit the databaseID.ACC file in the /database directory. Typical product and operating system elements include: Directory, path, file, dataset, member, database, program, command, and parameter names. Window, field, field group, check box, button, panel (or screen), and option labels. Names of keys. A plus sign (+) is inserted for key combinations (e.g., Alt+Tab). lowercase italic monospace Monospace Information that you provide according to your particular situation. For example, you would replace filename with the actual name of the file. Characters you must type exactly as they are shown, such as code, JCL, file listings, or command/statement syntax. Also used for denoting brief examples in a paragraph. Underline Vertical separator bar ( | ) with underline Denotes a cursor-selectable field or line. Indicates options available with the default value underlined (e.g., Y|N).
xi
Worldwide Customer Support

ASG provides support throughout the world to resolve questions or problems regarding installation, operation, or use of our products. ASG provides all levels of support during normal business hours and emergency support during non-business hours. You can access support information at http://www.asg.com/support/support.asp. ASG Third-party Support. ASG provides software products that run in a number of third-party vendor environments. Support for all non-ASG products is the responsibility of the respective vendor. In the event a vendor discontinues support for a hardware and/or software product, ASG cannot be held responsible for problems arising from the use of that unsupported version.
Intelligent Support Portal (ISP)

The ASG Intelligent Support Portal (ISP) provides online support at http://isp.asg.com. Log on to the ISP with this information: Customer ID = NNNNNNNNN Password = XXXXXXXXXX where: NNNNNNNNN is your customer ID supplied by ASG Product Distribution. XXXXXXXXXX is your unique password supplied by ASG Product Distribution. If you do not have your logon information, contact your local support center. The ASG-Intelligent Support Portal User's Guide provides instructions on how to use the ISP and is located on the ASG Support Web page. Expected Support Response Time
Within 30 minutes Within 2 hours Within 4 hours
Severity
1 2 3
Meaning
Production down, critical situation Major component of product disabled Problem with the product, but customer has work-around solution How-to questions and enhancement requests
Within 4 hours
xii
Preface
ASG Documentation/Product Enhancements

Submit all product and documentation suggestions to ASGs product management team at http://www.asg.com/asp/emailproductsuggestions.asp. Include your name, company, work phone, e-mail ID, and the name of the ASG product you are using. For documentation suggestions, include the publication number located on the publications front cover.
xiii
xiv
Chapter 1:
Introducing Zeke
1
This chapter provides an overview of Zeke and contains these topics: Topic
What is Zeke? Zeke Terminology Zeke Features Processing Ability SMP/E Install Tapes Online Facility Calendars Events JCL Sources User JCL Exit Dispatching Dependencies (WHEN conditions) Resource Checking Pools Variables Condition Code Validation Auto Replies Copying JCL and Documentation into the Zeke Database Import/Export Work Center Facility Operator Commands Forecasting Schedule Simulation PolyZeke Continuous Tracking Electronic Vaulting Audit Trail Facility Report Writer How Zeke Works Schedule Time Logical Day PolyZeke
Page
3 3 6 6 6 6 7 7 9 9 10 10 11 11 12 12 12 13 13 13 14 14 14 14 15 15 16 17 17 18 18
Topic
Zeke Interfaces to Other ASG Products ASG-OASIS ASG-Zeke AgentsCross-Platform Schedule Download ASG-Zeke Plug-ins for ASG-OpsCentral ASG-ZaraAutomated Tape Management ASG-ZebbRestart/Recovery ASG-ZenaCross-Platform Job Dependencies ASG-IMPACTProblem Tracking Support ASG-Cortex-Pdb Plug to Zeke ASG-JCLPREPJCL Validation ASG-JOB/SCANJCL Validation ASG-PRO/JCLJCL Validation ASG-Workload AnalyzerJob Analysis ASG-Workload PlannerJob Planning When Scheduling Zeke Enhancements Version 5.3.1 Enhancements Version 5.3.0 Enhancements Version 5.2.0 Enhancements Version 5.1.0 Enhancements
Page
21 21 22 22 22 22 23 23 23 24 24 24 25 25 26 26 33 35 39
1 Introducing Zeke
What is Zeke?
Zeke is an automated scheduling product that controls events on one or more computers. An event can be a computer process or action, or an off-line, manual task. More specifically, a Zeke event can be any of the following:

A jobstream processed by the operating system A message issued to the console operator A Zeke operator or batch command A VM control program (CP) command A communication event that issues commands to the operating system and replies to queries generated by those commands A manual task, called a work center
For job events, Zeke reads and interprets event definitions, schedules the jobs for processing, initiates and terminates the processing of the jobs and job steps, plus records the output data. For work centers, Zeke schedules the completion of the manual tasks and enables them to interface with tasks performed on the computer.
Zeke Terminology
To help you understand Zeke concepts, an overview of basic scheduling terminology, as well as Zeke-specific terminology is provided (in alphabetical order). Auto Reply. Allows you to automatically respond to outstanding replies (WTORs) from your Zeke events that have static or predictable responses, or for job events that need to be maintained. Calendar. Calendars provide a way for you to customize your processing schedule. You simply set up one or two standard calendars to distinguish among workdays, weekends, and holidays. One standard calendar is all you need for most events. However, you can also create user accounting calendars to tie events to the periods of your accounting year and special calendars for those few events with random scheduling criteria. Condition Code Validation. Zeke can determine if a job should be cancelled or marked as abended based on condition codes (or return codes). The condition code can be set at the job or step level and is defined for an event through the online facility. Documentation Segment. This feature allows you to select the type of documentation you want to maintain by entering the appropriate criteria from a list of options to display one of the following types of documentation: scratch, note, dataset, or text.
3
Electronic Vaulting. Electronic vaulting provides the ability to maintain a second copy of the Zeke database that will be at most one I/O behind the primary. By maintaining a second copy on another DASD string, or even another site, an installation can improve recovery time if a hardware error occurs. Event. An event is a computer process, such as a jobstream, a command, or message. An event can also be an off-line task, called a work center, that once completed will trigger other system-related events. Event Master Record (EMR). When you define events to the Zeke database, an event master record (EMR) is created that contains certain information, such as the date the event is to be scheduled, prerequisite conditions for dispatch, and resource requirements. Zeke uses these records to create the daily schedule. Logical Day. A logical day associates events that run in the early morning hours with the previous days schedule. This allows events that belong to a given day to be associated with that day, even though their schedule time actually lies outside the 24 hours of the given day. Logical Resource. Logical resources can be anything you want to define to represent the use of a physical resource such as the entire CPU, a specific CPU channel, a file, or a dataset. Logical resources are used for events, that if executed simultaneously, might cause contention among your systems resources. OCCURS Clause. An OCCURS clause is a statement that determines when the event should be added to the schedule. It is comprised of keywords, such as DAILY, WORKDAYS, MONDAY, JANUARY, WEEKENDS, and HOLIDAY that indicate when to schedule events. PathFinder. PathFinder shows all predecessor and successor relationships for any given event. This display is accessed through Schedule View (available through ISPF only) or by issuing a Zeke operator command. You can analyze at a glance what needs to occur before a job can run and what will happen after. Additionally, PathFinder can help you uncover predecessor loop conditions. Schedule Queue Record (SQR). When the SCHEDULE function creates the daily schedule, it uses the EMR information to create temporary records for each scheduled event. These records, called schedule queue records (SQRs), can be modified for that particular run, without affecting the permanent EMR. Schedule View. Schedule View, available only through ISPF, displays all the events currently scheduled. Schedule View presents all relevant schedule information on a single screen. And from this one screen, you can monitor the current schedule, and make changes to any of the fields.
1 Introducing Zeke
Additionally, all messages from a jobs JOBMSG and SYSMSG files can be displayed to aid in problem resolution and speed the restart process. Schedule View also allows access to JCL for one-time overrides. This allows authorized users access to a copy of the executable JCL to update parameters and correct abends. The updated copy is then attached to the events schedule entry for subsequent runs. You can choose color schemes for your displays, select the screen update interval, and determine your own field column layout, sort sequences and selection criteria. Security. Zeke offers two approaches to security: internal securityZekes own facility for securing access to Zeke records and functions; and external security which interfaces to any security package that supports SAF (System Authorization Facility). You can also use a combination of internal and external security to provide optimum protection. Simulation. Simulation creates a forecast of your schedule to uncover any missing prerequisites and help you plan a logical schedule flow. Simulation performs many of the same functions as Zeke, such as specifying tape drive and initiator quantities, reporting, and message generation, all without affecting the actual schedule. System Pooling. Multiple CPUs (real and virtual) can share one Zeke database. Every event is owned by one of the systems sharing the database. Sometimes an event is not limited to just one system. For those events, you can define a group of systems, known as a pool. Zeke selects which system to use for each event based on the system or pool defined for the event. Variable. A Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned value of either numeric or character format. Variables allow Zeke to automatically carry out a variety of specialized operations, such as automating JCL modifications, triggering event scheduling and dispatching, and responding to console data. Version. This term refers to multiple SQRs with the same schedule date. An event can have up to 32,767 versions. Each version of an event shares the same OCCURS clause, but can have a different WHEN condition defined for it. Most Zeke operator commands can select events by version number for processing, and WHEN conditions can trigger off of version numbers. WHEN Condition. A WHEN condition is a statement that contains prerequisites that must occur before the event can be dispatched. Similar to OCCURS clauses, WHEN conditions use keywords, such as EOJ, that indicate when to dispatch events. Work Center. Work centers are useful when manual intervention is required before a job can run. Work centers allow you to communicate directly with the schedule. Users can add, alter, and control events without filling out a form, making a phone call, or writing a note to an operator.
Zeke Features
This section provides an overview of some of Zekes key features.
Processing Ability
Zeke can schedule up to 24 computer systems from each Zeke database. Any combination of VSE, CMS, and z/OS systems can share a database. This multi-system support enables multiple operating systems to communicate about events occurring on one system that might affect the events on another system. Zeke can schedule system commands (SCOMs) as well as jobs. System commands include Zeke commands and VM (CP) commands. SCOM events can awaken CICS and issue CICS commands. As part of the communications system, machines sharing a Zeke database register at start-up and check out at termination. Machines that are stopped are forced off of the machine bit mask. When the machine becomes active again, recovery is automatic. A CPU ID (bit mask) is assigned to each machine during the registration and check out process. The number of active communications records depends on the volume being passed between multiple machines.
SMP/E Install Tapes

Sites can install Zeke using the SMP/E or non-SMP/E procedures, and maintenance is provided in both formats.
Online Facility
The Zeke online facility is a full-screen, menu-driven system that makes scheduling maintenance easy. The Zeke online facility runs under several environments:

CICS IDMS CMS TSO ROSCOE ISPF
1 Introducing Zeke
The Zeke online facility contains complete security, allowing only authorized users to access the scheduling database. Additionally, it allows definition of different levels of access for each authorized operator.
Calendars
An event can be scheduled by any of the following calendars: Calendar Type
Standard Special User Accounting
Description
Used for defining workdays, non-workdays, and holidays. Used for specifically identifying the schedule dates for an event. Used for defining a calendar that matches your accounting periods.
You can specify generic years on all calendars. For example, 07/04/**** means July 4th of any year.
Events
Event Templates
This feature allows you to set up model events to use when creating new events of the same type (such as job events). When you create an event from a template, all of the templates information is copied over to the new eventincluding documentation, JCL, OCCURS clause, and WHEN conditions. A template is basically a normal event, except that it can never be scheduled.
Multiple Schedule Queue Records (Versions)

Allows you to have multiple SQRs (versions) with the same schedule date. An event can have up to 32,767 versions. Each version of an event shares the same OCCURS clause, but can have a different WHEN condition defined for it. Most Zeke operator commands can select events by version number for processing, and WHEN conditions can trigger off of version numbers. You can also create a new event by copying an existing one; however, you have to know the event number. Templates simplify this function. All you need to know is a template name. There is no limit to the number of templates that can be defined for each event type.
Recurring, Permanent, and Milestone Events

An event can be defined to occur multiple times within the same schedule run. These events are referred to as recurring events. You define the frequency or time interval and the specified number of times. A recurring event can trigger another event each time it runs, or it can be set to trigger only on the first or last occurrence. A permanent event is never removed from the schedule so that it is always available to respond to triggers, even during schedule load processing. The event occurs across every schedule period until you deactivate it. A milestone event is a significant event in a job flow (in which events have predecessor/successor relationships) that must process on time in order to avoid a significant delay in the completion of the entire flow. Events flagged as milestones are not processed any differently than other events; this flag is simply a way to easily identify events that you consider to be milestones in a job flow. (For example, in OpsCentral you can filter events based on this designation.)
Non-executable Events
An event can be defined as non-executable. Non-executable events are scheduled like any other event, and are useful as predecessors to other events. A non-executable event is never submitted to JES for JCL execution. After dispatch, the event status automatically changes to indicate success and any dependent events are triggered. An event that is part of an intricate event flow can be marked as non-executable (in the EMR, from Schedule View, or using an operator command) without having to change the event flow. This eliminates the need for deleting an event and changing all of its successors WHEN clauses.
Routing Job Events to Other Platforms

Using the EMR fields Platform and Target, Zeke can dispatch job events for processing across systems and on other platforms.
Event Documentation
Zeke provides for full documentation of an event through the following facilities:
Text facility, which retains a sizeable amount of text (up to approximately 450 records) Scratch pad and note facilities, which provide an easy method for leaving short notes for the operations personnel about a job Dataset facility, which displays the volume serial numbers and datasets required to run a job
1 Introducing Zeke
On-Demand, On-Request Events

Requested events can be defined as events in the Zeke database and added by operator command to the schedule. Zeke dispatches these events as if they were normally scheduled, including checking of prerequisites and resource requirements.
JCL Sources
Zeke can retrieve JCL from any of the following sources:

Bim-Edit Librarian Condor Panvalet VM/CMS File Zeke JCL CA-Driver JCLMAN Vollie VSE/POWER SLI ICCF OWL
User JCL Exit

Zeke provides a user JCL exit that can add, review, modify, or delete JCL statements at submission time. The user exit can also place a hold on the job event.
Dispatching Dependencies (WHEN conditions)

Zeke can make dispatching of an event contingent upon any combination of the following circumstances:
Normal or abnormal end for: A job A job step A program An event A group of events
Beginning of a job or program Close of an output non-VSAM dataset, if DISP=NEW Current execution of a job or program Availability of variables or resources
Zekes cross-system triggering ability allows Zeke to satisfy WHEN conditions based on a job running on another system (mainframe or non-mainframe).
Extended Dependencies
Two WHEN conditions, XEOJ and XEOE, provide the ability to trigger jobs across multiple schedules. For example, say JOB_A is dependent on JOB_B, which ran a few weeks ago. The XEOJ keyword can be used to locate the JOB_B in the Zeke database and determine whether it has run since the last time JOB_A ran.
Resource Checking
Zeke checks resource availability before an event is dispatched. Physical resources, such as number of tape drives and initiator class, are defined as part of the EMR. Logical resources are user-defined in the Zeke database. Zeke allows you to specify the days and times each initiator is available for processing. Up to six initiator classes can be defined for each job event. Zeke dispatches a job event to an initiator that processes one of the named classes. If a class is not specified, Zeke selects an appropriate class for the job at dispatch time. As part of the resource requirement checking, Zeke ensures that there are the correct number of tape drives available before dispatching a job. Zeke also compares resource names across systems to prevent multiple events from using the same resource.
10
1 Introducing Zeke
Pools
Zeke can select the system a job will run on, in addition to selecting the initiator within that system. Pools allow the user to establish groups of systems. For example, pool 1 may include systems A, B, and F. An event defined to run on system 1 (rather than system A, B, or F) is dispatched by Zeke on the first available system within the pool. This prevents one system from being idle while another may be overloaded with jobs.
Variables
Zeke Variables
Zeke provides powerful tools, variables, which perform the following functions:

Controlling jobstream flows (bypassing segments) Triggering other events Preventing other events from occurring Documenting cancellation reasons Substituting values in OS and JES JCL statements at execution time
Variables establish relationships between events. For example, when a work center is signed off as complete, it sets a variable telling Zeke that certain jobs can be run. Variable substitution is performed on all jobstream statements submitted by Zeke, including JCL and data statements. When a jobstream is submitted, Zeke scans it for variables and substitutes the current values. Variable substitution also occurs in WHEN conditions during batch schedule build and during ZADD processing. For example,
WHEN EOJ PRDAA$(CYCLE)
If the value of the OASIS CYCLE variable is 09; this number is substituted into the dependency, and the jobname becomes PRDAA09. A feature in the ZEKESET batch program allows extensive date manipulation and calculation using Zeke variables. This provides the ability to create any desired format based on dates. When used with the variable substitution support (Subdata), this facility can automatically create program date cards.
11
OASIS Variables
OASIS variable values can be substituted in the same areas as Zeke variables (JCL, ZEKESET, SCOM, etc.). The value substituted into an OASIS variable can be based upon a qualifierjobname, schedule date, run date, Netregid, system, application ID, group ID, user ID, event number, or version number. This allows for multiple values for a single variable name. OASIS variables reside in an OASIS database on DASD, and are therefore retained across system outages and IPLs. The database is accessible to all applications using the same OASIS/HSI subsystem, so you can use OASIS variables to communicate information between your applications. OASIS has its own online facility for maintaining variables. Refer to your ASG-OASIS for z/OS Reference Guide for more information.
Condition Code Validation

Condition code validation can be specified for each job event. A master record can include an unlimited list of condition codes to be checked during the processing of that job. If the specified condition codes are met, the specified action (cancel, fail, etc.) is taken.
Auto Replies
You can pre-define replies to common messages from events using the Automatic Reply function. When a message and subsequent console read is issued, Zeke responds to the console read with the pre-defined reply, substituting any variables before the reply is issued.
Copying JCL and Documentation into the Zeke Database

JCL and documentation can be copied from an outside source into the Zeke database using the ZEKE batch utility program. This eliminates having to re-key any JCL or documentation that a user wishes to store in the Zeke database.
12
1 Introducing Zeke
Import/Export
Zekes import/export utility allows you to:

Export event (EMR) and variable (VAR) database records as XML data. Import EMR and VAR XML records into the Zeke database. Change key values of EMR and VAR records being imported or exported.
Filtering control statements allow you to select which records to import or export. Change control statements allow you to change fields within the records being imported or exported.
Work Center Facility

Zeke provides an online list of scheduled work centers for each person responsible for signing off or completing an off-line event. The Work Center facility performs the following functions:

Relates off-line tasks to online tasks Allows online review and update of work centers Produces online lists or batch reports of work centers by user ID Sets new variable values when the work center is completed Triggers other events when the work center is completed
To set up a work center, you create a work center and associate it with a user ID. This user ID specifies the person responsible for the event. Enter a ZDISPLAY command to list the work centers by user ID. When the user flags the event as complete, it is removed from the display, new variables are set, and any related events are triggered.
Operator Commands
A full range of operator commands can be entered through any authorized OS console, similar to JES commands, or through the online facility. These commands allow the operator to do such things as:

Determine if and why an event has not been dispatched Change priority Display and modify current schedule
13
Forecasting
You can produce a schedule report for any future date without affecting the status of the current schedule.
Schedule Simulation
Zeke can simulate the schedule function to generate a sample schedule for any future date. Schedule Simulation lists a flow of events as if the events were actually run. You specify the date, time, system ID, and resources in the simulation JCL, then run the simulation job separate from the Zeke program. The Zeke database is copied to another dataset, then the flow of events is simulated against that dataset.
PolyZeke
Allows multiple copies (and different releases) of Zeke to run simultaneously on a single operating system. Each Zeke can reference a separate database or they can all share one database. For more information, see PolyZeke on page 18.
Continuous Tracking
Zeke can monitor system activity and update schedule tables after Zekes address space is terminated. Zeke can track certain relevant system and event activity, even during periods when both Zeke and the OASIS subsystem have been terminated, for example, to apply maintenance. When Zeke, and event OASIS, are terminated, the system activities are recorded. When Zeke is restarted, the logged activities are basically played back, and the schedule is updated accordingly. Activity that can be tracked includes:

Starting of jobs, job steps, and programs Ending of jobs, job steps, and programs Datasets that are closed Because these activities are recorded, Zeke will be able to mark jobs that have ended and also satisfy triggers for any jobs that might have completed while Zeke and/or OASIS was shut down.
14
1 Introducing Zeke
Electronic Vaulting
Zeke provides dual DASD I/O writing for sites that have or are planning the implementation of a disaster recovery plan. This provides two options for designing a recovery plan:
Use a backup of the Zeke database and perform a database restore in the event of a disaster. Allocate a secondary DASD unit to replicate the Zeke database. When a record is written to the primary Zeke database, the electronic vaulting option writes a duplicate record to the secondary vault dataset.
Audit Trail Facility

The Audit Trail facility tracks Zeke database activity and logs the information in the Audit Trail facility. You define the actions logged through the /Options function of the online facility. You can also generate Audit Trail reports through the Report Writer facility. Actions you can log include operator commands that are issued from the console and the online facility along with any changes to the following:

Event status (beginning of job, end of job, etc.) Variable value EMR Internal security class record Calendar record External security class definition record Resource definition record Generation option Your company name or address Internal security operator record Password Partition or initiator definition Pool record SQR
Refer to your ASG-OASIS for z/OS Reference Guide for more information.
15
Report Writer
The Report Writer facility allows you to customize your own reports for the Zeke database. This is in addition to the standard reports. You can select the following items for each report.

Fields Sequence Schedule records Selection criteria EMRs
16
1 Introducing Zeke
How Zeke Works

Zeke maintains a database of events that need to run in a data center. The events are defined to the Zeke database through the online facility or the batch utility program. The database retains the following information about each event in the event master record (EMR):

Detailed scheduling information (OCCURS clause) Prerequisite conditions (schedule time, WHEN conditions) Resource requirements (number of tape drives, initiator class)
This information ensures that an event is scheduled properly and is not dispatched until the prerequisites have occurred and the required resources are available. The EMRs are used by the SCHEDULE function to create a processing schedule for each system. The schedule function, typically run at the start of each workday, removes the previous day's completed events and adds the current day's events. Events are added to the schedule when either of the following occurs:

The scheduling criteria is met An operator request is entered
Zeke monitors computer activities to detect actions that will trigger an event. When an event's scheduled time is reached (TIME satisfied) and prerequisites have occurred (WHEN satisfied), the event is placed into the dispatch queue. Zeke dispatches the event when an initiator is available, resources are available, the event and system are not on hold, and operator approval is given. Operator approval is an optional dispatch requirement that can be placed on an event.
Schedule Time
Schedule time is an optional dispatching prerequisite that must be met before an event can be dispatched. Schedule time fields available on the EMR include Sched, Early, Late, Mustend, and Notafter (see Specifying a Schedule Time on page 96). If the time the event is dispatched does not matter, leave these fields blank (00:00). However, if the event must be dispatched by a certain time or cannot be dispatched after a certain time, use the schedule times fields to place restrictions on the time of day an event can execute.
17
Logical Day
Zeke supports a 48-hour clock, which lets you schedule according to a logical day. If you have events that run past midnight, you can still consider those events to be part of the previous days schedule run. When the SCHEDULE function runs, it selects every event within 48 hours to be part of the day's schedule. For example, if the schedule runs on Monday at 08:00, events are selected if the OCCURS clauses match Monday and the schedule time is between 00:00 and 47:59. An event with a schedule time of 48:00 is never dispatched because 47:59 is the cutoff time for dispatching. Use a schedule time of 48:00 for events that you want to place in the schedule, but do not want to dispatch except by operator command.
PolyZeke
PolyZeke enables you to run multiple copies (and different releases) of Zeke on a single CPU. The default subsystem name that identifies the OASIS subsystem is SSSI, but you can use a different subsystem name if desired. You can have multiple copies of OASIS with different subsystem names, executing in common storage (ECSA/CSA) to support multiple copies of Zeke. (Refer to your ASG-Zeke for z/OS Installation Guide for more information.) This facilitates testing a new release on a single CPU or supporting multiple users with separate Zeke databases. Each Zeke must be running under a separate OASIS subsystem. Each subsystem should use a unique command prefix to allow commands to be targeted to a particular Zeke. We recommend every system run with generation option Posid=YES. See Maintaining Networking Options on page 307 for information about setting the Posid generation option. Each Zeke should have a unique system name, even though they share an OS. Each Zeke is associated with its own SMF exits. For example, if there are three Zekes running on a system, there will be at least three of each SMF exit, with each getting control serially. You assign each OASIS subsystem a command prefix. Commands can be targeted to a specific system using this prefix. Messages will be issued with the prefix, so you can determine which system issued the message. If a unique CMD prefix is not specified for any or all systems running on a system, then any Zeke commands issued on the system with the common Z prefix will be processed by all copies of Zeke on this OS that do not have a unique prefix defined. Jobs running on the system will be seen by the SMF exits of every system. How each Zeke processes, based on any one job, will be determined by the Trigjob generation option setting for that system.
18
1 Introducing Zeke
Caution! Multiple Zekes on the same system should be configured to reference separate databases. If all Zekes are at the same release level, they can share a database, but ASG strongly recommends against database sharing between multiple Zekes on the same LPAR. In this configuration, Zeke is not guaranteed to function properly with respect to recurring events, refreshing schedule records, and Zebb restart.
Testing a New Release

With a second subsystem, you can test a new PTF or release level on the same CPU during normal working hours without affecting the production environment and without terminating other applications. The second subsystem allows the same applications to access more than one database. For example, a customer on a production Zeke 5.3 release can allocate a second database (possibly for testing or for production usage) and test the Zeke 5.4 release, without affecting the 5.3 production system. This is shown in Figure 1.
Figure 1 Using PolyZeke for Testing a New Release
OASIS 260A SSSI
OASIS 270A SSSX
Zeke 5.3
Zebb 3.1
Zeke 5.4
Zeke Production Database
Zebb Production Database
Zeke Test Database
ISPF User
ISPF User
19
Support Multiple Application Databases

It is possible to supply end users with a separate Zeke system. This de-centralizes Zeke while isolating end users from viewing or possibly corrupting other production databases. This concept is illustrated in Figure 2.
Figure 2 Using PolyZeke for Supporting Multiple Databases
OASIS 270A SSSA
OASIS 270A SSSI
OASIS 270A SSSB
OASIS 270A SSSX
Zeke 5.4
Zebb 3.1
Zeke 5.4
Zeke 5.4
Zeke 5.4
Zeke Production Database #4
Zebb Production Database
ISPF User
20
1 Introducing Zeke
Zeke Interfaces to Other ASG Products

The following ASG products complement Zeke:

ASG-OASIS for common functions of Zeke, ASG-Zebb, and ASG-Zara ASG-Zeke Agents for a mainframe-centric approach to enterprise scheduling ASG-Zeke Plug-ins for OpsCentral for centralized management of enterprise scheduling workloads ASG-Zara for automated tape management ASG-Zebb for automated job restart/rerun ASG-Zena for distributed workload management and process automation ASG-IMPACT for complete IT service management ASG-Cortex-Pdb (production database) for documenting application objects and attributes ASG-JCLPREP for JCL management ASG-JOB/SCAN for JCL management ASG-PRO/JCL for JCL management ASG-Workload Analyzer for job analysis ASG-Workload Planner for job planning when scheduling

ASG-OASIS
OASIS/DMSCommon Functions
OASIS provides common functions for Zeke, ASG-Zebb, and ASG-Zara. OASIS/Distributed Management Server (herein called DMS) allows Zeke to communicate with other Zekes running on different systems or platforms, as well as enabling cross-platform scheduling using ASG-Zeke Agents for Windows, OS/400, and UNIX to name a few.
21
OASIS/ESISAF Security
Zeke supports SAF security through the OASIS External Security Interface facility (ESI). ESI provides the ability to use a third-party security product such as RACF or CA-ACF2 to control access to Zeke or other installed OASIS-supported products.
ASG-Zeke AgentsCross-Platform Schedule Download

Zeke allows you to download a subset of scheduled jobs in the Zeke schedule, cross-platform, to Zeke Agent. Zeke Agent then tracks and dispatches the SQRs in the same manner as Zeke would. Zeke Agent satisfies the time and when conditions for the downloaded jobs and dispatches the jobs when those conditions are met. The downloaded schedule can run stand-alone on Zeke Agent, even when the OASIS/DMS connection to Zeke is interrupted, as long as Zeke Agent can satisfy the predecessors for the SQR locally. Zeke can schedule and dispatch specified job events to be sent one at a time to a Zeke Agent system running on another platform. Zeke Agent can receive, track, schedule, execute, and re-route the jobs from Zeke (or another source) to another system, as necessary.
ASG-Zeke Plug-ins for ASG-OpsCentral

ASG-OpsCentral (herein called OpsCentral) is the cross-platform, graphical enterprise management console for managing Zeke schedules from a client workstation. The ASG-Zeke Plug-ins for ASG-OpsCentral maintain communication between your Zekes and OpsCentral and enable Zeke functions to be available under the OpsCentral client console.
ASG-ZaraAutomated Tape Management

ASG-Zara is an online media management system which secures, audits, and monitors valuable IT data in a z/OS environment, while providing real-time access to tape management data.
ASG-ZebbRestart/Recovery
The online facility can interface with ASG-Zebb (herein called Zebb) or third-party restart package through Schedule View. You can then specify the necessary restart parameters, including what type of restart should be performed after the restart package's database is updated. Zeke uses OASIS to communicate event changes (additions, deletions, and schedule record status changes) to Zebb so that Zebb can make the appropriate changes to its database. Likewise, Zebb uses OASIS to communicate back to Zeke.
22
1 Introducing Zeke
ASG-ZenaCross-Platform Job Dependencies

Zeke communicates via Zeke Agent for Windows with ASG-Zena (herein called Zena), the distributed job scheduling solution. Zeke uses Zeke Agent to communicate any cross-platform job dependencies to Zena. A Zeke job can have a WHEN condition that is based on the status of Zena job or process. Likewise, Zeke jobs can trigger jobs scheduled on Zena. Refer to your Zeke Agent and Zena documentation for more information on how cross-platform job dependencies are defined and satisfied.
ASG-IMPACTProblem Tracking Support

Zeke provides problem tracking support through a user exit to interface with ASG-IMPACT Consolidated Service Desk (herein called IMPACT), or by interfacing with third-party problem tracking systems. The problem tracking interfacing user exit is called and a tracking record is produced for each abnormal end-of-event (AEOE), abnormal end-of-job (AEOJ), abnormal end-of-program (AEOP), and abnormal end-of-step (AEOS). For IMPACT, when an event ends abnormally, the exit calls IMPACT and issues an open command consisting of the command ZEKJOB followed by the jobname and the event number. You can set up the exit to assign tickets to different people or groups based on jobnames. Refer to your ASG-Zeke for z/OS Installation Guide for more information.
ASG-Cortex-Pdb Plug to Zeke

ASG-Cortex-Pdb documents application objects and attributes in a production database that is compatible with any hardware or software environment. It is also a powerful compiler that generates standardized JCL and process flows. For example, it generates procedures, parameter streams, and job scheduling information for multiple environments (tests, acceptance, production, etc.) and platforms (z/OS, UNIX, etc.). In addition, Cortex-Pdb streamlines the process of moving your application JCL or other command language into production. The Zeke module ZEKEXAPI enables Zeke to bridge to Cortex-Pdb.
23
ASG-JCLPREPJCL Validation
Zeke provides several ways to scan the JCL associated with your jobs events for accuracy. ASG-JCLPREP (herein called JCLPREP) interfaces with Zeke through the Schedule View line command JPREP. JCLPREP also can be invoked while editing the event JCL from the Schedule View ZOOM display by issuing the JCLPREP edit macro FPREP. In addition to JCLPREP, you can also scan JCL using the Schedule View line command ZOOM, the JCL primary command, the Schedule View line command SCAN, or the ZSCAN operator command. Zeke also interfaces with ASG-JOB/SCAN (see below) using the Schedule View line command JSCAN. The ZSCAN operator command and SCAN line command do not require installation or customization. Refer to your ASG-Zeke for z/OS Users Guide for information on how to use the commands. Refer to your ASG-Zeke for z/OS Installation Guide for implementation instructions for the other methods.
ASG-JOB/SCANJCL Validation
ASG-JOB/SCAN, a JCL validation and standards enforcement product, helps single LPAR data centers (with COBOL or Assembler expertise for JCL standards programs) operate an error-free production JCL environment. Maintaining JCL throughout its lifecycle is vital to any IT operation, but especially important when running mission-critical applications driven by z/OS JCL. Using ASG-JOB/SCAN, the operator can eliminate costly reruns, meet service level agreements, automatically enforce site standards, reduce backlog at production turnover, and improve the overall JCL maintenance cycle. Zeke interfaces with ASG-JOB/SCAN using the Schedule View line command JSCAN.
ASG-PRO/JCLJCL Validation
ASG-PRO/JCL is an advanced JCL validation and standards enforcement product that helps multiple LPAR data centers (with REXX expertise for JCL standards programs) achieve and operate a production JCL environment that is error-free, standardized, and optimized. See the ASG-PRO/JCL Reference Guide for instructions on establishing the interface.
24
1 Introducing Zeke
ASG-Workload AnalyzerJob Analysis

ASG-Workload Analyzer is a PC-based analysis tool that tracks and analyzes batch window processing performance, detects problem areas, and presents an analysis of processing in a graphic format that is easy to understand. Workload Analyzer saves data center staff from time-consuming data analysis. Specifically, it displays executed jobs and identifies where jobs were abended or where time was lost. It graphically captures job runtime data from the system management facility, thereby expediting analysis of processing trends, resolving bottlenecks, and improving operational productivity in a z/OS environment.
ASG-Workload PlannerJob Planning When Scheduling

ASG-Workload Planner gives data center staff the ability to better understand complex schedules from a variety of mainframe scheduling systems. In addition, it helps staff forecast future scheduling performance. Workload Planner takes complex information contained in a scheduling system database and translates it into interactive graphic flowcharts. Forecast information, also collected from the scheduling system, is used to create a series of graphs that predict the performance of scheduled processing. Workload Planner provides a comprehensive flowchart of all scheduled jobs. By changing timing information, the addition or removal of jobs to and from a schedule is also modeled. This function allows you to simulate what-if scenarios to gauge the impact of changes on batch window processing.
25
Zeke Enhancements
For a summary of the new features, updated functions, and performance improvements included in Zeke version 5.4, refer to your ASG-Zeke Enhancement Summary. This section lists prior enhancements since version 5.1.0. ASG encourages you to visit the Intelligent Support Portal (ISP): http://www.asg.com/support/support.asp. The ISP allows you to verify whether any product or documentation revisions, new maintenance, or service packs apply to the current product release.
Version 5.3.1 Enhancements

Add Events by Path
You can now add an event to the schedule based on predecessor/successor relationships, that is, a specified events path. A path includes the root event and its predecessor and successor events.
Note:
This enhancement is available through the Zeke ISPF online facility only.
Event Master Definition Primary Commands

The following new primary commands, available on the Event Master Definitions screen, invoke the new Schedule View Add-By-Path wizard, which allows you to list predecessors and successors for an event and then schedule events in the list. Command
PATHADD
Description
List both predecessors and successors for an event and then schedule events in the list. List predecessors for an event and then schedule events in the list. List successors for an event and then schedule events in the list.
PREDADD SUCCADD
For a path, you can control the level of depth to display, as well as specify the OCCURS HIT date and event version to be considered by including the following command keywords. Keyword
LEVEL
Description
Limit the path to display this level of depth.
26
1 Introducing Zeke
Keyword
OCCDATE VERSION
Description
Julian date to use when the OCCURS clause is resolved. Version of the event for which to view predecessor/successor information.
ADD Event Record by Path Function

A new option on the Schedule Information Selection Criteria screen allows you to select event records to add to the schedule based on an event path. The ADD by path option launches the new ADD Event Record by Path Selection Criteria screen where you specify criteria for selecting the root event and event scheduling parameters. The Schedule View Event Add List screen lists the events in the path and allows you to select ones for scheduling.
Permanent Events
You can now define a Zeke event as permanent. A permanent event is a type of recurring event that is never removed from the schedule so that it is always available to respond to triggers, even during schedule load processing. You activate a permanent event by adding it to the schedule with the ZADD operator command. The event occurs across every schedule period until you deactivate it using the ZDELETE command.
Number of Events per Database

Version 5.3.1 removes the limit on the maximum number of events in the Zeke database. The previous limit was 131K.
Report Writer
Refer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following Report Writer enhancements.
New Parameters
These new parameters can be used with LIST EVENTS/PLAN for FIELDS selection: Parameter
LJCLsrc
Description
Indicates whether to include on the report the long JCL source (file type, DD or library name, and member name). Indicates whether to include on the report the value of the Permanent field for the selected events.
PERManent
27
This new parameter is available for use with LIST EVENTS/PLAN for event selection: Parameter
PERManent
Description
Specifies whether to select permanent or non-permanent events only.
WHENDETAIL Parameter
The WHENDETAIL parameter has been enhanced in several ways.
WHENDETAIL now selects events that contain the specified string, for example:
LIST EVENTS WHENDETAIL PAY1
This would match any WHEN condition with the string PAY1 in any position in the clause, such as:
EOJ PAY1BR14 WEOJ WEAKPAY1 VAR $ABC EQ DEVPAY1
For LIST PLAN, you can select events based specifically on satisfied conditions, for example:
LIST PLAN WHENDETAIL *VAR
This would select events that have at least one satisfied variable WHEN condition.
WHENDETAIL now accepts mixed-case values. This allows you to select events with mixed-case jobnames.
ZEKEXUTLImport/Export
You can use the import/export utility ZEKEXUTL to perform the following procedures:

Export event (EMR) and variable (VAR) database records as XML data. Import EMR and VAR XML records into the Zeke database. Change key values of EMR and VAR records being imported or exported.
Filtering control statements allow you to select which records to import or export. Change control statements allow you to change fields within the records being imported or exported.
REPORT Subfunction
The new REPORT subfunction of the IMPORT and EXPORT utilities allows you to print the results of an export or import of database records.
28
1 Introducing Zeke
SCHEDULE
Refer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following batch utility enhancements.
Generic Selection Criteria

You can now use wildcard or placeholder characters in your selection criteria for the following parameters when specified for the SCHEDULE function:
APPLICATION GROUPID SYSTEMID USERID
For each parameter, you can specify up to 20 values.
New Parameters
The following new parameters can be used with the SCHEDULE function: Parameter
ENAME JOB
Description
Selects events with the specified event name. Selects job events with the specified job name.
You can use wildcard or placeholder characters in your selection criteria for both parameters.
EVENT
Refer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following batch utility enhancement. The following new parameter can be used with the EVENT function: Parameter
PERManent
Description
Indicates whether the event is to remain in the schedule permanently. See Permanent Events on page 27.
29
RESTORE MERGE
Refer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following batch utility enhancement. Typically, when you restore EMRs and SQRs to the database, you indicate a starting event number. Optionally, you can restore the records by using available event numbers in the existing database.
ASG-OpsCentral Support
Version 5.3.1 supports ASG-OpsCentral (herein called OpsCentral) Version 2.0, the cross-platform, graphical enterprise management console for managing a Zeke schedule from a client workstation. If you have multiple Zeke systems operating in a ZekePlex or an ASG-Zena (herein called Zena) platform scheduler, OpsCentral can manage the scheduling information for any or all Zekes and Zena simultaneously. Zekes OpsCentral server is the message processor that facilitates communication between Zeke and OpsCentral via ASG-RI Server (herein called RIS). See Zeke OpsCentral Server Commands on page 32 for new operator commands related to the OpsCentral server. Refer to your ASG-Zeke for z/OS Installation Guide for detailed information on ASG-OpsCentral support.
OpsCentral Client Authentication

In Version 5.3.1, the OpsCentral Client is authenticated to Zeke using thread security services. A RACF security environment is created for each request (or executing thread) from OpsCentral. Although OpsCentral Client authentication can be disabled, ASG recommends you enable it unless your environment is highly secured and clients are authenticated by other means.
Average Duration
Zeke now maintains the average duration time in seconds (instead of minutes). If you use OpsCentral, this enhancement affects the average duration time Zeke provides to OpsCentral for use in Gantt charts.
30
1 Introducing Zeke
Generation Options
Version 5.3.1 introduces the following new generation options. Refer to your ASG-Zeke for z/OS Reference Guide and ASG-Zeke for z/OS Users Guide for detailed information. Option
DefDelOJ
Purpose
Code indicating the default setting for the Delete after next use option in an SQR when JCL is updated. Code indicating whether the DATASPACE parameter must be specified with the LIST command for Report Writer jobs to use a dataspace to create a batch report. Code indicating whether to suppress inter-product EMR messages.
DSPReprt
Zprdsemr
Operator Commands
Refer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following operator command enhancements.
Zeke Address Space Commands

Zeke provides its own operator modify commands for altering the Zeke environment. Command
#APPEND
Purpose
Append LE parameters to the list of LE parameters used when the OpsCentral server subtask is started (attached). Remove any LE parameters from the internal LE buffer passed to the OpsCentral server at start-up (when attached). Display contents of the LE parameter buffer and subtask information for all subtask modules. Reset the subtask restart counter back to zero. Set the LE parameters to be used when OpsCentral is started and the maximum number of automatic restarts. Start a subtask module.
#CLEAR
#DISPLAY
#RESET #SET
#START
31
Zeke OpsCentral Server Commands

The OpsCentral server (the message processor that facilitates communication between Zeke and OpsCentral via RIS) executes as a subtask of the Zeke started task. These commands allow you to manage OpsCentral server thread and trace options while the server is executing and without having to restart it. Command
$CLOSE $DISPLAY
Purpose
Close one or more alerts. Display the current sessions, server thread statistics, trace settings, and the alert cache. Remove a session ID, terminate a thread, or remove all sessions associated with a user ID. Create an alert message, which is sent to OpsCentral clients and placed in the OpsCentral server alert cache. Set the number of threads used to process requests or set or reset trace flags.
$KILL
$OPEN
$SET
Variables
For improved flexibility in variable substitution, variable values can now be specified in mixed case in the online facilities. (Previously, values were forced to upper case.) As in previous Zeke releases, mixed-case variable values continue to be supported by the batch utilities (ZEKE and ZEKESET), Report Writer, the Audit facility, and in WHEN conditions.
Note:
Currently, only the ZSET function does not support mixed-case values. Refer to your ASG-Zeke for z/OS Users Guide for detailed information.
External Security
A new external security class named Z$ACCESS secures use of generic selection criteria (for application ID, group ID, system ID, or user ID) or the CLEAR keyword with the SCHEDULE function. Refer to your ASG-Zeke for z/OS Users Guide for detailed information on external security.
32
1 Introducing Zeke
ASG-JCLPREP
If you use ASG-JCLPREP (herein called JCLPREP) to validate JCL in Schedule View, you can now use the JPREP line command to populate OASIS event-related items (XQxxxxx). Refer to your ASG-Zeke for z/OS Installation Guide for more information on configuring Zekes JCLPREP interface.

Cross-System Coupling Facility (XCF)
Refer to your ASG-Zeke for z/OS Installation Guide for a detailed explanation of XCF, configuration steps, and operating scenarios.
Using XCF for Data Sharing

Zeke 5.3 introduced support for IBMs Cross-System Coupling Facility (XCF) data repository, a hardware component which, combined with software available in z/OS, allows data to be shared between systems more quickly than is possible using DASD. A key benefit to using XCF is that it is restartable after an outage, without requiring any of the Zekes in the SysPlex to be restarted.
Using XCF for COMM Record Broadcasting

Optionally, Zeke can use XCF (in place of the Zeke database) to process communication (COMM) records (records that signal changes to schedule information).
Using XCF for NOTDURING Processing Across a SysPlex

XCF messaging services expand NOTDURING processing across your ZekePlex, as an option, by allowing Zeke to recognize non-Zeke jobs running on other systems in the SysPlex. Using XCF also reduces the time needed for Zeke to find both Zeke-controlled and non-Zeke jobs running on another system in the ZekePlex. In addition to enabling NOTDURING processing through XCF, setting PLEXNOTD to YES allows NOTDURING job processing in both JES2 and JES3 (otherwise, only JES2 supports NOTDURING dependencies). All Zekes must share the same JES pool.
ZPLEX Operator Command

The ZPLEX operator command is used to manage ZekePlex services. The ZPLEX command can be used to:

Display status information about all operating systems and Zekes in the ZekePlex. Display summary information about this Zekes XCF processing status. Start and stop ZekePlex services.
33
Continuous Job Tracking

Zeke can track certain relevant event activity, even during periods when both Zeke and the OASIS subsystem have been terminated, for example, to apply maintenance. When Zeke, and even OASIS, are terminated, the system activities are recorded. When Zeke is restarted, the logged activities are basically played back, and the schedule is updated accordingly. Because these activities are recorded, Zeke will be able to mark jobs that have ended and also satisfy triggers for any jobs that might have completed while Zeke and/or OASIS was shut down.
ZKILL TRACK Operator Command

The TRACK parameter is used with the Zeke operator command ZKILL to terminate the Zeke system and place it in SMF recording mode.
DMS Registration Performance

Zeke 5.3 enhanced the registration process through DMS. Previously, a single-threaded registration process created a backlog and extended the length of time required for Zeke to register with DMS successfully. This process has been improved by being changed to a multi-threaded process, improving overall DMS performance in the following ways:

Improving registration performance. Improving communication performance of DMS. Providing downward compatibility between new DMS data structures and currently supported versions of Zeke, Zebb, Zara, and Zeke Agents. Enhancing diagnostic capabilities.
Variable Index Processing

In prior releases, Zeke variable processing included an in-memory index for locating the database record containing variable information. This eliminated the need for a directory search of the database and the associated I/O. However, the in-memory index was not updated if a variable was added on another Zeke system. Zeke assumed the index to be inconsistent and searched the database when no entry was found in the index. In a large ZekePlex with many variables, this could cause a significant degradation in scheduling events that use variable values. In Zeke 5.3.0, the following changes were made:
Varindex generation option, which controlled the creation of the variable index, has been deleted so that the index is no longer optional; the variable index is always built.
34
1 Introducing Zeke
Updates to the variable index are broadcast to all Zeke systems in a ZekePlex through COMM records. This helps keep the index consistent and avoid the I/O overhead generated when searching the databaseif there is no record in the index, then the variable is assumed not to exist. Requests for variable substitution in JCL use only the index to determine if the variable exists. This reduces overhead and elapsed time for JCL variable substitution.
Note:
A special PTF is available if you do not want the additional storage use. Contact ASG Customer Support for assistance.
Finer Time Resolution for Event Dispatch/End Times

Previously, job dispatch and ending times were evaluated by Zeke and expressed in hours and minutes only. Because it is essential in determining if and when certain dependent events are to be triggered, event dispatch and end times are now evaluated and expressed in hours, minutes, and seconds (hh:mm:ss). This is especially important for extended dependencies for job events.
Documentation Enhancements
The ASG-Zeke for z/OS Reference Guide in your Zeke documentation set has been enhanced to list and define all Zeke online fields and generation options alphabetically. The ASG-Zeke for z/OS Users Guide and ASG-Zeke for z/OS Reference Guide now include all primary and secondary status codes and reason codes for Schedule View and the ZDISPLAY command ZD WAIT.

Downloading a Schedule to ASG-Zeke Agent
Beginning in Version 5.2.0, Zeke can handle your platform jobs by downloading a subset of the schedule records in the Zeke schedule to a ASG-Zeke Agent (herein called Zeke Agent) for dispatch and execution. (As with previous releases, Zeke continues to be able to dispatch jobs individually to Zeke Agent for execution on your distributed systems.) For more information on downloading jobs to Zeke Agent, refer to Schedules Downloaded to Zeke Agent on page 197 of this publication as well as your ASG-Zeke Agent Users Guide.
35
Note:
This feature requires ASG-Zeke Agent Version 2.x. Contact ASG to find out which platforms are currently supported.
ASG-JCLPREP Integration
ASG-JCLPREP (herein called JCLPREP), ASGs JCL management tool, provides a way to scan for accuracy the JCL associated with a job event. JCLPREP can be invoked using the Schedule View line command JPREP. Or, you can invoke JCLPREP as you are editing the event JCL via the Schedule View ZOOM display, by issuing the JCLPREP edit macro FPREP.
Note:
You must configure Zeke for interfacing with JCLPREP before you can use the JPREP line command. Refer to your ASG-Zeke for z/OS Installation Guide for details.
ASG-IMPACT Interface
Zeke 5.2 introduced a new user exit to interface with ASG-IMPACT Consolidated Service Desk (herein called IMPACT). (Zeke continues to interface with commonly-used third-party problem tracking systems.) Refer to your ASG-Zeke for z/OS Installation Guide for information on accessing and tracking IMPACT tickets opened by Zeke.
Zeke Server for ASG-Enterprise Scheduling Console

Version 5.2 introduced support for ASG-Enterprise Scheduling Console (herein called ESC), the cross-platform, GUI-based enterprise management console used for managing a Zeke schedule from a client workstation. ESC runs on a variety of different platforms, including Windows, UNIX, and Linux. Communications are facilitated through the ASG-RI Server (herein called RIS).
ASG-Cortex-Pdb Plug to Zeke

ASG-Cortex-Pdb for z/OS Version 6.2.0 (herein called Cortex-Pdb) provides a new plug-in interface to Zeke. As described in PTF Z520A058, a new Zeke module named ZEKEXAPI is installed, enabling Zeke to bridge to Cortex-Pdb. You must also apply the appropriate PTF for Cortex-Pdb (refer to your ASG-Cortex-Pdb Release Notes Version 6.2.0 for details). Refer to your ASG-Cortex-Pdb Plug to ASG-Zeke Users Guide for information on implementing and using the interface.
36
1 Introducing Zeke
Improved IBM Workload Manager Initiator Support

Zekes way of working with IBM Workload Manager (herein called WLM) initiators has been enhanced. WLM manages JES2 initiators, by starting and stopping them in response to job workloads. When running with the generation option Dispsel=Y, Zeke is not able to see any available initiators and does not submit WLM jobs. Normally, to allow the WLM jobs to be submitted, you would need to specify Dispsel=N. However, if your are running a mixture of WLM and non-WLM jobs, this would not be appropriate. Through a special PTF, you can mark job events as WLM-managed. These jobs will always be submitted by Zeke, even if Dispsel=Y, and regardless of whether a JES2 initiator is available. Essentially, the jobs are managed by WLM instead of Zeke. After their acceptance by JES2, WLM will start an initiator, as needed.
Julian Day KeywordJDAY

The Julian day can now be specified in the OCCURS clause using the new keyword, JDAY. JDAY uses the same format as the keyword DAY, but its period is for the year. You can also code JDAY by itself to refer to the current Julian day in comparison phrases.
Verload Field Protection

The Event Master Record Functions panel (Z1100000) was modified to prevent a user from over-typing data intended for the Target field so that it overflows into the Verload field. The SKIP(OFF) attribute was applied to the end of the Target field. This change requires you to press the Tab key after typing eight characters in the Target field to move to the Verload field. If you attempt to type beyond the end of the Target field, your keyboard will lock and you will have to press Reset and then the Tab key to continue.
Zeke PDS Override Option

Normally, the JCL override feature for PDS JCL works by attaching the JCL from the PDS as a ZEKEJCL attachment to the schedule queue record (SQR). This JCL can then be modified for the purpose of re-running the job. Optionally, you may choose for Zeke to override the JCL after the next job run. Zekes new PDS override option provides an alternative to the standard JCL override function in Schedule View. The new override option copies the JCL that is pointed to by the DDNAME/member name combination in the SQR to a PDS that is pointed to by the OVERRIDE DD in the Zeke started task. The SQR is updated to point to that DDNAME OVERRIDE. You can then edit the JCL through the ZOOM screen in Schedule View.
37
Schedule View
Sort Setup
The Schedule View Sort Setup screen provides a new way to set up the sort order for fields in Schedule View. Fields listed above the separator line are used for sorting in the user-specified sort order. Unused fields (below the line) are listed alphabetically, for convenience.
Display Setup
The Schedule View Display Setup screen provides a new way to set up the display order for fields in Schedule View. Fields listed above the separator line are displayed in the user-specified sort sequence. Unused fields (below the line) are listed alphabetically, for convenience.
Operator Commands
Version 5.2.0 added or updated the following parameters.
ZDISPLAY Command
Parameter
DOWnload
Description
Displays the list of schedule download agents and their processing statuses. Displays the download status of events. Only events with a target of a download agent are displayed. Displays events of a specified status. ACTive DISpatched Displays events currently running. Displays events that have been dispatched but have not started running. Displays events that ended abnormally. Displays events that are in the dispatch queue. Displays events with time and WHEN conditions that have not been satisfied. Displays events that completed successfully.
DLStatus
STATus
FAIl QUEued SCHeduled
SUCcess
38
1 Introducing Zeke
ZALTER Command
Parameter
SYNch
Description
Synchronizes schedule records downloaded to a Zeke Agent with their corresponding records on Zeke.
Auto Replies to Suppressed Messages

In addition to being triggered by a specified message, portion of a message, message ID, or other unique text string, a Zeke automatic reply can also be triggered by a message that has been suppressed from the console.

OS Compatibility
Zeke supports four-digit initiator names, in compliance with JES2 4.3 and above.
New Started Task Parameters

New startup parameters for Zeke allow you to start Zeke with the dispatcher on hold, start at a disaster recovery site without the vault dataset, or override certain generation options. The parameters are kept in a PARMLIB member. For example: Startup Parms
SYSHOLD=YES VAULT=NO DSPACE=NO
Description
Causes Zeke to start with the dispatcher on hold. Enables Zeke to start at a disaster recovery site without the vault dataset. Overrides the generation options and starts the started task without an EDB dataspace.
Event Definition
Increase Event Numbers to Six Digits
Zeke event numbers were increased to six digits. This allows you to define and maintain up to 999,999 events on a single Zeke database as long as the database size is sufficient.
39
Non-Executable Events
An event can be defined as non-executable. Non-executable events are scheduled like any other event, and are useful as predecessors to other events. A non-executable event is never submitted for execution. After dispatch, the event status automatically changes to indicate success and any dependent events are triggered.
30-Byte Jobnames
Zeke supports a 30-byte mixed-case jobname in the event definition for a non-mainframe event and for any jobname used in a WHEN condition. This allows for greater flexibility in defining WHEN conditions for events that execute on other platforms. All Event Master Record Functions screens are enhanced to allow long jobnames. Long jobname can now also be selected as a field for printing on reports.
Improved WHEN Condition Processing

WHEN condition processing using the Event Master Record Functions screen has been enhanced to allow the following functions:
All standard ISPF commands, such as FIND, CHANGE, CHANGEALL, SAVE and CANCEL are now available. Scrollable WHEN conditions. Limit on the length of jobnames used in a WHEN condition has been increased to 30 characters.
New Event Type for REXX Events

A REXX event type allows Zeke to dispatch and track REXX execs. REXX execs are commonly used to customize various Zeke functions, such as messages and commands. REXX events can be defined using the ISPF online facility or batch. REXX events can be reported or simulated like other event types.
Note:
To implement the use of REXX events, OASIS/ECF must be installed and set up. Refer to your ASG-OASIS for z/OS Installation Guide for instructions.
Schedule Time of 48:00

You can use 48:00 as a schedule time. An event with a schedule time of 48:00 is never dispatched because 47:59 is the cutoff time for dispatching. Use a schedule time of 48:00 for events that you want to place in the schedule, but do not want to dispatch except by operator command.
40
1 Introducing Zeke
Scheduling
Improved Flexibility in Adding or Deleting Events from the Schedule
Zeke now allows you to add an entire schedule for a run date other than the current date. All events added to the schedule will have the specified run date. Scheduled events can be deleted from the schedule by group ID, application ID, or user ID. Scheduled events that meet all of the specified criteria are cleared from the schedule. If only partial criteria or no criteria are met, then the events remain in the schedule.
Schedule Date Included in Message Z0302I

System message Z0302I has been changed to include the schedule date. This allows you to uniquely identify an event that is late when you have multiple events with the same event number, but different schedule times.
Note:
If you use an automated operator product, and are intercepting the Z0302I message, revise the automated operator to accommodate the schedule date portion of the message.
Schedule View
AUTO Command
The maximum wait time to break out of update mode is now specified using the INTERVAL command. When the screen is in automatic monitoring mode, a message at the bottom of the screen indicates that AUTO mode is on and displays the latest INTERVAL command settings.
INTERVAL Command
The following parameters were added for the INTERVAL command. Parameter
rate wait
Description
These two new operands control the automatic monitoring mode. The first number {rate} is the seconds between automatic refreshes. The second number {wait} is how often to check for a request to exit AUTO mode. To change the timing of screen refreshes, enter INT rate wait where rate is a range from wait value to 3660 seconds and wait is a range from 1 to 255. Both parameters are optional and have default values of 5. Additionally rate must be a multiple of wait; however, this is calculated and changed automatically. For example, to refresh the screen every 10 seconds and to check for an exit AUTO mode request every 5 seconds, enter INT 10 5.
41
Viewing Remote Jobnames

As a part of Zekes support for 30-byte mixed-case jobnames in the event definition for non-mainframe events, Schedule View now allows you to view longer remote jobnames in addition to eight-byte mainframe jobnames in your display. See Using Schedule View on page 202 for information on setting up how jobnames appear in your display.
Operator Commands
Six-Digit Event Numbers in Operator Commands
Six-digit event numbers can be specified in the event selection criteria for any operator command that accepts event number as a parameter.
ZADD Operator Command

The following parameters were added for the ZADD command. Parameter
APPLication
Description
Adds one or more events with the specified application ID to the schedule. The Multap generation option (see Generation Options on page 45) indicates the action to take when more than one event matches the specified application ID. Updates the scheduled events start time by adding the specified amount of time (hhmm) to the events start time. If the event does not have a start time specified, then the CURRPLUS value is added to the current time. Adds one or more events with the specified group ID to the schedule. The Multgr generation option (see Generation Options on page 45) indicates the action to take when more than one event matches the specified group ID. Displays a list of the events that would be added to the schedule if you submitted the ZADD command with the criteria currently specified. Adds the event to the schedule ready to run using the event master record (EMR) information. The RUN option satisfies the events time, WHEN, NOTACTIVE, and operator confirmation conditions. Adds one or more events with the specified user ID to the schedule. The Multus generation option (seeGeneration Options on page 45) indicates the action to take when more than one event matches the specified user ID.
CURRplus
GROup
PREView
RUN
USERid
42
1 Introducing Zeke
ZALTER Operator Command

The following parameter was added for the ZALTER command. Parameter
CONTROL
Description
Indicates whether this event is tracked as a Zeke-controlled event. Zeke-controlled events are tracked throughout the entire execution. You can also define the event as non-executable. This means the record can be scheduled as normal, but the JCL is not dispatched. Instead when the event is dispatched, the events status changes to SUCCESS and other events are triggered. Marks the event with an F/F (forced failure) status and triggers all the failure dependencies.
FAILURE
ZDELETE Operator Command

The following parameters were added for the ZDELETE command. Parameter
APPLication
Description
Deletes one or more events with the specified application ID from the schedule. The Multap generation option (see Generation Options on page 45) indicates the action to take when more than one event matches the specified application ID.
GROup
Deletes one or more events with the specified group ID from the schedule. The Multgr generation option (see Generation Options on page 45) indicates the action to take when more than one event matches the specified group ID.
PREView
Displays a list of the events that would be deleted from the schedule if the ZDELETE command string were submitted with the current criteria and without the PREVIEW parameter. Deletes events with the specified user ID from the schedule. The Multus generation option (see Generation Options on page 45) indicates the action to take when more than one event matches the specified user ID.
USERid
43
ZDISPLAY Operator Command

The following parameter was added for the ZDISPLAY command. Parameter
STATus
Description
Selects events of a specified status to display. Valid statuses are: Status SCHeduled Description Displays scheduled events with time conditions and dependencies that are not yet satisfied. Displays scheduled events in the dispatch queue. Displays scheduled events that are dispatched but not yet running. Displays scheduled events that are running. Displays scheduled events that completed successfully. Displays scheduled events that failed to complete.
QUEued DISpatched
ACTive SUCcess
FAIl
ZDISPLAY Formats
The display formats have changed to reflect revised column names, six-digit event numbers, and terminology changes. The ZDISPLAY statuses LATE, DSBL, PEND, ACTV, HOLD are unchanged.
ZRELEASE Operator Command

You can now use the ZRELEASE command to release an event even if the system is on hold.
44
1 Introducing Zeke
Generation Options
The following generation options were added. Option
DSPSched Multap
Description
Indicates whether the DATASPACE option can be used for schedule loads. Indicates what to do when a ZADD or ZDELETE is issued based on an application name, but more than one EMR has the specified application name. Indicates what to do when a ZADD or ZDELETE is issued based on a group name, but more than one EMR has the specified group name. Indicates what to do when a ZADD or ZDELETE is issued based on a user ID, but more than one EMR has the user ID specified. z/OS only. If Posid=YES, specifies whether POSID information is placed at the end or the beginning in Zeke-dispatched jobs. Indicates how to handle a remote trigger received for scheduled jobs with multiple schedule dates.
Multgr
Multus
Posidend
Remtrig
BACKUP Command
The following keyword was added for the BACKUP batch utility command. Keyword
DATASPACE
Description
Creates a backup copy of the database from a temporary copy created in a dataspace.
CREATE Command
The following keyword was added for the CREATE batch utility command. Keyword
PLEXID
Description
Specifies an eight-character name that uniquely identifies the Zeke database to which multiple systems are connected.
45
EVENT Command
The following parameters were added for the EVENT batch utility command: Parameter
SCOMSTART SCOMAPPEND
Description
Indicates the beginning of SCOM data in the SYSIN JCL to be added to an SCOM event master record as part of the EVENT ADD or EVENT UPDATE process. Indicates the end of SCOM data to be added to an SCOM event master record as part of the EVENT ADD or EVENT UPDATE process.
SCOMSTOP
RESTORE Command
The following keyword was added for the RESTORE batch utility command. Keyword
PLEXID
Description
Specifies an eight-character name that uniquely identifies the Zeke database.
SCHEDULE Command
The following parameters were added for the SCHEDULE batch utility command. Parameter
DATASPACE
Description
Creates a schedule from a temporary copy of the database created in a dataspace. This feature reduces I/O on the database, reducing CPU time by an average of 30%. Identifies the application the event is a part of. Identifies the group the event is a part of. Identifies the person who is responsible for the event. RDATE used with the ACTIVATE parameter allows you to specify an RDATE value other than the default value of today. All events added to the schedule will have the RDATE specified in the statement.
APPLication GROupid USERid RDATE
46
1 Introducing Zeke
Report Writer
LIST EVENTS/PLANEMR and Schedule Listings
The following parameter was added for the LIST EVENTS/PLAN command. Parameter
DATASPACE
Description
Lists the information using a temporary copy of the database created in a dataspace when generating the report. This reduces I/O on the database, allowing the batch program to execute much more quickly. Selects EMRs that execute on the specified remote system.
TARGet
OCCURSDETAIL
The OCCURSDETAIL parameter was added for the LIST EVENTS command. This parameter is not valid with the LIST PLAN command. Parameter
OCCURSDETAIL
Description
Selects events with OCCURS clauses that contain the specified keywords.
When using the OCCURSDETAIL parameter, it is important to understand how Zeke considers OCCURS clauses. In Version 4.5 and earlier, an event with the default OCCURS specification REQUEST was considered to have an OCCURS clause. However, in Version 5.1.0 (and above), an event with the default OCCURS specification REQUEST is considered by Zeke not to have an OCCURS clause. Beginning with the introduction of the OCCURSDETAIL parameter in Version 5.1.0, you can perform a LIST EVENTS to select events with any OCCURS clause or with specific OCCURS keywords. Based on Zekes interpretation of OCCURS clauses, an OCCURS value of REQUEST is never selected.
LJOBname
The following keyword were added for the FIELDS parameter of the LIST EVENTS/PLAN command. Parameter
FIELDs
Description
Specifies the fields to be printed on the report.
LIST EVENTS FIELD=(ENAME, LJOB)
Keyword LJOBname
Length 30
Description Long jobname 47
48
Chapter 2:
2
Topic
Starting Zeke Restarting Zeke Starting OASIS Only Starting Multiple Tasks Terminating OASIS Terminating Zeke
Starting Zeke and Using the Online Facility
This chapter explains how to start and terminate Zeke and OASIS. It also describes the ISPF interface to Zeke, and explains how to log on to and exit the Zeke online facility. Page
50 51 52 53 55 56 57 57 58 59
ISPF Interface ISPF Features General Screen Information Logging On
49
Starting Zeke
The SSS4001 program initializes Zeke. If the specified OASIS subsystem is not already initialized, SSS4001 initializes it before starting Zeke.
To start Zeke
Submit a job similar to the following:
//ZEKE PROC R=0M,S=ZK540, // XP=ZEKECOM,OASIS=(aa,bb), // ZK=YES, //stepname EXEC PGM=SSS41,REGION=&R,TIME=1440, // PARM=('OASIS=&OASIS,ZEKE=&ZK,XPROC=&XP,SUBSYS=&S,END) //STEPLIB DD DISP=SHR,DSN=Zeke load library // DD DISP=SHR,DSN=OASIS load library //ZEKERDR DD SYSOUT=(A,INTRDR) //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //xxxxxxxx DD DISP=SHR,DSN=any necessary DD statements
where: Code
aa bb
Meaning
OASISxx options member name suffix. Console option. Option L C Description List all options values on the console. Start an operator dialogue to list the values, override values for this start-up, and/or cancel the start-up. Both L and C. List option values on the console; then start an operator dialogue. Not L or C. Do not list option values or start a dialogue.
LC
50
2 Starting Zeke and Using the Online Facility
Restarting Zeke
If a Zeke started task subtask terminates, it is automatically restarted. An information message is issued when this occurs. If a subtask terminates numerous times, it is assumed a serious error exists and the subtask is not restarted. If this occurs, terminate Zeke and correct the problem before trying to restart Zeke. If multiple OASIS-supported products are active in one address space and Zeke is deactivated by the ZKILL command (WARM or COLD) or the system STOP command, start the same Zeke procedure that was used to initiate the address space that was terminated.
To restart Zeke when OASIS is already running

Issue the START ZEKE command from the operator console or issue a system MODIFY command to the address space.
F procname STPROD ZEKE
When the Zeke address space starts, it will find its schedule tables in CSA and determine whether it should do a warm or cold start.
51
Starting OASIS Only

You can start OASIS without starting Zeke. This is a normal procedure when you need to create a Zeke database.
To start OASIS
Issue the START command using the following syntax:
START procname,S=subsys,OASIS='(aa,bb)'
where:
procname subsys (aa,bb) Note: Name of the OASIS start-up procedure. OASIS subsystem name. OASISxx options member name suffix and console option.
If the start-up procedure provides values for the S and OASIS symbolic parameters, you can omit those parameters from the START command. The following is a sample of a typical OASIS startup:
S OASISSTC,S=SSSI,OASIS='(00,N)' $HASP100 OASISSTC ON STCINRDR $HASP373 OASISSTC STARTED IEF403I OASISSTC - STARTED - TIME=14.39.30 X00032I EXECPARM OASIS=(00,N),SUBSYS=SSSI X00353I Program SSS2SV2 installed as SVC 245 X00000I SET UP COMMAND PREFIX LENGTH X00008I SSSI Host System Interface initialized CPU=1B02095570600000 ID=A Name=A X00025I OASIS/HSI X270A000 z/OS 1.4.0 JES2 X00903I OASIS command processor enabled
52
Starting Multiple Tasks

The following examples show the changes to make to the Zeke started task, the ZEKEUTL batch utility, and the OASIS procedures for an alternate subsystem name of ZDOC. Refer to your ASG-OASIS for z/OS Installation Guide for more information on using PolyZeke, and on modifying Zeke and OASIS procedures to run multiple versions of Zeke on a single operating system.
Zeke Started Task
//* ZEKE : ALTERNATE STARTED TASK PROC //ZK53ALT PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS270 //ZK53ALT EXEC PGM=SSS4001,REGION=&R, // TIME=1440,PARM=OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //ZEKERDR DD SYSOUT=(A,INTRDR) //ZEKECAT DD DISP=SHR,DSN=* Alternate Zeke Database * //PARMLIB DD DSN=library containing OASIS00 member,DISP=SHR //STEPLIB DD DISP=SHR,DSN=* Your Zeke Load Library Name * // DD DISP=SHR,DSN=* Your OASIS Load Library Name* //*
Each Zeke must have its own unique ZEKExx and OASISxx members. In each Zeke started task procedure, change the OASIS=(00,L) and ZEKE=(00,L) to OASIS=(xx,L) and ZEKE=(xx,L), where xx is the last 2 characters of the OASISxx or ZEKExx options member for that particular Zeke.
ZEKE Batch Utility
//* ZEKE //ZEKEUTL //ZUTL //ZEKECAT //STEPLIB // //SYSPRINT //SYSABEND //SORTWK01 // //SORTWK02 // //SORTWK03 // //*
: BATCH UTILITY PROC PROC R=0M,P='SUBSYS=ZDOC' EXEC PGM=ZEKE,PARM='&P',REGION=&R DD DISP=SHR,DSN=* Alternate Zeke Database * DD DISP=SHR,DSN=* Your Zeke Load Library Name * DD DISP=SHR,DSN=* Your OASIS Load Library Name* DD SYSOUT=* DD SYSOUT=* DD DSN=&&SORTWK01,DISP=(NEW,DELETE), SPACE=(CYL,(2,2)),UNIT=SYSDA DD DSN=&&SORTWK02,DISP=(NEW,DELETE), SPACE=(CYL,(2,2)),UNIT=SYSDA DD DSN=&&SORTWK03,DISP=(NEW,DELETE), SPACE=(CYL,(2,2)),UNIT=SYSDA
53
OASIS Started Task
//* ZEKE //OASISALT //OASISALT //PARMLIB //SYSPRINT //SYSABEND //STEPLIB //
: OASIS ALTERNATE SUPPORT PROC PROC R=0M,OASIS=(00,L),S=ZDOC EXEC PGM=SSS0UTL,REGION=&R,PARM=OASIS=&OASIS,SUBSYS=&S,END DD DSN=ASG.PARMLIB,DISP=SHR DD SYSOUT=* DD SYSOUT=* DD DISP=SHR,DSN=* Your Zeke Load Library Name * DD DISP=SHR,DSN=* Your OASIS Load Library Name*
Zeke Started Task

This example shows the changes to use a single started task procedure to access multiple Zeke database and OASIS subsystems.
//ZEKE PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS270 // DB='ZEKE.DATABASE.NAME;' //ZEKE EXEC PGM=SSS4001,REGION=&R, // TIME=1440,PARM=OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END //SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //ZEKERDR DD SYSOUT=(A,INTRDR) //ZEKECAT DD DISP=SHR,DSN=&DB //PARMLIB DD DSN=library containing OASIS00 member,DISP=SHR //STEPLIB DD DISP=SHR,DSN=* Your Zeke Load Library Name * // DD DISP=SHR,DSN=* Your OASIS Load Library Name* //*
Zeke Start Up Commands

Use the following commands to start the Zeke primary production system using an alternate database:
S ZEKE S ZEKE,S=ZDOC,DB='ZEKE.TEST.DATABASE',OASIS=(01,L)
Starts production system Starts alternate database
54
Terminating OASIS
Do not terminate OASIS if any other OASIS-supported products are running in that OASIS subsystem. All OASIS-supported products in the same subsystem must be terminated prior to terminating OASIS. The following is a sample jobstream to terminate OASIS (where xxxx is the subsystem):
//ZOASIS JOB //SOASIS EXEC //SYSPRINT DD //STEPLIB DD //SYSIN DD TERMINATE /*
,MSGLEVEL=(1,1),CLASS=A PROC=OASIS,REGION=1024K,S=xxxx SYSOUT=A DSN=OASIS.LINKLIB,DISP=SHR *
<== If required
55
Terminating Zeke
To terminate Zeke with the STOP command
If more than one OASIS-supported product is active in the address space, the system STOP command (P command) terminates all active products as well as the started task. When the last, or only, active product in the address space terminates, the started task automatically terminates. 1 With the STOP command, specify the name of the procedure that starts the task. Issue the following command to terminate a Zeke started task:
STOP ZEKE
Zeke asks whether you want to perform a cold or warm termination (see the description of ZKILL below for the difference between cold and warm termination). Enter C for cold or W for warm.
To terminate Zeke using ZKILL

The ZKILL command terminates only Zeke; other products in the address space remain active. ZKILL releases Zeke-owned storage and system resources and terminates its subtasks. The COLD, WARM, and TRACK parameters dictate how the ZKILL is processed. Issue one of the following ZKILL commands to terminate Zeke, depending on the desired result. Command
ZKILL COLD
Result
Terminate all Zeke processing and release all Zeke program and table storage. Other products in the same address space remain active. Terminate only Zeke dispatching; Zeke still performs all job tracking, triggering, and updates. Other products in the same address space remain active. Note: If Zeke is cancelled during a cold start, before the schedule has been loaded the first time, or while a schedule reload is in progress, the schedule is freed and Zeke terminates fully.
ZKILL WARM
ZKILL TRACK
Terminate Zeke in the same manner as ZKILL COLD, but keep Zekes SMF exits active and place Zeke in SMF recording mode.
See ZKILL Command on page 273 for more details.

56
ISPF Interface
ISPF Features
The Zeke online facility is a dialog that runs under ISPF/PDF. Since it is a dialog, all ISPF functions, such as SPLIT SCREEN and JUMP, are available. You can enter any valid ISPF commands on the Command line or Option line. Additionally, you have control over the PF key settings.
Online Help
The online facility includes an online Tutorial and Help system. To access the Tutorial, enter T from the Zeke Option Menu. To access Help, press F1from any Zeke application screen.
Primary Commands
Primary commands, such as ADD, DELETE, BROWSE, and EDIT, are listed on most screens beside the Primary Commands heading. Enter these commands on the Command line or Option line to change the mode for the screen you are using or to switch to another screen. Screens that use editing also support all standard ISPF editing commands, such as SAVE, EDIT, CANCEL, and END.
Note:
A few commands, such as CANCEL, COPY, and EDIT, have the same name in ISPF as in Zeke. When these commands are issued within Zeke, they are processed as Zeke commands, not ISPF commands. To use the ISPF command within Zeke when there is a Zeke command by the same name, you must issue it as part of the ISPF EDIT command BUILTIN (e.g., BUILTIN CANCEL). Otherwise, the system assumes you are issuing a Zeke command. See your ISPF documentation for details about the BUILTIN command. Though not listed beside the Primary Commands heading, the OVAR primary command is available from the Command line of any screen in the ISPF online facility. This command accesses the OASIS Variable Maintenance screen where you can add, browse, edit, or delete OASIS variables.
57
Line Commands
Line commands, such as I for Insert, R for Repeat, and D for Delete, are listed on the screens beside the Line Commands heading where applicable. Enter these commands in the SEL field next to the appropriate item. The SEL field is located at the left-hand column of a screen. Screens that use line commands also support all standard ISPF editing commands, such as C for Copy, CC for Copy Block, and TF for Text Flow.
General Screen Information

This section describes the standard format of the Zeke ISPF screens, including the fields common to most screens.
ASG-Zeke Command or Option primary command entry line Command ===> Screen Name varies depending on screen purpose Primary Commands Zeke primary commands; varies by screen function; standard ISPF commands are also available Line Commands Zeke line commands; varies by screen function; standard ISPF commands are also available Screen Mode action allowed on this screen. Condition Code Validation ADD Scroll ===> PAGE
Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000006 Jobname: TSKKGUT1 System: ZEQA RA =Range O = Ok - Range Low High 8 16 Action Event Name: ZEKE51TST6
Operators: Actions: Stepname EOJ CC STEP01 STEP02
EQ NE LE LT GE GT F = Fail, C = Cancel, Procstep Operator
GT NE
F O
58
Logging On
This procedure explains how to log on to the Zeke ISPF online system. The online can be used to update the Zeke database and handle many tasks basic to using Zeke effectively. All the remaining ISPF procedures assume you begin at the Zeke Primary Menu.
To access the Zeke ISPF online facility

1 Access the IBM ISPF Primary Option Menu.
ISPF Primary Option Menu Option ===> ASG More: 0 Settings Terminal and user parameters 1 View Display source data or listings 2 Edit Create or change source data 3 Utilities Perform utility functions 4 Foreground Interactive language processing 5 Batch Submit job for language processing 6 Command Enter TSO or Workstation commands 7 Dialog Test Perform dialog testing 8 LM Facility Library administrator functions 9 IBM Products IBM program development products 10 SCLM SW Configuration Library Manager 11 Workplace ISPF Object/Action Workplace BS BookShelf IBM's BookShelf Z Zteam Zeke, Zebb, Zara Enter X to Terminate using log/list defaults + User ID . : SPTKAB Time. . . : 15:15 Terminal. : 3278 Screen. . : 1 Language. : ENGLISH Appl ID . : ISP TSO logon : $TSUSER TSO prefix: SPTKAB System ID : SYSD MVS acct. : ACCT Release . : ISPF 5.2
Enter Z and press Enter. The ASG Product Selection Menu is displayed.
ASG Product Selection Menu OASIS Subsystem ===> SSSI USERID - SPTKAB Automated Operations TIME - 15:22 Rerun/Restart Management Enterprise Scheduling Tape Management OASIS Variables and Audit
OPTION ZA ZB ZE ZR ZX WP WA
===> ZE -
ASG-Zack ASG-Zebb ASG-Zeke ASG-Zara ASG-OASIS ASG-WP ASG-WA
- Workload Planner (BETA 44) - Workload Analyzer (BETA 45)
EXIT
- Return to previous menu
Enter END command to return to the previous menu.
Enter ZE in the OPTION field.

59
Enter the subsystem you want to access in the OASIS Subsystem field. The default subsystem is SSSI. Press Enter. The ASG-Zeke Primary Menu is displayed.
ASG-Zeke Option ===> 1 2 3 4 5 6 7 8 F C T X Event Schedule View Calendar Options Work Security Documentation Variable Automation Control Tutorial Exit ASG-Zeke Primary Menu Z540A000
Event Master Record Schedule View / Scheduling Commands Calendar Maintenance Options and Passwords Maintenance Work Center Control Functions Security Control Functions Documentation for Events Variable Maintenance Fastpath Tables Maintenance Schedule View Display Characteristics Information about using ASG-Zeke Exit the ASG-Zeke Application
Copyright (C) 2007 Allen Systems Group, Inc. All rights reserved.
From this menu, select any of the online functions by entering the option number on the Option line and pressing Enter.
60
To log off the Zeke ISPF online system

1 From the ASG-Zeke Primary Menu, enter X on the Option line.
ASG-Zeke Option ===> 1 2 3 4 5 6 7 8 F C T X Event Schedule View Calendar Options Work Security Documentation Variable Automation Control Tutorial Exit ASG-Zeke Primary Menu Z540A000
Event Master Record Schedule View / Scheduling Commands Calendar Maintenance Options and Passwords Maintenance Work Center Control Functions Security Control Functions Documentation for Events Variable Maintenance Fastpath Tables Maintenance Schedule View Display Characteristics Information about using ASG-Zeke Exit the ASG-Zeke Application
Copyright (C) 2007 Allen Systems Group, Inc. All rights reserved.
Press Enter. The ISPF Main Menu is displayed.
Note:
If you have Zack installed, the Automation (Fastpath Tables Maintenance) option provides a quick way to manage Zack Fastpath and Autoreply tables directly from Zeke. If Zack is active, the option takes you directly to the Zack Fastpath Table Maintenance function. You are presented a directory listing of table names, types (message/reply/dataset), and statistics. You can then add, browse, copy, delete, or edit a specific table. Refer to your Zack documentation for more information on Fastpath tables.
61
62
Chapter 3:
Calendars
3
When Zeke creates a schedule of events, it uses calendars to distinguish a workday from a weekend day from a holiday. This information is important because it determines the meaning of some of the OCCURS keywords. For example, if you define your workdays as Monday through Friday, then the OCCURS keyword WORKDAYS means schedule the event Monday through Friday. However, if you define your workdays as Monday through Saturday, the OCCURS keyword WORKDAYS means schedule the event Monday through Saturday. Topic
Calendar Types Accessing the Calendar Facility Standard Calendars Special Calendars User Accounting Calendars Calendar Documentation Maintaining Scratch Pad or Note Documentation Maintaining Text Documentation
Page
64 65 67 69 70 72 73 74
63
Calendar Types
There are three types of calendars. Calendar
Standard Special
Description
Defines normal workdays and holidays. Defines the exact days an event is to run; a special calendar is used only when an event has truly random run dates. Defines normal workdays, holidays, and establish accounting periods.
User accounting
Most companies only need one or two Zeke calendars to meet all their scheduling needs; however, you can define as many calendars as you need. Zeke allows an unlimited number of calendars to be defined. Each calendar must have a unique ID.
Note:
If a calendar is set up for a specific year and begins processing on the first day or week of the year, you must also set up a calendar for the previous year for Zeke to reference when determining the previous workday. The same is true for a calendar processing on the last day or week of the year. You must set up a calendar for the next year for Zeke to reference.
64
3 Calendars
Accessing the Calendar Facility

To access the calendar facility
1 From the Zeke Primary Menu, enter option 3 and press Enter. The Calendar Selection Criteria screen is displayed.
ASG-Zeke Command ===> Calendar ID==> Primary commands: ADD Calendar Selection Criteria
Year==> BROWSE COPY DELETE EDIT
Type==> DOCUMENT
Enter SELECTION MASK in any field to be compared for selection. Clear any field that is not to be used for selection. * - is a prefix/suffix indicator. ? - is a wild/place holder character. * SELECTION FIELD MASKS *
Calendar ID => Calendar Type => Date Range =>
STD- Standard -
SPC- Special USR- User (MM/DD/YYYY) or (DD/MM/YYYY)
Press Enter. The Calendar Directory is displayed.

ASG-Zeke Command ===> Calendar Directory Row 1 to 3 of 3 Scroll ==> PAGE
Calendar id==> Year==> Type==> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: E Edit B Browse C Copy D Delete O dOcument Calendar Workdays Start End Last Name Year Type MTWTFSS Date Date Used A **** STD YYYYYNN 01/20/2007 ACCTG1 2007 USR YYYYYNN 01/01/2007 06/30/2007 USER1 2007 SPC N/A 01/01/2007 12/31/2007 ******************************Bottom of data*******************************
65
Perform the steps in the Action column, depending on the desired result. Desired Result
Add a new calendar
Action
Make the following entries: 1 Enter ADD on the Command line. 2 Enter the new calendar ID. 3 Enter the year the calendar covers. Note: For standard and special calendars, you can enter **** to indicate a generic year. User Accounting calendars require a specific year. 4 Enter the calendar type and press Enter. Type STD SPC USR Description Standard calendar Special calendar User accounting calendar
Update an existing calendar Delete an existing calendar
Move the cursor to the unlabeled Selection field to the left of the calendar you want to update and enter E. Move the cursor to the unlabeled Selection field to the left of the calendar you want to update and enter D. The Calendar Maintenance Functions screen is displayed, showing the calendar. Enter DEL and press Enter to confirm the deletion. This procedure is complete.
Press Enter. The Calendar Maintenance Functions screen for the appropriate type of calendar is displayed.
66
3 Calendars
Standard Calendars
Standard calendars define the normal workdays and holidays and indicate the first month of the fiscal year for your company. Most events are associated with a standard calendar. The default Calendar A that is installed with Zeke is a standard calendar that can be updated to accommodate your normal schedule. You can define as many standard calendars, each with different workdays and holidays, as you need. In this example, an event defined with the OCCURS clause WORKDAYS using calendar A is scheduled 5 times a week, and an event using calendar B is scheduled 6 times a week. Also, calendar A adjusts the scheduling of an event in case of a holiday, while calendar B does not recognize any holidays.
Calendar A Workdays Holidays Monday through Friday 01/01/****, 07/04/****, 12/24/****, 12/25/****, 05/28/2007, 09/03/2007, 11/22/2007, 11/23/2007 Monday through Saturday None
Calendar B
Workdays Holidays
To maintain a standard calendar

1 Access the Calendar Maintenance Functions screen as instructed in Accessing the Calendar Facility on page 65.
ASG-Zeke Command ===> Calendar Maintenance Functions EDIT
Primary Commands: ADD Calendar ID==> A
BROWSE
CANCEL COPY DELETE Year==> ****
DOCUMENT EDIT Type==> STD ** MM/DD/YYYY
** Work Days ** ********************* Holidays **************** MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY Monday: YES Tuesday: YES Wednesday: YES Thursday: YES Friday: YES Saturday: NO Sunday: NO Fiscal start month: 01 Calendar expire date: Calendar start date:
Date last accessed: 01/20/2007 Calendar end date :
67
Note:
On the screen, it appears that the Work Days and Holidays are related. They are not. In other words, Monday holidays do not have to be entered on the first line, Tuesday on the second, etc. 2 The default workdays are Monday through Friday, and weekends are Saturday and Sunday. There are no default holidays. You update the Work Days portion of the screen if your workdays are different from the default days. Use the New Line key to access each of the workday fields. For each day of the week, enter YES if it is a workday; enter NO if it is not a workday. To update the Holidays portion of the screen, enter the date of each holiday your company observes. From the Monday field, use the Tab key to access each holiday date field. You can enter up to 30 holidays on one calendar, so a single calendar can span several years. Press Enter to save your changes.
68
3 Calendars
Special Calendars
A special calendar is used for jobs with random scheduling dates, when no other type of calendar and no OCCURS clause can be used to describe the schedule. The job is still associated with a standard calendar as well. The OCCURS clause indicates the special calendar to use. To schedule an event on every selected date on the special calendar:
OCCURS (CALENDAR CAL1 AND DAILY)
You can use one special calendar for several jobs, then use keywords to specify dates in the OCCURS clause. To schedule an event on selected dates that fall on Monday.
OCCURS (CALENDAR CAL1 AND MONDAY)
To maintain a special calendar

ASG-Zeke COMMAND ===> Calendar Maintenance Functions BROWSE
Primary Commands: ADD ZEKE Calendar ID==> USER1
BROWSE
CANCEL COPY DELETE Year==> 2007 1 3 . . . . . . . . . . . * 1 4 . . . . . . . . . . . . 1 5 . . . . . . . . . . . . 1 6 . . . . . . . . . . . . 1 7 . . . . . . . . . . . . 1 8 . . . . . . . . . . . . 1 9 . . . . . . . . . . . . 2 0 . . . . . . . . . . . . 2 1 . . . . . . . . . . . . 2 2 . . . . . . . . . . . . 2 3 . . . . . . . . . . . . 2 4 . . . . . . . . . . . .
DOCUMENT EDIT Type==> SPC 2 5 . . . . . . . . . . . . 2 6 . . . . . . . . . . . . 2 7 . . . . . . . . . . . . 2 8 . . . . . . . . . . . . 2 9 . . . . . . . . . . . . 3 3 0 1 . . . . . . . . . . . . . . . . . .
January February March April May June July August September October November December
1 . . . . . . . . . . . *
2 . . . . . . . . . . . *
3 . . . . . . . . . . . *
4 . . . . . . . . . . . *
5 . . . . . . . . . . . *
6 . . . . . . . . . . . *
7 . . . . . . . . . . . *
8 . . . . . . . . . . . *
9 . . . . . . . . . . . *
1 0 . . . . . . . . . . . *
1 1 . . . . . . . . . . . *
1 2 . . . . . . . . . . . *
Calendar Expire Date: Calendar Start Date: 01/01/2007
Date Last Accessed: Calendar End Date: 12/31/2007
Enter an asterisk (*) on the days you want the job to be scheduled. The days are listed across the screen and the months are listed down the left-hand column to create a matrix of dates. To deselect a date where an asterisk has been entered, replace the asterisk with a period (.).
Press Enter to save your changes.
69
User Accounting Calendars

You set up user accounting calendars to match the days in your accounting periods. In this way, you can schedule jobs based on your company accounting schedule. An event is tied to a user accounting calendar with the Calid field, just as with a standard calendar. When you specify a user accounting calendar, keywords refer to periods instead of months. You must also use the OCCURS clause keyword PERIODS instead of MONTHS for jobs that use a user accounting calendar. For example, for the last Monday in period 2:
MONDAY.L AND PERIOD.2
To maintain a user accounting calendar

ASG-Zeke Command ===> Calendar Maintenance Functions BROWSE
Primary Commands: ADD BROWSE Calendar ID==> ACCTG1
CANCEL COPY DELETE Year==> 2007
DOCUMENT EDIT PERIODS Type==> USR
** Work Days ** ********************* Holidays **************** ** MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY Monday: YES Tuesday: YES Wednesday: YES Thursday: YES Friday: YES Saturday: NO Sunday: NO
Calendar expire date: Calendar start date: 01/01/2007
Date last accessed: Calendar end date : 06/30/2007
On the screen, it appears that the Work Days and Holidays are related. They are not. In other words, Monday holidays do not have to be entered on the first line, Tuesday on the second, etc.The default workdays are Monday through Friday and weekends are Saturday and Sunday. There are no default holidays. You update the Work Days portion of the screen, if your workdays are different from the default days. Use the New Line key to access each of the workday fields. For each day of the week, enter YES if it is a workday; enter NO if it is not a workday. To update the Holidays portion of the screen, enter the date (using the format MM/DD/YYYY) of each holiday your company observes. From the Monday field, use the Tab key to access each holiday date field. You can enter up to 30 holidays on one calendar.
70
3 Calendars
If you are adding a new calendar, enter the date the calendar becomes effective in the Calendar Start Date field and the date it is no longer effective in the Calendar Expire Date field and press Enter.
Note:
Set the Calendar Expire Date for six days after the desired expiration date to ensure proper calculation of OCCURS hits. 5 If you are updating an existing calendar, enter PERIODS on the Command line and press Enter.
ASG-Zeke COMMAND ===> Primary Commands: User Calendar Periods BROWSE
BROWSE CANCEL EDIT Calendar end date : 06/30/2007 Year==> 2007 Type==> USR 02: 28 05: 28 08: 11: 14: 17: 20: 23: Period Period Period Period Period Period Period Period 03: 35 06: 35 09: 12: 15: 18: 21: 24:
Calendar start date: 01/01/2007 ZEKE Calendar ID==> ACCTG1 Period Period Period Period Period Period Period Period 01: 28 04: 28 07: 10: 13: 16: 19: 22: Period Period Period Period Period Period Period Period
Number of slack days between periods: Enter number of days (01-90) in each period and number of slack days (00-40)
Enter the number of days in each period. Each period can have any number of days from 1 up to and including 90. You can enter up to 24 periods; however, only one period is required. For a standard 4 - 4 - 5 fiscal year calendar, enter 35 for Periods 03, 06, 09, and 12. For the remaining periods up to Period 11, enter 28. This assigns 28 days to the first 2 periods of each quarter and 35 to the last period of each quarter, and is useful if your company uses this accounting scheme.
If there are extra days between the end of this fiscal year and the start of the next one, enter that number in the Number of Slack Days field. If slack days are needed and are not entered, an error occurs when the SCHEDULE function is run.
71
Calendar Documentation
The Calendar facility allows you to store and maintain calendar-related documentation. There are three types of calendar documentation that can be stored. Type
Scratch Note
Description
Scratch pad and note documentation each allow you to store up to 10 lines of information for a calendar. These documentation areas are like sticky notes and are used to pass notes from shift to shift, or from one department to another. They can also be used for quick reference information. The operator should always review scratch pad or note pad information before an event runs. Stores up to approximately 450 records
Text
To access calendar documentation

1 From the Zeke Primary Menu, enter 3 and press Enter.Access the Calendar Maintenance Functions screen as instructed in Accessing the Calendar Facility on page 65. Enter DOCUMENT on the Command line and press Enter. The Documentation Segments screen is displayed. If an asterisk (*) is displayed to the left of the documentation type, that type of documentation exists for the calendar.
ASG-Zeke Option ===> Primary Command: DELETE Calid: A Year: **** Documentation Segments
Type: STD
Sdate:
Edate:
Documentation Record Selection Options 1 SCRATCH 2 * TEXT 3 NOTE Scratch pad Text information Note pad information
Enter one of the following codes on the Command line to select the type of documentation you want to add or update: Desired Result
Access scratch pad documentation
Action
Enter 1 and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 73.
72
3 Calendars
Desired Result
Access text documentation Access note documentation
Action
Enter 2 and press Enter. Go to Maintaining Text Documentation on page 74. Enter 3 and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 73.
Maintaining Scratch Pad or Note Documentation

Even though there are separate documentation areas for scratch pad and note information, the screens are identical. This procedure shows the scratch pad as an example, but the note screen works the same way.
To maintain scratch pad or note documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in Calendar Documentation on page 72.
ASG-Zeke Command ==> Primary Commands: BROWSE Documentation Scratch Pad EDIT
CANCEL
DELETE
EDIT
Line 1 USE THIS CALENDAR FOR ALL LEVEL 4 JOBS AND 2 FOR SPECIAL LEVEL 3 JOBS. 3 4 5 6 7 8 9 10 Calendar id : B Workdays : YYYYNNY Calendar year : **** Start date : Calendar type : STD End date :
When adding or updating scratch pad or note information, enter text information in the lined area. You can enter up to 60 characters per line, and up to 10 lines of text. Press Enter to update the data.
73
Maintaining Text Documentation

The text documentation area allows you to define a sizeable amount of information for a calendar (up to approximately 450 records).
To maintain text documentation

1 Access the Text Documentation screen as instructed in Calendar Documentation on page 72.
ASG-Zeke Command ===> Calid: ****** ==MSG> ==MSG> 000001 ****** Text Documentation EDIT Columns 000 000 Scroll ===> PAGE
A Year: **** Type: STD Sdate: Edate: *************************** Top of Data ***************************** -Warning- The UNDO command is not available until you change your edit profile using the command RECOVERY ON. SVP OR HIGHER SIGNATURE REQUIRED TO AUTHORIZE CHANGING THIS CALENDAR ************************** Bottom of Data ***************************
Enter text to the right of the column placeholder field. You can enter up to 80 characters per line, and up to several hundred lines of text. Use standard ISPF editing commands to edit the text. Press F8 to page forward and access an additional screen. Press Enter to update the data.
3 4 5
74
Chapter 4:
Events
4
An event is a unit of work, such as a batch process, program, or command, defined to Zeke and scheduled to occur under a given set of circumstances. Information about the event is gathered to create an event master record (EMR). The EMR includes the date and time to dispatch the event, prerequisite conditions for dispatch, and resource requirements. Topic
Defining Events Event Types Primary Commands Accessing the Event Master Record Defining an Event Template Creating an Event From a Template Copying an Event Maintaining a Job Event Routing a Job Event to Another System or Platform Downloading Jobs to Zeke Agent Maintaining a Message Event Maintaining Command Events Maintaining a REXX Event Defining a Recurring or Permanent Event OCCURS Clauses OCCURS Clause Format Sample OCCURS Clauses Scheduling Events on Holidays and Weekends Defining an OCCURS Clause WHEN Conditions Job and Program WHEN Conditions WHEN Conditions for Multiple Event Versions Extended Dependencies WEAK Conditions Started Tasks Generic Names Multiple WHEN Conditions Zeke Variables as WHEN Conditions NOTDURING Conditions Cross-platform Dependencies
Page
77 77 78 82 86 88 90 92 98 102 104 107 111 114 118 118 126 130 132 135 135 135 136 137 138 138 139 140 142 144 75
Topic
WHEN Condition Keywords Defining a WHEN Condition Viewing WHEN Conditions for All Event Versions Condition Codes Work Centers Variables in Work Centers Setting Up Work Centers Completing Work Centers Auto Replies Maintaining Auto Replies Displaying, Enabling, or Disabling Auto Replies Maintaining JCL Setting JCL Source Options Retrieving JCL from the Zeke Database Event Documentation Accessing Event Documentation Maintaining Scratch Pad or Note Documentation Maintaining Text Documentation Maintaining Dataset Documentation Event Activity Accounting
Page
145 150 151 154 161 161 163 166 171 172 175 176 176 179 181 181 184 185 186 188
76
4 Events
Defining Events
An event can be defined to the Zeke database through either of the following facilities:

Event Master Record Functions screens in the Zeke online facility EVENT function of the Zeke batch utility program
This chapter describes the procedures, as performed using the online facility. For information on performing the same procedures using the Zeke batch utility, refer to your ASG-Zeke for z/OS Reference Guide.
Event Types
The Zeke event types include: Type
JOB MSG WORK VCOM ZCOM SCOM PCOM REXX
Description
Jobstream event Console operator message event Work center event VM CP command event Zeke operator command event System command or system response event POWER command event REXX exec
This section explains how to define and maintain the different types of events.
77
Primary Commands
The following commands are available from most of the Event Master Definitions screens. Uppercase letters indicate each commands abbreviation. Command
ADD AUTorply BROwse CCode COPY
Description
Add an event. Maintain autoreply elements for job events. Browse an event. Maintain condition code information for job events. Copy event information to a new event number. The Event Master Definitions screen is displayed and you are prompted for the new event number.
COPYAll DEACt DELete
Copy all associated event master information. Deactivate an event. The event is not scheduled. Delete an event from the database. The Event Master Definitions screen is displayed and you are prompted to confirm the deletion by entering the DELETE command again. Note: You can delete an event definition only if there are no existing schedule records based on the definition. Otherwise, the existing schedule records must be deleted first.
DOCument EDIT JCL OCCurs
Define or maintain event documentation. Edit an event. Display JCL stored in the Zeke database. Maintain the OCCURS clause for this event.
78
4 Events
Command
PATH
Description
View the predecessors and successors of this event. Note: The DSPIndex generation option must be set to Y in order to use the PATH command.
Optional keywords include:
LEVel
Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all. Julian date to use when the OCCURS clause is resolved. Default is the current date. Version of the event for which to view predecessor/successor information.
PATH VER 3
OCCDate
VERsion
Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1. PATHADD Invoke the Schedule View Add-By Path wizard. The event, level, OCCURS date, version, and path type are auto-filled. Allows you to list predecessors and successors for an event and then schedule events in the list. Note: The DSPIndex generation option must be set to Y in order to use the PATHADD command. LEVel Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all. Julian date to use when the OCCURS clause is resolved. Default is the current date. Version of the event for which to view predecessor/successor information.
PATH VER 3
OCCDate
VERsion
Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1.
79
Command
PREd
Description
View the predecessors of this event. Note: The DSPIndex generation option must be set to Y in order to use the PRED command. LEVel Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all. Julian date to use when the OCCURS clause is resolved. Default is the current date. Version of the event for which to view predecessor/successor information.
PATH VER 3
OCCDate
VERsion
Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1. PREDADD Invoke the Schedule View Add-By Path wizard. (The event, level, OCCURS date, version, and path type are auto-filled.) Allows you to list predecessors for an event and then schedule events in the list. Note: The DSPIndex generation option must be set to Y in order to use the PREDADD command. LEVel Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all. Julian date to use when the OCCURS clause is resolved. Default is the current date. Version of the event for which to view predecessor/successor information.
PATH VER 3
OCCDate
VERsion
Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1. REACt RESOurce RESTart Reactivate an EMR that was previously deactivated. Maintain logical resource control information for job events. Request the restart facility (such as Zebb) for this job event.
80
4 Events
Command
SUcc
Description
View the successors of this event. Note: The DSPIndex generation option must be set to Y in order to use the SUCC command. LEVEL Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all. Julian date to use when the OCCURS clause is resolved. Default is the current date. Version of the event for which to view predecessor/successor information.
PATH VER 3
OCCDATE
VERSION
Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1. SUCCADD Invoke the Schedule View Add-By Path wizard. The event, level, OCCURS date, version, and path type are auto-filled. Allows you to list successors for an event and then schedule events in the list. Note: The DSPIndex generation option must be set to Y in order to use the SUCCADD command. LEVEL Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all. Julian date to use when the OCCURS clause is resolved. Default is the current date. Version of the event for which to view predecessor/successor information.
PATH VER 3
OCCDATE
VERSION
Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1. WHEN Maintain the WHEN conditions for this event. To maintain the dependency for a particular version of the event, enter WHEN followed by the version number (for example, WHEN 2). If you do not enter a version number, it defaults to first version. Enter WHEN followed by an asterisk (WHEN *) to display the different versions of WHEN conditions associated with the event.
81
Accessing the Event Master Record

The Event Master Record Functions screens are used to define or update any type of event, and to access documentation, JCL, auto replies, resources, condition codes, and WHEN conditions for an event.
To access the Event Master Record Definitions screens

1 From the Zeke Primary Menu, enter 1 and press Enter. The Event Master Selection Criteria screen is displayed.
ASG-Zeke Command ===> Event ===> Primary Commands: ADD BROWSE DELETE EDIT Enter a selection mask in any field(s) to be compared for selection. * - is a prefix/suffix indicator. ? - is a wild/place holder character. Selection Field Masks Job Name: Event Name: Application: Group ID: User ID: Drl ID: System: Calendar ID: Occurs: When: Event Master Selection Criteria
Place any character other than a space next to Event Types to be selected.
Event Types Job: Msg: Pcom: Work: Vcom: Zcom: Scom: REXX: Template: Permanent:
Define a new event
Action
If you want to add a new event, enter ADD on the Command line and press Enter. Go to step 3. Enter EDIT on the Command line. Enter the event number in the Event field. Press Enter. The Event Master Definition screen for the selected event is displayed. Perform the appropriate update procedure for the event type you are updating.
Update an existing event for which you know the event number
82
4 Events
Desired Result
Update an existing event, for which you do not know the event number
Action
Enter any character next to the appropriate event type under Event Types and any information you know for any of the Selection Field Masks fields. Press Enter. Go to step 6. Enter Y in the Template field and next to the desired event type. Press Enter. The Event Master Directory is displayed.
View a list of existing templates for a specific event type
Update the documentation, JCL, autoreply, resource, condition codes, or dependency information for an event
Enter any character next to the appropriate event type under Event Types and any information you know for any of the Selection Field Masks fields. Press Enter. Go to step 6.
ASG-Zeke Option ===> Use Template: Y 1 Job 2 Msg 3 Pcom 4 Work 5 Vcom 6 Zcom 7 Scom 8 REXX
Add Event Record Function
Add Add Add Add Add Add Add Add
a a a a a a a a
Job Event Message Event Pcom Event Work Center Event Vcom Event Zcom Event Scom Event REXX Event
Template JCLTEMPLATE MSGTEMPLATE PCOMTEMPLATE WORKTEMPLATE VCOMTEMPLATE ZCOMTEMPLATE SCOMTEMPLATE REXXTEMPLATE
Press PF3/PF15 key to abort the Add request
3 4
In the Option field, enter the option number for the type of event you want to define. In the Use Template field, enter N and press Enter. (For information on using a template, see Creating an Event From a Template on page 88.) The Event Master Definition screen for the selected event type is displayed.
Depending on the type of event you are adding, go to the appropriate procedure. Event Type
Job Msg PCOM, VCOM, ZCOM, SCOM Work
Procedure
Maintaining a Job Event on page 92 Maintaining a Message Event on page 104 Maintaining Command Events on page 107 Setting Up Work Centers on page 163 83
Event Type
REXX
Procedure
Maintaining a REXX Event on page 111
The Event Master Directory screen is displayed.

ASG-Zeke Command ===> Event Master Directory Scroll ===> PAGE
Primary Commands: ADD Line Commands: E/En - Edit B/Bn - Browse D/Dn - Delete n = 1 through 7 for the specific part of Event as listed below. 1 2 3 4 5 6 7 Event Event Jobname Evt DOC JCL Auto Rsrc Cond Occ Whn Number Name Type Repl Codes ========================================================================== 000001 ZEKE51TST1 MSG * * 000002 ZEKE51TST2 MSG * * 000003 ZEKE51TST3 MSG * * 000004 ZEKE51TST4 MSG * * 000005 ZEKE51TST5 MSG * * 000006 ZEKE51TST6 TSKKGUT1 JOB * * * * 000007 ZEKE51TST7 TSKKGUT2 JOB * * * * 000008 ZEKE51TST8 TSKKGUT3 JOB * * * 000009 ZEKE51TST9 TSKKGUT4 JOB * * * 000010 ZEKE51TST10 TSKKGUT5 JOB * * * 000011 ZEKE51CC SPTEXD11 JOB * * * * 000012 ZEKE51CC SPTEXD12 JOB * * * * 000013 WORK * * 000014 VCOM *
An asterisk in one of the columns at the right side of the screen indicates that a record of that type exists for this event. For example, an asterisk in the Cond Codes column indicates that condition code information exists for this event. 6 Perform the steps in the Action column in the following table, depending on the desired result. Desired Result
Update the EMR
Action
Enter E in the unlabeled Selection field to the left of the event you want to update, and press Enter. The Event Master Definition screen for the selected event is displayed. Perform the appropriate update procedure for the event type you are updating.
Delete the EMR
Enter D in the unlabeled Selection field to the left of the event you want to update, and press Enter. The Event Master Definition screen for the selected event is displayed. Press Enter to confirm the deletion. This procedure is complete.
84
4 Events
Desired Result
Action
Update the Enter E1 in the unlabeled Selection field to the left of the event documentation for an you want to update, and press Enter. event Go to Event Documentation on page 181. Update the online JCL for an event Enter E2 in the unlabeled Selection field to the left of the event you want to update, and press Enter. Go to Maintaining JCL on page 176. Update the auto reply Enter E3 in the unlabeled Selection field to the left of the event segments for an event you want to update, and press Enter. Go to Maintaining Auto Replies on page 172. Update the logical resources for an event Update the condition codes for an event Enter E4 in the unlabeled Selection field to the left of the event you want to update, and press Enter. Go to Maintaining Logical Resources on page 274. Enter E5 in the unlabeled Selection field to the left of the event you want to update, and press Enter. Go to Condition Codes on page 154. Update the OCCURS Enter E6 in the unlabeled Selection field to the left of the event clause for an event you want to update, and press Enter. Go to Defining an OCCURS Clause on page 132. Update the WHEN conditions for an event Enter E7 in the unlabeled Selection field to the left of the event you want to update, and press Enter. Go to Defining a WHEN Condition on page 150.
85
Defining an Event Template

Events that are in the same cycle are often defined with similar event information. Event templates eliminate the repetitive task of defining the same information over and over for multiple event records. An event template is used as a model when creating new events of a particular event type (such as job events). When you create an event from a template, all of the templates information is copied over to the new event including documentation, JCL, OCCURS clause, WHEN conditions, etc. A template is basically a normal event, except that it can never be scheduled. To create a certain type of event from a template, you must use a template of that type. For example, you cannot use a job event template to create a work center event. Zeke does not limit the number of templates that can be defined for each event type. Each user can define their own set of template names.
To define an event template

1 Access the Event Master Record Functions screen for the type of event you want to define a template for (such as job events) as instructed in the procedure, Accessing the Event Master Record on page 82.
ASG-Zeke Command ===> Event Master Definition EDIT
Event===> Primary Commands: ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN Template: Y Permanent: N Milestone: N Platform: MVS Evt: 243 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK51RJEABC App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A Control: Y Tapes: 000 Avgdur: 00:00:00
Job: TSKKGUT1 JCL--> PDS: Member: Zeke JCL (Y=Yes): Y
Class: CMS:
Pri: Ftype:
Enter an event name for the template. The event name is the identifier that will be used for selecting a template to create a new event. Continue to define the event as described earlier. Define all the fields that you want each new event created from this template to share.
86
4 Events
Enter Y in the Template field to indicate that this event is a template and can be used as a model for creating new events of this type. Press Enter. The changes are saved and an event number is assigned.
Optionally, deactivate the event template using the DEACT command. It is not necessary to deactivate a template, because templates are never scheduled. However, we recommend that you perform this step so that new events created from the template are not scheduled until you activate them. If you want each new event created from this template to share the same OCCURS clause, perform the procedure, Defining an OCCURS Clause on page 132. If you want each new event created from this template to share the same WHEN conditions, perform the procedure, Defining a WHEN Condition on page 150.
87
Creating an Event From a Template

To create a certain type of event from a template, you must use a template of that type. For example, you cannot use a job event template to create a work center. An unlimited number of templates can be defined for each event type. See Defining an Event Template on page 86 for more information on event templates.
To create an event from an existing event template

1 Access the Add Event Record Function screen as instructed in Accessing the Event Master Record on page 82.
ASG-Zeke Option ===> Use Template: Y 1 Job 2 Msg 3 Pcom 4 Work 5 Vcom 6 Zcom 7 Scom 8 REXX Add Event Record Function
Add Add Add Add Add Add Add Add
a a a a a a a a
Job Event Message Event Pcom Event Work Center Event Vcom Event Zcom Event Scom Event REXX Event
Template JCLTEMPLATE MSGTEMPLATE PCOMTEMPLATE WORKTEMPLATE VCOMTEMPLATE ZCOMTEMPLATE SCOMTEMPLATE REXXTEMPLATE
Press PF3/PF15 key to abort the Add request
In the Use Template field, enter Y to indicate that you want to create the new event from an existing event template. Tab to the Template field for the type of event you want to define and type the event name of the template you want to use. Enter the option for the type of event you want to define. To view a list of existing templates for a specific event type, go to the Event Master Record FunctionsBrowse screen (see Accessing the Event Master Record on page 82) and enter Y in the Template field and next to the desired event type.
Note:
If you have more than one template defined with the same name and the same event type, Zeke will use the template with the lowest event number. For example, if you have a job event template called JOBTEMPLATE that was assigned event number 12, and another job event template called JOBTEMPLATE that was assigned event number 34, Zeke will use the template with the event number 12.
88
4 Events
The Event Master Definition screen for the selected event type is displayed in update mode (a job event in this example).
Event===> Primary Commands: ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN Template: N Permanent: N Milestone: N Platform: MVS Evt: 243 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK51RJEABC App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A Control: Y Tapes: 000 Avgdur: 00:00:00
Class: CMS:
Pri: Ftype:
All the information that was defined in the template is copied over to the new event, with the exception that the Template field is changed to N. 3 Update the information as necessary. We recommend that you change the event name from the original template name to a new name. This will make it easier to distinguish between the template and the actual events created from that template. Press Enter. The changes are saved and an event number is assigned. If necessary, activate the event using the REACT command. If necessary, perform the procedure, Defining an OCCURS Clause on page 132 to specify when the event should be added to the schedule. If necessary, perform the procedure, Defining a WHEN Condition on page 150 to specify any prerequisites that must occur before the event can be dispatched.
4 5 6
89
Copying an Event
If you want to define an event that is similar to an existing event, and you do not have a template to create the event from, you can copy the existing event. If you will be creating a number of similar events, it is best to use a template.
To copy an event
1 Access the Event Master Definition screen, as instructed in Accessing the Event Master Record on page 82, for the event you want to copy.
Class: CMS:
Pri: Ftype:
Copy the EMR, OCCURS, and dependency information Copy all the EMR data
Action
Enter COPY on the Command line.
Enter COPYALL on the Command line.
The following message is displayed:

Z041I EVENT xxxxxx HAS BEEN COPIED TO EVENT yyyyyy
where xxxxxx is the original event number and yyyyyy is the new event number. Make a note of the new event number. Caution! The original event that was copied is still displayed. You need to access the newly created event before you make any changes. Otherwise, you will inadvertently change the original event information.
90
4 Events
To access the new event: a b c Press F3 to return to the Event Master Record Directory screen. Scroll down to the new event. Enter the E line command beside the event number. The Event Master Definition screen is redisplayed in Edit mode with the new EMR data. Edit the information as needed and press Enter to update the record.
Note:
If you copied a template using this procedure, the Template flag was set to N. If you want the newly created event to be a template, set this flag to Y.
91
Maintaining a Job Event

A job event, the most commonly-used event type, executes a specified jobstream.
To define or maintain a job event

1 Access the Event Master Definition screen for job events, as instructed in Accessing the Event Master Record on page 82.
Class: CMS:
Pri: Ftype:
Enter information in the following fields to define a job event. Field

Desc/Desc2
Description
User-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event. Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. End-of-Event (EOE), abnormal-end-of-event (AEOE) and End of Group (EOG) WHEN conditions and operator commands use the event name. Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs; be sure to enter the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.
Event Name
Usrid
92
4 Events
Field
System
Description
System or pool that owns the event. An event is associated only with one system. This is the system the event is dispatched from, not necessarily the system the EMR is defined on. Number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load using the ZADD command (up to 32,767 versions). See Creating Multiple Versions of an Event on page 97 for details on multiple event versions. Note: The SKIP(OFF) attribute is applied to the end of the Target field (the previous field on the EMR), to prevent a user from overtyping data intended for the Target field so that it overflows into the Verload field. Stray characters in the Verload field could result in an excessive number of events being scheduled unintentionally during the next schedule build cycle.
Verload
Sched
Normal schedule time for this event. The default is 00:00, which means this event is dispatched according to WHEN conditions instead of by time. See "Specifying a Schedule Time" on page 96 for a detailed explanation of schedule time.
Control
Code indicating whether this event is executed and tracked as a Zeke-controlled event. Note: Zeke does not support multiple jobs per event. Each job should be placed in a separate event. Any additional jobs in the same event are considered non-Zeke jobs. Code Y Meaning (Default.) Zeke recognizes the event as a Zeke-controlled event. Zeke-controlled events are tracked throughout the entire execution. Zeke does not recognize this event as Zeke-controlled and marks the job as DONE upon dispatch.
93
Field
Description
NX Zeke recognizes the event as a non-executable Zeke-controlled event. Non-executable events are scheduled like any other event, and are useful as predecessors to other events. A non-executable event is never submitted to JES for JCL execution. After dispatch, the event status automatically changes to indicate success and any dependent events are triggered. Note: An event you want to remove from an intricate event flow can simply be marked as non-executable as an alternative to changing the event flow, which typically means having to delete the event and then modify the WHEN clauses for all of the deleted events successors.
Tapes
Number of physical tape drives (0-255) the job requires. The event is dispatched when the specified number of drives is free. If it is time to dispatch and the drives are not free, Zeke informs the operator the event is waiting on drives. Zeke can calculate this value automatically, or you can manually enter a value. You can also make an entry to override the calculated number, if desired. Default is zero. If you leave this field at zero and tapes are required, operator intervention might be necessary the first time the job runs under Zeke control. If the Calctap generation option is set to Yes, then Zeke automatically calculates this number based on the last time this job was run and displays the value with an asterisk to indicate it is Zeke-calculated (see Calculating Tape Drive Usage on page 305). If Calctap=Yes and you manually override the Zeke-calculated value, then Zeke will not calculate the tape value again until you reset the tape value to zero. To reset the tape value, enter three blank spaces in the Tape field.
Job
Name of the job in the JCL. This name displays on screens and in messages and is used by Zeke to track the event during execution. This field must match the jobname on the job card for proper tracking. Up to 6 classes for the event. When the event is ready to run, Zeke selects an initiator according to the class defined. If no class is specified, the value specified for the Defdspcl generation option is used. If Defdspcl is not defined, Zeke selects any free initiator defined to it. See Defining Initiators to Zeke on page 269. This field is valid only if the generation option Dispsel is set to Yes. Yes is the default for Dispsel.
Class
94
4 Events
Field
JCL
Description
JCL source library and member information. Library Field Entries
Bim-Edit BIMJCL source library MemberBIM member name Condor JCL source library and Condor version
Librarian JCL source library and Librarian member name Panvalet PDS JCL source library and Panvalet member name PDS member dataset DD name; must be present in the Zeke started task procedure MemberPDS member name CMS JCL source library and CMS file name FtypeCMS file type of the JCL file
Enter information in the following fields to group events for selection for reports or scheduling. Report Writer, Work Center Control, and Zeke operator commands use these fields to sort and select events Field
App Grp
Description
User-assigned code to identify the application the event is a part of. User-assigned code to identify the group the event is a part of. This field is a subset of the application ID.
Press Enter. The changes are saved and the screen is displayed in update mode. If you are adding the event, an event number is assigned.
Perform the procedure Defining an OCCURS Clause on page 132 to specify when the event should be added to the schedule. Perform the procedure Defining a WHEN Condition on page 150 to specify any prerequisites that must occur before the event can be dispatched.
95
Specifying a Schedule Time

Schedule time is an optional dispatching prerequisite that must be met before an event can be dispatched. The schedule time fields are Sched, Early, Late, Mustend, and Notafter. If the time the event is dispatched does not matter, leave these fields blank (00:00). However, if the event must be dispatched by a certain time or cannot be dispatched after a certain time, use the schedule times fields to place restrictions on the time of day an event can execute.
Note:
For an explanation of Zekes 48-hour clock (known as DaySpan), which lets you schedule according to a logical day, see Logical Day (48-hour Clock) on page 192. Use the following table to determine which schedule time fields, if any, your events need to use: Desired Result
Schedule the event at a specific time
Action
In the Sched field, enter the normal schedule time for this event. If the time is greater than 24:00, Zeke knows the event is to be processed the next day. The default is 00:00, which means this event is scheduled according to WHEN conditions, instead of by time.
Set the earliest time an In the Early field, enter the earliest time this event can be dispatched. event can be dispatched An event can be dispatched at its early time as long as the WHEN conditions are satisfied. However, the events are dispatched in schedule time sequence. For example, an event is set up to run at 12:00 P.M., but can run as early as 11:00 A.M. if an initiator is available. Note: Use the early time to schedule a group of related events that normally run together or are dependent on each other. Specify the same early time and specify the groups schedule time in the required order. The schedule command displays will be easier to read as a result. If the events are dispatched early, they are still processed in the correct order. Set the time an event is considered late In the Late field, enter the time the event is considered late if it has not been dispatched. If the late time is reached and the event is not dispatched, a message is issued to the operator. For example, if an event is scheduled to run at 12:00 P.M. with a late time of 13:00, the event is considered late if it is not dispatched by 1:00 pm. If the generation option Prilate is set to Y, late events are dispatched before events that are not late, regardless of the schedule time.
96
4 Events
Desired Result
Set the time the event must complete processing by
Action
Enter the latest time the event can complete processing in the Mustend field. Prior to dispatch, Zeke adds the current system time and the events average duration. If the result is greater than the Mustend time, a message is issued to the console and the event is removed from the dispatch queue. For example, the Mustend time is 14:00, the system time is 13:00 and the average duration is 2 hours. Since the event would not complete until 15:00, the event is not dispatched.
Set the latest time an Enter the latest time an event can be dispatched in the Notafter field. event can be dispatched Prior to dispatch, Zeke compares the system time and the Notafter time. If the Notafter time is less than the system time, the event is no longer time satisfied. Zeke issues a message to the console and removes the event from the dispatch queue.
Creating Multiple Versions of an Event

Events can be defined to have multiple SQRs with the same schedule date. These are referred to as versions of the event. An event can have up to 32,767 versions. Each version of an event operates independently of all other versions of the same event. For instance, you can add a JCL override for one version without affecting other versions of the same event. Each version of an event shares the same OCCURS clause, but can have different WHEN conditions defined for it. Zeke operator commands can select events by version number for processing, and WHEN conditions can trigger off of version numbers. Multiple versions of the same event all have the same jobname; therefore, they cannot execute concurrently due to JES limitations. (Zeke provides a user exit, ZEKE02OX, to allow you to change the jobnames as events are added to the schedule. Refer to your ASG-Zeke for z/OS Installation Guide for more information on ZEKE02OX.) You use the Verload field on the Event Master Definitions screen to define the number of versions for an event. Then, you can define WHEN conditions based on a specific version number for that event.
97
Routing a Job Event to Another System or Platform

Zeke can route or send the JCL for a job event to another system or platform for execution. When the job has finished executing, the data or information can be sent back to the original Zeke for triggering other events. For example, you can route JCL from one operating system to another, or from a z/OS system to an OS/400. Zeke remote jobs support condition code processing (except if *Rmtlim is specified, see below) as well as logical resource usage. All trigger types are supported except dataset name and variable name, and all accounting information is updated in the EMR. Auto replies are not supported for remote jobs and NOTDURING conditions that reference remote jobs are not supported. To route a job to another system or platform, enter Target and Platform information on the EMR screen. Generally, the system programmer sets up the Posid and Netregid generation options.
To route a job event to another system or platform

1 Ensure that the Posid and Netregid generation options for your system are properly set-up with Posid=Y and a valid, non-blank Netregid. See "Maintaining Networking Options" on page 307. Access the Event Master Record FunctionsJob Events screen as instructed in the procedure,Accessing the Event Master Record on page 82.
Class: CMS:
Pri: Ftype:
Enter the information indicated in Maintaining a Job Event on page 92.
98
4 Events
Note:
If the remote system is using security, the Usrid field must be defined as a valid user ID on the remote system. 4 Enter the routing information in the following fields. Field
Target
Description
Enter a value to indicate how to handle routing. Note: Although the Target field appears in the Event Master Definition screen for all events, it currently applies to job events only. The target field defaults to *LOCAL for all other event types. Code Remote system DMS logical name Meaning Remote Zeke or Zeke Agent Netregid. This is the only type of remote processing where the dispatching and execution platform can be different. Zeke dispatches individual jobs to DMS, which routes them to the specified system, where they are submitted and monitored. The level of communication between the dispatching Zeke and the remote job is based on the jobs condition code processing requirements. If the specified system is a Zeke Agent defined as a download agent, then SQRs are downloaded via DMS, where they are tracked and executed. See Defining Schedule Download Agents on page 301. *R or *REMOTE The job instructions must contain the necessary NJE statements or parameters to route the job. Zeke dispatches and submits the job on the same system. Then NJE routes the job to the remote system for monitoring. The level of communication between the dispatching Zeke and the remote job is based on the jobs condition code processing requirements.
99
Field
Description
*RL or *RMTLIM Similar to *REMOTE. Zeke dispatches and submits the job on the same system. Then NJE routes the job to the remote system. The remote job sends all trigger information back to the dispatching Zeke, but executes independently. The dispatching Zeke monitors the remote job execution, but maintains no control over it. This type of remote job cannot be cancelled due to condition code processing. Similar to *REMOTE. Zeke dispatches and submits the job on the same system. Then NJE routes the job to the remote system. The executing job waits at each step for a reply from the dispatching Zeke before continuing. If for any reason the remote job loses communication with the dispatcher, it is cancelled at the remote site before trigger information is lost. This option can result in significantly more network traffic than *REMOTE. The dispatching Zeke maintains maximum control over the job.
*RF or *RMTFUL
Note: Values of *REMOTE, *RMTFUL, and *RMTLIM can only be used when the JOB is being routed to another system of the same platform as the dispatching system. If attempting to route from a z/OS system to a VSE, AIX, or OS/400 system, you must use a Netregid for the Target value. If routing to a like platform, for example, one VSE system to another VSE system, either the Netregid or *REMOTE values can be used for Target. Note: The SKIP(OFF) attribute is applied to the end of the Target field (the previous field on the EMR), to prevent a user from overtyping data intended for the Target field so that it overflows into the Verload field. Stray characters in the Verload field could result in an excessive number of events being scheduled unintentionally during the next schedule build cycle. This change requires you to press the Tab key after typing eight characters in the Target field to move to the Verload field. If you attempt to type beyond the end of the Target field, your keyboard will lock and you will have to press Reset and then the Tab key to continue.
100
4 Events
Field
Platform
Description
Indicate the operating system on which the event is executed. Zeke defaults to the value of the generation option Defpltfm. Valid values are: AIX DCOSX HPUX MVS OS2 OS400 SUN TANDEM USYS UNIX Includes all UNIX platforms: AIX, AT&T, HPUX, NCR, SCO, SunOS, Sun Solaris, etc. Includes z/OS. Pyramid.
VMS VSE WINDOWS Includes all supported versions.
Note: Although the AIX, HPUX, and SUN platform codes listed above are supported, it is preferred that you use the UNIX platform code. Zeke does not download jobs that have a platform of MVS or VSE.
101
Perform the procedure, Defining an OCCURS Clause on page 132, to specify when the event should be added to the schedule. Perform the procedure, Defining a WHEN Condition on page 150, to specify any prerequisites that must occur before the event can be dispatched.
Downloading Jobs to Zeke Agent

Zeke allows you to download a subset of scheduled jobs in the Zeke schedule cross-platform to Zeke Agent. Zeke Agent then tracks and dispatches the SQRs in the same manner as Zeke would. Zeke Agent satisfies the time and when conditions for the downloaded jobs and dispatches the jobs when those conditions are met. The downloaded schedule can run stand-alone on Zeke Agent, even when the OASIS/DMS connection to Zeke is interrupted, as long as Zeke Agent can satisfy the predecessors for the SQR locally. Zeke can also schedule an individual event directly to a Zeke Agent system running on another platform. Zeke Agent can receive, track, schedule, execute, and re-route a scheduled job from Zeke (or another source) to another platform in your enterprise, as necessary.
To download a job event to Zeke Agent

1 Ensure that the Posid and Netregid generation options for your system are properly set-up with Posid=Y and a valid, non-blank Netregid. See "Maintaining Networking Options" on page 307. Access the Event Master Record FunctionsJob Events screen as instructed in the procedure,Accessing the Event Master Record on page 82.
Class: CMS:
Pri: Ftype:
102
4 Events
Enter the information indicated in Maintaining a Job Event on page 92.

Note:
If the remote system is using security, the Usrid field must be defined as a valid user ID on the remote system. 4 Enter information about the Zeke Agent in the following fields. Field
Target
Description
Remote Zeke Agent Netregid. Be sure the specified system is a Zeke Agent system defined as a download agent. See Defining Schedule Download Agents on page 301.
Platform
Operating system of the Zeke Agent system on which the event is to be downloaded. Defaults to the value of generation option Defpltfm. Enter UNIX.
103
Maintaining a Message Event

A message event can be any message you want to issue to the system console. Many sites have certain consoles set up to receive certain messages. For example, the console for tape mounting only receives messages with route code=3, and the printer console only receives messages with route code=7. All messages and route codes are logged to the SYSLOG hardcopy file, regardless of the console that received them. For example, if you want the tape mount console operator to send a certain tape offsite after a job is complete, you would set up a message event with a route code=3 and the following message:
Send tape offsite; dependent on good EOJ of the job.
You could also set up your automation software to intercept the message and issue a command to eject the tape from the automated tape library. You can issue up to six lines of message text.
To define or maintain a message event

1 Access the Event Master Definition screen for message events as instructed in Accessing the Event Master Record on page 82.
ASG-Zeke Command ===> Event Master Definition BROWSE
Event===> Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT OCCURS PATH PRED REACT RESOURCE SUCC WHEN Template: N Permanent: N Milestone: N Evt: 482 Desc: OFFSITE CASH RUN TAPE Type: MSG Desc2: MONTHLY Event Name: ZECASTPOFF App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00004 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A Control: Y Route: (3) Oper Oper Oper Oper Oper Oper Msg1: END TAPE OFFSITE; DEPENDENT ON GOOD END OF JOB Msg2: Msg3: Msg4: Msg5: Msg6:
104
4 Events
Enter the appropriate information in the following fields to define a message event. Field
Template
Description
If you are defining a template, enter Y in this field. Otherwise, leave the default N. User-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event. Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. EOE, AEOE, and End of Group (EOG) WHEN conditions, and operator commands use the event name. If you are creating this event from a template, change this name to differ from the template. Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs. Be sure to enter the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.
Desc/Desc2
Event Name
Usrid
System
System or pool that owns the event. An event is associated with one system only. This is the system the event is dispatched from, not necessarily the system the EMR is defined on. Number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load using the ZADD command (up to 32,767 versions). See Creating Multiple Versions of an Event on page 97 for more information. Note: The SKIP(OFF) attribute is applied to the end of the Target field (the previous field on the EMR), to prevent a user from overtyping data intended for the Target field so that it overflows into the Verload field. Stray characters in the Verload field could result in an excessive number of events being scheduled unintentionally during the next schedule build cycle.
Verload
105
Field
Sched
Description
Normal schedule time for this event. The default is 00:00, which means this message is issued according to WHEN conditions instead of by time. User-assigned route code that corresponds to the alternate console route code. Message text to issue to the system operator console. The message event can contain up to 6 lines.
Route
Oper Msg
Enter information in the following fields to group events for reports or scheduling. The Report Writer, Work Center Control, and Zeke operator commands use these fields to sort and select events. Field
App Grp
Description
User-assigned code to identify the application the event is a part of. User-assigned code to identify the group the event is a part of.
Perform the procedure, Defining an OCCURS Clause on page 132 to specify when the event should be added to the schedule. Perform the procedure, Defining a WHEN Condition on page 150 to specify any prerequisites that must occur before the event can be dispatched.
106
4 Events
Maintaining Command Events

Command events issue specified commands to a specified destination. Several types of command events are available with Zeke. Command Type
SCOM
Description
Any command that can be issued from a console. You can enter an unlimited number of commands within each SCOM event. A security call will be made for each individual command line in an SCOM. See Security Calls on page 365 for more information.
ZCOM PCOM VCOM
Any valid Zeke operator command or combination of commands. Any valid POWER command for VSE systems. Any valid VM CP command.
SCOM events can issue any type of console command, and can be used instead of the other command event types (ZCOM, PCOM, and VCOM), which can only issue specific types of commands. This procedure describes how to define an SCOM event. If you choose to use the other types of command events, you define them in a similar manner.
107
To define and maintain a system command event

1 Access the Event Master DefinitionSCOM screen as instructed in Accessing the Event Master Record on page 82.
ASG-Zeke Command ===> Event Master Definition BROWSE
Event===> Primary Commands: ADD BACK BROWSE COPY COPYALL DEACT DELETE DOC EDIT NEXT OCCURS PATH PRED REACT RESOURCE SUCC TOPPAGE WHEN Template: N Permanent: N Milestone: N Evt: 458 Desc: RESUB MJP JOBS Type: SCOM Desc2: Event Name: LJDSCOM App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A Control: Y Code => Code: C Code: C Code: Z Code: Z Code: Z Code: Z Code: Z C=Sys Cmd R=Sys Response Z=Zeke Cmd 001 D T 002 $DI 003 ZINFO 001 ZADD EV 27 VER 1 REBUILD 002 ZADD EV 28 VER 1 REBUILD 003 ZADD EV 28 VER 2 REBUILD 004 ZADD EV 29 VER 1 REBUILD V=VM Cmd P=VSE/POWER Cmd
__ __ __ __ __ __ __
Enter the appropriate information in the following fields to define an SCOM event. Field
Template
Description
If you are defining a template, enter Y in this field. Otherwise, leave the default N. User-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event. Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. EOE, AEOE and End of Group (EOG) WHEN conditions and operator commands use the event name. If you are creating this event from a template, change this name to differ from the template. Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs; be sure to enter the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID applies to Zeke internal security only.
Desc/Desc2
Event Name
Usrid
108
4 Events
Field
System
Description
System or pool that owns the event. An event is associated only with one system or pool. This is the system the event is dispatched from, not necessarily the system the EMR is defined on. Number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load by using the ZADD command (up to 32,767 versions). See Creating Multiple Versions of an Event on page 97 for details on multiple event versions. Note: The SKIP(OFF) attribute is applied to the end of the Target field (the previous field on the EMR), to prevent a user from overtyping data intended for the Target field so that it overflows into the Verload field. Stray characters in the Verload field could result in an excessive number of events being scheduled unintentionally during the next schedule build cycle.
Verload
Sched
Normal schedule time for this event. The default is 00:00, which means this command is issued according to WHEN conditions instead of by time. Code indicating the type of command: Code C R Z V P Meaning System command System response Zeke command VM command VSE/POWER command
Code
109
Field
Line 001 through Line 005
Description
Up to 60 characters of commands or responses per line. Only the first line is required. To access additional command lines, position the cursor on any SCOM line except the first one and press Enter. The screen is redisplayed with new blank lines. Existing SCOM lines following the cursor are not displayed. Enter as many new lines as necessary and press Enter. The new lines are added to the EMR and the existing lines are redisplayed. When entering multiple Zeke commands on one line, include the command prefix on the first command only. For example, if your command prefix is ASG, you would code multiple commands in an SCOM event like this:
C 001 ASGZAD EV 12 HOLD ZAD EV 89 HOLD
When using variable substitution in an SCOM event, the length of each line must be no greater than 60 bytes, including the variable values. For example, suppose you submit the following SEND command from an SCOM event:
SE THIS IS A TEST TEST TEST TEST TEST.,USER=($ABCVAR)
Assume the value of the variable $ABCVAR equals ABCABCABCABCABC. The length of the command as it appears above is exactly 60 bytes. However, once variable substitution is performed for $ABCVAR, the length of the line will exceed 60 characters.
Enter information in the following fields to group events for reports or scheduling. Report Writer, Work Center Control, and Zeke operator commands use these fields to sort and select events. Field
App Grp
Description
A user-assigned code to identify the application the event is a part of. A user-assigned code to identify the group the event is a part of.
110
4 Events
Maintaining a REXX Event

A REXX event lets you dispatch and monitor REXX execs.
To define and maintain REXX events

1 Access the Event Master Definition screen for REXX events as instructed in Accessing the Event Master Record on page 82.
Event===> Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT OCCURS PATH PRED REACT RESOURCE SUCC WHEN Template: N Permanent: N Milestone: N Evt: 458 Desc: RESUB MJP JOBS Type: REXX Desc2: Event Name: LJDREXX App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A Control: Y
REXX exec: REXX1 Argument:
Class: A
Pri: 1
Enter the appropriate information in the following fields to define a REXX event. Field
Template
Description
If you are defining a template, enter Y in this field. Otherwise, leave the default N. User-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event. Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. EOE, AEOE and End of Group (EOG) WHEN conditions and operator commands use the event name. If you are creating this event from a template, change this name to differ from the template.
Desc/Desc2
Event Name
111
Field
Usrid
Description
Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs. Be sure to enter the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID applies to Zeke internal security only.
System
System or pool that owns the event. An event is associated only with one system. This is the system the event is dispatched from, not necessarily the system the EMR is defined on. Number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load using the ZADD command (up to 32,767 versions). See Creating Multiple Versions of an Event on page 97 for details on multiple event versions. Note: The SKIP(OFF) attribute is applied to the end of the Target field (the previous field on the EMR), to prevent a user from overtyping data intended for the Target field so that it overflows into the Verload field. Stray characters in the Verload field could result in an excessive number of events being scheduled unintentionally during the next schedule build cycle.
Verload
Sched
Normal schedule time for this event. The default is 00:00, which means this command is issued according to WHEN conditions instead of by time.
112
4 Events
Field
Control
Description
Enter the code indicating whether this event is executed and tracked as a Zeke-controlled event. Code Y Meaning (Default.) Zeke recognizes the event as a Zeke-controlled event. Zeke-controlled events are tracked throughout the entire execution. A Zeke-controlled REXX event is completed with either a status of EOE or AEOE. An EOE status is assigned if the exec completes with a return code of 0. Zeke does not recognize this event as Zeke-controlled. A REXX event that is not Zeke-controlled is completed with a status of EOE. Zeke recognizes the event as a non-executable Zeke-controlled event.
NX
REXX exec
Name of member that contains the REXX. The dataset that contains this member must be defined in the SYSEXEC or SYSPROC DD concatenation of the OASIS ECF address space started task. Note: The Zeke installation library contains the member REXSAMP, a sample REXX program for maintaining control over the status (EOE or AEOE) of the event.
Class
OASIS/ECF exec class the REXX exec is associated with. Valid classes are A through Z and 0 through 9. Refer to your ASG-OASIS for z/OS Reference Guide for more information. OASIS ECF exec queue priority. Valid priorities are 1 through 9, where 1 is the highest priority. The default is 5. Priority is used only if there is no free ECF task for the specified class when the event is dispatched. If so, the request is queued and this priority is used to determine which exec for the class executes when a task is available. Argument string to be passed to the REXX exec when it is dispatched. The strings values can be parsed into local REXX variables in the exec.
Pri
Argument
113
App Grp
Description
User-assigned code to identify the application the event is a part of. User-assigned code to identify the group the event is a part of.
Press Enter. The changes are saved and the screen is displayed in Update mode. If you are adding the event, an event number is assigned.
Defining a Recurring or Permanent Event

A recurring event is scheduled to occur more than once per schedule period. For example, a message issued to the operator every hour is a recurring event. The following statements are true for recurring events:
If a recurring event has a Not After time specified and the calculated start time is greater than the Not After time, the event is not rescheduled and is considered done. Recurring events that have reached DONE status at least once and are scheduled to run again will display in the output for both the ZD DONE and ZDISPLAY operator commands.
A permanent event is never removed from the schedule so that it is always available to respond to triggers, even during schedule load processing. It can run an unlimited number of times. You activate a permanent event by adding it to the schedule with the ZADD operator command. The event occurs across every schedule period until you deactivate it using the ZDELETE command.
114
4 Events
Zeke processes permanent events much like recurring events, with the following additional exceptions:

The OCCURS clause is forced to REQUEST. Non-workday options in the calendar are ignored. Only one version can be active (Verload=0). The event cannot be downloaded to Zeke Agent. The event can be triggered by any date. The values of generation options Trigdte, Dsntrig, and Remtrig are treated as any (A or TA). Any Multhit generation options are ignored.
To define a recurring or permanent event

1 Access the Event Master Definition screen as instructed in Accessing the Event Master Record on page 82.
Event===> Primary Commands: ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN Template: N Permanent: N Milestone: N Platform: MVS Evt: 243 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK51RJEABC App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 003 Freq: 00:30 Freqcalc: S Trig: A Control: Y Tapes: 000 Avgdur: 00:00:00
Class: CMS:
Pri: Ftype:
115
Complete the following fields, as applicable: Field

Permanent
Description
Code indicating whether the event is to remain in the schedule permanently/indefinitely. N Default. Event is processed by each schedule run according to the OCCURS clause. Event must be added to the schedule using ZADD. After it has been added, the event remains in the schedule even across schedule runs until it is deleted using the ZDELETE command.
Times
Number of times the event is to be dispatched per schedule run. For a recurring event, valid values are 2 through 255. For a permanent event, do not set a Times value; Zeke considers the number of times to be unlimited, and the value is displayed as 000. Note: If a permanent event is later changed to be non-permanent, Zeke automatically sets the Times value to 1.
Freq
Amount of time a recurring event is to wait before dispatching again. To determine the next schedule time, Zeke adds the value in this field to the current system time or the current schedule time, depending on the Freqcalc value. If you set Freq=00:00, the recurring or permanent event is marked as time-satisfied immediately after each completion. As soon as the WHEN condition (if any) is also satisfied, the event is dispatched. Note: For a permanent event, when the next schedule time passes 24:00, the run date is set to the current date.
Freqcalc
Code indicating how to calculate the next dispatch time for the recurring event. S Zeke schedules the event by the scheduled start time, regardless of the time the event actually runs. If the event is held up for some reason, any missed runs are dispatched immediately. Zeke schedules the event based on the completion time of the previous run. The current time and the Freq time are used to determine the next dispatch time. If Zeke has been down, any missed runs are dispatched according to the FREQ value.
116
4 Events
Field
Trig
Description
Applies to recurring events only. Code indicating when the recurring event can satisfy WHEN conditions (i.e., serve as a trigger) for other events. A (Default) The recurring event can trigger other events each time it runs. Note: Permanent events (i.e., recurring events which can occur an unlimited number of times) always trigger on all occurrences. F The recurring event can only trigger other events the first time it runs. The recurring event can only trigger other events the last time it runs.
For example, for a recurring event, you might use the following values: Times 24
Freqcalc S (schedule time) Freq Trig Start Time 01:00 (1 hour) F 8:00
This event is scheduled to run at 8:00 and then Zeke adds the schedule time (8:00) to the FREQ (one hour) and schedules the event to recur at 9:00. This continues until the event is dispatched the specified number of TIMES (24). The event can satisfy WHEN conditions only on the 8:00 run. All subsequent trigger calls for this event are ignored (until the event is rebuilt or refreshed). Changing Trig to A would allow the event to satisfy WHEN conditions every hour, on all 24 runs.
Perform the procedure Defining an OCCURS Clause on page 132 to specify when the event should be added to the schedule. Perform the procedure Defining a WHEN Condition on page 150 to specify any prerequisites that must occur before the event can be dispatched.
117
OCCURS Clauses
The OCCURS clause specifies the day or days an event should be scheduled. The ZEKE utility program SCHEDULE function scans the database and selects all events due to process on the schedule date based on the OCCURS clause. See OCCURS Keywords on page 120 for a list and description of all OCCURS clause keywords. An event is scheduled when its OCCURS clause is true. For example, suppose an event is defined as OCCURS (Monday). When the schedule function is processed on a Monday, the OCCURS clause is true. On any other day of the week, the clause is false. When an events OCCURS clause is false, the event is not scheduled.
OCCURS Clause Format

The format of the OCCURS clause is:
OCCURS (keyword AND|OR keyword)
Enclose the entire clause (excluding the word OCCURS) within parentheses. Any AND/OR logic and additional keywords are optional. For example, the following event OCCURS on Mondays:
OCCURS (MONDAY)
The following event OCCURS on the last Monday in January:

OCCURS (MONDAY.L AND JANUARY)
For events with multiple versions, all versions of the event share the same OCCURS clause. When appearing on reports and displays, the OCCURS clause appears as version zero.
118
4 Events
Multiple OCCURS Clause Phrases

An event can have more than just one OCCURS clause phrase, if needed. For example, the following event is to be selected on every Monday and Thursday. The event is defined with 2 OCCURS clause phrases joined with the word OR.
OCCURS (MONDAY OR THURSDAY)
The keyword OR indicates the event is scheduled when either clause is true. The keyword AND indicates the event is scheduled only when both of the OCCURS clauses are true. For example, the following event is scheduled for each Monday during January:
OCCURS (MONDAY AND JANUARY)
The following event is scheduled only when the current schedule date is Monday, and also Thursday. Since this situation can never occur, this OCCURS clause is invalid and the event is never scheduled.
OCCURS (MONDAY AND THURSDAY)
Grouping Multiple OCCURS Clause Phrases

In addition to AND/OR relationships between multiple OCCURS clause phrases, you can group multiple OCCURS clauses, in order to resolve one group of clauses before resolving the next, higher group. Use additional sets of parentheses to group multiple clauses. For example, suppose an event is scheduled for any Monday during the first month of each quarter. The months are January, April, July, and October. The OCCURS clause is specified as follows:
OCCURS (MONDAY AND (JANUARY OR APRIL OR JULY OR OCTOBER))
The innermost group is resolved first. The inner group is true if the current month is January or April or July or October. During any other month, the inner group is false. Because the keyword AND joins the two clauses, the event is only scheduled if it is a Monday in one of the named months. Use only additional sets of parentheses to separate multiple conditions. For example, (WORKDAYS AND (MONDAY OR TUESDAY)) does not need to be coded (WORKDAYS AND ((MONDAY) OR (TUESDAY))), because MONDAY and TUESDAY are not multiple conditions.
119
OCCURS Keywords
The following symbols are used in the OCCURS clause with keywords. Symbol
. (period)
Description
Specifies an occurrence of a keyword.
OCCURS (MONDAY.L)
Schedules for the last Monday of each month or period.

OCCURS (MONDAY.2)
Schedules for the second Monday of each month or period. + (plus) Adds the specified number of days or workdays. Can be used with the period (.) keyword followed by L or 1 through 24.
OCCURS (MONDAY.L + 3 DAY)
Schedules for 3 days after the last Monday of each month or period.
OCCURS (MONDAY.L + 3 WDAY)
Schedules for 3 workdays after the last Monday of each month or period. (minus) Subtracts the specified number of days or workdays. Can be used with the period (.) keyword followed by L or 1 through 24.
OCCURS (TUESDAY.1 - 5 WDAY)
Schedules for 5 workdays before the first Tuesday of each month or period.
OCCURS (EOM-2)
Schedules for 2 days before the last day of each month.
The OCCURS clause can contain one or more of the following keywords: Keyword
DAILY
Description
Schedules for any day the Zeke schedule function runs, regardless of whether the day is a workday, weekend, or holiday. Schedules for any normal working day (not on holidays or weekends). Schedules for Mondays. Schedules for Tuesdays. Schedules for Wednesdays. Schedules for Thursdays.
WORKDAYS MONDAY TUESDAY WEDNESDAY THURSDAY
120
4 Events
Keyword
FRIDAY SATURDAY SUNDAY WMONDAY WTUESDAY WWEDNESDAY WTHURSDAY WFRIDAY WSATURDAY WSUNDAY JANUARY
Description
Schedules for Fridays. Schedules for Saturdays. Schedules for Sundays. Schedules for working Mondays. Schedules for working Tuesdays. Schedules for working Wednesdays. Schedules for working Thursdays. Schedules for working Fridays. Schedules for working Saturdays. Schedules for working Sundays. Schedules if January. Use with AND. For example:
OCCURS (FRIDAY.L AND JANUARY)
Schedules the last Friday in January. FEBRUARY MARCH APRIL MAY JUNE JULY AUGUST SEPTEMBER OCTOBER NOVEMBER DECEMBER EOM Schedules if February. Use with AND. Schedules if March. Use with AND. Schedules if April. Use with AND. Schedules if May. Use with AND. Schedules if June. Use with AND. Schedules if July. Use with AND. Schedules if August. Use with AND. Schedules if September. Use with AND. Schedules if October. Use with AND. Schedules if November. Use with AND. Schedules if December. Use with AND. Schedules for last day of the month.
121
Keyword
EOM-xx WEOM WEOM-xx DAY DAY yy xx
Description
Schedules xx days before last day of the month. Schedules for last working day of the month. Schedules xx working days before last working day of the month. Schedules on the specified day of the month. Schedules on the specified day of the month if the relationship is true. Where: yy is an operator (LE, LT, GE, GT, NE, EQ) or period (.). xx is a number in the range 01 through 31, L, or L For example:
OCCURS (DAY LE 07)
Schedules on any day less than or equal to the seventh day of each month.
OCCURS (DAY.5)
Schedules on the fifth day of each month.

OCCURS (DAY.L-1)
Schedules on the day before the last day of each month. WDAY xx yy Schedules on the specified workday of the month if the relationship is true. xx is an operator (LE, LT, GE, GT, NE, EQ) or period (.) yy is a number in the range 01 through 31, L, or L For example,
OCCURS (WDAY EQ 04)
Schedules on the fourth workday of the month.

OCCURS (WDAY.5)
Schedules on the fifth workday of each month.

OCCURS (WDAY.L-1)
Schedules on the workday before the last workday of each month. JDAY Schedules on the specified day of the current year. JDAY uses the same format as the keyword DAY, but its period is for the year. JDAY can also be used to refer to the current Julian day in comparison phrases.
OCCURS (JDAY LE 31)
Schedules for the first 31 days of the year.

OCCURS (JDAY.L)
Schedules for the last day of the year.
122
4 Events
Keyword
DATE xx mm/dd/yyyy
Description
Schedules on the specified date if the relationship is true. xx=operator (LE, LT, GE, GT, NE, EQ) mm/dd/yyyy=an actual date For example,
OCCURS (DATE LE 12/31/2007)
Schedules for any date less than or equal to December 31, 2007. Note: You can also use the date format dd/mm/yyyy if your OASISxx PARMLIB member specifies DATE=DDMM. MONTH Schedules if the month is true. Use with AND.
OCCURS (MONDAY AND MONTH.11)
Schedules if the day is Monday and it is the eleventh month of the year. Month.11 is November in a regular calendar, but may be different if you are using a fiscal or user calendar.
OCCURS (TUESDAY AND MONTH.L)
Schedules if the day is Tuesday and the month is the last fiscal month. WEEK Schedules the week in a month or period. Use with AND.
OCCURS (MONDAY AND WEEK.3)
Schedules if the day is Monday and it is the third week of the month or period. FWEEK Schedules during a week in the month or period that includes Monday through Sunday. Use with AND.
OCCURS (TUESDAY AND FWEEK.1)
Schedules if the day is Tuesday and is in the first complete week of the month or period. WDAYW Schedules the working day of the week.
OCCURS (WDAYW.2)
Schedules the second workday of each week, which is based on the workdays and holidays specified in the calendar. WFWEEK Schedules during a normal full work week in the month or period that includes all normal workdays in that week. Use with AND.
OCCURS (TUESDAY AND WFWEEK.2)
Schedules if the day is Tuesday and is in the second week of the month or period that includes all normal workdays.
123
Keyword
USEREXIT
Description
Calls a user-written program during OCCURS clause processing. All calendar table information is passed to the exit. USEREXIT determines if the event should be scheduled.
OCCURS (USEREXIT TESTOCCUR)
Schedules if the user exit returns a response of true. Refer to your ASG-Zeke for z/OS Installation Guide for more information on user OCCURS clause exits and on using this keyword. EVERY xxx DAYS BEGINNING mm/dd/yyyy Schedules every xxx days beginning on the specified date. The event will not schedule prior to the specified date. Note: You can also use the date format dd/mm/yyyy if your OASIS00 member is set to DATE=DDMM. Schedules every xxx workdays prior to and after the specified date. When scheduling events for the future, the event will schedule prior to as well as after the specified date. Note: You can also use the date format dd/mm/yyyy if your OASIS00 member is set to DATE=DDMM. REQUEST Never automatically schedules this event. Use the ZADD command to schedule the event. Schedules according to the OCCURS clause of the specified event. This keyword can be used with other OCCURS keywords. Takes into account the NWDAY specification of the referenced event.
OCCURS (REFEVENT 26 + 2 WDAY)
EVERY xxx WDAYS FROM mm/dd/yyyy
REFEVENT
Schedules the event 2 workdays after the OCCURS of event 26. NOT Schedules if the specified keyword condition is not true. This keyword can be used for a single condition or for a compound condition enclosed in parentheses.
OCCURS (NOT WORKDAYS)
Schedules on any day that is not defined to Zeke as a workday.

OCCURS (NOT (MON OR TUES))
Schedules on all days except for Mondays and Tuesdays.

OCCURS (WORKDAYS AND NOT MONDAY)
Schedules on any working day that is not a Monday. AND 124 Schedules if both conditions are true.
4 Events
Keyword
OR BEFORE
Description
Schedules if either of the conditions is true. Schedules on the working day prior to the normal selection day if the day is a holiday or weekend. (Default.) Schedules on the working day after the normal selection day if the day is a holiday or weekend. Schedules on the normal selection day even if normal selection day is a holiday or weekend.
AFTER
ON
Note: Use the keywords BEFORE, AFTER, and ON to schedule an event when it would normally fall on a holiday or weekend. Place the keywords immediately after another keyword or compound conditions enclosed in parentheses. If BEFORE or ON is not specified, Zeke schedules the event the day after a holiday or weekend unless the NWDAY parameter specifies differently. See Scheduling Events on Holidays and Weekends on page 130. PERIOD Schedules the event according to the specified period. For example,
OCCURS (MONDAY.L AND PERIOD.3)
Schedules for the last Monday in the 3rd period of the calendar. HOLIDAYS Schedules on holidays. Note: To code an OCCURS clause with a relational reference to a holiday (such as (HOLIDAYS + 1 DAY)), the EMRs NWDAY parameter must be set to O (O=schedule the event on the non-workday). WEEKENDS HOL/WEEK CALENDAR Schedules on weekends. Schedules on holidays and weekends. Schedules based on the specified Special calendar. Use with AND.
OCCURS (CALENDAR TEST1 AND WEDNESDAY)
Schedules only for the Wednesdays marked in calendar TEST1. VAR Schedules if the specified Zeke variable is true. Use with AND.
OCCURS (VAR $SUE123 EQ OKAY AND PERIOD.2)
Schedules only if the value for $SUE123 is OKAY and it is the second period of the calendar.
125
Sample OCCURS Clauses

The following are some example OCCURS clauses and their descriptions. OCCURS (WORKDAYS AND MONTH.L) Occurs every workday in the last fiscal month. OCCURS (WEDNESDAY AND DATE LT 01/31/2007) Occurs every Wednesday before January 31, 2007. OCCURS (MONDAY.1 OR MONDAY.3) Occurs the first and third Monday of each month or period. OCCURS (EVERY 14 DAYS BEGINNING 02/12/2007) Occurs every other Monday starting on February 12, 2007. OCCURS (EVERY 5 WDAYS FROM 03/26/2007) Occurs every Monday before and after March 26, 2007. OCCURS (DAY.L) Occurs the last day of each month or period. OCCURS (WDAY NE 07) Occurs every workday except the seventh workday of each month or period. OCCURS (SUNDAY AND WEEK.1) Occurs on Sunday in the first week of each month or period. OCCURS ((FRIDAY.2 OR FRIDAY.4) AND (MONTH.3 OR MONTH.6 OR MONTH.9 OR MONTH.12)) Occurs the second and fourth Friday of the third month of each quarter. OCCURS (WEDNESDAY AND NOT DAY.1) Occurs every Wednesday unless Wednesday is the first day of the month. OCCURS (WORKDAYS AND NOT WEOM-1) Occurs every workday except the workday before the last day of the month. OCCURS (EOM + 5 WDAY) Occurs five workdays after the last day of the month. OCCURS (WFWEEK.1 AND NOT MONDAY) Occurs the first full work week of the month except for Monday. OCCURS (NOT FWEEK.1 AND DAILY) Occurs every day of the month (including weekends) except the first full week (Monday through Sunday) of the month.
126
4 Events
OCCURS (MONTH.10 AND WORKDAYS AND NOT FRIDAY) Occurs every workday in October except Friday. OCCURS ((WORKDAYS AND NOT FRIDAY) OR (FRIDAY AND WEOM)) Occurs every workday of the week, except for Friday, unless Friday is the last workday of the month. OCCURS (MONDAY.L AND PERIOD.1) Occurs the last Monday of the first period. OCCURS (WDAYW.3) Occurs the third workday of each week. OCCURS ((HOLIDAYS - 1 WDAY) OR (HOLIDAYS - 2 WDAY)) Occurs the 2 workdays preceding a holiday. OCCURS (WORKDAYS AND NOT (HOLIDAYS - 1 WDAY) AND NOT (HOLIDAYS - 2 WDAY)) Occurs every workday except the 2 workdays preceding a holiday. OCCURS (((FRIDAY AND EOM) - 7 DAY) OR ((SATURDAY AND EOM) - 8 DAY) OR ((SUNDAY AND EOM) - 9 DAY) OR (FRIDAY.L AND NOT EOM AND NOT EOM-1 AND NOT EOM-2)) Occurs the last Friday of the month unless the last Friday is also one of the last 3 days of the month; in that case, occurs on the next-to-last Friday of the month. OCCURS (((FRIDAY AND HOLIDAYS) - 1 DAY) OR (FRIDAY AND NOT HOLIDAYS)) Occurs every Friday unless it is a holiday; in that case, occurs on the previous Thursday. OCCURS (((((FRIDAY AND HOLIDAYS) - 1 DAY) AND HOLIDAYS) - 1 DAY) OR (((FRIDAY AND HOLIDAYS) - 1 DAY) AND NOT HOLIDAYS) OR (FRIDAY AND NOT HOLIDAYS)) Occurs every Friday unless it is a holiday; in that case, occurs on the previous Thursday. If previous Thursday is also a holiday, occurs the previous Wednesday. OCCURS (((MONDAY AND HOLIDAYS) + 2 DAY) OR ((MONDAY AND NOT HOLIDAYS) + 1 DAY)) Occurs every Wednesday following a Monday that is a holiday, and every Tuesday following a Monday that is not a holiday. OCCURS (WORKDAYS AND NOT WDAYW.1 AND (NOT HOLIDAYS + 1 DAY)) Occurs every workday unless it is the first workday of the week or the day after a holiday.
127
OCCURS (((WDAYW.1 - 2 DAY) AND NOT HOLIDAYS) OR ((MONDAY AND HOLIDAYS) - 1 DAY)) Occurs the second non-holiday day before the first workday of every week, unless the first workday of the week is a holiday; in that case, occurs the day before the first workday of the week. OCCURS ((WORKDAYS AND NOT FRIDAY.2) OR (FRIDAY.2 + 2 DAY)) Occurs every workday of the month except the second Friday; also occurs 2 days after the second Friday of the month. OCCURS (WORKDAYS AND NOT (HOLIDAYS AND MONDAY) + 1 DAY) Occurs every workday except the day following a Monday holiday. OCCURS (SEPTEMBER AND DAY EQ 28 OR (OCTOBER AND DAY EQ 26 OR (NOVEMBER AND DAY EQ 23 ON HOLIDAYS OR (DECEMBER AND DAY EQ 28)))) Occurs on September 28, October 26, November 23 (even if it is a holiday), and December 28. OCCURS ((DECEMBER AND DAY GE 6 AND DAY LE 27) AND WORKDAYS AND NOT FRIDAY) Occurs on all workdays, except Fridays, from December 6 through December 27 (inclusive). OCCURS (SATURDAY ON WEEKENDS OR (WORKDAYS AND NOT MONDAY)) Occurs every Saturday and every workday except Monday. OCCURS (MONDAY ON HOLIDAYS OR (TUESDAY ON HOLIDAYS OR (WEDNESDAY ON HOLIDAYS OR (THURSDAY ON HOLIDAYS OR (FRIDAY ON HOLIDAYS))))) Occurs every Monday, Tuesday, Wednesday, Thursday, and Fridayeven if it is a holiday. OCCURS (NOT SATURDAY ON HOLIDAYS AND NOT SUNDAY ON HOLIDAYS) would produce the same results. OCCURS (FRIDAY.1 AND PERIOD.4) Occurs the first Friday in the fourth period of the calendar. OCCURS (CALENDAR TEST2 AND WSATURDAY) Occurs every working Saturday marked in calendar TEST2. OCCURS ((WDAYW.3 AND WDAYW.L) - 1 DAY) Occurs on the second workday of the week if the third workday is the last workday in the week (for example, occurs on Tuesday if Thursday and Friday are holidays, or on Thursday if Monday and Tuesday are holidays).
128
4 Events
OCCURS (DAY EQ 15 BEFORE HOL/WEEK) Occurs on the fifteenth day of each month or period unless it is a holiday or weekend; in this case, occurs on the prior workday. OCCURS ((DAY.L BEFORE HOLIDAYS ON WEEKENDS OR ((DAY.1 AND HOLIDAYS) + 1 DAY)) OR (DAY.1 AND NOT HOLIDAYS)) Occurs the last day of each month or period (even if it is a weekend) unless it is a holiday; in this case, occurs on the prior workday. Also occurs the first day of each month or period unless it is a holiday; in this case, occurs the second day of the month or period. OCCURS (JDAY LE 31) Occurs the first 31 days of the year. OCCURS (JDAY LE 31 ON HOLIDAYS) Occurs the first 31 days of the year. Holidays will be scheduled for the actual day. OCCURS (JDAY.60) Occurs the 60th day of the year, either March 1 of non-leap year, or February 29 in a leap year. OCCURS (JDAY.L) Occurs on the last day of the year. OCCURS (JDAY.L - 1 DAY) Occurs on the penultimate day of the year. OCCURS (JDAY.L + 1 DAY) Occurs the first day of the next year. This is valid syntactically, but the event will never be scheduled. The Julian day is a day within the current year, so it is never next year. As a result the event cannot be scheduled.
129
Scheduling Events on Holidays and Weekends

The following OCCURS clause keywords are affected by holidays and weekends. DATE xx mm/dd/yyyy EOM-xx MONDAY-SUNDAY DAY EQ xx EVERY xx DAYS WEEKEND DAY.x HOLIDAYS EOM HOL/WEEK
Events scheduled for a particular day of the week, or EVERY xx DAYS, might hit on a nonworking day. However, events defined to OCCUR WORKDAYS, or WDAY EQ xx, or xx working days prior to the last working day of the month (WDAY.L-xx or WEOM-xx) are not affected by holidays or weekends because a workday, by definition, cannot be a holiday or weekend. When an event is scheduled to occur on a nonworking day, Zeke, by default, schedules the event for the following working day. For example, an event is defined to occur on Monday, and Monday is a holiday. Even if the schedule function is processed on Monday, the event is not scheduled because Monday is a holiday. Zeke schedules the event for the following Tuesday, dates the scheduled event with Monday's date, and places it in Tuesday's schedule. The scheduled event contains Monday's date, because there might be another scheduled event for Tuesday (suppose the event is defined to occur Monday or Tuesday). To schedule the event for the prior working day, Friday, code the OCCURS clause as follows:
OCCURS (MONDAY BEFORE HOLIDAYS)
To schedule the event for Mondays, regardless of whether Monday is a holiday, code the OCCURS clause as follows:
OCCURS (MONDAY ON HOLIDAYS)
To schedule an event for every Saturday when Saturday is defined as a weekend, code the OCCURS clause as follows:
OCCURS (SATURDAY ON WEEKENDS)
For another example, an event is defined to occur every 10 days. If the hit date falls on a holiday or on a weekend, Zeke, by default, schedules the event on the next working day. Use the following phrases to schedule an event prior to a holiday or weekend:
130
BEFORE HOLIDAYS BEFORE WEEKENDS BEFORE HOL/WEEK
4 Events
Use the same phrases with the word ON instead of BEFORE to schedule the event on the hit date even if it might be a holiday or weekend. The words ON, BEFORE and AFTER can be used outside of parentheses to apply to all keywords within parentheses. This does not apply if there is an individual holiday or weekend specified. For example, OCCURS ((MONDAY BEFORE HOLIDAYS) OR TUESDAY) Schedules event every Monday and Tuesday. However, if Monday is a holiday, schedules on the previous workday. OCCURS ((MONDAY OR TUESDAY) BEFORE HOL) Schedules event Monday or Tuesday. If either is a holiday, schedules event on the previous workday. When you specify a holiday or weekend in the OCCURS clause, it overrides the NWDAY field in the EMR. For global OCCURS clause specifications, you can set a Zeke generation option. See Scheduling Events on page 297 for information about the Nonwkday generation option.
Note:
The keyword DAILY schedules an event on any day the schedule function runs, regardless of whether that day is a workday, weekend, or holiday. The modifiers ON, BEFORE, and AFTER have no effect on the OCCURS clause keyword DAILY.
131
Defining an OCCURS Clause

To define and test an OCCURS clause
Class: CMS:
Pri: Ftype:
Enter OCCURS on the Command line and press Enter. The Event Record Occurs Clause screen is displayed.
ASG-Zeke Command ===> Primary Commands : Event Record Occurs Clause EDIT
BROWSE EDIT ACCTG OCCHIT Job: TSKKGUT1 Evt Name: ZEKE51TST6 Calid: A
Evt: 000006 Type: JOB Ver: 00000 Occurs: (WEEK.2)
132
4 Events
In the OCCURS field, enter a valid OCCURS clause. Enclose the clause in parentheses. The most common OCCURS keywords. Keyword
REQUEST
Description
(Default.) Event is not automatically scheduled. Manually add it to the schedule via Schedule View or the ZCOM option. See Using Schedule View on page 202 or Using the ZADD Operator Command on page 250. Event is scheduled every day, regardless if workday, weekend, or holiday. Event is scheduled for workdays only, as defined on the calendar for the event. Event is scheduled the last day of each month.
DAILY
WORKDAYS
EOM
4 5
Press Enter. The event is updated with the new OCCURS clause. Enter OCCHIT on the Command line and press Enter. The OCCURS Hit Resolution screen is displayed.
ASG-Zeke Command ===> Occurs Hit Resolution EDIT
Primary Commands: BROWSE EDIT NMONTH PMONTH NYEAR PYEAR Month: 11 Year: 2007 Event: 000032 Ename: TESTADDNM M O N 6 * 13 *2 20 27 T U E 7 * 14 21 28 W E D 1 8 * 15 22 29 T H U 2 9 * 16 23 30 F R I 3 10 * 17 24 S A 4 11 18 25 T W W W W
Calid: A S U 5 12 19 26 N W W W W
Ver: 00000 Occurs: (WEEK.2)
W = Weekend H = Holiday S = Slack day *X = Event scheduled x times on this date
* = Event scheduled on this date
The days of the current month are displayed. The highlighted days with an asterisk (*) to the right are the days the event is scheduled to occur.
133
View the results of the OCCURS clause for at least the next 12 months to verify that it is scheduling as desired. Perform the steps in the Action column in the following table, depending on the desired results. Desired Result
View the schedule for the next month View the schedule for the previous month View the schedule for the next year View the schedule for the previous year View the schedule for a specific month
Action
Enter NMONTH on the Command line and press Enter.
Enter PMONTH on the Command line and press Enter.
Enter NYEAR on the Command line and press Enter.
Enter PYEAR on the Command line and press Enter.
Enter the number of the month (01=January, 12=December) in the Month field and the year in the Year field. Press Enter.
134
4 Events
WHEN Conditions
WHEN conditions specify the conditions that must occur before an event can be dispatched. An event with WHEN conditions is not dispatched by Zeke until the WHEN conditions are satisfied. A WHEN condition, also known as a dependency, can be any of the following:

Execution of a specific program, system job, or Zeke event Relating a Zeke variable to a certain value Any combination of multiple WHEN conditions z/OS dataset creation
If an event does not have a dependency defined to it, then the event is dispatched according to the specified schedule time on the EMR. Work centers do not have WHEN conditions. See Work Centers on page 161.
Job and Program WHEN Conditions

Job and program WHEN conditions are satisfied when the system initiates or completes the action named in the dependency (such as starting or ending a specific job). As each dependency is satisfied, the WHEN conditions are examined to determine if they are all satisfied. When they are, the event status becomes WHEN OK.
WHEN Conditions for Multiple Event Versions

For events with multiple versions, separate WHEN conditions can be defined for each version. A dependency is assigned a version number to indicate which version of the event it belongs to. When an event version is placed in the schedule, Zeke searches for a dependency with the same version number. If one is found, that dependency is used for the event version. If one is not found, the version zero dependency is used as the default (if it exists). If a default dependency has not been defined for the event, the event is automatically changed to WHEN OK.
135
Extended Dependencies
The keywords XEOJ (extended end-of-job) and XEOE (extended end-of-event) provide the ability to trigger job events across multiple schedules. Extended WHEN conditions can be satisfied by events that have run in the past but are no longer in the schedule. If a job is dependent on another event that may have run as part of an earlier schedule, the XEOJ keyword is used to locate the triggering event in the Zeke database and determine whether it has run since the last time the dependent job ran. (See WHEN Condition Keywords on page 145 for details on including the XEOJ and XEOE keywords in a WHEN condition.) If a job has multiple extended WHEN conditions, all must be satisfied at the same time in order for the extended triggering to occur. At schedule load, the EMRs are searched (using the index, if present) and the first matching jobname is examined. If the last run of that event has completed successfully since the last time the job with the extended dependency ran, the dependency is satisfied and displayed with an asterisk (just like an EOJ or EOE). Otherwise, the dependency is treated as if it were a regular EOJ or EOE and must wait for the triggering job to complete successfully before it can be satisfied. Extended dependencies are examined each time an event becomes TIMEOK and WHENOK. For extended dependency triggering, the start date and time, the end date and time, and the status are retained in the EMR for the last execution of each event. (Refer to Event Activity Accounting on page 188.) If the schedule record has been requeued or if the execution is not being tracked, information is kept in the EMR for the previous execution instead. If multiple schedule records for an event are executing together, triggering occurs based on the execution with the latest end date and time.
Note:
Extended WHEN conditions are processed in the same manner as if the generation options Trigjob=C and Trigdt=A. In other words, the triggering event must have been dispatched by Zeke (or by a Zeke sharing the same database), but the start date does not have to be the same as the schedule date of the job being triggered. If the last execution of an event did not complete successfully, the event cannot trigger an extended dependency. (A JCL error is an unsuccessful completion; EOJ FORCED is a successful completion.) If the execution is unsuccessful, the information for that execution is still retained in the EMR, but no triggering takes place. Extended WHEN conditions can also be manually satisfied using the ZALTER WHENOK operator command.
136
4 Events
XEOE Example
Event 2 has an extended dependency (XEOE) on Event 1. When Event 2 is loaded into the schedule, Zeke checks to see if Event 1 ran since the last time Event 2 ran. If Event 1 last ran successfully a week ago and Event 2 last ran successfully two weeks ago, then the XEOE dependency would be satisfied and Event 2 would be dispatched (assuming any additional dependencies are also satisfied). But, if Event 1 ran two weeks ago and Event 2 ran only two days ago, the XEOE would not be satisfied and the dependency is treated as an EOE instead.
XEOJ Example
The job event named Job B has an extended dependency (XEOJ) on Job A. When Job B is loaded into the schedule, Zeke checks to see if Job A ran since the last time Job B ran. If Job A just ended today at 10:30:25 a.m. and Job B is otherwise ready to run at 10:30:40 a.m. today (during the same minute), then the XEOJ dependency would be satisfied and Job B would be dispatched (assuming any additional dependencies are also satisfied). But, if Job A did not end until 10:30:56 a.m. (also during the same minute), then the XEOJ would not be satisfied and the dependency is treated as an EOJ instead.
WEAK Conditions
WEAK conditions in a dependency allow you to create WHEN conditions referring to events that may or may not be in the schedule. WEAK conditions allow the user to specify that the condition should be respected if the event is in the schedule; otherwise, ignore the condition. The following is an example dependency for event 100:
WHEN (WEOJ JOBABC)
If JOBABC is in the schedule, event 100 is not dispatched until JOBABC reaches a successful end-of-job (EOJ). Zeke continuously checks for JOBABC until the event is dispatched. Zeke also verifies whether the condition was met because WEAK was satisfied (event not in the schedule) or because the condition was satisfied (job ran). If the generation option Removdq=Y, the example above is processed as follows. If JOBABC is not in the schedule, event 100 is moved to the dispatch queue. While the event is in the dispatch queue, Zeke continues to check for JOBABC. If JOBABC is added to the schedule (ZADD operator command), event 100 is removed from the dispatch queue and is not queued again until JOBABC reaches a successful EOJ. If JOBABC is never added, event 100 executes when the resources are available. (If Removdq=N, events are not removed from the dispatch queue once they have been added.)
137
Started Tasks
The BOJ, EOJ, BOP, EOP, AEOJ, EOS, and AEOP WHEN conditions can also refer to started tasks and programs within started tasks, provided the proper specifications are made in the SMFPRMxx member of SYS1.PARMLIB. Refer to your ASG-Zeke for z/OS Installation Guide for more information on SMF requirements or ask your system programmer if your installation supports WHEN conditions referencing started tasks.
Generic Names
To specify generic event names for the EOE, AEOE, XEOE, or EOG conditions, precede the event name with an asterisk and as many characters as you want to match. Generic names are only valid for event names. Generic names cannot be used for jobnames. For example, *ABC matches all jobs with event names beginning with ABC. To use an asterisk as a wildcard character, replace any character with an asterisk. For example, PAY***UPD selects all events with PAY in the first three positions, any characters in the fourth through sixth positions, and UPD in the seventh through ninth positions. If the event name contains spaces, specify the name in single quotes. For example, (EOE '**********') An asterisk can indicate a generic name and a wildcard character, so it is important to understand how Zeke interprets an asterisk. The maximum number of characters is 12. If all 12 characters are specified (with an asterisk in the first position), Zeke assumes the first asterisk is a wildcard. For example, *KKKKKKKKKKK selects all events with any character in the first position and K in the second through twelfth positions. If less than 12 characters are specified, Zeke assumes an asterisk in the first position means a generic name. For example, *KKKKKKKKKK (one less K than the previous example) selects all events beginning with 10 Ks. If you want to indicate a generic name, but need to specify 12 characters, place the asterisk in the last position, as in the example KKKKKKKKKKK*. This selects all events beginning with 11 Ks.
138
4 Events
Multiple WHEN Conditions

An event can have more than one dependency. This example shows two WHEN conditions joined with the word OR. The keyword OR indicates the event is satisfied when either clause is satisfied.
WHEN (EOJ ABC OR EOJ XYZ)
The keyword AND indicates the event is satisfied only when both of the WHEN conditions are satisfied.
WHEN (EOJ XYZ AND EOJ ABC)
Grouping Multiple WHEN Conditions

In addition to AND/OR relationships between multiple WHEN conditions, multiple WHEN conditions can be enclosed in parentheses. This separates the clauses into groups and indicates to resolve one group before resolving the next, higher group. For example, an event is satisfied when Job A completes and either Program A or Program B completes.
WHEN (EOJ JOBA AND (EOP PGMA OR EOP PGMB))
The inner group is resolved first. The inner group is satisfied if Program A or Program B finished. Because the keyword AND joins the 2 clauses, the event is only satisfied if Job A has also finished.
139
Zeke Variables as WHEN Conditions

To use a Zeke variable as a dependency, specify a variable and the relational operator to compare to a specified value. Variable substitution in WHEN conditions is performed when the schedule record is created (during the SCHEDULE function or during a ZADD function). For example, the following event is not dispatched until the variable $VARNAM1 is YES:
WHEN (VAR $VARNAM1 EQ YES)
When the variable is set to YES, the dependency is satisfied. The dependency is also satisfied if the variable is already equal to YES when the schedule is first loaded. In WHEN conditions, OASIS variables can only be used for substitution in an operand, such as the jobname in a BOJ condition, the jobname in an EOJ condition, or the expression following the EQ in a VAR condition. OASIS variable substitution is performed using qualifiers from the schedule record being created.
WHEN EOJ PRDAA$(CYCLE)
Say the value of the OASIS CYCLE variable is 09; this number is substituted into the dependency, and the jobname becomes PRDAA09. WHEN conditions containing variables are not checked for syntax when they are defined. Syntax checking occurs only after the variable substitution is performed. This is important in the following situation: suppose the operand of an EOJ dependency containing a variable is longer than eight characters before substitution occurs. Normally, this would be invalid due to its length. However, since syntax checking is not performed until after the substitution, it is valid as long as the value is no longer than eight characters after substitution occurs. The following relational operators are valid. Relational Operator
EQ NE LE GE LT GT 140
Description
EQual Not Equal Less than or Equal Greater than or Equal Less Than Greater Than
4 Events
Use either numeric or character literals, but only compare numeric values to numeric variables and character values to character variables. Express numeric literals explicitly (no delimiters), and enclose character literals in special character delimiters if the character string contains other than alpha/numeric characters. For example,
WHEN (VAR $TEST1 EQ PROCEED) WHEN (VAR $CTR4 EQ 411 AND VAR $CTR3 EQ 77) WHEN (VAR $SHOWLIT EQ 'IT IS OK TO CONTINUE NOW')
Caution! The following characters cannot be used as delimiters: dollar sign ($) question mark (?) number/pound sign (#) at sign (@) asterisk (*)
Combinations of Event Actions and Zeke Variables

Combinations of job, program, and event actions and Zeke variables can be specified as WHEN conditions for any event. For example,
WHEN (EOJ JOBNAME1 AND VAR $VARNAME EQ YES)
141
NOTDURING Conditions
A NOTDURING condition specifies that an event cannot be dispatched while the specified programs or jobs are running. The event remains eligible for dispatch until the NOTDURING conditions are satisfied. Then, the event is immediately dispatched. Zeke ensures that events with conflicting NOTDURING clauses are not dispatched at the same time. For example, if JOB1 is in PENDING status and JOB2 has an NOTDURING for JOB1, Zeke does not dispatch JOB2 even though JOB1 is not actually running. Disabling JOB1 allows JOB2 to dispatch. Caution! NOTDURING conditions are not supported while the system is in SMF recording mode (initiated by the ZKILL TRACK command).
Activating NOTDURING Processing

To enable Zeke to process NOTDURING conditions on a single Zeke system, you must have the generation option Dispsel=Yes (see Activating Initiator Options on page 267). Additionally, the Eojwake generation option determines whether events held due to a NOTDURING condition are re-evaluated at each end-of-job or only at each 60-second dispatch interval (see Checking the Dispatch Queue on page 306). To enable Zeke to use XCF to process NOTDURING conditions across a ZekePlex, the setting of Dispsel is not considered. Instead, you specify PLEXNOTD=YES in your Zeke options member. (Refer to your ASG-Zeke for z/OS Installation Guide for details.) This option allows NOTDURING job processing in both JES2 and JES3 (otherwise, only JES2 supports NOTDURING dependencies). In addition to setting PLEXNOTD=YES, be sure that PLEXID= has been defined in the OASISnn parmlib member for the OASIS under which this Zeke is running. Refer to the ASG-OASIS for z/OS Reference Guide for details on setting PLEXID= in the OASISnn parmlib member.
Specifying NOTDURING Conditions in a WHEN Clause

In a WHEN clause, NOTDURING conditions must be listed last, after all other WHEN conditions. NOTDURING conditions are related by the AND condition (the NOTDURING must be satisfied before an event can be dispatched). NOTDURING conditions are not used in determining whether an event is WHEN OK. Therefore, an event can be WHEN OK even though a program or job named in an NOTDURING clause is executing. However, the event is not actually dispatched until the NOTDURING program or job completes.
142
4 Events
Specifying Generic Jobnames

To specify generic NOTDURING program and jobnames, precede the job or program name with an asterisk and enter up to 7 characters. For example, *ABC matches all jobnames beginning with ABC. To use an asterisk as a wildcard character, replace any character with an asterisk. For example, PAY**UPD selects all jobs with PAY in the first three positions, any characters in the fourth and fifth positions, and UPD in the sixth through eighth positions. Since an asterisk can indicate both a generic name and a wildcard character, Zeke assumes that an asterisk in the first position means a generic name when fewer than eight characters are entered. For example, if you want to select all jobs with C in the seventh position, enter ******C* instead of ******C. Since all eight characters are specified, Zeke assumes the first asterisk is a wildcard character.
Note:
An event cannot have a generic NOTDURING with a pattern that matches the jobname. For example, a job with the name JOBBC3PX and WHEN (NOTDURING JOB *BC3P).
Examples
The following are examples of the WHEN NOTDURING condition: WHEN (EOJ JOB1 NOTDURING JOB PRODCICS) Requires EOJ on JOB1, but cannot run while job PRODCICS is running. WHEN (NOTDURING PGM DFHSIP) No real WHEN conditions, but cannot run while program DFHSIP is executing.
Note:
The NOTDURING PGM clause is honored regardless of the initiator the job is running in. WHEN (NOTDURING JOB *PAY NOTDURING PGM PAY**01A) Cannot run with any job that has a job name beginning with PAY, or during any program with a name that has PAY in positions 1 through 3, and 01A in positions 6 through 8.
Note:
Resource control is a another effective way to ensure that conflicting Zeke events do not run at the same time. See Maintaining Logical Resources on page 274 for more information.
143
Cross-platform Dependencies
Cross-platform scheduling dependencies are prerequisites that are satisfied by a remote schedulereither a remote Zeke system or another remote scheduler, such as ASG-Zena. Only the WHEN conditions EOJ, AEOJ, and BOJ can be shared with remote systems. To indicate a cross-schedule dependency, you use the AT keyword followed by the eight-character Netregid of the remote scheduler, for example: WHEN(EOJ JOBA AND EOJ JOBB AT SYSB) In this example, Zeke waits on EOJ from JOBB on system SYSB before dispatching the event. When JOBB is complete (EOJ), SYSB notifies the originating Zeke system that the dependency is satisfied. Zeke then satisfies the dependency for all events waiting for EOJ JOBB from SYSB. With the AT keyword, a job name can be up to 30 characters. The AT keyword does not support use of the VER keyword. If a version number is specified, it will be ignored.
Zeke-to-Zeke Cross-schedule Dependencies

When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the object of the AT netregid of another scheduler's trigger), a non-Zeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke's Trigjob generation option. Both the local and remote Zeke systems ignore the Trigjob genopt when satisfying cross-schedule triggers. Zeke honors schedule and run dates when satisfying cross-schedule triggers. If a job that satisfies a cross-schedule trigger is a Zeke controlled job, the SQR's schedule date and run date are sent to the local Zeke with the satisfy notification. If the job that satisfies a cross-schedule trigger is not a Zeke job, the current date on the system where the job ran is sent to the local Zeke as the job's schedule and run dates in the satisfy notification. When the local Zeke system processes the satisfy notification, the local Zeke applies Trigdt to the schedule and run dates from the remote system to decide whether the remote job will satisfy the trigger. If the remote scheduler does not send the dates in the satisfy notification, the local Zeke system bypasses the Trigdt setting and simply looks for a match on the job name. You can also use AT to specify a dependency using a ZALTER command. For example:
To add a remote dependency with an 'and' relationship:

ZALTER JOB 1 WHENAND (EOJ JOBC AT SYSB)
To add a remote dependency with an 'or' relationship.

ZALTER JOB 1 WHENOR (EOJ JOBC AT SYSB)
To satisfy a remote dependency:

ZALTER JOB 1 WHENOK (EOJ JOBB AT SYSB)
144
4 Events
Refer to your ASG-Zeke for z/OS Reference Guide for more information on the ZALTER operator command.
WHEN Condition Keywords

Use the following keywords with the WHEN parameter: Keyword
AT
Description
Eight-character Netregid for the remote scheduler where the cross-platform prerequisite is to occur.
WHEN (EOJ JOBA AND EOJ JOBB AT SYSB)
Note: With the AT keyword, a job name can be up to 30 characters. The AT keyword does not support use of the VER keyword. If a version number is specified, it will be ignored. See Cross-platform Dependencies on page 144 for more information. DSN Dataset triggering is based on the creation and close of an OS output dataset. The event is dispatched when a sequential, non-VSAM dataset that matches the DSN dependency is created and closed.
WHEN (DSN DATASET.NAME) WHEN (DSN DATASET.NAME AND EOJ PAYROLL)
Before using DSN for non-VSAM datasets, ensure that the generation option IEFU83 is set to Y and that Type 15 SMF records are being created on your system, or that Sterling Commerces Connect:Direct product (formerly Network Data Mover, or NDM) is installed and active with the appropriate RUN TASK statement. Refer to the ASG-Zeke for z/OS Installation Guide for more information on using on using Connect:Direct with Zeke. A generation data group (GDG) dataset name with a generation number of G0000V00' is satisfied when any dataset in its GDG index is created and closed. The following condition is satisfied when any generation in the GDG A.B' is created and closed.
WHEN (DSN A.B.G0000V00)
The IEFBR14 program does not close a dataset, so it will not trigger a DSN dependency. AEOJ Failed end of job.
WHEN (AEOJ JOB1)
AEOE
Failed event. Applies to any type of event, including work centers.

WHEN (AEOE JOB1)
145
Keyword
AEOP
Description
Abnormal end of program.
WHEN (AEOP PAYROLL)
AEOS
Abnormal end of step. For example, if the step that failed does not execute a procedure:
WHEN (AEOS STEP4..JOBX)
If the step that failed executes a procedure, the procname must be included:
WHEN (AE0S STEP2.PROC3.JOBX)
NOTDURING
Not during. Prevents jobs/programs from running at the same time. Must be the last condition in the clause.
WHEN (NOTDURING JOB JOBNAME) WHEN (EOJ JOB1 NOTDURING JOB PRODCICS) WHEN (NOTDURING JOB *PAY NOTAF PGM PAY**01A)
See NOTDURING Conditions on page 142 for a detailed discussion of NOTDURING WHEN conditions. BOJ Beginning of job.
WHEN (BOJ JOB3)
BOP
Beginning of program.
WHEN (BOP PGMNME)
EOG
Successful end of a group of events. Use EOG to trigger an event by the completion of any number of other events, including work centers. This dependency is satisfied when all events in the schedule that match the specified event name are in SUCCESS or DISABLED status and at least one of the matching events is in SUCCESS status.
WHEN (EOG GRPPAY)
For example, lets suppose a master file update is performed after all daily transactions are received. If the number of daily transaction jobs varies, EOE cannot be used, because some of the EOE conditions would not be satisfied if their corresponding jobs were not run on a particular day. With EOG, before the event is dispatched, Zeke ensures that all scheduled events matching the specified event name are in SUCCESS or DISABLED status. If no transaction jobs are complete, the master file update does not run.
146
4 Events
Keyword
Description
If the generation option Removdq=YES, the EOG dependency can be unsatisfied up to the time of dispatch If Removdq=NO, the EOG dependency can be unsatisfied up to the time the event is added to the dispatch queue. For example, lets suppose an event with an EOG dependency is scheduled at 18:00. At 10:00, two events that match the EOG are in the schedule. At 12:00, these events are completed. This satisfies the EOG, but the dependent event is not scheduled to run until 18:00. At 14:00, an event that matches the EOG dependency is added to the schedule. The EOG is no longer satisfied and the newly-added event must be completed or disabled before the event with the EOG dependency can be dispatched. Note: If you specify an EOG dependency in which the dependent event matches the generic event name specified in the EOG, the dependent event will never be triggered (because it is dependent on itself as well as other events). For example, if the WHEN condition specifies EOG *ASG123 and the event name for the dependent event is ASG12345, all other predecessor events might be completed, but the successor will never be triggered.
EOE
Successful end of event. This dependency is satisfied when an event in the schedule that matches the specified event name is in EOE or DISABLED status. Applies to any type of event, including work centers. Note: This keyword requires the event name. Do not use the event number.
WHEN (EOE JOB1) WHEN (EOE 'JOB TWO') WHEN (EOE PAYROLL) WHEN (EOE 'JOB PAYROLL')
EOP
Successful End Of Program.

WHEN (EOP PROGRAM.JOB) WHEN (EOP PGMNAME1 OR EOP PGMNAME2)
EOS
Successful end of step. The stepname is the name of the job step that calls the cataloged procedure. The procstep is the name of the procedure step. When executing a procedure:
WHEN (EOS STEPNAME.PROCSTEP.JOBNAME)
When not executing a procedure:

WHEN (EOS STEPNAME..JOBNAME)
147
Keyword
EOJ
Description
Successful end of job.
WHEN (EOJ JOBNAME1) WHEN (EOJ JOBNAME1 AND EOJ JOBNAME2 AND BOJ JOBNAME3) WHEN (EOJ JOB$(CYCLE))
VAR
Events are dispatched only when the variable is equal to the specified value.
WHEN (VAR $ABC EQ YES)
See Zeke Variables as WHEN Conditions on page 140 for a detailed explanation of variables used as WHEN conditions. VER Events are dispatched only at the end of a specific version of the event. If the VER condition is omitted, it defaults to the same version SQR. For example, if JOBB version 3 is waiting on EOJ of JOBA but no version is specified, it will wait on EOJ of JOBA run under a version 3 SQR.
WHEN (EOE JOB4 VER 88) WHEN (EOJ JOBC AND EOJ JOBC VER 2)
The VER condition can appear as part of any EOE, EOJ, EOP, EOS, or EOG clause (including their WEAK counterparts); however, it actually applies only to the SQR causing the trigger to be generatednot the job, program, or step. Use an asterisk after the VER condition to trigger off of any version of the SQR. In the following example, the event triggers off of the next EOE on EVTB.
WHEN (EOE EVTB VER *)
Note: The following conditions do not support use of the VER keyword: DSN, VAR, ?VAR, XEOJ, and XEOE. WEOG Weak end of group. Successful End Of a Group of events. Applies to any type of event, including work centers. This dependency is satisfied when all events in the schedule that match the specified event name are in EOE or DISABLED status. In addition, at least one event must be in EOE status. All events can be disabled for the WEOG condition. WEOG is also satisfied if there are no matching events in the schedule. See WEAK Conditions on page 137 for more information.
WHEN (WEOG GRPA)
148
4 Events
Keyword
WEOE
Description
Weak end of event. Applies to any type of event, including work centers. This keyword requires the event name. Do not use the event number. See WEAK Conditions on page 137 for more information.
WHEN (WEOE WC_ABC)
WEOJ
Weak end of job. See WEAK Conditions on page 137 for more information.
WHEN (WEOJ JOBNAME)
XEOE
Extended end of event. Applies to any type of event, including work centers. This keyword requires the event name. Do not use the event number. XEOE does not support use of the VER keyword. For example, if the following dependency is defined for JOBC, XEOE is satisfied if job ABC has run to DONE or DISABLED status since the last time JOBC ran.
WHEN (XEOE ABC)
XEOJ
Extended EOJ for job events only. Note: XEOJ does not support use of the VER keyword. If a version number is specified, it will be ignored. An event will be triggered by any version of a matching job. For example, if the following dependency is defined for JOBC, XEOJ is satisfied if JOBA has run since the last time JOBC ran.
WHEN (XEOJ JOBA)
149
Defining a WHEN Condition

To define and maintain a WHEN condition
1 Access the Event Master Definition screen as instructed in the procedure, Accessing the Event Master Record on page 82.
Class: CMS:
Pri: Ftype:
Enter WHEN # (where # is the version) on the Command line and press Enter. If you do not enter a version number, it defaults to the first version.
ASG-Zeke Command ===> Event Master Record Function EDIT Scroll ===> PAGE
Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN Evt: 000006 Type: JOB Job: TSKKGUT1 Evt Name: ZEKE51TST6 Calid: A Ver: 00000 Info: Platform: MVS ****** ***************************** Top of Data *************************** ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 (EOE ZEKE51TST5 AND EOE ZEKE51TST4 AND EOE ZEKE51TST1 AND EOE ZEKE51TST2 000002 AND EOE ZEKE51TST3) ****** **************************** Bottom of Data *************************
Use the standard ISPF commands to edit the bottom part of the Event Master Record Function screen. Enter a valid dependency for this version of the event.
150
4 Events
The most common WHEN keyword is EOJ jobname which dispatches the event at the successful end of the specified job. You can combine several WHEN conditions with the use of the keywords AND and OR. For example,
WHEN (DSN DATASET.NAME AND EOJ PAYROLL)
See WHEN Condition Keywords on page 145 for a complete list of valid keywords. 4 5 Press Enter. The event version is updated with the WHEN conditions. To define a dependency for another version of the event, enter ADD # (where # is the version number) on the Command line. Repeat steps 3 and 4. You can use the same dependency for multiple versions of an event using the COPY command. For example, to copy the dependency from version 7 to version 8, display the Event Master Record Function screen for version 7. Enter COPY 8 on the Command line. The dependency is copied to version 8, and the screen is displayed in Edit mode for version 8. If you do not specify a version number to copy to, Zeke selects one for you.
Viewing WHEN Conditions for All Event Versions

You can view the WHEN conditions that are defined for each version of an event.
To view WHEN conditions for all event versions

1 Access the Event Master Definition screen for the desired event as instructed in Accessing the Event Master Record on page 82.
Class: CMS:
Pri: Ftype:
151
Enter WHEN * on the Command line and press Enter. If there are WHEN conditions defined for the event, the WHEN/SET Clause Directory screen is displayed.
ASG-Zeke Command ===> WHEN/SET Clause Directory Scroll ===> PAGE
Primary Commands: ADD Line Commands: E - Edit Evt: 000032 Type: JOB
B - Browse
D - Delete
Job: NOMTEST Evt Name: TESTADDNM Calid: A Info: Platform: MVS Version Clause (partial) More ========================================================================== 00000 (EOJ TESTJOB0) 00002 (EOJ TESTJOB0 OR VAR $TESTVAR EQ YES) 00003 (EOJ TESTJOB2) 00004 (EOJ TESTJOB0 AND EOJ TESTJOB2 VER 2) ******************************Bottom of data******************************
All the WHEN conditions that have been defined for the event are listed, with their corresponding version numbers. If a dependency is longer than the width of the screen (indicated by a '>' symbol in the More column), you must go to the Event Master Record Function screen to view the remainder of the clause. To do so, use the Browse line command as described below. 3 Perform the steps in the Action column in the following table, depending on the desired results. Desired Result
Add a dependency for a new version number
Action
Enter ADD ver# on the Command line (where ver# is the number of the version you are adding). For example, ADD 5. Press Enter. The Event Master Record Function screen is displayed in Add mode. See Defining a WHEN Condition on page 150 for further instructions.
Browse the WHEN conditions for a particular version of the event
Enter B to the left of the dependency you want to browse. Press Enter. The Event Master Record Function screen is displayed in Browse mode.
152
4 Events
Desired Result
Delete the WHEN conditions for a particular version of the event
Action
Enter D to the left of the dependency you want to delete. The Event Master Record Function screen is displayed and you are asked to confirm the deletion. Type DELETE on the Command line and press Enter to confirm, or press F3 to cancel. Or, 1 Enter E to the left of the dependency you want to edit. The Event Master Record Function screen is displayed in Edit mode. 2 Type DELETE on the Command line and press Enter. 3 Type DELETE on the Command line again and press Enter to confirm, or press F3 to cancel.
Edit the WHEN conditions for a particular version of the event
Enter E to the left of the dependency you want to edit. The Event Master Record Function screen is displayed in Edit mode. When finished editing the dependency, press Enter to save your changes.
153
Condition Codes
Condition code validation is used to:
Flag a job as abended based on end-of-job (EOJ) or end-of-step (EOS) condition codes Cancel a job based on EOS condition codes Define an acceptable range of condition codes based on EOS Define EOJ and EOS condition code checking for an event Maintain the maximum condition code at EOJ
A condition code is not considered an abend by Zeke unless the operating system considers it an abend (or unless you manually define it as an abend). The condition code can be defined at the step level or job level. Step-level and EOJ checking are processed independently. This is useful if there is a maximum condition code that is valid for the entire job, and in addition, a specific condition code on a specific step requires an immediate cancellation. Zeke checks any specified step names first. Then, after the job completes, the maximum condition code for the job is checked. For every step specified, Zeke searches for the first match on STEP NAME, PROC STEP, OPERATOR, and RANGE. If a match is found, Zeke performs the specified action and the search ends. If there is no match, no action is taken. If an end-of-job condition is specified (i.e., EOJ CC), then that condition is compared at the end of the job to the maximum condition code from any step in that job. A condition code value that is acceptable at the step level can be designated as AEOJ at the job level.
Note:
If you have Zebb installed, condition code checking should be performed in Zeke.
To add, update, or delete condition codes

1 Access the Event Master Definition screen as instructed in the procedure Accessing the Event Master Record on page 82. From the Event Master Definition, enter CCODE on the Command line and press Enter.
154
4 Events
The Condition Code Validation screen is displayed.

ASG-Zeke Command ===> Condition Code Validation EDIT Scroll ===> PAGE
Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA RA =Range O = Ok - Range Low High 8 16 0 Action Event Name: ZEKE51CC
Operators: Actions: Stepname EOJ CC STEP01 STEP02 ********
******** ******** ********
GT NE GT
F O C
Perform the steps outlined in the Action column, depending upon the desired result: Desired Result
Add a new or edit an existing condition code Delete a single condition code Insert a new line after this line
Action
Ensure you are in Edit mode. Go to step 4.
Enter D on the left side of the screen next to the condition code you want to delete and press Enter. Enter I on the left side of the screen next to the line you want to insert after and press Enter. Note: You cannot insert lines before the line EOJ CC.
Repeat this line
Enter R on the left side of the screen next to the line you want to repeat and press Enter.
155
Enter information in the following fields. Field

Stepname
Description
The JCL step name. If the step is in a procedure, enter the step name that executes the procedure. If the stepname is nulls or blanks, enter the procstep name. You can use an asterisk as a wildcard character to identify a generic step name. For example, ***STEP5 selects step names with STEP5 in positions 4 through 8. Always list the most specific steps first, and the most generic steps last. For example, list STEP3 before ******** (see Sample Condition Code Entries on page 158 for detailed examples).
Procstep
The stepname within the procedure. If the JCL stepname was nulls and you entered the procstep name in the stepname field, leave this field blank. You can use an asterisk as a wildcard character to identify a generic procedure stepname. For example, ***PROC5 selects a procedure stepname with PROC5 in positions 4 through 8.
Operator
Operator indicating when to perform a specified action. Code EQ LE Meaning When the condition codes are EQual. When the condition code is Less than or Equal to the specified condition code. When the condition code is Less Than the specified condition code. When the condition code is Greater Than the specified condition code. When the condition code is Greater than or Equal to the specified condition code. When the condition codes are Not Equal. When the condition code is in the specified RAnge.
LT
GT
GE
NE RA Low
The code to compare. If Operator is RA, the lowest code in the range to compare. The highest code to compare. Only make an entry in this field if the Operator is RA, to create a range.
High
156
4 Events
Field
Action
Description
The code that identifies the action to take when the condition code meets the specified criteria Code F C Meaning Flag the job as Failed during end of job processing. Cancel the job at this step and flag it as Failed during end of job processing. Continue processing.
Use the EOJ CC line to specify condition codes to compare at the end of the job. a Make entries in the Operator, Low, and High fields just as you do for step-level checking. In the Action field, enter F. This is the only valid action for the job-level. Checking will be done at the job end for the maximum condition code from any step in this job. This checking is done independently of any step-level checking specified.
When you have finished updating condition code information, press Enter.
157
Sample Condition Code Entries

The following sample screens present a few different scenarios that might help you when defining your condition codes. In this first example, the ******** ******** acts as a generic condition code and applies to all steps except STEP3. If STEP3 receives a condition code 4, job processing continues; but if any other step gets a condition code greater than zero, the job is marked AEOJ and is cancelled.
Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA RA =Range O = Ok - Range Low High 4 0 Action Event Name: ZEKE51CC
Operators: Actions: Stepname EOJ CC STEP3 ********
******** ********
EQ GT
O C
In the following example, EOJ CC takes priority since it is encountered first in the list. Therefore, the conditions for STEP3 and STEP5 are ignored, and the job is marked AEOJ, even if STEP3 receives a condition code 4 or if STEP5 receives a condition code 8.
Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA RA =Range O = Ok - Range Low High 0 4 8 Action F O O Event Name: ZEKE51CC
Operators: Actions: Stepname EOJ CC STEP3 STEP5
EQ NE LE LT GE GT F = Fail, C = Cancel, Procstep Operator GT EQ LE
******** ********
158
4 Events
If you want to use the above example but you want the conditions for STEP3 and STEP5 to be checked, define the condition codes as shown in this example.
******** ******** ********
EQ LE GT
O O F
Here is the same scenario, but with a PROCSTEP defined.

PSTEP3 ******** ********
EQ LE GT
O O F
In this case, the job is not marked AEOJ if STEP3 PSTEP3 receives a condition code 4 or if STEP5 receives a condition code less than or equal to 8. Otherwise, if any other step/program receives a condition code greater than zero, the job is marked AEOJ. (Consequently, if any program within STEP3 other than PSTEP3 receives a condition code 4, the job is marked AEOJ.)
159
If the JCL step name is nulls, and the procedure MYPROC contains the step MYSTEP define the condition codes as follows.
Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA RA =Range O = Ok - Range Low High 4 0 Action Event Name: ZEKE51CC
Operators: Actions: Stepname

EOJ CC
MYSTEP ********
********
EQ GT
O F
160
4 Events
Work Centers
Work center events (work centers) are tasks that require manual intervention. For example, events that require any of the following:

User input, such as dates or check numbers User approval Completion of a manual task, such as data entry
Work centers allow the user to communicate directly with the schedule. You can add, alter, and control your own events without filling out a form, making a phone call, or writing a note to an operator or your data center. Work centers perform many functions, including:
Scheduling manual tasks that need to be complete by a certain time, Zeke lets you know when an event is late Running request jobs exactly when you need them, operator notification or intervention is not necessary Approving an event for processing Setting Zeke/OASIS variable values Triggering other events that are in the schedule Acting as a prerequisite for another event, completion of a work center satisfies an EOE dependency. Setting a variable through a work center and using that variable with the VAR keyword in a dependency
Note:
While work centers can be predecessors for other events, they cannot have their own WHEN clause. Instead, work centers can have SET clauses, as explained in the following sections. Work centers also do not use resources.
Variables in Work Centers

Work centers are often used to set variables. You can specify for a work center to set a variable to a specific value and then use that value as the prerequisite for another event. For example, suppose you are waiting for management approval before running a job. You can set up a work center to be completed when approval is obtained. Lets say you set up a variable called $APPROV. Completing the work center sets the variable $APPROV to the value GO. The work center event would contain the WHEN condition $APPROV EQ GO. When the work center is completed, $APPROV equals GO and the dependent job is triggered.
161
SET Clauses
Zeke or OASIS variables can be set to a specified value when a work center is completed. The SET clause defines how a variable value is set when a work center is completed. The format of the SET clause is similar to a WHEN condition that uses the VAR keyword, except that only an EQUAL condition can be specified. For example,
(VAR $TEST01 EQ PROCEED AND VAR $TEST02 EQ WAIT) (XVAR TEST03 EQ 'A VALUE WITHIN DELIMITERS')
Use the following keywords in the SET clause statement: Keywords Zeke
VAR
OASIS
XVAR
Description
Variable is automatically set to the specified value when the work center is completed. The operator cannot change the value.
(VAR $JOB1 EQ 45)
When the operator completes this work center, the $JOB1 variable is automatically set to 45. ?VAR ?XVAR Variable value can be entered by the operator before completion of the work center; if desired (the operator is not required to change the value). When the operator completes an event with a ?VAR or ?XVAR, Zeke displays a screen for entering the variable value. Example:
(?XVAR DATE EQ 'MM/DD/YYYY')
In this example, 'MM/DD/YYYY' is the default value and is retained unless the operator enters a new value. When the operator completes this work center, the next Work Center Control Functions screen is displayed and prompts the operator to enter the current date. When using OASIS variables in a SET clause, do not enclose the variable name in the substitution prefix/suffix (the $( ), or additional prefix/suffix defined for your system). OASIS variables qualified by jobname cannot be used in work centers. (Refer to your ASG-OASIS for z/OS Reference Guide for detailed information about OASIS variables and qualifiers.) Keywords can be mixed in the same SET clause. For example,
(?VAR $TEST03 AND XVAR TEST02 EQ 'YES')
When this work center is flagged as complete, the operator is prompted to enter the value for $TEST03 and Zeke automatically sets the OASIS variable TEST02 to YES.
162
4 Events
Setting Up Work Centers

Work centers are typically set up by scheduling personnel and completed by data center operators.
To set up work centers

1 Access the Event Master Definition screen as instructed in Accessing the Event
Master Record on page 82.

Event===> Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT OCCURS PATH PRED REACT RESOURCE SUCC WHEN Template: N Permanent: N Milestone: N Evt: 246 Desc: OBTAIN AUTH FOR JOB CASH0200 Type: WORK Desc2: Event Name: CASH0199 App: Grp: Usrid: EAN DRL: System: ZEQA Cal: A Retain: N Nwday: B Multhit: N Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A
WorkCtr WorkCtr WorkCtr WorkCtr WorkCtr WorkCtr
Line Line Line Line Line Line
1: 2: 3: 4: 5: 6:
OBTAIN MGMT OK FOR CHECK RUN
Enter information in the following fields to define a work center. Field

Template
Description
If you are defining a template, enter Y in this field. Otherwise, leave the default N. A user-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event. Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. EOE, AEOE and End of Group (EOG) WHEN conditions and operator commands use the event name. If you are creating this event from a template, change this name to differ from the template.
Desc/Desc2
Event Name
163
Field
Usrid
Description
An eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs. Be sure to enter the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID applies to Zeke internal security only.
System
The system or pool that owns the event. An event is associated only with one system. This is the system the event is dispatched from, not necessarily the system the EMR is defined on. The number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load using the ZADD command (up to 32,767 versions). See Creating Multiple Versions of an Event on page 97 for details on multiple event versions. Note: The SKIP(OFF) attribute is applied to the end of the Target field (the previous field on the EMR), to prevent a user from overtyping data intended for the Target field so that it overflows into the Verload field. Stray characters in the Verload field could result in an excessive number of events being scheduled unintentionally during the next schedule build cycle.
Verload
WorkCtr Line
The description of the work center activity. This information serves as instructions to the work center user. Up to six lines of comments can be entered. If more are needed, use the Documentation facility to add more notes.
164
4 Events
App Grp
Description
A user-assigned code to identify the application the event is a part of. A user-assigned code to identify the group the event is a part of.
Press Enter. The changes are saved and the screen is displayed in Update mode. If you are adding the event, an event number is assigned.
To set up a SET clause for this work center, enter WHEN on the Command line and press Enter. The Event Master Record Function screen is displayed.
ASG-Zeke Command ===> Event Master Record Function EDIT Scroll ===> PAGE
Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN Evt: 000013 Type: WORK Job: Evt Name: Calid: A Ver: 00000 Info: ***** ***************************** Top of Data **************************** ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 (?VAR $JOB1KG EQ XXXXXX) ***** **************************** Bottom of Data **************************
A SET clause is used instead of a WHEN condition for work center events. Enter the SET clause, enclosed in parentheses, and press Enter. See "SET Clauses" on page 162 to get an understanding of the function of the SET clause. See IF Clauses On SET Statements on page 359 for help defining the prerequisites that must occur before the event can be dispatched (if any). The changes are saved and the screen is re-displayed in update mode.
Perform the procedure Defining an OCCURS Clause on page 132 to specify when the event should be added to the schedule.
165
Be sure the operator has access to Zeke. If desired, you can set up the users Zeke operator ID so that when they log on to Zeke, the Work Center Selection Criteria screen is automatically displayed. See Setting Up Operator IDs on page 379 for more information. a Enter A to create a class ID with auto-entry access to the Work Center function. Associate the users operator ID with the class ID and with the user ID of the work center event.
The next time the SCHEDULE function runs, the work center event will be scheduled (assuming the OCCURS clause is true). Be sure all operators are aware of their user IDs for their work center events and how to log on to Zeke.
10
Completing Work Centers

Before an operator attempts to complete a work center, be sure the operator has access to the Zeke Work Center function.
To complete a work center

1 Depending on how your operator ID is set up, the Work Center Selection Criteria screen may automatically display when you log on to Zeke. Go to step 3. If the Work Center Selection Criteria Screen does not automatically display when you log on to Zeke, then from the Zeke Primary Menu, enter 5 and press Enter. The Work Center Selection Criteria screen allows you to display a directory of work center events.
ASG-Zeke Option ===> 1 2 3 Not Done All Done Work Center Selection Criteria
Directory of scheduled Work Centers not completed Directory of all matching scheduled Work Centers Directory of scheduled Work Centers completed
.-------- Selection Criteria --------. | | | UserID => KAC | | App => | | Group => | | System => | | | '------------------------------------'
166
4 Events
Enter one of the menu options on the Option line, depending on whether you want to see completed work centers only, uncompleted work centers, or both. Optionally, enter selection criteria to view a specific work center or group of work centers. If you leave a field blank or enter an asterisk only, then that field is not used to restrict the group of work centers selected. An asterisk (*) in any position performs a wildcard search for all positions following it. For example, ABC* in the UserID field selects all work centers assigned to users whose Zeke ID begins with ABC. A question mark (?) in any position performs a wildcard search for that one position. For example, A?C selects all records beginning with A, ending with C, and with any character in the second position. The wild cards can be used together. For example, enter R?M* for all user IDs beginning with R, with any letter in the second position, with M in the third position, and with any character in the remaining positions. Field
UserID
Description
Enter selection criteria to specify the group of user IDs to select. Zeke supports mixed-case user IDs. Be sure to enter the search criteria in the correct case (upper, lower, or mixed). Application name for the work center. Group name for the work center. System where the event executes.
App Group System
Press Enter. The Directory of Work Center Events is displayed.

ASG-Zeke Command ===> Directory of Work Center Events Row 1 to 2 of 2 Scroll ===> PAGE
Line Commands: A disAble B Browse C Complete N eNable O dOcumentation R Refresh Today :04/19/2007 Time :12:46:55 (36:46:55) Event Work Date Versn Sched Event Name Appl Grp System Set Status 000202 06/17/2007 00000 00:00 EANTST TSO45 Y NOT DONE 000205 06/17/2007 00000 00:00 EANTST05 TSO45 Y NOT DONE 000833 06/17/2007 00000 00:00 TEST OVAR APPL GRX TSO45 Y NOT DONE ***************************** Bottom of data ******************************
167
Browse the event
Action
Enter B to the left of the Event field. Use this command before completing the work center if SET=N. Enter C to the left of the Event field. If SET=N, the event status is changed to DONE. If SET=Y, the Work Center Function screen is displayed and you are asked to verify the variable value or enter a new one. Go to step 8.
Complete the event
Disable the event
Enter A to the left of the Event field, if the event is not considered part of the schedule. The status is updated to DISABLED. Enter N to the left of the Event field. The status is updated to ENABLED. Enter R to the left of the Event field. This changes a complete event to NOT DONE. Enter O to the left of the Event field. See Accessing Event Documentation on page 181.
Enable the disabled event
Refresh the event
Display the Work Center Doc. Segments Screen
The Work Center Control Function screen is displayed in browse mode.

ASG-Zeke Command ===> Primary Commands: Event: 000229 Appl: PAY Work Center Control Function
COMPLETE
DISABLE
DOCUMENT
ENABLE
REFRESH
Event Name: PAYCHECK Group: PAY UserID: KAC
System: A Set ver: 00000
Schd: 00:00 Sdate: 01/30/2007 Rdate: 01/30/2007 Today:01/30/2007 Late: Times: 001 Freq: * DONE * Time:16:01:51 (40:01:51) Comment Line 1: ENTER THE STARTING CHECK NUMBER AND PRESS ENTER. Comment Line 2: Comment Line 3: Comment Line 4: Comment Line 5: Comment Line 6: Set: (?VAR $PAYCHECK EQ 'NNNN')
Note:
Press Enter to display additional SET statements when there are multiple variables.
168
4 Events
The Work Center Control Function screen is displayed in update mode.

ASG-Zeke Command ===> Work Center Control Function
Depress the enter key to accept the new value, or depress PF3 to maintain the current value. Event: 000229 Appl: PAY Event Name: PAYCHECK Schd: 00:00 Late: Comment Line Comment Line Comment Line Comment Line Comment Line Comment Line Group: PAY System: A UserID: KAC Set ver: 00000
Sdate: 01/30/2007 Rdate: 01/30/2007 Today: 01/30/2007 Times: 001 Freq: NOT DONE Time: 15:59:27 (39:59:27) 1: ENTER THE STARTING CHECK NUMBER AND PRESS ENTER. 2: 3: 4: 5: 6:
Data-Name: $PAYCHECK Curr Value: 1001 New Value: 'NNNN' Force upper: Y
To use the current value and complete the work center, press F3.
Or
To change the value and complete the work center, enter a new value in the New Value field. The variable value can be numeric or any alphanumeric combination up to 64 characters in length. 9 In the Force Upper field, specify of the following codes if the Current Value includes alpha characters: Code
Y N
Meaning
Forces the Current Value string to uppercase. Keeps the case of the Current Value exactly as entered. Specify this code if you need to allow mixed-case values for variable substitution.
Note:
If the Current Value is numeric only, the Force Upper option is ignored.
169
10
Press Enter. A verify screen is displayed after all the variables are set.
ASG-Zeke Command ===> Work Center Control Function Row 1 to 2 of 2 Scroll ===> PAGE
Primary Commands: COMPLETE
CANCEL
Event: 000229 Ver: 00000 Sdate: 01/30/2007 Rdate: 01/30/2007 Today :01/30/2007 Time :15:59:27 (39:59:27) Set Ver: 00000 -------------------------------------------------------------------------Variable: $PAYCHECK ?Value: '1051' ****************************** Bottom of data*******************************
11
Perform the steps in the Action column, depending upon the desired result: Desired Result
Confirm the values are correct and complete the work center
Action
Enter COMPLETE on the Command line and press Enter. The Work Center Directory is displayed. The status is updated to DONE.
Do not set the values, or do not complete the work center
Enter CANCEL on the Command line and press Enter. The Work Center Directory is displayed. The status is unchanged.
170
4 Events
Auto Replies
Zeke allows you to respond automatically to outstanding replies (WTORs) from your Zeke-controlled jobs that have static or predictable responses. Replies can also use Zeke or OASIS variables to substitute all or part of the reply text. They can be limited by date, step, and program. Up to 999 replies can be defined for a single job. For example, replies can be triggered by any portion of the text of the message, message ID, or unique text string. Replies can even be triggered by suppressed messages. Each reply is called an element.
Note:
Auto replies are not supported in remote jobs. If a remote job containing an auto reply is dispatched, it must be replied to manually on the remote system.
Related Generation Options

Three generation options affect automatic replies for your systems: Generation Option
Aur Aurintv Aurmsg
Description
Enables or disables automatic responses to messages and replies. Specifies the interval to check for automatic responses. Indicates if the operator is notified of auto response issues.
The way these global functions are set for your system will determine your need to use the automatic reply operator commands to manually enable or disable exceptions to the global generation options for automatic replies. Caution! The defaults for Aur, Aurintv, and Aurmsg should already be activated before using automatic replies. See Setting Auto Replies on page 303, for additional information. In addition, you can use the ZDISPLAY, ZENABLE, and ZDISABLE operator commands to maintain existing automatic replies. These operator commands are used when you want to manually display, enable, or disable an automatic reply. For example, the Aur option on system A is set to Yes. This function globally enables automatic responses on system A. However, you do not want Job XYZ on system A to automatically reply to messages. To deactivate the automatic reply elements for Job XYZ, use the ZDISABLE command.
171
Maintaining Auto Replies

To maintain automatic replies for a job event
1 Check the Aur, Aurintv, and Aurmsg generation options to determine:
Global setup of automatic replies for your systems. See Setting Auto Replies on page 303. If there are exceptions to the global setup of automatic replies, use ZDISPLAY, ZENABLE, and ZDISABLE operator commands where applicable. See Displaying, Enabling, or Disabling Auto Replies on page 175.
Access the Event Master Definition screen as instructed in Accessing the Event Master Record on page 82. Enter AUTORPLY on the Command line and press Enter.
If auto replies exist for the event, the Auto Reply Summary screen is displayed. Go to step 4. If auto replies do not exist for the event, the Auto Reply Function screen is displayed. Go to step 5.
The Auto Reply Summary screen provides a list of all auto reply elements that have been defined for the event.
ASG-Zeke COMMAND ===> Auto Reply Summary SCROLL ===> PAGE Z1113000
Primary Commands: ADD DELALL Line Commands: B - Browse D - Delete
E - Edit
Event: 000019 Jobname: SPTEXD19 System: ZEQA Event Name: EKGSTRT1 NUM ----------------------- Message Text ----------------------PROGRAM 001 TEST MSG 001 ENTER GO TO PROCESS ***************************** Bottom of data ******************************
Add an auto reply element
Action
Enter ADD on the Command line and press Enter. Go to step 5. Enter DELALL on the Command line and press Enter. To confirm the delete, press Enter again. Enter B to the left of the NUM field and press Enter.
Delete all auto reply elements
Browse the auto reply detail 172
4 Events
Desired Result
Edit the auto reply element
Action
Enter E to the left of the NUM field and press Enter. Go to step 5. Enter D to the left of the NUM field and press Enter. To confirm the delete, press Enter again.
Delete the specific auto reply element
The Auto-Reply Function screen is displayed.

ASG-Zeke Command ===> Auto-Reply Function EDIT Update complete
Primary Commands: ADD BACK BROWSE DELALL DELETE EDIT NEXT Event: 000019 Jobname: SPTEXD19 System: ZEQA Event Name: ZEKE51CC
Desc: EKGSTRT1 Desc2: Automatic Reply Element Number: 001 Msg text: ENTER GO TO PROCESS Reply: GO Effective as of: 01/01/2007 Effective until: 06/01/2007 Job step name: STEP1 Program (Exec): <== <== MM/DD/YYYY MM/DD/YYYY
The Automatic Reply Element Number is the Zeke-assigned number that identifies the reply element. When there are multiple replies to the same message text, Zeke issues the elements in sequence starting with the lowest number and flags the element as used. If the message is issued more times than there are replies, the last used element is repeated. If a message is defined with only one reply, Zeke issues that reply as many times as needed. 5 Enter information in the following fields. Field
Msg Text
Description
Message to be replied to. This does not need to be the whole message; just enough to make a unique match. The message ID is usually a unique identifier.
173
Field
Reply
Description
Reply you want Zeke to issue to the message. For example: To enter a null reply... To enter a static reply... Leave Reply field blank. Enter YES in the Reply field, for example. Enter $CURDATE in the Reply field, for example.
To use a variable for a reply...
To use a variable with In the reply field, enter, for example: constant values in a reply...
YESTERDAY WAS $(PREVDATE)
Effective As Of Effective Until JOB STEP NAME
Date the reply goes into effect, formatted as shown on the screen. Date the reply expires, formatted as shown on the screen. OS job step name that issues the message text. The auto reply is only valid if this job step issues the message. Program name that issues the message text. The auto reply is only valid if this program issues the message.
Program (EXEC)
Press Enter to update the data.
174
4 Events
Displaying, Enabling, or Disabling Auto Replies

You can use the ZDISPLAY, ZENABLE, and ZDISABLE operator commands to manually display, enable, or disable automatic replies for a job event.
Displaying Auto Replies (ZDISPLAY)

The ZDISPLAY command performs many functions. One of those functions is to display the active automatic reply elements for a given jobname. If a job event is running, Zeke displays the messages and replies that are active for that job event.
To display active automatic reply elements

Issue the ZDISPLAY command with the JOBNAME and REPLY parameters. For example, to display messages and replies for jobname TESTXYZ, use:
ZDISPLAY JOB TESTXYZ REPLY
Enabling Auto Replies (ZENABLE)

The ZENABLE command has two functions.
To reactivate or enable one or more events that were previously disabled using the ZDISABLE command. To reactivate the automatic reply elements for an event that had automatic replies disabled.
A disabled event that was scheduled for a prior day will most likely have been dropped by the current day's first schedule update.
To enable an auto reply for an event

Issue the ZENABLE command with the REPLY and EVENT parameters. For example, to enable previously disabled auto replies for job 55, use:
ZENABLE JOB 55 REP
Disabling Auto Replies (ZDISABLE)

The ZDISABLE command has two functions.
To deactivate or disable one or more events that were previously enabled using the ZENABLE command. The ZDISABLE command prevents WHEN conditions for that event from being satisfied. To deactivate the automatic reply elements for an event that had automatic replies enabled.
175
To disable an auto reply for an event that is not running

Issue the ZDISABLE command with the REPLY and EVENT parameters. For example, to disable the auto reply for job 77, use:
ZDISABLE REP JOB 77
Maintaining JCL
You can store JCL for events in the Zeke database. However, it is not necessary if you have a JCL library facility. Zeke can retrieve JCL from a number of JCL library facilities, such as Bim-Edit, CMS, Librarian, Panvalet, and PDS. Before you can retrieve JCL for an event, you must first define your installed JCL libraries to Zeke.
Setting JCL Source Options

This section tells how to identify to Zeke the JCL libraries to be used. Each library type requires some steps to be performed by the systems programmer. Refer to the section on JCL library support in your ASG-Zeke for z/OS Installation Guide for information on link editing the third-party libraries or installing PDS or CMS support.
To set the JCL source generation options

1 Enter =4.1 on any Zeke Command line and press Enter.
ASG-Zeke Command ===> System ===> Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete System ******** MEDAZ520 ZK51VLT ***************************** Bottom of data ****************************** Option System Directory Row 1 to 1 of 1 Scroll ===> PAGE
E - Edit
Enter E to the left of system you want to change and press Enter.
Note:
'********' is the generic system. If generation options are not set for a system, it defaults to the generic system values.
176
4 Events
The Generation Options screen is displayed with the options in alphabetical order. 3 Use the F8 or F7 keys to scroll, as necessary.
ASG-Zeke Command ===> Zeke System: Abhold: Aur: Aurintv: Aurmsg: Batoprid: Batsec: Bimappl: Bimpasw: Bimuid: Bypjob: Calcmem: Calctap: Chgval: Cmdcons: Cmsftype: Commctl: Condrdv: Condrlb: Condrver: ******** (Y or N) (Y or N) (1 - NN) (Y or N) (xxxxxxxx) (Y or N) (xxxxxxxx) (xxxxxx) (xxxx) (Y or N) (Y or N) (Y or N) (Y or N) (Y or N) (xxxxxxxx) (Y or N) (xxxxxx) (xxxx) (xxx) Yes to hold recurring events if abended Yes to enable automatic responses Number of seconds to check auto responses Yes to inform operator auto. response issue Default security batch operator id Yes for Zeke to perform batch security Bimedit application name Bimedit access password Bimedit access userid Yes for Zeke to bypass all Power Job cards Yes to calculate virtual memory (VSE) Yes to calculate tape drive usage Yes to display Variable update message Yes to route cmd response to console Default CMS filetype Yes to retain Work Events until completed Condor camlib device name Condor camlib qualifier Condor version id Generation Options EDIT Scroll ===> PAGE
N Y 01 Y BATCH N
OMIT N Y Y Y Y JCL Y SYS000 OMIT 001
Depending on the JCL libraries you use, update the following options. Library
Librarian
Generation Options
If you do not know your Librarian number or codes, contact your Librarian vendor. Fairmod Your Librarian modification number. (Librarian 3.1 or higher.) Your Librarian options code. (Librarian 3.1 or higher.) Your Librarian record code. (Librarian 3.1 or higher.) Librarian library block size. Zeke uses this number to determine the amount of storage required for Librarian subroutines. The default is 12800. DD name of the Librarian library Zeke uses to retrieve JCL. The default is OMITTED. (The name LIBRJCL is reserved and cannot be used.)
Fairopn Fairrec Librblk
Librdtf
177
Library
Bim-Edit
Generation Options
Bimappl (optional) Bimpasw Bimuid
Application name of the Bim-Edit to be associated with Zeke. Unique BIM password. User ID Zeke passes to Bim-Edit in order to receive JCL. The default is OMIT.
Condor Condrver Condrlb Your Condor version number. The default is 001. Library that Zeke will pass to Condor to receive JCL. The default value is OMIT.
Panvalet Pandisk Code indicating the DASD type of the disk where the Panvalet library resides. This field cannot contain blanks. FBA 3340 3350 3375 3380 (default) 3390 3331 (3330-11 disk devices) Pandtf DD name of the first Panvalet library to be searched. If a value is not entered, Zeke searches for DD names of PANDDxx. The default is OMITTED. Amount of memory Zeke requires to obtain the Panvalet work area. The default is 0240.
Panmem
PDS Pdsdd The DD name in the Zeke started task procedure of the partitioned dataset to retrieve JCL.
VM/CMS JCL
Userid The name of the CMS JCL machine.
178
4 Events
Page to the Defjcl generation option and enter the code specifying the default JCL source type. The default JCL source type is used if none is specified on the EMR. Code
BIM CMS CONDOR LIBR PAN PDS ZEKE Z14C
Meaning
Bim-Edit CMS file Condor Librarian Panvalet Partitioned dataset member Zeke JCL Source not supported by Zeke (JCL is supplied by the ZEKE14C user exit)
Page to generation option JCL1 and enter one of the JCL sources listed above. You can enter additional JCL sources in the remaining JCL2-JCL5 fields. These options determine which JCL fields display on the Event Master Definition screen. Press Enter to update the options. To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.
7 8
Retrieving JCL from the Zeke Database

From the Event Master Definition screen, you can only retrieve Zeke JCL; however, you can retrieve Zeke JCL and any other valid JCL source from Schedule View. See Maintaining JCL on page 232 for further instructions on using Schedule View to retrieve JCL stored within other packages, as well as Zeke JCL.
Note:
ZEKEJCL must be defined as a JCL source type on the Generation Options screen. See Setting JCL Source Options on page 176 for more information.
To retrieve and maintain JCL that is stored in the Zeke database

179
ASG-Zeke Command ===>
Event Master Definition
EDIT
Class: CMS:
Pri: Ftype:
Enter JCL on the Command line and press Enter. The JCL screen is displayed. If no JCL exists, the screen is displayed in Add mode.
ASG-Zeke JCL EDIT Event 00060 Command ===> Scroll ===> PAGE ****** **************************** Top of Data **************************** ==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF). ==MSG> Data has valid standard numbers. ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000100 //MVSDEM10 JOB (10038),'G HILED', 000200 // MSGCLASS=Y,CLASS=A, 000300 // REGION=4M 000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5' 000610 //STEPLIB DD DISP=SHR,DSN=OASIS.R220A.LINKLIB.OS3901 000620 //* DD DISP=SHR,DSN=OASIS.R230A.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.R230AM1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDJKL.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDMNO.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.R300A.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.R300A.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *
While using this screen, control is passed to the ISPF Text Editor. Use the standard ISPF commands to add, delete, or edit the JCL. Press F3 to save the changes and return to the Event Master Definition screen.
180
4 Events
Event Documentation
Event documentation is used to store useful information about the event. There are four areas documentation can be stored. Documentation Type
Scratch Note Text Dataset
Description
Stores brief notes, limited to 10 lines Stores brief notes, limited to 10 lines Stores up to 450 records approximately Stores names of datasets used by a job
Accessing Event Documentation

Event documentation can be maintained through the Event, Schedule View, Documentation, and Work options in the Zeke online facility. All options update the same records. For simplicity, this procedure takes you directly through the Documentation option.
To access event documentation

1 From the Zeke Primary Menu, enter 7 and press Enter. The Documentation Selection Criteria screen is displayed. 2 Perform the steps in the Action column, depending on the desired result Desired Result
Update documentation for which you know the event number
Action
Enter EDIT on the Command line. Enter the event number in the Event field. Press Enter. The Documentation Segments screen is displayed. Go to step 4.
Update documentation for which you do not know the event number
Enter any character next to the appropriate event type under Event Types and any information you know for any of the Selection Field Masks fields. Press Enter.
181
The Event Documentation Directory is displayed. If an asterisk (*) is displayed in a column, that type of documentation exists for the event.
ASG-Zeke Command ===> Event Documentation Directory Scroll ==> PAGE
Line Commands: E/E1/E4 - Edit B/Bn - Browse D/D1/D4 - Delete n = 1 through 4 for specific types of documentation 1 Scratch * * 2 Text * * 3 Tape * 4 Note * *
Event -Event Name000001 ZEKE51TST1 000002 ZEKE51TST2 000003 ZEKE51TST3 000004 ZEKE51TST4 000005 ZEKE51TST5 000006 KTEST1 000007 KTEST2 000008 KTEST3 000009 KTEST4 000010 KTEST5 000011 ZEKE51CC 000012 ZEKE51CC 000013 000014 000015 000016
Jobname
TSKKGUT1 TSKKGUT2 TSKKGUT3 TSKKGUT4 TSKKGUT5 SPTEXD11 SPTEXD12
Type MSG MSG MSG MSG MSG JOB JOB JOB JOB JOB JOB JOB WORK VCOM ZCOM SCOM
Perform the steps in the Action column, depending on the desired result: Desired Result
Edit scratch pad documentation for the event
Action
Enter E1 to the left of the Event field and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 184. Enter E2 to the left of the Event field and press Enter. Go to Maintaining Text Documentation on page 185. Enter E3 to the left of the Event field and press Enter. Go to Maintaining Dataset Documentation on page 186. Enter E4 to the left of the Event field and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 184.
Edit text documentation for the event Edit dataset documentation for the event Edit note documentation for the event
182
4 Events
Desired Result
Delete the specified documentation for the event
Action
Enter Dn to the left of the Event field and press Enter (where n indicates the documentation type): 1 2 3 4 Scratch Pad Text Dataset Name List Note Pad The asterisk (*) indicating that documentation for the event exists is deleted, and the message:
DOCUMENT RECORD DELETED is displayed.
The Documentation Segments screen is displayed. If an asterisk (*) is displayed to the left of the documentation type, that type of documentation for the event exists.
ASG-Zeke Option ===> Primary Command: DELETE Event: 000031 Jobname: A2345678 Documentation Segments EDIT
Event Name: TESTNAME
System: A
Appl:
Documentation Record Selection Options 1 * SCRATCH 2 * TEXT 3 TAPE 4 * NOTE Scratch pad Text information Dataset name information Note pad information
Enter one of the following codes on the Command line to select the type of documentation to work with: Desired Result
Access scratch pad documentation
Action
Enter 1 and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 184. Enter 2 and press Enter. Go to Maintaining Text Documentation on page 185. Enter 3 and press Enter. Go to Maintaining Dataset Documentation on page 186. Enter 4 and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 184. 183
Access text documentation
Access dataset or tape documentation Access note documentation

Scratch Pad and Note documentation each allow you to define up to 10 lines of information for an event. These documentation areas are like sticky notes. They are used to pass notes from shift to shift, or from one department to another. The operator should always review scratch pad or note pad information before an event runs. These areas can also be used for quick reference information. Besides being displayed online and on Zeke reports, this data can be displayed for events in the current schedule through the Schedule View screen and even directly at the system console by issuing one of the following commands:
ZDISPLAY EVENT 99 NOTE Or ZDISPLAY EVENT 99 SCRATCH
Even though there are separate documentation areas for Scratch Pad and Note Information, the screens are identical. This procedure shows the Scratch Pad as an example, but the Note screen works the same way.
To maintain Scratch Pad or Note Documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in Accessing the Event Master Record on page 82.
ASG-Zeke Command ==> Primary Commands: BROWSE Documentation Scratch Pad EDIT
CANCEL
DELETE
EDIT
Line 1 SCRATCH TEXT FOR 30-BYTE NAME JOB 2 3 4 5 6 7 8 9 10 Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: A Desc : 30-CHAR NAME NOM Desc2: Early: Sched: 00:00 Late: Freq: Times: 00001 Vmem : 0* Tapes: 000 Average run time: :00 Jcl: ZEKE
When adding or updating scratch pad or note information, enter text information in the Line area. You can enter up to 60 characters per line, and up to 10 lines of text.
184
4 Events
When you finish adding or updating information on the Scratch Pad or Note screen, press Enter to update the data.

The text documentation allows you to define a sizeable amount of information for an event (up to approximately 450 records). You can maintain text documentation from the Event, Schedule View, and Documentation options. From the Work Center option, you can only browse text documentation.
To maintain Text documentation

1 Access the Text Documentation screen as instructed in Accessing Event Documentation on page 181.
ASG-Zeke Command ===> Event: ****** ==MSG> ==MSG> 000001 ****** Text Documentation EDIT Columns 000 000 Scroll ===> PAGE
000031 Jobname: A2345678 Event Name: TESTNAME System: A *************************** Top of Data ***************************** -Warning- The UNDO command is not available until you change your edit profile using the command RECOVERY ON. tHIS JOB USES TEH 30-CHAR NAME. REVIEW ALL 30 CHAR *************************** Bottom of Data **************************
Enter text to the right of the column placeholder field. You can enter up to 80 characters per line, and up to several hundred lines of text. Use standard ISPF editing commands to edit the text. Press F8 to page forward and access an additional screen. Press Enter to update the data.
3 4 5
185
Maintaining Dataset Documentation

Dataset documentation can be accessed via the Events, Schedule View, and Documentation options.
To maintain dataset documentation required by an event

1 Access the Data Set Name List screen as instructed in Accessing Event Documentation on page 181.
ASG-Zeke Command ===> Data Set Name List EDIT Scroll ===> PAGE
Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat Event: 000031 Jobname: A2345678 System: A Event Name: TESTNAME
I/O T/D Ver --------------Dataset Name-----------------I T 001 JNM.TAPE.STORE ***************************** Bottom of data ******************************
Enter information in the following fields. Field

I/O
Description
The code that identifies the dataset type. Code I O Meaning Input dataset (default) Output dataset
T/D
The code that identifies the dataset media type.

Code T D Meaning Tape (default) Disk
Ver
The dataset version number. This is a required field for input datasets; otherwise, leave it blank. For example, 001 (default) for the most current dataset; 002 next current dataset, etc. The dataset name.
Dataset Name
186
4 Events
Perform the steps in the Action column, depending on the desired result: Desired Result Action
Delete a line Insert a new line after this line Repeat this line Enter D to the left of the I/O field and press Enter. Enter I to the left of the I/O field and press Enter.
Enter R to the left of the I/O field and press Enter.
Press Enter to update the data.
187
Event Activity Accounting

Zeke provides you with a record of event accounting information so you can view the last date and time an event master record was updated and by whom. Event accounting also includes information concerning the last three dispatches of the event.
To view event accounting information

Class: CMS:
Pri: Ftype:
Enter OCCURS on the Command line and press Enter. The Event Record Occurs Clause screen is displayed.
ASG-Zeke Command ===> Primary Commands : Event Record Occurs Clause EDIT
BROWSE EDIT ACCTG OCCHIT Job: TSKKGUT1 Evt Name: ZEKE51TST6 Calid: A
Evt: 000006 Type: JOB Ver: 00000 Occurs: (WEEK.2)
Enter ACCTG on the Command line and press Enter.
188
4 Events
The Event Master Record Accounting screen is displayed.

ASG-Zeke Command ===> Event Master Record Accounting BROWSE
Primary Commands: BROWSE EDIT OCCHIT Evt: 000005 Type: JOB Job: MBCBR14 Ename: IEFBR14 System: MBCX260A
Dispatched 22 Times Last Update: 01/14/2007 15:33 by DEVMBC Start: 01/14/2007 17:37 End: 01/14/2007 17:37:30 Job ID: Version: 0 Sched Date: 01/14/2007 Status: FAIL Dispatch Date 01/14/2007 at 17:37:00 Tapes: 0 Dur: __:__:__ Cputime: __:__:__ Comp.code C0000 Dispatch Date 01/07/2007 at 11:31:00 Tapes: 0 Dur: __:__:__ Cputime: __:__:__ Comp.code C0000 Dispatch Date 01/02/2007 at 12:25:00 Tapes: 0 Dur: __:__:__ Cputime: __:__:__ Comp.code C0000 ------------Avg: __:__:__ Vmem: 0
Vmem:
Vmem:
The screen displays the following event activity information:

Number of times the event has been dispatched. Last date/time the EMR was updated, and by which user. Start date/time of the last execution that ran to completion (AEOJ, DONE, or FDONE). (If the job has never dispatched, this field does not appear.) Status of the last execution that ran to completion: SUCCESS means the event completed successfully (or the event completed successfully after failing once). FAIL means the event ended abnormally. F/SUCC means the event was forced to a successful completion (or the event was forced to a successful completion after failing once). F/FAIL means the event was forced to an abnormal completion.
End date and end time of the last execution that ran to completion. (If the job has never dispatched, this field does not appear.) Details about the last three dispatches.
189
Note:
Most time values are evaluated by Zeke and expressed in hours and minutes only. However, because they affect if and when any dependent events are triggered, dispatch and end times are evaluated and expressed in hours, minutes, and seconds. This is especially important for certain extended dependencies. For example, suppose Job B has an extended dependency on Job A. When Job B is loaded into the schedule, Zeke checks to see if Job A ran since the last time Job B ran. If Job A just ended today at 10:30:25 a.m. and Job B is otherwise ready to run at 10:30:40 a.m. today (during the same minute), then the XEOJ dependency would be satisfied. If Job A did not end until 10:30:56 a.m. (during the same minute), the XEOJ would not be satisfied and the dependency is treated as an EOJ. 4 If desired, you can directly access the OCCURS Hit Resolution screen, or return to the previous screen.
190
Chapter 5:
5
Topic
Creating and Monitoring the Schedule
Once jobs are defined to Zeke, it is time to create a schedule. The progress of the scheduled jobs can be monitored, altered, and maintained through the ISPF online Schedule View function. Page
192 192 194 196 197 197 198 199 202 211 217 219 220 222 224 225 227 229 230 232 234 236 237 239 241 242 243 244
Scheduling Logical Day (48-hour Clock) Creating the Zeke Schedule Setting Zeke to Schedule Itself Adding Events to the Schedule As They Are Created Schedules Downloaded to Zeke Agent How Zeke Determines Dispatching Sequence Forecasting and Simulating the Schedule Using Schedule View Schedule View Commands Accessing Other Online Information Refreshing the Screen Sorting Schedule View Information Selecting Fields to Display Changing the Date Display Format Viewing and Maintaining WHEN Conditions Displaying Event Status Accessing Resources for an Event Using the ZOOM Feature Maintaining JCL Zeke PDS JCL Override Validating JCL Invoking ASG-JCLPREP Invoking JOB/SCAN Using ZSCAN Creating Your Own Line Commands ZCOM Option PathFinder
191
Topic
Manually Adding Events to the Schedule Using the ZADD Operator Command Using the ADD Function Adding Events By Path
Page
250 250 252 255
Scheduling
The main purpose of Zeke is to ensure your jobs are dispatched in the most efficient and timely order. To accomplish this, Zeke creates a schedule of jobs using the SCHEDULE function. Along with creating a daily schedule of actual jobs, Zeke also provides ways to forecast a schedule for a future date and to simulate the run of a schedule complete with initiators, tape drives, and any defined logical resources.
Logical Day (48-hour Clock)

Zeke supports a 48-hour clock, which lets you schedule according to a logical day. If you have events that run past midnight, you can still consider those events to be part of the previous days schedule run. The following example is based on a three-shift day. According to the typical 12-hour clock, shift 1 starts at 8:00 AM, shift 2 at 3:00 PM, and shift 3 at 11:00 PM,. Shift 3 ends the next morning at 8:00 AM. Normal Time Shift
1 2 3
Logical Day Time Start

08:00 15:00 23:00
Start
8:00 AM 3:00 PM 11:00 PM
End
3:00 PM 11:00 PM 8:00 AM
End
15:00 23:00 32:00
In the example, using a logical day, shift 1 starts at 08:00, shift 2 at 15:00, and shift 3 at 23:00. Notice that the end time for shift 3 is 32:00 as compared to 8:00 A.M. on the normal 12-hour clock. This indicates that the entire eight-hour period of shift 3 is considered part of the same logical workday as shifts 1 and 2.
192
5 Creating and Monitoring the Schedule
When the SCHEDULE function runs, it selects every event within 48 hours to be part of the day's schedule. For example, if the schedule runs on Monday at 08:00, events are selected if the OCCURS clauses match Monday and the schedule time is between 00:00 and 47:59.
Note:
An event with a schedule time of 48:00 is never dispatched because 47:59 is the cutoff time for dispatching. Use a schedule time of 48:00 for events that you want to place in the schedule, but do not want to dispatch except by operator command. An event defined as OCCURS(MONDAY) at 27:00 is processed the same time as an event defined as OCCURS(TUESDAY) at 3:00 A.M. The difference is that the first event is included in Monday's schedule run and is considered Monday's event, while the second event is included in Tuesday's run. Event
A B
Weekday
Monday Tuesday
Time
27:00 03:00
Schedule Run Date

Monday (actually runs on Tuesday) Tuesday
193
Creating the Zeke Schedule

Schedule queue records (SQRs) control scheduling and dispatching. The schedule is comprised of all the SQRs created for each Zeke system. The SQRs are created using the SCHEDULE function of the ZEKE batch utility. Executing the SCHEDULE function:
Deletes completed jobs and retains uncompleted jobs from the previous day's schedule.
Note:
Events with no other outstanding dependencies are dispatched immediately after the schedule load completes.
Analyzes each job defined to the Zeke database and determines whether the job is scheduled to occur during the upcoming schedule period.
Note:
Events with no dispatch time, and not scheduled for a future date, are marked time-satisfied immediately.
Analyzes each scheduled job and determines whether the job needs to be downloaded to a remote Zeke Agent system for processing.
Note:
When a schedule is created containing jobs set up to be downloaded to a Zeke Agent target, Zeke compares the subset of the schedule to be downloaded with any existing schedules on Zeke Agent before downloading those jobs. Zeke provides a user exit that allows you to change various fields in the SQRs during the schedule build. Refer to your ASG-Zeke for z/OS Installation Guide for more information on the ZEKE02MX user exits. For instructions on setting Zeke to schedule itself, Setting Zeke to Schedule Itself on page 196.
194
To run the SCHEDULE function to create the daily schedule

1 Run the following job at least once a day.
//ZEKESCHD JOB //SCHED EXEC ZEKEUTL,PARM=SUBSYS=ZDEV //SYSIN DD* SCHEDULE TODAY ACTIVATE DATASPACE /*
Note:
Refer to your ASG-Zeke for z/OS Reference Guide for additional parameters you can use with the SCHEDULE function. 2 Ensure that the schedule load is complete before executing any other batch schedule runs. The schedule load is complete when the following message appears on the console:
Z5G03I SCHEDULE LOAD COMPLETE
Caution! Do not execute multiple SCHEDULE TODAY ACTIVATE functions simultaneously, in the same batch job, or while any system is in WARM mode (ZKILL WARM). Unpredictable results may occur during schedule load in these cases.
Note:
If multiple Zeke systems share a database, the Zeke systems begin the schedule load process after the batch schedule function completes. Each system issues the Z5G02I Reloading schedule message at this time. Once its schedule tables have been updated, each system issues the Z0398I Schedule tables loaded message. Once all systems have updated their schedule tables, only one of the systems will resolve the weak, EOG, extended, and variable WHEN conditions, after issuing the Z0399I Weak satisfy message. Meanwhile, the other systems in the ZekePlex will load the new schedule. Since only one of the systems performs the condition checking, this reduces I/O and shortens the schedule load process. It allows Zeke to load the schedule and begin dispatching events in the new schedule much more quickly. When that one system completes the WHEN condition checks, the schedule load is complete and all systems issue the Z5G03I Schedule load complete message.
195
Optionally, you can use the REPORT parameter to produce specific scheduling reports depending on the sub-parameters used in conjunction with REPORT. If you do not specify REPORT, all the scheduling reports are produced. Refer to your ASG-Zeke for z/OS Reference Guide for more information on generating scheduling reports using Report Writer. Optionally, you can use the OVERRIDE parameter to include and exclude various jobs, regardless of their OCCURS clauses. Refer to your ASG-Zeke for z/OS Reference Guide for more information on selecting events using the OVERRIDE parameter.
Setting Zeke to Schedule Itself

Creating the schedule as indicated in the preceding procedure allows you to run the SCHEDULE function manually whenever you need to. However, we recommend setting up Zeke so that the schedule runs automatically.
To set up an event so the schedule executes automatically

1 Set up a job event as instructed in Maintaining a Job Event on page 92. On the EMR, enter the start time plus 24 hours. For example, if you want the schedule to be created every day at 8:00 A.M., enter a start time of 32:00. Specify the appropriate JCL source to include the JCL described in Creating the Zeke Schedule on page 194. Add the OCCURS clause DAILY, so the job creating the schedule will run each day. See Defining an OCCURS Clause on page 132.
Note:
The following step only has to be performed the first time. 4 ZADD the event with yesterdays Julian date. For example, if the event number is 100 and todays date is December 30, 2007, issue the command:
ZADD EV 100 DA 2007364
The schedule is put in the queue with yesterdays date. When the start time is reached, the schedule load runs and then loads itself in the queue for the next day.
196
Adding Events to the Schedule As They Are Created

To create an event and add it to the schedule queue at the same time
1 Define a job event using the EVENT function of the Zeke batch utility. Refer to your ASG-Zeke for z/OS Reference Guide for details. Insert the SCHEDADD parameter at the end of the event definition as shown in this JCL example.
//SYSIN DD DATA,DLM=$$ EVENT ADD JCL TESTJOB1 PDS PRODLIB2 MEM TESTJCL2 OCC (MONDAY) SCHEDADD $$
Submit the JCL.
Schedules Downloaded to Zeke Agent

When the schedule is created, Zeke checks to see whether any jobs are specified to be downloaded to a Zeke Agent target. Zeke looks at the Netregid specified in the SQR as a jobs target to determine whether the job is to be downloaded. Zeke first sends a message to the specified Zeke Agent to determine if the set of jobs should be downloaded. A unique Zeke-generated schedule number is used to track and synchronize a schedule downloaded to Zeke Agent. If the newly-generated schedule number differs from the number of the schedule currently downloaded and processing on Zeke Agent, then the new schedule is downloaded to Zeke Agent. If the new schedule number matches the number of the current Zeke Agent schedule, then the schedule is not downloaded. As SQRs are being downloaded, the download status is reported to Zeke for each job. If Zeke is unable to download an SQR to its Zeke Agent target, the job is tracked and updated like any other Zeke job until it is ready to dispatch. Then, instead of dispatching the job, Zeke places the job on download hold. Later, when Zeke is able to communicate with the Zeke Agent target, the job will be downloaded and released from hold. See "Downloading Jobs to Zeke Agent" on page 102 and Defining Schedule Download Agents on page 301 for more information on how jobs are downloaded from Zeke to Zeke Agent.
197
How Zeke Determines Dispatching Sequence

Zeke determines the order in which events are dispatched by evaluating the following event attributes or conditions in sequence: 1 2 Dispatch priority from the events SQR. Whether the event is near its Must Start time. Zeke considers, as applicable, an events Not After time, Must End time, average duration, and the value of the Mspintrl generation option. Zeke uses one of the following two formulas to calculate an events near dispatch time and evaluate whether to elevate its dispatch priority: mustend avgdur mspintrl = near_dispatch_time For example, the Must End time for Job ABC is set to 17:00. The events average duration is 30 minutes. The value of the Mspintrl generation option is 1 hour (the default value). Zeke gives Job ABC a higher dispatch priority at 15:30.
Or
notafter mspintrl = near_dispatch_time For example, the Not After time for Job DEF is set to 11:00. The value of the Mspintrl generation option is 1 hour (the default value). Zeke gives Job DEF a higher dispatch priority beginning at 10:00. 3 Whether the event is past its Late time and the Prilate generation option is set to Yes, (giving priority to late events despite their schedule time). Run date. Schedule time from the SQR. Event number. Version number.
4 5 6 7
See Maintaining a Job Event on page 92 for information on schedule times and other event attributes that affect dispatch. See Dispatching Messages and Events on page 288 for details on the generation options that control dispatching.
198
Forecasting and Simulating the Schedule

Zeke provides several ways to predict how the schedule will flow without having to actually run the schedule or dispatch jobs. You can find missing prerequisite conditions, set up a logical schedule flow, and even plan for unusual system downtime or hardware maintenance. You can use any of the following methods to plan or forecast your schedule depending on your specific needs: Occurs Hit Resolution. Allows you to display a calendar showing the days the event will be scheduled. See Defining an OCCURS Clause on page 132. Schedule Forecast. Creates a schedule for a future date allowing you to forecast the schedule and make any necessary changes.
Forecasting the Schedule

This procedure does not actually activate the schedule.
To create a schedule for a future date

1 2 Execute the ZEKE utility program using the SCHEDULE control statement. Enter the DATE parameter followed by the date you want to forecast the schedule for (in MM/DD/YYYY format). Submit the JCL.
Note:
Refer to your ASG-Zeke for z/OS Reference Guide for information on running the actual schedule.
199
Simulating the Schedule

Schedule Simulation allows you to specify the date, time, system, and resources for an event in the simulation JCL, then run the simulation job separate from the Zeke program. The Zeke database is copied to another dataset, then the flow of jobs is simulated against that dataset. The simulation database must be contiguous. STARTDATE, STOPDATE, STARTTIME, and STOPTIME are specified according to a 24-hour clock, but jobs scheduled on a 48-hour clock dispatch at the correct time. Several simulation reports are available, depending on the report keyword you specify. Keyword
Console Exception Schedule Jobflow Note:
Description
Shows the messages produced during simulation. Shows the exceptions that occurred during simulation. Shows the schedule reports if a schedule run was requested. Shows a chart of initiator usage.
To simulate schedules accurately, Zeke uses the same programs that process real schedules. The program used to invoke simulation, SSS4001, is also used to start Zeke. When requesting simulation, you must specify the SIM option in the ZEKE parameter used to specify the Zeke PARMLIB member; otherwise, Zeke attempts to process a real schedule. Caution! Do not run the simulation function against the production database. Run simulation against a simulation-copied database only. No other Zeke system should be running against the same database as simulation. Running the simulation function against the production database will destroy the production database. Refer to your ASG-Zeke for z/OS Reference Guide for a complete list of simulation parameters.
To use the simulation feature

1 Execute the SSS4001 program using the SIMULATE control statement in the SYSIN. Specify the date, time, and conditions for the simulated schedule using the appropriate parameters.
200
Ensure a ZKSMLOG DD statement with the DCB parameters (LRECL=256, BLKSIZE=5124, RECFM=VB) is included in the JCL. This is the simulation log and is used to generate the reports after the simulation run is complete. To simulate your current schedule, set the SCHEDRUN and SCHEDCLR parameters to OFF, otherwise a new schedule is built by default. Execute the SIMULATE COPY function to copy the Zeke database before starting the simulation. For example,
COPY SIMULATE
FROMDD=INCAT TODD=OUTCAT STARTDATE 01/01/2007 STARTTIME 23:00 STOPDATE 01/02/2007 STOPTIME 22:59 DATABASEDD OUTCAT SATISFY ALL INITIATORS 10 TAPEDRIVES 5
REPORT ALL SYSTEM MVSSPA
Note:
To run the simulation against a dataspace, use DATASPACE as the value for both the TODD and DATASPACEDD parameters. Refer to your ASG-Zeke for z/OS Reference Guide for information about simulation from a dataspace. 5 Optionally, you can use the REPORT parameter to run specific simulation reports depending on the subparameters used with REPORT. To print simulation reports from a previous run without rerunning the simulation, ensure the ZKSMLOG dataset was saved from the previous run. Specify only REPORT parameters in the SYSIN control statements and point the ZKSMLOG DD to the saved log. 6 Submit the JCL.
201
Using Schedule View

Schedule View displays the current scheduled events. From this display, the schedule can be monitored and temporarily updated using simple line commands, as an alternative to Zeke operator commands. Operator commands can also be issued from the Schedule View Primary Command line.
Note:
Changes to SQRs are only temporary for that run of the event. The changes are not made to the EMR. You can choose the information you want to display and the placement of the fields. You can also change the way information is displayed and sorted. These customization options are accessed from the Schedule View Display Characteristics menu (option C on the Zeke Primary Menu). Changes made to display characteristics are valid for the current user and are saved in the users ISPF profile. Each user can set up Schedule View according to their preferences.
To update job information from the Schedule View screen

1 From the Zeke Primary Menu, enter 2 on the Option line and press Enter. The Schedule Information Selection Criteria screen is displayed.
ASG-Zeke Command ===> 1 1 2 3 4 Schedule View ZCOM ADD Function ADD by path Event ===> Permanently save criteria ===> N Event Types Selection Field Masks Job: Job Name: Msg: Event Name: Pcom: Application: Work: Group ID: Vcom: User ID: Zcom: System: Scom: Disp Class: REXX: Sched Date: Run Date: Target: Permanent: ---- Event Actv: Y Pend: Y Sched: Y Hold: Y Late: Y / OperOk: Needs - TimeOk: \ WhenOk: Status ---Done: Y ABOK: Y Fail: Y FBOK: Y FSucc: Y N N %Actv: N Schedule Information Selection Criteria
Schedule Display and Modification Facility List Scheduling System Commands Select Event Records "TO ADD" to Schedule Select Event Records by path
202
Type 1 on the Command line. To display all events in the current schedule, press Enter. To display particular events, enter selection criteria in any of the following fields and press Enter. Field
Event Types Selection Field Masks
Description
Enter any character next to the event types you want to display. Enter any information you know about the events you want to select, such as jobname, user ID, run date, etc. You can use * (asterisk) and ? (question mark) to perform wildcard searches. Enter * in any position to search for all positions following it. For example, ABC* in the JOBNAME field selects all events whose jobname begins with ABC. Enter ? in any position to search for that one position. For example, A?C selects all records beginning with A, ending with C, and with any character in the second position. Enter Y or N for each status code to indicate whether you want to display events with that particular status. Status Actv Pend Sched Description Y selects all active events. Y selects all pending events. Y selects all scheduled events. If N, you can select from the secondary statuses: Hold Late Needs OperOK Y selects all events on hold. Y selects all events that are late. Y selects all events waiting on an operator OK. Y selects all events waiting for a certain time. Y selects all events waiting for certain WHEN conditions.
Event Status
Needs TimeOK
Needs WhenOK
Done
Y selects all events with a status of EOJ or AEOJ. If N, you can select from the secondary statuses: ABOK Y selects all successful events that failed once. The screen status is Success Failed Once.
203
Field
Description
Fail Y selects all events that failed. The screen status is Forced. Y selects all events that failed once and then were forced to EOJ. The screen status is Success Forced Failed Once. Y selects all events forced to EOJ. The screen status is Success Forced.
FBOK
FSucc
Only the records that match the selection criteria are displayed in Schedule View.
ASG-Zeke Command ===> Event ===> Schedule View BROWSE Scroll ===> PAGE Selected=0000004
2007.022 15:45 Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When cond ? to list other Line Commands Line Event Sched Job Evnt Event Event Status Cmd No. Date Name Type Name Reason Code ========================================================================== 000001 2007053 MSG ZEKE51TST1 Queued Need Oper OK 000002 2007053 MSG ZEKE51TST2 Scheduled Time OK 000003 2007053 MSG ZEKE51TST3 Scheduled Time OK 000004 2007053 MSG ZEKE51TST4 Scheduled Time OK 000005 2007053 MSG ZEKE51TST5 Scheduled Time OK 000006 2007053 TSKKGUT1 JOB KTEST1 Scheduled Time OK 000007 2007053 TSKKGUT2 JOB KTEST2 Success 000008 2007053 TSKKGUT3 JOB KTEST3 Active 90% 000009 2007053 TSKKGUT4 JOB KTEST4 Success 000010 2007053 TSKKGUT5 JOB KTEST5 Success 000011 2007053 SPTEXD11 JOB ZEKE51CC Scheduled Time OK 000012 2007053 SPTEXD12 JOB ZEKE51CC Scheduled Time OK 000013 2007053 WORK Scheduled Time OK
System=SYSD
Schedule View can be scrolled left and right, as well as up and down to display all of the SQR fields, depending on how you set up your display characteristics. Use the normal ISPF left and right scroll commands to view additional fields.
204
Schedule View displays a variety of information about the scheduled jobs, including the event status and the reason the event is waiting to execute, if applicable. The following table lists the event status codes and their meanings. Event Status
Active
Description
The event is currently running. The percentage of average duration remaining is displayed to the right of the status. The event is currently being dispatched to JES. The event ended abnormally. The event was forced to an abnormal completion. The event is in the dispatch queue, but is not yet running. The event is scheduled but has not been dispatched yet. The event has completed successfully. The event ended abnormally, was refreshed, then finished successfully. The event was forced to a successful completion. The event was forced to a successful completion after failing once.
Dispatching Fail Fail Forced Queued Scheduled Success Success Failed Once
Success Forced Success Forced Failed Once
The following table lists the reason codes and their meanings. Reason Code
Awaiting Retry
Description
The event attempted dispatch but failed with a recoverable error. It will attempt to dispatch again. The event is currently being processed by multi-CPU processing. The event will be available for dispatching after the communication record is processed. Zeke is delaying the event dispatch due to multi-CPU processing requirements. The event is disabled and will not be dispatched. The event is being downloaded to a Zeke agent.
Comm Record Wait
Delayed Dispatch Wait
Disabled Download Hold
205
Reason Code
DSN Hold
Description
There are multiple SQRs in the schedule with the same DSN trigger specified. The Dsntrig generation option is set to NT, so Zeke did not trigger any of the events, and the events are on hold. The event failed, was refreshed, rerun, and finished successfully. The event was forced to completion without actually being dispatched or run. The event is on hold. The event was placed on hold due to an internal error in Zeke processing. The late time has passed. The event is one of a group of events that were manually scheduled by a single ZADD command. It is waiting for the other events in the group to be added and for any weak and variable conditions to be checked. This status occurs only in XCFONLY sysplexes. The events system ID is a pool, therefore the event can be in multiple dispatch queues. Enter the Why command to view the wait statuses for all systems. The event is waiting for an available initiator. The event is waiting for resources. Issue the ZRESOURCE command to display the resources. The event requires an operator OK (ZOK command) prior to dispatch. The required number of tape drives are not available. The event is on hold due to a networking error. A network hold is released when the other scheduler or agent re-registers with Zeke.
Failed Once
Forced
Hold Internal Hold
Late Manual Schedule Wait
Multiple Systems
Need Initiator Need Logical Resources
Need Oper Ok
Need Tape Drives Network Hold
Network Time Out New DQT Entry Not After/Must End
DMS timed out while waiting for a response reply. The event has just been added to the dispatch queue. The Not After time or the Must End time has been reached.
206
Reason Code
Notduring Wait
Description
The event is waiting for the completion of a program or job that is specified in the event's WHEN clause. The Zeke REXX event submitted through OASIS ECF abended and the event is on hold. The event is on operator hold because a ZHOLD command was issued for the event. The event has been dispatched and is just about to execute. The POSID generation option is set to No and the Control field on the EMR is set to Yes. With these settings, Zeke has no way to track a remote job, so the event was placed on hold. For Zeke to track a remote job, POSID must be set to Yes. Otherwise, Control must be set to No so that Zeke will not attempt to track the remote job. The event is ready to be dispatched. A ZREFRESH command was issued for this event; the event is refreshed and on operator hold. The job does not have the authority to run on the platform it was sent to. The event is on hold. Zeke encountered an error reading the JCL while attempting to dispatch the event. The event is on hold. The Zeke dispatching system is on hold. Issue the ZRELEASE command with the system parameter. The event has met the schedule time requirements. Zeke attempted to dispatch a pool event on a VSE system with Dispsel set to N. The event is on hold. There is a new schedule record entry added by the schedule load that is currently processing. The entry will be available for dispatching when the schedule load is complete. The event has been updated by a communications record, but its weak and variable conditions have not been checked yet. All prerequisites have been satisfied.
OASIS REXX Hold
Operator Hold
Pending Posid=No/Rem Hold
Ready Refresh Hold
Security Hold
SJCL Hold
System Hold
Time OK VSE Pool Hold
Wait Sched Load
Weak Resolution Wait
When OK
Enter EDIT on the Command line and press Enter.
207
Perform the steps in the Action column, depending on the desired result.
Note:
The following are all fields that can be updated from the Schedule View screen. The actual fields displayed on your screen depend on how your display is set up through the Schedule View Display Setup screen. Desired Result
Display a list of all valid line commands Change the dispatch priority Change the time the event is scheduled to run
Action
Enter ? in any Line Cmd field and press Enter.
Type over the number in the Dp field and press Enter.
Type over the number in the Start Time field and press Enter. 00:00 indicates the event is dispatched according to the WHEN conditions. Update any of the following fields to alter other start time information: Late Time Early Time Must Time Notaftr Time Avgdur
Change the system or pool the job can run on Change the number of times an event is dispatched
Type over the information in the System field and press Enter.
Type over the number in the Cnt field and enter the amount of time to wait between dispatches in the Freq field and press Enter. If you do not enter a time in the Freq field, the event is dispatched as soon as the previous run has completed. See Defining a Recurring or Permanent Event on page 114. Enter the name of the class in the Dsptch Class field and press Enter. Enter the number (between 0 and 255) of tape drives in the No. Tap field and press Enter. Enter the amount of storage in the Virt Mem field and press Enter.
Change the class or class list for the job Change the number of required tape drives Change the amount of storage required by the event
208
Desired Result
Change the way JCL is submitted and executed
Action
Enter the code to indicate the type of processing to be used in the Target field and press Enter. Code *LOCAL Meaning The JCL for the job is executed on the dispatching system. Remote Limited processing. The JCL is dispatched and submitted on one system and executed on another but does not support condition code processing. Remote Full processing. The JCL is dispatched and submitted on one system and executed on another. Remote processing. Zeke determines whether to use RL or RF processing based on the jobs minimum required support. DMS Netregid of another Zeke system or Zeke Agent where the SQR will be dispatched or downloaded.
*RL
*RF
*R
other
Change the target that an event downloads to
Type over the information in the Target field and press Enter. From the Schedule Information Selection Criteria screen, enter REB in the Line Cmd field and press Enter to rebuild the schedule. The rebuilt schedule is downloaded to Zeke Agent. Note: The Target field may be changed only if the event is not downloaded yet.
Repeat the last command entered
Enter any valid line command for an event and = in the Line Cmd Field for one or more jobs. Each time you press Enter from the Schedule View screen, the same line command is applied to the next job with an equal sign.
209
Optionally, you can make the same change to any subsequent lines by performing the following steps: a b Enter ALT in the Line Cmd field for the job with the change Enter = in the Line Cmd field for any subsequent lines you want to apply the change Press Enter.
Note:
You can continue applying the change as long as a new line command is not entered. 5 If you make any changes to an SQR that you want Zeke to download to Zeke Agent, then you must rebuild the schedule record before the job can be downloaded to Zeke Agent.
210
Schedule View Commands

Primary Commands
The following primary commands can be issued from the Command line on the Schedule View screen. Command
ADD AUTO
Action
Add events to the schedule through the Add wizard. Enable or disable the automatic monitoring function depending on the parameter selected. Parameter Description ON (Default.) Monitors the current schedule and automatically refreshes the screen with any schedule changes based on the specified interval of time. Disables the automatic monitoring function. Pressing any key will also disable this function.
OFF
Note: AUTO will not function properly if you are operating in split-screen mode. BROWSE DOC EDIT INT View the existing scheduled events. Display the Documentation Segments screen. Update an existing scheduled event. Display the 2 values that control automatic monitoring mode. The first number {rate} is the seconds between automatic refreshes. The second number {wait} is how often to check for a request to exit AUTO mode. To change the timing of screen refreshes, enter INT rate wait where rate is a range from wait value to 3660 seconds and wait is a range from 1 to 255. Both parameters are optional and have default values of 5. Additionally rate must be a multiple of wait; however, this is calculated and changed automatically. For example, to refresh the screen every 10 seconds and to check for an exit AUTO mode request every 5 seconds, enter INT 10 5. EMR Display the Event Master Selection Criteria screen.
211
Command
SELECT
Action
Refresh the screen with any schedule changes. When entered with a event number, selects only that event. Note: When the schedule is refreshed, the cursor remains on the same line number it was on. This may not be the same SQR if the schedule changed during that time.
SORT
Re-arrange the sequence of the fields displayed on the screen based on the SORT parameters. This command is only in effect for the current session. For more information and to change the display order permanently, see the Schedule View Sort Setup screen. Note: Enter SORT HELP on the command line to display a complete list of SORT parameters and their abbreviations.
WORK
Display the Work Center Selection Criteria screen.
The following ISPF primary commands are also valid in the Command line on the Schedule View screen: Command
X ALL F STRING NEXT F STRING FIRST F STRING LAST F STRING ALL
Action
Exclude all displayed lines. Find the next occurrence of a specified string of text. Find the first occurrence of a specified string of text. Find the last occurrence of a specified string of text. Find all occurrences of a specified string of text. Note: The FIND ALL command does not display the total number of strings found.
RESET
Re-display a group of lines that were previously suppressed using the EXCLUDE command.
212
Line Commands
Enter one or more of the following line commands in the Line Cmd field to update a scheduled job. You can enter line commands for more than one job and they are stacked in the order they appear on the screen. Then each time you press F3 or Enter, the next command is executed. Command
? =
Action
Display the complete list of line commands online. Repeat the last command entered. Enter any valid line command for an event and the equal sign (=) for one or more jobs. Each time you press the PF3/END key, the same line command is applied to the next job with (=). Add a NEED OPEROK to the requirements of the scheduled job without rebuilding it. Make any change directly to the scheduled job by typing over the existing information. The same change will be applied to any subsequent lines using the equal sign (=) line command. Delete the event from the schedule. Disable the event and remove it from the schedule. To enable the record, use the EN command. Note: The DIS command prevents WHEN conditions for that record from being satisfied.
ADDOK
ALTer
DEL DIS
DSN
Display the Step/DD Level Information screen. Press F3 or Enter to return to Schedule View. Note: This is valid for job events only. Also, Zebb must be active on this system of Zeke.
EMR
Display the EMR screen for the scheduled job. From this display you can make permanent changes to the EMR for that event. Use the REB command to see changes reflected in Schedule View. Enable a disabled event and add it back to the schedule. Release the resources for the event before deleting the SQR.
EN FDEL
213
Command
FDONE FFAIL FREB FREF
Action
Force the SQR to DONE, regardless of the status of the resources. Force to failed status. Release the resources for the SQR before the event is re-added to the schedule. Release the resources and refresh the SQR before the event is re-added to the schedule. Force the SQR to Success status. Place an operator hold on the scheduled event. To release the hold, use the REL command. Retrieve the actual JCL from the JCL source and put it in the SQR so you can view it or update it. The JCL must reside on the same system you are issuing the command from. Note: You must then issue the ZOOM line command for the same event to display the Schedule View Record Expand Function screen. From that screen, you can view, update or delete the JCL.
FSUCC Hold
JCLR
JPREP
Invoke ASG-JCLPREP to scan JCL. See Invoking ASG-JCLPREP on page 237 for more information. Display the List DSN Detail Information screen. Press F3 or Enter to return to Schedule View. Note: This is only valid for job events. Also, Zebb must be active on this system of Zeke.
LDSN
NOTE OK
Display note text for the event, if applicable. Allow the event to be dispatched. If the generation option OPEROK is set to YES, this command is required by the operator to OK the event. Display the Pathfinder screen for predecessors and successors of the event. Enter a number (1 through 9) after the PATH command to display that number of levels. For example, PATH4 displays four levels of predecessor and successor information. Enter an asterisk (*) to display all levels. Display the Pathfinder screen for events that the specified event number or jobname is dependent upon. See PathFinder on page 244 for more information.
PATH
PRED
214
Command
REB
Action
Recreates the SQR with the current status for the event. This produces the same result as deleting a record and re-adding it. Rebuilds the SQR and places the event on hold. Refresh the SQR by resetting the event as if it had not run. Any refreshed event is placed on operator hold automatically and must be released using the REL command before it is dispatched. Release an operator hold on an event. Display the resources for the event, alter resource detail, and release a resource from events or a system. See the Schedule View Resource Screen at the end of this section for more information. Display the Job Restart Management screen. Press F3 or Enter to return to Schedule View. Note: This is valid for job events only. Also, Zebb must be active on this system of Zeke.
REBH REF
REL RESO
RSTRT
RUN
Satisfy all conditions and dispatch the scheduled event. Any NOTDURING WHEN conditions are ignored for this event, until a new one is added re-using the EMR. Scan and validate JCL that is submitted by Zeke. See Validating JCL on page 236 for more information. Display the Pathfinder screen for events dependent upon the specified event number or jobname. See PathFinder on page 244 for more information. View the JES2 job output information for the selected event, where x is one of the following codes: Code L M J Meaning Display all job log information. Display any messages that were generated. Display the actual JCL that was executed.
SCAN
SUCC
SYSx
215
Command
Action
The SYSM, SYSL, and SYSJ commands are valid only if the following conditions are met: You are running an MVS release that supports IBMs spool browse facility, and You are running JES release 4.x or above, and The job is in the JES spool.
TOK WHEN
Satisfy the time requirements for the scheduled event. Display and alter the WHEN conditions for the selected event during this schedule run. See Viewing and Maintaining WHEN Conditions on page 225 for more information. Display the reasons the event is awaiting execution and change the WHEN conditions, if necessary. See Displaying Event Status on page 227 for more information. Satisfy all WHEN conditions for the scheduled event. Display the Work Center Selection Criteria menu. This command is only valid with work centers. Display the Job Functions Menu. Press F3 or Enter to return to Schedule View. Note: Only valid for job events. Also, Zebb must be active on this system of Zeke.
WHY
WOK WORK
ZEBB
ZOom
Display the Schedule View Record Expand Function screen. You can update SQR information from one screen. This screen is similar to the EMR screen except that changes on the Schedule View Record Expand Function screen are only temporary for this run of the schedule. Create your own CLIST or REXX command that can be executed from Schedule View. An example, ZUSER, is included on the install tape.
. . . .
216
Accessing Other Online Information

You can access other areas of the Zeke online facility through Schedule View. The menu options are still valid; however, Schedule View offers an alternate way to access these other areas of the online facility. For further information on each of the online facility areas listed below, see the appropriate section in this chapter.
To access other online facility information

1 From the Zeke Primary Menu, enter 2.1 on the Option line and press Enter. The Schedule View screen is displayed. 2 Perform the steps in the Action column, depending on the desired result. Desired Result
Access EMR
Action
Enter EMR on the Command line and press Enter. The Event Master Selection Criteria screen is displayed. Or, enter EMR in the Line Cmd field for the event and press Enter. The Event Master Definition screen is displayed in Browse mode. See Defining Events on page 77.
Access online documentation
Enter DOC on the Command line and press Enter. The Documentation Selection Criteria screen is displayed. Or, enter NOTE in the Line Cmd field for the event and press Enter to display Note Text information only for a specific event. See Event Documentation on page 181.
Access Work Center information
Enter WORK on the Command line or in any Line Cmd field and press Enter. The Work Center Selection Criteria screen is displayed. See Work Centers on page 161. Enter one of the following line commands in the Line Cmd field. See PathFinder on page 244. Command Action PATH Displays all predecessors and successors for the event. Displays only predecessors. Displays only successors.
Access PathFinder
PRED SUCC
217
Desired Result
Access Zebb
Action
Enter one of the following line commands in the Line Cmd field to access the desired Zebb function. Command Action ZEBB DSN LDSN RSTRT Display the Job Functions Menu. Display the Step/DD Level Information screen. Display the List DSN Detail Information screen. Display the Job Restart Management screen.
Note: You must have Zebb active on the same system as Zeke before issuing any of these commands from Schedule View. Display SQR information on one screen Edit or override JCL for a job event Enter ZOOM in the Line Cmd field for the event and press Enter. See Using the ZOOM Feature on page 230.
Enter ZOOM in the Line Cmd field for the event and press Enter. See Maintaining JCL on page 232.
Press F3 to return to the Schedule View screen.
218
Refreshing the Screen

Schedule View monitors the current schedule and automatically refreshes the screen with any schedule changes at specified intervals. Use the following procedure to enable or disable the automatic monitoring function, and to change the screen refresh rate when this feature is enabled.
To change the automatic refresh options

1 To enable automatic monitoring of the current schedule, enter AUTO ON on the Command line and press Enter. AUTO ON is the default. To disable this function, enter AUTO OFF on the Command line and press Enter. To view the current refresh rate when the automatic monitoring function is enabled, enter INT on the Command line and press Enter. Two numbers are displayed. The first number {rate} is the seconds between automatic refreshes. The second number {wait} is how often Zeke checks for a request to exit AUTO mode. To change the timing of screen refreshes, enter INT rate wait where rate is a range from wait value to 3660 seconds and wait is a range from 1 to 255. Both parameters are optional and have default values of 5. Additionally rate must be a multiple of wait; however, this is calculated and changed automatically. For example, to refresh the screen every 10 seconds and to check for an exit AUTO mode request every 5 seconds, enter INT 10 5. Another example, to refresh the screen every 12 seconds and to check for an exit AUTO mode request every 4 seconds, enter INT 12 4. If you enter INT 13 4, the 13 is automatically changed to 12.
2 3
219
Sorting Schedule View Information

You can change the way scheduled event information is sorted on the Schedule View screen. You can set up a default sort sequence so that each time you log in to Zeke your preferred settings are used. Or, you can temporarily change the sort settings for the current session only; the next time you log in, your default settings are restored.
To change the default sorting sequence

1 From the Zeke Primary Menu, enter C.3 on the Option line and press Enter. The Schedule View Sort Setup screen is displayed.
ASG-Zeke Command ===> Schedule View Sort Setup Row 1 to 16 of 33 Scroll ===> PAGE
Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't use; A/D - direction nnn --Order A/D --------10 A 20 D 30 A Field Description -------------------------------------------------------------Status/Reason Code Schedule Date Event Number ----- Sort uses fields above; fields below are not used ----Application Identification Average Duration CNT (number of times) Dispatching Classes Download Status DP (Dispatch Priority) Early Dispatch Time Event Name Event Type Freq (dispatch interval) Frequency Calc Group Identification
40
The following line serves as a separator on this screen.

----- Sort uses fields above; fields below are not used -----
Fields listed above the line are used for sorting in the user-specified sort order. Unused fields (below the line) are listed alphabetically, for convenience. 2 In the nnn field, do the following: a To remove a field as a sort field, enter the line command 0 next to the field and press Enter. This moves the field down to the not used section of the table. To include a field as a sort field, enter any other value next to the field and press Enter. This to moves the field up to the used section. The value determines the fields placement in the sort order.
220
Order values begin at 10 and increment by 10. This allows you to position multiple fields in between existing fields, if necessary. Each time a field is included in or removed from the sort sequence, or fields are reordered, the Order values are recalculated for the entire list. In the previous example, the scheduled events are designated to be sorted by Status/Reason Code first, Schedule Date second, and Event Number third. The user has specified that Cnt be used as the fourth sort option. 3 Enter A or D in the A/D field to specify an ascending or descending order for the sort and press Enter. Ascending numerical and alphabetical order is the default. In the example, Status/Reason Code, Event Number, and Cnt will sort in ascending order and Schedule Date will sort in descending order. 4 Type END at the Command line to return to the previous screen.
To change the sorting sequence temporarily

1 From the Zeke Primary Menu, enter 2.1 on the Option line and press Enter. The Schedule View screen is displayed. 2 Enter SORT followed by a space and the abbreviation for the fields you want to sort by and press Enter. Separate each field with a comma and no space. Enter SORT HELP on the Command line and press Enter to display a list of SORT parameters and the correct syntax.
221
Selecting Fields to Display

You can select the fields you want to display on the Schedule View screen, and re-order the placement of those fields in Schedule View.
To format the Schedule View screen layout

1 From the Zeke Primary Menu, enter C.2 on the Option line and press Enter. The Schedule View Display Setup screen is displayed.
ASG-Zeke Command ===> Schedule View Display Setup Row 17 of 33 Scroll ===> PAGE
Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't show nnn --Order ----170 180 190 200 210 Field Description *Date Format: YYYYDDD -----------------------------------------------------------------Version Number Frequency Calc Trigger Type Full Job Name Download Status ----- Fields above are displayed; fields below are not ----CNT (number of times) DP (Dispatch Priority) Early Dispatch Time Event Name Event Type Freq (dispatch interval) Late Dispatch Time Must End Time Run Date * Status Time
The following line serves as a separator on this screen.

----- Fields above are displayed; fields below are not -----
Fields listed above the line are displayed in the user-specified sequence. Unused fields (below the line) are listed by alphabetically, for convenience. 2 In the nnn field, do the following: a To remove a field from the display, enter the line command 0 next to the field and press Enter. This moves the field below the line to the not used section of the table. To include a field in the display, enter any other value next to the field and press Enter. This to moves the field above the line to the used section. The value determines the fields placement on the screen. To re-order fields, enter a new value next to the fields and press Enter.
c
222
Order values begin at 10 and increment by 10. This allows you to position multiple fields in between existing fields, if necessary. Each time a field is included in or removed from the display sequence, or fields are reordered, the Order values are recalculated for the entire list. 3 Type END at the Command line to return to the previous screen. In the following example, the Event Number and Schedule Date appear in Fields 1 and 2. The Sched Time appears in Field 3 and the Status/Reason Code appears in Field 4. None of the other fields display.
ASG-Zeke Command ===> Schedule View Display Setup Row 1 of 33 Scroll ===> PAGE
Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't show nnn --Order ----10 20 30 40 50 60 70 80 90 100 110 120 130 140 150 160 Field Description *Date Format: YYYYDDD -----------------------------------------------------------------Event Number Schedule Date * Schedule Time Status/Reason Code Job Name Event Type Event Name DP (Dispatch Priority) Late Dispatch Time System Identification Run Date * Freq (dispatch interval) CNT (number of times) Status Time Early Dispatch Time Must End Time
0 0 0 0 0 0 0 0 0 0 0 0
Note:
On the Schedule View screen, the DOC, JCL, AUTO REPLY, RESOURCE, COND CODE, and WHEN fields always appear as the last six fields. These cannot be changed.
223
Changing the Date Display Format

You can specify the format for selected dates displayed in Schedule View. Entries made on the Date Selection screen affect the fields marked with * (an asterisk) on the Schedule View Display Setup screen.
To change date display format

1 From the Zeke Primary Menu, enter C.4 on the Option line and press Enter. The Date Selection screen is displayed.
ASG-Zeke OPTION ===> Current Format * Date Selection
OPT 1 2 3 4
Format YYYYDDD YYDDD MM/DD/YYYY MM/DD/YY
Description Use Use Use Use 7 digit Julian date (default) 5 digit Julian date 10 character Gregorian date 8 character Gregorian date
In the OPTION field, enter the number of the option marking the format you want displayed on the Schedule View screens. The selected format is marked by * (an asterisk) in the Current Format column. Press Enter.
224
Viewing and Maintaining WHEN Conditions

The following procedure explains how to view and maintain WHEN conditions through Schedule View. See WHEN Condition Keywords on page 145 for a list valid keywords. Changes are only in effect for this run of the schedule. To change the condition permanently, you must use the Event Master Record Function screen.
To view and maintain WHEN conditions through Schedule View

1 From the Schedule View screen, enter WH in the Line Cmd field beside the version you want to view WHEN conditions for and press Enter. The Schedule View - WHEN Conditions screen is displayed.
ASG-Zeke Option ===> Schedule View
Event = 000116 Event Name = MYBR14 Jobname = MDRBR14 When Vr = 00000 CAPS: ON >>>>>>>>>>>>>>>>>>>>>>>>>> When Conditions <<<<<<<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>>>> English When Conditions <<<<<<<<<<<<<<<<<<<<<<<<< (EOE EVEX VER 2 OR EOJ JOBEO VER 3 OR EOE EVFF VER 2) >>>>>>>>>>>>>>>>>>>>>>>>> Tabular When Conditions <<<<<<<<<<<<<<<<<<<<<<<<< EOE 'EVEX' VER 2 EOJ 'JOBEO' VER 3 EOE 'EVFF' VER 2 ******************************* BOTTOM OF DATA ****************************
Alter the existing WHEN conditions
Action
Tab to the blank field after the existing clause under the heading English WHEN Conditions and enter AND or OR and another dependency to the end of the existing one. Do not backspace over any part of the existing clause and do not enter a closing parenthesis. The maximum size for WHEN conditions is 17 lines, or approximately 1360 characters. Schedule View removes the update field once the maximum is reached. You can only add approximately 120 characters when altering a dependency through Schedule View, due to necessary buffer information. To post a dataset dependency using a dataset name longer than 120 characters, use the Zeke operator commands.
225
Desired Result
Satisfy or complete an individual WHEN condition
Action
Tab to the blank space in front of the condition under the Tabular WHEN Conditions heading and enter any character. The following symbols in the space in front of the condition describe the status of the prerequisite. Symbol * + Meaning Zeke satisfied the condition. An operator command was used to manually satisfy the condition. The condition is satisfied because the event is not in the schedule.
Satisfy or complete all WHEN conditions
Enter WOK in the Line Cmd field for the desired event on the Schedule View screen.
Press Enter.
Note:
The following screen is displayed if WH is entered beside a work center job on the Schedule View screen. Follow the same procedures for altering and satisfying WHEN conditions to alter or satisfy SET statements.
Event = 000117 Event Name = CLEANERS Jobname = When Vr = 00000 CAPS: ON >>>>>>>>>>>>>>>>>>>>>>>>> When Conditions <<<<<<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>>>> English Set Conditions <<<<<<<<<<<<<<<<<<<<<<<<< (?XVAR TEST1 EQ 'THIS IS A TEST') >>>>>>>>>>>>>>>>>>>>>>>>> Tabular Set Conditions <<<<<<<<<<<<<<<<<<<<<<<<< ?VAR TEST1 EQ 'THIS IS A TEST' ******************************** BOTTOM OF DATA ***************************
226
Displaying Event Status

This procedure explains how to display and update information about the event status. The reason a version is awaiting execution is displayed under the Event Status heading. If a version has WHEN conditions that have not been satisfied, they are displayed under the Tabular WHEN Conditions heading.
To display and update information about the event status

1 From the Schedule View screen, enter WHY in the Line Cmd field beside the desired version and press Enter. The Schedule ViewWHY screen is displayed.
Event = 000116 Event Name = MYBR14 Jobname = MDRBR14 When Vr = 00000 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Event Status <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Needs Time OK Event is LATE ****** ************************** BOTTOM OF DATA ***************************
For events with a status of Queued and a reason code of Multiple Systems, the WHY command displays the wait reasons for all systems. For example:
Event = 000005 Event Name = EVENT5 Jobname = JKMWTOR5 When Vr = N/A >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Event Status <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< JKMSYSD Need Oper OK JKMSYSB System Hold Event was scheduled for system POOLBD or pool POOLBD Needs Operator OK Needs Resource(s) ****** ************************** BOTTOM OF DATA ***************************
The Event Status lines that include a system name (JKMSYSD and JKMSYSB) indicate that the SQR is waiting in the dispatch queue on those systems. The lines which are not preceded by a system name apply to the base SQR on any system. This WHY screen format is only generated for pooled SQRs in a SysPlex with PLEXCOMM=XCFONLY on all Zekes. If the SysPlex has PLEXCOMM set to XCFONLY, the system name is always shown, even for non-pooled events. See page 205 for explanations of the status codes/reason codes.
227
Satisfy a particular condition under Event Status Satisfy or complete an individual WHEN condition
Action
Tab to the blank space in front of the condition, type any character and press Enter. Tab to the blank space in front of the condition under the Tabular WHEN Conditions heading and enter any character. The following symbols in the space in front of the condition describe the status of the prerequisite: Symbol * + Meaning Zeke satisfied the condition. An operator command was used to manually satisfy the condition. The condition is satisfied because the event is not in the schedule.
Satisfy or complete all WHEN conditions
Tab to the blank space in front of the statement Needs WHEN OK under the Event Status heading, enter any character, and press Enter. If the job is waiting for resources, the Schedule View Resource screen is displayed. See Accessing Resources for an Event on page 229.
228
Accessing Resources for an Event

To view and release the resources assigned to an event
1 From the Schedule View screen, enter RESO in the Line Cmd field beside the desired event and press Enter. The Schedule ViewResource screen is displayed.
ASG-Zeke OPTION ===> Event = 000028 Schedule View
Event Name = ZEKE51TST6
Jobname = TSKKGUT1
Line Commands: Who - Show holder(s)
Rel - Release the resource
Count Mode Sta Event Ver Date Scp Resource Name ============<============================================================> 1 SHR 000028 00000 2007053 GBL INIT1 ******************************** BOTTOM OF DATA ***************************
Note:
If there are no resources defined for the event, the following message is displayed: **** NO RESOURCE DEFINED **** 2 Perform the steps in the Action column, depending on the desired result. Desired Result
Release the resource
Action
Tab to the unlabeled field to the left of the resource and enter REL. Press Enter. Tab to the unlabeled field to the left of the resource and enter WHO. Press Enter. If there are no resources currently being held for the event, the following message is displayed:
**** RESOURCE NOT HELD ****
Display the event currently using the resource
229
Using the ZOOM Feature

The ZOOM feature allows you to view or edit all SQR information for the selected event on one screen. This screen is similar to the Event Master Definition screen, except changes to the Schedule View Record Expand Function screen are only temporary for the current run of the schedule. The ZOOM feature of Schedule View works as is with JCL stored in Zeke and PDS datasets. If you plan to use JCL stored in a Librarian or Panvalet source, modify sample CLIST ZEKELIB (provided on the install tape in ZEKE.CMDPROC) according to the instructions provided in the CLIST. Refer to your ASG-Zeke for z/OS Installation Guide for more information on Librarian and Panvalet.
To view scheduled event information

1 From the Schedule View screen, enter ZOOM in the Line Cmd field beside the desired event and press Enter. The Schedule View Record Expand Function screen is displayed.
ASG-Zeke Command ===> Evt: 000028 Schedule View Record Expand Function BROWSE
Job: TSKKGUT1
Platform: MVS JES2 Job Id:
Sched date: 2007053 Run date: 2007053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKE51TST6 App: System: ZEQA Class: Target: *LOCAL Early: Dprty: 50 Cntrl: Y Sched: 00:00 Times: Tapes: 1 Late: Freq: AvgDur: 00:00 D - Delete Mustend: Freqcalc: S Virt Mem: E - Edit Grp: Usrid:
Notafter: Trig: A
JCL Line Commands: B - Browse JCL--> Zeke JCL
R - Retrieve
Note:
If JCL exists for an event, you can browse, delete, edit, or retrieve it from this screen. The JCL line commands are displayed on the screen, followed by the JCL source. 2 Press F3 to return to the Schedule View screen.
230
To edit scheduled job information

1 From the Schedule View screen, enter EDIT on the Command line and press Enter. The screen is re-displayed in Edit mode. When in Edit mode, you can edit any of the highlighted fields directly from this screen. Scroll left or right to access additional fields. Typically, it is more convenient to edit fields from the Schedule View Record Expand Function screen.
Or
From the Schedule View screen, enter ZOOM in the Line Cmd field beside the desired event and press Enter. The Schedule View Record Expand Function screen is displayed.
Job: TSKKGUT1
Sched date: 2007053 Run date: 2007053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKE51TST6 App: System: ZEQA Class: Target: *LOCAL Early: Dprty: 50 Cntrl: Y Sched: 00:00 Times: Tapes: 1 Late: Mustend: Freqcalc: S Virt Mem: E - Edit Grp: Usrid:
Notafter: Trig: A
Freq: AvgDur: 00:00 D - Delete
R - Retrieve
2 3
Update the fields, as necessary, and press Enter. To update or view the events JCL, tab to the blank field left of JCL--> and enter one of the available JCL line commands. Press Enter. Caution! Changes made to JCL via this option are applied to the EMR for this event.
Press F3 to return to the Schedule View screen.
231
Maintaining JCL
For job events, Schedule View allows access to JCL for one-time overrides. You can retrieve the actual JCL from the JCL source and insert it in the SQR to view or update. This allows authorized users access to a copy of the executable JCL to update parameters and correct abends. The updated copy is then attached to the events schedule entry for subsequent runs. If you override the JCL for a recurring event, all subsequent runs for that schedule day will use the override unless the override copy is manually deleted. The JCL override copy is purged with the event at the next schedule load, if the event completes.
To maintain JCL for an event

1 From the Schedule View screen, enter JCLR in the Line Cmd field next to the job and press Enter. The message following message is displayed:
Request queued
Enter ZOOM in the Line Cmd field and press Enter. The Schedule View Record Expand Function screen is displayed.
Job: TSKKGUT1
Notafter: Trig: A
JCL Line Commands: B - Browse
R - Retrieve
JCL--> Override present in SQR JCL--> Zeke JCL
Delete after next use (Y/N) N
Tab to first JCL field. In this example, the field indicates the JCL has not been retrieved yet:
Override present in SQR
Enter the JCL line command E to edit the JCL and press Enter. Changes to this JCL field are only in effect for this run of the schedule.
232
In the Delete after next use field, specify whether to delete the updated JCL after the next use. If set to Y, the update JCL is deleted after the next run of the job. If set to N, the JCL is kept and re-used for every run until it is manually deleted (using the D line command in Schedule View) or this option is changed to Y. The default setting for this field is controlled by the DefDelOJ generation option. The additional JCL field contains the name of the specified JCL source for the job. Update this field, if necessary. Changes to that field are permanent and affect the EMR for this event. The Zeke JCL Override screen is displayed.
ASG-Zeke JCL Override EDIT Event 00029 COMMAND ===> SCROLL ===> PAGE ****** *************************** Top of Data **************************** ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 //EANTST29 JOB (26010,200),'JOHN DOE X9999',CLASS=A,MSGCLASS=A, 000002 // USER=PDDOE,PASSWORD=WHILEOUT 000003 //* 000004 //ZEKE EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5' 000005 //STEPLIB DD DISP=SHR,DSN=ZEKE.PDDOE.LINKLIB 000006 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000007 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000008 //SYSPRINT DD SYSOUT=* 000009 //SYSABEND DD SYSOUT=* 000010 //SYSUDUMP DD SYSOUT=* 000011 //SYSIN DD * 000012 SET WAIT 1 000013 //* ****** ************************** Bottom of Data **************************
Make any necessary changes and press F3 to save the changes and return to the Schedule View Record Expand Function screen.
Note:
A few editing commands have the same name in ISPF as in Zeke, such as CANCEL, COPY, and EDIT. When these commands are issued from Zeke, they are processed as Zeke commands rather than ISPF commands. To use the ISPF command when there is a Zeke command by the same name, you must issue it as part of the ISPF EDIT command BUILTIN (e.g., BUILTIN CANCEL). Otherwise, it is assumed that you are issuing a Zeke command and not an ISPF command. See your ISPF documentation for details about the BUILTIN command. 8 9 Press F3 again to return to the Schedule View screen. Optionally, you can check your JCL for syntax errors without affecting the actual SQR. See Validating JCL on page 236.
233
Zeke PDS JCL Override

JCL override for PDS JCL works by attaching the JCL from the PDS as a ZEKEJCL attachment to the schedule queue record (SQR). This JCL can then be modified for the purpose of re-running the job. As an option, you may choose for Zeke to override the JCL after the next job run. Zekes PDS override option provides an alternative to the standard JCL override function in Schedule View. This override option copies the JCL that is pointed to by the DDNAME/member name combination in the SQR to a PDS that is pointed to by the OVERRIDE DD in the Zeke started task. The SQR is updated to point to that DDNAME OVERRIDE. You can then edit the JCL through the ZOOM screen in Schedule View. The OVERPDS command allocates the datasets pointed to by the DDNAME in the Zeke started task based on the DDNAME found in the current SQR. For information on how to install and configure the PDS JCL override option, refer to your ASG-Zeke for z/OS Installation Guide.
To perform a Zeke PDS override

1 From the Schedule View screen, enter ZOOM in the Line Cmd field beside the desired job and press Enter.
ASG-Zeke Command ===> Event ===> Schedule View BROWSE Scroll ===> PAGE Selected=0000034 2007.084 12:51
System=SYSD
Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When cond ? to list other Line Commands Line Event Sched Job Evnt Event Event Status Cmd No. Date Name Type Name Reason Code ========================================================================== 000001 2007067 DOWN0001 JOB DOWNLOAD0001 Queued Download Hold zoom 000021 2007069 CGC806 JOB ABEND806 Fail S806 000025 2007065 CGCXDCA JOB JOBTEMPLATE Queued Need Oper OK 000076 2007057 CGCJCL JOB ZEKEJCLTEST Success 000079 2007065 CGCJCL2 JOB ZEKEJCLTEST Fail Forced 001014 2007068 KATHYG01 JOB KATHYG01 Fail JCL Error 001098 2007067 TRACK04 JOB TRACK0000004 Active 6900% 001694 2007067 SCOM EOJTRACK75 Success ********************************** BOTTOM OF DATA *************************
234
The Schedule View Record Expand Function screen is displayed.

ASG-Zeke Schedule View Record Expand Function BROWSE Command ===> OVERPDS Platform: MVS Evt: 000021 Job: CGC806 JES2 Job Id: JOB09781 Sched date: 2007069 Run date: 2007069 STATUS TIME: 01:06 STATUS/REASON: Fail S806 Type: JOB EventName: ABEND806 System: SYSD Class: A Early: Dprty: 50 Cntrl: Y Sched: 00:00 Times: Tapes: 1 Late: Version: 00000
App: A2345678 Target: *LOCAL Mustend:
Grp: G23 Usrid: U2345678
Notafter: Trig: A
Freqcalc: S Virt Mem: E - Edit
R - Retrieve
JCL--> PDS: ZEKEJCL Member: ABEND806
On the Command line, enter OVERPDS.

ASG-Zeke Command ===> Evt: 000021 Schedule View Record Expand Func Override successful Platform: MVS JES2 Job Id: JOB09781 Version: 00000
Job: CGC806
Sched date: 20072007069 Run date: 2007069 STATUS TIME: 01:06 STATUS/REASON: Fail S806 Type: JOB EventName: ABEND806 System: SYSD Class: A Early: Dprty: 50 Cntrl: Y Sched: 00:00 Times: Tapes: 1 Late: App: A2345678 Target: *LOCAL Mustend:
Notafter: Trig: A
R - Retrieve
JCL--> PDS: ZEKEJCL Member: ABEND806
After the datasets are allocated, OVERPDS copies the member (indicated in the SQR) to a dataset pointed to by the OVERRIDE DD in the Zeke started task. A ZALTER command is issued against the SQR to change the SQR to point to the OVERRIDE DD. 3 Exit and then re-enter the zoom screen to see the change in the SQR.
235
You can the enter E to the left of the JCL>PDS: OVERRIDE line to edit the override JCL, if needed.
ASG-Zeke Command ===> Evt: 000021 Schedule View Record Expand Function BROWSE Platform: MVS JES2 Job Id: JOB09781 Version: 00000
Job: CGC806
Sched date: 2007069 Run date: 2007069 STATUS TIME: 01:06 STATUS/REASON: Fail S806 Type: JOB EventName: ABEND806 System: SYSD Class: A Early: Dprty: 50 Cntrl: Y Sched: 00:00 Times: Tapes: 1 Late:
App: A2345678 Target: *LOCAL Mustend:
Notafter: Trig: A
R - Retrieve
e JCL--> PDS: OVERRIDE Member: ABEND806
Validating JCL
After you create or edit JCL you can check it for syntactical errors using one of the following:

ASG-JCLPREPusing the JPREP line command ASG-JOB/SCANusing the JSCAN line command ZSCAN operator command
Note:
Other JCL scanning products can be invoked from the Schedule View display by using the Zeke line command JSCAN. You must write a TSO CLIST or REXX exec to perform the validation before using the JSCAN line command. Refer to the section on using other JCL scanning products in your ASG-Zeke for z/OS Installation Guide. If your product provides an ISPF EDIT macro to scan JCL, then you may use it while editing event JCL from the ZOOM display.
236
Invoking ASG-JCLPREP
ASG-JCLPREP (herein called JCLPREP) validates the JCL syntax for a job and issues a report about its accuracy. From Schedule View, you can invoke JCLPREP in either of two ways:

Via the ZOOM feature By entering the JPREP line command
JCLPREP can only be used for jobs with existing JCL.

Note:
The JPREP line command can be used to populate OASIS event-related items (XQxxxxx). JPREP invokes the ZJCLPREP REXX exec (which requires site-specific modifications). After you edit JCL from the ZOOM display, you can validate the JCL while still in EDIT mode using the FPREP EDIT macro. Both methods for accessing JCLPREP are described in this section. Refer to your ASG-Zeke for z/OS Installation Guide for information on configuring JCLPREP for JCL management, and for important setup procedures that must be performed before you can invoke JCLPREP from Schedule View.
To invoke JCLPREP using Schedule View ZOOM

1 From the Schedule View screen, type ZOOM in the Line Cmd field beside the desired job and press Enter. The Schedule View Record Expand Function screen is displayed.
Job: TSKKGUT1
Notafter: Trig: A
R - Retrieve
237
To access the JCL, enter E in front of the JCL field and press Enter. The JCL screen is displayed.
ASG/Zeke JCL EDIT Event 00054 Command ===> Scroll ===> PAGE ****** **************************** Top of Data **************************** ==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF). ==MSG> Data has valid standard numbers. ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000100 //EANTST30 JOB (10038),'J SMITH', 000200 // MSGCLASS=Y,CLASS=A, 000300 // REGION=4M 000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5' 000610 //STEPLIB DD DISP=SHR,DSN=OASIS.R220A.LINKLIB.OS3901 000620 //* DD DISP=SHR,DSN=OASIS.R230A.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.R230AM1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.R300A.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.R300A.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *
Enter FPREP on the command line and press Enter to invoke the JCLPREP EDIT macro. JCLPREP is invoked to check the JCL syntax. After JCLPREP completes the check, the JCLPREP output is displayed.
When you finish reviewing the JCLPREP output, press F3 to exit the output screen.
To invoke JCLPREP using the JPREP line command

1 From the Schedule View screen, enter JPREP in the Line Cmd field beside the desired event and press Enter. JCLPREP is invoked to check the JCL syntax. After JCLPREP completes the check, the JCLPREP output is displayed. 2 When you finish reviewing the JCLPREP output, press F3 to exit the output screen.
238
Invoking JOB/SCAN
From Schedule View, you can invoke the JCL management tool, ASG-JOB/SCAN, in either of two ways: via the ZOOM feature, or by entering the JSCAN line command. Both methods for accessing ASG-JOB/SCAN (herein called JOB/SCAN) are described in the following section. JOB/SCAN can only be used for jobs that have existing JCL. Refer to your ASG-Zeke for z/OS Installation Guide for information on configuring JOB/SCAN for JCL management, and for important setup procedures that must be performed before you can invoke JOB/SCAN from Schedule View. Also refer to your JOB/SCAN documentation series for more information.
To invoke JOB/SCAN using the ZOOM feature of Schedule View

1 From the Schedule View screen, type ZOOM in the Line Cmd field next to the job and press Enter. The Schedule View Record Expand Function screen is displayed.
Job: TSKKGUT1
Notafter: Trig: A
R - Retrieve
To access the JCL, enter E in front of the JCL field and press Enter.
239
The JCL screen is displayed.

ASG/Zeke JCL EDIT Event 00054 Command ===> Scroll ===> PAGE ****** **************************** Top of Data **************************** ==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF). ==MSG> Data has valid standard numbers. ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000100 //EANTST30 JOB (10038),'J SMITH', 000200 // MSGCLASS=Y,CLASS=A, 000300 // REGION=4M 000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5' 000610 //STEPLIB DD DISP=SHR,DSN=OASIS.R220A.LINKLIB.OS3901 000620 //* DD DISP=SHR,DSN=OASIS.R230A.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.R230AM1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.R300A.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.R300A.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *
Enter JEM on the command line and press Enter to invoke the JOB/SCAN EDIT macro. JOB/SCAN is invoked to check the JCL syntax. After JOB/SCAN completes the check, the JOB/SCAN output is displayed.
When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.
To invoke JOB/SCAN using the JSCAN line command

1 From the Schedule View screen, enter JSCAN in the Line Cmd field next to the job and press Enter. JOB/SCAN is invoked to check the JCL syntax. After JOB/SCAN completes the check, the JOB/SCAN output is displayed. 2 When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.
Note:
See the JOB/SCAN documentation series for more instructions.
240
Using ZSCAN
You can check your JCL for syntax errors through the OS facility. This function is the same as issuing the Zeke operator command ZSCAN and follows the same guidelines as the JCL feature TYPRUN=SCAN. Your job card must have a MSGCLASS= value that will hold the output on the spool. Otherwise, you will not be able to view the OS messages.
Note:
To validate JCL on another system, you must specify the system name. Use the ZSCAN operator command to do so. Refer to your ASG-Zeke for z/OS Reference Guide for details).
To check your JCL for syntax errors using ZSCAN

1 2 From the Schedule View screen, enter SCAN in the Line Cmd field and press Enter. If you have a package designed to browse the JES spool, such as SDSF or BETA92, use it to view the messages. Otherwise, enter SYSM in the Line Cmd field and press Enter. The Schedule View Record Expand Function screen is displayed. All SYSLOG and JESLOG messages can be displayed to aid in problem resolution and speed the restart process. Use the SYSL and SYSJ line commands, respectively.
Note:
The SYSM, SYSL, and SYSJ commands are valid only if the following conditions are met: you are running an OS release that supports IBMs spool browse facility; you are running JES release 4.x or above; and the job is in the JES spool.
241
Creating Your Own Line Commands

Schedule View allows you to create your own CLIST or REXX commands that can be executed from Schedule View. See the ZUSER example included on the install tape.
To create a line command

1 From the Schedule View screen, enter the 3-character to 5-character name of your CLIST or REXX command in the Line Cmd field beside the desired job and press Enter. The user-defined command is executed. This sample shows the parameters passed in the ZUSER example.
EVENT NUMBER = 00021 VERSION = 00000 SCHEDULE DATE = 2007053 JOB NAME = TSKKGUT1 EVENT TYPE = JOB EVENT NAME = KTEST1 STATUS/REASON CODE = SCHEDULED TIME OK DISPATCH PRIORITY = 50 START TIME = 00:00 LATE DISPATCH TIME = SSYSTEM = ZEQA RUN DATE = 2007053 FREQUENCY = NUMBER OF TIMES = 1 STATUS TIME = 00:00 EARLY DISPATCH TIME = MUST END TIME = NOT AFTER TIME = USER ID = APPLICATION ID = KTEST GROUP IDENTIFICATION = DISPATCHING CLASSES = A NUMBER OF TAPES REQUIRED = VIRTUAL MEMORY REQUIRED = AVERAGE DURATION = 00:00 JES NUMBER = TARGET DESIGNATION = *LOCAL FREQUENCY CALC = S TRIGGER TYPE = A SUBSYSTEM = ZEQA
242
ZCOM Option
From the console or via the ZCOM option, you can enter Zeke operator commands. Refer to your ASG-Zeke for z/OS Reference Guide for a complete list of commands, parameters, and values that are valid for operator commands. The Schedule Control Function screen lists some of the most common operator commands you are allowed to enter, depending on your security and class definition. These commands are used for altering and displaying scheduled event information. You can also alter the values of Zeke variables through the ZCOM option.
To issue operator commands

1 From the Zeke Primary Menu, enter option 2.2 and press Enter. The Schedule Control Functions screen is displayed.
ASG-Zeke Option ===> Schedule Control Function BROWSE
Please enter a valid Zeke operator command Opt Description 1 2 3 4 5 6 7 8 9 10 11 12 ZD ZD JOB ZD MSG ZD SCOM ZD ZCOM ZD WAIT ZD DONE ZD LATE ZD HOLD ZD AV ZID ZMAP Opt Description 13 14 15 16 17 18 19 20 21 22 23 24
Cmd: Add - ZADD Function
Enter an option number or enter a command on the Option line and press Enter. The Zeke Command Output Display screen is displayed.
Note:
You can also Tab over to the description section for options 13 through 24 and set up your own command options. For example, to display all of the events for the current schedule, you can enter 1 on the Option line and press Enter, or enter ZD on the Option line and press Enter.
243
The corresponding Zeke Command Output Display screen is displayed detailing the selected criteria.
ASG-Zeke Command ===> Zeke Command Output Display BROWSE Row 1 to 17 of 30 Scroll ==> PAGE
Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. -------------------------------------------------------------------------Z0922I DATE RDATE VERS TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS 000006 2007053 2007053 0000 JOB TSKKGUT1 50 00:00 1 T 000008 2007053 2007053 0000 JOB TSKKGUT3 50 00:00 1 T 000011 2007053 2007053 0000 JOB SPTEXD11 50 00:00 1 T 000018 2007053 2007053 0000 JOB SPTEXD18 50 00:00 1 T 000019 2007053 2007053 0000 JOB SPTEXD19 50 00:00 1 T 000020 2007053 2007053 0000 JOB SPTEXD20 50 00:00 1 T 000021 2007053 2007053 0000 JOB SPTEXD21 50 00:00 1 T 000022 2007053 2007053 0000 JOB SPTEXD22 50 00:00 1 T 000023 2007053 2007053 0000 JOB SPTEXD23 50 00:00 1 T 000024 2007053 2007053 0000 JOB SPTEXD24 50 00:00 1 T 000025 2007053 2007053 0000 JOB SPTEXD25 50 00:00 1 T 000026 2007053 2007053 0000 JOB SPTEXD26 50 00:00 1 T 000028 2007053 2007053 0000 JOB TSKKGUT1 50 00:00 1 T 000029 2007053 2007053 0000 JOB SPTEXD29 50 00:00 1 T 000030 2007053 2007053 0000 JOB SPTEXD30 50 00:00 1 T Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00028 SYSTEM ZEQA
Press F3 to return to the previous screen.
PathFinder
PathFinder shows all predecessor and successor relationships for any given event. This allows you to view what needs to occur before a job can run and what will happen after the job has run. This display can be accessed through Schedule View or by issuing a Zeke operator command. The following procedure explains how to access PathFinder using several operator commands. Refer to your ASG-Zeke for z/OS Reference Guide if you are unfamiliar with Zeke operator commands. See Using Schedule View on page 202 for information on accessing this feature through Schedule View.
Note:
Any commands listed in this procedure can also be entered directly from the console.
244
To access PathFinder using Zeke operator commands

1 2 From the Zeke Primary Menu, enter 2.2 on the Option line and press Enter. Perform the steps in the Action column, depending on the desired result. Desired Result
Display predecessors for an event at all levels
Action
Enter:
ZD PRE LEV * JOB jobname
or
ZD PRE LEV * EV event number
on the Option line and press Enter. The specified job is the zero (0) level job and is displayed at the bottom of the flow. You may have to scroll down to see the Level 0 job. Then, scroll up to see the order of the predecessors. They will be displayed from the bottom to the top, beginning with the first job (Level 1). Displayed above each Level 1 job are all the jobs that trigger it (Level 2 through the end). If a condition has already been displayed, the following message appears directly underneath the job that triggered it:
CONDITION ALREADY DISPLAYED BELOW
Display successors for an event at all levels
Enter:
ZD SU LEV * JOB jobname
or
ZD SU LEV * EV event number
on the Option line and press Enter.
The specified job is the zero (0) level job and is displayed at the top of the screen. All jobs that are triggered by this job are displayed below the Level 0 job beginning with the first job (Level 1). Displayed under each Level 1 job are all the jobs that it triggers (Level 2 through the end). If a condition has already been displayed, the following message appears directly underneath the job that triggered it: CONDITION ALREADY DISPLAYED ABOVE
245
Desired Result
Action
Display all predecessors Enter: and successors for an event or
ZD PRE SU LEV * JOB jobname
ZD PRE SU LEV * EV event number
on the Option line and press Enter. Scroll down until you find the first job (Level 0) and page up for the predecessors and down for the successors. Display non-Zeke jobs in path The generation option Trigjob must be set to A so that any job can trigger another event's WHEN conditions, regardless of how the job is dispatched. The following message is displayed whenever a non-Zeke job is found:
** NOT IN THE SCHEDULE OR NOT A ZEKE EVENT **
Note: The predecessors cannot be displayed because those events do not have WHEN conditions. Display different levels in the hierarchy Enter LEV followed by a space and the number of levels you want to display with one of the commands listed above and press Enter. For example,
ZD SU EV 100 LEV 3
Display up to 3 levels of jobs that are dependent upon event 100. Note: Enter an (*) asterisk to display all levels.
If Zeke detects a loop in any of the WHEN conditions, it will continue to list all predecessors and successors and display the following message:
*** INFINITE WHEN-CONDITION LOOP DETECTED!! ***
246
Display Successor Example

The following shows an example of all jobs dependent on MYTEST:
MYTEST (Level 0)
ALHJOB2 (Level 1)
DONETST (Level 2)
ZTSRPT9T (Level 2)
ZTSERAXT (Level 3)
ZTSBKUP (Level 4)
ZTSDONE (Level 4)
After the following command is entered:

ZD SU LEV * JOB MYTEST
a screen similar to the following is displayed.

Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. ----------------------------------------------------------------------------ZD SU LEV * JOB MYTEST Z09ADI SUCCESSORS FOR THE REQUESTED EVENT: LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR 0 MYTEST JOB 000008 2007053 0000 T 00:00 ---------------------------------------------------------------------------->>1 ALHJOB2 JOB 000002 2007045 0000 EOJ MYTEST T 00:00 2 DONETST JOB 000053 2007045 0000 WEOG ALHJOB2 00:00 2 ZTSRPT9T JOB 000067 2007045 0000 WEOG ALHJOB2 00:23 3 ZTSERAXT JOB 000003 2007045 0000 WEOJ ZTSRPT9T 00:03 4 ZTSBKUP JOB 000708 2007045 0000 WEOJ ZTSERAXT 00:20 4 ZTSDONE JOB 000930 2007045 0000 WEOJ ZTSERAXT 00:10 ******************************* Bottom of data *******************************
247
Display Predecessor Example

The following diagram shows an example of all jobs that MYTEST is dependent on:
ZTSVLDTT (Level 5)
ZSJOBAT (Level 5)
ZTSJOBBT (Level 4)
ZTSVLDTT (Level 4)
ZTSVLDTT (Level 3)
ZTSJOBDT (Level 3)
ZTSJOBKT (Level 2)
EANTST04 (Level 1)
MYTEST (Level 0)
After the following command is entered:

ZD PRE LEV * EVENT 54

AZ09ACI PREDECESSORS FOR THE LVL JOB/EVT NAME TYPE EVENT 3*ZTSVLDTT JOB 001005 5*ZTSVLDT3 JOB 001009 5*ZSJOBAT JOB 001010 4 ZTSJOBBT JOB 001007 REQUESTED EVENT: DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR 2007038 0000 * 00:00 2007038 0000 * 00:00 2007038 0000 * 00:00 2007038 0000 EOJ ZTSVLDT3 T 00:00 EOJ ZSJOBAT 4*ZTSVLDT2 JOB 001008 2007038 0000 * 00:00 3 ZTSJOBDT JOB 001006 2007038 0000 EOJ ZTSJOBBT T 00:00 EOJ ZTSVLDT2 2 ZTSJOBKT JOB 001004 2007038 0000 EOJ ZTSVLDTT T 00:00 EOJ ZTSJOBDT >>1 EANTST04 JOB 001003 2007038 0000 EOJ ZTSJOBKT T SCHD 00:00 -----------------------------------------------------------------------------0 MYTEST JOB 001002 2007038 0000 EOJ EANTST04 T 00:00 ******************************* Bottom of data ********************************
248
Display Predecessor and Successor Example

The following is an example of all events that ZEKE51TST3 is dependent upon and all events dependent on ZEKE51TST3. After the following command is entered:
ZD PRE SU LEV * EV 3

Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. ----------------------------------------------------------------------------ZD PRE SU LEV * EV 3 Z09AEI PREDECESSORS AND SUCCESSORS FOR THE REQUESTED EVENT: LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR >>1*ZEKE51TST1 MSG 000001 2007053 0000 * 2 KATHYG *** NOT IN THE SCHEDULE OR NOT A ZEKE JOB *** 2*ZEKE51TST1 MSG 000001 2007053 0000 * 2*ZEKE51TST1 MSG 000034 2007053 0000 * >>1 ZEKE51TST2 MSG 000002 2007053 0000 EOJ KATHYG T EOE ZEKE51TST1 >>1*ZEKE51TST1 MSG 000034 2007053 0000 * ----------------------------------------------------------------------------0 ZEKE51TST3 MSG 000003 2007053 0000 EOE ZEKE51TST2 T EOE ZEKE51TST1 ---------------------------------------------------------------------------->>1 ZEKE51TST4 MSG 000004 2007053 0000 EOE ZEKE51TST3 T 2 ZEKE51TST5 MSG 000005 2007053 0000 EOE ZEKE51TST4 T 3 SPTEXD11 JOB 000011 2007053 0000 EOE ZEKE51TST5 T 00:00 2 SPTEXD29 JOB 000029 2007053 0000 EOE ZEKE51TST5 T 00:00
predecessors
successors
249
Manually Adding Events to the Schedule

Normally, the SCHEDULE function (a batch utility program) automatically schedules all of the required events. However, sometimes you need to manually add an individual event or a group of events to the schedule. Zeke offers several methods for creating an SQR manually:

ZADD operator command ADD online function ADD by path online function
Note:
If a job event manually added to the schedule has Zeke Agent as its target, then Zeke downloads (if the agent is configured in Zeke as a download agent) or dispatches the new job event immediately after the SQR is created.
Using the ZADD Operator Command

This procedure requires that you know the event number, the event name, or the jobname of the event you want to add to the schedule.
To manually add an event to the schedule using the ZADD command

1 From the Zeke Primary Menu, enter 2.2 and press Enter. The Schedule Control Function screen is displayed.
ASG-Zeke Option ===> Schedule Control Function BROWSE
Please enter a valid Zeke operator command Opt Description 1 2 3 4 5 6 7 8 9 10 11 12 ZD ZD JOB ZD MSG ZD SCOM ZD ZCOM ZD WAIT ZD DONE ZD LATE ZD HOLD ZD AV ZID ZMAP Opt Description 13 14 15 16 17 18 19 20 21 22 23 24
Cmd: Add - ZADD Function
250
To add one job by event number To add several jobs using a range of event numbers
Action
Enter ZADD EV event-num
Enter ZADD EV (event-num, event-num, ...)
To add one version of an Enter ZADD EV event-num VER version-num event by event number To add a job event by jobname To add any job by event name Note: Enter ZADD JOB name
Enter ZADD ENAME name
Refer to your ASG-Zeke for z/OS Reference Guide for a complete list of commands, parameters, and values that are valid with the ZADD command. For example, to add event 00018 to the schedule, enter ZADD EV 18 on the Command line and press Enter. A corresponding message screen is displayed.
Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. -------------------------------------------------------------------------ZADD EV 18 Z0952E EVENT 000018 SCHEDULE RECORD ALREADY EXISTS WITH SAME DATE/VERSN Z0929I ZEKE COMMAND PROCESSED Z0922I DATE RDATE VERS TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS 000018 2007053 2007053 0000 JOB SPTEXD18 50 00:00 1 T 000018 2007055 2007055 0000 JOB SPTEXD18 50 00:00 1 T Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00002 SYSTEM ZEQA ****************************** Bottom of data *****************************
251
Using the ADD Function

This procedure describes how to add any type of event to the schedule using the online facility. Behind the scenes, Zeke uses your selections on this screen to build a ZADD operator command.
To manually add an event to the schedule using the ADD function

1 From the Zeke Primary Menu, enter option 2.3 and press Enter. The ADD Event Record Selection Criteria screen is displayed.
ASG-Zeke Command ===> Options: Auto: Hold: Rerun: Run: ADD Event Record Selection Criteria 2007.055 15:26
N N N N
(Y/N) (Y/N) (Y/N) (Y/N) (YYYYDDD)
Enable: N Rebuild: N Refresh: N
(Y/N) (Y/N) (Y/N)
Schedule Date: 2007055 Event ===>
Run Date: 2007055
(YYYYDDD)
Enter a selection mask in any field(s) to be compared for selection. * - is a prefix/suffix indicator. ? - is a wild/place holder character. Event Types Job: Msg: Pcom: Work: Vcom: Zcom: Scom: REXX: Selection Field Masks Job Name: Event Name: Application: Group ID: User ID: Drl ID: System: Permanent:
Enter Y in any of the following fields if you want to include that parameter with the ZADD command issued from this screen. The default for each field is N. Field
Auto
Description
Add one to the value for number of dispatch times, if the scheduled job is active. The REFRESH and ENABLE parameters are assumed. This parameter is not valid for work center events. Change the scheduled job status from DISABLE to ENABLE. Place an operator hold on the event after it is added, refreshed, or enabled. The event must then be released from hold before it can be dispatched. This parameter is not valid for work centers.
Enable Hold
252
Field
Rebuild
Description
Recreate the SQR. (If an SQR does not exist, you do not need this parameter.) This produces the same result as deleting a record and re-adding it. Resets all WHEN conditions Reflects any EMR changes Places the event into ACTIVE status Resets any ZALTER changes previously made
Rerun
Add the RERUN designation to the schedule job record. The RERUN designation appears in the ZDISPLAY output and is passed to the user exit ZEKE14D. If the generation option TRIGRRN=NO, the job will not trigger the WHEN conditions of other jobs. Use the NORERUN parameter of the ZALTER command to remove the RERUN designation. Refresh an SQR if the status is EOJ, AEOJ, or Pending. (The ZADD REFRESH does not place an operator hold on the job like the ZREFRESH command.) Add the job to the schedule ready to run. This is the same as a ZALTER RUN operator command.
Refresh
Run
3 4
If one job is to be added, the event number may be entered in the Event field. Enter information in any of the fields under either or both of the following headings to restrict the number of events selected. The more information you enter here, the fewer events you need to look at to find the event you want to work with. If you do not enter information in any fields, all events defined in your Zeke database are displayed. Field
Event Types
Description
Enter any character except a space to indicate the types of jobs to be selected. Enter any information you know about the events you want to select, such as jobname, user ID, run date, etc. You can use * (asterisk) and ? (question mark) to perform wildcard searches. Enter * in any position to search for all positions following it. For example, ABC* in the Job Name field selects all events whose jobname begins with ABC. Enter ? in any position to search for that one position. For example, A?C selects all records beginning with A, ending with C, and with any character in the second position.
Selection Field Masks
253
Press Enter. The Schedule View Event Add List screen is displayed.
Schedule View Event Add List Scroll ===> PAGE Selected=0000046
Line Commands: S - Select to add the event to the Schedule Versn Event Event Sched Evnt System Applic User Job No. Number Name Info Type ID ID ID Name ========================================================================== 000001 ZEKE51TST1 2007053 MSG ZEQA 000002 ZEKE51TST2 2007053 MSG ZEQA 000003 ZEKE51TST3 2007053 MSG ZEQA 000004 ZEKE51TST4 2007053 MSG ZEQA 000005 ZEKE51TST5 2007053 MSG ZEQA 000006 KTEST1 2007053 JOB ZEQA KTEST TSKKGUT1 000007 KTEST2 2007053 JOB ZEQA KTEST TSKKGUT2 000008 KTEST3 2007053 JOB ZEQA KTEST TSKKGUT3 000009 KTEST4 2007053 JOB ZEQA KTEST TSKKGUT4 000010 KTEST5 2007053 JOB ZEQA KTEST TSKKGUT5 000011 ZEKE51CC 2007053 JOB ZEQA SPTEXD11 000012 ZEKE51CC 2007053 JOB ZEQA SPTEXD12 000013 2007053 WORK ZEQA 000014 2007053 VCOM ZEQA 000015* today ZCOM ZEQA 000016 2007053 SCOM ZEQA
Enter S in the unlabeled Selection field to the left of all the events you want to add to the schedule. To add a particular version of an event to the schedule, enter the version number in the Versn No. field. You can add as many of the events displayed on one screen as you want.
Note:
An asterisk (*) next to an event number indicates that more than one event is scheduled with the same event number and different schedule dates. 7 Press Enter to select all the events marked on this page. Press F8 to display the next page of events. Press Enter. All the events marked are added to the current schedule.
254
Adding Events By Path

You can add an event to the schedule based on predecessor/successor relationships, that is, a specified events path. A path includes the root event and its predecessor and successor events.
Note:
To use this function, the DSPIndex generation option must be set to Y. You cannot use this function to schedule events with an OCCURS clause of (REQUEST).
To manually add an event to the schedule based on an event path

1 From the Zeke Primary Menu, enter option 2.4 and press Enter. The ADD Event Record by Path Selection Criteria screen is displayed.
ASG-Zeke Command ===> Criteria: Event Version Occurs Date Level Type ZADD options: Run Date Auto: Rebuild: Run: N N N ==> (Y/N) (Y/N) (Y/N) (YYYYDDD) Enable: N Refresh: N (Y/N) (Y/N) Hold: N Rerun: N (Y/N) (Y/N) ==> ==> ==> 2007022 ==> 1 ==> B ADD Event Record By Path Selection Criteria
(omit for default) (YYYYDDD) (P=pred, S=succ, B=both)
Complete the following fields to specify the root event to be processed. Field
Event
Description
Required. Event number for the root event, the event for which to display the path information. Version of the root event. OCCURS HIT date (in Julian format). Only events that would be scheduled on this date are included in the path. Default is the current system date.
Version Occurs Date
255
Field
Level
Description
Number of path levels to display. Valid values are 1-999, or enter an asterisk (*) for all levels. Default is 1. Type of path to display. Valid values are: P S B Predecessors only. Successors only. Default. Both predecessors and successors.
Type
In the Run Date field, specify date on which the event is to run, in Julian format (YYYYDDD). Events are added with the specified run date. Specify which parameters for adding the event. The default for each field is N. Enter Y for each parameter you want to include for the ZADD. Field
Auto
Description
Add 1 to the value for number of dispatch times if the scheduled event is active. The REFRESH and ENABLE parameters are assumed. Note: This parameter is not valid for work center events.
Enable Hold
Change the event status from DISABLE to ENABLE. Place an operator hold on the event after it is added, refreshed, or enabled. The event must be released from hold before it can be dispatched. Note: This parameter is not valid for work centers.
Rebuild
Recreate the SQR if one already exists. This option essentially: Deletes the SQR Re-adds the SQR Resets all WHEN conditions Reflects any EMR changes Places the event into ACTIVE status Resets any ZALTER changes previously made
256
Field
Refresh
Description
Refresh an SQR, if the status is EOJ, AEOJ, or Pending, by resetting the event as if it had never run. (The ZADD REFRESH does not place an operator hold on the job like the ZREFRESH command.) Add the RERUN designation to the schedule job record. The RERUN designation appears in the ZDISPLAY output and is passed to the user exit ZEKE14D. If the generation option Trigrrn=NO, the job will not trigger the WHEN conditions of other jobs. Use the NORERUN parameter of the ZALTER command to remove the RERUN designation. Add the event to the schedule ready to run. This is the same as a ZALTER RUN operator command.
Rerun
Run
Press Enter.
Note:
If the criteria entered results in multiple dates, a pop-up window appears and allows you to select the appropriate date.
257
The Schedule View Event Add List screen is displayed.

ASG-Zeke Command ===> Schedule View Event Add List
Line Commands: S - Select to add the event to the Schedule Level Event Job Evnt Event Sched Versn System Appl Grp Name Name Type Number Date Number ID ID ID ================================================================================= 3 EVENT00V JOB00V JOB 000024 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00W JOB00W JOB 000025 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00U JOB00U JOB 000023 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BA JOB00BA JOB 000029 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BH JOB00BH JOB 000036 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BQ JOB00BQ JOB 000045 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BL JOB00BL JOB 000040 2007094 00000 SYSTEM1 PATHAPP PTH *1 EVENT00BF JOB00BF JOB 000034 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BI JOB00BI JOB 000037 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BH JOB00BH JOB 000036 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BK JOB00BK JOB 000039 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BI JOB00BI JOB 000037 2007094 00000 SYSTEM1 PATHAPP PTH 1 EVENT00BG JOB00BG JOB 000035 2007094 00000 SYSTEM1 PATHAPP PTH 0 *1 2 3 3 3 2 3 3 *1 2 3 3 2 3 3 EVENT00BE EVENT00BC EVENT00BA EVENT00Y EVENT00Z EVENT00BL EVENT00BB EVENT00Z EVENT00BA EVENT00BD EVENT00BB EVENT00Z EVENT00BA EVENT00BC EVENT00BA EVENT00BB JOB00BE JOB00BC JOB00BA JOB00Y JOB00Z JOB00BL JOB00BB JOB00Z JOB00BA JOB00BD JOB00BB JOB00Z JOB00BA JOB00BC JOB00BA JOB00BB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB JOB 000033 000031 000029 000027 000028 000040 000030 000028 000029 000032 000030 000028 000029 000031 000029 000030 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 2007094 00000 SYSTEM1 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PATHAPP PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH PTH
Enter S in the unlabeled Selection field to the left of each event to add to the schedule. To add a particular version of an event to the schedule, enter the version number in the Versn Number field.
Note:
An asterisk (*) next to the Level number indicates events that begin a new level. 7 8 Press Enter to select all the events marked on the current page. Press F8 to display the next page of events.
258
9 10
Repeat steps 6 through 8, as necessary. Press Enter. All selected events are added to the current schedule.
259
260
Chapter 6:
Resources
6
Zeke provides both physical and logical resource control. Before dispatching an event, it ensures all resources are available. Topic
Resource Types Physical Resources How Initiator Processing Works Activating Initiator Options Defining Initiators to Zeke Defining Pools to Zeke Maintaining Logical Resources Defining a Logical Resource Maintaining Resources for an Event Deleting Resources for an Event
Page
262 262 263 267 269 272 274 275 277 281
261
Resource Types
Resource Type
Physical Logical
Includes
Tape drives, systems, pools, and initiators. Anything you want to define to represent the use of a physical resource such as the entire CPU, a specific CPU channel, a file, or a dataset. Logical resources are used for jobs that if executed simultaneously might cause contention among your system resources.
Note:
Work center events do not use resources.
Physical Resources
Tape drives are a resource used with job events. To ensure sufficient tape drives are available before an event executes, you can specify the number of required tape drives on the jobs EMR. See Maintaining a Job Event on page 92. Or, Zeke can automatically calculate the number of tape drives needed for each job. Use the generation option Calctap to activate this feature (see Calculating Tape Drive Usage on page 305). An initiator is a physical resource required by every OS job. To maximize the use of system resources, you can choose to have Zeke submit jobs to a system only when an initiator of the correct class is available.
Note:
Zeke does not support initiator selection for JES3. Another physical resource is the actual system the job will process on. These systems can be combined into pools that share the same database, allowing Zeke to select the proper system for each job.
262
6 Resources
How Initiator Processing Works

Before you determine whether you want to activate initiator processing, you need to understand how initiator selection occurs. Defining initiators to Zeke does not mean that Zeke controls them. Instead, it lets Zeke know which initiators are eligible for selection. Regardless of how an initiator is selected (Zeke or JES), the actual initiator is determined by a host of factors, including:

Whether there is a class on the job card Settings of the generation options Dispsel, Defdspcl, and Usercls Whether there is a list of classes on the EMR Initiator availability at the time of dispatch
As mentioned previously, there are several generation options that relate to initiator processing. The most important is Dispsel.
When Dispsel=Y
If Dispsel is set to Y, Zeke checks the EMR for a class list. An event can have up to six classes. If one or more classes is specified, Zeke selects a free initiator that has been defined to Zeke and can process one of the specified classes. If no classes are specified on the EMR, Zeke selects any free initiator defined to Zeke. Then, Zeke adds or changes the class parameter on the job card to reflect the selected class based on the following criteria:
If no class list is supplied, Zeke updates the job card with the highest priority class defined to the initiator and submits the job. If there is a class list, Zeke checks the value of the generation option Usercls. If Usercls is set to Y, Zeke updates the job card with the EMR class that caused the initiator to be selected and submits the job. However, if Usercls is set to N, Zeke updates the job card with the highest priority class defined to the initiator and submits the job.
263
The following flowchart illustrates the process that occurs before an event is dispatched to an initiator when Dispsel=Y.
Figure 3 Zeke Initiator Selection ProcessDispsel=Y
Dispsel=Y
Was a class specified in the EMR?
Waits until Zeke-defined initiator is available
Waits until a Zeke-defined initiator that processes the specified class is available. Initiator class preference is determined by the order in which they appear in the EMR.
Usercls=Y?
The highest priority class processed by the selected initiator is put on the job card and the job can run in any available initiator that can run that particular class.
The class on the EMR that caused the initiator to be selected is put on the job card.
Submit the job to JES
264
6 Resources
When Dispsel=N
If the generation option Dispsel is set to N, initiator selection is deactivated and Zeke submits jobs directly to JES when all other dispatching criteria have been met, without regard for initiator availability. One thing to be aware of is that jobs waiting in the JES input queue will have a PENDING status as they wait for JES to select the initiator. If Dispsel is set to N, Zeke checks the EMR for a class list. An event can have up to six classes. Zeke continues processing based on the following:
If no class list is supplied, Zeke checks the value of the generation option Defdspcl.
If Defdspcl does not have a value, Zeke submits the job to JES and the job card is unchanged. If a class is not specified on the job card, JES uses the JES-defined default class. If Defdspcl has a value, Zeke updates the job card with the default class value and submits the job to JES.
If there is a class list, Zeke updates the job card with the first EMR class and submits the job to JES.
The following considerations apply if you specify Defdspcl=N:

Initiator name does not appear in message Z0533I. NOTDURING dependency support is not available.
Note:
If you have set PLEXNOTD=YES in your Zeke options member to enable enhanced NOTDURING processing, then Dispsel=N is ignored for NOTDURING dependency support.

Tape drive prerequisites specified in the EMR are ignored. An auto-reply defined for one initiator is valid for all. The ZMAP command does not show initiator name. The ZDISPLAY AVAILABLE command is not valid. The INITIATOR parameter of the ZHOLD, ZRELEASE, ZALTER, and ZDISPLAY operator commands is not valid.
265
The following flowchart illustrates the process that occurs before an event is dispatched to an initiator, where Dispsel=N.
Figure 4 Zeke Initiator Selection Process-Dispsel=N
Dispsel=N
N Was a class specified in the EMR?
Was a value specified for Defdspcl?
Make no changes to the job card
Put the Defdspcl value on the job card
Put the first class specified on the job card
Submit the job to JES
266
6 Resources
Activating Initiator Options

Five generation options are related to determining how Zeke can use initiators for your system: Option
Defjprty Defdspcl Dispdly
Description
Specifies the default job priority on the EMR. Specifies the default dispatch class on the EMR. Specifies the number of seconds to wait before dispatching jobs to Zeke pools. (The Dispdly value is ignored if POSID is set to Y.) Specifies whether or not Zeke selects initiators. Specifies whether to use the EMR class for job submission.
Dispsel Usercls
To activate initiator options

1 Enter =4.1 on any Command line and press Enter. The Option System Directory is displayed.
E - Edit
Note:
'********' is the generic system name, so that if a system is not set up with its own generation options, it defaults to the values entered under this ID. 2 Enter E to the left of the System field and press Enter, or enter EDIT on the Command line and the system name in the System field and press Enter. Press F8 to scroll to the Defjprty field.
267
In the Defjprty field, enter a default job operating system priority (between 0 and 15) to use if a priority is not entered on the EMR PRI field. The default is 01. Enter NO if the priority should be left unchanged. In the Dispsel field, enter the code indicating whether Zeke selects the initiators. Code
Y N Note:
Meaning
Default. Selects initiators Disregard initiators
Dispsel is ignored if you are using JES3. 6 In the Defdspcl field, enter the default dispatch class that will be assumed if the class is not entered on the EMR. In the Dispdly field, enter the number of seconds to wait between dispatches of pooled events. The default is 30 seconds. This field is required if Dispsel=N, but is ignored if POSID=Y. Optionally in the Usercls field, enter one of the following codes to determine the job submission class. Code
N
Meaning
Do not use the EMR class; select initiators using the Zeke class selection process. Default. Use the class specified in the EMR to submit jobs to the initiator. Zeke does not change the class at dispatch time. If this option is set to Y and no classes are defined on the EMR, Zeke selects initiators using the regular class selection process.
At the Command line on any screen enter ZRELOAD GENOPT to reload the changed options.
268
6 Resources
Defining Initiators to Zeke

The next step is to define all the initiators for each operating system running Zeke. ASG recommends that you define every initiator and specify the times the initiator is available. If an initiator is not normally used by Zeke, specify a time range of 00:00 - 00:00 hours. This gives the operator the ability to alter, by operator command, the initiator information and enable the system to use the initiator on demand. ASG also recommends that when you define the initiators to JES, you make the first class of each initiator unique. This ensures that jobs will run in the Zeke-selected initiators, because when Zeke selects the initiator, it puts the highest priority class for that initiator in the job card, depending on the generation option Usercls. (See the Dispsel=Y flowchart on page 264.)
To define initiators
1 From the Zeke Primary Menu, enter 4.3 and press Enter. The System Initiator/Partition Directory is displayed.
ASG-Zeke Command ===> System ===> System Initiator/Partition Directory Row 1 to 1 of 1 Scroll ===> PAGE
System type ===>
("MVS", "VSE" or "VSE/ESA")
Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete System JES/POWER ID System Type
E - Edit
Description
_ ******** MVS _ TSO45 VSE/ESA _ Z51TST MVS ***************************** Bottom of data ******************************
Add a new system and initiator specifications
Action
Do the following: Enter ADD on the Command line Enter the name of the new system in the System field; this is the value of the NAME parameter in the OASIS options member Enter MVS in the System Type field to indicate the operating system
Edit initiator information for an Enter E in the unlabeled Selection field to the left of the existing system system you want to update. 269
Press Enter. The System Initiator Specification screen is displayed.

ASG-Zeke Command ===> System Initiator Specification EDIT Scroll ==> PAGE
Zeke System: ******** System type: MVS JES System ID: Description: Primary command: ADD BROWSE CANCEL COPY EDIT DELETE (All initiators) Line commands: B - Browse initiator detail E - Edit initiator detail D - DELETE A LINE R - REPEAT A LINE I - INSERT A LINE Initid A T004 T03 T2 1 2 B C D E F G MTWTFSS NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN
_ _ _ _ _ _ _ _ _ _ _ _
Add an initiator
Action
In the Initid field, enter the ID to be assigned to the initiator. Use the same name as when it was defined to JES. Press Enter and the initiator is added. To add availability detail for the initiator, enter E in the unlabeled Selection field next to the initiator.
Edit existing initiator information Copy an initiator record
Enter E in the unlabeled Selection field next to the initiator you want to update. Enter R in the unlabeled Selection field next to the initiator you want to copy. Enter D in the unlabeled Selection field next to the initiator you want to delete and press Enter. The initiator is deleted for this system. Go to step 7. Enter DELETE on the Command line and press Enter. To confirm the delete, enter DELETE on the Command line again and press Enter. Go to step 7.
Delete a single initiator
Delete system name and all initiator specifications
270
6 Resources
Press Enter. The System Initiator Detail screen is displayed.

ASG-Zeke COMMAND ===> System Id : EDMVS System Initiator Detail EDIT
Initiator Id:
A1
Primary commands: BROWSE CANCEL EDIT Start Monday Tuesday Wednesday Thursday Friday Saturday Sunday time time time time time time time ranges: ranges: ranges: ranges: ranges: ranges: ranges: End Start End Start End Start End
To restrict the time of day the initiator is available to Zeke, enter the hours of availability in the Start and End fields for each day. If you do not enter a range for a day, the initiator is assumed to be available 24 hours that day. For example, if the initiator is available 24 hours a day Monday through Saturday, but on Sunday only from 7:00 a.m. to 6:00 p.m., in the first Start field next to Sunday time ranges, enter 07:00. In the first End field, enter 18:00. A time range of 00:00 - 00:00 makes the initiator unavailable all day. However, the operator can still make use of the initiator on-demand through Zeke operator commands.
7 8
Press Enter. At the Command line on any screen enter ZRELOAD INIT to reload the changed information.
271
Defining Pools to Zeke

Every job is owned by one of the systems sharing the Zeke database or by one of the pools. A pool is a user-defined group of systems identified to Zeke. If you have a group of systems you want to treat as a unit, you can group them in a pool. For example, if you have multiple systems used only for testing, you can define them as a pool. Then, when you assign an event to that pool, it will run on one of your test systems. On the EMR, the System field specifies the owning system or pool the job belongs to. The system name corresponds to the NAME parameter of the OASIS00 options member (if not using a pool ID). If no owner is specified, a default of system A is used.
To define and maintain a system pool

1 From the Zeke Primary Menu, enter 4.5 and press Enter. The System Pool Directory is displayed.
ASG-Zeke Command ===> Pool id ===> POOL1 Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C -Copy D - Delete System Pool Directory Row 1 to 1 of 1 Scroll ===> PAGE
E - Edit
Pool ID Description ************************************************************************** POOL1 TEST POOL MAIN PROD1 POOL ***************************** Bottom of data ******************************
Add a new pool
Action
Make the following entries: Enter ADD on the Command line. Enter the name of the new system in the Pool ID field. Note: Do not use any Zeke operands, parameters, keywords, or abbreviations of these to name your systems or pools. For example, do not name an system or pool AB, which is short for the parameter ABEND.
Edit an existing pool
Enter E in the unlabeled Selection field to the left of the pool you want to update.
272
6 Resources
Desired Result
Delete a pool
Action
Enter D in the unlabeled Selection field to the left of the pool you want to delete. Press Enter. Enter DELETE on the Command line and press Enter. The pool is deleted. This procedure is complete.
Press Enter. The System Pool Specification screen is displayed.

ASG-Zeke Command ===> Pool ID: POOL1 System Pool Specification EDIT Scroll ==> PAGE Desc: TEST POOL
Primary command: ADD BROWSE CANCEL COPY DELETE EDIT Line commands: D - Delete a line I - Insert a line SYSTEM TSO45
R - Repeat a line
Add a system to a new pool
Action
Enter the new system name in the System field. You can enter up to 15 systems on one screen. If you need to add more than 15 systems, press F8 to view additional blank lines for entry. Note: Do not use any Zeke operands, parameters, keywords, or abbreviations of these to name your systems or pools. For example, do not name a system or pool AB, which is short for the parameter ABEND.
Add a system to an existing pool
Enter I in the unlabeled Selection field next to a system name. Press Enter. A blank line is added. Enter the new system name on the blank line. Enter the changes to the system you want to update. Enter D in the unlabeled Selection field next to the system name.
Edit an existing system Delete a system from a pool
273
Press Enter. The pool record is updated.
Cycle Zeke in order for your modifications to take effect.
Maintaining Logical Resources

Logical resources are user-defined and represent the use of a physical resource. The difference between a logical resource and a physical resource is the logical resource does not really have to exist. Logical resources can be used for events that if executed simultaneously might cause contention among your system resources. Think of logical resources as a more versatile and sophisticated NOTDURING dependency. A logical resource can be anything you want to define to represent the use of a physical resource such as an entire CPU, a specific CPU channel, a file, or a dataset. For example, a file is used by six different jobs. Jobs 1 through 5 use this file in Read mode while job 6 backs up the file. This causes dataset contention when job 6 is running with any of the other 5 jobs. To avoid dataset contention, use logical resources to ensure that job 6 runs alone. Define a resource to represent the file and give job 6 exclusive access to the resource. To set up or define a logical resource, you must enter:
A quantitative figure to let Zeke know how much of a resource is available at any one time. Which systems the resource is active on.
Then, for each job that uses this resource, enter the resource name and the amount used of the required resource on the EMR. Prior to dispatch, Zeke ensures the required resource is available in the quantity specified. For example, say a resource is defined with a value of 1. JOBA needs 1 of this resource before it can run. If JOBB is running and using this resource, it will not be available and JOBA will have to wait for JOBB to free the resource.
Note:
When Dispsel=N, only resources defined as GLOBAL (that is, any system can share the resource) are resolved.
274
6 Resources
Defining a Logical Resource

This procedure defines resources to the Zeke database. It tells Zeke where each resource exists and how many are available.
To define a logical resource

1 From the Zeke Primary Menu, enter 4.6 and press Enter. The Resource Specification screen is displayed.
ASG-Zeke Command ===> Resource name ===> System ===> Line Commands: C - Copy D - Delete Primary Commands: ADD COPY DELETE Maximum Active? Shared EDR2 MEDA 00001 YES EDR2 TSO45 00001 YES EDR3 (GLOBAL) 00001 YES INIT1 (GLOBAL) 00005 YES TAPE (GLOBAL) 09901 YES TAPEDRIVE HLPDESK 00001 YES ***************************** Bottom of data ****************************** Resource name System Resource Specification Row 1 to 1 of 1 Scroll ===> PAGE
Perform the steps outlined in the Action column, depending on the desired result: Desired Result
Define a resource to Zeke
Action
Make the following entries: Enter ADD on the Command line. Enter the resource name in the Resource Name field and press Enter.
Caution! Do not use spaces within the resource name.

For example, the name MY DATASET NAME is invalid. Instead, use MY.DATASET.NAME. Edit an existing resource To update Maximum Shared or Active, type over the existing information and press Enter.
275
Desired Result
Copy an existing resource to a new name
Action
Enter COPY on the Command line. Enter the resource name to copy in the Resource Name field and press Enter. The Resource Detail screen is displayed. Enter the new name in the Resource Name field and press Enter to complete the procedure and to return to the Resource Specification screen.
Delete a resource
Enter DELETE on the Command line. Enter the resource name to delete in the Resource Name field and press Enter. The Resource Detail screen is displayed. Press Enter again to delete the resource and return to the Resource Specification screen. Note: Ensure no events reference a deleted resource. Events that try to acquire a deleted resource will not dispatch.
The Resource Detail screen is displayed when the add, copy, or delete command is entered.
ASG-Zeke Command ===> Resource name: INIT1 Resource Detail Scroll ===> PAGE
Primary commands: ADD CANCEL COPY DELETE EDIT System: (GLOBAL) Max share count: 00005 Active?: YES
In the System field, enter the code identifying the system that owns the resource. You can specify a resource more than once with different system names. GLOBAL is the default and means any system can share this resource. If the jobs system name is assigned to a pool, leave this field GLOBAL to ensure proper dispatching. In the Max Share Count field, enter the number identifying the resource amount. This can be any number that quantifies the resource availability.
276
6 Resources
Enter the code indicating whether the resource is active in the Active field. Code
YES
Meaning
Indicates the resource is active. Zeke ensures the resource is available before dispatching an event that uses this resource. Indicates the resource is not active. Zeke does not perform any resource control for events that use this resource.
NO
When you have finished adding or updating information on the Resource Detail screen, press Enter to update the data.
Maintaining Resources for an Event

Once you have defined logical resources for your systems, use the Resource Control screen to assign the appropriate resource name and amount used of the required resource for each event. Prior to dispatch, Zeke ensures the required resource is available in the quantity specified. Caution! You must complete the procedure Defining a Logical Resource on page 275 before beginning this procedure for adding the resource to an event. If a resource is added to an event before defining it, the event will be unable to acquire it and will not dispatch properly.
To add a resource to an event

1 Access the EMR or the Event Master Directory as instructed in the procedure, Accessing the Event Master Record on page 82. Perform one of the following:
From the Event Master Directory, enter E4 to the left of the event number for the event you want to assign a resource to and press Enter. From the EMR, enter RESOURCE on the Command line and press Enter.
277
The Resource Control screen is displayed.

ASG-Zeke Command ===> Resource Control EDIT Scroll ===> PAGE
Primary Commands: BROWSE DELETE EDIT Evt: 000007 Type: JOB Job: TSKKGUT2 Evt Name: KTEST2 System: ZEQA
Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S) --------------Resource Name----------------- Cnt --CodesMd H E A ========================================================================== INIT1 001 SR N R N
If the job has no resources defined, simply enter the name of the resource in the Resource Name field. If the job already has one or more resources defined: a Enter i in the line command field to the left of one of the existing resource names and press Enter to insert a line after that resource. Enter the name of the new resource in the Resource Name field of the new line.
b 5
In the Cnt field, enter a number to represent how much of this resource is used when this job runs.
Note:
If mode is EX or ES, this field must be 001. 6 In the Md field, enter a code indicating the resource mode required by the job: Desired Result
Allow only one job access to this resource in Write mode.
Action
For that one job, enter EX in the Md field. For example, a file is used by 6 jobs. All of the jobs but 1 use the file in Read mode. The remaining job backs up the file. This causes dataset contention when the job backing up the file is running with the other 5 jobs. To avoid dataset contention, youll want to run the job that backs up the file alone. Set up a logical resource with a maximum share count of 5. Define the resource to each of the 5 jobs that read the dataset with a mode of SR and a count of 1. Define the resource to the job that backs up the dataset with a mode of EX so it wont execute concurrently with any of the 5 jobs reading the dataset.
278
6 Resources
Desired Result
Allow only one job access to this resource in Read mode
Action
Enter ES in the Md field. For example, out of a group of 6 jobs, 2 of the jobs (A and B) cannot run together. However, the remaining jobs can run in any combination with either jobs A or B. Set up a logical resource with a maximum share of 5. Define Jobs A and B with a mode of ES and a count of 1. Define the other jobs with a mode of SR and a count of 1. Note: Jobs with exclusive share cannot run with other exclusive share jobs, but they can run with any number of share jobs.
Allow multiple jobs access to this Enter SR in the Md field. resource For example, 3 jobs execute nightly at about the same time which causes performance problems. Set up a logical resource with a maximum share of 100. Set up each job with a resource mode of SR and a count of 50. Zeke only allows 2 of these jobs to run simultaneously. The third job must wait for one of the jobs to complete so that at least 50 of the resource is available.
In the H field, enter a code indicating if resources should be held. Code

Y
Meaning
Hold resource if available and the correct mode. However, the resource can be stolen by another job with a higher dispatch priority. For example, job A requires 4 resources prior to dispatch. Other jobs require only 1. With the H field set to Y, job A holds each resource as it becomes available until it has all 4. The other jobs must wait until job A releases the hold on the resources before they can run. (Default.) Do not hold available resource. For example, job A requires 4 resources prior to dispatch. Other jobs require only 1. With the H field set to N, the other jobs continue to obtain 1 of the resources as needed. Job A waits and does not hold any resources until all 4 are available at the same time.
279
In the E field, enter a code indicating if resources should be released at AEOJ. Code
K
Meaning
Keep resource if the job abends. The resource mode must be EX or ES and can be obtained by a restart/rerun. (Default.) Release resource if the job abends.
In the A field, enter a code indicating whether to use the resource for a restart. Code
Y
Meaning
Use resource for a restart. The job will try to obtain the resource from an abended job, if the job is set to release the resource (RESKEEP=YES). The resource mode must be EX or ES and can be obtained by a restart/rerun. Do not use resource for a restart. Job can assume the resource from itself only, if it abends.
N S
10
When you have finished adding or updating information on the Resource Control screen, press Enter to update the data.
280
6 Resources
Deleting Resources for an Event

Use the Resource Control screen to delete one or more resources for an event.
To delete one or more resources for an event

1 Access the EMR or the Event Master Directory as instructed in the procedure, Accessing the Event Master Record on page 82. Do one of the following: a From the Event Record Directory screen, enter E4 to the left of the Event Number field for the event for which you want to delete a resource and press Enter. From the EMR, enter RESOURCE on the Command line and press Enter.
The Resource Control screen is displayed.

ASG-Zeke Command ===> Resource Control EDIT Scroll ===> PAGE
Primary Commands: BROWSE DELETE EDIT Evt: 000007 Type: JOB Job: TSKKGUT2 Evt Name: KTEST2 System: ZEQA
Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S) --------------Resource Name----------------- Cnt --CodesMd H E A ========================================================================== INIT1 001 SR N R N EDTR2 002 SR N R N
To delete one or more specific resources, enter d in the line command field to the left of the resource names you wish to delete. Press Enter.
Or
To delete the entire resource record for the job, enter DEL on the Command line and press Enter. Press Enter again to confirm the deletion.
281
282
Chapter 7:
Maintaining Zeke
7
Zeke provides you with a great amount of flexibility and control of event scheduling and Zeke database access and maintenance. Generation options set these specifications. Topic
Changing Zeke Operating Criteria Accessing Generation Options Activating Variable Substitution Dispatching Messages and Events Recognizing NOT-CAT2 Messages Retaining Events Triggering Events Scheduling Events Pending Messages and Events Defining Schedule Download Agents Setting Auto Replies Loading the Work Center to SQT Calculating Tape Drive Usage Checking the Dispatch Queue Maintaining the Job Restart Facility Maintaining Networking Options Maintaining Inter-product Communication Using Shared Databases Dispatching Events After Zeke Start-up Building EDB Indexes Obtaining Operating Passwords Changing ISPF Color Scheme Using the Audit Facility Database Maintenance Creating the Zeke Databases (Primary and Vault) Backing Up the Zeke Database Restoring the Zeke Database Moving the Vault Database Recovery Using Electronic Vaulting
Page
284 286 288 288 290 291 293 297 300 301 303 304 305 306 306 307 309 311 312 312 314 316 318 320 320 323 324 326 328
283
Topic
Continuous Job Tracking Terminating Zeke Using ZKILL TRACK SMF Recording Mode Applying Maintenance SMF Playback
Page
331 331 332 335 335
Changing Zeke Operating Criteria

Generation options are necessary because no two data centers are exactly the same. In fact, for some installations, no two systems are the same. Zeke allows you to set up separate systems with different generation options for each. When Zeke is installed, these generation options are set to default values that are satisfactory for most data centers. As you gain more experience and start to use more of the features, you may want to update the generation options to better meet your needs. Because they affect your entire site, your personnel responsible for system programming, scheduling, data security, and site standards all should review and agree on your generation options settings. You should define the options immediately after Zeke is installed. (They can be changed at a later date, if necessary.) To date, there are over 150 generation options. This chapter discusses in greater detail only the options most commonly used. Refer to your ASG-Zeke for z/OS Reference Guide for an alphabetical listing, along with explanations, of all Zeke generation options. After any changes are made, you must enter the operator command ZRELOAD GENOPT at the console for each system that will be affected by the changes. For most generation options, the changes take effect immediately. However, some options require you to cycle Zeke, using either ZKILL COLD or ZKILL TRACK. The table below lists the generations options that require you to cycle Zeke when changed, and indicates whether ZKILL TRACK is effective for making the change.
284
7 Maintaining Zeke
Table 1 Generation Options Requiring a Zeke Cycle Cycle Required Generation Option
Aur DSPIndex Dynsmf EDBindex GUIServ Iefu83 MultSys Netregid Oprhold Posid Wktrgdn X14coml ZPRDcom
COLD
TRACK
285
Accessing Generation Options

To access the generation options
1 Enter =4.1 on any Command line and press Enter. The Option System Directory is displayed.
E - Edit
This screen displays a list of existing systems.

Note:
'********' is the generic system, so that if a system is not set up with its own generation options, it defaults to the values entered under this ID. 2 Depending on the desired result, perform one of the following actions. Desired Result
Add a system
Action
Enter ADD on the Command line and enter the new system in the System field, and press Enter. The Generation Options screen is displayed. Re-enter the new system on the Command line and press Enter. Enter B to the left of the System field and press Enter, or enter BROWSE on the Command line and the system in the System field and press Enter. Enter E to the left of the System field and press Enter, or enter EDIT on the Command line and the system in the System field and press Enter.
Browse an existing system
Edit an existing system
286
7 Maintaining Zeke
Desired Result
Copy an existing system
Action
Enter C to the left of the System field and press Enter, or enter COPY on the Command line and the system in the System field and press Enter. The Generation Options screen is displayed. Enter the new system on the Command line and press Enter. Enter D to the left of the System field and press Enter, or enter DELETE on the Command line and the system in the System field and press Enter. The Generation Options screen is displayed. Enter DELETE on the Command line to confirm the delete and press Enter.
Delete an existing system
The first Generation Options screen is displayed.

N Y 01 Y BATCH N
Scroll to the generation option you want to view or update by pressing F8 (scroll forward), or F7 (scroll backwards). See the procedures listed in this section for a detailed explanation on how to update specific generation options.
287
Activating Variable Substitution

The Subdata generation option affects variable substitution. Activate this option if you want variable substitution to be performed in your JCL. If this option is not activated, errors will occur in jobs submitted with Zeke and OASIS variable names in the JCL.
To activate variable substitution

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286 Press F8 to scroll to the Subdata field. Enter Y to substitute variables in the JCL before submitting the job to JES and press Enter. To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
2 3
Dispatching Messages and Events

The following generation options are related to dispatching events and issuing related messages. Defdprty Dispdly Dispmsg Msgwait Mspintrl Operok Prilate
Note: Specifies the default dispatch priority on the EMR. Specifies the number of seconds to wait between dispatches of pooled events. (The Dispdly value is ignored if POSID is set to Y.) Specifies whether or not to issue event dispatch messages. Specifies amount of time between messages for events waiting in the dispatch queue. Specifies the time when an event is given a higher dispatch priority. Specifies whether Zeke is to wait for an operator OK before dispatching any event. Specifies whether to dispatch late events with priority.
In this section the term priority refers to the Zeke dispatching priority, not the operating system job priority.
288
7 Maintaining Zeke
To activate the options for dispatching messages and events

1 Access the Option System Directory screen in Edit mode as instructed inAccessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the Defdprty field, enter a default dispatch priority (between 1 and 99) to use if a dispatch priority is not entered on the EMR. The default is 50. This number displays in the Dprty field on the EMR. If Dispel=N, then in the Dispdly field, enter the number of seconds to wait before dispatching pooled events. The default is 30 seconds. (The Dispdly value is ignored if POSID=Y.) In the Dispmsg field, enter the code indicating whether Zeke should issue dispatching messages. Code
Y N
2 3
Meaning
(Default.) Issue dispatching messages Z0603I, Z0604I, and Z0605I Disregard dispatching messages
In the Msgwait field, enter the amount of time (HH:MM) Zeke waits between issuing messages for events waiting in the dispatch queue. The default is 1 hour. This option affects the following messages:
Z0601I Z0615I Z0628I Z0602I Z0617I Z0631I Z0611I Z0618I Z0634I
In the Mspintrl field, enter a time interval (HH:MM) for near dispatches. Jobs are given a higher dispatch priority if their Must Start or Not After times are within the specified interval. The default is 1 hour.
289
In the Operok field, enter a code indicating whether Zeke is to wait for an operator OK before dispatching any event. This option can be overridden for an individual event on the EMR (OPEROK). Code
Y
Meaning
Wait for an operator OK; a message is issued when an event is placed in the dispatch queue (Default.) Dispatch events without an operator OK
In the Prilate field, enter the code indicating whether to dispatch late events with a higher dispatch priority. Code
Y N
Meaning
Dispatch late events before other events, regardless of the schedule time (Default.) Dispatch events in the schedule time sequence, without regard to late time
10
To activate the updated options, enter ZRELOAD GENOPT on the Command line.
Recognizing NOT-CAT2 Messages

This option recognizes the following NOT-CAT2 messages and marks the job as failed.
IEF377I IEF452I IEFC452I IAT4801 IEF287I IEF378I MIM1083 (MIMS product message)
To activate the NOT-CAT2 option

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the IGNCAT2 field. Enter N for Zeke to recognize NOT-CAT2 messages, and to mark the job as failed. To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
2 3 4
290
7 Maintaining Zeke
Retaining Events
The following generation options are related to retaining events.
Commctl Retain Retdays Retdone Retpend Specifies whether to retain work centers until completed. Specifies whether to retain incomplete events. Specifies the days to retain pending or AEOJ job events. Specifies whether to retain completed events in the schedule. Specifies whether to retain SQRs until completion of the event.
To activate any of the options for retaining events

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the Commctl field, enter the code indicating whether Zeke should retain work centers in the schedule until they are done (EOJ) or disabled. Code
Y N
2 3
Meaning
(Default.) Retain work centers until completed or disabled. Discard work centers the next day, regardless of status.
If the value for Retain in the EMR is Yes and the value in the Commctl parameter is No, the Commctl parameter overrides the definition on the EMR for work centers. However, if Retain is Yes and Commctl is No, but the Loadcomm option is set to Yes, then the work center is retained. 4 In the Retain field, enter the code indicating whether Zeke should retain non-dispatched events. This option determines the default value for the Retain field on the EMR. Code
Y N
Meaning
(Default.) Retain events for the next schedule run. Discard non-dispatched events during the next schedule run.
291
In the Retdays field, enter the number of days to retain pending or failed events. The default is 002 days.
Note:
If you enter 000 days in the Retdays field, the events will be dropped on the next days schedule load. 6 In the Retdone field, enter the code indicating whether Zeke should retain completed events in the schedule. Code
Y N Note:
Meaning
(Default.) Retain completed events Discard completed events after EOJ
If using EOG, you must retain completed events. 7 In the Retpend field, enter the code indicating whether Zeke should retain SQRs until the event is complete. Code
Y N
Meaning
(Default.) Retain events until done (EOJ or disabled) Delete schedule records when the event is dispatched
To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.
292
7 Maintaining Zeke
Triggering Events
The following generation options are related to triggering events.
Iefu83 Dynamically installs SMF IEFU83 to trigger events when a newly created dataset is open and closed. Note: Because the Iefu83 generation option controls whether the Zeke IEFU83 SMF exit ZEKE48G is loaded, changes to the value of this option do not take effect when a ZKILL TRACK restart is performed. Changing this option requires a ZKILL COLD restart. Remtrig Indicates how to handle a remote trigger received for scheduled jobs with multiple schedule dates if the remote trigger does not contain a schedule or run date. If the remote trigger has a schedule and run date, this option is ignored and the Trigdt option is applied to the dates to process the trigger. If the remote trigger was satisfied by a Zeke-controlled job, the SQR's schedule and run dates are sent with the trigger. If the remote trigger was satisfied by a non-Zeke job on a Zeke system, the system's current date is sent as the schedule date and run date with the trigger. TA NT Trigger all dates. If multiple dates exist, then do not trigger any date. If only one date exists, trigger that date. Trigger the oldest date only. Trigger the newest date only.
OD ND Trigdt
Specifies whether a Zeke-controlled job can trigger another events WHEN conditions if the schedule or run dates are different. Note: When the schedule is created and a subset of SQRs is to be downloaded to Zeke Agent, the value of the Trigdt genopt is communicated to Zeke Agent. If this genopt is changed on Zeke and a ZRELOAD GENOPT command is executed, Zeke Agent continue to use the old Trigdt value until a new schedule is downloaded.
293
Trigjob
Specifies whether a job can trigger another events WHEN conditions if the job is not dispatched by this Zeke (or by another Zeke sharing the same database). Note: When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the object of the AT netregid of another scheduler's trigger), a non-Zeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke's Trigjob generation option. Both the local and remote Zeke systems ignore the Trigjob genopt when satisfying cross-schedule triggers.
Trigrrn
Specifies whether a job can trigger another events WHEN conditions if the job has a rerun designation. Specifies whether completed events can trigger weak WHEN conditions.
Wktrgdn
To activate any of the triggering options

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the IEFU83 field, enter the code indicating whether to dynamically install the SMF IEFU83 exits. Code
Y N
2 3
Meaning
Install the SMF IEFU83 exits to use the DSN dependency (Default.) Do not install the SMF IEFU83 exits
In the Trigdt field, enter the code indicating whether an Zeke-controlled job can trigger another events WHEN conditions if the dates are different. Code
A
Meaning
(Default.) Any event can trigger an events WHEN conditions, regardless of the date. The schedule dates must be the same before an event can trigger another jobs WHEN conditions. The schedule date is the date that an event would have run if it were not a non-workday (weekend or holiday).
294
7 Maintaining Zeke
Code
R
Meaning
The run dates must be the same before an event can trigger another events WHEN conditions. The run date is the date the event was actually added to the schedule, either by the ZADD command or the batch schedule function. The run date also could have been added with a ZADD command using a different date with the RDATE parameter.
Note:
If multiple Zeke systems are sharing a database (Multsys is set to Y), each of the Zeke systems must be set to the same Trigdt value. Otherwise, you may experience excessive database I/O. 5 In the Trigjob field, enter the code indicating whether an event can trigger another events WHEN conditions. Code
A
Meaning
(Default) Any job can satisfy triggers on this Zeke regardless of how/where the job is dispatched. Only jobs dispatched by this Zeke (or by a Zeke sharing the same database) can satisfy triggers on this Zeke. Remote Zeke jobs and non-Zeke jobs are ignored. Only jobs dispatched by this Zeke (or by a Zeke sharing the same database) and non-Zeke jobs can satisfy triggers on this Zeke. Remote Zeke jobs are ignored.
Note:
If multiple Zeke systems are sharing a database (i.e., Multsys is set to Y), each of the Zeke systems must be set to the same Trigjob value. When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the object of the AT netregid of another scheduler's trigger), a non-Zeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke's Trigjob generation option. Both the local and remote Zeke systems ignore the Trigjob genopt when satisfying cross-schedule triggers.
295
In the Trigrrn field, enter the code indicating whether an event can trigger another events WHEN conditions if the event has a rerun designation. Code
Y
Meaning
(Default.) Any event can trigger an events WHEN conditions, regardless of the rerun designation A rerun event cannot trigger another events WHEN conditions
In the Wktrgdn field, enter the code indicating whether previously completed events can trigger weak WHEN conditions. Code
Y N
Meaning
Allow completed events to trigger weak WHEN conditions (Default.) Do not allow previously completed events to trigger weak WHEN conditions
Note:
If multiple Zeke systems are sharing a database (Multsys is set to Y), each of the Zeke systems must be set to the same Wktrgdn value. Otherwise, you may experience excessive database I/O. 8 To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.
296
7 Maintaining Zeke
Scheduling Events
The following generation options are related to scheduling events.
MultAp Specifies what to do when a ZADD by application ID is issued and multiple events have the same application ID. Specifies what to do when a ZADD by group ID is issued and multiple events have the same group ID. Specifies whether an event is scheduled multiple times when there is a nonworkday. Specifies what to do when a ZADD by job name is issued and multiple events have the same name. Specifies what to do when a ZADD by event name is issued and multiple events have the same name. Specifies what to do when a ZADD by user ID is issued and multiple events have the same user ID. Specifies whether to schedule an event if the OCCURS clause is true for a nonworkday.
MultGr
Multhit
MultJn
MultEn
MultUs
Nonwkday
Note:
The options MultAp, MultGr, MultJn, MultEn, and MultUs work together to determine what jobs are added with the ZADD command. If multiple criteria is used on the same ZADD command, the option with the most restricted value is applied. For example, if a ZADD by jobname and application ID is requested and MultJn=All and MultAp=None, then no events are added since the most restricted is none.
To activate the event scheduling generation options

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the Multap field, enter the code indicating how to handle a ZADD by application ID when multiple events exist with the same application. Code
F
2 3
Meaning
(Default.) Add the first matching event and end the search; this is the most efficient
297
Code
N A
Meaning
Do not add any events; list all matching events on the console Add all the matching events
In the Multgr field, enter the code indicating how to handle a ZADD by group ID when multiple events exist with the same group. Code
F
Meaning
(Default.) Add the first matching event and end the search; this is the most efficient Do not add any events; list all matching events on the console Add all the matching events
N A
In the Multhit field, enter the code indicating whether an event can be scheduled multiple times when there is a nonworkday. This option determines the default value for the Multhit field on the EMR. Code
Y
Meaning
(Default.) Allow multiple schedule records. For example, if Monday is a holiday, then Zeke schedules the jobs to run 2 times on Tuesday, if they are supposed to run on Monday and Tuesday. Allow only 1 schedule record
In the Multjn field, enter the code indicating how to handle a ZADD by jobname when multiple events exist with the same name. Code
F
Meaning
N A
298
7 Maintaining Zeke
In the Multen field, enter the code indicating how to handle a ZADD by event name when multiple events exist with the same name. Code
F
Meaning
N A
In the Multus field, enter the code indicating how to handle a ZADD by user ID when multiple events exist with the same user ID. Code
F
Meaning
(Default.) Add the first matching event and end the search; this is the most efficient Do not add any events; list all matching events on the console add all the matching events
N A
In the Nonwkday field, enter the code indicating when to schedule an event if the OCCURS clause is true for a nonworkday. This option is the default used on the EMR (Nwday field). Code
A
Meaning
(Default.) Schedule the event after the nonworkday. For example, if Monday is a holiday, all events scheduled for Monday will be scheduled for Tuesday. Schedule the event before the nonworkday Schedule the event on the nonworkday Do not schedule the event
B O N
10
To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.
299
Pending Messages and Events

The following generation options are related to pending messages and events.
Pendinv Pendmsg Specifies the pending event interval. Specifies the pending message interval.
To activate the options for pending messages and events

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the Pendinv field, enter the number of minutes Zeke will hold a pending events initiator. At the end of this interval, Zeke will place the initiator in the table of available initiators and dispatch other events to it. In the Pendmsg field, enter the number of minutes between messages that notify you of a pending event. Enter 0 if you do not want a message to be issued. To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.
2 3
300
7 Maintaining Zeke
Defining Schedule Download Agents

Zeke allows you to download a subset of SQRs in the Zeke schedule to a Zeke Agent. In order to download SQRs to Zeke Agent, Zeke Agent must first be defined to Zeke.
To define a download agent

1 From the Zeke Primary Menu, enter 4 and press Enter. The Options Selection Menu is displayed. 2 From the Options Selection Menu, enter 9 and press Enter. The Schedule Download Agents List screen is displayed.
ASG-Zeke Command ===> NETREGID ===> Primary Commands: ADD DELETE EDIT END Line Commands: D - Delete E - Edit NETREGID Description ****************************************************************************** UNIXAGNT ZEKE AGENT UNIX ******************************* Bottom of data ******************************* Schedule Download Agents List Row 1 of 3 Scroll ===> PAGE
Perform the steps in the Action Column, depending on the desired result. Desired Result
Add a new agent
Action
Make the following entries: Enter ADD on the Command line. Enter the Netregid on the NETREGID line. Press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 4.
Update an existing agent for which you know the Netregid
Make the following entries: Enter EDIT on the command line. Enter the Netregid on the NETREGID line. Press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 5.
Update an existing agent for which you do not know the Netregid
Enter E next to the appropriate Netregid and press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 5. 301
Desired Result
Delete an agent for which you know the Netregid
Action
Make the following entries: Enter DELETE on the Command line. Enter the Netregid on the NETREGID line. Press Enter. The Schedule Download Agent Specification screen is displayed. Enter DELETE on the Command line to confirm the delete. Press Enter. The Netregid that you selected is deleted and the Schedule Download Agents List screen is displayed. This procedure is complete.
Delete an agent for which you do not know the Netregid
Enter D next to the appropriate Netregid and press Enter. The Schedule Download Agent Specification screen is displayed. Enter DELETE on the Command line to confirm the delete. Press Enter. The Netregid that you selected is deleted and the Schedule Download Agents List screen is displayed.
Schedule Download Agent Specification
Primary commands: CANCEL END NETREGID: NTAGENT Description:
In the Description field, enter the description of the agent and press Enter.
Note:
You may not change the information in the NETREGID field. 5 Press F3 to save the information and to return to the Schedule Download Agents List screen.
ASG-Zeke Command ===> NETREGID ===> Primary Commands: ADD DELETE EDIT END Line Commands: D - Delete E - Edit NETREGID Description ******************************************************************************* NTAGENT ZEKE AGENT NT UNIXAGNT ZEKE AGENT UNIX ******************************* Bottom of data ******************************** Schedule Download Agents List Agent added Scroll ===> PAGE
302
7 Maintaining Zeke
Setting Auto Replies

Zeke allows you to automatically respond to outstanding replies (WTORs) from your Zeke-controlled jobs which have static or predictable responses. The following generation options affect automatic replies.
Aur Enables or disables automatic responses to messages and replies.
Caution! You must cycle Zeke if you update the Aur generation option.
Aurintv Aurmsg Specifies the interval to check for automatic responses. Indicates whether the operator is notified of issued auto responses.
To activate automatic replies

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the Aur field, enter Y to enable the automatic reply facility. This facility is designed for job events that require message replies. In the Aurintv field, specify the number of seconds to check for automatic replies (from the default of 01 to 99).
Note:
2 3
If you have numerous jobs with auto replies, use a lower value to improve throughput. If you only have a few jobs with auto replies, use a higher value to decrease system overhead. 5 In the Aurmsg field, enter Y (default) to issue a message to the operator when an automatic reply is supplied. Cycle Zeke if you have updated the Aur field. To activate the updated Aurintv and Aurmsg options, enter ZRELOAD GENOPT on the Command line and press Enter.
6 7
303
Loading the Work Center to SQT

The Loadcomm option specifies whether to load work centers to the schedule queue table (storage). We recommend you activate this option if you use work centers that are loaded into the schedule queue at schedule load time. This improves response time when accessing the events through the work center function. Additionally, work centers can be displayed in Schedule View and by using the ZDISPLAY command.
Note:
The Loadcomm option must be set to Y to access or complete work centers from an OpsCentral console.
To activate the LOADCOMM option

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Loadcomm field. In the Loadcomm field, enter the code indicating whether to load work centers to the schedule queue table. Code
Y
2 3
Meaning
(Default.) Load work centers to the schedule queue table. This option loads the work center more efficiently, but requires more above the line CSA storage. Do not load work centers to the schedule queue table.
To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter. To load work centers to the current schedule queue, enter ZRELOAD SCHD on the Command line and press Enter.
304
7 Maintaining Zeke
Calculating Tape Drive Usage

The Calctap option automatically tracks the number of tape drives used by a job. If Calctap=Y, the calculated value is displayed on the EMR with an asterisk (*), indicating it is an Zeke-calculated value. A value without an asterisk indicates that it is a user-assigned value. Zeke keeps a running count of all tape mounts for a job, not just the tape drives. For example, if a job mounts 2 tapes in the same step or 1 tape per step in a 2-step job, the calculated tape value is 2. Zeke does not recognize that the tape mounts are probably done on 1 drive. If you need a better way to handle this situation, use logical resources.
Note:
If Dispsel=N, then Calctap=Y is ignored.
To deactivate automatic calculation of tape drive usage

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Calctap field. Enter N to deactivate tracking and recording the number of tape drives used by a job.
Note:
2 3
If the Tapes field on the EMR is specified, Zeke requires that many tape drives be available before it will dispatch a job. 4 To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
305
Checking the Dispatch Queue

This option specifies when Zeke will check the dispatch queue.
To specify when to check the dispatch queue

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Eojwake field. Enter the code indicating whether to check the dispatch queue for batch jobs at EOJ. Code
Y N
2 3
Meaning
(Default.) Zeke checks the dispatch queue at EOJ of each job. Zeke checks the dispatch queue every 60 seconds. This value may delay dispatch of an event for up to one minute.
To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
Maintaining the Job Restart Facility

This option specifies whether a restart facility (like Zebb) is used.
To specify the restart facility

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Jobrst field. In the Jobrst field, enter the code, in upper case, indicating which type of restart facility (if any) is used. Code
blank ZEBB CA-11
2 3
Meaning
(Default.) No restart facility ASG-Zebb Restart facility from Computer Associates
4
306
To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
7 Maintaining Zeke
Maintaining Networking Options

The following generation options are related to networking.
Posid Specifies whether to assign a unique POSID (positive event ID) to each Zeke job event. The job is tracked by its jobname and assigned POSID until the job is done. Note: All Zeke systems sharing the same Zeke database must have the same value for Posid. Posidend Specifies whether Posid information is placed at the beginning or end of Zeke-controlled jobs. Specifies the Zeke logical Netregid (network registration ID), which is used to identify the current Zeke system.
Netregid
Caution! You must cycle Zeke if you update the Posid or Netregid generation options.
To activate the networking options

1 Access the Option System Directory screen in edit mode. as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the generation option you want to update. In the Posid field, enter the code indicating whether Zeke will assign a unique ID to each Zeke-controlled job event. Code
Y
2 3
Meaning
(Default.) Assign a unique POSID (positive event ID) to each Zeke job event. The job is tracked by its jobname and assigned POSID until the job is done. If Posid=YES, Zeke inserts an IEFBR14 step with the POSID information either after the job card or as the last step in each Zeke-controlled job event. For example:
//* THE ZEKECTL STEP IS INSERTED BY ZEKE. //ZEKECTL EXEC PGM=IEFBR14,COND=ONLY,PARM=(A913EC42,199915C,00000012 //A9BD957F,MEDADVLP,LDVLP,DVLPZEKE)
The placement of the POSID information is determined by the Posidend generation option.
307
Code
Meaning
Note: For multiple event versions, the version number is passed to the submitting system as part of the POSID information. If the submitting system also supports multiple event versions, the version number enables the dispatch system to correctly identify the associated SQR. Note: Zeke does not support multiple jobs per event, and when Posid=YES, only the first job of an event is considered a Zeke job. All other jobs in the same event are considered non-Zeke jobs. Therefore, each job should be placed in a separate event.
Do not assign a unique ID and tracks jobs by job name only. Note: A POSID cannot be used with JCL sources of CMS or JCLMAN. If using either of these services, set Posid=NO or specify Control=NO for each event when submitting from these sources.
Note: To override the Posid option for a specific event, use the Control field on the EMR screen. (When Control=NO, Zeke does not recognize the event as Zeke-controlled, and marks the job as EOJ at dispatch.)
If Posid=Y, in the Posidend field, enter the code indicating where the POSID information is placed in the job. Code
Y N
Meaning
POSID is placed at the end of the job, as the last step (Default.) POSID is placed at the start of the job, as the first step
For most jobs, the POSID is acceptable in either location. But there are cases in which one location might be preferable over the other. For example, if a job has the INCLUDE statement immediately following the job card, and the included member has any JCL statements that must precede the first step (JOBLIB, for example) the job will fail if Posidend=NO. If a job has in-stream data (SYSIN DD *) containing an imbedded job, the job will fail if Posidend=YES.
308
7 Maintaining Zeke
If a remote job is dispatched to another Zeke system via DMS, the Posidend generation option on the execution system governs POSID placement. If a remote job is dispatched to another system through NJE, the dispatching Zekes Posidend generation option governs POSID placement. 5 In the Netregid field, enter the Zeke unique DMS logical registration ID. Remote events dispatched by other Zeke systems to be monitored by this Zeke should specify this Netregid in the remote events Target field. Cycle Zeke if you have updated the Posid and/or Netregid generation options.
Maintaining Inter-product Communication

Zeke can communicate with other ASG products (such as Zebb) via API interfaces. You can control whether EMR messages are enabled or suppressed.
To enable communication with other ASG products via APIs

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Zprdcom field. In the Zprdcom field, enter the code indicating whether to activate inter-product communication. Valid values are: Code
Y
2 3
Meaning
Default. Activate product-to-product communication. Added or deleted events in Zeke will be reflected in Zebb. A COPY or COPYALL performed in Zeke will also be reflected in Zebb. Note: When ZPRDCOM=Y, the Zebb load library must be in the Zeke started task procedure. The library must also be in the JCL for any Zeke batch utilities and online users (CICS, TSO, etc.) who can add or delete events.
Do not activate product-to-product communications.
Cycle Zeke (ZKILL COLD or ZKILL TRACK) to activate the updated option.
309
To suppress inter-product messages

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Zprdsemr field. In the Zprdsemr field, enter the code indicating whether to suppress inter-product EMR messages. Valid values are: Code
Y
2 3
Meaning
Prevent messages regarding EMR changes from being sent to other products, such as Zebb; send SQR messages only. Default. Allow both EMR and SQR messages to be sent. Changes to Zprdsemr require a ZRELOAD GENOPT command to become effective.
Note:
For this option to be effective, the Zprdcom generation option must be set to Y. 4 To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
310
7 Maintaining Zeke
Using Shared Databases

The MultSys generation option indicates whether the database is shared by more than one machine (real or virtual). The database cannot be shared with previous versions of Zeke. Caution! You must cycle Zeke COLD if you update the MultSys generation option. If more than one system is sharing the same Zeke database, the following generation options must be set to the same values for each Zeke system sharing the database:

Posid Posidend Trigdt Trigjob Wktrgdn
To use shared databases

1 Access the Option System Directory screen in Edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Multsys field. Enter the code indicating whether the database is shared by more than one machine. Code
Y N
2 3
Meaning
Default. Database is shared by more than one machine. Database is not shared. This reduces unnecessary I/O.
Cycle Zeke COLD to activate the updated option.
311
Dispatching Events After Zeke Start-up

This procedure is used to specify whether events are dispatched after Zeke start-up. We recommend you do not place Zeke on hold with Oprhold=Y for start-up. Issuing the command ZRELOAD GENOPT also places Zeke on hold if Oprhold=Y.
To dispatch events after Zeke start-up

1 Access the Option System Directory screen in edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the Oprhold field. Ensure that the code equals N (default) to have the Zeke ready to dispatch events after start-up.
Note:
2 3
When the value is set to Y, events cannot be dispatched. Issue the command ZREL SYSTEM to release Zeke. 4 To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.
Building EDB Indexes

Zeke provides the following options for building EDB indexes:
DSPIndex For ESA-capable dataspaces only; this option is used to specify whether you want Zeke to build a full EDB index for each event (maximum size = 2 gigabytes). Setting this option to Y is recommended for large databases because it: Improves ZADD command processing Improves online browsing and retrieval of jobs Enables the PATH, PREDECESSOR, and SUCCESSOR functions from the EMR EDBindex Specifies whether you want Zeke to build a reduced version of the EDB index in core. This requires approximately 20 bytes of above-the-line CSA storage for every event in the database. Setting this option to Y results in improved speed and efficiency of ZADD command processing.
Caution! If you update either of these generation options, you must cycle Zeke.
312
7 Maintaining Zeke
To set the options for building EDB indexes

1 Access the Option System Directory screen in edit mode as instructed in Accessing Generation Options on page 286. Press F8 to scroll to the field you want to update. In the DSPIndex field, enter the code indicating whether to build a full EDB index for each event. Code
Y N
2 3
Meaning
Build a full EDB index for each event (Default.) Do not build a full EDB index
In the EDBindex field, enter the code indicating whether to build a reduced version of the EDB index in core. Code
Y N Note:
Meaning
(Default.) Build a reduced version of the EDB index in core Do not build a reduced version of the EDB index in core
If both the DSPIndex and EDBindex generation options are set to Y, the DSPIndex option overrides EDBindex. 5 Cycle Zeke (using ZKILL COLD or ZKILL TRACK) if you have changed either of these options.
313
Obtaining Operating Passwords

Zeke requires a password for each CPU serial number it operates on. The password is provided by ASG and authorizes Zeke to operate on a specific CPU model and serial number. A different password is required for a system operating under VM than is required for that same system running native on a CPU. The Zeke database holds up to 20 operating passwords. Zeke operates on a system if any of the 20 passwords in the database is the required password. Zeke will run up to 45 days without a password. Each time Zeke is started without a new password, a console message is issued indicating the number of days that Zeke has left to operate. If you replace the CPU, you must contact ASG for a new operating password. You can update the password using either the Zeke batch utility program or the online, as in the following procedure.
To obtain a new operating password

1 2 Verify that you have a signed License Agreement. Obtain the following information:

Company name, address, telephone, and FAX number Contact name Operating system Product release number Real CPU model and serial number
Virtual/Guest machine model and serial number

Note:
The CPU model is the type of machine, such as 4341, 4381, etc. The CPU serial number is the 6-character serial number of the machine. For guest VM systems, the serial number is the 6-character serial number of the virtual machine located in the VM directory. 3 4 5
314
Contact ASG Customer Support. After you receive your new password, log on to the Zeke online facility. From the Zeke Primary Menu, enter 4.2 on the Option line.
7 Maintaining Zeke
The Operating Password Information screen is displayed.

ASG-Zeke Command ===> Operating Password Information BROWSE
Primary Commands:
BROWSE
EDIT
Zeke Operating Passwords Pass 1: Pass 5: Pass 9: Pass 13: Pass 17: 9OF9K3R4 Pass 2: XKVUHXKS Pass 6: Pass 10: Pass 14: Pass 18: Pass 3: Pass 7: Pass 11: Pass 15: Pass 19: Pass 4: Pass 8: Pass 12: Pass 16: Pass 20:
The Zeke operating passwords shown on this display screen are those that allow Zeke to operate on a particular CPU serial number. These passwords are obtained from Allen Systems Group, Inc. for each CPU on which Zeke is to operate. These passwords change only when the CPU on which Zeke is operating changes.
6 7
Enter EDIT on the Command line and press Enter. Enter the new password in the next consecutive Pass field and press Enter.
Note:
The operating password must be in the Zeke database at all times.
315
Changing ISPF Color Scheme

Zeke allows you to control the colors that display on your ISPF online screens. The color and attributes you choose only affect your logon ID and remain in place until you change them again. The command INIT resets the colors back to the default values.
To change the colors on your Zeke ISPF screens

1 From the Zeke Primary Menu, enter option C.1 and press Enter. The User Color Select Screen is displayed.
ASG-Zeke Command ==> Primary Commands: Description Screen Title Field and Column Heading Normal Text Accented Text Normal Output Data Accented Output Text Normal Input Data Accented Input Data Input Field in Error Warning Field Exception Field User Color Select Screen
INIT SAVE Color ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________ Hilite ________ ________
________ ________ ________ ________ ________ ________ ________
Colors: Red, Blue, Green, Yellow, White, Pink, Turq Hilite Keywords: Reverse, Uscore, Blink, or leave blank
Decide the type of data you want to change. The following is a description of each type. Data Type
Screen Title Field and Column
Description
The first line of the screen. Labels that identify the fields. Field names and Heading column headings are treated the same, whether the fields are arranged in a column or placed next to the field name that applies to them. Descriptive or narrative text that usually explains or introduces other information displayed on the screen. For example, in the phrase D - Delete line, Delete line, which is the explanation, is normal text, while D, which is the entry, is accented.
Normal Text
316
7 Maintaining Zeke
Data Type
Accented Text
Description
Descriptive or narrative text that is highlighted for emphasis, such as the line command letter to enter in the Select field. For example, in the phrase D - Delete line, D, which is the entry, is accented. Displayed information that has previously been entered or has been calculated by the system. Displayed information that has previously been entered or has been calculated by the system, and has been highlighted for emphasis. Fields available for entry. Fields available for entry; highlighted for emphasis. Not used at this time. Not used at this time. Not used at this time.
Normal Output Data
Accented Output Text
Normal Input Data Accented Input Data Input Field in Error Warning Field Exception Field
3 4 5
In the Color field, enter the first letter of the color you want. In the Hilite field, enter the first letter of the attribute you want. Enter SAVE on the Command line and press Enter.
317
Using the Audit Facility

The audit log facility tracks Zeke database activity and logs the information in the Audit Log database. You decide what types of activity you want to audit. Actions you can log include the following:

Issued Zeke operator commands Changes to any of the following: Events status (scheduled, active, EOJ, etc.) Zeke variable record Event record Internal security class record Calendar record External security class definition record Zeke generation option Your company name or address Internal security operator record Password Partition definition Pool record Resource definition record SQR
Whenever the item you select is updated, the update is automatically recorded on an audit log. The records created by Audit can be used for reporting updates to the respective databases. You can generate reports to view the logged information. Refer to your ASG-OASIS for z/OS Reference Guide for more information on Audit reporting. You must set the OASIS option ZEKEADT for the number of Zeke Audit logs and allocate the datasets for the Audit logs before any activity will be logged. Refer to your ASG-OASIS for z/OS Reference Guide for information on the OASIS00 options.
318
7 Maintaining Zeke
To select the types of activity to log for Audit

1 From the Zeke Primary Menu, enter 4.7 and press Enter. The Audit Log Options screen is displayed.
ASG-Zeke Command ===> Primary Commands: BROWSE Audit Log Options System: EDIT BROWSE
System: ******** Job Execution Flow: Y Zeke Command: Y Zeke Variable: Y Event Master Record: Y Security Class: Y Calendar: Y External-Security Class Def: Y Genopt: Y Name/Address: Y Security Operator: Y Password: Y Partition/Initiator: Y Pool: Y Resource Definition: Y Schedule Queue Record: Y
Display the audit log for a specific system Define or update the audit log for a single system
Action
Enter BROWSE on the Command line and the system name in the System field and press Enter. Enter EDIT on the Command line and the system name in the System field and press Enter. The Audit Log Options screen is re-displayed.
Note:
The system must be added before you can set the audit log options for it. See Accessing Generation Options on page 286 for information on adding a system. 3 4 Enter Y in a field to activate auditing of that area. Each field defaults to N. Re-cycle both Zeke and OASIS for the changes to go into effect.
319
Database Maintenance
Database maintenance can be performed when you want to:

Allocate and catalog datasets Backup the database Move or enlarge a database Recover from a hardware failure Recover the contents of a destroyed database Run Zeke and use electronic vaulting
Note:
We recommend you use the BACKUP command in the Zeke utility program to back up your database at least once a day.
Creating the Zeke Databases (Primary and Vault)

The dataset name used to create the Zeke database has the DD name ZEKENEW, and the dataset name to maintain and access the Zeke database has the DD name ZEKECAT. The different names prevent the accidental destruction of the database by the CREATE function of the utility program. Since the Zeke batch program is independent of the operating system, it requires that OASIS be active. Special provisions have been made to allow OASIS to be activated without Zeke being active. This is a normal condition during the process of installing Zeke.
Note:
This procedure must be performed before using Zeke for the first time.
To initialize and create the Zeke databases

1 Start the OASIS started task, using the following syntax:
START procname,S=subsys,OASIS='(aa,bb)'
where:
procname = Name of the OASIS start-up procedure. subsys (aa,bb) 320 = OASIS subsystem name. = OASISxx options member name suffix and console option.
7 Maintaining Zeke
Note:
If the start-up procedure provides appropriate default values for the S and OASIS symbolic parameters, you can omit those parameters from the START command. 2 To create the primary database only, run the CREATE function using a jobstream similar to the following sample. This job allocates and catalogs the dataset.
//ZFRMT //ZALLOC //ZNEW // //* //ZUTL //ZEKENEW //ZEKECAT //SYSIN CREATE /*
JOB EXEC DD
,MSGLEVEL=(1,1),CLASS=A PGM=IEFBR14 DSN=ZEKE.DATABASE,DISP=(NEW,CATLG), UNIT=SYSDA,VOL=SER=PERMVL,SPACE=(CYL,(10),,CONTIG) ZEKEUTL,PARM=SUBSYS=ZDEV DSN=ZEKE.DATABASE,DISP=OLD DSN=ZEKE.DATABASE,DISP=OLD *
EXEC DD DD DD
For electronic vaulting, run the CREATE function using a jobstream similar to the following sample.
321
This job creates both the primary Zeke database and the Zeke vault database for electronic vaulting.
//ZALLOC //ZNEW // //ZVAULT // //ZUTLP //ZEKENEW //ZEKECAT //SYSIN CREATE /* //ZUTLV //ZEKENEW //ZEKECAT //SYSIN CREATE /*
EXEC DD DD EXEC DD DD DD *
PGM=IEFBR14 DSN=ZEKE.PRIMARY.DATABASE,DISP=(NEW,CATLG), UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG) DSN=ZEKE.VAULT.DATABASE,DISP=(NEW,CATLG), UNIT=XXXX,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG) ZEKEUTL,PARM=SUBSYS=ZDEV DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
EXEC DD DD DD *
ZEKEUTL,PARM=SUBSYS=ZDEV DSN=ZEKE.VAULT.DATABASE,DISP=SHR DSN=ZEKE.VAULT.DATABASE,DISP=SHR
Start Zeke with the ZEKECAT DD pointing to the primary database and the ZEKEVLT DD pointing to the vault dataset.
322
7 Maintaining Zeke
Backing Up the Zeke Database

This procedure explains how to back up a Zeke database to a tape or disk file. The BACKUP command copies the contents of the Zeke database in case it must be restored. Use the BACKUP command to back up your database at least once a day. ASG recommends backing up the database prior to each scheduling run. The database can be copied in two formats. Format
Physical Logical
Description
Copy on tape is an exact copy of the database on disk. Copy follows the pointers to the different types of database records and groups all the elements of an event together. Multiple logical backups can be merged into one database. Refer to your ASG-Zeke for z/OS Reference Guide for more information on restoring a database backup.
Note:
The Zeke database is not a normal sequential file and most backup/copy utilities do not perform properly when used with the Zeke database. Only use the Zeke BACKUP and RESTORE functions. The Zeke database BACKUP DD name is ZEKEBK. In the ZEKEUTL jobstream, enter the Zeke backup file dataset name. This is a sequential file; it does not matter how you allocate this file (e.g., 80x80 or 512x512) because when the Zeke backup process writes to the file, it will alter the LRECL and block size of the file as needed. Use the parameter DATASPACE with the BACKUP batch utility to improve back up processing performance.
To back up the Zeke database

Run a job to back up the Zeke database to tape. The following JCL is a sample job:
//ZEKEBKUP JOB ,MSGLEVEL=(1,1),CLASS=A //ZBK EXEC ZEKEUTL,PARM=SUBSYS=ZDEV //ZEKEBK DD DSN=ZEKE.BACKUP,DISP=(NEW,KEEP), // VOL=(RETAIN,SER=ZEKETP),UNIT=TAPE,LABEL=(1,SL) //SYSIN DD * BACKUP DISK DATASPACE /*
323
Note:
The Zeke database is enqueued for the duration of the physical backup. We recommend scheduling the backup during the period that has the least amount of CPU activity.
Restoring the Zeke Database

This procedure describes how to restore a Zeke database from backup. This procedure uses the BACKUP, CREATE, and RESTORE functions. You can use this procedure to recover the contents of a destroyed database and to move and/or enlarge the database. The file must have been produced by the utility program BACKUP function.
Note:
If a Zeke database containing SQRs that were downloaded to Zeke Agent is restored from a backup, either the RESTORE NOSCHED option should be used, or the job records should be removed from the Zeke Agent that is maintaining copies of the SQRs. Caution! Do not use the RESTORE function to restore an active database. Refer to your ASG-Zeke for z/OS Reference Guide for more information on the BACKUP, CREATE, and RESTORE functions. Before you perform this procedure, ensure that you allocate contiguous space in cylinders for the new Zeke database dataset (no secondary extents). Allocate more space if you are enlarging the database.
To restore the Zeke database

1 Run a job to backup the Zeke database. The following JCL is a sample for backing up the database to tape:
//ZEKEBKUP //ZBK //ZEKEBK // // // //SYSIN BACKUP /*
JOB EXEC DD
DD
,MSGLEVEL=(1,1),CLASS=A ZEKEUTL,PARM=SUBSYS=ZDEV DSN=ZEKE.BACKUP, DISP=(NEW,KEEP), VOL=(,RETAIN,SER=ZEKETP), UNIT=TAPE,LABEL=(1,SL) *
Terminate Zeke by issuing the ZKILL COLD command. (Do not use the ZKILL WARM or ZKILL TRACK command.)
324
7 Maintaining Zeke
Terminate any other active Zeke systems sharing the database. Caution! Do not use the OASIS STOP command.
4 5
Terminate any other OASIS-supported products sharing this same subsystem. Terminate OASIS using the XKILL command.
Note:
Ensure that all products have been terminated before issuing the OASIS XKILL command. 6 Allocate a new Zeke database and rename the old database as a precautionary measure. Restart OASIS. OASIS becomes active without activating Zeke. Run a Zeke utility job using the CREATE control statement to allocate a new Zeke database. ZEKENEW and ZEKECAT must both point to the new database. The following is a sample of the database CREATE jobstream:
7 8
//ZEKECRET //ZUTL //ZEKENEW // // // //SYSIN CREATE /*
JOB EXEC DD
DD
,MSGLEVEL=(1,1),CLASS=A ZEKEUTL,PARM=SUBSYS=ZDEV DSN=new database name, DISP=(NEW,CATLG),UNIT=SYSDA, VOL=SER=ZEKEVL, SPACE=(CYL,(10),,CONTIG) *
Note:
The message CATALOG INITIALIZATION COMPLETE is displayed when the job is complete. 9 Perform a logical restore. The following is sample JCL to restore over an existing database; however, you must change the dataset names to reflect the actual ones in the following DD statements:

ZEKECAT DD = new enlarged database name ZEKENEW DD = new enlarged database name ZEKERS DD = backup dataset name
325
//ZEKEREST JOB ,MSGLEVEL=(1,1),CLASS=A //ZRS EXEC ZEKEUTL,PARM=SUBSYS=ZDEV //ZEKECAT DD DISP=SHR,DSN=new enlarged database name //ZEKENEW DD DISP=SHR,DSN=new enlarged database name //ZEKERS DD DSN=last Zeke backup name,DISP=OLD, // VOL=SER=ZEKETP,UNIT=TAPE,LABEL=(1,SL) //SYSIN DD * RESTORE LOGICAL MESSAGE NEWCATLG /*
Note:
The RESTORE function builds the Zeke database specified in the ZEKENEW DD statement. 10 Edit the started task procedure and change the ZEKECAT DD statement to point to the new database, if applicable. If Zeke vaulting is being used, pre-allocate the vault database to be contiguous and have the same attributes (size, cylinder boundary, device type) as the new database. Copy (IEBGENER) the Zeke database to the Zeke vault dataset. ASG recommends that you cycle OASIS at this point. Start Zeke.
11
12 13
Moving the Vault Database

At times, it may be necessary to relocate the vault database to a new DASD volume. Zeke does not initialize if the vault database is pointing to a different primary database. This prevents accidental initialization with the wrong dataset and getting the vault out of sync with the primary database (especially if other systems are running). If it becomes necessary to relocate the vault database to a new DASD volume, you must force Zeke to use this new vault volume. To do so, use one of the following procedures.
Moving the vault databaserecommended procedure

1 Create the new vault database as instructed in Creating the Zeke Databases (Primary and Vault) on page 320. Using the ZEKEUTL utility function, disable the old vault by specifying VAULT DISABLE in the SYSIN (ZEKEVLT DD points to the original vault DSN). This clears the vault dataset name and volume information in the primary database.
326
7 Maintaining Zeke
Terminate all active Zekes sharing this primary database/vault database pair (ZKILL COLD command). Restart your Zeke with the ZEKEVLT DD pointing to the new vault DSN.
The first Zeke that is started up initializes the new vault dataset from the primary database and writes the new dataset name and volume information to the primary database.
Moving the vault databaseemergency procedure

1 Create the new vault database as instructed in Creating the Zeke Databases (Primary and Vault) on page 320. Enter the ZDISABLE VAULT operator command on any Zeke system sharing the old vault dataset. Vaulting is then disabled on all systems sharing the old vault. Zeke is now running WITHOUT electronic vaulting recovery services. Schedule hourly backups of the Zeke database until you can restore electronic vaulting. Caution! Vaulting remains disabled from the time the ZDISABLE VAULT command is issued until the new vault is initialized. 4 Restore electronic vault support at the next available opportunity. To do so: a b Terminate all active Zekes sharing the database (ZKILL COLD command). Start Zeke with ZEKEVLT DD pointing to the new vault DSN.
The first Zeke that is started up initializes the new vault dataset from the primary database.
327
Recovery Using Electronic Vaulting

Electronic vaulting offers an advantage over traditional restore recovery methods because it eliminates the cost of down time for hardware failures. Zekes secondary DASD unit replicates the primary Zeke database. When a record is written to the primary Zeke database, the electronic vaulting option writes a duplicate record to the secondary database. The primary and secondary databases must have the same allocation size. For example, if a database allocates 250 contiguous cylinders for the primary Zeke database, then a second Zeke vault database must be a contiguous 250 cylinders as well. This second database should be located on a different DASD unit on a string of DASD with a different controller for disaster recovery considerations. Only use electronic vaulting if ample additional DASD is available. If there is a hardware failure that makes the Zeke database unavailable, you can recover full services with the following procedure. If you must recover more quickly than you can copy the Zeke database, you can by using the partial recovery procedure; however, you will have to bring Zeke back down at the first opportunity to complete the recovery.
Note:
We strongly recommend that you perform the full recovery procedure the first time, rather than the partial recovery.
To fully recover electronic vaulting

1 Terminate Zeke. If you want to terminate the Zeke system and place it in SMF recording mode, issue the ZKILL TRACK command. (See Continuous Job Tracking on page 331 for details). Otherwise, issue the ZKILL COLD command. If this fails, cancel Zeke. Use the OASIS batch utility to STOP ZEKE.
Note:
You may see message X00224E. This does not indicate a problem. It simply means the Zeke code has already been pulled for the subsystem. 3 Allocate a dataset of the same size and on the same device type (but not on the same volume) as the damaged database. The dataset must be in a contiguous extent. Copy (IEBGENER or FDR) the undamaged vault database to the new dataset on the same DASD device type (i.e., 3380 to 3380, 3390 to 3390).
328
7 Maintaining Zeke
Change the started task JCL so that ZEKECAT points to the newly copied database and ZEKEVLT remains pointing to the undamaged vault database. Start Zeke. Resume processing.
6 7
To partially recover electronic vaulting

1 2 Terminate Zeke by issuing the ZKILL COLD command. If this fails, cancel Zeke. Use the OASIS batch utility to STOP ZEKE.
Note:
You may see message X00224E. This does not indicate a problem. It simply means the Zeke code has already been pulled for the subsystem. 3 4 Rename the vault dataset. Change the started task JCL so that ZEKECAT points to the renamed vault database and comment out the ZEKEVLT DD. Ensure that there are no other Zeke systems currently active on the old database. (To determine whether there are Zeke systems sharing the database, use the ZD COM operator command.) Start Zeke. You will receive the console message Z0129R during start-up. This is normal. Again, ensure that there are no other Zeke systems currently active on the old database and enter NO in response to message Z0129R. Initialization will continue with the old vault database as the new primary database. If there are other active Zeke systems, enter YES in response to message Z0129R. Initialization is terminated with message Z0130E. You must first bring down other active Zekes and restart Zeke (step 5). 8 9 Resume processing. Zeke is now running without electronic vaulting recovery services. Schedule hourly backups of the Zeke database until you can restore electronic vaulting.
329
10
After you have performed the partial recovery procedure, restore electronic vault support at the next available opportunity: a Allocate a dataset of the same size and on the same device type (but not on the same volume) as the existing database. The dataset must be in a contiguous extent. Format the new dataset as a database using the batch utility CREATE function. Terminate all Zekes sharing the database by issuing the ZKILL COLD command. (To determine whether there are Zeke systems sharing the database, use the ZD COM operator command.) If this fails, cancel Zeke. Change the started task JCL by adding the ZEKEVLT DD to point to the newly created database. Start Zeke. The first Zeke system that is started initializes the vault dataset from the primary database. Resume processing.
b c
330
7 Maintaining Zeke
Continuous Job Tracking

Zeke can track relevant system and event activities during periods when both the Zeke and OASIS subsystem have been terminated. This ability is useful when you need to apply Zeke or OASIS maintenance, or recover database services by switching to a vault database. With continuous job tracking, disruption to Zeke job dispatching is minimized. When Zeke (and even OASIS) are terminated, the system activities are recorded. When Zeke is restarted, the recorded activities are played back, and the schedule is updated accordingly. Activity that can be tracked includes:

Starting of jobs, job steps, and programs Ending of jobs, job steps, and programs Datasets that are closed
During playback, Zeke will satisfy triggers and update the status for job activity that occurred while Zeke was down.
Note:
Logged system activity is not maintained across an IPL.
Terminating Zeke Using ZKILL TRACK

Use the ZKILL TRACK operator command to terminate the Zeke system and place it in SMF recording mode. Zeke issues an informational message indicating that system activity is being recorded. Termination continues as it would for a traditional ZKILL COLD, except that only the IEFUJV SMF exit is de-installed. See also the section on ZKILL in your ASG-Zeke for z/OS Reference Guide.
Z49F05I Zeke SMF Recording started Z49F01I ZEKE TERMINATION BEGINNING Z0904I ZEKE COMMAND PROCESSOR TERMINATING X00354I Program ZEKE48H (IEFUJV ) de-installed Z0505I Zeke Schedule Monitor terminating Z5H02I Zeke Remote Dependency task terminating Z5I14I Zeke Agent task terminating Z5G07I Schedule load task terminating Z5F06I Zeke Multi-System communications terminating
Caution! Do not use ZKILL TRACK under the following conditions: If Zeke will be restarted on a different database than it is currently using. If the database will be restored before Zeke is restarted. If a full schedule run will occur before Zeke is restarted. If you are upgrading to a different release of Zeke.
331
Note:
ZKILL TRACK can be used if you are upgrading to a different PTF level within the same release.
SMF Recording Mode

Limitations
The following Zeke and OASIS services are not available when Zeke is shut down using ZKILL TRACK:

Auto-replies JCL error tracking NOTDURING WHEN condition processing Zeke condition code processing. Condition code processing is suspended for any job active while Zeke is in recording mode. Condition code processing cannot resume for that job run even for steps that occur after Zeke is restarted. Zeke activities requiring DMS services, for example: Remote triggers from jobs running on Zeke but dispatched by a remote system are not sent back to the dispatcher until Zeke is restarted. Remote dependencies sent to Zeke are not satisfied. Schedule updates from a Zeke Agent that has downloaded the Zeke schedule are not communicated. However, send, store, and forward processing by Zeke Agent will send the updates when Zeke is restarted.
The following services are not available if OASIS is also terminated:

Zeke and OASIS batch utilities Report Writer
332
7 Maintaining Zeke
Database Considerations
If multiple Zeke systems share a database:
A Zeke in record mode does not make schedule updates. The other Zekes will be notified of schedule changes made as playback occurs. Only A/EOS, A/B/EOP, and DSN triggers needed by the schedule are recorded. If another Zeke adds any triggers of these types to the schedule, they are not tracked. When terminated with ZKILL TRACK, Zeke retains enough information from its internal tables to determine which SMF records will trigger an event. Zeke conserves CSA use by recording only SMF records that are pertinent. If an event is added by another Zeke, the event is not seen by the recording system until Zeke is restarted. No changes to the generation options by another system will be reflected in the recording system until Zeke is restarted.
CSA Considerations
Caution! Because Zeke SMF recording logs system activity in ECSA, ASG recommends restarting Zeke as soon as possible to minimize the storage allocated. SMF recording periodically queries the amount of unallocated ECSA remaining. Starting when only 2 MB of ECSA remains, and every 100 K thereafter, Zeke issues the following warning:
Z48R4W Zeke SMF Recording: 2.0 MB ECSA remaining Z48R5W Zeke SMF recording will halt with 1.0 MB ECSA remaining
This warning gives you the opportunity to restart Zeke before any recorded activity is discarded. If any triggers are discarded due to the ECSA limit, a start-up message indicates the number of triggers affected. When 1 MB remains, Zeke stops recording activity and issues the following message:
Z48R6E Zeke SMF recording ECSA limit reached - triggers will be discarded
If the system is in record mode for a brief period of time, little ECSA will be useda little over 1 K for each record logged. However, terminating Zeke with the TRACK option just before leaving for vacation could cause a problem. In cases where ECSA usage becomes a system constraint, a utility is provided to stop SMF recording and free all recorded records.
333
//ZEKECLR JOB (ACCT),,CLASS=A,MSGLEVEL=(1,1) //STEP1 EXEC PGM=ZEKE11M,REGION=2048K, // PARM='SUBSYS=SSSI,REPORT' //STEPLIB DD DISP=SHR,DSN=ZEKE.LINKLIB //SYSPRINT DD SYSOUT=* /* //
If the REPORT parameter is specified, a report of all the discarded triggers is printed to SYSPRINT:
Zeke SMF Triggers Discarded NAME ZEKE ZEKEAG53 JCLPREP SPTJX1A QATST01 QAUTIL STEPUSI QATST01 QATST02 QAUTIL STEPUSI QATST02 JOBNAME ZEKEAG53 ZEKEAG53 SPTJX1A SPTJX1A QATST01 QATST01 QATST01 QATST01 QATST02 QATST02 QATST02 QATST02 PROCSTEP TRIGGER EOS EOJ EOS EOJ BOJ BOP EOS EOJ BOJ BOP EOS EOJ TIME SCHED DATE EVENT 16:53:42 16:53:42 16:53:43 16:54:08 16:54:00 2007/006 000001 16:54:01 16:54:11 16:54:11 16:54:01 2007/006 000002 16:54:01 16:54:11 16:54:11 VER
00000
00000
334
7 Maintaining Zeke
Applying Maintenance
When you issue ZKILL TRACK, all Zeke modules are unloaded so that maintenance can be applied, except:

ZEKE48B ZEKE48C ZEKE48D ZEKE48F ZEKE48G
After maintenance is applied, terminate Zeke again using ZKILL COLD, then restart Zeke in order to reload these modules. If OASIS is terminated also, all OASIS modules are unloaded so that maintenance may be applied.
SMF Playback
When Zeke restarts, it initiates playback. Activity within an individual job is played back in the order it occurred. The order between different jobs is not preserved. Playback time is compressed as much as possible so that Zeke may resume its normal dispatching. Job accounting information, however, reflects the actual start time, end time, and duration of the job run. After playback is complete, various messages are issued to indicate the amount of activity and storage used during recording.
Z0140I GENOPT record A successfully loaded Z03B03I SYSGEN record ******** successfully loaded Z0401I Zeke Variable Monitor initialized Z0701I Zeke System startup successful 5.4 Z540A000 Z5G06I Schedule load task enabled Z5G01I Initial schedule load started Z0501I Zeke Schedule Monitor enabled Z0510I Zeke ... Time is now 16:26:48 X00353I Program ZEKE48H installed as an IEFUJV exit Z5F02I Zeke Multi-System communications enabled Z5H01I Zeke Remote Dependency task enabled Z0901I Zeke Command Processor enabled Z5I01I Zeke Agent Schedule Download Task Enabled Z5G03I Schedule load complete Z0502I Zeke Event dispatching enabled Z45P1I Playback of SMF records has begun Z45P6I 23 System triggers logged Z45P7I 29 Kbytes ECSA used Z45P8I 0 Kbytes used for filter tables Z45P9I 13 Kbytes saved by filter tables Z45PAI 11 triggers discarded by filter tables Z45PBI 0 triggers discarded due to ECSA limit Z45P5I Playback of SMF records is complete
335
336
Chapter 8:
Variables
8
Variables, user-defined keywords representing values, enable Zeke to automatically carry out a wide variety of specialized operations. With variables you can automate several important tasks, such as JCL modifications, job triggering, and console response handling. Topic
Zeke Variables Naming Zeke Variables Setting Zeke Variable Values Maintaining Variable Documentation OASIS Variables Naming OASIS Variables Setting OASIS Variable Values Temporary OASIS Variables System-Dependent Variables How Variables Are Used Using Variables to Trigger Events Using Variables to Control Jobstream Flow Using Variables to Restart a Job Substituting Variable Values in JCL IF Clauses On SET Statements Variable Substitution in SCOM Events
Page
338 338 338 343 347 348 349 350 351 351 352 353 354 356 359 359
337
Zeke Variables
A Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned value of either numeric or character format. Zeke supports the following types of variables:

Zeke variables OASIS variables System-dependent variables
Naming Zeke Variables

It is a good idea to name variables according to the jobstream, application, or function they are related to, because standard naming conventions help prevent questions about the purpose of a specific variable. For example, a restart variable that relates to JOBA is named $JOBASTEP. Zeke variable names can be up to 16 characters long, and the first character must be a dollar sign ($). The remaining 15 characters can be alpha or numeric.
Note:
Do not use special characters (hex value 7F or less) in variable names, because Zeke assumes that these characters are the end of the variable name during variable substitution. After the dollar sign, use only the characters 0 through 9 and A through Z.
Setting Zeke Variable Values

You do not need to define a variable before using it in JCL or a work center SET statement. They remain in the database, accessible to all systems sharing that database, until explicitly deleted. A character value for a Zeke variable can be up to 64 bytes long; a numeric value can be from -2,147,483,647 to +2,147,483,647.
338
8 Variables
Zeke variable values can be established or changed using any of the following methods:
ZEKESET SET statement. For example:
//S1 EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV //SYSPRINT DD SYSOUT=* //SYSIN DD * SET VAR $ABC EQ 'ERROR' SET VAR $XYZ EQ $XYZ + 1 /*
Refer to your ASG-Zeke for z/OS Reference Guide for more information on defining variables using SET VARIABLE.
ZSET operator command. For example:

ZSET VAR $XYZ EQ 0 ZSET VAR $OPERFLG EQ NO Variable $XYZ = 0 Variable $OPERFLG = NO
Refer to your ASG-Zeke for z/OS Reference Guide for more information on using the ZSET operator command.
Calling the subroutine ZEKEVAR. (Refer to your ASG-Zeke for z/OS Installation Guide for more information.) User programs, using a supplied subroutine. Work center events. See Work Centers on page 161. The Zeke online facilities. ISPF is shown in the following procedure.
Note:
This procedure cannot be used to define or maintain OASIS variables. To access OASIS variable maintenance, issue the OVAR primary command from any Command line in the Zeke ISPF online facility.
To define and maintain a Zeke variable

1 From the Zeke Primary Menu, enter 8 and press Enter.
339
The Variable Selection Criteria screen is displayed.

ASG-Zeke Command ===> Variable Name ===> Primary commands: ADD Enter Clear * -is ? -is BROWSE COPY DELETE DOCUMENT EDIT Variable Selection Criteria
Selection Mask in any field to be compared for selection. any field that is not to be used for selection. a prefix/suffix indicator. a wild/place holder character. * Selection Field Masks *
Variable: Type: System: Appl: GroupID: UserID: Date Range: Time Range:
C - character, N - numeric
(MM/DD/YYYY) or (DD/MM/YYYY) (HH:MM:SS)
Define a new variable
Action
Enter ADD on the Command line and the variable name in the Variable Name field. Press Enter. Go to step 3. Enter EDIT on the Command line. Enter the variable name in the Variable Name field. Press Enter. Go to step 3. Enter any information you know for any of the Selection Field Masks fields. Press Enter. The Variable Name Directory screen is displayed.
Update a variable for which you know the name
Update a variable for which you do not know the name
340
8 Variables
ASG-Zeke Command ===> Variable name ===>
Variable Name Directory
Row 1 to 6 of 6 Scroll ===> PAGE
Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit O - dOcument Variable Name Appl Grp UserID Date Time System $ED 01/30/2007 12:13:35 ZEQA $KATHYG 02/08/2007 14:53:44 ZEQA $KATHYG1 02/07/2007 16:54:40 ZEQA $KATHYG2 02/07/2007 16:54:48 ZEQA $KATHYG3 02/07/2007 16:55:57 ZEQA $STPNAME 01/20/2007 15:16:32 ZEQA ***************************** Bottom of data ******************************
Perform the steps in the Action column depending on the desired result. Desired Result
Update the variable
Action
Enter E in the unlabeled Selection field to the left of the variable you want to edit, and press Enter. Enter B in the unlabeled Selection field to the left of the variable you want to view, and press Enter. Enter D in the unlabeled Selection field to the left of the variable you want to delete, and press Enter. The Variable Name Record Functions screen is displayed. Enter DELETE on the Command line and press Enter to confirm the deletion. This procedure is complete.
View the variable value
Delete the variable
The Variable Name Record Functions screen is displayed.

ASG-Zeke Command ===> Variable Name Record Functions EDIT
Variable Name: $PAYCHECK Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT
Appl: PAYROLL GroupID: CHK Desc: STARTING CHECK NUMBER Desc2:
UserID: KAC
Curr Value: 1001 Force upper: Y Value set by: U (J=Job P=Program U=User) Name: SPTKAB Date/Time: 01/30/2007 14:39:55 System: SYSD Part/Init: TSO Prev Value: 1001 Value set by: U (J=Job P=Program U=User) Name: SPTKAB Date/Time: 01/30/2007 14:39:51 System: SYSD Part/Init: TSO
341
Optionally, enter a description of the variable in the Desc/Desc2 fields. This description appears on summary screens and is printed on reports. If you want to set the initial value of the variable, enter the value in the Curr Value field. In the Force Upper field, specify of the following codes if the Current Value includes alpha characters: Code
Y N
Meaning
Forces the Current Value string to uppercase. Keeps the case of the Current Value exactly as entered. Specify this code if you need to allow mixed-case values for variable substitution.
Note:
If the Current Value is numeric only, the Force Upper option is ignored. 7 Enter information in the following fields to group variables for report selection. Field
Appl
Description
User-assigned code to identify the application the variable is a part of. The Report Writer, Work Center Control, and Zeke operator commands use this field to sort and select variables. User-assigned code to identify the group the variable is a part of. This field can be used as a subset of the application ID.
Groupid
In the Userid field, enter a character string up to eight bytes in length. This field is used to determine which users can update the variable. Press Enter. The variable is updated.
342
8 Variables
Maintaining Variable Documentation

The Variable Maintenance facility gives you a place to maintain and store Zeke variable-related documentation, provided you have security authorization.
To access and maintain variable documentation

1 2 From the Zeke Primary Menu, enter 8 and press Enter. Access the Variable Name Directory screen, as described in To define and maintain a Zeke variable on page 339.
ASG-Zeke Command ===> Variable name ===> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit O - dOcument Variable Name Appl Grp UserID Date Time System $ED 01/30/2007 12:13:35 ZEQA $KATHYG 02/08/2007 14:53:44 ZEQA $KATHYG1 02/07/2007 16:54:40 ZEQA $KATHYG2 02/07/2007 16:54:48 ZEQA $KATHYG3 02/07/2007 16:55:57 ZEQA $STPNAME 01/20/2007 15:16:32 ZEQA ***************************** Bottom of data ****************************** Variable Name Directory Row 1 to 6 of 6 Scroll ===> PAGE
Enter the line command O to the left of the Variable Name field and press Enter. The Document Segments screen is displayed. This screen allows you to access screens where you can maintain documentation for Zeke variables.
ASG-Zeke Option ===> Primary Command: DELETE Variable: $KATHYG1 System: ZEQA User: Documentation Segments EDIT
Group:
Appl:
Documentation Record Selection Options 1 2 3 SCRATCH TEXT NOTE Scratch pad Text information Note pad information
Note:
If an asterisk (*) is displayed to the left of the documentation type, documentation already exists for the variable.
343
Enter one of the following codes on the Command line to select the type of documentation you want to work with: Desired Result
Access scratch pad documentation Access text documentation
Action
Enter 1 and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 344. Enter 2 and press Enter. Go to Maintaining Text Documentation on page 346. Enter 3 and press Enter. Go to Maintaining Scratch Pad or Note Documentation on page 344.
Access note documentation
Note:
OASIS variables are maintained through the OASIS Variable Maintenance screens. See OASIS Variables on page 347 for an overview.

You can add, browse, edit, or delete Scratch or Note documentation from the Variable option. The Scratch Pad or Note Information screens allow you to define or browse up to 10 lines of information for a variable.
Note:
Even though there are separate documentation areas for Scratch Pad and Note Information, the procedures have been combined because the screen layouts, number of lines of text, and fields displayed are identical. This screen is like a sticky note. It is used to pass notes from shift to shift, or from one department to another. The operator should always review scratch pad or note pad information before a job runs. This area can also be used for quick reference information.
344
8 Variables
To maintain scratch pad or note documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in Maintaining Variable Documentation on page 343.
ASG-Zeke Command ==> Primary Commands: BROWSE Documentation Scratch Pad ED
CANCEL
DELETE
EDIT
Line 1 PASS THIS TO 3RD SHIFT 2 3 4 5 6 7 8 9 10 Variable name: $TAPUG1 System: ZEQA Userid:
Groupid:
Appl:
To delete the scratch pad or note information, enter DELETE on the Command line and press Enter. To confirm, re-enter DELETE on the Command line and press Enter. To add or update scratch pad or note information, enter text information in the Line area. You can enter up to 60 characters per line, and up to 10 lines of text. When you have finished adding or updating information on the Scratch Pad or Note screen, press Enter to update the data.
345

You can add, browse, edit, or delete text documentation from the Variable option. This screen allows you to define a sizeable amount of information for a variable (up to approximately 450 records).
To maintain text documentation

1 Access the Text Documentation screen as instructed in Maintaining Variable Documentation on page 343.
ASG-Zeke Command ===> Text Documentation EDIT Columns 000 000 Scroll ===> PAGE
Variable: $KATHYG1 System: ZEQA User: Grup: ****** *************************** Top of Data ***************************** ==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 IF YOU NEED TO UPDATE THIS VARIABLE MORE THAN 3 TIMES PER SHIFT, (NOT 000002 PER DAY), NOTIFY THE SHIFT SUPERVISOR. THE BASE VALUE WILL NEED TO BE 000003 RECONFIGURED BASED ON NUMBER OF OCCUPIED SEATS AND AVAILABLE LINES. ****** *************************** Bottom of Data **************************
Use standard ISPF editing commands to enter text in the line area, or to the right of the column placeholder field, if there is existing text. You can enter up to 80 characters per line, and up to several hundred lines of text. Page forward to access an additional screen. When you have finished adding or updating information on the Text screen, press Enter to update the data.
346
8 Variables
OASIS Variables
OASIS variable values can be substituted in the same areas as Zeke variables (JCL, ZEKESET, SCOM, etc.), but they differ from Zeke variables in the following aspects:
OASIS variables reside in an OASIS database on DASD, and are therefore retained across system outages and IPLs. The database is accessible to all OASIS-supported applications using the same subsystem, so you can use OASIS variables to communicate information between your applications. OASIS variable values can be from zero to 255 characters in length. They can contain any displayable character in the EBCDIC character set, including leading blanks, imbedded blanks, and trailing blanks. Each OASIS variable substitution function call includes the variable name enclosed in a substitution prefix and substitution suffix. This prefix and suffix are user-definable. The default prefix is $( and the default suffix is ). For example: $(OASVAR1). OASIS has its own online for variables where you can define, edit, and view OASIS variable names and their values. The value substituted in an OASIS variable can be based on one or more of the following qualifiers. This allows for multiple values for a single variable name. (An unqualified variable has only one value associated with it.)
Schedule date Run date Job name Netregid Application ID Group ID User ID Event number Version number System name
Various types of formatting for substitution are allowed. One type of formatting allows you to substitute the entire variable value or just a portion of it. For example, you can specify to substitute only the last 2 characters of the value, or only the second word of the value. You can also pad the substituted value with extra characters. The following substitution functions can be performed on OASIS variables: Substitution Function
DATE
Description
Convert a date to a specified format and return the result.
347
Substitution Function
EXEC ITEM LEFT RIGHT SUBSTR SUBWORD UPPER VALUE
Description
Call an exec and return its return value. Return the value of a qualifier. Return the left-most positions of the string. Return the right-most positions of the string. Return a substring of the string. Return one or more specified words from the string. Return the string in upper case. Return the value of a variable whose name is obtained from the value of another variable or a nested function call.
Functions can be performed on OASIS variables using the SSS0UTV utility program. SSS0UTV can be used to create new variable value records, replace or delete existing value records, and list variable definition records and value records. The TVSET function allows you to create and set the value of a temporary OASIS variable, which remains available until your program terminates, or to override an existing OASIS variable value temporarily (that is, for the current run of the job). See Temporary OASIS Variables on page 350 for more information.
Refer to your ASG-OASIS for z/OS Reference Guide for detailed information that you need to know before using OASIS variables for the first time.
Naming OASIS Variables

OASIS variable names can be up to 64 characters long. The first character can be any of the following:

Dollar sign ($) Underscore (_) Pound sign (#) At sign (@) Any capital letter (A through Z)
The remaining characters can be any of the above characters or the digits 0 through 9. Imbedded blanks are not allowed in variable names.
348
8 Variables
Setting OASIS Variable Values

OASIS variable values are set using any of the following methods:

The SSS0UTV utility program. The OASIVAR Application Programming Interface. Refer to your ASG-OASIS for z/OS Reference Guide. The OASIS online, as shown in the following procedure.
To maintain OASIS variables

Issue the OVAR primary command from any Command line in the Zeke online facility. The OASIS Variable Maintenance screen is displayed, where you can add, edit, delete, or browse variable definition records and variable value records.
OASIS Variable Maintenance OPTION ===> 12/20/00 Primary Commands: ADD ADDDEF BROWSE BRWDEF DELDEF DELETE EDIT EDITDEF LIST Variable: ________________________________________________________________ Variable qualifiers: Job name: ________ Schedule date: _______ Run date: _______ Netregid: ________ Application name: ________ Group name: ___ Userid: ________ Event number: _________ Version number: _____ System: ________ *** Press PF1/PF13 or type "?" in field to see mininum product levels
349
Temporary OASIS Variables

The TVSET function, unique to OASIS variables, allows you to:
Create and set the value of a temporary OASIS variable, which remains available until your program terminates. Override an existing OASIS variable value temporarily.
For Zeke-dispatched jobs, you can use TVSET if you want to override an existing variable value without changing the variable itself.
Syntax
//*TVSET {variable name} {new value}
Caution! Do not use an equal sign (=) between the variable name and value. For example, to change the value of the OASIS variable ABC to NEW_VALUE without modifying the variable value record, add the following line to the JCL:
//*TVSET ABC NEW_VALUE
The new value overrides the previous value anywhere the variable appears, and affects only the current run of the job. The TVSET command does not appear in the resulting output JCL. When the //*TVSET statement is used in JCL, it appears in the output stream when run, and it is checked for syntax errors. If an error is found, message Z0683E is issued to the JESMSGLG and SYSLOG of the Zeke started task for each //*TVSET line found to be in error. The error message contains the input line number in error and the event and version numbers associated with the EMR. Message Z0685E is displayed on the console for the event. When the JCL is retrieved, the //*TVSET statement is included. The TVSET syntax is not checked for errors when it is retrieved; the TVSET syntax is checked (and if applicable, the above error messages are issued) when the retrieved JCL is run.
350
8 Variables
System-Dependent Variables
System-dependent variables allow you to run the same job control statement and use the same variables on different systems while keeping the variables separate. To define a system-dependent variable, use three dollar signs ($$$) as the first three characters of the variable name (for example, $$$NAME). Zeke replaces the third dollar sign with the 1-character ID of the dispatching CPU. The following are examples of system-dependent variables: Job Control Variable Name
FL$$$PRFLGG $$$OPER1 $$$VAR01 $$$TEST Note:
CPUID
A C B A
Actual Name Used

$$APRFLG $$COPER1 $$BVAR01 $$ATEST
System-dependent variables cannot be used with Zeke operator commands (such as ZSET) because operator commands are processed only by the CPU on which they are entered. To use a system-dependent variable with an operator command, replace the third dollar sign with the CPUID. For example, $$AFLAG instead of $$$FLAG. System-dependent variables can be used in ZEKESET statements and by programs that call the ZEKEVAR subroutine.
How Variables Are Used

Zeke and OASIS variables are powerful job management tools. They perform the following functions:

Trigger jobs (Zeke variables only) Prevent jobs from being dispatched Control jobstream flows by selecting the steps to be processed at execution time Simplify jobstream recovery and restart Provide automatic restart at the cancelled step Substitute values in OS and JES JCL statements at submission time Pass information from one job, job step, or program to another
351
Document cancellation reason Establish relationships between jobs
Using Variables to Trigger Events

A dependency is a condition that must exist before an event can be dispatched. Dependencies include a job that must process, a dataset that must close, or a variable that must be set to a specific value. See WHEN Conditions on page 135 for more information. Using a variable value as a dependency enables you to trigger or prevent a job from occurring through job streams and programs. Additionally, this feature enables you to trigger jobs through external actions, such as the receipt of data for an application. In this case, an event can be established with a variable dependency that can be satisfied by the ZSET operator command. For example, jobstream PRUPDT is a job with a dependency condition. The dependency states that variable $PRDATA1 should have a value of YES. The WHEN condition to establish this job is as follows:
WHEN (VAR $PRDATA1 EQ YES)
Also, this jobstream is not processed until the job PREDIT is processed with no errors. A situation determined outside of the computer room. When word is received that the results of job PREDIT are satisfactory, and job PRUPDT can be processed, the operator simply informs Zeke by entering the command:
ZSET VAR $PRDATA1 EQ YES
This command satisfies the job dependency for PRUPDT, and if the Early/Schedule time has been reached, the event is moved to the dispatch queue. The event is dispatched from the dispatch queue when all resource requirements are available. Additionally, the variable $PRDATA1 needs to be reset to NO when PRUPDT is complete. This is accomplished by a ZEKESET program SET statement after the last step in the jobstream. The variable $PRDATA1 could be set to YES in several ways:

Using a ZEKESET program SET statement. Using the subroutine ZEKEVAR. This facility enables programs to make decisions that can affect the dispatching of subsequent events. Using the Zeke online work center facility.
Note:
OASIS variables cannot be used to trigger jobs.

352
8 Variables
Using Variables to Control Jobstream Flow

Variables can control the flow of OS job streams. As a simple example, the following jobstream consists of four steps processed daily, and an additional job step to be processed only when the second step creates a special file of exception records.
//ARUPDT JOB ,AR.DEPT,MSGLEVEL=(1,1),CLASS=X //INIT EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV //SYSPRINT DD SYSOUT=A //SYSIN DD * SET VAR $$$ARFLG EQ NO Begin with variable=NO /* //ARSTP1 EXEC PGM=PROG1 Step 1 //INFILE DD DSN=AR.MASTER.TAPE,DISP=OLD,UNIT=TAPE, // VOL=SER=ARTAPE,LABEL=(1,SL) //SYSPRINT DD SYSOUT=A //* //ARSTP2 EXEC PGM=PROG2 Step 2 //OUTFILE DD DSN=AR,MASTER.TAPE,DISP=(NEW,KEEP),UNIT=TAPE, // VOL=SER=ARTAPE,LABEL=(1,SL) //EXCPFILE DD DSN=AR.EXCPS,DISP=(NEW,CATLG),UNIT=SYSDA, // SPACE=(132,(2000,500)) //SYSPRINT DD SYSOUT=A //ARSTP3 EXEC PGM=PROG3 Step 3 //RPTS DD DSN=&&AR.REPORTS,UNIT=SYSDA,DISP=(NEW,PASS), // SPACE=(132,(2000,500)) //SYSPRINT DD SYSOUT=A //* //ARSTP4 //TAPEIN //RPTSIN EXEC DD DD PGM=PROG4 Step 4 DSN=SOME.DATASET,DISP=OLD,UNIT=TAPE DSN=&&AR.REPORTS,DISP=(OLD,DELETE),UNIT=SYSDA
//SYSPRINT DD SYSOUT=A //* //CHKEXCP EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV //SYSPRINT DD SYSOUT=A //SYSIN DD * SET CONDCODE 20 IF $$$ARFLG NE YES Bypass Step 5 if variable=NO /* //ARSTP5 EXEC PGM=PROG5,COND=(0,NE,CHKEXCP) Step 5 //EXCPFILE DD DSN=AR.EXCPS,DISP=(OLD,DELETE) //SYSPRINT DD SYSOUT=A //
In this jobstream:
An system-dependent variable called $$$ARFLG is set to NO early in the jobstream, so that Step 5 is normally skipped. The subroutine ZEKEVAR updates the variable value of $$$ARFLG if Step 2 (program PROG2) creates the special exceptions file that needs to be processed.
353
If the variable is still set to NO, the CHKEXCP step terminates with a condition code of 20. Otherwise, the condition code is zero. The MVS JCL parameter COND on the EXEC statement for Step 5 tests the condition code of the previous step. If the condition code is 20, Step 5 is bypassed.
Using Variables to Restart a Job

Variables can be used to restart a job at a cancelled step. A variable can save the name of the last job step processed in a jobstream, so that if any step abends, the job can be restarted at that step. This facility works best when used with an MVS COND=ONLY step. The step which specifies COND=ONLY is executed if any previous step in the jobstream abends. If no abend occurs, the OS bypasses the step. If an abend occurs, the COND=ONLY step sets up the information for the restart. For example, in the following jobstream, the variable $CL01P043STEP saves the restart step name.
//CL01P043 JOB ,MSGLEVEL=(1,1),RESTART=$CL01P043STEP ... JCL FOR STEP 1 /* ... JCL FOR STEP 2 /* ... JCL FOR STEP 3 Last normal step //EOF EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV Normal end of job reached here //SYSPRINT DD //SYSIN DD * SET VAR $CL01P043STEP EQ * For next time job is run /* //ABEND EXEC PGM=ZEKESET,COND=ONLY EXEC ONLY IF ABEND OCCURRED //SYSPRINT DD //SYSIN DD * Come here only if job abends SET VAR $CL01P043STEP EQ LASTSTEP Set VAR to prior step * (At this point, you can set a variable to a value that dispatches a recovery job) /* // END OF JOB
The JOB statement contains an OS restart parameter. This starts job processing at the named step. Since the parameter is a Zeke variable, Zeke supplies the value through the internal reader when the job is submitted. If the job completes normally, ZEKESET sets the variable to * (asterisk). z/OS starts the jobstream at the first job step the next time it is run.
354
8 Variables
The last job step specifies COND=ONLY on its execute statement. If the job completes normally, z/OS bypasses this step. If an abend occurs, this statement sets the variable to the name of the step which abended. When this job is restarted by the ZREFRESH operator command, the first step executed is the one which previously failed (the value of $CL01P043STEP). No external action is necessary. To restart at a step other than the one that abends, enter the ZSET command to set $CL01P043STEP to the desired restart step name. For example, say that the above jobstream abends in step CLSTP3, but the jobstream needs to be restarted at step CLSTP2 for some reason. Enter the following command to begin processing at CLSTP2 the next time it runs:
ZSET VAR $CL01P043STEP EQ CLSTP2
The OS does not execute the COND=ONLY step, even though the job did not run properly, in any of the following conditions:

A JCL error occurs (i.e., a dataset is missing) The operator cancels the job (i.e., system S222 abend) A complete system failure (i.e., power failure)
If these conditions become a major factor in system reliability, use the following alternate restart technique. Execute the ZEKESET program between each of the normal job steps in a jobstream. The restart variable can be set to the name of the step about to be executed (the step following the ZEKESET step). This ensures that the variable is always set to the step to be restarted, even on full system failures.
355
Substituting Variable Values in JCL

Zeke and OASIS variables can be used in both JCL and non-JCL statements submitted to the system by Zeke. When the generation option Subdata=YES, Zeke scans all statements as the jobstream is submitted through JES. If a variable is found, it is replaced with its current variable value. Variable substitution is performed while Zeke is writing JCL statements to the JES internal reader. The variables must contain the proper values at job dispatch time. Because of the timing, it is not valid to set variable values in the following ways:
In one job step and expect the new value to be substituted into a subsequent statement in the same job. The substitution for that statement was already done before the job started with the value of the variable at that time. For statements in procedures that are called from the dispatched job. Zeke does not see the actual statements in the procedure, only the EXEC statement.
To use the variable values on statements in a procedure, code the Zeke or OASIS variable as the value of a parameter on the EXEC statement. Zeke substitutes the variable value into the EXEC statement and the procedure can substitute this value into the statements in the procedure. For example, EXEC PROC=TEST1, PARM1=$VAR. During variable substitution, trailing spaces are truncated from character values to a maximum of 1 trailing space, and leading zeros are truncated from numeric values, leaving 1 zero if the numeric value is zero.
Note:
When variable substitution occurs on JCL statements with line numbers in columns 72 through 80, the line numbers may be shifted to the left if the variable value substituted in for the variable name is shorter than the variable name itself. Contact ASG Customer Support for assistance.
356
8 Variables
The following are examples of variable statements and the actual values. Assume that the variables have these values:
$X = PR01P001 $Y = 0074
Sample Statement
//$X.$Y
Resolved Statement
//PR01P00174
Explanation
To concatenate 2 variables, enter a period (.) between the 2 variables. Zeke discards the period and joins the values of the variables. You can also use variable concatenation to create a variable longer than 64 characters. For example, if $A is 64 characters and $B is 16 characters, then $A.$B = an 80-character value. This example leaves a space between the variables. If you want the variable and the value to be separated by a period after concatenation, enter 2 periods between the variable and the value. If the variable value is longer than the variable name, the data following the variable shifts to the right. If the variable value is shorter than the variable name, the data following the variable shifts to the left. The leading zeros are dropped. ABC is appended to the value of $X (concatenation). A comma after the variable name is retained with the value. A word adjacent to the variable name remains adjacent to the variable value.
//$X $Y
//PR01P001 74
//$X..$Y
//PR01P001.74
//$X JOB, PAYROLL.EDIT
//PR01P001 JOB, PAYROLL.EDIT
Y EQ $Y $X.ABC
Y EQ 74 PR01P001ABC
$X,
PR01P001,
word$Y
word74
357
Use the following control statements, beginning in column 1, to activate or deactivate variable substitution support. Statement
ZEKE-CTL NOSUB ZEKE-CTL SUB
Purpose
Deactivate substitution. Reactivate substitution.
During the jobstream submission, Zeke discards the control statement and either activates or deactivates the variable substitution facility, accordingly. If the variable substitution facility is deactivated, it remains deactivated until the end of the jobstream, or until a new ZEKE-CTL statement reactivates it. If Zeke is generated with Subdata=YES, variable substitution is always in effect for each new jobstream being submitted, unless the control statements are input to the program ZEKESET. The variable substitution control statements cannot be combined with the Zeke PDS library control statements. Both control statements use the verb ZEKE-CTL, but the operands of the two statements cannot be specified on a single statement. If both statements are desired in a single jobstream, code two separate statements. If you are executing ZEKESET in a PROC and the JCL calling the PROC is passing a SET VAR $... statement in the SYSIN DATA, the calling JCL should contain the ZEKE-CTL NOSUB statement after the exec statement to prevent variable substitution on the variables name in the SET VAR ... statements.
Note:
The difference between using OPTION NOSUB and ZEKE-CTL NOSUB to turn off variable substitution is that OPTION NOSUB turns it off at statement execution time, while ZEKE-CTL NOSUB turns it off at variable substitution time, just prior to dispatch of the event. Refer to your ASG-Zeke for z/OS Reference Guide for more information on OPTION NOSUB.
358
8 Variables
IF Clauses On SET Statements

IF clauses on SET statements can check certain special names in addition to checking variables. Some of the special names that can be used are JOBNAME, CPUID, TIME, DATE, DAY (of week), and ZEKESTEP. Refer to your ASG-Zeke for z/OS Reference Guide for a full list of the special names available.
Note:
The difference between special names and Zeke variables is that special names are pre-defined to Zeke, while Zeke variables are user-defined and begin with a dollar sign ($).
Variable Substitution in SCOM Events

An SCOM event can contain a maximum of 60 characters of commands or responses per line. When using variable substitution in an SCOM, the length of each line must be no greater than 60 bytes including the variable values. For example, suppose you submit the following SEND command from an SCOM:
SE THIS IS A TEST TEST TEST TEST TEST TEST.,USER=($ABCVAR)
and the value of the variable $ABCVAR equals ABCABCABCABCABC. The length of the command as it appears above is exactly 60 bytes. However, once variable substitution is performed for $ABCVAR, the length of the line will exceed 60 characters. In this case, the line must be modified to be 60 characters or less including the variable value.
359
360
Chapter 9:
Security
9
Zeke security can be defined using its internal security function or through the OASIS External Security Interface (ESI). Zekes versatility allows you to control access to Zeke objects and functions from another vendors security product, or your own, provided the product uses the SAF (System Authorization Facility) interface. You may even use a combination of internal and external security packages. It is recommended that you fully understand Zeke internal and external security features before implementing either, or both of them. Topic
Preparing for Implementation Objects and Functions Security Processing Security Calls Processing Logic Tracing Processing Internal Security Online Access: Logging On Function Access: Class Record Record Access: Operator Record Batch Access Setting Up Internal Security Zeke External Security Security Classes Resource Names Implementing External Security
Page
362 363 364 365 367 368 369 370 370 371 371 372 382 383 386 387
361
Preparing for Implementation

Securing information for any computer system can be a complex task, requiring knowledge of the security package, the information to be protected, and the application that stores the information. With this in mind, we recommend that your Zeke security team be made of people who are familiar with Zeke, system programming functions, and, if applicable, your security product.
Note:
Before attempting to implement any security for Zeke, read this entire section and the ESI chapter of your ASG-OASIS for z/OS Reference Guide (particularly the section about planning and implementing ESI). This will ensure that you choose the security method that best meets your needs. In general, you must answer the following questions before deciding on a security approach:
What exactly needs to be secured? Access to information (for example, objects like the Zeke database and specific records) Access to Zeke (for example, functions like primary menu options and Zeke operator commands) Access to a combination of information and the Zeke functions
Do you want to use Zeke internal security, an external security package, or a combination of the two? How will you determine who is granted access and to what authority level?
362
9 Security
Objects and Functions

Before you can decide what needs to be secured, you must understand the different security approaches that Zeke uses. Security Approach
Object
Description
Controlling access to the information contained in a data structure, such as a record or file. This includes controlling access to individual Zeke EMRs, Zeke SQRs, and Zeke variables. Securing by object protects the information regardless of how access is attempted: by command, by batch utility, or by online program. For example, securing EMRs as objects protects them regardless of whether access is attempted from the EVENT online function, the EVENT batch utility command, or the LIST EVENTS report writer facility.
Function
Securing by function means controlling access to commands, programs, and online screens. These functions provide access to the information and also control Zeke processing. For example, securing access to Zeke commands by function controls access to records, such as variables (ZSET VAR), EMRs (ZADD EV), and SQRs (ZALTER EV); and controls access to Zeke processes that do not use records, such as ZHOLD SYS and ZKILL. Specific functions that can be protected with Zeke internal security are: Zeke Primary Menu Options Batch Equivalents of Primary Menu Options Zeke Operator Commands
The following table lists the specific objects and functions that can be protected with Zeke security (internal and/or external). Objects
Zeke Database EMRs Schedule Records Variables Calendars Generation Options (GENOPTS)
Internal Security
External Security
363
Objects
Initiator Definitions (GENSYS) Company Name and Address Pool Definitions Internal Security Records (Class & Operator) Operating Passwords Logical Resource Records ESI Definition Records
Internal Security
External Security
Functions
Primary Menu Options Batch Equivalents of Primary Menu Options SCHEDULE Function ZEKESET Commands Individual SCOM Command Lines Zeke Operator Commands Online Event Add (by event type)
Security Processing
Zeke has its own internal security facility. However, you can control access to Zeke objects and functions from any SAF-compliant security product through OASIS External Security Interface (ESI). Additionally, you can use a combination of both security methods. This is why it is important that you understand both internal and external security before deciding on an approach. Zeke external security provides increased benefits over internal security by including the ability to secure at a more detailed level, more comprehensive security, and more flexibility in establishing access criteria. This section gives a general overview of Zeke security processing, whether you are using internal, external, your own security exit or a combination of all three.
364
9 Security
Security Calls
When a user attempts to access an Zeke object or function, Zeke calls the security processing routine ZEKE15A to determine whether to allow the request. Each security call is governed by the following hierarchy of authority levels (from lowest to highest): Authority Level
Read Update Alter Control
Description
Can browse, display, and list records. Can modify existing records, plus all the authority of READ access. Can add and delete records, plus all the authority of UPDATE access. Can perform the requested command (only applies to individual SCOM command lines).
Each security call specifies the minimum authority level required for the request. For example, if you have granted a user UPDATE access to a record and the user is only requesting READ access, then Zeke allows the request, since READ access is assumed to be granted for someone with UPDATE access.
Note:
Internal security uses only READ and WRITE access. WRITE is a combination of UPDATE and ALTER. Therefore, if a user is granted WRITE access, internal security allows the user to add and delete records, as well as update existing records. Sometimes a single user request results in more than one security call. For example, if a user issues the command ZALTER EV 1 WHENOK, two security calls are made. One security call to determine if the user is authorized to issue ZALTER operator commands and the second to determine if the user is authorized to update the schedule record for event 1. In this example, the user must be authorized for both, or the request is denied. Additionally, if a single user request requires access to multiple records, even more security calls may be generated. For example, if a user issues the command ZDISPLAY JOB, several calls are made. One security call to determine if the user is authorized for the ZDISPLAY command, followed by a call for every job-type schedule record to determine which ones the user is authorized to display (READ access). In this example, if the user is authorized for ZDISPLAY, then only the records that the user has READ access to are displayed. However, if the user is not allowed to issue ZDISPLAY operator commands, then the entire request is denied.
365
A security call can originate from any of the following sources: Source
Online
Description
A request from the Zeke online system. Logging on Accessing one of the primary menu options Accessing a specific record or group of records Issuing a command, such as ZDISPLAY Invoking special commands, such as a catalog STATUS Adding or updating commands in an SCOM event Logging off
Batch
A request from a batch program or job (ZEKE utility or ZEKESET). Logging on (first Zeke access attempt) Accessing function that is the batch equivalent of one of the online functions Invoking a batch-only function, such as SCHEDULE or LIST Accessing a specific record or group of records Using SET ZCOM to issue command, such as ZDISPLAY Issuing a command using SET SCOM ... within an execution of ZEKESET Invoking a global database function, such as BACKUP or RESTORE Logging off Zeke in this initiator
Console
A request from the system console. Issuing a command, such as ZDISPLAY Accessing a specific Zeke record or group of records
ZEKECMD
A request from the ZEKECMD subroutine. For example, issuing a command. This could originate from a batch program, a TSO or CMS users address space, or a multi-user address space (CICS). A request from the ZEKEVAR subroutine. For example, accessing a variable. This could originate from a batch program, a TSO or CMS users address space, or a multi-user address space (CICS).
ZEKEVAR
366
9 Security
Processing Logic
The following flowchart represents the general flow of Zeke security.
Access Request
Hard-Coded ESI Call?
N Genopt ESI ACTV = Y?
Does ESI say to revert to internal?
Does ESI apply to this call?
Does internal security apply?
Y
Call External Security Interface
Internal security verification
Call User Security Exit, if exists
Allow/Deny Request
Every request is assumed to be allowed until it is denied by one of the three security processes: ESI (external security), internal security, or a user exit. Security calls to ESI have been hard-coded for the following Zeke global database functions: CREATE, RESTORE, BACKUP, and STATUS. This is done to provide the most security when the integrity of the database is in question and security criteria may not be accessible. So, if you have a security product on your system, you may be required to set up and define authorized users for the Z$CATAL external class before you can run the CREATE or RESTORE. You can do so by granting at least one user ALTER-level
367
authority to the following resource (entity) names: BACKUP##, CREATE##, RESTORE#, BLOCK###, STATUS##. If you do not define the class and authorized users, your request may be denied, depending how your external security product handles calls with undefined classes. If the return code generated and passed to SAF from your security product is 0 or 4, Zeke allows the request without the class and resource names. If the return code is not 0 or 4, the request is denied. Also, if a user security exit exists, the request may be denied. See Security Classes on page 383 for important details about the Z$CATAL class. External security for other calls can be activated with the generation option ESI Actv. If ESI Actv is set to N, there are no calls to external security (except for Z$CATAL) and, instead, they are passed to internal security. Even when using external security, there may be situations when the administrator wants to revert to internal security. This is especially useful in backup security situations when the security product is down. A user security exit (ZEKE15B) is always called, if present, after all other security verification has occurred. This exit can only deny requests that, up to this point, are allowed, or change the user ID to be used for the internal security logon. It cannot allow requests that have already been denied.
Tracing Processing
You can trace the Zeke security processing flow using the command ZD SEC. The trace displays the security parameter list contents at various key points during processing. This is the same parameter list that is passed to any existing user security exits (ZEKE15B). Use the trace to help determine the following information:

If a security exit is being called and what effect it has on the security decision What element of the security process is making the allow/deny decision Whether internal and external security processing are being performed for a specific call The values of various fields passed to and from the user security exit
368
9 Security
Internal Security
Zeke internal security uses two types of records, stored in the Zeke database, to control access: operator records and class records. Record Type
Operator
Description
Control access to records (objects) in the database, such as schedule records, EMRs, work centers, documentation, and variables. Control access to Zeke functions, such as the Zeke Primary Menu Options and Zeke operator commands.
Class
There are four different IDs related to internal security: ID

Logon ID
Description
ID of the user trying to access the online system. Usually a TSO, CMS, CICS, ROSCOE, or IDMS user ID. A user defined to Zeke. Usually a TSO, CMS, CICS, ROSCOE, or IDMS user ID. The operator ID, combined with the user ID, determines which events and variables a user is authorized to view or update. Any number of user IDs can be assigned to an operator ID. Zeke events and variables have a User ID field. Access to individual event and variable records is determined by the value of this field. An Zeke operator record contains a list of masks to be compared with User ID to control access to the event or variable for a specific operator ID. The User ID does not have to correspond to any logon or operator ID. Any number of events or variables can have the same user ID. Defines the online functions that can be accessed and the Zeke operator commands that are allowed for each operator ID. Any number of operator IDs can be assigned to the same class.
Operator ID
User ID
Class ID
Note:
Keep in mind that class has a different meaning in internal security than in external security and the two concepts are unrelated.
369
Online Access: Logging On

You can either restrict online logon access to specific logon IDs or you can allow anyone to logon with a default level of authority, with more specific criteria for certain defined users. The generation option Reqopid determines whether a specific logon ID is required or whether a default ID is allowed. If Reqopid=Y, an operator ID matching the users logon ID must be defined in the Zeke database, or access is denied. If access is granted, the assigned operator ID is used for all internal security calls required during the session. If Reqopid=N, first Zeke attempts to find a matching operator ID. If a match is found and access is granted, the assigned operator ID is associated with the user. If a match is not found and access is granted, the operator ID in the generation option Defopid is associated with the user. The associated operator ID is used for all internal security calls required during the session. Caution! Verify that an operator record is defined for the value specified in the Defopid generation option; otherwise, access is denied for anyone whose logon defaults to this ID.
Function Access: Class Record

After logon, the class record controls the access to the Zeke Primary Menu Options. The class record also controls which Zeke operator commands the user is authorized to issue. In the online system all Zeke operator commands are issued under the ZCOM/SCHEDULE VIEW option. Not only must a user be authorized to issue a command, a user may also need access to the Zeke database records and the ZCOM online function. This depends on whether the command accesses records and whether the command verb implies Write access. For example, to be fully authorized to issue the command ZADD EV 1, the user must have the following levels:

Yes for the ZADD command Write for the ZCOM menu option Write for event 1
370
9 Security
Record Access: Operator Record

The operator record controls which specific EMRs, schedule records, and variable records a user can access and to what level. When an event or variable record is defined, you can assign a user ID to that record. Any number of records can have the same user ID. Then, on the operator record, you enter that same user ID, or a mask of that user ID, to be compared when access to the event or variable record is attempted. Next to each user ID mask you can specify the level of authorized access (NONE, READ, or WRITE) for each record type. On the operator record, the list of user IDs (or masks) is tested from the top down and the first match is used. If no match is found, access is denied.
Batch Access
Batch security processing is activated by the generation option Batsec=Y. Batch security controls access to the Zeke database and functions as attempted by batch jobs. Batsec does not affect external security nor does it affect the user security exit (ZEKE15B). A batch logon security call is made when the first Zeke batch function in a job is processed. If a ZEKE15B user security exit does not specify an Zeke operator ID to be associated with the job, then Zeke uses the default specified in the generation option Batoprid. If a matching operator record cannot be found, access is denied. If Zeke is down when the batch job starts, an internal batch logon is performed for each function or record access requested in the job. Once the operator ID is determined, security processing works the same as it does for online access. If any access requests are denied, the action taken depends on the generation option Secfail. If Secfail=C, the job is cancelled. If Secfail=I, the denied request is ignored and processing continues.
Note:
The SCHEDULE function and the ZEKESET commands that do not access variables are not secured through internal security. These functions must be secured by either external security or by a ZEKE15B user security exit.
371
Setting Up Internal Security

Begin by first checking or changing the default Generation Options that affect internal security. Go to Setting Internal Security Requirements on page 372. If you decide to structure your internal security with restrictive access you will need to maintain class IDs and operator IDs.
Set up class IDs to group individuals who need similar access to the online functions and commands. Go to Setting Up Class IDs on page 376. Define an operator ID for each user who is to be granted access to the system. Define which online functions and operator commands can be accessed by assigning a class ID. Go to Setting Up Operator IDs on page 379.
Setting Internal Security Requirements

The following generation options affect internal security processing. Option
Batch Requirements: Batoprid Default operator ID used for internal security verification of batch functions. The default is BATCH. Indicates whether Zeke is to provide internal security for batch processing. Indicates the action for Zeke to take if batch security verification fails.
Description
Batsec
Secfail
372
9 Security
Option
Online Requirements: Defopid
Description
Default operator ID to be assigned when an undefined operator logs on. The default is OPERATOR. Required if N is entered in the Reqopid field. When Zeke is first installed, the default operator ID is OPERATOR. This logon ID is also tied to any commands issued from the console. Therefore, any changes made to the security class for OPERATOR are also made for the console. For example, if access to the ZADD command is changed to N, then the ZADD command can no longer be performed from the console. To restrict operator commands from being entered at the console, change the OPERATOR security class ID accordingly. However, if you need the console to be available to issue all commands, do not change the OPERATOR security class ID. Since there is no way to change the ID for the console, we recommend changing the default operator ID to another name to avoid confusion with the OPERATOR operator ID used at the console. Note: If Reqopid=Y, then it is not necessary to change the default operator ID.
Reqopid
Indicates whether an authorized operator ID is required when logging on to Zeke.
Caution! Do not change Reqopid to Y until at least one operator ID

is defined to Zeke with at least write authority for the security function. Otherwise, all users will be locked out of the online facility. User Exit: SECEXITW={xxxx} The number of bytes of storage allocated to call the Zeke security exit routine (ZEKE15B).
373
To set the internal security requirements

1 Determine if you want to require a users logon ID to be defined in the Zeke database as an operator ID before logon access to the Zeke online is granted. If yes, define at least one new operator ID with write access to all security functions to ensure that you are not locked out of the system. If no, define a new operator ID to be used as the default when an undefined user logs on to Zeke.

From the Zeke Primary Menu, enter 6.1 and press Enter. From the Directory of Operator IDs screen, enter ADD on the Command line. Enter the new default operator ID in the Operator ID field and press Enter. The Operator Detail screen is displayed. In the Class ID field, use the default class of A and press Enter. This allows access to all Zeke functions and operator commands as long as class A has not been changed.
If you want to invoke internal security for batch processing, define an operator ID for the name you will use in the Batoprid generation option. The default for Batoprid is BATCH; however, you can define it to match the ID that the security exit calls, or a newly defined operator ID.

From the Zeke Primary Menu, enter 6.1 and press Enter. From the Directory of Operator IDs screen, enter ADD on the Command line. Enter the new default operator ID in the Operator ID field and press Enter. The Operator Detail screen is displayed. In the Class ID field, use the default class of A and press Enter. This allows access to all Zeke functions and operator commands as long as class A has not been changed.
From the Command line, enter =4.1 and press Enter.
374
9 Security
The Option System Directory is displayed.

ASG-Zeke Command ===> System ===> Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete System ******** MEDAZ510 ZK51VLT ****************************** Bottom of data ***************************** Option System Directory Row 1 to 1 of 1 Scroll ===> PAGE
E - Edit
Enter E to the left of the system you want to change and press Enter.
Note:
*********' is the generic system; if generation options are not set for a system, it defaults to the generic system values. 5 The first Generation Options screen is displayed with the options in alphabetical order. Use the F8 or F7 keys to scroll.
N Y 01 Y BATCH N
375
If you want to require a users logon ID be defined in the Zeke database as an Zeke operator ID before logon access to the Zeke online is granted, enter Y in the Reqopid field.

If you want to allow logon access for users who are not defined to Zeke: In the Defopid field, enter the new operator ID you created in step 1 and press Enter. Do not leave Defopid=OPERATOR. Verify that Reqopid is set to N.
If you want to activate internal security for batch processing:

In the Batoprid field, enter the new operator ID you created in step 2. In the Batsec field, enter Y to activate the batch portion of internal security and press Enter. This has no effect on whether a ZEKE15B exit is called. If you are using the ZEKE15B exit, it is called regardless of how this option is set. Determine whether you want to cancel a batch job when an unauthorized request is encountered. If you do, then change the generation option Secfail to C. If you do not, ensure that the option is set to I, to ignore the unauthorized request and continue processing with the next input statement to that batch program.
If you will be using a ZEKE15B user security exit, in the Secexitw field, enter the number of bytes of storage allocated to call the security exit routine (ZEKE15B). Press Enter. To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.
Setting Up Class IDs

A class ID is a way to grant or deny access to specific functions and operator commands for a group of operator IDs. When Zeke is installed, the default class ID A is defined. Class A allows write access to all functions and operator commands. We recommend that this level be reserved for the Zeke security administrator.
376
9 Security
To maintain class IDs

1 From the Zeke Primary Menu, enter 6.2 on the Option line and press Enter.
ASG-Zeke Command ===> Directory of Command Classes Row 1 to 2 of 2 Scroll ===> PAGE
Class ID==> Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete Class Event Zcom Cal Opt Work Sec Doc Var
E - Edit Res
A W W W W W W W W W B W N W W W W W W W ***************************** Bottom of data ******************************
Add a new class ID
Action
Enter ADD on the Command line. Enter the new class ID and press Enter. Go to step 3. Enter E to the left of the desired class ID and press Enter. Go to step 3. Make the following entries: Enter C to the left of the desired class ID and press Enter. Enter the new class ID, and press Enter. The message Record Copied is displayed. This procedure is complete.
Update an existing class ID
Copy a class ID
Delete an existing class ID
Make the following entries: Enter D to the left of the desired class ID and press Enter. Enter DELETE on the Command line to confirm the delete. This procedure is complete.
377
The Class Detail screen is displayed.

ASG-Zeke Command ===> Class Id: A Primary Commands: ADD Allowed functions Event - W Zcom - W Calendar - W Options - W Restart - W Schedule ZADD ZALTER ZDELETE ZDISABLE ZDISPLAY ZENABLE ZHOLD BROWSE CANCEL COPY DELETE EDIT Class Detail EDIT
Work CenterSecurity Document Variable -
W W W W
(R=Read only W=Write allowed) (A=Auto entry in write mode) (N=Not allowed)
control (OPERATOR) commands allowed (Y=Yes, N=No) - Y ZID - Y ZSET - Y ZKILL - Y ZSTATUS - Y ZMAP - Y ZSCAN - Y ZOK - Y ZRESOURCE DISPLAY - Y ZREFRESH - Y ZRESOURCE ALTER - Y ZRELEASE - Y ZRESOURCE RELEASE - Y ZRELOAD - Y ZPLEX -
Y Y Y Y Y Y Y
Each of the major online functions are listed on the screen. To the right of each function, enter the level of access allowed for this class ID. The class ID grants access which can be limited further by user IDs on the operator record. Level
W
Description
Write and read access; can perform all operations for the specified online functions. Read only; can only view functions. Not valid for the work center function. No access; cannot access the specified online function. Auto entry in Write mode; the first screen of the function is displayed when the operator logs on to Zeke. Only one function can be assigned this code.
R N A
Enter a code to the right of each operator command. As with the online functions, these commands can be limited further by the user ID on the operator record. Code
Y
Meaning
Allow this class to execute this command. Do not allow this class to execute this command.
5
378
Press Enter to update the database.
9 Security
Setting Up Operator IDs

Zeke allows you to assign an operator ID to each authorized user. Each operator ID is assigned to a class that specifies which functions and commands are valid for the user. Also, access can be restricted further by the user ID, which identifies the event and variable records the user can access. Zeke operator records control access to records in the Zeke database, such as schedule records, EMRs, work centers, documentation, and variables. Associated with every operator record is the class ID. Class IDs control access to functions, such as the operator commands. Zeke is installed with the default operator ID of OPERATOR. We recommend that you do not use OPERATOR as a default logon operator ID. See Setting Internal Security Requirements on page 372 for additional information.
To maintain operator IDs

ASG-Zeke Command ===> Directory of Operator IDs Operator ID: Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: E - Edit B - Browse C - Copy Operator ID Class Row 1 to 1 of 1 Scroll ===> PAGE
D - Delete
Date Date Last Added Updated OPERATOR A 01/16/2007 01/30/2007 L003J A 01/24/2007 02/04/2007 ****************************** Bottom of data *****************************
Perform the steps in the Action column, depending on the desired result: Desired Result
Add a new operator ID
Action
Make the following entries: Enter ADD on the Command line. Enter the new operator ID, such as your TSO logon ID, in the Operator ID field and press Enter. Go to step 3.
Update an existing operator ID
Enter E to the left of the desired operator ID and press Enter. Go to step 3.
379
Desired Result
Copy an operator ID
Action
Make the following entries: Enter C to the left of the desired operator ID and press Enter. Enter the new operator ID, such as your TSO logon ID, in the Operator Id field and press Enter. This procedure is complete.
Delete an existing operator ID
Make the following entries: Enter D to the left of the desired operator ID and press Enter. Enter DELETE on the Command line to confirm the delete. This procedure is complete.
The Operator Detail screen is displayed.

ASG-Zeke Command ===> Operator Detail EDIT Scroll ===> PAGE CAPS ===> ON
Primary Commands: ADD BROWSE COPY DELETE EDIT Operator ID: OPERATOR Class ID: A
Enter below the Event User IDs or User ID mask, and for each User ID, enter: R - READ MODE W - WRITE MODE OR N - NOT ALLOWED UserID ******** Zcom W Event W Work W Documentation W Variable W
Enter the class ID in the Class ID field.

Note:
The default class when the database is created is A, which gives access to all Zeke functions and operator commands. You should reserve this class for the security administrator of Zeke. See Setting Up Class IDs on page 376 for information on defining class IDs. 4 In the Userid field, enter a user ID to either limit or grant access to an online function. You can enter a specific or a generic user ID. For example, enter PAY***** to control access to all events with a user ID beginning with PAY. Zeke supports mixed-case security user IDs. Use the ISPF command CAPS to toggle between mixed-case and upper case modes. The current mode is displayed in the upper right-hand portion of the screen.
380
9 Security
The authorized user IDs are checked in columnar sequence. Therefore, it is possible to allow access to user ID BILL0501, but prohibit access to any other BILL**** user ID. Enter the BILL0501 user ID first in the list, allowing access. Then list the BILL**** user ID further down the list prohibiting access. Zeke also supports blank user IDs (user IDs composed of all spaces) for operator records, and allows user ID masks containing leading spaces, embedded spaces, trailing spaces, or all spaces.
Note:
When creating variables with a blank user ID, the blank user ID must be set up to have write security access to variables and work centers. 5 Enter a code in the space below each online function indicating the type of security access. If you do not specify an access level, it defaults to R. Code
W R
Meaning
Grant Write access to the function. (Default.) Grant Read (only) access to the function. Not valid for the Work (work center) function. Disallow access to the function.
Press Enter to update the database.
381
Zeke External Security

Zeke external security provides added benefit over internal security by providing the ability to secure at a more detailed level, more comprehensive security, and more flexibility in establishing access criteria. Zeke uses the External Security Facility (ESI) to pass security information to the SAF security interface. This allows you to use a third-party security product, such as RACF or CA-ACF2, to control access to resources for specific Zeke functions. Therefore, you must have previously installed and be familiar with an external security package before using this option. Also, it is a good idea to be familiar with Zeke internal security because you can use a combination of internal and external security for your installation. See Security Processing on page 364 for an overview of Zeke security. Zeke external security is primarily object-oriented. Its main focus is securing the data structures that contain the Zeke information, as opposed to securing the processes or functions that are used to access those structures. However, a few of the external security classes are function-oriented because in certain situations, securing a process is more appropriate than securing the structure. This allows you the flexibility to set up the most effective security for your particular situation. For example, access to schedule records can be controlled by functionlimiting access to the ZCOM online screen and the Zeke operator commands, or by objectthe schedule records themselves. Each of these items is controlled by a security class. Because the protection provided by many of these classes overlaps, you probably will not need to activate all of the classes to obtain the desired security level.
Note:
The term class has different meanings in internal and external security; the types of classes used for internal and external security are unrelated. As another example, Zeke variables can be accessed using one of the following methods:

The online system (Variable menu option) A Zeke command (ZSET VAR $TEST EQ YES) The ZEKESET program (SET VAR $TEST) Completion of a work center
382
9 Security
The following describes different ways to secure access to variables:
Secure access to the variable records by using Z$VAR class. This allows you to secure access to any attempt made through the online system, a Zeke command, the ZEKESET program, or by completion of a work center. Secure access to the online menu options by using the Z$ONLINE class. This allows you to restrict who can access the ZCOM, variable, and work center options. Secure access to the ZEKESET program by using the Z$SET class. This allows you to restrict who can issue the special commands available in ZEKESET. Secure access to the Zeke commands by using the Z$CMD class. This allows you to restrict who can issue certain commands.
Security Classes
In external security, classes are used to identify each resource type. For example, the internal class name for EMRs is Z$EMR. The internal class name is used for all references to that resource type in ESI documentation, messages, and commands. See Security Calls on page 365 for an explanation of the different authority levels for classes. The following is a list of all the security classes provided with Zeke, including a description and the authority classes.
Z$ACCESS Secures use of generic selection criteria (for application ID, group ID, system ID, or user ID) or the CLEAR keyword with the SCHEDULE function. Resource name=SCHEDULE.GENERICS/SCHEDULE.CLEAR Levels: If the ACTIVATE parameter is specified, ALTER authority is required. Otherwise, READ authority is required. Z$CATAL Secures access to the database as a single unit. Resource name=CREATE/BACKUP/RESTORE/STATUS/BLOCK. Levels: READ enables Status and Backup functions; ALTER enables Create, Restore, and Block functions. Z$CLASS Secures access to Zeke class records that are used in internal security. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER Z$CMD Secures access to Zeke operator commands. Default resource name format=(command verb). Levels: READ Z$CND Secures access to calendar records. Default resource name format=(calendar-name). Levels: READ/UPDATE/ALTER
383
Z$ECDR
Secures access to the ESI class definition records. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$DOWNLD
Secures access to the schedule download agents list. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$EMR
Secures access to the EMRs. Default resource name format=(userid.record-type). Levels: READ/UPDATE/ALTER
Z$GOPT
Secures access to the generation option records. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$NAME
Secures access to the customer name records. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$ONLINE
Secures access to the Zeke online functions. Default resource name format=(online menu option name). Typically, this option is not necessary if all of the desired records have been secured. Levels: READ enables Read mode for that section of the online; UPDATE enables Write mode. Options to which you do not have access are not displayed on the Zeke Primary Menu.
Z$OPER
Secures access to operator records used in internal security. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$PASS
Secures access to the operating passwords. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$PINT
Secures access to the partition/initiator records. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$POOL
Secures access to the pool definition records. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
384
9 Security
Z$RESRC
Secures access to the resource definition records. Default resource name format=(Zeke catalog-id). Levels: READ/UPDATE/ALTER
Z$SCHED
Secures access to the SCHEDULE function. Default resource name format=(userid). The parameters provided by the user are used to build the resource name for one SAF call. Object-oriented security is not applied to this function because a security call would be required for each attempt to access a record. Since the SCHEDULE function involves reading every EMR in the Zeke database, calendars, and variables, and then creating schedule records, thousands of security calls could result, with a substantial impact on performance. Levels: If the ACTIVATE parameter is specified, ALTER authority is required. Otherwise, READ authority is required.
Z$SET
Secures access to the ZEKESET functions. Default resource name format=(command verb). Levels: READ
Z$SIM
Not valid at this time. In a future release, this class will secure access to the simulation function. Default resource name format=(userid). Levels: n/a
Z$SQR
Secures access to the schedule records. Default resource name format=(userid). Levels: READ/UPDATE/ALTER
Z$VAR
Secures access to variables. Default resource name format=(userid). Levels: READ/UPDATE/ALTER
Z$XCOM
Secures access to individual commands within an SCOM event. Default resource name format=(command code). Levels: CONTROL
385
Resource Names
Each class has a resource name format that contains the information that is used to make the security decisions. The resource name can be broken down into elements. When the resource name is built for the SAF call, the value of the element is inserted into the resource name. The eligible elements for each class are listed on the X1FOFSELESI Customization screen. There are several types of elements:
Fields Most elements that are eligible to be a part of the resource name are fields in the records being secured. For example, for the class that secures the EMR (Z$EMR), the list of elements includes EVENTNAME, APP, and GROUP. Some elements are structures that are associated with the Zeke database, such as the catalog ID and the system you are running under. These elements get their values from a set of constants applicable to that element. For example, the source of the request. If a command is entered from the console, the source is CONSOLE. Likewise, if a command is entered through the ZCOM function, the source is ONLINE. User-defined constants and delimiter characters are also eligible elements.
Structures
Constants
User-defined
The most common elements are described below:

Catalog ID The 8-byte unique catalog identifier, determined when the catalog is created. The catalog ID appears after the word CATID in the last line of output from a ZID command. Once created, the catalog ID cannot be changed, even if the catalog is restored from a backup dataset. The command verb issued. For example, Z$CMD ClassZID, ZDISPLAY, ZALTER, etc. Z$SET ClassSET, CDATE, etc. Command Code The type of command issued from an SCOM event. C R Z V P System command System response (VSE only) Zeke command VM command VSE/POWER command
Command
386
9 Security
Command Text Function Record Type
The full text of an entered command. The name of the online function to which access is being requested. The sub-record type to which access is requested. for example, an EMR has several types of subordinate records like JCL and DOC The source of the request that caused the security call to be made. For example, if a command is entered from the console, the value of the source field is CONSOLE.
Source
Subsystem Name The OASIS subsystem that this Zeke system is running under. Multiple subsystems allow the user to run more than one system on the same operating system. Its value is shown on the third line of the response to the ZID command.
Implementing External Security

ASG recommends fully implementing external security for a single internal class before implementing ESI for other classes. This allows you to go through the complete implementation process, including testing, for a small area of the system before performing a large-scale implementation. ASG also recommends that you activate all classes initially, except for the Z$ONLINE class. After some use and testing, you may want to deactivate or combine some classes into the same external class name, or to activate the Z$ONLINE class. All of the Zeke ESI classes provide the flexibility of changing the external class name, the process option, and the resource name formatexcept for the Z$CATAL class. The default external class name for all classes is the same as the internal class name, and the default process option for all classes is N4 (except for the Z$CATAL class). The Z$CATAL class is unique in that the external class name, the process option, and the resource name format cannot be changed. Because this class incorporates functions such as a database RESTORE and CREATE, the SAF call is fixed to ensure that the database as a resource is secure under all conditions. Before making any changes to the external security screens, please read the ESI chapter of your ASG-OASIS for z/OS Reference Guide, particularly the section about setting up ESI.
To modify ESI class definition records

387
On the ESI CustomizationX1SELECT screen, each line represents an ESI class definition record that is uniquely defined by the system ID and the internal class name.
ESI Customization COMMAND ===> BROWSE SCROLL ===> PAGE X1SELECT
Primary Commands: DOWN UP EDIT BROWSE END RETURN Line Commands: F - Resource name format C - Copy to discrete ECDR D - Delete discrete ECDR "Copy to" System Internal Class Z$CATAL Z$CLASS Z$CMD Z$CND Z$ECDR Z$EMR Z$GOPT Z$NAME Z$ONLINE Z$OPER Z$PASS Z$PINT Z$POOL Z$RESRC External Class Z$CATAL Z$CLASS Z$CMD Z$CND Z$ECDR Z$EMR Z$GOPT Z$NAME Z$ONLINE Z$OPER Z$PASS Z$PINT Z$POOL Z$RESRC Process Option Y4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4
System ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ********
Perform the following actions, depending on the desired result: Desired Result Action
Change the external class name Make the following entries: Enter EDIT on the Command line and press Enter. Enter the new class name in the External Class field of the class to change. Press Enter. Go to step 6. Copy a record with all of its attributes to another system Enter C to the left of the record to copy. Enter the new system ID in the Copy to System field. Press Enter. Go to step 6. Delete a record with all of its attributes Enter D to the left of the record to delete and press Enter. Go to step 6. Note: The generic (********) records cannot be deleted.
388
9 Security
Desired Result
Change the process option
Action
Note: If changes are made to the external class name or the resource name format, leave the process option set to N4 until you have tested the implementation. Make the following entries: Enter EDIT on the Command line and press Enter. Enter the process option in the Process Option field. Process Option N0 N4 Description
Do not call SAF. Grant all access requests. Do not call SAF. Use internal security to determine whether to grant the access request. Do not call SAF. Deny all access requests. Call SAF. If the SAF return code is 4, grant the access request. Call SAF. If the SAF return code is 4, use internal security to determine whether to grant the access request. If there is no internal security, access is allowed. Call SAF. If the SAF return code is 4, deny the access request.
N8 Y0
Y4
Y8
Press Enter to update the record. Go to step 6. Change the resource name format Enter F to the left of the class name that you are changing and press Enter. Go to step 3.
389
The ESI CustomizationX1FRMAT1 screen is displayed with the current list of elements for the specified resource name format.
********.Z$EMR/Z$EMR COMMAND ===> ESI Customization BROWSE SCROLL ===> PAGE X1FRMAT1
Primary Commands: DOWN UP EDIT BROWSE RESET END RETURN CANCEL Line Commands: A - Insert element after B - Insert element before D - Delete element --+---1----+----2----+----3----+----4----+----5----+----6----+----7---+--8 aaaaaaaa.bbbbbbbb Start a 001 . 001 b 001 **END** Length 008 001 008 Field Description User ID Delimiter character Record type 3 elements
Perform the steps in the Action column, depending on the desired result Desired Result
Add an element
Action
Make the following entries: Enter EDIT on the Command line and press Enter. Enter the code to the left of an element to position the new element. Code A B Meaning Add the new element after the selected element. Add the new element before the selected element.
Press Enter. Go to step 4. Make the following entries: Change a portion of an element to be included in Enter EDIT on the Command line and press Enter. the resource name format Enter the beginning position in the Start field. Enter the length in the Length field. For example, if the element value is ABCDEDFG (start position of 1 and length of 8), and you want to select CDE as the new value. Enter 3 in the Start field and 3 in the Length field. Go to step 6. Restore the resource name format to the default If you have saved changes to the format and wish to cancel them, enter RESET on the Command line and press Enter.
390
9 Security
Desired Result
Exit screen without saving changes made to the format Delete an existing element
Action
If you have made changes to the format that you do not wish to keep and have not saved them, enter CANCEL on the Command line and press Enter. Make the following entries: Enter EDIT on the Command line and press Enter. Position the cursor to the left of the element you wish to delete. Enter D and press Enter. Go to step 6.
The ESI Customization X1FOFSEL screen is displayed with a list of eligible elements (fields) for this class.
********.Z$EMR/Z$EMR COMMAND ===> ESI Customization EDIT SCROLL ===> PAGE X1FOFSEL
Primary Commands: DOWN UP END RETURN Line Commands: C - Copy field Length 001 1-8 008 008 003 012 008 008 004 008 008 008 007 002 008 004 Field Description Delimiter character Literal value ===> __________ User ID Application ID Group ID Event name Job name System name Event type Record type Target Platform Source Disaster recovery level Zeke internal catalog ID Subsystem name
(quoted)
To add the element to the resource name format, enter C to the left of the desired element and press Enter. After all the desired elements are included in the resource name format, press F3. For each class that you updated, use the OASIS operator command RELOAD to replace the in-storage ESI class definition record. With the RELOAD command, enter the internal class name for which the in-storage ESI class definition record is to be replaced. For example, RELOAD ECDR Z$CMD reloads the Zeke operator commands.
5 6
391
To activate the External Security Interface

E - Edit
Enter E to the left of the system you want to change and press Enter.
Note:
*********' is the generic system; if generation options are not set for a system, it defaults to the generic system values. 3 The Generation Options screen is displayed with the options in alphabetical order. Use the F8 or F7 keys to scroll.
ASG-Zeke Command ===> Zeke System: Defopid: Defpltfm: DefSysId Dispdly: Dispmsg: Dispsel: ******** (xxxxxxxx) (xxxxxxxx) (xxxxxxxx) (xxxxx) (Y or N) (Y or N) (xx) Default online operator ID Default Jobevent EMR Platform value Default System Id for Event add Seconds to delay dispatching pooled events Yes to issue dispatch message Yes for Zeke to select initiators (MVS) (yes is ignored for JES3) TA=Trigger All Dates NT=If Multi-Dates exist, Place on HOLD, else Trigger Date OD=Trigger Oldest Date ND=Trigger Newest Date Yes to create an index dataspace Yes to use a dataspace for Schedule load Yes to dynamically install SMF exit Yes to build EDB in-core index Yes for Zeke to wake up at EOJ Yes to activate Ext Sec Interface (SAF) Fairmod option code Generation Options BROWSE Scroll ===> PAGE
OPERATOR MVS ZEQA 030 Y N
Dsntrig: TA
DSPIndex: DSPSched: Dynsmf: EDBindex: Eojwake: ESI Actv: Fairmod:
Y Y Y N Y Y 023000
(Y or N) (Y or N) (Y or N) (Y or N) (Y or N) (Y or N) (xxxxxx)
Page to the ESI Actv generation option and enter Y to activate the External Security Interface.
392
9 Security
For the Defopid generation option, enter the default Zeke operator ID to be assigned when an undefined operator logs on. The default is OPERATOR. Although Defopid applies solely to internal security, it must be set when activating ESI even if you plan to use only external security. This is because the ESI process option allows for the possibility to revert to internal security under certain circumstances. In such a case, the default operator ID is required. This operator ID must be supplied to Zeke during log-on. If you plan to use ESI exclusively, it is not important what level of authority is assigned the default operator ID. If you intend to use internal security with external security, set it to the default level of authority.
Set the Batoprid generation option to the default operator ID to use for security verification of batch functions. The default is BATCH. Batoprid is the batch equivalent of Defopid (described in step 5). Verify that there is an operator ID record defined for this ID. Determine whether you want to cancel a batch job when an unauthorized request is encountered.

If you do, ensure that Secfail is set to C. If you do not, ensure that Secfail is set to I, to ignore the unauthorized request and continue processing with the next input statement to that batch program.
Determine whether you want to display primary records if security access is denied.

If you do, ensure that Sechide1 is set to N. If you do not, ensure that Sechide1 is set to Y. Any Zeke online screen that displays a directory of records will only display those records the user has at least Read access to.
Determine whether you want to display subordinate records if security access is denied to a user.

If you do, ensure that Sechide2 is set to N. If you do not, ensure that Sechide2 is set to Y. Any Zeke online screen that displays a directory of records will only display those subordinate records the user has at least Read access to. For example, the * (asterisk) displayed in the DOC column on the Event Master Directory screen indicates a subordinate record of the EMR exists.
10
To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter. If you have not defined the external class name, go to the procedure To modify ESI class definition records on page 387. You are ready to test the implementation. For information on testing ESI with ESITRACE, refer to your ASG-OASIS for z/OS Reference Guide.
393
11
12
394
Index
Symbols * (asterisk) used with generic names for dependencies 138, 143 job types 84 special calendars 69 A adding events by path 79, 255 ALTER, Schedule View command 213 Audit Log Facility defining/updating the audit log 319 displaying the audit log 319 logging in the Audit Log database 318 jobs status changes 318 Zeke operator commands 318 tracking Zeke database activity 318 updating audit actions 318 Auto access 378 auto replies disabling 175 displaying 175 enabling 175 managing Zack Fastpath/Autoreply tables from Zeke 61 responding to outstanding replies 39, 171 setting generation options 39, 171 172 using the AUTORPLY function 172 Automation option, managing Zack Fastpath/Autoreply tables from Zeke 61 B backing up the database 323 using a dataspace 45, 323 C calculating tape drive usage 305 calendars accessing online 65 adding a calendar 66 deleting a calendar 66 description of 3 special calendars 69
standard calendars 67 summary of types 7 user accounting calendars 70 overview of user accounting periods 71 CAPS mode 380 class IDs 369, 376 CLIST commands 242 creating your own 242 colors, changing ISPF screen 316 commands CLIST 242 command events 107 in SCOM events 359 ISPF 5758, 78, 180, 185, 233, 346 creating your own 242 JCL 230231 operator 92, 95, 97, 105108, 111, 114, 165, 171, 175, 202, 243 244, 318, 351, 362 auto reply 171 securing 370 security 369 POWER 107 REXX 242 Schedule View 202, 211217 securing 363 system 107 VM 107 ZADD, for Schedule View 250, 252 Zeke start-up 54 ZEKESET 371 ZKILL 56 communication, inter-product controlling 309 completing work centers 166168 condition codes 3, 154157 controlling jobstream flow using variables 353 conventions page xi CREATE batch utility setting up Z$CATAL class 367 creating CLIST or REXX commands 242 Zeke database 320 cross-platform dependencies 144 cycling Zeke 284 395
D database backing up the database 323 backup using a dataspace 45, 323 creating Zeke database 320 Zeke started task 326 job information contained in 17 moving the vault database 326 recovery, Zeke started task 329 retrieving JCL 179 shared 311 dataset triggering 145 hold code 206 dataspace building a full EDB index 312 creating the schedule using a 46 database backups using a 45, 323 events listing using a 47 for schedule loads 45 running simulation against a 201 start-up parameter 39 use in report generation 47 date format, Schedule View 224 DaySpan, description of logical days 4 defining permanent events 115 recurring events 115 dependencies cross-platform scheduling 144 dataset triggering 145 defining 150 description of 5 EOG (end of group) 146, 148 extended dependencies 136, 149 generic event names 138 grouping multiple phrases 139 length of 225 maintaining from Schedule View 225 from the EMR (all versions) 151 multiple 139, 141 multiple job versions 135 Not Active 142 see also logical resources processing of 135 referencing started tasks 138 satisfied 17, 135 using variables 140 viewing from Schedule View 225 from the EMR (all versions) 151 WEAK conditions 137 396
dispatch queue, checking 306 dispatching description of 17 jobs after Zeke start-up 312 list of prerequisites 10 messages and jobs 288 see also dependencies displaying fields in Schedule View 222 documentation calendars note pad 73 scratch pad 73 text 74 events 181 jobs datasets 186 note pad 184 scratch pad 184 summary of types 8 text 185 segments, definition 3 variables note pad 344 scratch pad 344 text 346 downloaded schedules 197 downloading, setting up a job for 102103 DSPIndex generation option 312 E ECDRs, modifying 387 EDB indexes, building 312 electronic vaulting considerations for using 328 database allocation 328 description of 4 features 15 full recovery procedure 328 partial recovery procedure 329 ESI, see security, external security event activating an event 80 adding events to the schedule manually 250 command events 107 copying an event 90 from a template 88 creating from a template 88 deactivating an event 78 job events 92 routing to another system or platform for execution 98 permanent 8, 114117 recurring 8, 114117 resources, accessing 229
Index
routing a job event to another system or platform 98 status codes, in Schedule View 205 status, displaying 227 templates creating events from a template 88 defining a template 86 work centers 161 exporting database records 28 extended dependencies, see under dependencies external security see security F Fastpath, managing Zack Fastpath/Autoreply tables from Zeke 61 forecasting the schedule 5 G generation options accessing 286 activating 284 cycling Zeke 284 dataspace 45 AUR 303 AURINTV 303 AURMSG 303 Batoprid 376, 393 Batsec 376 Calctap 305 COMMCTL 291 DEFDPRTY 288 Defopid 376, 393 DISPDLY 288 DISPMSG 288 DISPSEL 305 DSPIndex 79, 312 EDBindex 312 Eojwake 306 IEFU83 293 Igncat2 290 JOBRST 306 Loadcomm 304 MSGWAIT 288 MSPINTRL 288 MULTAP 297 MULTEN 297 MULTGR 297 Multhit 297 Multjn 297 Multsys 295, 311
MULTUS 297 Netregid 98, 102, 307 Nonwkday 297 OPEROK 214, 288 Oprhold 312 Pendinv 300 Pendmsg 300 Posid 98, 102, 307 POSIDEND 45, 307 PRILATE 288 Reqopid 376 RETAIN 291 RETDAYS 291 RETDONE 291 RETPEND 291 Secexitw 376 Secfail 376, 393 Sechide1 393 Sechide2 393 Subdata 288 TRIGDT 293 TRIGJOB 294 TRIGRRN 294 WKTRGDN 294 H help, accessing Zeke ISPF online 57 holding an event 252, 256 I IF clauses within SET statements 359 importing database records 28 initializing the database 320 initiators adding a system 269 specifications 269 copying an initiator record 270 defining initiators 269 deleting a single initiator 270 all initiators for a system 270 editing an existing initiator 269 selecting, according to class 266 system availability 271 installation, setting up Z$CATAL class before running CREATE 367 interfaces, Zebb restart management 215 internal security see security inter-product communication, controlling 309
397
ISPF online facility accessing a subsystem 60 changing colors on screens 316 commands 5758, 78, 180, 185, 233, 346 creating your own 242 common fields 58 features 57 logging on 59 screen format 58 Zeke primary menu 6061 see also under online J JCL displaying actual execution JCL 215 JCLR, Schedule View line command 214 line commands 230231 override 234 performing one-time overrides for job events 232 retrieving JCL from the Zeke database 179 specifying JCL source libraries PDS 176 substituting variable values 356 syntax checking 241 with JCLPREP 237238 with JOB/SCAN 239240 using variables to control jobstream flow 353 to restart a job 354 to trigger jobs 352 validation using ZSCAN 241 with JCLPREP 237 with JOB/SCAN 239 JCLPREP, invoking from Schedule View 237238 job activating pending messages and jobs 300 adding jobs to the schedule 254, 258 checking the dispatch queue 306 creating and adding to the schedule at the same time 197 defining 75 definition 4 dispatching jobs after Zeke start-up 312 messages and jobs 288 EMR accessing 82 definition of 4 398
event 92 setting up for downloading 102103 log, displaying 215 MSG jobs 104 NOT-CAT2 messages, recognizing 290 PCOM jobs 107 pending 300 predecessors, viewing in Schedule View 214 on the EMR 7980 refreshing jobs 215 restart facility 306 retaining jobs 291 scheduled job, changing via Schedule View 213 scheduling jobs 297 SCOM jobs 107108 successors, viewing in Schedule View 214 on the EMR 79 on the master 81 templates defining 86 overview 7 types of jobs Zeke processes 3 VCOM jobs 107 versions, dependencies for 135 ZCOM jobs 107 JOB/SCAN, invoking from Schedule View 239240 JPREP line command 238 JSCAN line command 24, 240 L line commands see commands listing events using a 47 loading the work center to SQT 304 Logical Day 4 scheduling examples 18, 96, 192 logical resources copying a resource 276 defining a resource to Zeke 275 defining resources for an event 277 deleting a resource 276 deleting resources for an event 281 description of 4, 262 editing an existing resource 275 maintaining 274 logon IDs, maintaining 369 ISPF online 59
Index
M menus Zeke Primary Menu 6061 messages dispatching 288 display system 215 pending 300 MSG job 104 multiple OASIS support 20 system support 6 Zekes 18 N NETREGID 145, 307 Network Hold status 206 networking options, maintaining 307 NOT-CAT2 messages, recognizing 290 NOTDURING processing reason code 207 using logical resources 274 WHEN conditions 142, 146, 215 O OASIS multiple OASIS support 20 started task 54 starting the 320 starting multiple tasks 54 without Zeke 52 terminating 55 variables accessing 57 in SET clauses 162 naming 348 overriding variable values temporarily 350 overview 347 setting with XVAR and ?XVAR 162 temporary variables 350 OCCURS clauses defining 132 description of 4 grouping multiple phrases 119 list of keywords 118 multiple phrases 118 processing 118 sample clauses 126 scheduling for holidays and weekends 130 using parentheses in 119
online see also ISPF online facility operator commands 92, 95, 97, 105108, 111, 114, 165, 171, 175, 202, 243244, 318, 351, 362 auto reply 171 securing 369370 ZKILL 51 operator hold on an event 252, 256 operator IDs maintaining 369, 379 mixed case 380 OpsCentral 22 OVAR 57 overriding JCL 214, 234 P PATH master primary command 79 Schedule View line command 214 PathFinder adding events by path 79, 255 description of 4 displaying different levels in the hierarchy 246 non-Zeke jobs in a path 246 PCOM job 107 PDS JCL support 176 PDS override, Zeke started task option 234 pending messages and jobs 300 permanent events 8, 114117 defining 115 physical resources defining initiators to Zeke 269 defining pools 272 Poly-Zeke 14, 18 pools adding a pool 272 a system ID 273 definition of 5 deleting a single pool 273 all pools for a system 273 editing an existing pool 272 an existing system 273 POSID 307 POSIDEND 45, 307 POWER commands 107 predecessors, viewing in Schedule View 214 on the EMR 7980
399
prerequisites, see dependencies primary commands see commands primary database versus secondary database 328 see also under database primary menu, Zeke 6061 R random scheduling dates, creating calendar for 69 Read access 378, 381 reason codes in Schedule View 205 recovery, see disaster recovery level, electronic vaulting recurring events 8, 114117 defining 115 refreshing jobs 215 refreshing Schedule View 219 remote dependencies 144 rerunning a scheduled job 253, 257 resources checking before dispatch 10 see also logical resources, physical resources restarting jobs using variables 354 Zeke 51 restoring the database 324 RESTORE batch utility setting up Z$CATAL class 367 restricting number of jobs selected 253 system availability initiators 271 retaining jobs 291 retrieving JCL for updating 214 JCL from the Zeke database 179 return codes see also condition codes REXX commands 242 creating your own 242 RSTRT, interface to Zebb 215 RUN, Schedule View line command 215 S SAF security 22 schedule adding a newly created job to the schedule 197 adding events by path 255 creation using a dataspace 46
event scheduling 250 forecasting 5 job scheduling 254, 258, 297 number 197 record, rerunning 253, 257 SCHED ID, see OCCURS clauses SCHEDADD parameter 197 SCHEDULE batch utility function of 17 running the schedule automatically 196 scheduled job definition of 4 displaying 202 recreating 253, 256 status, changing 252, 256 scheduling criteria, see OCCURS clauses simulation 5, 199 schedule download 197 displaying agents 22, 102 setting up a job for downloading 102 103 schedule queue record, definition of 4 Schedule View accessing event master record information 217 online documentation 217 other online information 217 PathFinder 217 resources for an event 229 work center information 217 adding events to the schedule 250, 254, 258 ALTER line command 213 changing amount of storage for an event 208 class or class list for an event 208 dispatch priority 208 number of tape drives 208 number of times an event is dispatched 208 schedule time 208 scheduled job status 252, 256 sort sequence 220 system or pools 208 way JCL is submitted and executed 209 commands 211216
400
Index
creating CLIST or REXX commands 242 schedule 194 date format 224 description of 4 display fields 222 displaying event status 227 schedule queue record information 230 scheduled jobs 202 status of events 227 invoking JCLPREP 237238 invoking JOB/SCAN 239240 line commands 202, 208, 213, 217 SYSJ, SYSL, and SYSM 216, 241 maintaining dependencies 225 maintaining JCL 232 placing an operator hold on an event 252, 256 primary commands 211 recreating the scheduled job 253, 256 refreshing the screen 219 repeating the last command entered 209 rerunning a scheduled job 253, 257 restricting the number of jobs selected 253 setting display characteristics 202 sort sequence, changing 221 validating JCL 241 ZADD command 252 ZCOM option, entering operator commands 243 ZOOM line command 230, 237, 239 SCOM jobs 107108 variable substitution within SCOM jobs 359 SECEXITW - specifies work area size 376 SECHIDE1, displaying primary records 393 SECHIDE2, displaying subordinate records 393 secondary database versus primary database 328 see also under database security authority levels 365 building a Zeke security team 362 calls to ZEKE15A 365 sources of 366 commands 363
exit BATOPRID 376 BATSEC=YES 376 SECEXITW option 376 SECFAIL - what to do if security fails 376, 393 ZEKE15B 368, 376 external security activating ESI 392 advantages over internal security 364 cancelling unauthorized batch job(s) 393 changing the external class name 388 changing the process option, internal class 389 copying an ECDR 388 deleting an ECDR 388 description of 5 displaying primary records 393 displaying subordinate records 393 elements 386 hard-coded calls 367 main focus 382 modifying ECDRs 387 protection provided by 363 replacing the ESI class definition record, internal class 391 resource name format 386, 389391 security class 382383 implementing 362 internal security activating security for batch processing 376 allocating work area size 376 cancelling unauthorized batch jobs 376 changing security requirements 372 class IDs, maintaining 369, 376 defining logon ID to Zeke database 376 description of 5 IDs used 369 logon IDs, maintaining 369 not restricting logon access 376 online logon access 370 operator IDs, maintaining 369, 379 protection provided by 363
401
record types used 369 user IDs, maintaining 369 using Zeke security 361 operator commands 369370 processing 364 logic 367 securing by function 363 securing by object 363 tracing processing 368 SET clause 162 IF clause within 359 simulation running against a dataspace 201 schedule 5, 14, 199 SMFPRMxx 138 SMP/E install 6 sorting Schedule View 220 SQR, definition of 4 started task OASIS 54 starting 320 Zeke 51, 5354 database creation 326 database recovery 329 including the Zebb load library 309 PDS override option 37, 234 start-up parameters 39 terminating 56 starting multiple tasks OASIS started task 54 Zeke batch utility 53 Zeke started task 5354 start-up commands 54 parameters, dataspace 39 status, event status in Schedule View 205 STOP command 56 subsystem 18 accessing ISPF online using 60 successors, viewing in Schedule View 214 on the EMR 79 on the master 81 SYS1.PARMLIB SMFPRMxx 138 SYSJ, SYSL, and SYSM line commands 216, 241 system commands 107 maintaining 286 networking options 307 operating criteria, changing 284 system-dependent variables 351
T tape drives, calculating usage 305 tasks, Zeke started tasks 54 templates creating an event from a template 88 defining 86 overview 7 temporary OASIS variables 350 terminating OASIS 55 the Zeke started task 56 Zeke 56 using STOP 56 using ZKILL 56 triggering events, hold code 206 tutorial, accessing Zeke ISPF online 57 TVSET function (temporary variable set) 350 U user ID maintaining 369 mixed case 380 V validating JCL 236 VAR and ?VAR keywords 162 variables as an event prerequisite 140, 351 controlling jobstream flow using variables 353 deleting a variable 341 description of Zeke variables 5 in dependencies 352 naming variables 338 OASIS, see under OASIS variables overriding variable values temporarily 350 restarting a job using variables 354 setting values 169 setting with VAR and ?VAR 162 substitution activating variable substitution 288 activating/deactivating 358 in JCL 356 within SCOM jobs 359 summary of features 11 system-dependent variables 351 temporary OASIS variables 350 triggering jobs using variables 352 vault database, moving 326 vaulting, see electronic vaulting
402
Index
VCOM job 107 versions, description of 5 VM commands 107 W wait reasons, displaying 227 WEAK conditions 137 WHEN conditions see dependencies work centers 161 adding or updating a variable value 169 completing 166168 confirming variable values 170 description of 5 disabling an event 168 displaying variables for an event 168 enabling a disabled event 168 loading the work center to SQT 304 refreshing an event 168 SET clause 162 setting up work centers 163 Write access 378, 381 X XEOJ/XEOE keywords 136, 149 XVAR and ?XVAR keywords 162 Z Zack, managing Fastpath/Autoreply tables from Zeke 61 ZADD command 250, 252 ZCOM job 107 ZCOM option 250 entering operator commands 243 Zebb load library in the Zeke started task 309 restart management interface 215 Zeke cycling 284 OpsCentral setup 22 PDS JCL override 234 restarting 51 starting multiple tasks 54 start-up commands 54 terminating 56 using STOP 56 using ZKILL 56 Zeke started task 53 database creation 326 database recovery 329 including the Zebb load library 309
PDS override option 234 terminating 56 ZEKE15A 365 ZEKECAT 320 ZEKENEW 320 ZEKESET commands 371 ZEKEXUTL (import/export utility) 28 ZKILL ZKILL COLD command 56 ZKILL TRACK command 56 ZKILL WARM command 56 ZOOM, Schedule View line command using to invoke JCLPREP 237 using to invoke JOB/SCAN 239
403
404
ASG Worldwide Headquarters Naples Florida USA | asg.com
CD Contents

Zeke

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Zeke

Uploaded by

Copyright:

Available Formats

ASG-Zeke for z/OS Users Guide

Version 5.4 Publication Number: AZM0200-54 Publication Date: March 2007

ASG-Zeke for z/OS Users Guide

Starting Zeke and Using the Online Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

ASG-Zeke for z/OS Users Guide

Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 191

Maintaining JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232 Zeke PDS JCL Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

236 237 239 241

Maintaining Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

ASG-Zeke for z/OS Users Guide

311 312 312 314 316

ASG-Zeke for z/OS Users Guide

About this Publication

ASG-Zeke for z/OS Users Guide

To obtain a specific version of a publication, contact ASG Customer Support.

ASG-Zeke for z/OS Users Guide

Worldwide Customer Support

Intelligent Support Portal (ISP)

ASG Documentation/Product Enhancements

ASG-Zeke for z/OS Users Guide

ASG-Zeke for z/OS Users Guide

ASG-Zeke for z/OS Users Guide

ASG-Zeke for z/OS Users Guide

SMP/E Install Tapes

CICS IDMS CMS TSO ROSCOE ISPF

Multiple Schedule Queue Records (Versions)

ASG-Zeke for z/OS Users Guide

Recurring, Permanent, and Milestone Events

Routing Job Events to Other Platforms

On-Demand, On-Request Events

User JCL Exit

ASG-Zeke for z/OS Users Guide

Dispatching Dependencies (WHEN conditions)

ASG-Zeke for z/OS Users Guide

Condition Code Validation

Copying JCL and Documentation into the Zeke Database

Work Center Facility

ASG-Zeke for z/OS Users Guide

Audit Trail Facility

ASG-Zeke for z/OS Users Guide

Fields Sequence Schedule records Selection criteria EMRs

How Zeke Works

The scheduling criteria is met An operator request is entered

ASG-Zeke for z/OS Users Guide

Testing a New Release

OASIS 260A SSSI

OASIS 270A SSSX

Zeke Production Database

Zebb Production Database

Zeke Test Database

ASG-Zeke for z/OS Users Guide

Support Multiple Application Databases

OASIS 270A SSSA

OASIS 270A SSSI

OASIS 270A SSSB

OASIS 270A SSSX

Zeke Production Database #4

Zebb Production Database

Zeke Production Database #3

Zeke Production Database #2

Zeke Production Database #1

Zeke Interfaces to Other ASG Products

ASG-Zeke for z/OS Users Guide