Zeke 6.0 Users Guide.pdf

ASG-Zeke™ Scheduling for z/OS User’s Guide Version 6.0 Publication Number: AZM0200-60 Publication Date: September 2012

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 © 2012 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 | [email protected] 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 E-mail User Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x Publication Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi Worldwide Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Intelligent Support Portal (ISP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii Product Support Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii ASG Documentation/Product Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiv

Chapter 1:

Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zeke Processing (Multisystem Support) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

2 2 2 3

Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Event Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Event Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Event Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Schedule Monitoring and Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operator Commands (ZCOM Option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Job Restart/Rerun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workload Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

12 13 13 14 14 14 15

Configuration and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Database Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16 16 16 17

Batch Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 ZEKE Batch Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 i

ASG-Zeke Scheduling for z/OS User’s Guide

Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 ZEKESET Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 ZEKEXUTL Import/Export Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 Zeke Interfaces to other ASG Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ‘Z’ Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-platform Schedule Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JCL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Workload Analysis and Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ASG-Automation Center (Problem Tracking Support) . . . . . . . . . . . . . . . . . . . . . . . . . ASG-Cortex-Pdb Plug to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 2:

20 20 21 22 22 23 23

Starting Zeke and Using the Online Facility. . . . . . . . . . . . . . . . . . . . . 25 Starting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Restarting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Starting OASIS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Starting Multiple Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Terminating OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 Terminating Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Using the ISPF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISPF Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Screen Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Logging On and Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Changing the ISPF Color Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32 32 33 33 36

Starting the Zeke Online Facility under TSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Chapter 3:

Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Calendar Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Accessing the Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 Standard Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Special Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 User Accounting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Calendar Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Maintaining Scratch Pad or Note Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Chapter 4:

Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Event Master Record (EMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52 Event Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 EMR Primary Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

ii

Contents

Specifying Generic Selection Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 Accessing the Event Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 Adding an Event Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Updating an Event Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Defining an Event Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63 Creating an Event From a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 Copying an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 Defining a Job Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Defining a Message Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Defining a Command Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Defining a REXX Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Defining a Recurring or Permanent Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Defining a Milestone Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102 Using Scheduling Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105 OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OCCURS Clause Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Sample OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling Events on Holidays and Weekends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining an OCCURS Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

107 107 115 118 121

WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Job and Program WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WHEN Conditions for Multiple Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Extended Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WEAK Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . NOTDURING Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cross-platform Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Generic Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Multiple WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Specifying Started Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Zeke Variables as WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . WHEN Condition Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a WHEN Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing WHEN Conditions for All Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . .

124 124 124 124 126 127 129 130 130 131 131 133 139 140

Condition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Defining Condition Codes for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using Variables in Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Completing Work Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

149 150 151 155

Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Defining Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160 Managing Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Accessing Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165 Maintaining Scratch Pad or Note Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168 iii

ASG-Zeke Scheduling for z/OS User’s Guide

Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Maintaining Dataset Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170 Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Viewing Event Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172 Maintaining Job Duration Statistics, Alerts, and Failures. . . . . . . . . . . . . . . . . . . . . . . 174

Chapter 5:

Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 181 Logical Day (48-hour Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Creating the Zeke Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183 Creating the Schedule Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184 Creating the Schedule Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Downloading the Schedule to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186 Forecasting and Simulating the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Forecasting the Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 Simulating the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188 Creating and Adding an Event to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191 Using Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Schedule View Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Updating a Scheduled Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Displaying or Updating an Event Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing Event Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing an Expanded SQR (Using ZOOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Customizing Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Other Zeke Online Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Managing JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

191 191 200 203 206 213 215 216 218 224 226

Zeke Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Early Warning Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 /ZCOM Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Modifying PF Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241 Manually Adding Events to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the ZADD Operator Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Using the ADD Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding Events By Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 6:

247 247 249 252

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 Physical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Initiator Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258 Defining Pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268

iv

Contents

Logical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining a Logical Resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Defining Resources for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting Resources for an Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 7:

271 272 274 277

Customizing and Maintaining Zeke. . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Zeke Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GENOPTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing the Zeke Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Adding a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Editing a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Viewing Pending GENOPT Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Deleting a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Reloading GENOPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Audit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dispatching Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Exit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . JCL Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Message Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Scheduling Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Interface Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Variables Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

280 280 281 287 290 291 293 295 296 297 309 309 312 319 320 324 325 325 326

Defining Schedule Download Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327 Obtaining Operating Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329

Chapter 8:

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. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

330 331 333 334 337 338

Continuous Job Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Terminating Zeke using ZKILL TRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMF Recording Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Applying Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SMF Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

340 341 341 344 344

Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345 Zeke Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting Zeke Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Maintaining Variable Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

346 346 346 351 v

ASG-Zeke Scheduling for z/OS User’s Guide

OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Naming OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Setting OASIS Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Temporary OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

355 357 357 358

System-dependent Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359 Uses for Zeke Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 9:

359 360 361 362 363 366 366

Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369 Preparing for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370 Zeke Security Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Security Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372 Security Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376 Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal Security Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Online Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operator Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Class Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Batch Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implementing Internal Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

377 377 378 379 379 380 380 380

External Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392 Security Classes and Resource Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393 Implementing External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398

Chapter 10: Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Web Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407 Accessing Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408 Setting Zeke Web Services as Your Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409 Managing Work Centers from the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessing Scheduled Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Creating and Maintaining Custom Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Completing a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Enabling or Disabling a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Refreshing a Work Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

409 409 412 418 423 424

Appendix A: Zeke “Agentless” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425 vi

Contents

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 Installation and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426 JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428 ZEKE6NOA Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430

Appendix B: Interface to ThruPut Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 Enabling the ThruPut Manager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431 ZEKECTL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432 Zeke Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433 ThruPut Manager Descriptors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436 $ZEKE_JECL_OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

vii

ASG-Zeke Scheduling for z/OS User’s Guide

viii

Preface

This ASG-Zeke Scheduling for z/OS User’s Guide explains the procedures for using ASG-Zeke Scheduling (herein called Zeke) for enterprise-wide workload management. 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, “Customizing and 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.

•

Chapter 10, “Zeke Web Services,” explains how to use Zeke Web Services (which enable you to access to work center functions from a Web browser instead of requiring you to establish access to Zeke through an online facility).

ix

ASG-Zeke Scheduling for z/OS User’s Guide

E-mail User Forum To share information, ask questions, receive tips, or compare notes, consider joining the Zeke e-mail user group, Autoops. It is easy to join and, if needed, easy to unsubscribe.

To subscribe to Autoops 

Visit the Autoops Info Page at http://usdenlist.asg.com/mailman/listinfo/autoops and complete the form under “Subscribing to Autoops”.

After your request is received, you will receive an e-mail confirming your membership. As a member, you will receive a copy of all new messages sent by other members of the group. An archive of past messages is also available on the Autoops Info Page.

Related Publications The documentation library for Zeke consists of these publications (where nn represents the product version number):

x

•

ASG-Zeke Scheduling for z/OS Enhancement Summary (AZM1000-nn) describes new Zeke features, updated functions, and performance improvements.

•

ASG-Zeke Scheduling for z/OS User’s Guide (AZM0200-nn) explains the procedures for using Zeke for enterprise scheduling.

•

ASG-Zeke Scheduling 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 Zeke.

•

ASG-Zeke Scheduling for z/OS Reference Guide (AZM0400-nn) provides a reference for using Zeke batch programs and operator commands, and for generating reports.

•

ASG-Zeke Scheduling 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 Enhancement Summary (AZO0100-nn) describes new OASIS features, updated functions, and performance improvements.

•

ASG-OASIS for z/OS Installation Guide (AZO0300-nn) provides information on installing ASG-OASIS (herein called OASIS), the framework for your ASG enterprise workload management (‘Z’) products.

•

ASG-OASIS for z/OS Reference Guide (AZO0400-nn) provides information on OASIS commands, options, and other functions.

Preface

•

ASG-OASIS Messages and Codes Guide (AZO1200-nn) lists and explains OASIS messages. It also provides return code explanations.

Note:

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

Publication Conventions ASG uses these conventions in technical publications: Convention

Usage

Arrow (  )

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).

xi

ASG-Zeke Scheduling for z/OS User’s Guide

Convention

Usage

lowercase italic monospace

Information that you provide according to your particular situation. For example, you would replace filename with the actual name of the file.

Monospace

Characters you must type exactly as they are shown (e.g., code, JCL, file listings, or command/statement syntax). Also used for denoting brief examples in a paragraph.

Underline

Denotes a cursor-selectable field or line.

Vertical separator bar ( | ) with underline

Indicates options available with the default value underlined (e.g., Y|N).

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 nonbusiness 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

xii

Preface

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. This table outlines the support response times you can expect:

Meaning

Expected Support Response Time

1

Production down, critical situation

Within 30 minutes

2

Major component of product disabled

Within 2 hours

3

Problem with the product, but customer has work-around solution

Within 4 hours

4

“How-to” questions and enhancement requests

Within 4 hours

Severity

Product Support Policy ASG fully supports the current release and one previous release of each of its products. ASG will temporarily support an older release, for up to six months, to provide time for you to upgrade. Once programming support for a product release is withdrawn, ASG will no longer supply new fixes for problems nor accept enhancement requests for that release. When a vendor announces the end of support for system software or a hardware configuration on which ASG products rely, ASG will make a similar announcement regarding the support plans for its products. ASG’s support for problems affected by system software release levels will terminate when the vendor no longer supports their hardware or software. Announcements regarding support plans for various products can be found on ASG’s Web site. Support for Field-developed Interfaces (FDIs) developed by ASG’s Professional Services staff is described in ASG Professional Services FDI Support Guide that can be found on the ASG Support Web site in the Guide to Support section. This document describes how FDIs are supported by ASG Customer Support and ASG Worldwide Professional Services.

xiii

ASG-Zeke Scheduling for z/OS User’s Guide

ASG Documentation/Product Enhancements Submit all product and documentation suggestions to ASG’s 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 publication’s front cover.

xiv

Chapter 1:

Introducing Zeke

1 This chapter provides an overview of Zeke and contains these topics: Topic Introducing Zeke OASIS Zeke Processing (Multisystem Support) Online Facilities

Page 2 2 2 3

Event Management Event Terminology Event Scheduling Event Dispatching Event Activity Accounting

3 4 8 9 12

Schedule Monitoring and Intervention Schedule View Operator Commands (ZCOM Option) PathFinder Job Restart/Rerun Web Services Workload Management

12 13 13 14 14 14 15

Configuration and Maintenance Generation Options Database Maintenance Security

16 16 16 17

Batch Utilities ZEKE Batch Utility Report Writer Auditing ZEKESET Utility ZEKEXUTL Import/Export Utility

17 17 18 18 19 20

Zeke Interfaces to other ASG Products ‘Z’ Products Cross-platform Schedule Management JCL Validation Workload Analysis and Planning ASG-Automation Center (Problem Tracking Support) ASG-Cortex-Pdb Plug to Zeke

20 20 21 22 22 23 23 1

ASG-Zeke Scheduling for z/OS User’s Guide

Introducing Zeke You use Zeke to define and maintain the database of events (i.e., computer processes) that run in your data center. Zeke automates your production workload by dynamically scheduling and dispatching events. It monitors all aspects of your processing schedule to optimize performance and efficiency, while also providing you with data processing control and flexibility. Zeke is supported on z/OS and VSE operating systems and extends its functions to many other distributed platforms.

OASIS OASIS—Open Architecture System Integration Solution—is the subsystem that provides the common functions for your ASG enterprise workload management ‘Z’ products. OASIS/Distributed Management Server (DMS) enables Zeke to communicate with other Zekes running on different systems or platforms, as well as enabling cross-platform scheduling (see “Cross-platform Schedule Management” on page 21).

Zeke Processing (Multisystem Support) Database Sharing Zeke can schedule up to 24 computer systems from a single Zeke database (any combination of VSE, CMS, and z/OS systems can share a database). This capability enables multiple operating systems to communicate about events occurring on one system that might affect events on other systems. All Zeke systems that share the same database register at startup and check out on termination. When a system becomes active again, recovery is automatic. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information.

PolyZeke OASIS enables multiple copies or versions of Zeke to operate on a single z/OS operating system. PolyZeke facilitates testing a new release on a single CPU or supporting multiple users with separate Zeke databases.

2

1 Introducing Zeke

Note:

Although multiple Zekes (at the same release level) can reference the same database, ASG strongly recommends that multiple Zekes running on the same system each have a separate database. 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 enables the same applications to access more than one database. By providing users with a separate Zeke database to decentralize Zeke, you can prevent users from accessing, or possibly corrupting, other production databases. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information.

Online Facilities Zeke’s online facility is a full-screen, menu-driven system that makes schedule management easy. The Zeke online facility runs under these environments: •

CICS

•

IDMS

•

CMS

•

TSO

•

ROSCOE

•

ISPF

Zeke provides full security for its online facility and allows authorized only users to access the scheduling database. You can set up different levels of access for each authorized operator. See “Security” on page 17 for more information.

Event Management You can define events to the Zeke database through the Zeke online system or using the ZEKE batch utility program. The database retains this information about each event: •

Detailed scheduling information (i.e., OCCURS clause)

•

Prerequisite conditions (i.e., schedule time and WHEN conditions)

•

Resource requirements (i.e., number of tape drives and, initiator class)

3

ASG-Zeke Scheduling for z/OS User’s Guide

This information ensures that Zeke schedules the event properly and does not dispatch the event until the prerequisites have occurred and the required resources are available. Zeke provides a wide range of options for defining events and controlling how they are managed and processed.

Event Terminology This section provides an overview of some of the key concepts related to Zeke events.

Event Types These are the Zeke event types: Type

Description

JOB

Batch jobstream

MSG

Console message

WORK

Work center (i.e., an offline task that triggers other system-related events)

VCOM

VM/CP command

ZCOM

Zeke operator command

SCOM

System command or system response.

PCOM

(VSE only) POWER command

REXX

(z/OS only) REXX EXEC

Event Master Records (EMRs) Zeke reads and interprets the event definitions in the Zeke database, which are known as event master records (EMRs). You can create EMRs from scratch or from a template or copy of another event. The EMR contains 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. See “Event Master Record (EMRs)” on page 52 for more information.

4

1 Introducing Zeke

Schedule Queue Records (SQRs) When you run the SCHEDULE function of the ZEKE batch utility program to create the daily schedule, it uses the EMR to create a temporary schedule record for each event. You can modify these records, called schedule queue records (SQRs), for that particular run (without affecting the EMR).

Event Versions (Multiple SQRs) Zeke can support concurrent schedules using the same events (versions). You can define an event to have multiple versions, where multiple SQRs have the same schedule date. Each version shares the same scheduling criteria, but can have different prerequisites. Most Zeke operator commands can select events by version number for processing, and Zeke can satisfy prerequisites based on version numbers. See “Creating Multiple Versions of an Event” on page 76 for more information.

Recurring, Permanent, and Milestone Events You can define an event 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. You can set a recurring event to trigger another event each time it runs, or you can set it to trigger only on the first or last occurrence. A permanent event is never removed from the schedule, so 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 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. See “Defining a Recurring or Permanent Event” on page 97 and “Defining a Milestone Event” on page 102 for more information.

Critical Path Milestone events are an essential element in the concept of a critical path. The critical path is the sequence of predecessor/successor events that will take the longest to complete. The critical path represents the minimum amount of time to complete the event flow from the event with the earliest start through the event that finishes last. The critical path could change from time to time as events are completed ahead of or behind schedule. Typically, delays along the critical path imply that additional time is required to complete the event flow. This information helps you monitor the completion of the current schedule to ensure there is no conflict with the start of the next schedule.

5

ASG-Zeke Scheduling for z/OS User’s Guide

Nonexecutable Events You can define an event as nonexecutable, simply to use it as a predecessor to other events. Zeke schedules nonexecutable events just like any other event, but never submits the event to JES for JCL execution. After “dispatching” the event, Zeke automatically updates its status to Success and triggers any dependent events. From the EMR or Schedule View, or using a Zeke operator command, you can flag an event in an intricate event flow as nonexecutable without having to change the event flow. This action helps to eliminate the need to delete an event and change all of its successors’ prerequisites.

Remote Job Events Zeke provides efficient job routing and can schedule and dispatch job events for processing across systems or on other platforms and then continue to track those events. The EMR enables you to specify the platform and the target system.

External Job Events You can define job events that will come from an external source. This type of job event does not have JCL; instead, its EMR indicates that the JCL is contained in the JES job queue. This enables jobs that originate from any source to still be dispatched and tracked like any other Zeke event.

Job Events Downloaded to ASG-Zeke Agent Zeke enables you to download a subset of scheduled jobs in the Zeke schedule cross-platform to ASG-Zeke Agent (herein called Zeke Agent), which then tracks and dispatches the SQRs in the same manner as Zeke. 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 also can schedule an individual event directly to a Zeke Agent system running on another platform. Zeke Agent can receive, track, schedule, execute, and reroute a scheduled job from Zeke (or another source) to another platform in your enterprise, as necessary. See “Downloading a Job Event to Zeke Agent” on page 83 for more information.

6

1 Introducing Zeke

On-Request Events You can define on-request events in the Zeke database, which enables you to add them to the schedule (as needed) using an operator command. Zeke dispatches these events as if they were scheduled normally (including checking prerequisites and resource requirements).

JCL Sources Zeke provides simultaneous support for multiple JCL libraries. Zeke can retrieve JCL from any of these sources: •

Bim-Edit

•

CA Driver

•

CA Librarian

•

CA Panvalet

•

CA Vollie

•

Condor

•

JCLMAN

•

ICCF

•

OWL

•

VM/CMS file

•

VSE/POWER SLI

•

Zeke JCL

Event Documentation Zeke enables you to provide full documentation of an event through these facilities: •

Text facility (which retains a sizeable amount of text)

•

Scratch pad and note facilities (which provide an easy method for leaving short notes for an operator)

•

Dataset facility (which displays the volume serial numbers and datasets required to run a job)

See “Event Documentation” on page 164 for more information.

7

ASG-Zeke Scheduling for z/OS User’s Guide

Work Centers Zeke enables you to define associated offline tasks, called work centers, and schedule their completion by relating them to online tasks and integrating them with processes occurring throughout the Zeke system. When you create a work center, you associate it with a user ID, which specifies the operator responsible for completing or validating the offline task. You can issue a Zeke operator command or run a batch report to list the scheduled work centers by user ID. When an operator flags the event as completed, Zeke removes it from the display, sets any variables (as necessary), and triggers any dependent events. See “Work Centers” on page 149 for more information.

Event Scheduling Zeke’s scheduling function uses the EMRs to create a processing schedule for each Zeke system. The SCHEDULE function, which you typically run at the start of each workday, removes the previous day’s completed events and adds the current day’s events. Zeke adds an event to the schedule if the scheduling criteria are met or when it receives an operator request. See Chapter 4, “Events,” on page 51 for more information.

Calendars Calendars enable you to customize your processing schedule. You simply set up one or two standard calendars to distinguish among workdays, weekends, and holidays. Typically, one standard calendar is all you need for most events; however, you also can create user accounting calendars to tie events to the periods of your accounting year and special calendars for those events with random scheduling criteria. Zeke provides predefined calendars that accommodate most scheduling situations (including perpetual calendars that enable you to define dates far into the future). See Chapter 3, “Calendars,” on page 39 for more information.

Schedule Time Schedule time is an optional dispatching prerequisite that must be met before a scheduled event can be dispatched. You specify schedule time options in the EMR (see “Time Requirements” on page 9).

8

1 Introducing Zeke

Logical Day (DaySpan) Zeke supports a 48-hour clock, which enables you to schedule according to a logical day (known as DaySpan). If you have events that run past midnight, you still can consider those events to be part of the previous day’s 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, Zeke selects each event that has an OCCURS clause that matches Monday and a schedule time between 00:00 and 47:59. Zeke nevers dispatches an event with a schedule time of 48:00 because 47:59 is the dispatching cutoff time. You can 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. See “Logical Day (48-hour Clock)” on page 182 for more information.

OCCURS Clauses Zeke determines when to add an event to the schedule based on the event’s OCCURS clause. The OCCURS clause contains keywords (e.g., DAILY, WORKDAYS, MONDAY, JANUARY, WEEKENDS, and HOLIDAY) that indicate when to schedule the event. See “OCCURS Clauses” on page 107 for more information.

Event Dispatching Zeke monitors system activities to detect actions that will trigger an event. When an event’s scheduled time is reached and its prerequisites have occurred, Zeke places the event 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 any optional dispatch requirements are met (e.g., an operator approval).

Time Requirements As an optional dispatching prerequisite, Zeke enables you to place restrictions on the time of day that Zeke can execute an event. You can specify any of these schedule time requirements that must be met before Zeke dispatches an event: •

Earliest time that Zeke can dispatch the event (i.e., early time)

•

Latest time that Zeke can dispatch the event (i.e., not after time)

•

Latest time by which the event must be completed (i.e., must end time)

9

ASG-Zeke Scheduling for z/OS User’s Guide

•

Time at which Zeke considers the event late (based on its start time) (i.e., late start time)

•

Time at which Zeke considers the event late (based on its end time) (i.e., late end time)

If the time the event is dispatched does not matter, you do not need to use these options. See “Specifying a Schedule Time” on page 73 for more information.

WHEN Conditions Similar to an OCCURS clause, a WHEN condition is a statement containing keywords that indicate prerequisites that Zeke must validate before dispatching a particular event. Zeke can make dispatching of an event contingent on any combination of these circumstances: •

Normal or abnormal end for these occurrences: —

A job

—

A job step

—

A program

—

An event

—

A group of events

•

Beginning of a job or program

•

Close of an output dataset

•

Current execution of a job or program

•

Availability of variables or resources

Cross-platform Scheduling Dependencies Zeke provides cross-system triggering by enabling certain WHEN conditions to be satisfied based on remote jobs. Cross-platform scheduling dependencies are prerequisites that are satisfied based on a job that runs on a remote system (i.e., a Zeke system or another scheduler, such as ASG-Zena).

Extended Dependencies Two WHEN conditions, XEOJ and XEOE, provide the ability to trigger jobs across multiple schedules. For example: JOB_A is dependent on JOB_B (which ran a few weeks ago). You can use the XEOJ keyword to locate JOB_B in the Zeke database and determine whether it has run since the last time JOB_A ran.

10

1 Introducing Zeke

See “WHEN Conditions” on page 124 for more information.

Resource Checking Zeke checks resource requirements and availability before dispatching an event. You define physical resources (e.g., number of tape drives and initiator class) in the EMR. You define logical resources in the Zeke database. Zeke enables you to specify the days and times each initiator is available for processing and then dynamically selects the systems and initiators to use. Zeke also compares resource names across systems to prevent an excessive number of events from using the same resource. As required, Zeke also ensures that the correct number of tape drives are available before dispatching an event. See Chapter 6, “Resources,” on page 257 for more information.

Condition Code Validation Through SMF, Zeke checks and validates individual job and step-level condition codes during job processing to determine whether a job should be cancelled or marked as abended based on the condition codes (or return codes). You define an unlimited number of condition codes for an event in the EMR through the online facility. See “Condition Codes” on page 143 for more information.

Variables Zeke automates variable calculation and substitution. You can use variables to perform or enable a variety of specialized operations automatically: •

Controlling jobstream flows (i.e., bypassing segments)

•

Triggering other events

•

Preventing other events from occurring

•

Documenting cancellation reasons

•

Substituting values in z/OS and JES JCL statements at execution time

•

Automating JCL modifications

•

Triggering event scheduling and dispatching

•

Responding to console data

11

ASG-Zeke Scheduling for z/OS User’s Guide

You can use OASIS variables in the same areas as Zeke variables. Because they reside in an OASIS database on DASD, OASIS variables are retained across system outages and IPLs. Because the OASIS database is accessible to all of your ‘Z’ products that use the same subsystem, you can use OASIS variables to communicate information between your ‘Z’ products. OASIS has its own online facility for maintaining variables. See the ASG-OASIS for z/OS Reference Guide for more information. See Chapter 8, “Variables,” on page 345 for more information.

Auto Replies Automatic replies (i.e., auto replies) enable you to predefine responses and then respond automatically to outstanding messages from your Zeke events that have static or predictable responses, or job events that require intervention. When a message is issued, Zeke responds to the console read with the predefined reply (substituting any variables before the reply is issued). See “Auto Replies” on page 159 for more information.

Event Activity Accounting Zeke provides you with a record of event accounting information so that you can view the last date and time an EMR was updated and by whom. Event accounting also includes information concerning the last three dispatches of the event, the average duration of the event, and the normal range of durations for the event. By calculating and monitoring event duration, Zeke enables you to determine acceptable ranges and then generates alerts when exceptions occur. See “Event Activity Accounting” on page 172 for more information.

Schedule Monitoring and Intervention After your events are defined to Zeke, you are ready to create the schedule. You can monitor the progress of your scheduled events, as well as intervene and make changes, through the ISPF online Schedule View function. See Chapter 5, “Creating and Monitoring the Schedule,” on page 181.

12

1 Introducing Zeke

Schedule View Schedule View, available only through ISPF, displays all relevant information for the currently scheduled events on a single screen and highlights exceptions automatically. From this display, you can monitor and make changes using simple line commands. (You also can issue Zeke operator commands from Schedule View.) 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. Changes to display characteristics are valid for the current user and are saved in the user’s ISPF profile. Each user can set up Schedule View according to their preferences. The ZOOM feature enables you to view or edit the information in the EMR that was used to build the SQR for a selected event. Note:

Any changes you make to a SQR are temporary and only for the current schedule run (no changes are made to the EMR). For jobs, you can display messages from a job’s JOBMSG and SYSMSG files to aid in problem resolution and speed the restart process. Schedule View also enables authorized users to access to a copy of the executable JCL for one-time overrides (to update parameters and correct abends); Zeke attaches the updated copy to the event’s schedule entry for subsequent runs. See “Using Schedule View” on page 191 for more information.

Operator Commands (ZCOM Option) Zeke provides a full range of operator commands to monitor schedule processing and intervene, as necessary. You can issue Zeke operator commands through any authorized operating system console (similar to JES commands), or through the ZCOM option in the online facility. These are some of the common operations that you can perform using Zeke operator commands: •

Add an event to the schedule

•

Delete an event from the schedule

•

Display or update information for a scheduled event

•

Override or validate JCL

•

Display event statuses, predecessor and successor events, and remote prerequisites

•

Provide an operator approval

•

Enable or disable a scheduled event, or refresh an event

13

ASG-Zeke Scheduling for z/OS User’s Guide

•

Place a hold (on an event, an initiator, or the Zeke system), or release a hold

•

Display database information, or disable electronic vaulting

•

Display information about an initiator, or update its availability

•

Display, enable, or disable automatic replies

•

Display information on variables, or set a value

•

Display generation options, or reload updated options

•

Display tracing messages

•

Terminate Zeke

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using the ZEKE batch utility.

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 it runs. Additionally, PathFinder can help you uncover predecessor loop conditions. See “PathFinder” on page 241 for more information.

Job Restart/Rerun You can specify the necessary restart parameters (including what type of restart should be performed after the restart package's database is updated). See “ASG-Zebb (Automated Job Restart/Rerun)” on page 21 for more information.

Web Services Web Services enable you to access to work center functions from a Web browser instead of requiring you to establish access to Zeke through an online facility (e.g., TSO or ISPF) or an OpsCentral client. Web Services takes advantage of the Zeke server to enable remote access to Zeke from a Web browser using Hypertext Transport Protocol (HTTP). Access to Zeke through a Web browser can be secured (i.e,. through SAF) or unsecured (i.e., controlled based only on the default operator ID). See Chapter 10, “Zeke Web Services,” on page 407 for more information.

14

1 Introducing Zeke

Workload Management Whether you have one system, or multiple systems worldwide, Zeke optimizes your workload by providing workload balancing and efficiency. Zeke provides effective real-time, logical and physical resource management and control (see “Resource Checking” on page 11). Logical Pooling. Multiple CPUs (real and virtual) can share a single Zeke database. Each 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 the system to be used for each event based on the system or pool defined for the event and also selects the initiator within that system. See Chapter 6, “Resources,” on page 257 for mor information. Scheduling Environments. Zeke supports IBM Workload Manager (WLM) scheduling environments for dispatching all Zeke event types. You can define Zeke as a resource in a WLM scheduling environment. See Chapter 6, “Resources,” on page 257 for mor information. Continuous Tracking. Zeke can track certain relevant system and event activity, even during periods when both Zeke and the OASIS subsystem have been terminated (e.g., to apply maintenance). These are the types of activity that Zeke tracks in recording mode: •

Starting of jobs, job steps, and programs

•

Ending of jobs, job steps, and programs

•

Datasets that are closed

When it restarts, Zeke uses the recorded activities to update the schedule, as appropriate (e.g., Zeke satisfies triggers for jobs that completed while Zeke and/or OASIS were inactive). See “Continuous Job Tracking” on page 340 for more information. Forecasting and 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 (e.g., specifying tape drive and initiator quantities, reporting, and message generation) without affecting the actual schedule. See “Forecasting and Simulating the Schedule” on page 187 for more information.

15

ASG-Zeke Scheduling for z/OS User’s Guide

Configuration and Maintenance This section describes some of the key functions that provide Zeke customization and maintenance options.

Generation Options Generation options enable you to configure the operating criteria for your environment. No two data centers are exactly the same, and, typically, no two systems are identical within an environment. Zeke enables you to configure separate systems with different generation options for each one. A collection of generation options is referred to as a GENOPT table or GENOPT. You can use GENOPTs to group together specific generation option settings that control a particular system or that you want to be used across multiple systems. You can create new GENOPTs, or Zeke provides default GENOPTs that you can customize or copy. See “Zeke Generation Options” on page 280 for more information. See the ASG-Zeke Scheduling for Z/OS Reference Guide for details on using the ZEKE batch utility for maintaining GENOPTs.

Database Maintenance Database maintenance includes these tasks: •

Allocating and cataloging datasets.

•

Backing up the database. Note:

ASG recommends you use the BACKUP command of the ZEKE utility program to back up your database at least daily. •

Moving or enlarging a database.

•

Recovering from a hardware failure.

•

Recovering the contents of a destroyed database.

•

Running Zeke using electronic vaulting.

For an existing database, you can generate a database status report that provides details about the database (e.g., its size and event capacity, and the dates it was created, last backed up, and last restored). See “Database Maintenance” on page 330 for more information. 16

1 Introducing Zeke

See the ASG-Zeke Scheduling for Z/OS Reference Guide for details on using the ZEKE batch utility for performing database maintenance tasks.

Disaster Recovery As part of a disaster recovery plan, electronic vaulting provides the ability to allocate a secondary DASD unit and maintain a copy of the Zeke database that is no more than one I/O behind the primary database. When Zeke writes a record to the primary database, the electronic vaulting option writes a duplicate record to the secondary vault dataset.

Security You can define Zeke security using its internal security function or through the OASIS External Security Interface (ESI). Zeke’s versatility enables you to control access to Zeke objects and functions from another vendor’s security product, or your own, as long as the product uses the System Authorization Facility (SAF) interface. You even can use a combination of internal and external security packages. ASG recommends that you understand Zeke internal and external security features completely before implementing either (or both). Zeke supports SAF security through the OASIS/External Security Interface (ESI). ESI provides the ability to use a third-party security product (e.g., RACF or CA-ACF2) to control access to Zeke or other installed OASIS-supported ‘Z’ products. See Chapter 9, “Security,” on page 369 for instructions on implementing Zeke security. See the ASG-OASIS for z/OS Reference Guide for more information on ESI.

Batch Utilities This section describes the Zeke batch utility programs.

ZEKE Batch Utility The ZEKE batch utility provides batch functions that enable you to perform these Zeke scheduling and maintenance tasks: •

Scheduling tasks: —

Create the daily schedule.

—

Generate schedule reports.

—

Create a simulation of the Zeke schedule. 17

ASG-Zeke Scheduling for z/OS User’s Guide

•

Maintenance tasks: —

Create, back up, and restore the Zeke database (or restore an individual EMR from a backup file), or generate a database status report.

—

Add, update, and delete calendars.

—

Add, update, and delete event definitions.

—

Add and delete local GENOPTs (and update specific field values).

—

Copy documentation or JCL from an outside source into the Zeke database.

—

Update your customer ID or Zeke password.

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using the ZEKE batch utility.

Report Writer The Report Writer facility enables you to create and customize your own reports based on information extracted from the Zeke database, as well as generate standard reports. These are the types of reports you can produce: •

Event (EMR) listings

•

Scheduled event (SQR) listings

•

Variable listings

•

Calendar listings

•

GENOPT listings (including option values)

•

Security class listings

•

Operator ID listings

•

Resource listings

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using Report Writer.

Auditing Zeke tracks database activity and logs the information. You define the actions be logged through the Zeke generation options. You can generate audit reports using the AUDIT utility. These are the types of actions that you can have audited and logged: • 18

Operator commands that are issued from the console and the online facility

1 Introducing Zeke

•

Changes to any of these elements: —

Event status

—

Variable value

—

EMR

—

SQR

—

Internal security operator or class record

—

Calendar record

—

External security class definition record

—

Resource definition record

—

Pool record

—

Generation option

—

Your company name or address

—

Password

See “Audit Options” on page 296 for more information on setting audit options. See the ASG-OASIS for z/OS Reference Guide for more information on using the AUDIT utility.

ZEKESET Utility You can control jobstream flow by using the ZEKESET utility to perform these tasks: •

Set variables

•

Set the step condition code

•

Set a user abend code

•

Execute Zeke operator commands

•

Execute z/OS commands, JES commands, or VM commands

The ZEKESET batch utility enables extensive date manipulation and calculation using Zeke variables, which provides the ability to create any desired format based on dates. When used together with variable substitution, this utility can automatically create program date cards. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using the ZEKE batch utility.

19

ASG-Zeke Scheduling for z/OS User’s Guide

ZEKEXUTL Import/Export Utility Zeke provides import/export facilities to ease migration across Zeke implementations or move from test to production environments. You use the import/export utility program ZEKEXUTL to perform these procedures: •

Export these types of Zeke database records as XML data: —

Event master records (EMR)

—

Variable records (VAR)

—

Calendar records (CAL)

•

Import event, variable, and calendar XML records into the Zeke database.

•

Change key values in the records being imported or exported.

Filtering control statements enable you to select which records to import or export. Change control statements enable you to change fields within the records being imported or exported. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using the ZEKE batch utility.

Zeke Interfaces to other ASG Products Zeke extends its workload management functions by providing interfaces with several additional ASG products.

‘Z’ Products These are the OASIS-supported, enterprise workload management, or ‘Z’ products.

ASG-Zack (Automated Operations) Zeke includes interfaces to the automated console operator product ASG-Zack (herein called Zack). Zack shares the same OASIS subsystem and works with Zeke to ensure maximum data center efficiency.

ASG-Zara (Automated 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.

20

1 Introducing Zeke

ASG-Zebb (Automated Job Restart/Rerun) The Zeke 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 SQR status changes) to Zebb so that Zebb can make the appropriate changes to its database. Likewise, Zebb uses OASIS to communicate back to Zeke.

Cross-platform Schedule Management These ASG products extend Zeke’s cross-platform schedule management capabilities.

Zeke Agent Zeke Agent provides a mainframe-centric approach to enterprise scheduling and enables cross-platform schedule downloading. You can download a subset of scheduled jobs in the Zeke schedule (across platforms) to Zeke Agent, which then dispatches and tracks the SQRs in the same manner as Zeke. 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 also can schedule and dispatch specified job events to be sent one at a time to a Zeke Agent running on another platform. Zeke Agent can receive, execute, track, and even reroute the jobs from Zeke (or another source) to another system, as necessary. Note:

See Appendix A, “Zeke “Agentless”,” on page 425 for details on how to run Zeke jobs on other platforms without implementing DMS or a Zeke Agent on the target system.

ASG-Zena Zeke communicates via Zeke Agent for Windows with ASG-Zena (herein called Zena), the distributed workload management and process automation 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.

21

ASG-Zeke Scheduling for z/OS User’s Guide

ASG-OpsCentral ASG-OpsCentral (herein called OpsCentral) enables centralized management of enterprise scheduling workloads from a client workstation. The ASG-Zeke Scheduling Plug-ins for OpsCentral maintain communication between your Zekes and OpsCentral and enable Zeke functions to be available under the OpsCentral client console.

JCL Validation Zeke provides several ways to scan the JCL associated with your jobs events for accuracy. These ASG products provide JCL validation services:

ASG-JCLPREP 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.

ASG-JOB/SCAN ASG-JOB/SCAN is a JCL validation and standards enforcement tool that helps single LPAR data centers (with COBOL or Assembler expertise for JCL standards programs) operate an error-free production JCL environment. Maintaining JCL through its lifecycle is vital to any IT operation, but especially when running mission-critical applications driven by JCL on z/OS. Using ASG-JOB/SCAN, you 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/JCL ASG-PRO/JCL is an advanced JCL validation and standards enforcement tool that helps multiple LPAR data centers (with REXX expertise for JCL standards programs) achieve and operate an error-free, standardized, and optimized production JCL environment.

Workload Analysis and Planning These ASG products provide workload analysis and planning.

22

1 Introducing Zeke

ASG-Workload Analyzer ASG-Workload Analyzer is a PC-based analysis tool that tracks and analyzes batch processing performance, detects problem areas, and presents an analysis of processing in a graphic format that is easy to understand. Workload Analyzer reduces the need for 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 SMF, thereby expediting analysis of processing trends, resolving bottlenecks, and improving operational productivity in a z/OS environment.

ASG-Workload Planner ASG-Workload Planner helps you to better understand complex schedules from a variety of mainframe scheduling systems. Workload Planner extracts information from a scheduling system database and translates it into interactive, comprehensive or specialized graphic flowcharts of your workflow, including ones that predict the performance of schedule processing.

ASG-Automation Center (Problem Tracking Support) Zeke provides problem tracking support through a user exit to interface with ASG-Automation Center (herein called Automation Center), or by interfacing with third-party problem tracking systems. The problem tracking interfacing user exit ZEKE03X 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 Automation Center, when an event ends abnormally, the exit calls Automation Center 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.

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-Zeke Scheduling for z/OS User’s Guide

24

Chapter 2:

2

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 access and exit the Zeke online system. It contains these topics: Topic

Page

Starting Zeke

26

Restarting Zeke

27

Starting OASIS Only

27

Starting Multiple Tasks

28

Terminating OASIS

30

Terminating Zeke

31

Using the ISPF Interface ISPF Features General Screen Information Logging On and Off Changing the ISPF Color Scheme

32 32 33 33 36

Starting the Zeke Online Facility under TSO

38

25

ASG-Zeke Scheduling for z/OS User’s Guide

Starting Zeke The SSS4001 program initializes Zeke. If the specified OASIS subsystem is not initialized already, then SSS4001 initializes it first.

To start Zeke 

Submit a job similar to this one:

//ZEKE PROC R=0M,S=Z600, // XP=ZEKECOM,OASIS=(aa,bb), // ZK=YES //STEPNAME EXEC PGM=SSS4ØØ1,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=* //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name * //xxxxxxxx DD DISP=SHR,DSN=any necessary DD statements

where: Code

Meaning

aa

OASISxx options member name suffix.

bb

Console option. Note: This controls console display and conversation only; the options always are listed in the JESMSGLG and SYSLOG. These are the valid options:

26

L

List all option values on the console.

C

Start an operator dialogue (e.g., to list the values, override values for this startup, or cancel the startup); do not list option values on the console.

LC

List all option values on the console, then start an operator dialogue.

N

(Neither) Default. Do not list option values on the console and do not start an operator dialogue.

2 Starting Zeke and Using the Online Facility

Restarting Zeke Normally, if a Zeke started task subtask is terminated, the subtask is restarted automatically (an informational message is issued when this occurs). If a subtask terminates numerous times, this indicates a serious error and the subtask is not restarted. If this occurs, ASG recommends that you terminate Zeke and correct the problem before trying to restart Zeke. If multiple OASIS-supported ‘Z’ products are active in a single address space and you terminate Zeke using the ZKILL command (WARM or COLD), or using the MVS system command STOP, then you can execute the same Zeke procedure that you used to initialize the same address space.

To restart Zeke when OASIS is already running 

Issue the START ZEKE command from the operator console. Or

Issue an MVS system MODIFY command to the address space using this syntax: F procname STPROD ZEKE

When you start Zeke, the Zeke address space locates its schedule tables (either in common storage or in a data space) and determines whether to perform a WARM or COLD start.

Starting OASIS Only You can start OASIS without starting Zeke. Typically, this is done when you need to create a Zeke database.

To start the OASIS subsystem 

Issue the START command using this syntax: START procname,S=subsys,OASIS='(aa,bb)'

where: procname is the name of the OASIS start-up procedure. subsys is the OASIS subsystem name. (aa,bb) is the OASISxx options member name suffix and console option.

27

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

If the start-up procedure provides values for the S and OASIS symbolic parameters, you can omit those parameters from the START command. This is an example of a typical OASIS startup and the messages issued in response to the command:

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 X300A000 z/OS 1.10 JES2 X00903I OASIS command processor enabled

Starting Multiple Tasks These examples illustrate the modifications made to the Zeke started task, the ZEKE batch utility program (ZEKEUTL), and the OASIS procedures for an alternate subsystem name of ZDOC. See the ASG-OASIS for z/OS Installation Guide for more information on modifying the Zeke and OASIS procedures to run multiple versions of Zeke on a single operating system. This example shows the modified Zeke started task procedure:

//* ZEKE : ALTERNATE STARTED TASK PROC //ZK56ALT PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS300 //ZK56ALT EXEC PGM=SSS4001,REGION=&R, // TIME=1440,PARM=’OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END’ //SYSPRINT DD SYSOUT=* //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name * //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 * //*

28

2 Starting Zeke and Using the Online Facility

Each Zeke must have its own unique ZEKExx and OASISxx options members. In each Zeke started task procedure, change the these parameters: OASIS=(00,L) ZEKE=(00,L)

to: OASIS=(xx,L) ZEKE=(xx,L)

where xx is the last two characters of the OASISxx or ZEKExx options member for that particular Zeke. This example shows the modified ZEKE batch utility (ZEKEUTL) procedure:

//* ZEKE //ZEKEUTL //ZUTL //ZEKECAT //STEPLIB // //SYSPRINT //SYSMDUMP //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 DISP=SHR,DSN=* Your Dump Dataset Name * 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

This example shows the modified OASIS started task procedure:

//* ZEKE //OASISALT //OASISALT //PARMLIB //SYSPRINT //SYSMDUMP //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 DISP=SHR,DSN=* Your Dump Dataset Name * DD DISP=SHR,DSN=* Your Zeke Load Library Name * DD DISP=SHR,DSN=* Your OASIS Load Library Name *

29

ASG-Zeke Scheduling for z/OS User’s Guide

This example shows the changes to use a single Zeke started task procedure to access multiple Zeke database and OASIS subsystems:

//ZEKE PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS300, // 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=* //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name * //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 * //*

Use these Zeke startup commands to start the Zeke primary production system using an alternate database:

S ZEKE Starts PROD system S ZEKE,S=ZDOC,DB='ZEKE.TEST.DATABASE',OASIS=(01,L) Starts ALT database

Terminating OASIS Do not terminate OASIS if any other OASIS-supported ‘Z’ products are running in the same OASIS subsystem. You must terminate all products in the subsystem before you terminate OASIS. This is a sample jobstream to terminate OASIS (where xxxx is the subsystem):

//ZOASIS JOB //SOASIS EXEC //SYSPRINT DD //STEPLIB DD //SYSIN DD TERMINATE /*

30

,MSGLEVEL=(1,1),CLASS=A PROC=OASIS,REGION=1024K,S=xxxx SYSOUT=A DSN=OASIS.LINKLIB,DISP=SHR *

Screen Name Varies depending on screen purpose Primary Commands Zeke primary commands Varies by screen function Standard ISPF commands also are available Line Commands Zeke line commands Varies by screen function Standard ISPF commands also are 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

Operators: Actions: Stepname EOJ CC STEP01 STEP02

System: ZEQA

EQ NE LE LT GE GT F = Fail, C = Cancel, Procstep

Operator

GT NE

Event Name: ZEKE51TST6

RA =Range O = Ok - Range Low High 8 16

Action

F O

Logging On and Off This section explains how to access the Zeke ISPF online facility. Note:

All remaining online procedures in this publication start from the Zeke Primary Menu.

33

ASG-Zeke Scheduling for z/OS User’s Guide

To access the Zeke ISPF online facility 1

Access the ISPF Primary Option Menu: Menu

Utilities

Compilers

Options

Status

Help

TSO-Access

ASG

ISPF Primary Option Menu Option ===> ASG 0 1 2 3 4 5 6 7 8 9 10 11 S ASG

Settings View Edit Utilities Foreground Batch Command Dialog Test LM Facility IBM Products SCLM Workplace SDSF ASG

More: Terminal and user parameters Display source data or listings Create or change source data Perform utility functions Interactive language processing Submit job for language processing Enter TSO or Workstation commands Perform dialog testing Library administrator functions IBM program development products SW Configuration Library Manager ISPF Object/Action Workplace System Display and Search Facility ASG Product Panel

+ User ID . : Time. . . : Terminal. : Screen. . : Language. : Appl ID . : TSO logon : TSO prefix: System ID : MVS acct. : Release . :

ASGUSER 13:28 3278 1 ENGLISH ISR $TSASG TSOUSR SYSD ACCT ISPF 6.1

Enter X to Terminate using log/list defaults

2

Type ASG in the Option field and press Enter. The ASG Product Menu is displayed: -------------------------- ASG PRODUCT MENU ---------------------------------SELECTION ===> 5 ------ASG PRODUCTS------------------DESCRIPTION--------------------2 3 4 5 F PM

AFI STEST ESW zTEAM SMUF/APTS PRODMAN

-----MISC UTILITIES----A DASD/QUICKREF J JCLPREP Q MVS/QUICKREF C CICSPLEX D DB2 / Other ST SYSTOOLS TM TMON INFO CENTER X

34

EXIT

ASG-FAVORITES FOR MAXIMZING ISPF PRODUCTIVITY ALLEN SYSTEMS DEBUGGING FACILITY ASG-ESW EXISTING SYSTEMS WORKBENCH ZEKE, ZEBB AND ZARA SMUF/APAR PTF TRACKING PRODUCT-MANUFACTURING -------------DESCRIPTION--------------------DASD FREE SPACE INFORMATION OPTION S JCLPREP (JCL VALIDATOR) QUICK REF (ONLINE ERRORS/MESSAGES/SYNTAX) CICSPLEX SYSTEM MANAGER ADMIN, SPUFI, QMF, Ditto ... SYSTEM- AND SUBSYSTEM-TOOLS TMON INFO CENTER FOR DEVELOPER RETURN TO ISPF MAIN MENU

2 Starting Zeke and Using the Online Facility

3

Type 5 in the SELECTION field and press Enter. The ASG Product Selection Menu is displayed: ASG Product Selection Menu OPTION

===>

ZA ZB ZE ZR ZX

ASG-Zack ASG-Zebb ASG-Zeke ASG-Zara ASG-OASIS

-

WP WA

ASG-WP ASG-WA

- Workload Planner (BETA 44) - Workload Analyzer (BETA 45)

X

EXIT

Automated Operations Rerun/Restart Management Scheduling for z/OS Tape Management OASIS Variables and Audit

OASIS Subsystem ===> SSSI USERID - ASGUSER TIME - 13:26

- Return to previous menu

Enter END command to return to the previous menu. Copyright (C) 2012 Allen Systems Group, Inc. All rights reserved.

4

Enter ZE in the OPTION field.

5

Type the subsystem name 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

Z600A000

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) 2012 Allen Systems Group, Inc. All rights reserved.

6

From this menu, type the option number on the Option line and press Enter to select the corresponding online function.

35

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

If you have Zack (or the Zeke Automation Option) installed, the Automation— Fastpath Tables Maintenance option enables you to manage Fastpath and Autoreply tables in Zack (directly from Zeke). If Zack is active, the option activates the Zack Fastpath Table Maintenance function and displays a directory listing of table names, types (i.e., message, reply, dataset), and statistics, where you can add, browse, copy, delete, or edit a specific table. See the ASG-Zack publication library for more information.

To exit the Zeke ISPF online facility 

From the ASG-Zeke Primary Menu, type X on the Option line and press Enter. The ISPF Primary Option 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

Z600A000

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) 2012 Allen Systems Group, Inc. All rights reserved.

Changing the ISPF Color Scheme Zeke enables you to control the colors that display on your Zeke ISPF online screens. The color and attributes that you choose affect only your logon ID and remain in effect until you change them again. You can use the INIT command to reset the colors back to the default values.

36

2 Starting Zeke and Using the Online Facility

To change Zeke ISPF online screen colors 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:

User Color Select Screen

INIT SAVE

Description

Color

Hilite

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

________ ________ ________ ________ ________ ________ ________ ________ ________ ________ ________

________ ________

________ ________ ________ ________ ________ ________ ________

Colors: Red, Blue, Green, Yellow, White, Pink, Turq Hilite Keywords: Reverse, Uscore, Blink, or leave blank

2

Consider the types of data you want to change. This table provides is a description of each type: Data Type

Description

Screen Title

First line of the screen.

Field and Column Heading

Labels that identify the fields. Field names and 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).

Normal Text

Descriptive or narrative text that usually explains or introduces other information displayed on the screen.

Accented Text

Descriptive or narrative text that is highlighted for emphasis (e.g., the line command abbreviation to enter in the Select field).

Normal Output Data

Displayed information that has been entered previously, or has been calculated by the system.

Accented Output Text

Displayed information that has been entered previously, or has been calculated by the system (and has been highlighted for emphasis).

Normal Input Data

Fields available for entry. 37

ASG-Zeke Scheduling for z/OS User’s Guide

Data Type

Description

Accented Input Data

Fields available for entry (and highlighted for emphasis).

Input Field In Error

Not used.

Warning Field

Not used.

Exception Field

Not used.

3

In the Color field, enter the first letter of the color you want to use.

4

In the Hilite field, enter the first letter of the attribute you want to use.

5

Enter SAVE on the Command line and press Enter.

Starting the Zeke Online Facility under TSO The module ZEKEOL controls the Zeke TSO online facility. This module (and others that make up the complete online system) is in the Zeke SZEKLMD0 library.

To start the Zeke online facility under TSO 1

Issue the command ZEKEOL (or its alias ZOL) from any full screen terminal. Note:

The ZEKEOL command is not supported as a called program from TSO. If you are running multiple versions of Zeke, you must include the subsystem: TSO ZEKEOL SUBSYS=subsystem Note:

If you use the default subsystem (SSSI), including it in the command is optional.

38

Chapter 3:

Calendars

3 When it creates a schedule of events, Zeke uses calendars to distinguish a workday, from a weekend day, from a holiday. This distinction 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 to schedule the event on Monday through Friday. However, if you define your workdays as Monday through Saturday, the OCCURS keyword WORKDAYS means to schedule the event on Monday through Saturday. Topic

Page

Calendar Types

39

Accessing the Calendar Facility

40

Standard Calendars

42

Special Calendars

43

User Accounting Calendars

44

Calendar Documentation Maintaining Scratch Pad or Note Documentation Maintaining Text Documentation

47 48 49

Calendar Types These are the calendar types: Calendar

Description

Standard

Defines normal workdays and holidays.

Special

Defines the exact days an event is to run. You would use a special calendar only when events have run dates that are random.

User accounting

Defines normal workdays and holidays, and establishes accounting periods.

39

ASG-Zeke Scheduling for z/OS User’s Guide

Most companies only need one or two Zeke calendars to meet all of their scheduling needs; however, you can define as many calendars as necessary. Zeke provides for an unlimited number of calendars to be defined. Each calendar must have a unique ID. Note:

If you define a calendar for a specific year to begin processing on the first day or week of the year, you also must set up a calendar for the previous year for Zeke to reference when determining the previous workday. This also is true for calendar processing on the last day or week of the year. You must set up a calendar for the next year that Zeke can use for reference.

Accessing the Calendar Facility To access the calendar facility 1

From the Zeke Primary Menu, enter option 3. Press Enter. The Calendar Selection Criteria screen is displayed: ASG-Zeke Command ===>

Calendar Selection Criteria

Calendar ID==>

Year==>

Primary commands: ADD

BROWSE

COPY

Type==> DELETE

EDIT

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 =>

40

*

STD- Standard -

SPC- Special USR- User (MM/DD/YYYY) or (DD/MM/YYYY)

3 Calendars

2

Press Enter. The Calendar Directory is displayed: ASG-Zeke Command ===>

Calendar Directory

Row 1 to 3 of 3 Scroll ==> PAGE

Calendar id==> Primary Commands: ADD Line Commands: E Edit

Year==> Type==> BROWSE COPY DELETE DOCUMENT 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/2012 ACCTG1 2012 USR YYYYYNN 01/01/2012 06/30/2012 USER1 2012 SPC N/A 01/01/2012 12/31/2012 ******************************Bottom of data*******************************

3

Perform the steps in the Action column (depending on the desired result). Desired Result

Action

Add a new calendar

1 Enter ADD on the Command line. 2 Enter the new calendar ID (up to eight alphanumeric characters long) in the Calendar id field. 3 Enter the calendar year in the Calendar Year field. 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 in the Type field. Press Enter. These are the valid types: STD

Standard calendar

SPC

Special calendar

USR

User accounting calendar

Update an existing calendar

Move the cursor to the unlabeled selection field to the left of the calendar you want to update and enter E.

Delete an existing calendar

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 displays the calendar to be deleted. Enter DEL and press Enter to confirm. This procedure is complete.

4

Press Enter. The Calendar Maintenance Functions screen for the appropriate type of calendar is displayed. 41

ASG-Zeke Scheduling for z/OS User’s Guide

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. Zeke’s default calendar A is a standard calendar that can be updated to accommodate your normal schedule. You can define as many standard calendars as necessary, each with different workdays and holidays. In this example, an event defined with the OCCURS clause WORKDAYS using calendar A is scheduled five times per week, and an event using calendar B is scheduled six times per 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

Calendar B

Workdays

Monday through Friday

Holidays

01/01/****, 07/04/****, 12/24/****, 12/25/****, 05/28/2012, 09/03/2012, 11/22/2012, 11/23/2012

Workdays

Monday through Saturday

Holidays

None

To maintain a standard calendar 1

Access the Calendar Maintenance Functions screen as instructed in “Accessing the Calendar Facility” on page 40. ASG-Zeke Command ===>

Calendar Maintenance Functions

Primary Commands: ADD Calendar ID==> A

Work Days:

Mon YES

Tue YES

MM/DD/YYYY

BROWSE

Wed YES

CANCEL COPY DELETE Year==> ****

Thu YES

Fri YES

MM/DD/YYYY

Sat NO

BROWSE

DOCUMENT EDIT Type==> STD

Sun NO

MM/DD/YYYY

MM/DD/YYYY

MM/DD/YYYY

Holidays:

Fiscal start month: 01 Calendar expire date: 12/31/2012 Calendar start date:

42

Date last accessed: 04/26/2012 Calendar end date :

3 Calendars

2

Update the Work Days fields if your workdays are different from the default days. The default workdays are Monday through Friday, and weekends are Saturday and Sunday. There are no default holidays. For each day of the week, enter YES if it is a workday; enter NO if it is not a workday.

3

Update the Holidays fields with the date of each holiday your company observes. You can enter up to 30 holidays on one calendar, so a single calendar can span several years.

4

Press Enter to save the calendar information.

Special Calendars You can use a special calendar for events that have random scheduling dates for which no other calendar type or OCCURS clause can pinpoint the correct schedule dates. First, you must associate the event with a standard or user accounting calendar. If you need to consider an additional, special calendar to establish the correct run dates, then you specify the special calendar in the OCCURS clause for the event. Note:

A special calendar is the only calendar type that you can use in an OCCURS clause. For example, this OCCURS clause schedules an event on every selected date on the special calendar: OCCURS (CALENDAR CAL1 AND DAILY)

You can use one special calendar for several events, then use keywords to specify dates in the OCCURS clause. For example, this OCCURS clause schedules an event on selected dates that fall on Monday: OCCURS (CALENDAR CAL1 AND MONDAY)

43

ASG-Zeke Scheduling for z/OS User’s Guide

To maintain a special calendar 1

Access the Calendar Maintenance Functions screen as instructed in “Accessing the Calendar Facility” on page 40. ASG-Zeke COMMAND ===>

Calendar Maintenance Functions

Primary Commands: ADD ZEKE Calendar ID==> USER1

January February March April May June July August September October November December

1 . . . . . . . . . . . *

2 . . . . . . . . . . . *

3 . . . . . . . . . . . *

4 . . . . . . . . . . . *

5 . . . . . . . . . . . *

6 . . . . . . . . . . . *

7 . . . . . . . . . . . *

8 . . . . . . . . . . . *

9 . . . . . . . . . . . *

BROWSE

CANCEL COPY DELETE Year==> 2012

DOCUMENT EDIT Type==> SPC

1 0 . . . . . . . . . . . *

1 4 . . . . . . . . . . . .

2 5 . . . . . . . . . . . .

1 1 . . . . . . . . . . . *

1 2 . . . . . . . . . . . *

1 3 . . . . . . . . . . . *

Calendar Expire Date: Calendar Start Date: 01/01/2012

2

BROWSE

1 5 . . . . . . . . . . . .

1 6 . . . . . . . . . . . .

1 7 . . . . . . . . . . . .

1 8 . . . . . . . . . . . .

1 9 . . . . . . . . . . . .

2 0 . . . . . . . . . . . .

2 1 . . . . . . . . . . . .

2 2 . . . . . . . . . . . .

2 3 . . . . . . . . . . . .

2 4 . . . . . . . . . . . .

2 6 . . . . . . . . . . . .

2 7 . . . . . . . . . . . .

2 8 . . . . . . . . . . . .

2 9 . . . . . . . . . . . .

3 3 0 1 . . . . . . . . . . . .

. . . . . .

Date Last Accessed: Calendar End Date: 12/31/2012

Enter an asterisk (*) or slash (/) for the days you want the job to be scheduled. The days are listed across the screen and the months are listed down the left column to create a matrix of dates. To deselect a date, replace the asterisk or slash with a period (.) or blank.

3

Press Enter to save your changes.

User Accounting Calendars If you want to schedule events based on your company accounting schedule, you can set up user accounting calendars to match the days in your accounting periods. You associate an event with a user accounting calendar using the Cal field in the EMR, like you do for a standard calendar. When you specify a user accounting calendar, the keywords refer to periods instead of months. In an OCCURS clause, you must use the keyword PERIODS instead of MONTHS for events that will use a user accounting calendar.

44

3 Calendars

For example, this OCCURs clause selects the last Monday in period 2: MONDAY.L AND PERIOD.2

To maintain a user accounting calendar 1

Access the Calendar Maintenance Functions screen as instructed in “Accessing the Calendar Facility” on page 40. ASG-Zeke Command ===>

Calendar Maintenance Functions

Primary Commands: ADD BROWSE Calendar ID==> ACCTG1

Work Days:

Mon YES

Tue YES

MM/DD/YYYY

Wed YES

CANCEL COPY DELETE Year==> 2012

Thu YES

Fri YES

MM/DD/YYYY

Sat NO

BROWSE

DOCUMENT EDIT PERIODS Type==> USR

Sun NO

MM/DD/YYYY

MM/DD/YYYY

MM/DD/YYYY

Holidays:

Calendar expire date: Calendar start date: 01/01/2012

Date last accessed: Calendar end date : 06/30/2012

The default workdays are Monday through Friday and weekends are Saturday and Sunday. There are no default holidays. 2

Update the Work Days portion of the screen, if your workdays are different from the default days. Use the Tab 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.

3

To update the Holidays portion of the screen, specify 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.

4

If you are adding a new calendar, specify 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.

45

ASG-Zeke Scheduling for z/OS User’s Guide

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 CANCEL EDIT

Calendar start date: 01/01/2012 ZEKE Calendar ID==> ACCTG1 Period Period Period Period Period Period Period Period

01: 28 04: 28 07: 10: 13: 16: 19: 22:

BROWSE

Period Period Period Period Period Period Period Period

Calendar end date : 06/30/2012 Year==> 2012 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:

Number of slack days between periods: Enter number of days (01-90) in each period and number of slack days (00-40)

6

Specify the number of days (up to 90) in each period. 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 two periods of each quarter and 35 to the last period of each quarter, and is useful if your company uses this accounting scheme.

7

46

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.

3 Calendars

Calendar Documentation The Calendar facility enables you to store and maintain calendar-related documentation. There are three types of calendar documentation that can be stored. Type

Description

Scratch

Scratch pad and note documentation each enable you to store up to ten 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 also can be used for “quick reference” information. The operator should always review scratch pad or note pad information before an event runs.

Note

Text

Stores up to approximately 450 records

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 40.

2

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 ===>

Documentation Segments

Primary Command: DELETE Calid: A Year: ****

Type: STD

Sdate:

Edate:

Documentation Record Selection Options 1 SCRATCH 2 * TEXT 3 NOTE

3

Scratch pad Text information Note pad information

Enter one of these codes on the Command line to select the type of documentation you want to add or update: Desired Result

Action

Access scratch pad documentation

Enter 1 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 48.

47

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Access text documentation

Enter 2 and press Enter. Go to “Maintaining Text Documentation” on page 49.

Access note documentation

Enter 3 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 48.

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 47. ASG-Zeke Command ==> Primary Commands: BROWSE

Documentation Scratch Pad

CANCEL

DELETE

EDIT

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

48

Calendar year : **** Start date :

Calendar type : STD End date :

2

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 ten lines of text.

3

Press Enter to save the changes.

3 Calendars

Maintaining Text Documentation The text documentation area enables 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 described in “Calendar Documentation” on page 47. 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 ***************************

2

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.

3

Use standard ISPF editing commands to edit the text.

4

Press F8 to page forward and access an additional screen.

5

Press Enter to save the changes.

49

ASG-Zeke Scheduling for z/OS User’s Guide

50

Chapter 4:

Events

4 An event is a unit of work (e.g., a batch process, program, command, message, etc.) defined to Zeke and scheduled to occur under a particular set of circumstances. You create an event master record (EMR) in the Zeke database that defines information for the event. The EMR includes the date and time to schedule the event, prerequisite conditions for dispatch, and resource requirements. This chapter discusses these topics: Topic

Page

Event Master Record (EMRs) Event Types EMR Primary Commands Specifying Generic Selection Criteria Accessing the Event Definition Adding an Event Definition Updating an Event Definition Defining an Event Template Creating an Event From a Template Copying an Event Defining a Job Event Defining a Message Event Defining a Command Event Defining a REXX Event Defining a Recurring or Permanent Event Defining a Milestone Event Using Scheduling Environments

52 53 53 57 58 59 61 63 65 67 69 86 89 93 97 102 105

OCCURS Clauses OCCURS Clause Format Sample OCCURS Clauses Scheduling Events on Holidays and Weekends Defining an OCCURS Clause

107 107 115 118 121

WHEN Conditions Job and Program WHEN Conditions WHEN Conditions for Multiple Event Versions Extended Dependencies WEAK Conditions NOTDURING Conditions

124 124 124 124 126 127 51

ASG-Zeke Scheduling for z/OS User’s Guide

Topic Cross-platform Dependencies Specifying Generic Names Specifying Multiple WHEN Conditions Specifying Started Tasks Using Zeke Variables as WHEN Conditions WHEN Condition Keywords Defining a WHEN Condition Viewing WHEN Conditions for All Event Versions

Page 129 130 130 131 131 133 139 140

Condition Codes Defining Condition Codes for an Event

143 144

Work Centers Using Variables in Work Centers Defining a Work Center Completing Work Centers

149 150 151 155

Auto Replies Defining Auto Replies Managing Auto Replies

159 160 163

Event Documentation Accessing Event Documentation Maintaining Scratch Pad or Note Documentation Maintaining Text Documentation Maintaining Dataset Documentation

164 165 168 169 170

Event Activity Accounting Viewing Event Accounting Information Maintaining Job Duration Statistics, Alerts, and Failures

172 172 174

Event Master Record (EMRs) You can define an event through either of these facilities: •

Event Master Record Definition screens in the Zeke online facility

•

EVENT function of the ZEKE batch utility program

This chapter describes the procedures as you would perform them using the online facility. For information on performing the same general procedures using the ZEKE batch utility program, see the ASG-Zeke Scheduling for z/OS Reference Guide.

52

4 Events

Event Types These are the Zeke event types: Type

Description

JOB

Jobstream event

MSG

Console operator message event

WORK

Work center event

VCOM

VM CP command event

ZCOM

Zeke operator command event

SCOM

System command or system response event

PCOM

(VSE only) POWER command event

REXX

(z/OS only) REXX EXEC

EMR Primary Commands These are the primary commands that are available from most Event Master Definition screens (and their corresponding functions): Note:

Uppercase characters indicate the command’s minimum abbreviation. Command

Action

ACCT

Maintain the event accounting history.

ADD

Add an event definition.

AUTorply

Maintain auto reply elements for a job event.

BROwse

Browse an event definition.

CCode

Maintain condition code information for a job event.

COPY

Copy the basic identifying information and OCCURS/WHEN information from an existing event definition to create a new event. (Zeke generates the new event number.)

53

ASG-Zeke Scheduling for z/OS User’s Guide

Command

Action

COPYAll

Copy all associated event information from an existing event definition to create a new event. (Zeke generates the new event number.)

DEACt

Deactivate an event, so that Zeke does not include it in the schedule.

DELete

Delete an event definition from the Zeke database. (Zeke requires you to confirm the action.) Note: You can delete an event definition only if there are no existing schedule queue records (SQRs) already in the schedule based on the event definition. (Otherwise, you must delete the existing SQRs first.)

DISPlay

Display the event definition in Browse mode.

DOCument

Define or maintain event documentation.

EDit

Display the event information in Edit mode.

JCL

Display JCL that is stored in the Zeke database.

OCCurs

Maintain the OCCURS clause for the event.

PATH

View the predecessors and successors of the event. Note: The DSPIndex generation option must be set to Y to enable the PATH command (see “Building EDB Indexes” on page 311). These are the optional command keywords: LEVel

Specifies the level of depth to display for the path. The valid values range from 1 through 999, or you can enter an asterisk (*) to display all levels. The default value is *.

OCCDate

Specifies the Julian date for Zeke to use to resolve the OCCURS clause. The default value is the current date.

VERsion

Specifies the version of the event for which to display predecessor/successor information. For example: PATH VER 3

The default value is 0 (if the Verload generation option is set to 0). Otherwise, the default value is 1.

54

4 Events

Command

Action

PATHADD

Invoke the Schedule View Add-by-Path wizard, which enables you to list predecessors and successors for an event and then schedule events from the list. Zeke auto-fills the event, depth level, OCCURS date, version, and path type. Note: The DSPIndex generation option must be set to Y to enable the PATHADD command (see “Building EDB Indexes” on page 311). LEVel

Specifies the level of depth to display for the path. The valid values range from 1 through 999, or you can enter an asterisk (*) to display all levels. The default value is *.

OCCDate

Specifies the Julian date for Zeke to use to resolve the OCCURS clause. The default value is the current date.

VERsion

Specifies the version of the event for which to display predecessor/successor information. For example: PATHADD LEV 5

The default value is 0 (if the VerLoad generation option is set to 0). Otherwise, the default value is 1. PREd

View the predecessors of the event. Note: The DSPIndex generation option must be set to Y to enable the PRED command (see “Building EDB Indexes” on page 311). LEVel

Specifies the level of depth to display for the path. The valid values range from 1 through 999, or you can enter an asterisk (*) to display all levels. The default value is *.

OCCDate

Specifies the Julian date for Zeke to use to resolve the OCCURS clause. The default value is the current date.

VERsion

Specifies the version of the event for which to display predecessor information. For example: PRED VER 3

The default value is 0 (if the Verload generation option is set to 0). Otherwise, the default value is 1.

55

ASG-Zeke Scheduling for z/OS User’s Guide

Command

Action

PREDADD

Invoke the Schedule View Add-by-Path wizard, which enables you to list predecessors for an event and then schedule events from the list. Zeke auto-fills the event, depth level, OCCURS date, version, and path type. Note: The DSPIndex generation option must be set to Y to use the PREDADD command (see “Building EDB Indexes” on page 311). LEVel

Specifies the level of depth to display for the path. The valid values range from 1 through 999, or you can enter an asterisk (*) to display all levels. The default value is *.

OCCDate

Specifies the Julian date for Zeke to use to resolve the OCCURS clause. The default value is the current date.

VERsion

Specifies the version of the event for which to view predecessor information. PREDADD LEV 3

The default value is 0 (if the Verload generation option is set to 0). Otherwise, the default value is 1. REACt

Reactivate an EMR (that was previously deactivated) and enable it to be scheduled.

RESOurce

Maintain logical resource control information for a job event.

RESTart

Request the restart facility (e.g., Zebb) for the job event.

SUcc

View the successors of the event. Note: The DSPIndex generation option must be set to Y to use the SUCC command (see “Building EDB Indexes” on page 311).

56

LEVEL

Specifies the level of depth to display for the path. The valid values range from 1 through 999, or you can enter an asterisk (*) to display all levels. The default value is *.

OCCDATE

Specifies the Julian date for Zeke to use to resolve the OCCURS clause. The default value is the current date.

4 Events

Command

Action VERSION

Specifies the version of the event for which to view successor information. SUCC VER 3

The default value is 0 (if the Verload generation option is set to 0). Otherwise, the default value is 1. SUCCADD

Invoke the Schedule View Add-by-Path wizard, which enables you to list successors for an event and then schedule events from the list. Zeke auto-fills the event, depth level, OCCURS date, version, and path type. Note: The DSPIndex generation option must be set to Y to use the SUCCADD command (see “Building EDB Indexes” on page 311). LEVEL

Specifies the level of depth to display for the path. The valid values range from 1 through 999, or you can enter an asterisk (*) to display all levels. The default value is *.

OCCDATE

Specifies the Julian date for Zeke to use to resolve the OCCURS clause. The default value is the current date.

VERSION

Specifies the version of the event for which to view successor information. SUCCADD LEV 3

The default value is 0 (if the Verload generation option is set to 0. Otherwise, the default value is 1). WHEN

Maintain the WHEN conditions (i.e., prerequisites or dependencies) for the event (or for a particular version of the event).

Specifying Generic Selection Criteria When using a Zeke online function that enables you to select events in the Zeke database, you can use wildcard or placeholder characters in your selection criteria. These are the most common event attributes that enable the use of wildcards and placeholders: •

Application ID

•

Event name

•

Group ID

•

Jobname

•

System ID

•

User ID 57

ASG-Zeke Scheduling for z/OS User’s Guide

An asterisk (*) can be used as a wildcard for one or more characters and functions in these ways: •

An asterisk at the end of an operand string (e.g., ABC*) selects any name (of any valid length) that begins with the specified characters.

•

An asterisk at the beginning of an operand string (e.g., *ABC) selects any name (of any valid length) that ends with the specified characters.

•

An asterisk in the middle of an operand string performs a wildcard search for any name matching the specified beginning and ending characters (plus any characters in between).

A question mark (?) can be used as a placeholder for any unknown, single character. Wildcards and placeholders can be used in combination.

Accessing the Event Definition You use the Event Master Record Definition screens to define or update an event definition for any type of event. The event definition includes the event’s scheduling and dispatching criteria, documentation, JCL, auto replies, resources, and condition codes.

To access an existing event definition 1

From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria screen is displayed: ASG-Zeke Command ===>

Event Master Selection Criteria

Event ===> Primary Commands:

ADD BROWSE DELETE EDIT

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: Milestone:

58

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:

4 Events

2

3

Optional. To a list of existing templates for a specific event type, perform these steps: a

Enter Y in the Template field.

b

Enter Y in the appropriate Event Types field.

Press Enter. The Event Master Directory 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 ZEKE60TST1 MSG * * 000002 ZEKE60TST2 MSG * * 000003 ZEKE60TST3 MSG * * 000004 ZEKE60TST4 MSG * * 000005 ZEKE60TST5 MSG * * 000006 ZEKE60TST6 TSKKGUT1 JOB * * * * 000007 ZEKE60TST7 TSKKGUT2 JOB * * * * 000008 ZEKE60TST8 TSKKGUT3 JOB * * * 000009 ZEKE60TST9 TSKKGUT4 JOB * * * 000010 ZEKE60TST10 TSKKGUT5 JOB * * * 000011 ZEKE60CC SPTEXD11 JOB * * * * 000012 ZEKE60CC SPTEXD12 JOB * * * * 000013 WORK * * 000014 VCOM *

An asterisk (*) in any column on the right side of the screen indicates that a record of that type exists for the corresponding event (e.g., an asterisk in the Cond Codes column indicates that condition code information exists for the event).

Adding an Event Definition This section describes the general procedure for adding a new event to the Zeke database and then directs you to the appropriate procedure for defining the specific event type.

To add a new event definition 1

From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria screen is displayed.

59

ASG-Zeke Scheduling for z/OS User’s Guide

2

Enter ADD on the Command line, and press Enter. The Add Event Record Function screen is displayed: 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

In the Option field, specify the option number for the type of event that you want to define.

4

In the Use Template field, enter N. Or

If you want to create the event using a template, skip to “Creating an Event From a Template” on page 65. 5

Press Enter. The Event Master Definition screen for the selected event type is displayed in Add mode.

Depending on the type of event that you want to add, continue to the appropriate procedure:

60

•

For job events, see “Defining a Job Event” on page 69.

•

For message events, see “Defining a Message Event” on page 86.

•

For command events (e.g., PCOM, SCOM, VCOM, ZCOM), see “Defining a Command Event” on page 89.

•

For work center events, see “Defining a Work Center” on page 151.

•

For REXX events, see “Defining a REXX Event” on page 93.

4 Events

Updating an Event Definition This section describes the general procedure for updating an existing event in the Zeke database and then directs you to the appropriate procedure for updating specific event types or event attributes.

To update an existing event definition 1

From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria screen is displayed.

2

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Update an existing event based on event number

1 Enter EDIT on the Command line. 2 Specify the event number in the Event field. 3 Press Enter. The Event Master Definition screen for the selected event is displayed in Edit mode. Continue to step 3 on page 62.

Update an existing event (without the event number)

1 Enter any character in the appropriate Event Types field. 2 Enter any additional information about the event in the Selection Field Masks fields. 3 Press Enter. The Event Master Directory displays events that match the selection criteria. Continue to step 3 on page 62.

Update an event template

1 Enter Y in the Template field. 2 Enter Y next to the appropriate event type. 3 Press Enter. The Event Master Directory displays the existing templates of the specified type. Continue to step 3 on page 62.

Update event documentation, 1 Enter any character in the appropriate Event Types JCL, auto reply, resource, field. condition codes, or 2 Enter any additional information about the event in the dependency information Selection Field Masks fields. 3 Press Enter. The Event Master Directory displays events that match the selection criteria. Continue to step 3 on page 62.

61

ASG-Zeke Scheduling for z/OS User’s Guide

3

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Update the EMR

Enter E to the left of the event that you want to update, and press Enter. The Event Master Definition screen for the selected event is displayed in Edit mode. Perform the appropriate update procedure for the event type you are updating: • See “Defining a Job Event” on page 69. • See “Defining a Message Event” on page 86. • See “Defining a Command Event” on page 89. • See “Defining a REXX Event” on page 93. • See “Defining a Work Center” on page 151.

Delete the EMR

1 Enter D to the left of the event that you want to update, and press Enter. The Event Master Definition screen for the selected event is displayed in Delete mode. 2 Press Enter again to confirm. This procedure is complete.

Update event documentation

Enter E1 to the left of the event that you want to update, and press Enter. Continue to “Accessing Event Documentation” on page 165.

Update online event Enter E2 to the left of the event that you want to update, and press JCL Enter. Continue to “Overriding JCL” on page 226. Update event auto reply segments

Enter E3 to the left of the event that you want to update, and press Enter. Continue to “Defining Auto Replies” on page 160.

Update event logical resources

Enter E4 to the left of the event that you want to update, and press Enter. Continue to “Defining Resources for an Event” on page 274.

Update event condition codes

Enter E5 to the left of the event that you want to update, and press Enter. Continue to “Condition Codes” on page 143.

62

4 Events

Desired Result

Action

Update the OCCURS clause for an event

Enter E6 to the left of the event that you want to update, and press Enter.

Update the WHEN conditions for an event

Enter E7 to the left of the event that you want to update, and press Enter.

Continue to “Defining an OCCURS Clause” on page 121.

Continue to “Defining a WHEN Condition” on page 139.

Defining an Event Template Typically, multiple events have common or similar event information. You can create event templates to use as models for defining new EMRs more quickly (especially multiple, similar events). You define a template just like any other event; however, you cannot add a template to the schedule. When you create an event from a template, Zeke copies information from the template to create the new event (e.g., documentation, JCL, OCCURS and WHEN clauses, etc). To create new events from a template, you must use a template of the same event type (e.g., a job event). You can create an unlimited number of templates for each event type.

To define an event template 1

Access the Event Master Definition screen for the type of event that you want to create, as described in “Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: ABC Usrid: ASGTEST DRL: 2 System: SYS1 Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: ASGJOBABC JCL--> PDS: Member: Zeke JCL (Y=Yes): Y Bim: Mbr: JESQ (Y, D=dynamic):

Class:

Pri: 0 CMS:

Ftype:

63

ASG-Zeke Scheduling for z/OS User’s Guide

2

In the Event Name field, enter a name for the template (which is used for selecting the template to create a new event).

3

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.

4

Complete the fields that you want to have common values that are defined by default for all events that you create using the template. See these procedures for more information on the fields you can define for each event type: •

See “Defining a Job Event” on page 69.

•

See “Defining a Message Event” on page 86.

•

See “Defining a Command Event” on page 89.

•

See “Defining a REXX Event” on page 93.

•

See “Defining a Work Center” on page 151.

5

Press Enter to save the event template; Zeke assigns it a unique event number.

6

Optional. ASG recommends that you deactivate the event template by issuing the DEACT primary command. Note:

Although it is not necessary to deactivate a template (because templates cannot be scheduled), ASG recommends that you perform this step so that you cannot schedule a new event that has been created from a template until you activate the event.

64

7

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 121.

8

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 139.

4 Events

Creating an Event From a Template To create an event from a template, you must use a template of the same event type (e.g., you can create a work center only from a work center template). See “Defining an Event Template” on page 63 for details on defining event templates.

To create an event from an existing template 1

Access the Add Event Record Function screen, as described in “Accessing the Event Definition” on page 58 for details: 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

2

In the Use Template field, enter Y to indicate that you want to create the new event from an existing template.

3

In the Template field for event type, specify the event name of the event template that you want to use to create events of that type.

4

On the Option line, enter the option for the type of event that you want to define. To view a list of existing templates for a specific event type, access the Event Master Selection Criteria screen (see “Accessing the Event Definition” on page 58), and enter Y in the Template field next to the event type. Note:

If you have multiple templates defined with the same event name and type, Zeke uses the template with the lowest event number. For example, if you have a job event template named JOBTEMPLATE that is assigned event number 12, and another job event template named JOBTEMPLATE this is assigned event number 34, Zeke uses the template with the event number 12.

65

ASG-Zeke Scheduling for z/OS User’s Guide

The Event Master Definition screen for the selected event type is displayed in Update mode (this example illustrates a job event): ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA JCL--> PDS: Member: Zeke JCL (Y=Yes): Y Bim: Mbr: JESQ (Y, D=dynamic):

Class:

Pri: 0 CMS:

Ftype:

All of the information in the template definition is copied to the new event (except that Zeke resets the Template field in the new event to N).

66

5

Update the event definition, as necessary. ASG recommends that you change the event name to a new name (to make it easier to distinguish between the template and the events you create from the template).

6

Press Enter to save the event; Zeke assigns it a unique event number.

7

Optional. If the event template was deactivated, activate the event by issuing the REACT primary command. Activating the event enables it to be scheduled.

8

Optional. Perform the procedure, “Defining an OCCURS Clause” on page 121 to specify any additional event scheduling criteria.

9

Optional. Perform the procedure, “Defining a WHEN Condition” on page 139 to specify any event dispatching prerequisites.

4 Events

Copying an Event If you want to define an event that is similar to an existing event, you can create the new event from a copy of the existing event. Note:

If you plan to create numerous, similar events, ASG recommends that you create and use an event template. See “Creating an Event From a Template” on page 65 for details.

To create a new event from a copy of an existing event 1

Access the Event Master Definition screen (see “Accessing the Event Definition” on page 58) for the event that you want to copy: ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA

Class:

JCL--> PDS: Member: Zeke JCL (Y=Yes): Y Bim: Mbr: JESQ (Y, D=dynamic):

2

Pri: 0 CMS:

Ftype:

To copy only the basic EMR (as displayed on this screen), OCCURS clause (i.e., scheduling criteria), and WHEN conditions (i.e., dispatching prerequisites), enter COPY on the Command line. Or

To copy the entire EMR, enter COPYALL on the Command line. 3

Press Enter. Zeke displays this message: Z041I EVENT xxxxxx HAS BEEN COPIED TO EVENT yyyyyy

where xxxxxx is the original event number, and yyyyyy is the new event number. Make note of the new event number. 67

ASG-Zeke Scheduling for z/OS User’s Guide

Caution! After the copy is completed, Zeke continues to display the original event (that was used to create the new event). To avoid inadvertently changing the original event, access the newly created event before you attempt to make any changes. 4

To access the new event: a

In the Event field, specify the new event number.

b

Press F2.

Note:

Zeke automatically deactivates the new event. c

Edit the event information (as necessary), and press Enter.

d

Press F3 to return to the Event Master Directory screen.

e

Locate the new event in the directory.

f

Enter E in the selection field to the left of the event number, and press Enter. The Event Master Definition screen is redisplayed in Edit mode for the new event.

g

Edit the event information (as necessary), and press Enter to save the changes.

Note:

If you used this procedure to copy a template, Zeke resets the Template field to N. If you want the new event to be a template, set this field to Y.

68

4 Events

Defining a Job Event A job event is the most commonly used event type, and executes a specified jobstream.

To define or maintain a job event 1

Access the Event Master Definition screen for job events, as described in “Accessing the Event Definition” on page 58. ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA

Class:

JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

2

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

Complete these fields (as applicable) to define the job event: Field

Description

Template

Indicate whether you are defining a message event template. The valid values are Y and N. See “Defining an Event Template” on page 63 for more information.

Desc/Desc2

Specify a description of the job event. This description is displayed on summary screens and printed on reports.

Event Name

Specify the name of the job event. The event name is displayed on Zeke online screens and reports, and can be used as selection criteria. The event name also can be specified in end-of-event (EOE), abnormal-end-of-event (AEOE) and end-of-group (EOG and AEOG) WHEN conditions.

69

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description

Usrid

Specify the user ID (up to eight characters long) for the user authorized to access the job event. Since Zeke supports mixed-case user IDs, be sure to specify the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.

System

Specify the system or pool that owns the job event (which can be associated with only one system). Note: This is the system where the event is dispatched, and not necessarily the system where the EMR was defined.

Verload

Specify the number of versions of this job event that Zeke loads during schedule build. The valid values range from 0 through 32767. The default value is 0. For example, if Verload is set to 3, Zeke adds EMRs to the schedule for three versions of the event during schedule build (i.e., versions 1, 2, and 3). If Verload is set to 0, then only one version of the event (version zero) can be in the schedule at a time. If Verload is set to 1, Zeke loads only one version during the schedule build, but you can use the ZADD operator command to add multiple versions (up to 32,767) to the schedule after the schedule load. Note: ASG recommends that you run no more than 1,000 versions of a single event. See “Creating Multiple Versions of an Event” on page 76 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 you 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.

70

4 Events

Field

Description

Sched

Specify the normal schedule time for the event. The default value is 00:00 (i.e., the event is dispatched according to WHEN conditions instead of by time). See “Specifying a Schedule Time” on page 73 for a detailed explanation of schedule time.

Control

Specify the code that indicates whether the Zeke dispatches and tracks the job event as a Zeke-controlled event. Note: Zeke does not support multiple jobs as a single event. You must define each job as a separate event. Zeke considers any additional jobs in the same event as nonZeke jobs. These are the valid codes: Y

Default. Zeke recognizes the job event as a Zeke-controlled job. Zeke-controlled jobs are tracked throughout their entire execution.

N

Zeke does not recognize the job event as Zeke-controlled, and, on dispatch, marks the job with the status Done.

NX

Zeke recognizes the job event as a nonexecutable, Zeke-controlled event. Zeke schedules and dispatches a nonexecutable event just like any other event, but never submits the JCL to JES for execution. Nonexecutable events are useful as predecessors to other events. After Zeke dispatches a nonexecutable event, Zeke marks the job with a Success status, and triggers any dependent events. Note: To remove an event from an intricate event flow, you can mark the event as nonexecutable as an alternative to changing the event flow (which typically requires you to delete the event and then modify the WHEN conditions for all of the deleted event’s successors).

71

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description

Tapes

Specify the number of physical tape drives that the job event requires. Zeke dispatches the event when the specified number of drives are available. If it becomes time to dispatch the event, and the required drives are not free, Zeke indicates that the event is waiting on drives. You can enable Zeke to calculate this value automatically through the Calctap generation option (see “Tape Options” on page 308), or you can enter a value. The valid values range from 0 through 255. The default value is 0. Note: If you keep the default value (zero), but tapes are required, then operator intervention might be necessary the first time the event runs under Zeke’s control. If the Calctap generation option is set to Y, then Zeke automatically calculates the number of tapes based on the last time the job ran. Zeke displays an asterisk (*) next to the value if is Zeke-calculated. You also can enter a Tapes value that overrides the Zeke-calculated number. Note: If Calctap is set to Y, and you manually override the Zeke-calculated value, then Zeke does not calculate the tape value again until you reset the Tapes value to 0. To reset the tape value, enter three blank spaces in the Tapes field.

Secgroup

Valid for z/OS job events only. Specify the security group (up to eight characters long). If the SecULock generation option is enabled, you cannot update this field. If the SecUInit generation option is enabled, Zeke automatically populates this field. (This overrides any entered value or value obtained from an event template.) If the RepJGrp generation option is enabled, Zeke replaces the GROUP= keyword parameter on the JOB card with this value when the job is submitted. For more information on these generation options, see the ASG-Zeke Scheduling for z/OS Reference Guide.

Job

72

Specify the name of the job event in the JCL. The jobname displays on Zeke online screens and messages, and is used by Zeke to track the event during execution. This value must match the jobname on the job card for accurate tracking.

4 Events

Field

Description

Class

Specify up to six job classes for the job event. When the event is ready to run, Zeke selects an initiator according to the defined classes. This field is valid only if the generation option DispSel is set to Y (i.e., the default). If you do not specify a class, then Zeke uses the value of the DefDspCl generation option. If no value is defined for the DefDspCl generation option, then Zeke selects any free, defined initiator. See “Defining Initiators to Zeke” on page 262.

JCL

Specify the JCL source library and member information. See “Retrieving JCL from the Zeke Database” on page 84 for more information about JCL sources. See “Overriding JCL” on page 226 for more information on making one-time JCL overrides.

3

Complete these fields (as applicable), which enable you to group events for selection for scheduling or reporting: Field

Description

App

Specify the code (up to eight characters long) to identify the application ID associated with the job event.

Grp

Specify the code (up to three characters long) to identify the group ID associated with the job event. This field is a subset of the application ID.

4

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns the event a unique, event number.

5

Perform the procedure “Defining an OCCURS Clause” on page 121 to specify when Zeke schedules the job event.

6

Perform the procedure “Defining a WHEN Condition” on page 139 to specify any prerequisites that must occur before Zeke dispatches the job event.

Specifying a Schedule Time Schedule time is an optional dispatching prerequisite that must be met before Zeke can dispatch an event. The schedule time fields are: Sched, Early, Latestart, Lateend, Mustend, and Notafter. If the precise time that Zeke dispatches the event is not important, then you can leave these fields blank (i.e., 00:00). However, if Zeke must dispatch the event by a certain time, or cannot dispatch the event after a certain time, or if the event must finish by a certain time, you use the schedule times fields to place restrictions on the time. 73

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

For an explanation of Zeke’s 48-hour clock (known as DaySpan), which lets you schedule according to a logical day, see “Logical Day (48-hour Clock)” on page 182. Use this table to help you to determine how to define the schedule time fields to meet your scheduling requirements for an event: Desired Result

Action

Schedule the event at a specific time

In the Sched field, specify the normal schedule time for the event.

Set the earliest time Zeke can dispatch an event

In the Early field, specify the earliest time that Zeke can dispatch the event. Zeke dispatches the event at its early time as long as the WHEN conditions are satisfied. When multiple events are eligible to be dispatched early, Zeke dispatches the events by their schedule time sequence.

If you specify a time value greater than 24:00, Zeke processes the event the next day. The default value is 00:00 (which indicates that Zeke schedules the event according to WHEN conditions instead of by time).

For example, you could set an event to run normally at 12:00 P.M., but also enable it to run as early as 11:00 A.M., if an initiator is available. Note: You can 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 for each of the events, and specify the schedule time for each event in the required sequence. If the events become eligible to be dispatched early, then Zeke still processes the events in the correct sequence. This also makes the SCHEDULE command output more easy to read. Set the time the event In the Mustend field, specify the latest time the event can complete must complete processing processing. Prior to dispatch, Zeke adds the current system time to the event’s average duration. If the result is greater than the Mustend time, Zeke issues a console message and removes the event from the dispatch queue. For example, let’s suppose the Mustend time is 14:00, the system time is 13:00, and the average duration of the event is two hours. Because the event would not complete until 15:00, Zeke does not dispatch event.

74

4 Events

Desired Result

Action

Set the latest time Zeke can dispatch an event

In the Notafter field, specify the latest time that Zeke can dispatch an event. Prior to dispatch, Zeke compares the current system time and the Notafter time. If the Notafter time is less than the system time, the event no longer is time-satisfied. Zeke issues a console message, and removes the event from the dispatch queue.

Set the time Zeke considers an event as late (based on its start time)

In the Latestart field, specify the time by which Zeke must dispatch the event. The valid values range from 00:00 through 47:59. The event is flagged as late if the current system time is past the Latestart time, and Zeke has not dispatched the event. (If the Latestart time is reached before Zeke dispatches the event, Zeke issues message Z0302I.) For example, if an event is scheduled to run at 12:00 P.M. with a Latestart time of 13:00, Zeke considers the event to be late if it is not dispatched by 1:00 P.M. Zeke predicts whether an event might not be dispatched before its Latestart time (based on its predecessors). • If an event is projected to start late, Zeke does not flag the event as late until the event’s Latestart time is reached. • If an event is projected to start late, Zeke does not prevent the event from being dispatched until the event’s Notafter time is violated. • If an event is projected to start late, Zeke issues an early warning alert to OpsCentral. Note: If the Zeke generation option PriLate is set to Y, Zeke dispatches late events before other events that are not late (regardless of the schedule time).

Set the time Zeke considers an event as late (based on its end time)

In the Lateend field, specify the time by which the event must finish. The valid values range from 00:00 through 47:59. The event is flagged as late if the current time is past the Lateend time, and the event has not completed yet. (If the Lateend time is reached before the event has completed, Zeke issues message Z0302I.) Zeke predicts whether an event might not be completed before its Lateend time (based on its average duration). • If an event is projected to finish late, Zeke does not prevent the event from being dispatched until the event’s Mustend time is violated. • If an event is projected to finish late, Zeke does not flag the event as late until the event’s Lateend time is reached.

75

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action Note: If the Zeke generation option PriLate is set to Y, Zeke dispatches late events before other events that are not late (regardless of the schedule time).

Creating Multiple Versions of an Event You can define an event 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; however, ASG recommends running no more than 1,000 versions of a single event. Each version of an event operates independently of all other versions of the same event. For example, 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. You can issue Zeke operator commands that select events by version number for processing. You also can define WHEN conditions to trigger based on 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 enable you to change the jobnames while the events are added to the schedule. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information on ZEKE02OX.) You use the Verload field on the Event Master Definition screen to define the number of versions for an event. Then, you can define WHEN conditions based on a specific version number of the event.

Defining a Externally Submitted Job Event (JESQ) You can define job events that will come from an external source. These events do not have JCL associated with them; instead, their EMRs indicate that the JCL is contained in the JES job queue. This enables a job event to originate from any source, and enables Zeke to dispatch and track the event just like any other Zeke event.

To define an externally submitted job

76

1

Access the Event Master Definition screen for a job event, as described in “Accessing the Event Definition” on page 58.

2

Specify the information indicated in “Defining a Job Event” on page 69.

4 Events

3

If you specify MVS in the Platform field, then the JESQ field is displayed in the JCL—> section. The Target field is automatically set to *LOCAL. In the JESQ field, specify the codes that indicates how Zeke processes the externally submitted job event. These are the valid values: Code

Description

Y

Indicates that Zeke must create the event’s SQR in the normal way (i.e., as added by the SCHEDULE function, or through the ZADD operator command). If JESQ is set to Y, the job event does not have a JES job ID at dispatch time.

D

Indicates that Zeke dynamically creates a new SQR for a matching job that enters the JES queue (if an unassigned SQR does not already exist). Note: If JESQ is set to D, you still can add the job event to the schedule using the SCHEDULE function or the ZADD operator command. When Zeke dynamically creates an SQR, the job ID of the JES queue job is placed in the SQR at that time, and the SQR is assigned to the JES queue job (and is the only SQR used to dispatch the job). If JESQ is set to D, the Verload field in the SQR is automatically set to 1, so that Zeke can dynamically create multiple SQRs for the same schedule date. The Retain field is set to Y, and the Times field is set to 001.

Caution! You cannot change an existing SQR’s JCL source to, or from, JESQ. If you change an EMR’s JCL source from JESQ to a different JCL source, while an existing associated SQR has JESQ as the JCL source, the SQR does not dispatch or track the JESQ job.

JESQ Job Processing When a job enters the JES queue, Zeke attempts to match it with an EMR that has JESQ specified as the JCL source and the same jobname as the JES job card. After locating the matching EMR, Zeke searches the schedule for an unassigned SQR for that event. If a match is located, Zeke tracks the job as a Zeke-controlled job. Caution! If more than one EMR has JESQ specified as the JCL source, and a jobname that matches the JES job card, Zeke pairs the JES job with the first matching EMR located (which is not necessarily the one with the lowest event number). Also, if the first matching EMR is deactivated, Zeke stops searching, and does not add an SQR. For these reasons, ASG recommends that you do not define more than one EMR with the JCL source JESQ and the same jobname; otherwise, the results are unpredictable.

77

ASG-Zeke Scheduling for z/OS User’s Guide

Dynamically Created SQRs (JESQ=D) If Zeke cannot locate a matching SQR, and if the EMR is set to JESQ=D, Zeke dynamically adds an SQR to the schedule. In this case, the JES job ID of the JES queue job is added to the newly created SQR, and this SQR becomes the only one that can dispatch the job. For triggering purposes, an event defined with JESQ=D ignores version numbers; the event triggers, and is triggered by, another event (regardless of that event’s version number). If you have an EMR defined with JESQ=D, and the job abends, you must refresh the SQR that is in a failed status before resubmitting the job to the JES queue. Otherwise, Zeke dynamically adds a new SQR when the job is resubmitted.

Held Jobs A job can be submitted to the JES queue on hold (or not on hold). If the job is not on hold, Zeke places it on hold, and re-queues the job to the JES job queue (where it can be controlled by the JESQ event). Zeke dispatches a held job by releasing it from the JES queue. If the JES queue contains a held job with a matching jobname, Zeke releases it. If there are multiple matching jobs, Zeke dispatches the job with the lowest JES job ID. If there is no matching held job, the event remains in the dispatch queue until a matching job arrives (or until the event is removed from the dispatch queue). In this state, Zeke assigns the event the event reason code JESQ Held Job Wait in Schedule View and in ZD WAIT operator command output. If a dynamically created SQR is deleted before it dispatches and releases the held job, the held job is orphaned. In this case, you must manually release the held job. Zeke then places the job on hold, re-queues it, and dynamically creates a new SQR for it. Note:

You can use the ZPLEX DISPLAY operator command to display the held jobs in the JES queue (and whether they have been assigned to an SQR). The JES queue is scanned every 30 seconds for new held jobs, so it could take up to 30 seconds for Zeke to dispatch or dynamically create a new SQR for a new JES queue job.

JESQ Processing Requirements •

78

The EDBindex generation option must be set to Y (see page 311). Zeke matches the jobname to a JESQ event using the EDB index; therefore, after you add JESQ job event (or change the event to JESQ), Zeke does not dynamically add or identify the SQR on another system until the other system processes the EMR communication record.

4 Events

•

SVC 34 (console 0) is used to issue the JES commands to release a held job and to requeue an job that is not on hold. The Zeke started task and the Zeke IEFUJI SMF exit must have authority to issue these commands.

•

The system that dispatches the job must have access to the JES queue that contains the job. Ensure that the system ID in the SQR is a system (or pool of systems) that has appropriate access.

JESQ Processing Considerations •

If the DispSel generation option is set to Y (see page 299), Zeke does not dispatch a JESQ event until an initiator of the specified class is available. (The initiator classes are those specified in the EMR, not those defined on the JES job card.)

•

The ZSCAN, SCAN, JCLR, and JPREP commands in Schedule View are not supported for SQRs that have the JCL source JESQ.

•

You cannot create override JCL from OpsCentral.

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 z/OS to another, or from a z/OS system to an AS/400. Zeke remote jobs support condition code processing (except if *Rmtlim is specified, see below) as well as logical resource usage. Zeke supports all trigger types except dataset name and variable name, and updates all accounting information in the EMR. Zeke does not support auto replies for remote jobs and NOTDURING conditions that reference remote jobs. To route a job to another system or platform, you specify the target and platform information in the EMR.

To route a job event to another system or platform 1

Ensure that the Posid and Netregid generation options for your system are set appropriately, with Posid set to Y, and a valid, nonblank Netregid. (Generally, your system programmer defines these options. See “Job Networking Options” on page 317.)

79

ASG-Zeke Scheduling for z/OS User’s Guide

2

Access the Event Master Definition screen for a job event, as described in “Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA

Class:

JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

3

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

Specify the information indicated in “Defining a Job Event” on page 69. Note:

If the remote system is secured, the Usrid field must specify a valid user ID on the remote system. 4

Complete these fields to specify the routing information: Field

Description

Target

Valid for job events only. Specify a value to indicate how to handle routing. Note: Although the Target field appears in the EMR screen for all event types, it currently applies to job events only, and defaults to *LOCAL for all other event types. These are the valid values: netregid

Indicates the OASIS/DMS logical name (Netregid) for the remote Zeke or Zeke Agent system. Note: This is the only type of remote processing where the dispatching and execution platform can be different from each other.

80

4 Events

Field

Description Zeke dispatches an individual job to OASIS/DMS, which routes the job to the specified remote system. The remote system submits the job for execution, and monitors it). The level of communication between the dispatching Zeke and the job on the remote system is based on the job’s condition code processing requirements. Note: If the remote system is a Zeke Agent defined as a download agent, then the SQRs that specify this system are downloaded via OASIS/DMS and then executed and tracked on the remote system. See “Downloading a Job Event to Zeke Agent” on page 83 for more information. *R or *REMOTE

Indicates that the job instructions must contain the necessary Network Job Entry (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 system is based on the job’s condition code processing requirements.

*RF or *RMTFUL

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.

*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 the requested triggering information back to the dispatching Zeke, but executes independently. The dispatching Zeke monitors the execution of the remote job, but does not control it. Note: This type of remote job cannot be cancelled due to condition code processing.

81

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description Note: The values *REMOTE, *RMTFUL, and *RMTLIM can be used only when Zeke routes the job to a remote system on the same platform as the dispatching system. If you want to route a job from a z/OS system to a system on VSE, AIX, or AS/400, you must specify netregid as the target. If you want to route a job to the same platform (e.g., from one VSE system to another), you can specify either netregid or *REMOTE as the 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 locks, and you must press Reset and then the Tab key to continue.

Platform

Indicate the operating system on which the event is executed. The default values is the value of the DefPltfm generation option. These are the valid values: AIX (see Note below) DCOSX (Pyramid) HPUX (see Note below) MVS (i.e., z/OS) OS2 OS400 SUN (see Note below) TANDEM UNIX (e.g., AIX, AT&T, HPUX, NCR, SCO, SunOS, Sun Solaris, etc.) USYS VMS VSE WINDOWS (i.e., all supported versions) Note: Although the AIX, HPUX, and SUN platform codes are supported, ASG recommends that you use the UNIX platform code. Zeke does not download jobs (to a remote system) that have a platform of MVS or VSE.

5

82

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

4 Events

6

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

7

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

Downloading a Job Event to Zeke Agent Zeke enables you to download a subset of scheduled jobs in the Zeke schedule, cross-platform, to Zeke Agent on a UNIX platform, where Zeke Agent dispatches and tracks the jobs in the same manner as Zeke. Zeke Agent satisfies the time and WHEN conditions for the downloaded jobs, and dispatches the jobs when the prerequisites are met. The downloaded schedule can run stand-alone on Zeke Agent (even when its OASIS/DMS connection to Zeke is interrupted), as long as Zeke Agent can satisfy the predecessors for the SQR locally. Zeke also can dispatch an individual event directly to a Zeke Agent for execution and tracking (see “Routing a Job Event to Another System or Platform” on page 79 for more information).

To download a job event to Zeke Agent 1

Ensure that the Posid and Netregid generation options for your system are set appropriately, with Posid set to Y, and a valid, nonblank Netregid. (Generally, your system programmer defines these options. See “Job Networking Options” on page 317.)

2

Access the Event Master Definition screen for a job event, as described in Specify the information indicated in “Defining a Job Event” on page 69.“Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

Class:

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

83

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

If the remote system is secured, the Usrid field must specify a valid user ID on the remote system. 3

Complete these fields to specify the remote Zeke Agent: Field

Description

Target

Specify the Netregid of the remote Zeke Agent. Be sure that the specified Zeke Agent is defined in the Zeke database as a download agent (see “Defining Schedule Download Agents” on page 327).

Platform

Specify the operating system where the remote Zeke Agent resides. The default value is the value of the DefPltfm generation option. Enter UNIX.

4

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

5

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

6

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

Retrieving JCL from the Zeke Database You can store JCL in the Zeke database and retrieve it from the EMR. From Schedule View, you can retrieve both Zeke JCL and other valid JCL source types (from other JCL library facilities). See “Overriding JCL” on page 226 for instructions on retrieving and updating JCL.from Schedule View.

To retrieve and maintain JCL stored in the Zeke database 1

84

Verify that ZEKEJCL is defined as a JCL source type. See “JCL Source Options” on page 313.

4 Events

2

Access the Event Master Definition screen as instructed in “Accessing the Event Definition” on page 58. ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 60 Desc: TEST JOB ASG Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 01:01 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

3

Class:

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

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.LINKLIB.MVS1 000620 //* DD DISP=SHR,DSN=OASIS.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDJKL.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDMNO.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSMDUMP DD DISP=SHR,DSN=ZEKE.DUMP 000900 //SYSIN DD *

4

From this screen (which is controlled by the ISPF Text Editor), use standard ISPF commands to add, delete, or edit the JCL.

5

Press F3 to save the changes and return to the Event Master Definition screen. 85

ASG-Zeke Scheduling for z/OS User’s Guide

Defining a Message Event A message event can be any message that you want to be issued to the console. You could have certain consoles that are set up to receive certain messages. For example, the console for tape mounting might only receive messages with route code 3, while the printer console only receives messages with route code 7. All messages and route codes are logged to the SYSLOG file, regardless of the console that received them. For example, if you want the tape mount console operator to send a certain tape off site after a job is completed, you could set up a message event with a route code 3, and this message: Send tape offsite; dependent on good EOJ of the job.

You also could 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 in a message event.

To define or maintain a message event 1

Access the Event Master Definition screen for message events, as instructed in “Accessing the Event Definition” on page 58. 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: 0 Latestart: Early: Sched: 00:00 Mustend: Notafter: Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: Freqcalc: S Trig: A Control: Y SchEnv: ASGSCHEDUENVIRON Route: (3) Oper Oper Oper Oper Oper Oper

86

Msg1: END TAPE OFFSITE; DEPENDENT ON GOOD END OF JOB Msg2: Msg3: Msg4: Msg5: Msg6:

4 Events

2

Complete these fields to (as applicable) to define the message event: Field

Description

Template

Indicate whether you are defining a message event template. The valid values are Y and N. See “Defining an Event Template” on page 63 for more information.

Desc/Desc2

Specify a description of the message event. This description is displayed on summary screens and printed on reports.

Event Name

Specify the name of the message event. The event name is displayed on Zeke online screens and reports, and can be used as selection criteria. The event name also can be specified in end-of-event (EOE and AEOE) and end-of-group (EOG and AEOG) WHEN conditions.

Usrid

Specify the user ID (up to eight characters long) for the user authorized to access the message event. Because Zeke supports mixed-case user IDs, be sure to specify the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.

System

Specify the system or pool that owns the message event (which can be associated with only one system). Note: This is the system where the event is dispatched, and not necessarily the system where the EMR was defined.

Verload

Specify the number of versions of this event that Zeke loads during schedule build. The valid values range from 0 through 32767. The default value is 0. For example, if Verload is set to 3, Zeke adds EMRs to the schedule for three versions of the event during schedule build (i.e., versions 1, 2, and 3). If Verload is set to 0, then only one version of the event (version zero) can be in the schedule at a time. If Verload is set to 1, then Zeke loads only one version during the schedule build, but you can use the ZADD operator command to add multiple versions (up to 32,767) to the schedule after the schedule load. Note: ASG recommends that you run no more than 1,000 versions of a single event.

87

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description See “Creating Multiple Versions of an Event” on page 76 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 you 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.

Sched

Specify the normal schedule time for the event. The default value is 00:00 (i.e., the event is dispatched according to WHEN conditions instead of by time). See “Specifying a Schedule Time” on page 73 for a detailed explanation of schedule time.

3

88

Route

Specify the user-defined route code that corresponds to the alternate console route code.

Oper Msg

Specify the message text (up to six lines long) to issue to the system console.

Complete these fields (as applicable), which enable you to group events for selection for scheduling or reporting: Field

Description

App

Specify the code (up to eight characters long) to identify the application ID associated with the message event.

Grp

Specify the code (up to three characters long) to identify the group ID associated with the message event. This field is a subset of the application ID.

4

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

5

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

6

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

4 Events

Defining a Command Event A command event issues specified commands to a specified destination. These are the types of command events that you can define in Zeke: Type

Description

PCOM

VSE only. Any valid POWER command.

SCOM

Any command that can be issued from a console. You can specify an unlimited number of commands in an SCOM event. Zeke makes a security call for each individual command line in an SCOM event. See “Security Calls” on page 372 for more information.

VCOM

Any valid VM CP command.

ZCOM

Any valid Zeke operator command (or a combination).

SCOM events are the most versatile command type. You can use SCOM events to issue any type of console command, and including any of the other command event types (i.e., ZCOM, PCOM, and VCOM), which you can use only to issue particular types of commands. This procedure describes how to define an SCOM event. You define all of the other command event types in a similar manner.

89

ASG-Zeke Scheduling for z/OS User’s Guide

To define and maintain a system command event 1

Access the Event Master Definition screen for SCOM events, as instructed in “Accessing the Event Definition” on page 58: 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: 0 Latestart: 08:30 Early: Sched: 00:00 Mustend: Notafter: Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: Freqcalc: S Trig: A Control: Y SchEnv: ASGSCHEDUENVIRON

__ __ __ __ __ __ __

2

90

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

Complete these fields (as appropriate) to define an SCOM event: Field

Description

Template

Indicate whether you are defining a message event template. The valid values are Y and N. See “Defining an Event Template” on page 63 for more information.

Desc/Desc2

Specify a description of the command event. This description is displayed on summary screens and printed on reports.

Event Name

Specify the name of the command event. The event name is displayed on Zeke online screens and reports, and can be used as selection criteria. The event name also can be specified in end-of-event (EOE and AEOE) and end-of-group (EOG and AEOG) WHEN conditions.

4 Events

Field

Description

Usrid

Specify the user ID (up to eight characters long) for the user authorized to access the command event. Since Zeke supports mixed-case user IDs, be sure to specify the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.

System

Specify the system or pool that owns the command event (which can be associated with only one system). Note: This is the system where the event is dispatched, and not necessarily the system where the EMR was defined.

Verload

Specify the number of versions of this event that Zeke loads during schedule build. The valid values range from 0 through 32767. The default value is 0. For example, if Verload is set to 3, Zeke adds EMRs to the schedule for three versions of the event during schedule build (i.e., versions 1, 2, and 3). If Verload is set to 0, then only one version of the event (version zero) can be in the schedule at a time. If Verload is set to 1, then Zeke loads only one version during the schedule build, but you can use the ZADD operator command to add multiple versions (up to 32,767) to the schedule after the schedule load. Note: ASG recommends that you run no more than 1,000 versions of a single event. See “Creating Multiple Versions of an Event” on page 76 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 you 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.

91

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description

Sched

Specify the normal schedule time for the event. The default value is 00:00 (i.e., the event is dispatched according to WHEN conditions instead of by time). See “Specifying a Schedule Time” on page 73 for a detailed explanation of schedule time.

Code

Line 001 through line 005

Indicate the type of command. These are the valid values: C

System command

P

VSE/POWER command

R

System response

V

VM command

Z

Zeke command

Specify 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 (after the first one), and press Enter. The screen is redisplayed with a new blank line. (Any existing SCOM lines below the cursor are hidden.) Repeat, as necessary, to add additional lines. (The new lines are added to the EMR, and the existing lines are redisplayed.) When you enter multiple Zeke operator commands on the same line, you must include the command prefix on the first command only. For example, if your command prefix is ASG, specify multiple commands in an SCOM event like this: C 001 ASGZAD EV 12 HOLD ZAD EV 89 HOLD

When you are using variable substitution in an SCOM event, the length of each line cannot be greater than 60 bytes (including the variable values). For example, let’s suppose you submit this SEND command from an SCOM event: SE ‘THIS IS A TEST TEST TEST TEST TEST.’,USER=($ABCVAR)

Let’s suppose that the value of the variable named $ABCVAR equals ABCABCABCABCABC. The length of the command in the example is exactly 60 bytes; however, when Zeke performs variable substitution for $ABCVAR, the length of the line will exceed 60 characters.

92

4 Events

3

Complete these fields (as applicable), which enable you to group events for selection for scheduling or reporting: Field

Description

App

Specify the code (up to eight characters long) to identify the application ID associated with the command event.

Grp

Specify the code (up to three characters long) to identify the group ID associated with the command event. This field is a subset of the application ID.

4

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

5

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

6

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

Defining a REXX Event A REXX event enables you to dispatch and monitor REXX EXECs. If you plan to use REXX events, also review the chapter on OASIS/ECF in the ASG-OASIS for z/OS Reference Guide.

93

ASG-Zeke Scheduling for z/OS User’s Guide

To define and maintain REXX events 1

Access the Event Master Definition screen for REXX events, as instructed in “Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

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: 0 Latestart: Early: Sched: 00:00 Mustend: Notafter: Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: Freqcalc: S Trig: A Control: Y SchEnv: ASGSCHEDUENVIRON REXX exec: REXX1

Class: A

Pri: 1

Argument:

2

Complete these fields (as appropriate) to define a REXX event: Field

Description

Template

Indicate whether you are defining a message event template. The valid values are Y and N. See “Defining an Event Template” on page 63 for more information.

Desc/Desc2

Specify a description of the REXX event. This description is displayed on summary screens and printed on reports.

Event Name

Specify the name of the REXX event. The event name is displayed on Zeke online screens and reports, and can be used as selection criteria. The event name also can be specified in end-of-event (EOE and AEOE) and end-of-group (EOG and AEOG) WHEN conditions.

Usrid

Specify the user ID (up to eight characters long) for the user authorized to access the REXX event. Since Zeke supports mixed-case user IDs, be sure to specify the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.

94

4 Events

Field

Description

System

Specify the system or pool that owns the REXX event (which can be associated with only one system). Note: This is the system where the event is dispatched, and not necessarily the system where the EMR was defined.

Verload

Specify the number of versions of this event that Zeke loads during schedule build. The valid values range from 0 through 32767. The default value is 0. For example, if Verload is set to 3, Zeke adds EMRs to the schedule for three versions of the event during schedule build (i.e., versions 1, 2, and 3). If Verload is set to 0, then only one version of the event (version zero) can be in the schedule at a time. If Verload is set to 1, Zeke loads only one version during the schedule build, but you can use the ZADD operator command to add multiple versions (up to 32,767) to the schedule after the schedule load. Note: ASG recommends that you run no more than 1,000 versions of a single event. See “Creating Multiple Versions of an Event” on page 76 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 you 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.

Sched

Specify the normal schedule time for the event. The default value is 00:00 (i.e., the event is dispatched according to WHEN conditions instead of by time). See “Specifying a Schedule Time” on page 73 for a detailed explanation of schedule time.

95

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description

Control

Specify the code indicating whether this event is executed and tracked as a Zeke-controlled event. These are the valid values:

REXX exec

Y

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.

N

Zeke does not recognize this event as Zeke-controlled. A REXX event that is not Zeke-controlled is completed with a status of EOE.

NX

Zeke recognizes the event as a nonexecutable Zeke-controlled event.

Specify the name of the member that contains the REXX EXEC. The dataset that contains this member must be defined in the SYSEXEC or SYSPROC DD concatenation of the OASIS/ECF address space started task. Zeke calls the REXX program as a function. A RETURN statement with an explicit return code is required: • If the return code is 0, Zeke considers the REXX event to be successful. • If the return code in the RETURN statement is nonzero, is unspecified, or if the program exits without a RETURN statement, then Zeke considers the REXX event to have failed. Note: Sample member REXSAMP in the Zeke SALTINS0 library contains a sample REXX program for maintaining control over the event status (i.e., EOE or AEOE).

96

Class

Specify the OASIS/ECF EXEC class associated with the REXX EXEC. The valid classes range from A through Z, and from 0 through 9.

Pri

Specify the OASIS/ECF EXEC queue priority. The valid values range from 1 through 9 (where 1 is the highest priority). The default value is 5. The priority value is used only if there is no free ECF task for the specified class when Zeke dispatches event. In this case, the request is queued, and this priority is used to determine which EXEC for the class executes when a task is available.

Argument

Specify the argument string to pass to the REXX EXEC when Zeke dispatches the REXX event. The string’s values can be parsed into local REXX variables in the EXEC.

4 Events

3

Complete these fields (as applicable), which enable you to group events for selection for scheduling or reporting: Field

Description

App

Specify the code (up to eight characters long) to identify the application ID associated with the REXX event.

Grp

Specify the code (up to three characters long) to identify the group ID associated with the REXX event. This field is a subset of the application ID.

4

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

5

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

6

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

Defining a Recurring or Permanent Event You can define an event to occur multiple times across a particular schedule run, or to occur across every schedule (until it is removed from the schedule). These events are referred to as recurring events and permanent events, respectively.

Recurring Events A recurring event occurs more than once in a single schedule period. For example, a message that is issued to the operator every hour is a recurring event. You define the frequency or time interval and the number of occurrences. You can use a recurring event to trigger other events each time it runs, or only on the first or last occurrence.

Not After Time If a recurring event has a ‘not after’ time (Notafter) time specified, and the calculated start time is greater than the Notafter time, Zeke does not reschedule the event, and considers it done.

WHEN Conditions Zeke resets a recurring event’s WHEN conditions at dispatch time, not at completion time. The event’s WHEN conditions can be satisfied even while the event is running.

Recurring Job Status Recurring events that have reached a Done status at least once, and are scheduled to run again, display in the output for both the ZD DONE and ZDISPLAY operator commands. 97

ASG-Zeke Scheduling for z/OS User’s Guide

Permanent Events Zeke never removes a permanent event from the schedule, so the event always is available to respond to triggers (even during schedule load processing). A permanent event 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 remove it using the ZDELETE operator command. Zeke processes permanent events in the same manner as recurring events, with these exceptions: •

Zeke forces the OCCURS clause to REQUEST.

•

Zeke ignores nonworking day options in the calendar.

•

Only one version can be active (the Verload field is set to 0).

•

The event can be triggered by any date. The values of the Zeke generation options TrigDt, DsnTrig, and RemTrig are treated as “any” (i.e., A or TA).

•

Zeke ignores any MultHit generation options.

Schedule Time Zeke uses only the schedule time (Sched) to time-satisfy a permanent event, and ignores any other time specifications (e.g., early time). Each time Zeke executes (and then reschedules) a permanent event, the run date increments, so that the schedule time stays under 24:00. (Normally, when the schedule time passes 24:00, the run date increments and the schedule time is reduced by 24 hours.) You can set the schedule time, or any other time that increments at rescheduling (e.g., Late, Mustend, or Notafter), above 24:00 in the EMR for a permanent event. The first time Zeke reschedules the event, the run date increments so that the updated schedule time is below 24:00.

Freqcalc is S (Schedule Time) When Zeke reschedules a permanent event (with the Freqcalc value set to S) Zeke updates the event’s run date and schedule time to its previous run date and schedule time (added to the event’s frequency). When Zeke reschedules a permanent event (with the Freqcalc value set to S) that has a run date in the past (e.g., after a database restore), the event’s run date and schedule time are still likely to be in the past. So, Zeke immediately considers the event to be time-satisfied (TIMEOK), instead of waiting. Zeke immediately considers the event to be time-satisfied every time the event is rescheduled, until its run date and schedule time catch up to the system date and time.

98

4 Events

When a permanent event (with the Freqcalc value set to S) has a run date in the future, is forced to run, and then is rescheduled, the event’s updated run date and schedule time remain in the future. The event becomes time-satisfied when the system date and time reach the event’s updated run date and schedule time.

Freqcalc is C (Clock Time) When Zeke reschedules a permanent event (with the Freqcalc set to C), the event’s run date and schedule time are set to the current system date and time (added to the event’s frequency). When Zeke reschedules a permanent event (with the Freqcalc value set to C) that has a run date in the past, the event’s run date and schedule time are updated to the current system date and time (added to the event’s frequency). So, Zeke now waits until the frequency interval is past before considering the event to be time-satisfied again. When a permanent event (with the Freqcalc value set to C) has a run date in the future, is forced to run, and then is rescheduled, the event’s run date and schedule time are reset to the current date and time (added to the event’s frequency). The event becomes time-satisfied again when its frequency has expired, instead of waiting for its future run date (which is reset to today's date).

To define a recurring or permanent event 1

Access the Event Master Definition screen, as instructed in “Accessing the Event Definition” on page 58. ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 3 Freq: 00:30 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

Class:

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

99

ASG-Zeke Scheduling for z/OS User’s Guide

2

Complete these fields (as applicable) to define a permanent or recurring event: Field

Description

Permanent Indicates whether to retain the event in the schedule permanently (i.e., indefinitely). These are the valid values:

Times

N

Default. Zeke processes the event for each schedule run according to the OCCURS clause.

Y

The event must be added to the schedule using the ZADD operator command. After you add the event, it remains in the schedule (across schedule runs) until you delete the event using the ZDELETE operator command.

Specify the number of times Zeke dispatches the event per schedule run. For a recurring event, the valid values range from 2 through 9999. For a permanent event, you do not specify a Times value; Zeke considers the number of times to be unlimited. Zeke automatically sets the value to 000. If you later update a permanent event to remove the permanent specification, Zeke automatically sets the Times value to 1.

Freq

Specify the amount of time Zeke waits before dispatching a recurring event again. To determine the next dispatch time, Zeke adds the Freq value to the current system time or current schedule time (depending on the Freqcalc value). Note: ASG recommends that you specify a Freq time and/or a WHEN condition for permanent and recurring events. If you set the Freq value to 00:00, Zeke immediately considers the recurring or permanent event to be time-satisfied after each completion. When the WHEN condition (if one exists) becomes satisfied, Zeke dispatches the event. Note: For a permanent event, Zeke sets the run date to the current system date when the next schedule time passes 24:00.

100

4 Events

Field

Description

Freqcalc

Indicate how to calculate the next dispatch time for the recurring or permanent event. These are the valid values:

Trig

C

Zeke schedules the event based on the completion time of the previous run. Zeke uses the current time and the Freq time to determine the next dispatch time. If the event becomes delayed for any reason, Zeke dispatches any missed runs according to the Freq value.

S

Zeke schedules the event by its start time, regardless of the time the event actually runs. If the event becomes delayed for any reason, Zeke dispatches any missed runs immediately.

Indicate how the recurring event satisfies WHEN conditions (i.e., serves as a trigger) for other events. Note: This field is valid for recurring events only; permanent events trigger other events on all occurrences. These are the valid values: A

Default. The recurring event triggers other events each time it runs.

F

The recurring event trigger other events only the first time it runs.

L

The recurring event triggers other events only the last time it runs.

For example, let’s suppose that for a recurring event, you specify these values: Times

24

Freqcalc S (schedule time) Freq

01:00 (one hour)

Trig

F

Start time

8:00

101

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description Zeke schedules the event to run at 8:00 A.M. Zeke adds the schedule time (8:00) to the Freq value (01:00), and reschedules the event at 9:00 A.M. Zeke repeats this until the event has been dispatched the specified number of times (24). The event satisfies WHEN conditions for other events only on the 8:00 A.M. run. All subsequent triggers for the event are ignored (until the event is rebuilt or refreshed). You could update the Trig value to A to enable the event to satisfy WHEN conditions every hour, on all 24 runs.

3

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

4

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

5

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

Defining a Milestone Event A milestone event is a significant event in an event flow (that includes predecessor/successor relationships) that must process on time to avoid a significant delay in the completion of the entire flow. Events flagged as milestones are not processed any differently from other events—the milestone flag simply makes these events more easy to identify in the event flow. In Schedule View (ISPF only), milestone events are indicated by an asterisk in the Milestone column.

102

4 Events

Note:

In OpsCentral, you can filter events that have been flagged as milestone events. You also can view (graphically) the positions of milestone events in the event flow. If you use ASG-Unified Management Architecture (herein called UMA), information about Zeke milestone events can be sent to UMA automatically. Through the Zeke server, Zeke communicates these milestone event statuses for display in Zeke, from an OpsCentral client, or in a UMA dashboard: Status

Description

n/a (gray)

Indicates whether the milestone event is in the current schedule.

Normal (green)

Indicates whether Zeke expects the milestone event to process normally in the event flow.

Met (blue)

Indicates whether the milestone was met successfully (i.e., the event completed successfully within all of its time constraints).

Missed (red)

Indicates whether the milestone event has failed or violated a time constraint (according to its Latestart, Lateend, Notafter, or Mustend times).

At-risk (yellow)

Indicates whether the milestone event is at risk because of a problem with a predecessor (or other projected time violation). You can define the criteria that puts a milestone event at risk through this variable in the ZENVIRN file: ZEKE_SERVER_MILESTONE_AT_RISK

(See the ASG-Zeke Scheduling for z/OS Installation Guide for details.) This is an example of an alert that would be issued to OpsCentral if a milestone were at risk because of a failed predecessor: Milestone event 000060 2009134 ver 00001 JOBKAC is at risk due to predecessor events: Event 000083 2009134 ver 00001: Failed

103

ASG-Zeke Scheduling for z/OS User’s Guide

Critical Path Milestone events are an essential element in the concept of a critical path. The critical path is the sequence of predecessor/successor events that will take the longest to complete. The critical path represents the minimum amount of time to complete the event flow from the event with the earliest start through the event that finishes last. The critical path could change from time to time as events are completed ahead of or behind schedule. Typically, delays along the critical path imply that additional time is required to complete the event flow. This helps you monitor the completion of the current schedule to ensure that there is no conflict with the start of the next schedule.

To define a milestone event 1

Access the Event Master Definition screen for a job event, as described in “Accessing the Event Definition” on page 58.

2

In the Milestone field, indicate whether the event is a milestone event. This designation is valid for any type of event. These are the valid values: Code

Meaning

N

Default. Do not designate the event as a milestone.

Y

Designate the event as a milestone, which Zeke flags in Schedule View and OpsCentral.

3

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

4

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

5

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

Note:

You also can flag an event as a milestone using the EVENT function of the ZEKE utility program. See the ASG-Zeke Scheduling for z/OS Reference Guide for details.

104

4 Events

Using Scheduling Environments Zeke supports IBM Workload Manager (WLM) scheduling environments for dispatching all event types. A scheduling environment defines the conditions for when an event can (or cannot) be dispatched, and is a collection of resources and their required states. When all resources for a system match an environment’s defined requirements, the environment becomes active. Events can be scheduled to the system because it satisfies all of the required resource states listed in the scheduling environment. (For more information on defining scheduling environments, see your IBM documentation, MVS Planning: Workload Management.) You also can define Zeke as a resource in a WLM scheduling environment. This resource is used to indicate whether Zeke is active (on) or inactive (off) on a system to ensure Zeke-submitted jobs run only on MVS systems where Zeke is running. See the ASG-Zeke Scheduling for z/OS Installation Guide for instructions on how to define Zeke as a WLM resource. The Zeke generation option ChkSEnv (see “Dispatching Options” on page 297) determines whether Zeke performs scheduling environment checking. If the ChkSEnv option is set to Y, Zeke checks the EMR for each event to be scheduled for the value of the SchEnv field, which indicates the name of the requested scheduling environment. Based on the SchEnv value, Zeke dispatches the event according to these rules: •

For job events targeted for the current system, and all other event types, Zeke dispatches the event when the scheduling environment is active.

•

For job events targeted for a pool, Zeke dispatches the event if the scheduling environment is active on any system in the pool.

•

For job events targeted for a remote system, Zeke does not check for the scheduling environment.

Generally, you specify or change the scheduling environment for an event in the EMR. You also can modify the scheduling environment in these ways: •

By changing the Scheduling Environment value in Schedule View. See “Using Schedule View” on page 191.

•

By executing the EVENT ADD/UPDATE batch utility and including the SCHENV parameter. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information.

•

By issuing the ZALTER operator command and including the NEWSCHENV keyword. See the ASG-Zeke Scheduling for z/OS Reference Guide) for more information.

105

ASG-Zeke Scheduling for z/OS User’s Guide

To specify a scheduling environment 1

Access the Event Master Definition screen as instructed in “Accessing the Event Definition” on page 58. ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 163 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 3 Freq: 00:30 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: CGCJOBA JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

2

Class:

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

In the SchEnv field, specify the name of the WLM scheduling environment (up to 16 characters long). Note:

Zeke does not validate this name; an invalid name will cause JES to fail the job. If you specify a scheduling environment, Zeke schedules the event and the event waits in the dispatch queue until the scheduling environment becomes active (i.e., until the resource states defined in the scheduling environment are matched). Note:

For a job event, you can insert this value in the JCL before the job is submitted to JES. See “JOB Card Override” on page 315 for more information.

106

3

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

4

Perform the procedure, “Defining an OCCURS Clause” on page 121, to specify when Zeke schedules the event.

5

Perform the procedure, “Defining a WHEN Condition” on page 139, to specify any prerequisites that must occur before Zeke dispatches the event.

4 Events

OCCURS Clauses The OCCURS clause specifies the day or days Zeke schedules an event. The SCHEDULE function of the ZEKE utility program scans the Zeke database, and select each event to process on the specified schedule date based on its OCCURS clauses. Zeke schedules an event when the event’s OCCURS clause is true. For example, let’s suppose you define an event 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 OCCURS clause is false (in this case, Zeke does not schedule the event). See “OCCURS Keywords” on page 109 for a list and description of all OCCURS clause keywords.

OCCURS Clause Format This is the OCCURS clause format: OCCURS (keyword AND|OR keyword)

Enclose the entire clause (excluding the word OCCURS) within parentheses. Any AND/OR logic and additional keywords are optional. Examples: This event OCCURS on Mondays: OCCURS (MONDAY)

This 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 0.

Multiple OCCURS Clause Phrases An event can have more than just one OCCURS clause phrase. For example, this event is scheduled every Monday and Thursday (the event is defined with two OCCURS clause phrases joined by OR): OCCURS (MONDAY OR THURSDAY)

107

ASG-Zeke Scheduling for z/OS User’s Guide

The keyword OR indicates the event is scheduled when either clause is true. The keyword AND indicates the event is scheduled only when both OCCURS clauses are true. Examples: This event is scheduled every Monday during January: OCCURS (MONDAY AND JANUARY)

This event is scheduled only when the current schedule date is Monday, and Thursday: OCCURS (MONDAY AND THURSDAY)

Because this case is impossible, this OCCURS clause is invalid and Zeke never schedules the event.

Grouping Multiple OCCURS Clause Phrases In addition to AND/OR relationships between multiple OCCURS clause phrases, you can group multiple OCCURS clauses to resolve one group of clauses before resolving the next, higher group. You use additional sets of parentheses to group multiple clauses. For example, let’s suppose an event is scheduled for any Monday during the first month of each quarter. The months are January, April, July, and October. You would specify the OCCURS clause like this: OCCURS (MONDAY AND (JANUARY OR APRIL OR JULY OR OCTOBER))

Zeke resolves the innermost group 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, Zeke schedules the event only if it is a Monday in one of the named months. You use additional sets of parentheses only to separate multiple conditions. For example, Because MONDAY and TUESDAY are not multiple conditions, it is not necessary to code the clause like this: (WORKDAYS AND ((MONDAY) OR (TUESDAY)))

Instead, this clause is valid: (WORKDAYS AND (MONDAY OR TUESDAY))

108

4 Events

OCCURS Keywords You can use these symbols in an OCCURS clause that includes keywords: Symbol

Description

.

Specifies an occurrence of a keyword. For example:

(period)

OCCURS (MONDAY.L)

Schedules on the last Monday of each month or period. OCCURS (MONDAY.2)

Schedules on the second Monday of each month or period. + (plus)

Adds the specified number of days or workdays. You can use this symbol with the period (.) keyword followed by L, or a value from 1 through 24. For example: OCCURS (MONDAY.L + 3 DAY)

Schedules three days after the last Monday of each month or period. OCCURS (MONDAY.L + 3 WDAY)

Schedules three workdays after the last Monday of each month or period. (minus)

Subtracts the specified number of days or workdays. You can use this symbol with the period (.) keyword followed by L, or a value from 1 through 24. For example: OCCURS (TUESDAY.1 - 5 WDAY)

Schedules five workdays before the first Tuesday of each month or period. OCCURS (EOM-2)

Schedules two days before the last day of each month.

You can use these keywords in an OCCURS clause: Keyword

Description

DAILY

Schedules on any day that the SCHEDULE function runs, regardless of whether the day is a workday, weekend, or holiday.

WORKDAYS

Schedules on any normal working day (not on holidays or weekends).

MONDAY

Schedules on Mondays.

TUESDAY

Schedules on Tuesdays.

WEDNESDAY

Schedules on Wednesdays.

THURSDAY

Schedules on Thursdays.

FRIDAY

Schedules on Fridays.

109

ASG-Zeke Scheduling for z/OS User’s Guide

Keyword

Description

SATURDAY

Schedules on Saturdays.

SUNDAY

Schedules on Sundays.

WMONDAY

Schedules on working Mondays.

WTUESDAY

Schedules on working Tuesdays.

WWEDNESDAY

Schedules on working Wednesdays.

WTHURSDAY

Schedules on working Thursdays.

WFRIDAY

Schedules on working Fridays.

WSATURDAY

Schedules on working Saturdays.

WSUNDAY

Schedules on working Sundays.

JANUARY

Schedules if January. Use with AND. For example: OCCURS (FRIDAY.L AND JANUARY)

Schedules on the last Friday in January.

110

FEBRUARY

Schedules if February. Use with AND.

MARCH

Schedules if March. Use with AND.

APRIL

Schedules if April. Use with AND.

MAY

Schedules if May. Use with AND.

JUNE

Schedules if June. Use with AND.

JULY

Schedules if July. Use with AND.

AUGUST

Schedules if August. Use with AND.

SEPTEMBER

Schedules if September. Use with AND.

OCTOBER

Schedules if October. Use with AND.

NOVEMBER

Schedules if November. Use with AND.

DECEMBER

Schedules if December. Use with AND.

EOM

Schedules on last day of the month.

EOM-xx

Schedules xx days before last day of the month.

4 Events

Keyword

Description

WEOM

Schedules on last working day of the month.

WEOM-xx

Schedules xx working days before last working day of the month.

DAY

Schedules on the specified day of the month.

DAY yy xx

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 ranging from 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. yy is an operator (LE, LT, GE, GT, NE, EQ) or period (.). xx is a number ranging from 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 also can be used to refer to the current Julian day in comparison phrases. For example: OCCURS (JDAY LE 31)

Schedules on the first 31 days of the year. OCCURS (JDAY.L)

Schedules on the last day of the year.

111

ASG-Zeke Scheduling for z/OS User’s Guide

Keyword

Description

DATE xx mm/dd/yyyy

Schedules on the specified date if the relationship is true, where: xx is the operator (i.e., LE, LT, GE, GT, NE, or EQ). mm/dd/yyyy is an actual date. For example: OCCURS (DATE LE 12/31/2012)

Schedules on any date less than or equal to December 31, 2012. Note: You also can use the date format dd/mm/yyyy if your OASISxx options member specifies the start-up option DATE=DDMM. MONTH

Schedules during the specified month. Use with AND. For example: 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 could 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 during the specified week in a month or period. Use with AND. For example: 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 the specified week in the month or period that includes Monday through Sunday. Use with AND. For example: 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 on the working days of the week. For example: OCCURS (WDAYW.2)

Schedules on the second workday of each week, which is based on the workdays and holidays specified in the calendar. WFWEEK

Schedules during the specified full work week in the month or period that includes all normal workdays in that week. Use with AND. For example: 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.

112

4 Events

Keyword

Description

USEREXIT

Calls a user-written program during OCCURS clause processing. All Zeke calendar table information is passed to the exit. The USEREXIT keyword determines whether the event should be scheduled. For example: OCCURS (USEREXIT TESTOCCUR)

Schedules if the user exit returns a response of true. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information on OCCURS clause user exists, and on using this keyword. EVERY xxx DAYS BEGINNING mm/dd/yyyy

EVERY xxx WDAYS FROM mm/dd/yyyy

Schedules every xxx days beginning on the specified date. Zeke does not schedule the event before the specified date. Note: You also can use the date format dd/mm/yyyy if your OASISxx options member specifies the start-up option DATE=DDMM. Schedules every xxx workdays before and after the specified date (when scheduling events for the future). Note: You also can use the date format dd/mm/yyyy if your OASISxx options member specifies the start-up option DATE=DDMM.

REQUEST

Zeke does not add the event to the schedule automatically. You must issue the ZADD operator command to schedule the event.

REFEVENT eventname/ number

Schedules according to the calendar (including nonworking days) and the OCCURS clause of another event. If you update the OCCURS clause or calendar for the referenced event, Zeke schedules all events that reference the event according to the changes. You can specify the event that you want to reference either by event number or event name. Because an event name might not be unique in the Zeke database, Zeke selects the first event that matches the event name for the reference.

Caution! Event numbers are unique; however, because Zeke assigns the event numbers automatically (and can reuse event numbers), ASG recommends that you reference other events by event name to avoid unintended references. You can use this keyword in combination with other OCCURS keywords. For example: OCCURS (REFEVENT ASGJOB1 + 2 WDAY)

Schedules two workdays after the OCCURS of event ASGJOB1.

113

ASG-Zeke Scheduling for z/OS User’s Guide

Keyword

Description

NOT

Schedules if the specified keyword condition is false. This keyword can be used for a single condition or for a compound condition enclosed in parentheses. For example: 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

Schedules if both of the specified conditions are true.

OR

Schedules if either of the specified conditions is true.

BEFORE

Schedules on the working day before the normal selection day (if the day is a holiday or weekend).

AFTER

Default. Schedules on the working day after the normal selection day (if the day is a holiday or weekend).

ON

Schedules on the normal selection day even (if normal selection day is a holiday or weekend).

Note: You use the keywords BEFORE, AFTER, and ON to schedule an event when it would normally fall on a holiday or weekend. Place these keywords immediately after another keyword or compound conditions enclosed in parentheses. If you do not specify BEFORE or ON, Zeke schedules the event the day after a holiday or weekend (unless the Nwday field in the EMR specifies differently). See “Scheduling Events on Holidays and Weekends” on page 118. PERIOD

Schedules the event according to the specified period. For example: OCCURS (MONDAY.L AND PERIOD.3)

Schedules on the last Monday in the third period of the calendar. HOLIDAYS

Schedules on holidays. Note: To code an OCCURS clause with a relational reference to a holiday (e.g., (HOLIDAYS + 1 DAY)), you must set the Nwday field to O in the EMR, which indicates to schedule the event on the nonworking day.

114

WEEKENDS

Schedules on weekends.

HOL/WEEK

Schedules on holidays and weekends.

4 Events

Keyword

Description

CALENDAR

Schedules based on the specified criteria, and according to the specified special calendar. Use with AND. For example: OCCURS (CALENDAR TEST1 AND WEDNESDAY)

Schedules only for the Wednesdays that are marked in special calendar TEST1. Schedules if the specified Zeke variable is true. Use with AND. For example:

VAR

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.

Sample OCCURS Clauses These 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/2012)

Occurs every Wednesday before January 31, 2012. OCCURS (MONDAY.1 OR MONDAY.3)

Occurs the first and third Monday of each month or period. OCCURS (EVERY 14 DAYS BEGINNING 02/12/2012)

Occurs every other Tuesday starting on February 12, 2012. OCCURS (EVERY 5 WDAYS FROM 03/26/2012)

Occurs every Wednesday before and after March 26, 2012. 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 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. 115

ASG-Zeke Scheduling for z/OS User’s Guide

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. 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. 116

4 Events

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. OCCURS (((WDAYW.1 - 2 DAY) AND NOT HOLIDAYS) OR ((MONDAY AND HOLIDAYS) - 1 DAY))

Occurs the second nonholiday 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 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 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 Friday—even 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.

117

ASG-Zeke Scheduling for z/OS User’s Guide

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). OCCURS (DAY EQ 15 BEFORE HOL/WEEK)

Occurs 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 are scheduled for the actual day. OCCURS (JDAY.60)

Occurs the 60th day of the year, either March 1 of nonleap year, or February 29 in a leap year. OCCURS (JDAY.L)

Occurs the last day of the year. OCCURS (JDAY.L - 1 DAY)

Occurs 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.

Scheduling Events on Holidays and Weekends These OCCURS clause keywords are affected by holidays and weekends: DATE xx mm/dd/yyyy DAY. EOM HOLIDAYS MONDAY-SUNDAY DAY EQ xx EVERY xx DAYS EOM-xx 118

4 Events

HOL/WEEK WEEKENDS

An event that you define to occur on a particular day of the week, could hit on a nonworking day. For example: OCCURS (EVERY xx DAYS)

However, an event that you define to occur according to any of these conditions is not affected by holidays or weekends because a workday, by definition, cannot be a holiday or weekend: OCCURS (WORKDAYS) OCCURS (WDAY EQ xx) OCCURS (WDAY.L-xx OR WEOM-xx) By default, when an event is defined to occur on a nonworking day, Zeke schedules the event for the next working day. (You can change this behavior for an event using the Nwday field in the EMR, or globally using the NonWkday generation option.) For example, let’s suppose that an event is defined to occur on Monday, and Monday is a holiday. Even if the SCHEDULE function is processed on Monday, Zeke does not schedule the event because Monday is a holiday. Zeke schedules the event for the following Tuesday (but still dates the event with Monday’s date), and places it in Tuesday’s schedule. Zeke dates the event with Monday’s date because there could already be another scheduled event for Tuesday (e.g., if the event is defined to occur Monday and Tuesday).

ON, BEFORE, and AFTER Keywords You can use the these keyword phrases to schedule an event before a holiday or weekend: BEFORE HOLIDAYS BEFORE WEEKENDS BEFORE HOL/WEEK

You can use these same phrases with the keyword ON (instead of BEFORE) to schedule the event on the hit date (even if it could be a holiday or weekend). For example: To schedule the event the prior working day, Friday, use this OCCURS clause: OCCURS (MONDAY BEFORE HOLIDAYS)

To schedule the event Mondays (even if Monday is a holiday), use this OCCURS clause: OCCURS (MONDAY ON HOLIDAYS)

119

ASG-Zeke Scheduling for z/OS User’s Guide

To schedule an event for every Saturday (when Saturday is defined as a weekend), use this OCCURS clause: OCCURS (SATURDAY ON WEEKENDS)

You can use the keywords ON, BEFORE, and AFTER outside of parentheses to apply to all of the keywords that are within parentheses. (This does not apply if there is an individual holiday or weekend specified.) For example: This clause schedules every Monday and Tuesday; however, if Monday is a holiday, it schedules on the previous workday. If Tuesday is a holiday, it schedules on the next workday. OCCURS ((MONDAY BEFORE HOLIDAYS) OR TUESDAY)

This clause schedules Monday or Tuesday. If either is a holiday, it schedules on the previous workday: OCCURS ((MONDAY OR TUESDAY) BEFORE HOL)

This clause schedules every Sunday in August, even if Sunday is defined as a weekend day: OCCURS ((SUNDAY AND AUGUST) ON WEEKENDS)

Nwday Field/Nonwkday Option The Nwday field in the event’s EMR specifies whether to schedule after, before, or on a holiday (or not at all). 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 the NonWkday generation option (see “Scheduling Options” on page 320), which specifies the default Nwday value when you add an EMR.

DAILY Keyword The DAILY keyword schedules an event on any day that the SCHEDULE function runs, regardless of whether that day is a workday, weekend, or holiday. The keywords ON, BEFORE, and AFTER have no effect on the OCCURS clause keyword DAILY.

120

4 Events

Defining an OCCURS Clause This procedure explains how to define an OCCURs clause for an event in the EMR and then test the clause to ensure that it schedules the event as expected.

To define and test an OCCURS clause 1

Access the Event Master Definition screen for the desired event, as instructed in “Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 6 Desc: TEST JOB Type: JOB Desc2: Event Name: ZEKE60TST6 App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 3 Freq: 00:30 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: TSKKGUT1

Class:

JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

2

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

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

Evt: 000006 Type: JOB Job: TSKKGUT1 Evt Name: ZEKE60TST6 Calid: A Ver: 00000 Platform: MVS Occurs: (TUESDAY OR WEDNESDAY OR DAY.11)

121

ASG-Zeke Scheduling for z/OS User’s Guide

3

In the Occurs field, specify a valid OCCURS clause. You must enclose the OCCURS clause in parentheses. These are the most common OCCURS keywords: Keyword

Description

REQUEST

Default. Zeke does not schedule the event automatically. You must add the event the schedule through Schedule View or using the ZADD operator command through the ZCOM option. See “Using Schedule View” on page 191 or “Using the ZADD Operator Command” on page 247.

DAILY

Zeke schedules the event every day, regardless of whether it is a workday, weekend, or holiday.

WORKDAYS

Zeke schedules the event on workdays (as defined on the calendar specified for the event).

EOM

(End of month) Zeke schedules the event on last day of each month.

See “OCCURS Clauses” on page 107 for a full discussion of OCCURS clauses. See “OCCURS Keywords” on page 109 for a complete list of valid keywords. 4

Press Enter to save the event with the new OCCURS clause.

5

Enter OCCHIT on the Command line, and press Enter. The OCCURS Hit Resolution screen is displays the days of the current month: ASG-Zeke Command ===>

Occurs Hit Resolution

EDIT

Primary Commands: BROWSE EDIT NMONTH PMONTH NYEAR PYEAR Month: 03 Year: 2012 Event: 000006 Ename: ZEKE60TST6 M O N

T U E

W E D

T H U

F R I

3 10 17 24 31

4 11 18 25

5 12 19 26

6 13 20 27

7 14 21 28

* * * *

* * * *

S A 1 8 15 22 29

Calid: A T W W W W W

S U 2 9 16 23 30

N W W W W W

Ver: 00000 Occurs: (TUESDAY OR WEDNESDAY OR DAY.11)

W = Weekend H = Holiday S = Slack day *X = Event scheduled x times on this date

* = Event scheduled on this date

An asterisk (*) marks the days the event is scheduled to occur.

122

4 Events

Zeke uses these codes to indicate the status of each day in the current month:

6

Code

Meaning

W

Weekend day

H

Holiday

S

Slack day (i.e., day in the period between accounting calendars)

Review the results of the OCCURS clause for at least the next 12 months to verify that the event is hitting the schedule as expected. Perform the steps in the Action column (depending on the desired result): Desired Result

Action

View the schedule for the next month

Enter NMONTH on the Command line, and press Enter.

View the schedule for the previous month

Enter PMONTH on the Command line, and press Enter.

View the schedule for the next year

Enter NYEAR on the Command line, and press Enter.

View the schedule for the previous year

Enter PYEAR on the Command line, and press Enter.

View the schedule for a specific month

Specify the number of the month (e.g., 01 for January, 12 for December) in the Month field, and press Enter.

View the schedule for a specific year

Specify the year in the Year field, and press Enter.

123

ASG-Zeke Scheduling for z/OS User’s Guide

WHEN Conditions You use WHEN conditions to specify the conditions that must occur before Zeke dispatches a scheduled event. Zeke does not dispatch an event until its WHEN conditions are satisfied. A WHEN condition, also known as a dependency, can be any of these actions or conditions: •

Execution of a specific program, system job, or another 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 defined dependency, then Zeke dispatches the event according to the specified schedule time in the EMR. Work centers do not have WHEN conditions (see “Work Centers” on page 149).

Job and Program WHEN Conditions Job and program WHEN conditions become satisfied when the system initiates or completes the action named in the dependency (e.g., starting or ending a specific job) for an event. As each dependency is satisfied, Zeke examines the event’s WHEN conditions to determine whether all are satisfied. When all WHEN conditions are satisfied, Zeke updates the event status to WHENOK (i.e., dependencies are satisfied).

WHEN Conditions for Multiple Event Versions For events with multiple versions, you can define separate WHEN conditions for each version. Zeke assigns a version number to each dependency to indicate the associated event version. When it schedules an event version, Zeke searches for a dependency with the same version number. If one is found, Zeke uses that dependency for the event version. If one is not found, Zeke uses the default (version 0) dependency (if it exists). If a default dependency has not been defined for the event, Zeke automatically updates the event status to WHENOK (i.e., dependencies are satisfied).

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 no longer are in the schedule. If a

124

4 Events

job is dependent on another event that might have run as part of an earlier schedule, Zeke uses the XEOJ keyword 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 133 for details on including the XEOJ and XEOE keywords in a WHEN condition. If a job has multiple extended WHEN conditions, all conditions must be satisfied at the same time for the extended triggering to occur. At schedule load, Zeke searches the EMRs (using the index, if present) and examines the first matching jobname. If the last run of the event completed successfully since the last time the job with the extended dependency ran, the dependency is satisfied and marked by an asterisk (*) (just like an EOJ or EOE). Otherwise, Zeke considers the dependency as if it were a regular EOJ or EOE, and waits for the triggering job to complete successfully before satisfying the dependency. Zeke examines extended dependencies each time an event becomes TIMEOK (i.e., time-satisfied) and WHENOK (i.e., dependencies are satisfied). In extended dependency triggering, Zeke retains the start date and time, the end date and time, and the event status in the EMR for the last execution of each event (see “Event Activity Accounting” on page 172 for details). If the SQR has been requeued, or if Zeke is not tracking the execution, Zeke retains the information in the SQR for the last execution instead. If multiple SQRs for an event are executing at the same time, triggering occurs based on the execution with the latest end date and time. Note:

Zeke processes extended WHEN conditions in the same manner as if the generation option TrigJob is set to C, and TrigDt is set to A. This indicates that Zeke (or another Zeke that shares the database) must have dispatched the triggering event, 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. For example, a JCL error is an unsuccessful completion; an EOJ FORCED status indicates a successful completion. If the execution is unsuccessful, Zeke still retains the information for that execution in the EMR, but no triggering takes place. Extended WHEN conditions also can be manually satisfied using the ZALTER WHENOK operator command.

XEOE Example Event 2 has an extended dependency (XEOE) on Event 1. When it loads Event 2 into the schedule, Zeke checks to see whether 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 is satisfied, and Zeke dispatches Event 2 (assuming that any 125

ASG-Zeke Scheduling for z/OS User’s Guide

additional dependencies also are satisfied). However, if Event 1 ran two weeks ago, and Event 2 ran only two days ago, the XEOE is not satisfied, and Zeke treats the dependency as an EOE instead.

XEOJ Example The job event named Job B has an extended dependency (XEOJ) on Job A. When Zeke loads Job B into the schedule, Zeke checks to see whether 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 ready to run at 10:30:40 A.M. today (during the same minute), then the XEOJ dependency is satisfied, and Zeke dispatches Job B (assuming that any additional dependencies also are satisfied). However, if Job A did not end until 10:30:56 A.M. (also during the same minute), then the XEOJ is not satisfied, and Zeke treats the dependency as an EOJ instead.

WEAK Conditions You can use WEAK conditions in a dependency to create WHEN conditions that refer to other events that might not be in the schedule. WEAK conditions enable you to specify that Zeke must respect the condition if the event is in the schedule; otherwise, Zeke ignores the condition. For example, let’s suppose that this is a dependency for event 100: WHEN (WEOJ JOBABC)

If the job event JOBABC is in the schedule, Zeke does not dispatch event 100 until JOBABC reaches a successful end-of-job (EOJ) status. Zeke continuously checks the status of the job event JOBABC until it is dispatched. Zeke verifies whether a dependency has been met because a weak condition was satisfied (i.e., the event is not in the schedule), or because the dependency has been satisfied (i.e., the job ran). If the job event JOBABC is not in the schedule, Zeke processes the event according to the Zeke generation option RemovDq:

126

•

If the Zeke generation option RemovDq is set to Y, Zeke moves event 100 to the dispatch queue. While event 100 is in the dispatch queue, Zeke still continues to check the schedule for JOBABC. If JOBABC is added to the schedule (e.g., using the ZADD operator command), Zeke removes event 100 from the dispatch queue, and does not queued the event again until JOBABC reaches a successful EOJ. If JOBABC never is added to the schedule, Zeke dispatches event 100 (which executes when its resources are available).

•

If the RemovDq option is set to N, Zeke does not remove the dependent event from the dispatch queue (once it has been added).

4 Events

NOTDURING Conditions A NOTDURING condition specifies that Zeke cannot dispatch an event while the specified programs or jobs are running. The event remains eligible for dispatch until the NOTDURING conditions are satisfied; then, Zeke immediately dispatches the event. Zeke ensures that events with conflicting NOTDURING clauses are not dispatched at the same time. For example, if JOB1 has the status Pending, and JOB2 has a NOTDURING condition for JOB1, Zeke does not dispatch JOB2 (even though JOB1 is not actually running). You can disable JOB1 to enable Zeke to dispatch JOB2. Caution! Zeke does not support NOTDURING conditions while in SMF recording mode (as initiated by the ZKILL TRACK command). Note:

Resource control is a another effective way that you can ensure that conflicting events do not run at the same time. See “Defining a Logical Resource” on page 272 for more information.

Enabling NOTDURING Processing To enable Zeke to process NOTDURING conditions on a single Zeke system, you must set the Zeke generation option DispSel to Y (see “Setting Dispatching Options” on page 262). Additionally, the EojWake generation option determines whether events that are held due to a NOTDURING condition are reevaluated at each end-of-job (EOJ), or only at each one-minute, dispatching interval (see “Dispatching Events and Messages” on page 300). To use XCF to process NOTDURING conditions across a Zekeplex, Zeke does not consider the DispSel option value. Instead, you must specify the start-up option PLEXNOTD=YES in your ZEKExx options member (see the ASG-Zeke Scheduling for z/OS Installation Guide for details). This start-up option enables NOTDURING JOB processing for both JES2 and JES3 (otherwise, only JES2 supports NOTDURING dependencies). In addition, you also must specify the start-up option PLEXID=value in your OASISxx options member for the OASIS subsystem for this Zeke system (see the ASG-OASIS for z/OS Reference Guide for details).

Specifying NOTDURING WHEN Conditions Its NOTDURING conditions must be satisfied before an event can be dispatched. Zeke does not use NOTDURING conditions to determine whether an event is WHENOK. An event could be WHENOK even though a program or job named in an NOTDURING clause is executing; however, Zeke does not dispatch the event until the NOTDURING program or job is completed.

127

ASG-Zeke Scheduling for z/OS User’s Guide

In a WHEN condition, you must list NOTDURING conditions last (after all other WHEN conditions). You relate multiple NOTDURING conditions using the AND keyword.

Specifying Generic Names and Wildcards To specify generic NOTDURING program and jobnames, you can precede the job or program name with an asterisk (*) followed by up to seven characters. For example, *ABC would match names beginning with ABC. To use * as a wildcard character, you can replace any character with *. For example, PAY**UPD would select 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. Because * could indicate a generic name or a wildcard character, Zeke assumes that an asterisk in the first position indicates a generic name when fewer than eight characters are entered. For example, to select all jobs with C in the seventh position, you would enter ******C*, instead of ******C. Because all eight characters are specified, Zeke assumes the first * is a wildcard character. Note:

An event cannot have a generic NOTDURING with a pattern that matches the jobname (e.g., a jobname JOBBC3PX and WHEN (NOTDURING JOB *BC3P).

Examples These are examples of NOTDURING WHEN conditions: WHEN (EOJ JOB1 NOTDURING JOB PRODCICS)

The event requires an EOJ on JOB1, but cannot run while job PRODCICS is running. WHEN (NOTDURING PGM DFHSIP)

The event cannot run while program DFHSIP is executing. Note:

Zeke honors the NOTDURING PGM condition regardless of the initiator where the job is running. WHEN (NOTDURING JOB *PAY NOTDURING PGM PAY**01A)

The event cannot run with any job that has a jobname 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.

128

4 Events

Cross-platform Dependencies Cross-platform scheduling dependencies are prerequisites that are satisfied by a remote scheduler—either a remote Zeke system or another remote scheduling system (e.g., 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 system. 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 completed (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 jobname can be up to 30 characters long. The AT keyword does not support the use of the VER keyword. If you specify a version number, Zeke ignores it.

Zeke-to-Zeke Cross-schedule Dependencies When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (i.e., a Zeke system is the object of the AT netregid of another scheduler’s trigger), a nonZeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of the Zeke generation option TrigJob. Both the local and remote Zeke systems ignore the TrigJob generation option 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 the value of TrigDt generation option 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 value and simply looks for a match on the jobname. You also can use AT to specify a dependency using the ZALTER operator command. For example: •

To add a remote dependency with an AND relationship: ZALTER JOB 1 WHENAND (EOJ JOBC AT SYSB)

129

ASG-Zeke Scheduling for z/OS User’s Guide

•

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)

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on the ZALTER operator command.

Specifying Generic Names To specify generic event names for the EOE, AEOE, XEOE, or EOG conditions, you precede the event name with an asterisk (*), and the characters that you want to match. Generic names are only valid for event names; you cannot use them for jobnames. For example, *ABC matches all jobs with event names that begin with ABC. To use an asterisk as a wildcard character, you 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, you must specify the name in single quotes. For example, (EOE '**********'). You can use an asterisk (*) to indicate both a generic name and a wildcard character, so it is important to understand how Zeke interprets an asterisk. The maximum number of characters that you can specify in a generic name is 12. If you specify all 12 characters (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 you specify fewer than 12 characters, Zeke assumes that an asterisk in the first position indicates a generic name. For example, *KKKKKKKKKK (one less K than the previous example) selects all events that begin with ten K’s. If you want to indicate a generic name, but need to specify 12 characters, you can place the asterisk in the last position. For example, KKKKKKKKKKK* selects all events beginning with 11 K’s.

Specifying Multiple WHEN Conditions You can define an event to have more than one dependency. This example shows two WHEN conditions joined with the keyword OR (which indicates that the event is satisfied when either clause is satisfied): WHEN (EOJ ABC OR EOJ XYZ)

130

4 Events

The keyword AND indicates that 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, you can enclose multiple WHEN conditions 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 is completed, and either Program A or Program B is completed: 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 have completed. Because the keyword AND joins the two clauses, the event is only satisfied if Job A has also completed.

Specifying Started Tasks These WHEN conditions also can refer to started tasks and programs within started tasks (if the you make the appropriate specifications in the SMFPRMxx member of SYS1.PARMLIB): BOJ EOJ BOP EOP AEOJ EOS AEOP WHEN

See the ASG-Zeke Scheduling for z/OS Installation Guide for more information on SMF requirements, or ask your system programmer whether your installation supports WHEN conditions that reference started tasks.

Using Zeke Variables as WHEN Conditions To use a Zeke variable as a dependency, you specify a variable and the relational operator to compare to a specified value. Zeke performs variable substitution in WHEN conditions when the SQR is created (using the SCHEDULE function or the ZADD operator command).

131

ASG-Zeke Scheduling for z/OS User’s Guide

For example, Zeke does not dispatch this event until the value of the variable named $VARNAM1 is YES: WHEN (VAR $VARNAM1 EQ YES)

When the variable is set to YES, the dependency is satisfied. The dependency also is satisfied if the variable is already set to YES when Zeke loads the schedule. In WHEN conditions, you can use OASIS variables only for substitution in an operand (e.g., the jobname in a BOJ or EOJ condition, or the expression following EQ in a VAR condition). OASIS variable substitution is performed using qualifiers from the created SQR. For example: WHEN EOJ PRDAA$(CYCLE)

Let’s suppose that the value of the OASIS variable CYCLE is 09. When this value is substituted into the dependency, the jobname becomes PRDAA09. Zeke does not check WHEN conditions that contain variables for syntax when they are defined. Syntax checking occurs only after the variable substitution is performed. This is important in certain situations. For example, if the operand of an EOJ dependency that contains a variable is longer than eight characters before substitution occurs, this normally would be invalid because of length limitations. Because Zeke does not perform syntax checking until after the substitution, the length is valid as long as the value is no longer than eight characters after substitution occurs. These are the valid relational operators that you can use in a Zeke variable: Relational Operator

Description

EQ

EQual to

GE

Greater than or Equal to

GT

Greater Than

LE

Less than or Equal to

LT

Less Than

NE

Not Equal to

You can use either numeric or character literals; however, numeric values are compared only to numeric variables, and character values are compared only to character variables. You must express numeric literals explicitly (no delimiters), and enclose character literals in special character delimiters (if the character string contains other than alpha/numeric characters). 132

4 Events

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! You cannot use these characters as delimiters: —

dollar sign ($)

—

question mark (?)

—

number/pound sign (#)

—

at sign (@)

—

asterisk (*)

Combining Event Actions and Zeke Variables You can specify combinations of job, program, and event actions, and Zeke variables as WHEN conditions for any type of event. For example: WHEN (EOJ JOBNAME1 AND VAR $VARNAME EQ YES)

WHEN Condition Keywords These are the available keywords that you can use with the WHEN parameter to define WHEN conditions: Keyword

Description

AT netregid

(Target) Specify the Netregid (up to eight characters long) for the remote system where the cross-platform prerequisite must occur. For example: WHEN (EOJ JOBA AND EOJ JOBB AT SYSB)

Note: When you use the AT keyword, you can specify a dependency on a job with a jobname up to 30 characters long. Using the AT keyword does not support use of the VER keyword. If a version number is specified, Zeke ignores it. See “Cross-platform Dependencies” on page 129 for more information.

133

ASG-Zeke Scheduling for z/OS User’s Guide

Keyword

Description

DSN

(Dataset name) Dataset triggering is based on the close of a z/OS output dataset. Zeke dispatches the event when a sequential, nonVSAM dataset that matches the DSN dependency is closed. For example: WHEN (DSN DATASET.NAME) WHEN (DSN DATASET.NAME AND EOJ PAYROLL)

Before using DSN for nonVSAM datasets, ensure that the Zeke generation option IEFU83 is set to Y, and that your system is creating Type 15 SMF records, or that Connect:Direct (formerly Network Data Mover, or NDM) is installed and active with the appropriate RUN TASK statement. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information on using on using Connect:Direct with Zeke. A generation data group (GDG) dataset name with the generation number 'G0000V00' is satisfied when any dataset in its GDG index is created and closed. For example, this condition is satisfied when any generation in the GDG 'A.B' is created and closed: WHEN (DSN A.B.G0000V00)

Because the IEFBR14 program does not close a dataset, it cannot trigger a DSN dependency. Note: The DsclTrig generation option (see “Dispatching Options” on page 297) controls the dataset dispositions that qualify as triggers for DSN WHEN conditions. AEOJ

(Abnormal end of job) Specify the jobname. For example: WHEN (AEOJ JOB1)

AEOE

(Abnormal end of event) Specify an event of any type (including work centers). For example: WHEN (AEOE JOB1)

AEOP

(Abnormal end of program) Specify the program name. For example: WHEN (AEOP PAYROLL)

AEOS

(Abnormal end of step) Specify the stepname. 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)

134

4 Events

Keyword

Description

NOTDURIN G

(Not during) Specify the program name or jobname. This prevents jobs/programs from running at the same time. If you use this keyword, you must specify it as the last condition in the WHEN condition statement. For example: WHEN (NOTDURING JOB JOBNAME) WHEN (EOJ JOB1 NOTDURING JOB PRODCICS) WHEN (NOTDURING JOB *PAY NOTAF PGM PAY**01A)

See “NOTDURING Conditions” on page 127 for a detailed discussion of NOTDURING WHEN conditions. BOJ

(Beginning of job) Specify the jobname. For example: WHEN (BOJ JOB3)

BOP

(Beginning of program) Specify the program name. For example: WHEN (BOP PGMNME)

EOG

(Successful end of group) Specify the name of the group of events. For example: WHEN (EOG GRPPAY)

You can use EOG to trigger an event by the completion of multiple events (including work centers). This dependency is satisfied when all events in the schedule that match the specified event name are in Done or Disabled status, and at least one of the matching events is in Done status. For example, let’s suppose a master file update is performed after all daily transactions are received. If the number of daily transaction jobs varies, you cannot use EOE, because some of the EOE conditions would not be satisfied if their corresponding jobs were not run on a particular day. With EOG, before dispatching the event, Zeke ensures that all scheduled events matching the specified event name are in Done or Disabled status. If no transaction jobs are complete, the master file update does not run. If the generation option RemovDq is set to Y, the EOG dependency can be unsatisfied up to the time of dispatch. If RemovDq is set to N, the EOG dependency can be unsatisfied up to the time the event is added to the dispatch queue. For example, let’s suppose that an event with an EOG dependency is scheduled at 18:00. At 10:00, two events that match the EOG are in the schedule; and 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.

135

ASG-Zeke Scheduling for z/OS User’s Guide

Keyword

Description 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) Specify the name of an event of any type. Do not specify the event number. This dependency is satisfied when an event in the schedule that matches the specified event name has reached a EOE or Disabled status. For example: WHEN (EOE JOB1) WHEN (EOE 'JOB TWO') WHEN (EOE PAYROLL) WHEN (EOE 'JOB PAYROLL')

EOP

(Successful end of program) Specify the program name. For example: WHEN (EOP PROGRAM.JOB) WHEN (EOP PGMNAME1 OR EOP PGMNAME2)

EOS

(Successful end of step) Specify the stepname (i.e., the job step that calls the cataloged procedure) or the procstep name. For example, when executing a procedure: WHEN (EOS STEPNAME.PROCSTEP.JOBNAME)

For example, when not executing a procedure: WHEN (EOS STEPNAME..JOBNAME)

EOJ

(Successful end of job) Specify the jobname. For example: WHEN (EOJ JOBNAME1) WHEN (EOJ JOBNAME1 AND EOJ JOBNAME2 AND BOJ JOBNAME3) WHEN (EOJ JOB$(CYCLE))

VAR

(Variable) Specify a variable value. Zeke dispatches the event only when the variable is equal to the specified value. For example: WHEN (VAR $ABC EQ YES)

See “Using Zeke Variables as WHEN Conditions” on page 131 for a detailed explanation on using variables in WHEN conditions.

136

4 Events

Keyword

Description

VER

(Version) Specify the event version. Zeke dispatches the event only at the end of the specified event version. If you omit this keyword, the default is the same SQR version. For example, if JOBB version 3 is waiting on EOJ for JOBA, but no version is specified, JOBB waits on EOJ for JOBA as a version 3 SQR. For example: WHEN (EOE JOB4 VER 88) WHEN (EOJ JOBC AND EOJ JOBC VER 2)

You can use the VER condition for any EOE, EOJ, EOP, EOS, or EOG condition (including their WEAK counterparts); however, it affects only the SQR that generates the trigger (i.e., not the job, program, or step). You can specify an asterisk (*) in the VER condition to trigger from any SQR version. For example, this event is triggered from the next EOE for EVTB: WHEN (EOE EVTB VER *)

Note: Zeke does not support use of the VER keyword for these WHEN conditions— DSN, VAR, ?VAR, XEOJ, and XEOE. WEOG

(Weak end of group) Specify the group name. For example: WHEN (WEOG GRPA)

You can use WEOG to trigger an event by the completion of an event group (which could include work centers). This dependency is satisfied when all events in the schedule that match the specified group name are in EOE or Disabled status, and at least of the matching events must be in EOE status. A WEOG condition can be satisfied even if there are no matching events in the schedule. See “WEAK Conditions” on page 126 for more information. WEOE

(Weak end of event) Specify the event name; do not specify the event number. For example: WHEN (WEOE WC_ABC)

You can use WEOE to trigger an event by the completion of another event (including work centers). A WEOE condition can be satisfied even if there are no matching events in the schedule. See “WEAK Conditions” on page 126 for more information.

137

ASG-Zeke Scheduling for z/OS User’s Guide

Keyword

Description

WEOJ

(Weak end of job) Specify the jobname. For example: WHEN (WEOJ JOBNAME)

A WEOJ condition can be satisfied even if there are no matching jobs in the schedule. See “WEAK Conditions” on page 126 for more information. XEOE

(Extended end of event) Specify the event name; do not specify the event number. An XEOE is satisfied when an event (including work centers) in the schedule that matches the specified event name has reached an EOE or Disabled status since the last time this event ran. For example, if this dependency is defined for JOBC, then XEOE is satisfied if job ABC has run to EOE or Disabled status since the last time JOBC ran: WHEN (XEOE ABC)

Note: Zeke does not support the use of the VER keyword with the XEOE keyword. XEOJ

(Extended end of event) Specify the jobname. An XEOJ is satisfied when a job event in the schedule that matches the specified jobname has reached an EOJ or Disabled status since the last time this job event ran. For example, if this dependency is defined for JOBC, XEOJ is satisfied if JOBA has run since the last time JOBC ran: WHEN (XEOJ JOBA)

Note: Zeke does not support use of the VER keyword with XEOJ. If you specify a version number, Zeke ignores it and the job is triggered by any version of the specified job.

138

4 Events

Defining a WHEN Condition This procedure explains how to define a WHEN condition for an event in the EMR.

To define and maintain a WHEN condition 1

Access the Event Master Definition screen as instructed in the procedure, “Accessing the Event Definition” on page 58. ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 6 Desc: TEST JOB Type: JOB Desc2: Event Name: ZEKE60TST6 App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 0 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 00:30 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: TSKKGUT1

Class:

JCL--> PDS: Member: Zeke JCL (Y=Yes): Y Bim: Mbr: JESQ (Y, D=dynamic):

2

Pri: 0 CMS:

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: ZEKE60TST6 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 ZEKE60TST5 AND EOE ZEKE60TST4 AND EOE ZEKE60TST1 AND EOE ZEKE60TST2 000002 AND EOE ZEKE60TST3) ****** **************************** Bottom of Data *************************

3

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.

139

ASG-Zeke Scheduling for z/OS User’s Guide

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 133 for a complete list of valid keywords. 4

Press Enter. The event version is updated with the WHEN condition.

5

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 issue to COPY command to use the same dependency for multiple versions of an event. 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 event, as instructed in “Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

Event===> Primary Commands: ACCT 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: 32 Desc: TEST JOB Type: JOB Desc2: Event Name: TESTADDNM App: Grp: Usrid: DRL: 2 System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 4 Latestart: 13:00 Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: 00:30 Freqcalc: S Trig: A Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup: SchEnv: ASGSCHEDUENVIRON Job: NOMTEST JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

140

Class:

Pri: 0 CMS: Ftype: JESQ (Y, D=dynamic):

4 Events

2

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

B - Browse

D - Delete

Type: JOB

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 access the Event Master Record Function screen to view the remainder of the statement. To do so, use the Browse line command as described in the next step. 3

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Add a dependency for a new version number

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 139 for further instructions.

Browse the WHEN conditions for a particular version of the event

Enter B to the left of the dependency that you want to browse. Press Enter. The Event Master Record Function screen is displayed in Browse mode.

141

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Delete the WHEN conditions for a particular version of the event

Enter D to the left of the dependency that you want to delete. The Event Master Record Function screen is displayed and you are asked to confirm the deletion. Enter 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 that you want to edit. The Event Master Record Function screen is displayed in Edit mode. 2 Re-enter DELETE on the Command line, and press Enter. 3 Re-enter DELETE on the Command line, and press Enter to confirm, or press F3 to cancel.

Edit the WHEN conditions Enter E to the left of the dependency that you want to edit. for a particular version of The Event Master Record Function screen is displayed in Edit the event mode. When finished editing the dependency, press Enter to save your changes.

142

4 Events

Condition Codes You use condition code validation for these purposes: •

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

Zeke does not consider a condition code to be an abend, unless the operating system considers it an abend (or unless you manually define it as an abend). You can define the condition code 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. Note:

The MaxCC generation option enables you to specify a default maximum job condition code for job events that do not have condition codes specified. Zeke checks any specified step names first; then, after the job is completed, Zeke checks the maximum condition code for the job. 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.

143

ASG-Zeke Scheduling for z/OS User’s Guide

Defining Condition Codes for an Event This section explains how to add, update or delete condition codes for an event.

To define condition codes for an event 1

Access the Event Master Definition screen for the event, as instructed in “Accessing the Event Definition” on page 58.

2

From the Event Master Definition, enter CCODE on the Command line, and press Enter. 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

Operators: Actions:

3

System: ZEQA

EQ NE LE LT GE GT F = Fail, C = Cancel,

Event Name: ZEKE60CC

RA =Range O = Ok

Stepname

Procstep

Operator

- Range Low High

Action

EOJ CC STEP01 STEP02 ********

******** ******** ********

GT NE GT

8 16 0

F O C

Perform the steps in the Action column (depending upon the desired result): Desired Result

Action

Add a new or edit an existing condition code

Enable Edit mode (if necessary).

Delete a single condition code

Enter D to the left of the condition code that you want to delete, and press Enter.

Insert a new line

Enter I to the left of the line after which you want to insert a new line, and press Enter.

Go to step 4.

Note: You cannot insert lines before the line EOJ CC. Repeat this line

144

Enter R to the left of the line that you want to repeat, and press Enter.

4 Events

4

Complete these fields (as applicable): Field

Description

Stepname

Specify the JCL step name. If the step is in a procedure, specify the step name that executes the procedure. If the stepname is nulls or blanks, specify the procstep name. You can use an asterisk (*) as a wildcard character to identify a generic step name. For example, you would enter ***STEP5 to select stepnames 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 146 for detailed examples.

Procstep

Specify 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 procstep name. For example, you would enter ***PROC5 to select a procstep name with PROC5 in positions 4 through 8.

Operator

Indicate when to perform a specified action. These are the valid codes: EQ

When the condition codes are EQual.

LE

When the condition code is Less than or Equal to the specified condition code.

LT

When the condition code is Less Than the specified condition code.

GT

When the condition code is Greater Than the specified condition code.

GE

When the condition code is Greater than or Equal to the specified condition code.

NE

When the condition codes are Not Equal.

RA

When the condition code is in the specified RAnge.

Low

If Operator is RA, specify the lowest code in the range to compare.

High

If Operator is RA, specify the highest code in the range to compare.

Action

Indicates the action to take when the condition code meets the specified criteria. These are the valid codes:

145

ASG-Zeke Scheduling for z/OS User’s Guide

Field

5

6

Description F

Flag the job as Failed during end-of-job processing.

C

Cancel the job at this step, and flag it as Failed, during end-of-job processing.

O

Continue processing.

On the EOJ CC line, specify condition codes to compare at the end of the job: a

Complete the Operator, Low, and High fields just as you would for step-level checking.

b

In the Action field, enter F. This is the only valid action for the job level. Checking is done at end-of-job for the maximum condition code from any step in this job. This checking is done independently of any specified step-level checking.

Press Enter to save the changes.

Sample Condition Code Entries These sample screens illustrate a few different scenarios to assist in defining condition codes. In this example, Stepname Procstep ******** ******** 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: 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

Operators: Actions: Stepname EOJ CC STEP3 ********

146

System: ZEQA

EQ NE LE LT GE GT F = Fail, C = Cancel, Procstep

******** ********

Operator

EQ GT

Event Name: ZEKE60CC

RA =Range O = Ok - Range Low High 4 0

Action

O C

4 Events

In this example, EOJ CC takes priority because it is encountered first in the list. 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: 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

Operators: Actions:

System: ZEQA

EQ NE LE LT GE GT F = Fail, C = Cancel,

Stepname

Procstep

EOJ CC STEP3 STEP5

******** ********

Operator GT EQ LE

Event Name: ZEKE60CC

RA =Range O = Ok - Range Low High 0 4 8

Action F O O

If you want to use the previous example as a model, but you want the conditions for STEP3 and STEP5 to be checked, define the condition codes as shown in this example: 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

Operators: Actions: Stepname EOJ CC STEP3 STEP5 ********

System: ZEQA

EQ NE LE LT GE GT F = Fail, C = Cancel, Procstep

******** ******** ********

Operator

EQ LE GT

Event Name: ZEKE60CC

RA =Range O = Ok - Range Low High 4 8 0

Action

O O F

147

ASG-Zeke Scheduling for z/OS User’s Guide

This is the same scenario, but with a procstep defined: 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

Operators: Actions: Stepname

EQ NE LE LT GE GT F = Fail, C = Cancel, Procstep

EOJ CC STEP3 STEP5 ********

System: ZEQA

Operator

PSTEP3 ******** ********

Event Name: ZEKE60CC

RA =Range O = Ok - Range Low High

EQ LE GT

Action

4 8 0

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.) If the JCL step name is nulls, and the procedure MYPROC contains the step MYSTEP, define the condition codes like this: 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

Operators: Actions:

148

System: ZEQA

EQ NE LE LT GE GT F = Fail, C = Cancel,

Stepname

Procstep

Operator

EOJ CC MYSTEP ********

********

EQ GT

Event Name: ZEKE60CC

RA =Range O = Ok - Range Low High 4 0

Action

O F

4 Events

Work Centers Work center events are tasks that require manual operator intervention. For example: •

User input (e.g., dates or check numbers)

•

User approval

•

Completion of a manual task (e.g., data entry)

Work centers enable an operator to interact with the schedule directly. 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 are useful for these types of functions: •

Scheduling manual tasks that need to be complete by a certain time. Zeke lets you know, for example, 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 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.

While work centers can be predecessors for other events, they do not have their own WHEN condition. Instead, work centers can have SET clauses, as explained in this section. Work centers do not use resources. Note:

Zeke Web Services enable you to view and manage Zeke work center events from a Web browser. See “Managing Work Centers from the Web” on page 409 for more information.

149

ASG-Zeke Scheduling for z/OS User’s Guide

Using 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. Let’s 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.

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 these keywords in the SET clause statement: Keywords Zeke

OASIS

Description

VAR

XVAR

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 specify the current date. 150

4 Events

Keywords Zeke

OASIS

Description

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. (See the 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 specify the value for $TEST03 and Zeke automatically sets the OASIS variable TEST02 to YES.

Defining a Work Center Work centers are typically set up by scheduling personnel, and completed by data center operators.

To define or maintain a work center 1

Access the Event Master Definition screen, as instructed in “Accessing the Event Definition” on page 58: ASG-Zeke Command ===>

Event Master Definition

EDIT

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: 0 Latestart: Early: Sched: 00:00 Mustend: Notafter: Lateend: 00:00 Dprty: 50 Operok: N Times: 1 Freq: Freqcalc: S Trig: A SchEnv: ASGSCHEDUENVIRON WorkCtr WorkCtr WorkCtr WorkCtr WorkCtr WorkCtr

Line Line Line Line Line Line

1: 2: 3: 4: 5: 6:

OBTAIN MGMT OK FOR CHECK RUN

151

ASG-Zeke Scheduling for z/OS User’s Guide

2

Complete these fields (as applicable) to define a work center: Field

Description

Template

Indicate whether you are defining a message event template. The valid values are Y and N. See “Defining an Event Template” on page 63 for more information.

Desc/Desc2

Specify a description of the work center event. This description is displayed on summary screens and printed on reports.

Event Name

Specify the name of the work center event. The event name is displayed on Zeke online screens and reports, and can be used as selection criteria. The event name also can be specified in end-of-event (EOE), abnormal-end-of-event (AEOE) and end-of-group (EOG and AEOG) WHEN conditions.

Usrid

Specify the user ID (up to eight characters long) for the user authorized to access the work center event. Since Zeke supports mixed-case user IDs, be sure to specify the desired user ID in the correct case (upper, lower, or mixed). Note: This user ID is for Zeke internal security only.

System

Specify the system or pool that owns the work center event (which can be associated with only one system). Note: This is the system where the event is dispatched, and not necessarily the system where the EMR was defined.

152

4 Events

Field

Description

Verload

Specify the number of versions of this event that Zeke loads during the schedule build. The valid values range from 0 to 32767. The default value is 0. For example, if Verload is set to 3, Zeke adds EMRs to the schedule for three versions of the event during schedule build (i.e., versions 1, 2, and 3). If Verload is set to 0, then only one version of the event (version zero) can be in the schedule at a time. If Verload is set to 1, Zeke loads only one version during the schedule build, but you can use the ZADD operator command to add multiple versions (up to 32,767) to the schedule after the schedule load. Note: ASG recommends that you run no more than 1,000 versions of a single event. See “Creating Multiple Versions of an Event” on page 76 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 you 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.

WorkCtr Line

Specify a description of the work center activity. This information serves as instructions to the work center operator. You can enter up to six lines of comments. If more lines are needed, you can use the Documentation facility to add more notes.

153

ASG-Zeke Scheduling for z/OS User’s Guide

3

Complete these fields (as applicable), which enable you to group events for selection for scheduling or reporting: Field

Description

App

Specify the code (up to eight characters long) to identify the application ID associated with the work center event.

Grp

Specify the code (up to three characters long) to identify the group ID associated with the work center event. This field is a subset of the application ID.

4

Press Enter to save the changes. The screen is redisplayed in Update mode. If you are adding the event, Zeke assigns a unique event number.

5

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: 000246 Type: WORK Job: Evt Name: CASH0199 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. 6

Specify the SET clause (enclosed in parentheses). See "SET Clauses" on page 150 for more information. See “IF Clauses On SET Statements” on page 366 for information on defining the prerequisites that must occur before Zeke dispatches the event. Press Enter to save the changes. The screen is redisplayed in Update mode.

7

154

Perform the procedure “Defining an OCCURS Clause” on page 121 to specify when Zeke schedules the event.

4 Events

8

Be sure the operator has Zeke access. You can set up a user’s Zeke operator ID, so that when they log on to Zeke, the Work Center Selection Criteria screen is automatically displayed. See “Defining Operator Records” on page 389 for more information. a

Enter A to create a class ID with auto-entry access to the Work Center function.

b

Associate the user’s operator ID with the class ID and the user ID of the work center event.

Be sure all operators are aware of their user IDs for their work center events and how to log on to Zeke. The next time the SCHEDULE function runs, the work center event is scheduled (assuming the OCCURS clause is true).

Completing Work Centers Before an operator attempts to complete a work center, be sure that the operator has access to the Work Center function.

To complete a work center 1

Depending on how your operator ID is set up, the Work Center Selection Criteria screen might automatically display when you log on to Zeke. Go to step 3.

2

If the Work Center Selection Criteria Screen does not automatically display when you log on to Zeke, then from the Zeke Primary Menu, enter option 5. The Work Center Selection Criteria screen displays, and enables you to display a directory of work center events: ASG-Zeke Option ===> 1 2 3

Work Center Selection Criteria

Not Done All Done

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 => | | | '------------------------------------'

155

ASG-Zeke Scheduling for z/OS User’s Guide

3

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).

4

Optional. Complete these fields (as applicable) to select the work centers that you want to display: Note:

You can use wildcards and placeholders (see “Specifying Generic Selection Criteria” on page 57). You also can leave a field blank, or enter an asterisk (*) to omit the field from the selection criteria. Field

Description

UserID

Specify selection criteria to specify the group of user IDs to select. Zeke supports mixed-case user IDs. Be sure to specify the search criteria in the correct case (upper, lower, or mixed).

5

App

Application ID associated with the work center.

Group

Group name associated with the work center.

System

Specify the system or pool that owns the work center (which can be associated with only one system).

Press Enter. The Directory of Work Center Events is displayed: ASG-Zeke Command ===> Line Commands:

Directory of Work Center Events

A disAble R Refresh

B Browse

C Complete

Today :04/19/2012 Time Event Work Date Versn Sched Event Name 000202 06/17/2012 00000 00:00 EANTST 000205 06/17/2012 00000 00:00 EANTST05 000833 06/17/2012 00000 00:00 TEST OVAR ***************************** Bottom of data

6

N eNable

Row 1 to 2 of 2 Scroll ===> PAGE O dOcumentation

:12:46:55 (36:46:55) Appl Grp System Set Status TSO45 Y NOT DONE TSO45 Y NOT DONE APPL GRX TSO45 Y NOT DONE ******************************

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Browse the event

Enter B to the left of the Event field. Use this command before completing the work center if SET=N.

156

4 Events

Desired Result

Action

Complete the event

Enter C to the left of the Event field. If SET=N, Zeke updates the event status to Done. If SET=Y, the Work Center Function screen is displayed, and prompts you to verify the variable value or enter a new value. Go to step 8.

Disable the event

Enter A to the left of the Event field, if the event is not considered part of the schedule. Zeke updates the event status to Disabled.

Enable the disabled event

Enter N to the left of the Event field. Zeke updates the event status to Enabled.

Refresh the event

Enter R to the left of the Event field. Zeke updates the status of a completed event to Not Done.

Display the Work Center Doc. Segments Screen

Enter O to the left of the Event field. See “Accessing Event Documentation” on page 165.

The Work Center Control Function screen is displayed in Browse mode: ASG-Zeke Command ===>

Work Center Control Function

Primary Commands: Event: 000229 Appl: PAY

COMPLETE

DISABLE

DOCUMENT

Event Name: PAYCHECK Group: PAY UserID: KAC

ENABLE

REFRESH

System: A Set ver: 00000

Schd: 00:00 Sdate: 01/30/2012 Rdate: 01/30/2012 Today:01/30/2012 Late: Times: 0001 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:

You can press Enter to display additional SET statements when there are multiple variables. This procedure is complete.

157

ASG-Zeke Scheduling for z/OS User’s Guide

7

Press Enter. 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

Group: PAY System: A

UserID: KAC Set ver: 00000

Schd: 00:00 Sdate: 01/30/2012 Rdate: 01/30/2012 Today: 01/30/2012 Late: Times: 0001 Freq: NOT Done Time: 15:59:27 (39:59:27) 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: Data-Name: $PAYCHECK Curr Value: 1001 New Value: 'NNNN' Force upper: Y

8

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 long). 9

In the Force Upper field, specify whether the Current Value includes alpha characters. These are the valid values: Code

Meaning

Y

Indicates to force the Current Value string to uppercase.

N

Indicates to keeps the case of the Current Value exactly as entered. Use this code if you need to allow mixed-case values for variable substitution.

Note:

If the Current Value is numeric only, Zeke ignores the Force Upper option.

158

4 Events

10

Press Enter. A verification screen is displayed after all the variables are set: ASG-Zeke Command ===>

Work Center Control Function

Primary Commands: COMPLETE

Row 1 to 2 of 2 Scroll ===> PAGE

CANCEL

Event: 000229 Ver: 00000 Sdate: 01/30/2012 Rdate: 01/30/2012 Today :01/30/2012 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 on the desired result): Desired Result

Action

Confirm that the values are correct, and complete the work center.

Enter COMPLETE on the Command line, and press Enter. The Work Center Directory is displayed. Zeke updates the event status 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 event status is unchanged.

Auto Replies Zeke enables you to respond automatically to outstanding replies (WTORs) from your Zeke-controlled jobs that have static or predictable responses. Replies also can 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.

159

ASG-Zeke Scheduling for z/OS User’s Guide

Related Generation Options Three generation options affect automatic replies for your systems: Generation Option

Description

Aur

Enables or disables automatic responses to messages and replies.

AurIntv

Specifies the interval to check for automatic responses.

AurMsg

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 “Auto Reply Options” on page 308, 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, issue the ZDISABLE operator command.

Defining Auto Replies This procedure explains how to define or maintain auto replies for a job event.

To define or maintain automatic replies 1

2

160

Verify the Aur, Aurintv, and Aurmsg generation option settings: •

Determine the how automatic replies are set up for your Zeke systems globally. See “Auto Reply Options” on page 308.

•

If there are exceptions to how automatic replies are set up globally, use ZDISPLAY, ZENABLE, and ZDISABLE operator commands, as applicable. See “Managing Auto Replies” on page 163.

Access the Event Master Definition screen, as instructed in “Accessing the Event Definition” on page 58.

4 Events

3

Enter AUTORPLY on the Command line, and press Enter. •

If auto replies do not exist for the event, the Auto Reply Function screen is displayed. Go to step 5.

•

If auto replies exist for the event, the Auto Reply Summary screen is displayed.

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 ******************************

4

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Add an auto reply element Enter ADD on the Command line, and press Enter. Delete all auto reply elements

1 Enter DELALL on the Command line, and press Enter.

Browse the auto reply detail

Enter B to the left of the NUM field, and press Enter.

2 Press Enter again to confirm.

Edit the auto reply element Enter E to the left of the NUM field, and press Enter. Delete the specific auto reply element

Enter D to the left of the NUM field, and press Enter. Press Enter again to confirm.

161

ASG-Zeke Scheduling for z/OS User’s Guide

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: ZEKE60CC

Desc: EKGSTRT1 Desc2: Automatic Reply Element Number: 001 Msg text: ENTER GO TO PROCESS Reply: GO Effective as of: 01/01/2012 Effective until: 06/01/2012 Job step name: STEP1 Program (Exec):



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 Long 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

This 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 alphabetically, for convenience. 2

222

In the nnn field, perform these steps: a

To remove a field from the display, specify the line command 0 next to the field, and press Enter. This moves the field below the line to the not used section.

b

To include a field in the display, enter any value (other than 0) next to the field and, press Enter. This to moves the field above the line to the used section. The value determines the field’s placement on the screen.

5 Creating and Monitoring the Schedule

c

To reorder fields, specify a new value next to the desired fields, and press Enter.

Order values begin at 10, and increment by 10. This enables 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

Enter END at the Command line to save the changes and return to the previous screen. In this example, the Event Number appears in Field 1, the Schedule Date in Field 2, the Sched Time in Field 3, and the Status/Reason Code in Field 4. The remaining fields are marked for removal because their “nnn” value has been set to 0. When you press Enter, those fields are moved below the separator line to indicate that they are not displayed: 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 ---

0 0 0 0 0 0 0 0 0 0 0 0

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

Note:

On the Schedule View screen, the DOC, JCL, AUTO REPLY, RESOURCE, CODE, and WHEN fields always appear as the last six fields, and cannot be moved.

223

ASG-Zeke Scheduling for z/OS User’s Guide

Changing the Date Display Format You can specify the format for selected dates displayed in Schedule View. Entries that you make 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 option C.4. The Date Selection screen is displayed. The selected format is marked by an asterisk (*) in the Current Format column: ASG-Zeke OPTION ===>

OPT 1 2 3 4

2

Current Format *

Date Selection

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, specify the corresponding option number (OPT) to select the date format that you want to use in Schedule View, and press Enter.

Accessing Other Zeke Online Functions You can quickly access other functions of the Zeke online facility from Schedule View. The Zeke Primary Menu options are still valid; however, Schedule View offers an alternate way to access these other areas of the online facility.

To access other Zeke online functions from Schedule View 1

224

From the Zeke Primary Menu, enter option 2.1. The Schedule View screen is displayed.

5 Creating and Monitoring the Schedule

2

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Access EMRs

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 an event, and press Enter. The Event Master Definition screen is displayed in Browse mode. See “Event Master Record (EMRs)” on page 52 for more information.

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 an event, and press Enter to display Note Text information only for the selected event. See “Event Documentation” on page 164 for more information.

Access work centers

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 149 for more information.

Access PathFinder

Enter one of these line commands in the Line Cmd field: PATH

Displays all predecessors and successors for the event.

PRED

Displays only predecessors.

SUCC

Displays only successors.

See “PathFinder” on page 241 for more information.

225

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Access Zebb

Enter one of these line commands in the Line Cmd field to access the appropriate Zebb function: ZEBB

Display the Job Functions Menu.

DSN

Display the Step/DD Level Information screen.

LDSN

Display the List DSN Detail Information screen.

RSTRT

Display the Job Restart Management screen.

Note: This function requires Zebb to be active on this Zeke system. Display SQR information on one screen

Enter ZOOM in the Line Cmd field for the selected event, and press Enter. See “Accessing an Expanded SQR (Using ZOOM)” on page 216 for more information.

Edit or override JCL for a job event

Enter ZOOM in the Line Cmd field for the selected event, and press Enter. See “Overriding JCL” on page 226 for more information.

3

Press F3 to return to the main Schedule View screen.

Managing JCL For job events, you can access JCL from Schedule View for one-time overrides, as well as validate the JCL that you have created or edited.

Overriding JCL For job events, Schedule View enables you to retrieve the actual JCL from the JCL source, and insert it in the SQR so that you can view it or make temporary overrides. This enables authorized users access to a copy of the executable JCL to update parameters and correct abends. The updated copy of the JCL is attached to the event’s 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 JCL (unless the override copy is manually deleted). When the event is completed successfully, the JCL override copy is purged with the event at the next schedule load. Note:

If JESQ is the JCL source for the SQR, you cannot override the JCL from Zeke. 226

5 Creating and Monitoring the Schedule

To modify the JCL for an event 1

Access Schedule View, and locate the event for to which you want to access the JCL (as described in “Displaying Scheduled Events” on page 200).

2

Enter JCLR in the Line Cmd field next to the job, and press Enter. This message is displayed: Request queued

3

Enter ZOOM in the Line Cmd field, and press Enter. The Schedule View Record Expand Function screen is displayed: ASG-Zeke Command ===> Evt: 000028

Schedule View Record Expand Function

BROWSE

Platform: MVS JES2 Job Id:

Job: TSKKGUT1

Sched date: 2012053 Run date: 2012053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKEEVTST6 App: System: ZEQA Class: Target: *LOCAL Early:

Dprty: 50 Cntrl: Y

Sched: 00:00

Times: Tapes:

1

LateStrt: LateEnd: 00:00

Freq: AvgDur: 00:00

JCL Line Commands: B - Browse

D - Delete

JCL--> Override present in SQR JCL--> Zeke JCL

4

Grp:

Usrid:

Mustend:

Freqcalc: S Virt Mem: E - Edit

Notafter:

Trig: A

R - Retrieve

Delete after next use (Y/N) N

Review the first JCL field. In this example, the field indicates the JCL has not been retrieved yet: Override present in SQR

5

To edit the JCL, type line command E to the left of the JCL field, and press Enter. Any changes to this field are effective only for the current schedule run.

6

In the Delete after next use (Y/N) field, specify whether to delete the updated JCL after the next use. If you set this field to Y, the override JCL is deleted after the next run of the job. If you set this field to N, the JCL is kept and re-used for every job run until the override JCL 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.

227

ASG-Zeke Scheduling for z/OS User’s Guide

7

The additional JCL field contains the name of the specified JCL source for the job. Update this field, if necessary. Changes to this 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 //ZEKTST29 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.LINKLIB.DVLP 000007 // DD DISP=SHR,DSN=OASIS.LINKLIB 000008 //SYSPRINT DD SYSOUT=* 000009 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name * 000011 //SYSIN DD * 000012 SET WAIT 1 000013 //* ****** ************************** Bottom of Data **************************

8

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 (e.g., CANCEL, COPY, and EDIT). When these commands are issued from Zeke, they are processed as Zeke commands (rather than as 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. 9

Press F3 again to return to the Schedule View screen.

10

Optional. You can check your JCL for syntax errors without affecting the actual SQR. See “Validating JCL” on page 231.

Zeke PDS JCL Override JCL override for PDS JCL works by attaching the JCL from the PDS as a ZEKEJCL attachment to the SQR. This JCL can then be modified for the purpose of re-running the job. As an option, you can choose for Zeke to override the JCL after the next job run.

228

5 Creating and Monitoring the Schedule

Zeke’s 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 ZOVERPDS 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, see the ASG-Zeke Scheduling for z/OS Installation Guide.

To perform a Zeke PDS override for a job 1

Access Schedule View, and locate the event that you want to update (as described in “Displaying Scheduled Events” on page 200).

2

Enter ZOOM in the Line Cmd field to the left of the job, and press Enter. ASG-Zeke Command ===> Event ===>

Schedule View

System=SYSD

BROWSE Scroll ===> PAGE Selected=0000034

2012.084 12:51

Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When ? to list other Line Commands Line Event Sched Job Evnt Event Event Status Cmd No. Date Name Type Name Reason Code ========================================================================== 000001 2012067 DOWN0001 JOB DOWNLOAD0001 Queued Download Hold zoom 000021 2012069 ZEK806 JOB ABEND806 Fail S806 000025 2012065 ZEKXDCA JOB JOBTEMPLATE Queued Need Oper OK 000076 2012057 ZEKJCL JOB ZEKEJCLTEST Success 000079 2012065 ZEKJCL2 JOB ZEKEJCLTEST Fail Forced 001014 2012068 KATHYG01 JOB KATHYG01 Fail JCL Error 001098 2012067 TRACK04 JOB TRACK0000004 Active 6900% 001694 2012067 SCOM EOJTRACK75 Success ********************************** BOTTOM OF DATA *************************

229

ASG-Zeke Scheduling for z/OS User’s Guide

The Schedule View Record Expand Function screen is displayed: ASG-Zeke Schedule View Record Expand Function BROWSE Command ===> ZOVERPDS Platform: MVS Evt: 000021 Job: ZEK806 JES2 Job Id: JOB09781 Sched date: 2012069 Run date: 2012069 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

App: A2345678 Target: *LOCAL

LateStrt: LateEnd: 00:00

Freq: AvgDur: 00:00

JCL Line Commands: B - Browse

Version: 00000

D - Delete

Grp: G23 Usrid: U2345678

Mustend:

Freqcalc: S Virt Mem: E - Edit

Notafter:

Trig: A

R - Retrieve

JCL--> PDS: ZEKEJCL Member: ABEND806

3

On the Command line, enter ZOVERPDS. ASG-Zeke Command ===> Evt: 000021

Schedule View Record Expand Func Override successful Platform: MVS JES2 Job Id: JOB09781

Job: ZEK806

Sched date: 20122012069 Run date: 2012069 STATUS TIME: 01:06 STATUS/REASON: Fail S806

Version: 00000

Type: JOB EventName: ABEND806 System: SYSD Class: A

Grp: G23 Usrid: U2345678

Early:

Dprty: 50 Cntrl: Y

Sched: 00:00

Times: Tapes:

1

App: A2345678 Target: *LOCAL

LateStrt: LateEnd: 00:00

Freq: AvgDur: 00:00

JCL Line Commands: B - Browse

D - Delete

Mustend:

Freqcalc: S Virt Mem: E - Edit

Notafter:

Trig: A

R - Retrieve

JCL--> PDS: ZEKEJCL Member: ABEND806

After the datasets are allocated, ZOVERPDS 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. 4

230

Exit, and then re-access, the zoom screen to see the change in the SQR.

5 Creating and Monitoring the Schedule

5

Optional. Enter E to the left of the JCL-->PDS: OVERRIDE Member field to edit the override JCL. ASG-Zeke Command ===> Evt: 000021

Schedule View Record Expand Function BROWSE Platform: MVS JES2 Job Id: JOB09781

Job: ZEK806

Sched date: 2012069 Run date: 2012069 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

App: A2345678 Target: *LOCAL

LateStrt: LateEnd: 00:00

Freq: AvgDur: 00:00

JCL Line Commands: B - Browse

Version: 00000

D - Delete

Grp: G23 Usrid: U2345678

Mustend:

Freqcalc: S Virt Mem: E - Edit

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 these facilities: •

ASG-JCLPREP (through use of the JPREP line command)

•

ASG-JOB/SCAN (through use of 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. See the section on using other JCL scanning products in the ASG-Zeke Scheduling for z/OS Installation Guide. If your product provides an ISPF EDIT macro to scan JCL, then you can use it while editing event JCL from the ZOOM display.

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: •

Through the ZOOM feature

•

By entering the JPREP line command

JCLPREP can only be used for jobs with existing JCL. 231

ASG-Zeke Scheduling for z/OS User’s Guide

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. See the ASG-Zeke Scheduling 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. Note:

This feature is not supported for SQRs which have JESQ as the JCL source.

To invoke JCLPREP using Schedule View ZOOM 1

Access Schedule View, and locate the event that you want to update (as described in “Displaying Scheduled Events” on page 200).

2

Enter ZOOM in the Line Cmd field to the left of the selected job event, and press Enter. The Schedule View Record Expand Function screen is displayed: ASG-Zeke Command ===> Evt: 000028

Schedule View Record Expand Function

BROWSE

Platform: MVS JES2 Job Id:

Job: TSKKGUT1

Sched date: 2012053 Run date: 2012053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKEEVTST6 App: System: ZEQA Class: Target: *LOCAL Early:

Sched: 00:00

Dprty: 50 Cntrl: Y

Times: Tapes:

1

LateStrt: LateEnd: 00:00 Freq: AvgDur: 00:00

JCL Line Commands: B - Browse JCL--> Zeke JCL

232

D - Delete

Grp:

Mustend:

Notafter:

Freqcalc: S Virt Mem: E - Edit

Usrid:

Trig: A

R - Retrieve

5 Creating and Monitoring the Schedule

3

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 //ZEKTST30 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.LINKLIB.MVS1 000620 //* DD DISP=SHR,DSN=OASIS.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name * 000900 //SYSIN DD *

4

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.

5

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 to the left of the 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.

Invoking JOB/SCAN From Schedule View, you can invoke the JCL management tool, ASG-JOB/SCAN, in either of two ways: through the ZOOM feature, or by entering the JSCAN line command. Both methods for accessing ASG-JOB/SCAN (herein called JOB/SCAN) are described in this section. JOB/SCAN can only be used for jobs that have existing JCL.

233

ASG-Zeke Scheduling for z/OS User’s Guide

See the ASG-Zeke Scheduling 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 Note:

For SQRs with JESQ as the JCL source, the JCL cannot be viewed or edited. 1

Access Schedule View, and locate the event that you want to update (as described in “Displaying Scheduled Events” on page 200).

2

Enter ZOOM in the Line Cmd field next to the job and press Enter. The Schedule View Record Expand Function screen is displayed: ASG-Zeke Command ===> Evt: 000028

Schedule View Record Expand Function

BROWSE

Platform: MVS JES2 Job Id:

Job: TSKKGUT1

Sched date: 2012053 Run date: 2012053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKEEVTST6 App: System: ZEQA Class: Target: *LOCAL Early:

Sched: 00:00

Dprty: 50 Cntrl: Y

Times: Tapes:

1

LateStrt: LateEnd: 00:00 Freq: AvgDur: 00:00

JCL Line Commands: B - Browse JCL--> Zeke JCL

234

D - Delete

Grp:

Mustend:

Notafter:

Freqcalc: S Virt Mem: E - Edit

Usrid:

Trig: A

R - Retrieve

5 Creating and Monitoring the Schedule

3

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 //ZEKTST30 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.LINKLIB.MVS1 000620 //* DD DISP=SHR,DSN=OASIS.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *

4

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.

5

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

Access Schedule View, and locate the event that you want to update (as described in “Displaying Scheduled Events” on page 200).

2

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.

3

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.

235

ASG-Zeke Scheduling for z/OS User’s Guide

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 cannot view the system messages. Note:

To validate JCL on another system, you must specify the system name. Use the ZSCAN operator command to do so. See the ASG-Zeke Scheduling for z/OS Reference Guide for details). Note:

This feature is not supported for SQRs which have JESQ as the JCL source.

To check your JCL for syntax errors using ZSCAN 1

Access Schedule View, and locate the event that you want to update (as described in “Displaying Scheduled Events” on page 200).

2

Enter SCAN in the Line Cmd field, and press Enter.

3

If you have a package designed to browse the JES spool (e.g., 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 these conditions are met:

236

•

You are running an OS release that supports IBM’s spool browse facility

•

You are running JES release 4.x or above

•

The job is in the JES spool.

5 Creating and Monitoring the Schedule

Zeke Dispatching Zeke determines the order in which events are dispatched by evaluating these event attributes or conditions in sequence: 1

Dispatch priority from the event’s SQR.

2

Whether or not the event is near its ‘must start’ time (Muststart). Zeke considers, as applicable, an event’s ‘not after’ time (Notafter), ‘must end’ time (Mustend), average duration (Avgdur), and the value of the Mspintrl generation option (see page 300). Zeke uses one of these two formulas to calculate an event’s near dispatch time and evaluate whether to elevate its dispatch priority: Mustend – Avgdur – Mspintrl = near_dispatch_time For example, let’s suppose that the Mustend time for event ABC is set to 17:00. The event’s average duration is 30 minutes. The value of the Mspintrl generation option is 1 hour (the default value). Based on this formula, Zeke assigns event ABC a higher dispatch priority at 15:30. Or

Notafter – Mspintrl = near_dispatch_time For example, let’s suppose that the Notafter time for event DEF is set to 11:00. The value of the Mspintrl generation option is 1 hour (the default value). Based on this formula, Zeke assigns event DEF a higher dispatch priority beginning at 10:00. 3

Whether the event is past its ‘late start’ time (Latestart) and the Prilate generation option is set to Y (which gives priority to late events despite their schedule time).

4

Run date.

5

Schedule time from the SQR.

6

Event number.

7

Version number.

Note:

An event’s ‘late end’ time (Lateend) does not affect its dispatching sequence. See “Defining a Job Event” on page 69 for information on schedule times and other event attributes that affect event dispatching.

237

ASG-Zeke Scheduling for z/OS User’s Guide

See “Dispatching Events and Messages” on page 300 for details on the generation options that control dispatching.

Early Warning Alerts If enabled, Zeke’s early warning processor analyzes the historical run times for a scheduled event’s predecessors, identifies (at the earliest possible moment) any event that could be dispatched late, and then issues alerts to OpsCentral. For example, if an early event in the schedule is running longer than usual and affects a job downstream that has a Latestart time specified, Zeke alerts you while the earlier job is running. Every minute, Zeke’s early warning processor estimates the start and end time of every SQR that has one or more of these time constraint values specified: •

Latestart

•

Lateend

•

Notafter

•

Mustend

If the SQR’s projected start or end time exceeds one of its time constraints, Zeke issues an early warning alert to OpsCentral. To enable early warning alerts, the OpsCentral server must be configured (i.e., the GUI Serv generation option must be set to Y) and the ZEKE_SERVER_ALERT_EARLYWARN environment variable must be set to YES on at least one of the Zeke systems in your Zekeplex. Zeke projects an SQR’s start and end times by examining the triggers from its WHEN condition and recursively projecting the start and end times of its predecessors. The early warning processor considers only triggers that can be matched to an SQR in the schedule. These types of triggers are ignored: •

DSN, VAR, and NOTDURINGs.

•

All abend triggers (i.e., AEOJ, AEOS, AEOP, AEOE).

•

EOS, EOP, and BOP triggers that do not specify a jobname.

•

Remote dependencies (i.e., triggers with the AT keyword).

•

EOJ, BOJ, or EOE triggers with a job or event name that does not match an SQR.

Other than these exceptions, Zeke’s early warning processor assumes that all of an SQR’s triggers must be satisfied before the event can be dispatched (i.e., Zeke assumes that all WHEN conditions use the AND operator instead of the OR operator).

238

5 Creating and Monitoring the Schedule

Zeke ignores any SQR requirements other than time and WHEN prerequisites (e.g., logical resources, tape drives, and initiators), and also any manual intervention requirements (i.e., operator OKs and work centers). Because Zeke does not track the duration lengths of nonjob events, when projecting start/end times, Zeke’s early warning processor assumes that all nonjob SQRs have a duration of one minute. Caution! If you use early warning alerts and you restore an earlier Zeke database backup file, ASG recommends that you restore the database with the NOSCHED option. Otherwise, if an earlier schedule is restored, your network could become flooded with early warning alerts.

/ZCOM Option You can issue Zeke operator commands either from the console or through the /ZCOM option. See the ASG-Zeke Scheduling for z/OS Reference Guide for a complete list of commands, parameters, and values that are valid for Zeke operator commands. Note:

You also can update the values of Zeke variables through the /ZCOM option.

To issue Zeke operator commands through /ZCOM 1

From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions screen is displayed: ASG-Zeke Option ===>

Schedule Control Function

BROWSE

Please enter a valid Zeke operator command Opt Description

Opt Description

1 2 3 4 5 6 7 8 9 10 11 12

13 14 15 16 17 18 19 20 21 22 23 24

ZD ZD JOB ZD MSG ZD SCOM ZD ZCOM ZD WAIT ZD DONE ZD LATE ZD HOLD ZD AV ZID ZMAP

Cmd: Add - ZADD Function

239

ASG-Zeke Scheduling for z/OS User’s Guide

The Schedule Control Function screen lists some of the most common operator commands you can issue for displaying and updating scheduled event information (depending on your security and class definition). 2

Enter the command (or the option number for the command) on the Option line and press Enter. The ZCOM Output screen is displayed. For example, to display all of the events in the current schedule, enter 1 or ZD on the Option line, and press Enter. Note:

You also can set your own customized commands for options 13 through 24.

Modifying PF Keys Using the SETPF command, you can temporarily modify the PF keys assigned to ZCOM commands. Modified PF keys remain set until you exit the ZCOM function. For example, this command modifies the command assigned and executed when you press PF1: SETPF PF1 'ZD JOB = *PR'

You also can assign a command to a PF key and include a prompt so that you can modify the command parameters before the command is executed. Use these special characters in the command assignment: Character

Meaning

>

Indicates to display the command on the Command line without executing it. This enables the operator to modify the command. Specify this character in the first position (before the command).

@

Indicates where in the command to position the cursor so that the operator can insert parameter values.

For example, let’s suppose you issue this command to modify the command assigned and executed when you press PF1: SETPF PF1 ‘>ZADD APP @

DATE 999999’

When you press PF1, this command is displayed on the Command line: ZADD APP @

DATE 999999

The cursor is positioned after APP to enable to specify the application name. 240

5 Creating and Monitoring the Schedule

When you press Enter, 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 VER TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS 000006 2012053 2012053 000 JOB TSKKGUT1 50 00:00 1 T 000008 2012053 2012053 000 JOB TSKKGUT3 50 00:00 1 T 000011 2012053 2012053 000 JOB SPTEXD11 50 00:00 1 T 000018 2012053 2012053 000 JOB SPTEXD18 50 00:00 1 T 000019 2012053 2012053 000 JOB SPTEXD19 50 00:00 1 T 000020 2012053 2012053 000 JOB SPTEXD20 50 00:00 1 T 000021 2012053 2012053 000 JOB SPTEXD21 50 00:00 1 T 000022 2012053 2012053 000 JOB SPTEXD22 50 00:00 1 T 000023 2012053 2012053 000 JOB SPTEXD23 50 00:00 1 T 000024 2012053 2012053 000 JOB SPTEXD24 50 00:00 1 T 000025 2012053 2012053 000 JOB SPTEXD25 50 00:00 1 T 000026 2012053 2012053 000 JOB SPTEXD26 50 00:00 1 T 000028 2012053 2012053 000 JOB TSKKGUT1 50 00:00 1 T 000029 2012053 2012053 000 JOB SPTEXD29 50 00:00 1 T 000030 2012053 2012053 000 JOB SPTEXD30 50 00:00 1 T Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00028 SYSTEM ZEQA

As usual, press F3 to return to the previous screen.

PathFinder PathFinder displays all predecessor and successor relationships for an event. This enables you to evaluate what needs to occur before an event can run, and what will happen after the event has run. You can access PathFinder through Schedule View, or by issuing a Zeke operator command. See “Using Schedule View” on page 191 for information on activating PathFinder through Schedule View. This procedure explains how to activate PathFinder using a variety of Zeke operator commands. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on Zeke operator commands. Note:

You also can issue any of the operator commands described in this procedure directly from the console.

241

ASG-Zeke Scheduling for z/OS User’s Guide

To activate PathFinder using Zeke operator commands 1

From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions screen is displayed.

2

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Display predecessors for an event at all levels

Issue one of these commands from the Option line: ZD PRE LEV * JOB jobname ZD PRE LEV * EV event-number

Zeke considers the specified event to be at level 0 and displays at the bottom of the flow. You might have to scroll down to see the Level 0 job. Then, scroll up to see the order of the predecessors. They are 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, this message appears directly underneath the job that triggered it: CONDITION ALREADY DISPLAYED BELOW

Display successors for an event at all levels

Issue one of these commands from the Option line: ZD SU LEV * JOB jobname ZD SU LEV * EV event number

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, this message appears directly underneath the job that triggered it: CONDITION ALREADY DISPLAYED ABOVE Display all predecessors Issue one of these commands from the Option line: and successors for an event ZD PRE SU LEV * JOB jobname

ZD PRE SU LEV * EV event number

Scroll down until you find the first job (Level 0) and page up for the predecessors and down for the successors.

242

5 Creating and Monitoring the Schedule

Desired Result

Action

Display nonZeke 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. this message is displayed whenever a nonZeke 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 this message: *** INFINITE WHEN-CONDITION LOOP DETECTED!! ***

243

ASG-Zeke Scheduling for z/OS User’s Guide

Display Successor Example This diagram and screen display show all events that are dependent on an event named MYTEST (i.e., its successors):

MYTEST (Level 0)

ALHJOB2 (Level 1)

DONETST (Level 2)

ZTSRPT9T (Level 2)

ZTSERAXT (Level 3)

ZTSBKUP (Level 4)

ZTSDONE (Level 4)

If you issue this command: ZD SU LEV * JOB MYTEST

then, a screen similar to this one is displayed: ASG-Zeke Command ===>

Zeke Command Output Display

BROWSE

Row 1 to 5 of 5 Scroll ==> PAGE

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 2012053 0000 T 00:00 ---------------------------------------------------------------------------->>1 ALHJOB2 JOB 000002 2012045 0000 EOJ MYTEST T 00:00 2 DONETST JOB 000053 2012045 0000 WEOG ALHJOB2 00:00 2 ZTSRPT9T JOB 000067 2012045 0000 WEOG ALHJOB2 00:23 3 ZTSERAXT JOB 000003 2012045 0000 WEOJ ZTSRPT9T 00:03 4 ZTSBKUP JOB 000708 2012045 0000 WEOJ ZTSERAXT 00:20 4 ZTSDONE JOB 000930 2012045 0000 WEOJ ZTSERAXT 00:10 ******************************* Bottom of data *******************************

244

5 Creating and Monitoring the Schedule

Display Predecessor Example This diagram and screen display show all events on which the event MYTEST is dependent (i.e., its predecessors):

ZTSVLDTT (Level 5)

ZSJOBAT (Level 5)

ZTSJOBBT (Level 4)

ZTSVLDTT (Level 3)

ZTSVLDTT (Level 4)

ZTSJOBDT (Level 3)

ZTSJOBKT (Level 2)

ZEKTST04 (Level 1)

MYTEST (Level 0)

If you issue this command: ZD PRE LEV * EVENT 54

then, a screen similar to this one is displayed: 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 2012038 0000 * 00:00 2012038 0000 * 00:00 2012038 0000 * 00:00 2012038 0000 EOJ ZTSVLDT3 T 00:00 EOJ ZSJOBAT 4*ZTSVLDT2 JOB 001008 2012038 0000 * 00:00 3 ZTSJOBDT JOB 001006 2012038 0000 EOJ ZTSJOBBT T 00:00 EOJ ZTSVLDT2 2 ZTSJOBKT JOB 001004 2012038 0000 EOJ ZTSVLDTT T 00:00 EOJ ZTSJOBDT >>1 ZEKTST04 JOB 001003 2012038 0000 EOJ ZTSJOBKT T SCHD 00:00 -----------------------------------------------------------------------------0 MYTEST JOB 001002 2012038 0000 EOJ ZEKTST04 T 00:00 ******************************* Bottom of data ********************************

245

ASG-Zeke Scheduling for z/OS User’s Guide

Display Predecessor and Successor Example This is an example that shows all of the other events that event ZEKEEVTST3 is dependent on (i.e., its predecessors), and all of the events that are dependent on event ZEKEEVTST3 (i.e., its successors. If you issue this command: ZD PRE SU LEV * EV 3

then, a screen similar to this one is displayed: ASG-Zeke Command ===>

Zeke Command Output Display

BROWSE

Row 1 to 17 of 131 Scroll ==> PAGE

Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel.

predecessors

successors

246

----------------------------------------------------------------------------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*ZEKEEVTST1 MSG 000001 2012053 0000 * 2 KATHYG *** NOT IN THE SCHEDULE OR NOT A ZEKE JOB *** 2*ZEKEEVTST1 MSG 000001 2012053 0000 * 2*ZEKEEVTST1 MSG 000034 2012053 0000 * >>1 ZEKEEVTST2 MSG 000002 2012053 0000 EOJ KATHYG T EOE ZEKEEVTST1 >>1*ZEKEEVTST1 MSG 000034 2012053 0000 * ----------------------------------------------------------------------------0 ZEKEEVTST3 MSG 000003 2012053 0000 EOE ZEKEEVTST2 T EOE ZEKEEVTST1 ---------------------------------------------------------------------------->>1 ZEKEEVTST4 MSG 000004 2012053 0000 EOE ZEKEEVTST3 T 2 ZEKEEVTST5 MSG 000005 2012053 0000 EOE ZEKEEVTST4 T 3 SPTEXD11 JOB 000011 2012053 0000 EOE ZEKEEVTST5 T 00:00 2 SPTEXD29 JOB 000029 2012053 0000 EOE ZEKEEVTST5 T 00:00

5 Creating and Monitoring the Schedule

Manually Adding Events to the Schedule Normally, the SCHEDULE function (a ZEKE batch utility program) automatically schedules all of the required events. If you occasionally need to add an individual event or a group of events to the schedule. Zeke offers these methods for creating an SQR manually: •

ZADD operator command

•

ADD online function

•

ADD by path online function

Note:

If you manually add a job to the schedule that 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 Zeke creates the SQR.

Using the ZADD Operator Command This section explains how to add an event to the schedule using the ZADD operator command. You must know the event number, event name, or jobname of the event that you want to add.

To add an event to the schedule using ZADD 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

Opt Description

1 2 3 4 5 6 7 8 9 10 11 12

13 14 15 16 17 18 19 20 21 22 23 24

ZD ZD JOB ZD MSG ZD SCOM ZD ZCOM ZD WAIT ZD DONE ZD LATE ZD HOLD ZD AV ZID ZMAP

Cmd: Add - ZADD Function

247

ASG-Zeke Scheduling for z/OS User’s Guide

2

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

To add an event by event number

Issue this command: ZADD EV event-num

To add multiple events using a range of event numbers

Issue this command:

To add one version of an event by event number

Issue this command:

To add a job event by jobname

Issue this command:

ZADD EV (event-num, event-num, ...)

ZADD EV event-num VER version-num

ZADD JOB name

To add any event by event name

Issue this command: ZADD ENAME name

Note:

See the ASG-Zeke Scheduling for z/OS Reference Guide for a complete list of parameters and values that are valid with the ZADD operator 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: ASG-Zeke Command ===>

Zeke Command Output Display

BROWSE

Row 1 to 7 of 7 Scroll ==> PAGE

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 VER TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS 000018 2012053 2012053 000 JOB SPTEXD18 50 00:00 1 T 000018 2012055 2012055 000 JOB SPTEXD18 50 00:00 1 T Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00002 SYSTEM ZEQA ****************************** Bottom of data *****************************

248

5 Creating and Monitoring the Schedule

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

To add an event to the schedule using the ADD function 1

From the Zeke Primary Menu, enter option 2.3. The ADD Event Record Selection Criteria screen is displayed: ASG-Zeke Command ===> Options:

ADD Event Record Selection Criteria

Auto: Hold: Rerun: Run:

N N N N

(Y/N) (Y/N) (Y/N) (Y/N)

Schedule Date: 2012055

Enable: N Rebuild: N Refresh: N

(YYYYDDD)

(Y/N) (Y/N) (Y/N)

Run Date: 2012055

2012.055 15:26

(YYYYDDD)

Event ===> 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:

2

Selection Field Masks Job Name: Event Name: Application: Group ID: User ID: Drl ID: System: Permanent:

Specify these additional parameters for adding the event. The valid values for each field are N (the default) and Y. Specify Y for each action that you want Zeke to perform during the ZADD process: Field

Description

Auto

Indicates to add 1 to the 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

Indicates to change the event status from Disabled to Enabled.

249

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description

Hold

Indicates to place an operator hold on the event after Zeke adds, refreshes, or enables the event. You must release the event from hold before Zeke can dispatch it. Note: This parameter is not valid for work centers.

Rebuild

Indicates to re-create the SQR (if an SQR exists already). When rebuilding an SQR, Zeke performs these actions: • Deletes the SQR. • Re-adds the SQR to the schedule. • Resets all WHEN conditions. • Reflects any EMR changes. • Updates the event status to Active. • Resets any changes made previously using the ZALTER operator command.

Rerun

Indicates to add the RERUN designation to the SQR. The RERUN designation appears in the ZDISPLAY operator command output, and is passed to the ZEKE14D user exit. If the Zeke generation option TrigRm is set to N, the event does not trigger the WHEN conditions of other events. You must use the NORERUN parameter with the ZALTER operator command to remove the RERUN designation.

Refresh

Indicates to refresh an SQR (i.e., if the status is EOJ, AEOJ, or Pending) by resetting the event as if it had never run. Note: This parameter does not place an operator hold on the event as the ZREFRESH operator command does.

Run

Indicates to add the event to the schedule ready to run. Note: This parameter has the same effect as the ZALTER RUN operator command.

3

250

If you are adding only one event, you can specify the event number in the Event field.

5 Creating and Monitoring the Schedule

4

Complete the fields in these sections (as applicable) to specify event selection criteria to limit the number of events that are displayed: Note:

If you do not enter any selection criteria, Zeke displays all events defined in the Zeke database.

5

a

Specify any character (except a space) in one or more of the Event Type fields to display events of the selected type(s).

b

In the Selection Field Mask fields, specify any additional information about the events that you want to display (e.g., jobname, user ID, run date, etc.). You can use wildcards and placeholders (see “Specifying Generic Selection Criteria” on page 57).

Press Enter. The Schedule View Event Add List screen is displayed: ASG-Zeke Command ===>

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 ZEKEEVTST1 2012053 MSG ZEQA 000002 ZEKEEVTST2 2012053 MSG ZEQA 000003 ZEKEEVTST3 2012053 MSG ZEQA 000004 ZEKEEVTST4 2012053 MSG ZEQA 000005 ZEKEEVTST5 2012053 MSG ZEQA 000006 KTEST1 2012053 JOB ZEQA KTEST TSKKGUT1 000007 KTEST2 2012053 JOB ZEQA KTEST TSKKGUT2 000008 KTEST3 2012053 JOB ZEQA KTEST TSKKGUT3 000009 KTEST4 2012053 JOB ZEQA KTEST TSKKGUT4 000010 KTEST5 2012053 JOB ZEQA KTEST TSKKGUT5 000011 ZEKEEVCC 2012053 JOB ZEQA SPTEXD11 000012 ZEKEEVCC 2012053 JOB ZEQA SPTEXD12 000013 2012053 WORK ZEQA 000014 2012053 VCOM ZEQA 000015* today ZCOM ZEQA 000016 2012053 SCOM ZEQA

6

Enter S to the left of each event that you want to add to the schedule. To add a particular version of an event to the schedule, specify the version number in the Versn No. field. You can add multiple events at the same time. 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 of the events that you marked on this page. 251

ASG-Zeke Scheduling for z/OS User’s Guide

8

Optional. Press F8 to display the next page of events, and repeat step 6 and step 7.

9

Press Enter to add all of the marked events to the current schedule.

Adding Events By Path You can add an event to the schedule manually, based on predecessor/successor relationships (i.e., the specified event’s 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 the OCCURS clause (REQUEST).

To add an event to the schedule based on an event path 1

From the Zeke Primary Menu, enter option 2.4. The ADD Event Record by Path Selection Criteria screen is displayed: ASG-Zeke Command ===>

ADD Event Record By Path Selection Criteria

Criteria: Event Version Occurs Date Level Type

==> ==> ==> 2012022 ==> 1 ==> B

(omit for default) (YYYYDDD) (P=pred, S=succ, B=both)

ZADD options: Run Date Auto: Rebuild: Run:

2

252

==> 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)

Complete these fields to specify the root event: Field

Description

Event

Required. Specify the event number for the root event (i.e., the event for which to display the path information).

Version

Specify the version of the root event.

5 Creating and Monitoring the Schedule

Field

Description

Occurs Date

Specify the OCCURS HIT date (in Julian format). Only events that would be scheduled on this date are included in the path. The default value is the current system date.

Level

Specify the number of path levels to display. The valid values range from 1 through 999, or you can specify an asterisk (*) to display all levels). The default value is 1.

Type

Specify the type of path to display. These are the valid values: B

Default. Both predecessors and successors.

P

Predecessors only.

S

Successors only.

3

In the Run Date field, specify date on which the event is to run, in Julian format (YYYYDDD). Zeke adds the events with the specified run date.

4

Specify these additional parameters for adding the event. The valid values for each field are N (the default) and Y. Specify Y for each action that you want Zeke to perform during the ZADD process: Field

Description

Auto

Indicates to add 1 to the 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

Indicates to change the event status from Disabled to Enabled.

Hold

Indicates to place an operator hold on the event after Zeke adds, refreshes, or enables the event. You must release the event from hold before Zeke can dispatch it. Note: This parameter is not valid for work centers.

253

ASG-Zeke Scheduling for z/OS User’s Guide

Field

Description

Rebuild

Indicates to re-create the SQR (if an SQR exists already). When rebuilding an SQR, Zeke performs these actions: • Deletes the SQR. • Re-adds the SQR to the schedule. • Resets all WHEN conditions. • Reflects any EMR changes. • Updates the event status to Active. • Resets any changes made previously using the ZALTER operator command.

Refresh

Indicates to refresh an SQR (i.e., if the status is EOJ, AEOJ, or Pending) by resetting the event as if it had never run. Note: This parameter does not place an operator hold on the event as the ZREFRESH operator command does.

Rerun

Indicates to add the RERUN designation to the SQR. The RERUN designation appears in the ZDISPLAY operator command output, and is passed to the ZEKE14D user exit. If the Zeke generation option TrigRm is set to N, the event does not trigger the WHEN conditions of other events. You must use the NORERUN parameter with the ZALTER operator command to remove the RERUN designation.

Run

Indicates to add the event to the schedule ready to run. Note: This parameter has the same effect as the ZALTER RUN operator command.

5

Press Enter. Note:

If the criteria entered results in multiple hit dates, a pop-up window appears and enables you to select the appropriate date.

254

5 Creating and Monitoring the Schedule

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 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00W JOB00W JOB 000025 2012094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00U JOB00U JOB 000023 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BA JOB00BA JOB 000029 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BH JOB00BH JOB 000036 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BQ JOB00BQ JOB 000045 2012094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BL JOB00BL JOB 000040 2012094 00000 SYSTEM1 PATHAPP PTH *1 EVENT00BF JOB00BF JOB 000034 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BI JOB00BI JOB 000037 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2012094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BH JOB00BH JOB 000036 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2012094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BK JOB00BK JOB 000039 2012094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BI JOB00BI JOB 000037 2012094 00000 SYSTEM1 PATHAPP PTH 1 EVENT00BG JOB00BG JOB 000035 2012094 00000 SYSTEM1 PATHAPP PTH 0

EVENT00BE

JOB00BE

JOB

000033

2012094

00000 SYSTEM1

PATHAPP

PTH

*1 2 3 3 3 2 3 3 *1 2 3 3 2 3 3

EVENT00BC EVENT00BA EVENT00Y EVENT00Z EVENT00BL EVENT00BB EVENT00Z EVENT00BA EVENT00BD EVENT00BB EVENT00Z EVENT00BA EVENT00BC EVENT00BA EVENT00BB

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

000031 000029 000027 000028 000040 000030 000028 000029 000032 000030 000028 000029 000031 000029 000030

2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094 2012094

00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000 00000

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

6

SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1 SYSTEM1

Enter S to the left of each event that you want to add to the schedule. To add a particular version of an event, specify the version number in the Versn Number field. Note:

An asterisk (*) next to the Level number indicates where the events at the next level begin. 7

Press Enter to select all of flagged events on the current page.

8

Optional. Press F8 to display the next page of events, repeat step 6 and step 7.

9

Press Enter to add all of the selected events to the current schedule.

255

ASG-Zeke Scheduling for z/OS User’s Guide

256

Resources

Chapter 6:

6 Before dispatching an event, Zeke ensures that all resources are available. These are the resource types: Type

Description

Physical

Includes tape drives, systems, pools, and initiators.

Logical

Anything that you want to define to represent the use of a physical resource (e.g., an entire CPU, a specific CPU channel, a file, or a dataset). Logical resources are used for events that, if executed simultaneously, could cause contention among your system resources.

Note:

Work center events do not use resources. This chapter discusses these topics: Topic

Page

Physical Resources Initiator Processing Defining Pools

258 258 268

Logical Resources Defining a Logical Resource Defining Resources for an Event Deleting Resources for an Event

271 272 274 277

257

ASG-Zeke Scheduling for z/OS User’s Guide

Physical Resources These are the key types of physical resources that Zeke can use: Type

Description

Initiators

An initiator is a physical resource that is required by every MVS event. To optimize the use of system resources, you can configure Zeke to submit events to a system only when an initiator of the correct class is available. Note: Zeke does not support initiator selection for JES3.

Systems and pools

The actual system where an event is processed is a physical resource. Systems can be combined into pools that share the same database (which enables Zeke to select the appropriate system for each event).

Tape drives

Tape drives are a physical resource used for job events. To ensure sufficient tape drives are available before an event executes, you can specify the number of required tape drives on the job’s EMR. See “Defining a Job Event” on page 69. Or, Zeke can automatically calculate the number of tape drives needed for each job. You use the Zeke generation option Calctap to activate this feature. See “Tape Options” on page 308.

Initiator Processing Before you determine whether that 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. No matter how an initiator is selected (i.e., by Zeke or by JES), these are some of the many factors that determine the actual initiator:

258

•

Whether there is a class on the job card

•

Whether there is a list of classes on the EMR

•

Initiator availability at the time of dispatch

•

Whether IBM’s Workload Manager (WLM) is in use

6 Resources

•

Settings of the Zeke generation options DispSel, DefDspCl, and UserCls.

Initiator Selection Using DispSel The most important generation option that affects how initiators are selected is DispSel.

When DispSel is No If the DispSel generation option is set to N, Zeke submits jobs directly to JES when all other dispatching criteria have been met (without regard for initiator availability). Jobs waiting in the JES input queue will have a Pending status while 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 these criteria: •

•

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.

If you set the DispSel generation option to N, these are some additional considerations: •

NOTDURING dependencies are not supported. Note:

If you have specified PLEXNOTD=YES in your ZEKExx PARMLIB options member to enable enhanced NOTDURING JOB processing, then a DispSel value of 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 initiators.

•

The ZMAP command does not show initiator names.

•

The ZDISPLAY AVAILABLE command is not valid.

•

The INITIATOR parameter of the ZHOLD, ZRELEASE, ZALTER, and ZDISPLAY operator commands is not valid.

259

ASG-Zeke Scheduling for z/OS User’s Guide

This flowchart illustrates the process that occurs before an event is dispatched to an initiator, where DispSel is set to N. Figure 1 • Zeke Initiator Selection Process (DispSel is No)

DispSel=N

N

Y Was a class specified in the EMR?

N

Was a value specified for DefDspCl?

Make no changes to the job card

Y

Put the DefDspCl value on the job card

Put the first class specified on the job card

Submit the job to JES

When DispSel is Yes If the DispSel generation option is set to Y, Zeke checks the job’s EMR for a class list. (A job 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 in the Zeke database. Then, Zeke adds or changes the class parameter on the job card to reflect the selected class based on these criteria: •

260

If no class list is supplied, Zeke updates the job card with the highest priority class defined to the initiator and submits the job.

6 Resources

•

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.

—

If UserCls is set to N, Zeke updates the job card with the highest priority class defined to the initiator and submits the job.

This flowchart illustrates the process that occurs before an event is dispatched to an initiator when DispSel is set to Y: Figure 2 • Zeke Initiator Selection Process (DispSel is Yes) DispSel=Y

Was a class specified in the EMR?

N

Y

Waits until a Zeke-defined initiator that processes the specified class is available. Initiator class preference is determined by the order in which the resources are defined in the EMR.

Waits until a Zeke-defined initiator is available

N

UserCls=Y?

The highest priority class processed by the selected initiator is inserted on the job card; the job can run in any available initiator that can run that particular class.

Y

The class in the EMR that causes the initiator to be selected is inserted on the job card.

Submit the job to JES

261

ASG-Zeke Scheduling for z/OS User’s Guide

Defining Job Class Exceptions If you want to configure Zeke to select initiators generally (Zeke generation option DispSel is set to Y), you also can define up to 36 job classes to be treated as exceptions (as if DispSel were set to N). See “Specifying Job Class Capacity Limits” on page 265 for details.

Setting Dispatching Options The first step in setting up Zeke initiator processing is to set the generation options that control dispatching. See “Dispatching Options” on page 297 for more information.

Defining Initiators to Zeke After the dispatching options have been set, 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 normally is not used by Zeke, specify a time range of 00:00 to 00:00 hours. This setting 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 setting ensures that jobs will run in the Zeke-selected initiators, because when Zeke selects the initiator, it inserts the highest priority class for that initiator in the job card, depending on the UserCls generation option. (See the flowchart on page 261.)

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

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

Row 1 to 7 of 7 Scroll ===> PAGE

E - Edit

Description

_ ******** MVS _ *GLOBAL MVS GLOBAL JOB CLASS CAP _ LZ56 MVS _ PLEX55 MVS _ QA27 MVS _ SM27 MVS _ 55QA MVS ******************************* Bottom of data ****************************

262

6 Resources

2

Perform the steps in the Action column (depending on the desired result). Desired Result

Action

Add a new system and initiator specifications

1 Enter ADD on the Command line. 2 Enter the name of the new system in the System field; this is the value of the NAME parameter in the OASISxx PARMLIB options member. 3 Enter MVS in the System Type field to indicate the operating system.

Edit initiator information for an existing system

3

Enter E to the left of the system that you want to update.

Press Enter. The System Initiator Specification screen is displayed: ASG-Zeke Command ===>

System Initiator Specification

EDIT Scroll ==> PAGE

Zeke System: ******** JES System ID:

System type: MVS Description:

Primary command: ADD BROWSE CANCEL CAPACITY COPY DELETE EDIT Line commands: B - Browse initiator detail E - Edit initiator detail D - DELETE A LINE R - REPEAT A LINE I - INSERT A LINE

_ _ _ _ _ _ _ _ _ _ _ _

4

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

Perform the steps in the Action column (depending on the desired result). Desired Result

Action

Add an initiator

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. To add availability detail for the initiator, enter E to the left of the initiator.

263

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Edit existing initiator information

Enter E to the left of the initiator that you want to update.

Copy an initiator record

Enter R to the left of the initiator that you want to copy.

Delete a single initiator

Enter D to the left of the initiator that you want to delete, and press Enter. The initiator is deleted for this system. Go to step .

Delete system name and all initiator specifications

1 Enter DELETE on the Command line, and press Enter. 2 Re-enter DELETE on the Command line, and press Enter to confirm. Go to step .

5

Press Enter. The System Initiator Detail screen is displayed: ASG-Zeke COMMAND ===>

System Initiator Detail

System Id : EDMVS

Initiator Id:

EDIT

A1

Primary commands: BROWSE CANCEL EDIT Start Monday Tuesday Wednesday Thursday Friday Saturday Sunday

6

time time time time time time time

End

Start

End

Start

End

Start

End

ranges: ranges: ranges: ranges: ranges: ranges: ranges:

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. Press Enter. For example, if the initiator is available 24 hours a day on Monday through Saturday, but on Sunday it is available 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 to 00:00 makes the initiator unavailable all day. However, an operator can still make use of the initiator on-demand by using Zeke operator commands. If you do not enter a range for a day, Zeke assumes the initiator is available 24 hours that day.

264

6 Resources

7

At the Command line on any screen, enter ZRELOAD INIT to reload the updated information. (See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using the ZRELOAD operator command.)

Specifying Job Class Capacity Limits If you want to configure Zeke to select initiators generally (the DispSel generation option is set to Y), you also can define up to 36 job classes to be treated as exceptions (as if DispSel were set to N). For example, exceptions are necessary if you are using IBM’s Workload Manager (WLM) to manage initiators and provide workload balancing. Normally, when a job is ready to be submitted, Zeke does not submit the job to the JES queue until there is an available initiator. If WLM is in use and the job’s execution class is for a WLM-managed initiator, then WLM cannot start an initiator until the job has been submitted to JES. Consequently, Zeke does not submit the job because there are no initiators, and WLM does not start more initiators because there is no pending work in the JES queues. Creating job class exceptions enables Zeke-controlled jobs to be submitted to JES without having to wait for an available initiator (even if initiators are managed by WLM). Job class exceptions also are useful if you simply want to limit the number of jobs that Zeke can submit for a particular class of initiators. When you set a job class limit, Zeke submits the job to JES according to the capacity limit and does not consider whether an initiator is available. Because JES (along with WLM, if used) assumes control over job scheduling after the job reaches the JES input queue, setting job capacity limits helps you manage the order of job execution by controlling when a job is placed into the JES queue. Controlling the number of Zeke-submitted jobs that are in the JES queue at the same time (instead of allowing Zeke to send an unlimited number) will increase the potential for the jobs to be executed in closer accordance with your Zeke-defined dispatching priorities.

265

ASG-Zeke Scheduling for z/OS User’s Guide

To specify job class capacities for all defined resources for a system 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

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

Row 1 to 7 of 7 Scroll ===> PAGE

E - Edit

Description

_ ******** MVS _ *GLOBAL MVS GLOBAL JOB CLASS CAP _ LZ56 MVS _ PLEX55 MVS _ QA27 MVS _ SM27 MVS _ 55QA MVS ******************************* Bottom of data ****************************

You can specify job class limits for the resources defined for all of these: •

A particular, named local system.

•

All local systems that are not defined explicitly (********).

•

Resources shared by all systems (*GLOBAL).

Note:

If you define an identically named job class for the *GLOBAL system (as well as the local system), Zeke uses the capacity specified in the local system definition.

266

6 Resources

2

Enter E to the left of the system for which you want to define job class capacity limits. The System Initiator Specification screen is displayed: ASG-Zeke Command ===>

System Initiator Specification

EDIT Scroll ==> PAGE

Zeke System: ******** JES System ID:

System type: MVS Description:

Primary command: ADD BROWSE CANCEL CAPACITY 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

_ _ _ _ _ _ _ _ _ _ _ _

3

MTWTFSS NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN NNNNNNN

At the Command line, enter CAP. The Job Class Capacity screen is displayed: ASG-Zeke Command ===>

Job Class Capacity

Zeke System: ******** JES System ID:

EDIT

System type: MVS Description:

Primary commands: BROWSE CANCEL EDIT Class ----A G

4

Max --NO 99

Class ----B H

Max --9 999

Class ----C I

Max --99 NO

Class ----D J

Max --999 9

Class ----E K

Max --NO 99

Class ----F L

Max --9 999

Enter up to 36 job classes on the six available lines: Field

Description

Class

Job class ID. The valid values range from A through Z, and 0 through 9.

Max

Maximum number of jobs that Zeke can submit for this initiator class. Zeke will submit jobs to JES according to this capacity limit without considering whether an initiator is available. The valid values are NO (i.e., unlimited), or range from 0 through 999. 267

ASG-Zeke Scheduling for z/OS User’s Guide

5

Press Enter to update the data.

6

At the Command line on any screen, issue the command ZRELOAD INIT to reload the updated information. See the ASG-Zeke Scheduling for z/OS Reference Guide for additional information on using the ZRELOAD operator command.

WLM Scheduling Environments You can define Zeke as a resource in a WLM scheduling environment. This resource is used to indicate whether Zeke is active (on) or inactive (off) on a system to ensure Zeke-submitted jobs run only on MVS systems where Zeke is running: •

After Zeke loads the schedule tables, the resource is set to ON.

•

When you terminate Zeke COLD or TRACK (or if the Zeke address space terminates abnormally), the resource is set to OFF.

•

When you terminate Zeke WARM, the resource remains ON.

See the ASG-Zeke Scheduling for z/OS Installation Guide for instructions on how to define Zeke as a WLM resource.

Defining Pools Every job is owned by a system sharing the Zeke database or by a pool. A pool is a user-defined group of systems identified to Zeke. If you have a group of systems that 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 to which the job belongs. The system name corresponds to the NAME parameter of the OASISxx PARMLIB options member (i.e., if you are not using a pool ID). If you do not specify an owning system, then the default of system A is used.

268

6 Resources

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 ===>

System Pool Directory

Row 1 to 1 of 1 Scroll ===> PAGE

Pool id ===> POOL1 Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C -Copy D - Delete

E - Edit

Pool ID Description ************************************************************************** POOL1 TEST POOL MAIN PROD1 POOL ***************************** Bottom of data ******************************

2

Perform the steps in the Action column (depending on the desired result). Desired Result

Action

Add a new pool

1 Enter ADD on the Command line. 2 Enter the name of the new system in the Pool ID field. Note: Do not use any Zeke operands, parameters, or 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).

Edit an existing pool

Enter E to the left of the pool that you want to update, and press Enter.

Delete a pool

1 Enter D to the left of the pool that you want to delete, and press Enter. 2 Enter DELETE on the Command line, and press Enter to confirm. Go to step 6 on page 270.

269

ASG-Zeke Scheduling for z/OS User’s Guide

3

Press Enter. The System Pool Specification screen is displayed: ASG-Zeke Command ===> Pool ID:

System Pool Specification

EDIT Scroll ==> PAGE

POOL1

Desc: TEST POOL

Primary command: ADD BROWSE CANCEL COPY DELETE EDIT Line commands: D - Delete a line I - Insert a line

R - Repeat a line

SYSTEM TSO45

4

Perform the steps in the Action column (depending on the desired result). Desired Result

Action

Add a system to a new pool

In the System field, enter a name for the new system name. You can enter up to 15 systems on one screen. To add more than 15 systems, press F8 to view additional blank entry lines. Note: Do not use any Zeke operands, parameters, or 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

1 Enter I in the unlabeled selection field next to a system name, press Enter. A blank line is added. 2 Enter the new system name on the blank line.

270

Edit an existing system

Complete the changes to the system that you want to update.

Delete a system from a pool

Enter D to the left of the system name, and press Enter.

5

Press Enter to update the pool record.

6

Re-cycle Zeke for the changes to take effect.

6 Resources

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 that the logical resource does not really have to exist. You can use logical resources for events that, if executed simultaneously, could cause contention among your system resources. You can think of logical resources as a more versatile and sophisticated NOTDURING dependency. A logical resource can be anything that you want to define to represent the use of a physical resource (e.g., an entire CPU, a specific CPU channel, a file, or a dataset). For example, let’s suppose that 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 situation causes dataset contention when job 6 is running with any of the other five jobs. To avoid dataset contention, you can use logical resources to ensure that job 6 runs alone. You define a resource to represent the file and give job 6 exclusive access to the resource. To define a logical resource, you must specify this information: •

A quantitative figure to let Zeke know how much of a resource is available at any one time.

•

The systems where the resource is active.

For each job that uses this resource, you then can specify 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, let’s suppose that a resource is defined with a value of 1. Job A needs 1 of this resource before it can run. If Job B is running and using this resource, the resource is not available, and Job A will have to wait for Job B to free the resource. Note:

If DispSel is set to N, Zeke resolves only the resources defined as GLOBAL (i.e., any system can share the resource).

271

ASG-Zeke Scheduling for z/OS User’s Guide

Defining a Logical Resource This section describes how to define resources to the Zeke database. The resource definition specifies 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 Specification

Row 1 to 1 of 1 Scroll ===> PAGE

Resource name ===> System ===> Line Commands: C - Copy D - Delete Primary Commands: ADD COPY DELETE Resource name

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 ******************************

2

System

Perform the steps outlined in the Action column (depending on the desired result): Desired Result

Action

Define a resource to the Zeke database

1 Enter ADD on the Command line. 2 Enter the resource name in the Resource Name field, and press Enter.

Caution! Do not use spaces in the resource name. Edit an existing resource

To update Maximum Shared or Active, type over the existing information, and press Enter.

Copy an existing resource to create a new one

1 Enter COPY on the Command line. 2 Enter the resource name to copy in the Resource Name field, and press Enter. The Resource Detail screen is displayed. 3 Enter the new name in the Resource Name field, and press Enter.

272

6 Resources

Desired Result

Action

Delete a resource from the Zeke database

1 Enter DELETE on the Command line. 2 Enter the resource name to delete in the Resource Name field, and press Enter. The Resource Detail screen is displayed. 3 Press Enter again to confirm.

Caution! Before deleting a resource, ensure that no Zeke events reference the resource to be deleted. An event that attempts to acquire a deleted resource is not dispatched.

3

The Resource Detail screen is displayed: ASG-Zeke Command ===>

Resource Detail

Resource name:

Scroll ===> PAGE INIT1

Primary commands: ADD CANCEL COPY DELETE EDIT System: (GLOBAL)

Max share count: 00005

Active?: YES

In the System field, enter the name of the system that owns the resource. You can specify a resource multiple times with different system names. The default value is GLOBAL (i.e., any system can share the resource). If the job’s system name is assigned to a pool, keep the default value to ensure proper dispatching. 4

In the Max Share Count field, enter the number identifying the resource amount. This value can be any number that quantifies the resource’s availability.

5

In the Active field, enter the code that indicates whether the resource is active:

6

Code

Meaning

YES

Indicates that the resource is active. Zeke ensures that the resource is available before dispatching an event that uses this resource.

NO

Indicates that the resource is not active. Zeke does not perform any resource control for events that use this resource.

When you have finished adding or updating information on the Resource Detail screen, press Enter to save the changes.

273

ASG-Zeke Scheduling for z/OS User’s Guide

Defining Resources for an Event After you have defined logical resources for your systems, you can 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 specified quantity. Caution! You must complete the procedure “Defining a Logical Resource” on page 272 before adding the resource to an event. If you add a resource to an event before you have defined the event, the event will be unable to acquire the resource and cannot be dispatched properly.

To add a resource to an event 1

Access the EMR for the event, or the Event Master Directory, as described in, “Accessing the Event Definition” on page 58.

2

From the Event Master Directory, enter E4 to the left of the event number for the event to which you want to assign a resource. Or

From the EMR, enter RESOURCE on the Command line. 3

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

274

4

If the job has no resources defined, simply enter the name of the resource in the Resource Name field.

5

If the job already has one or more resources defined, perform these steps: 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.

b

Enter the name of the new resource in the Resource Name field of the new line.

6 Resources

6

In the Cnt field, specify a number to represent how much of this resource is used when this job runs. Note:

If mode is EX or ES, this value must be 001. 7

In the Md field, specify the resource mode required by the job. These are the valid codes: Code

Meaning

EX

Allow only one event to access to resource in Write mode For example, let’s suppose that a file is used by six jobs. All of the jobs, except one, use the file in Read mode. The remaining job backs up the file. This situation causes file contention when the job backing up the file is running with the other five jobs. You could avoid file contention (in this example) by taking these steps: • 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 five jobs that read the file with a mode of SR and a count of 1. • Define the resource to the job that backs up the file with a mode of EX, so that it will no execute concurrently with any of the five jobs reading the dataset.

ES

Allow only one event to access this resource in Read mode For example, let’s suppose that, out of a group of six jobs, two of the jobs (A and B) cannot run together; however, the remaining jobs can run in any combination with either job A or B. You could avoid contention (in this example) by taking these steps: • Set up a logical resource with a maximum share count 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: Exclusive-share events cannot run with other exclusive-share events, but they can run with multiple share events.

275

ASG-Zeke Scheduling for z/OS User’s Guide

Code

Meaning

SR

Allow multiple events to access this event For example, three jobs execute nightly at around the same time (which causes performance problems). You could avoid contention (in this example) by taking these steps: • Set up a logical resource with a maximum share count of 100. • Set up each job with a resource mode of SR and a count of 50. Note: Zeke allows only two of these jobs to run simultaneously. The third job must wait for one of the other jobs to complete (so that at least 50 of the resource is available). In this example, the resource must be defined with a maximum share count of 100.

8

In the H field, specify whether resources should be held. These are the valid codes: Code

Meaning

Y

Hold the resource if it is available and is in the correct mode; however, the resource can be “stolen” by another event with a higher dispatch priority. For example, Job A requires four resources prior to dispatch, but other jobs require only one. If the H field is set to Y, then Job A holds each resource as it becomes available until it has all four resources. The other jobs must wait until Job A releases the hold on the resources before they can run.

N

Default. Do not hold the available resource. For example, Job A requires four resources prior to dispatch, but other jobs require only one. If the H field is set to N, the other jobs continue to obtain one of the resources, as needed. Job A waits and does not hold any resources until all four resources are available at the same time.

9

276

In the E field, specify whether resources should be released at AEOJ. These are the valid codes: Code

Meaning

K

Keep resource at AEOJ if the job abends. The resource mode must be EX or ES, and can be obtained by a restart/rerun.

R

Default. Do not hold the resource; release the resource if the job abends.

6 Resources

10

In the A field, specify whether to use the resource for a restart. These are the valid codes: Code

Meaning

Y

Use resource for a restart. The event tries again to obtain the resource from an abended event that has specified its Reskeep value set to Y. Note: The resource mode must be EX or ES and can be obtained by a rerun/restart.

11

N

Do not use resource for a restart.

S

The event assumes the resource only from itself (if the event abends).

Press Enter to save the changes.

Deleting Resources for an Event You can 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 described in, “Accessing the Event Definition” on page 58.

2

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. Or

From the EMR, type 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

277

ASG-Zeke Scheduling for z/OS User’s Guide

3

To delete one or more specific resources, enter d in the line command field to the left of the resource names that you want to delete, and 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. All resources for the event are deleted.

278

Customizing and Maintaining Zeke

Chapter 7:

7 Zeke provides you with a great amount of flexibility and control over Zeke operations including event scheduling and dispatching, as well as maintenance and database access. This chapter discusses these topics: Topic

Page

Zeke Generation Options GENOPTs Accessing the Zeke Generation Options Adding a GENOPT Editing a GENOPT Viewing Pending GENOPT Updates Deleting a GENOPT Reloading GENOPTS Audit Options Dispatching Options Exit Options General Options JCL Options Message Options Scheduling Options Security Options Trace Options User Interface Options Variables Options

280 280 281 287 290 291 293 295 296 297 309 309 312 319 320 324 325 325 326

Defining Schedule Download Agents

327

Obtaining Operating Passwords

329

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

330 331 333 334 337 338

279

ASG-Zeke Scheduling for z/OS User’s Guide

Topic

Page

Continuous Job Tracking Terminating Zeke using ZKILL TRACK SMF Recording Mode Applying Maintenance SMF Playback

340 341 341 344 344

Zeke Generation Options Generation options enable you to configure the operating criteria for your environment. No two data centers are exactly the same, and, typically, no two systems are identical within an environment. Zeke enables you to configure separate systems with different generation options for each one. During Zeke installation, the generation options are set to default values that are suitable for most data centers. ASG recommends that you review the options immediately after you install Zeke and make any modifications. With gained experience using Zeke, you might choose later to change these settings options to better address your needs. Because they affect your entire site, ASG recommends that the personnel responsible for system programming, scheduling, data security, and site standards all review and agree on your generation option settings. There are over 250 generation options. This chapter discusses in greater detail the options that are most commonly used and modified. See the ASG-Zeke Scheduling for z/OS Reference Guide for an alphabetical listing and explanations of all options.

GENOPTs A collection of generation options is referred to as a GENOPT table or GENOPT. You can use GENOPTs to group together specific generation option settings that control a particular system or that you want to be used across multiple systems. You can create new GENOPTs, or Zeke provides default GENOPTs that you can customize or copy. These are the types of GENOPTs:

280

Type

Name

Description

Special

*ACTIVE

Contains all options loaded in memory and currently active (i.e., both global and local options) for the local Zeke system. This GENOPT is generated automatically and is for reference only; you cannot modify or delete it.

7 Customizing and Maintaining Zeke

Type

Name

Description

Global

*GLOBAL

Contains options that require the same setting across all Zeke systems in the Zekeplex (i.e., that share the same database). The global GENOPT *GLOBAL is created during Zeke installation and can be customized. You cannot rename, copy or delete it. When you start Zeke or reload the GENOPTs on request (see “Reloading GENOPTS” on page 295), Zeke loads this GENOPT along with the local GENOPT for the system being initialized.

Local

********

Contains options that control a local Zeke system.

or

You can define a different local GENOPT for each Zeke system in the Zekeplex. The GENOPT name must match the name of user-defined the system ID for Zeke to associate them. The default local GENOPT (********) contains the default option settings for local Zeke systems and can be customized and copied. You cannot rename or delete it. When you start Zeke or reload the GENOPTs on request (see “Reloading GENOPTS” on page 295), Zeke loads the local GENOPT for the system being initialized along with the *GLOBAL GENOPT. If no local GENOPT is found that matches the system ID, Zeke loads the default GENOPT (********). Note: If you customize the default local GENOPT (********), the updated settings are used when you add a new GENOPT (which then can be customized).

Accessing the Zeke Generation Options This procedure explains how to access the GENOPTs Directory (which contains a listing of all default and user-defined GENOPT tables in the Zeke database) using the ISPF online facility. From this directory, you can add, browse, copy, edit, or delete GENOPTs.

To access the GENOPTs Directory 

Enter =4.1 on any Command line, and press Enter.

281

ASG-Zeke Scheduling for z/OS User’s Guide

The GENOPTs Directory screen displays a listing of all GENOPTs in the Zeke database: ASG-Zeke Command ===>

GENOPTs Directory

Row 1 to 4 of 4 Scroll ===> CSR

Zeke System: Primary Commands: ADD BROWSE CONFIRM COPY DELETE EDIT PENDING Line Commands: B - Browse C - Copy D - Delete E - Edit System * Description Last updated by - -------- - -------------------------------- ---------------------------*ACTIVE In-memory values (ZEKE60A ) *ZEKEUP* 01/10/2012 13:21:28 *GLOBAL Zekeplex global options ZEKEUSER 12/05/2011 19:14:48 ZEKE60A * Zeke 6.0 component on SYSA ZEK60JOB 11/29/2011 15:53:54 ******** Default local system options *DBCNVT* 11/10/2011 13:05:28 ******************************* Bottom of data *******************************

The listing displays this information for each GENOPT: •

GENOPT name (which, for local GENOPTs, matches the system ID).

•

Optional, user-defined descriptions for each local GENOPT, and the default local and global GENOPTs. (The description for the *ACTIVE GENOPT is static and references the name of the currently active GENOPT.) In addition to being displayed online, this description is also displayed when you request a GENOPT details for a batch report or ZDISPLAY output. (See the ASG-Zeke Scheduling for z/OS Reference Guide for more information.)

•

Date and time that the local or global GENOPT was last updated, and the user ID or batch jobname that made the update; or, the date and time that the *ACTIVE GENOPT was last reloaded, and the user ID or batch jobname that reloaded it.This information also helps indicate whether a GENOPT was last reloaded automatically as result of a Zeke startup, or as a result of a database CREATE or RESTORE.

•

An asterisk (*) in the second column indicates whether this local GENOPT is the one that is currently active.

From this screen, you can add, browse, copy, edit, and delete GENOPTs using the primary and line commands, as well as set controls for monitoring any changes that are made to a GENOPT.

282

7 Customizing and Maintaining Zeke

Viewing GENOPT Details A detailed view of each GENOPT displays the current setting of each generation option field. The fields are listed alphabetically by default. The CATEGORY primary command enables you to sort and view the display by functional categories. If you sort the display by category, these are the predefined categories under which the generation option fields are organized: Category

Description

Audit

Audit options.

Dispatching

Options that affect event dispatching.

Exits

Options that affect Zeke and operating system exits.

General

All options that do not fall under another category.

JCL

Options related to JCL sources and processing.

Messages

Options that control the issuing of messages.

Scheduling

Options that affect event scheduling.

Security

Options that control security.

Traces

Data space trace options.

User interfaces

Options that affect the ISPF and online facilities.

Variables

Options related to Zeke variables.

To access a detailed GENOPT view 1

Follow the procedure in “Accessing the Zeke Generation Options” on page 281.

2

Enter B in the selection field to the left of the GENOPT you want to browse. Or

a

In the System field, type the name of the GENOPT you want to browse. (The GENOPT name matches the system ID for the associated Zeke system.)

b

Enter BROWSE on the Command line, and press Enter.

283

ASG-Zeke Scheduling for z/OS User’s Guide

The Generation Options screen displays (in browse mode) the options and settings for the selected GENOPT. This is an example of the default (alphabetical) detail view: ASG-Zeke Command ===>

Generation Options

Zeke System: ********

Description:

Option --------Aur: AurIntv: AurMsg: BimAppl: BimPasw: BimUid: CalcMem: CalcTap: ChgVal: CmdCons: CondrDv: CondrLb: CondrVer: DispDly: DispSel:

Value ---------Y 1 Y

OMIT Y Y Y Y SYS000 OMIT 001 30 Y

DSPBatch: N

BROWSE

Row 1 to 17 of 141 Scroll ===> CSR (active)

Description --------------------------------------------------------(Y,N) Yes to enable automatic responses (1-99) Number of seconds to check auto responses (Y,N) Yes to inform operator auto. response issues (xxxxxxxx) Bimedit application name (xxxxxx) Bimedit access password (xxxx) Bimedit access userid (Y,N) Yes to calculate virtual memory (Y,N) Yes to calculate tape drive usage (Y,N) Yes to display Variable update message (Y,N) Yes to route command response to console (xxxxxx) Condor camlib device name (xxxx) Condor camlib qualifier (xxx) Condor version id (nnnnn) Seconds to delay dispatching pooled events (Y,N) Yes for Zeke to select initiators (Yes is ignored for JES3) (Y,N) Yes to use a dataspace for ZEKE batch program

If this is the currently active GENOPT, (active) is displayed to the right of the Description. 3

Optional. You can change the way the options are sorted. Enter this command on the Command line to toggle between a category view and the default (alphabetical) view: CATegory [ON|OFF]

For example, enter CAT ON.

284

7 Customizing and Maintaining Zeke

This is an example of the detail view by category for the same GENOPT: ASG-Zeke Command ===>

Generation Options

Zeke System: JCRZEKEA

Description:

BROWSE

Row 1 to 17 of 152 Scroll ===> CSR

Option Value --------- ---------==================== ==================== Aur: Y AurIntv: 1 CalcMem: Y CalcTap: Y DispDly: 30 DispSel: Y

Description --------------------------------------------------------Audit =================================================== Dispatching ============================================= (Y,N) Yes to enable automatic responses (1-99) Number of seconds to check auto responses (Y,N) Yes to calculate virtual memory (Y,N) Yes to calculate tape drive usage (nnnnn) Seconds to delay dispatching pooled events (Y,N) Yes for Zeke to select initiators (Yes is ignored for JES3) Idcams: N (Y,N) Yes to replace occurences of IDCAMS IgnCat2: N (Y,N) Yes to ignore NOT-CAT2 messages PauseEoj: N (Y,N) Yes to pause partition at FAIL ScomMax: 1 (nn) Maximum subtasks for SCOMs ScomWt: 5 (nn) Maximum minutes before SCOM timeout TapeIO: 100 (nnn) Number of tape I/Os before Zeke calculates ==================== Exits =================================================== DynSmf: Y (Y,N) Yes to dynamically install SMF exit

In a detailed view by category, the categories are listed alphabetically and the applicable fields are listed alphabetically under each category. All category headings are displayed, even if there are no fields in that category associated with the selected GENOPT. Note:

Based on the definition of the GENOPT (i.e., local or global, some options might not be applicable. 4

Scroll through the pages on the Generation Options screen and review the options. Or

To quickly find a particular field or category, you can use these primary commands: Command

Description

FIND

Finds and moves the cursor to the beginning of the specified text string in field names, values, descriptions, and category headings. This is the command format: FIND string

For example, this command finds and places the cursor at the generation option field named Jcl1: FIND JCL

285

ASG-Zeke Scheduling for z/OS User’s Guide

Command

Description

LOCATE

Locates the first line that begins with the specified text string and scrolls to the associated field. This is the command format: LOCATE string

When fields are displayed alphabetically, this command scrolls to the first field that contains the string. When the fields are sorted by category, this command scrolls to the first category name that contains the string. For example, this command scrolls to the JclBrows option field if the fields are listed alphabetically: LOCATE JCL

The same command scrolls to the JCL category if the fields are sorted by category. Note: You cannot use the LOCATE command to scroll to subsequent lines that begin with the string; the command locates only the first line. Finds and highlights the next occurrence of the text string specified on the last FIND string command. This is the command format:

RFIND

RFIND

For example, this is the result when you issue the command FIND DISP: ASG-Zeke Command ===>

Generation Options

Zeke System: KACZ600A

Description: Adding a GENOPT Proc Test

Option --------Aur: AurIntv: AurMsg: BimAppl: BimPasw: BimUid: CalcMem: CalcTap: ChgVal:

286

Value ---------Y 1 Y

OMIT Y N Y

EDIT

Found 'DISP' Scroll ===> CSR

Description --------------------------------------------------------(Y,N) Yes to enable automatic responses (1-99) Number of seconds to check auto responses (Y,N) Yes to inform operator auto. response issues (xxxxxxxx) Bimedit application name (xxxxxx) Bimedit access password (xxxx) Bimedit access userid (Y,N) Yes to calculate virtual memory (Y,N) Yes to calculate tape drive usage (Y,N) Yes to display Variable update message

7 Customizing and Maintaining Zeke

This is the result when you issue the command FIND DISP when the screen is in category mode (i.e., CAT ON): ASG-Zeke Command ===>

Generation Options

Zeke System: KACZ600A

Description: Adding a GENOPT Proc Test

Option Value --------- ---------==================== Aur: Y

EDIT

Row 2 to 18 of 152 Scroll ===> CSR

Description --------------------------------------------------------Dispatching ============================================= (Y,N) Yes to enable automatic responses

This is the result when you issue the command LOCATE DISP: ASG-Zeke Command ===>

Generation Options

EDIT

Row 14 to 30 of 141 Scroll ===> CSR

Zeke System: KACZ600A

Description: Adding a GENOPT Proc Test

Option Value Description --------- ---------- --------------------------------------------------------DispDly: 30

(nnnnn)

Seconds to delay dispatching pooled events

5

In the Zeke ISPF online facility, you can press F1 for field-level help for a particular option. See the ASG-Zeke for z/OS Reference Guide for an alphabetical reference of all Zeke generation option fields.

6

Enter END on the Command line, and press Enter to return to the GENOPTs Directory.

Adding a GENOPT You can add a new GENOPT based on the default local GENOPT (********) or from a copy of another existing GENOPT. Note:

You cannot add a new GENOPT based on the *GLOBAL or *ACTIVE GENOPTs.

To add a GENOPT based on the default local GENOPT 1

Follow the procedure in “Accessing the Zeke Generation Options” on page 281.

2

Enter B or E in the selection field to the left of the default local GENOPT (********). The Generation Options screen displays its options and settings. Skip to step 3 on page 288. Or

287

ASG-Zeke Scheduling for z/OS User’s Guide

3

a

In the System field, type a name (up to eight characters long) for the new GENOPT. The name must match the system ID for the associated Zeke system.

b

In the Description field, type a description for the GENOPT (up to 32 characters long).

Enter ADD on the Command line, and press Enter. A new GENOPT is created based on the settings in the default local GENOPT (********). ASG-Zeke Command ===>

Generation Options

Zeke System:

Description:

Option --------Aur: AurIntv: AurMsg: BimAppl: BimPasw: BimUid: CalcMem: CalcTap: ChgVal: CmdCons: CondrDv: CondrLb: CondrVer: DispDly: DispSel:

Value ---------Y 1 Y

OMIT Y Y Y Y SYS000 OMIT 001 30 Y

DSPBatch: N

ADD

Initial values loaded Scroll ===> CSR

Description --------------------------------------------------------(Y,N) Yes to enable automatic responses (1-99) Number of seconds to check auto responses (Y,N) Yes to inform operator auto. response issues (xxxxxxxx) Bimedit application name (xxxxxx) Bimedit access password (xxxx) Bimedit access userid (Y,N) Yes to calculate virtual memory (Y,N) Yes to calculate tape drive usage (Y,N) Yes to display Variable update message (Y,N) Yes to route command response to console (xxxxxx) Condor camlib device name (xxxx) Condor camlib qualifier (xxx) Condor version id (nnnnn) Seconds to delay dispatching pooled events (Y,N) Yes for Zeke to select initiators (Yes is ignored for JES3) (Y,N) Yes to use a dataspace for ZEKE batch program

4

If you did not already do this from the directory (in step 2 on page 287), enter the GENOPT name (which must match the system ID for the associated Zeke system) in the Zeke System field.

5

Optional. Enter a description (up to 32 characters long) of the GENOPT in the Description field.

6

Scroll through the pages on the Generation Options screen and review the options. Make any necessary changes to the option settings. Note:

By default, the options are listed alphabetically. You also can list the options by category. To change the way the options are sorted, see step 3 on page 284, or to quickly locate an option or category, see step on page 285.

288

7 Customizing and Maintaining Zeke

7

On the Command line, type SAVE to save the new GENOPT and remain on the screen in edit mode, or type END to save the GENOPT and return to the GENOPTs Directory. Note:

You can type CANCEL to cancel adding the new GENOPT, if necessary. Press Enter. The new GENOPT is added to the Zeke database.

To copy an existing GENOPT 1

Follow the procedure in “Accessing the Zeke Generation Options” on page 281.

2

Enter C in the selection field to the left of the GENOPT that you want to copy. Skip to step 3. Or

a

In the System field, type the name of the GENOPT that you want to copy. (The GENOPT name matches the system ID for the associated Zeke system.)

b

Enter COPY on the Command line, and press Enter.

The Generation Options screen displays the options and settings for the selected GENOPT. Note:

You also can access the GENOPT to be copied in browse or edit mode, and then issue the COPY command from the Generation Options detail screen. 3

In the Zeke System field, enter a name (up to eight characters long) for the new GENOPT. The name must match the system ID for the associated Zeke system.

4

Optional. In the Description field, type a description for the GENOPT (up to 32 characters long) or replace the existing value.

5

Scroll through the pages on the Generation Options screen and review the options. Make any necessary changes to the option settings. Note:

By default, the options are listed alphabetically. To change the way the options are sorted, see step 3 on page 284, or to quickly locate an option or category, see step on page 285.

289

ASG-Zeke Scheduling for z/OS User’s Guide

6

On the Command line, type SAVE to save the new GENOPT and remain on the screen in edit mode, or type END to save the GENOPT and return to the GENOPTs Directory. Note:

You can type CANCEL to cancel adding the new GENOPT, if necessary. Press Enter. The new GENOPT is added to the Zeke database.

Editing a GENOPT You can edit all existing GENOPTs except *ACTIVE (which is generated automatically by Zeke).

To edit a GENOPT 1

Follow the procedure in “Accessing the Zeke Generation Options” on page 281.

2

Enter E in the selection field to the left of the GENOPT that you want to edit. Skip to step 3. Or

a

In the System field, type the name of the GENOPT that you want to edit. (The GENOPT name matches the system ID for the associated Zeke system.)

b

Enter EDIT on the Command line, and press Enter.

The Generation Options screen displays (in edit mode) the options and settings for the selected GENOPT. 3

Scroll through the pages on the Generation Options screen and review the options. Note:

By default, the options are listed alphabetically. To change the way the options are sorted, see step 3 on page 284, or to quickly locate an option or category, see step on page 285.

290

4

Make any necessary changes to the option settings. You also can update the System name and/or Description by typing over the existing values.

5

Enter SAVE on the Command line to save the updated GENOPT and remain on the screen in edit mode, or enter END to save the GENOPT and return to the GENOPTs Directory.

7 Customizing and Maintaining Zeke

Note:

You can enter CANCEL to cancel the changes the GENOPT, if necessary. Press Enter. The GENOPT is updated in the Zeke database. If you updated the currently active GENOPT, a pop-up panel displays the options that were changed, the new values, and the action required to activate each updated option: ASG-Zeke Generation Options EDIT +---------------- ASG-Zeke Generation Options ----------------+ | Pending GENOPT Changes Row 1 to 6 of 6 | | Command ===> ______________________________________________ | | | | You have made changes to the active GENOPT, ********. | | | | No options require Zeke to be recycled COLD. | | 4 options require Zeke to be recycled TRACK. | | 2 options can be activated with ZRELOAD GENOPT. | | _ Issue the ZRELOAD command | | | | Option Action New value | | ---------- ------- -------------------------------------- | | Aur TRACK N | | BatSec ZRELOAD N | | PbTrack TRACK Y | | Posid TRACK Y | +-------------------------------------------------------------+ Condrdv: SYS000 (xxxxxx) Condor camlib device name Condrlb: OMIT (xxxx) Condor camlib qualifier Condrver: 001 (xxx) Condor version id Datasub: Y (Y or N) Yes for Zeke to substitute DOS JCL

6

Optional. To issue the ZRELOAD GENOPT command at this point, enter any nonblank character in the Issue the ZRELOAD command field or enter the ZRELOAD GENOPT command on the Command line. This command requires the appropriate user authorization.

Viewing Pending GENOPT Updates When you update and save the currently active GENOPT, a pop-up panel displays the options that were changed, the new values, and the action required to activate each updated option. You also can quickly view any changes that are pending (i.e., that have not been made active yet by an options reload or a Zeke re-cycle) for the currently active GENOPT.

To view pending updates to the active GENOPT 1

Follow the procedure in “Accessing the Zeke Generation Options” on page 281. 291

ASG-Zeke Scheduling for z/OS User’s Guide

2

Enter PENDING on the Command line, and press Enter. ASG-Zeke Generation Options EDIT Row 1 to 17 of 141 +________________ ASG-Zeke Generation Options ________________+ ll ===> CSR | Pending GENOPT Changes Row 1 to 1 of 1 | | Command ===> Scroll ===> CSR | | | | Changes are pending to the current GENOPT, JCR600B. | | | | No options require Zeke to be recycled COLD. | | No options require Zeke to be recycled TRACK. | | 1 options can be activated with ZRELOAD GENOPT. | | Issue the ZRELOAD command | | | | Option Action New value Gbl | | -------- ------- ----------------------------------- --- | | DSPBatch ZRELOAD N | | ********************* Bottom of data ********************** | | | | | | | | | +_____________________________________________________________+ DispSel: Y (Y,N) Yes for Zeke to select initiators (Yes is ignored for JES3) DSPBatch: N (Y,N) Yes to use a dataspace for ZEKE batch program

The Pending GENOPT Changes pop-up displays these details:

3

292

•

Name of the currently active GENOPT.

•

Number of updated settings that require Zeke to be re-cycled COLD.

•

Number of updated settings that require Zeke to be re-cycled TRACK.

•

Number of updated settings that you can activate by issuing a ZRELOAD GENOPT command.

•

Name and new value of each updated option, and the required action to activate the new setting.

Optional. To issue the ZRELOAD GENOPT command at this point, enter any nonblank character in the Issue the ZRELOAD command field or enter the ZRELOAD GENOPT command on the Command line. This command requires the appropriate user authorization.

7 Customizing and Maintaining Zeke

Deleting a GENOPT You can delete any GENOPT except the special ones (i.e., ********, *GLOBAL, and *ACTIVE).

To delete a GENOPT 1

Follow the procedure in “Viewing GENOPT Details” on page 283. The Generation Options screen displays the options and settings for the selected GENOPT. Skip to step 3b. Or

Follow the procedure “Accessing the Zeke Generation Options” on page 281. 2

Enter D in the selection field to the left of the GENOPT that you want to delete. Or

3

a

In the System field, type the name of the GENOPT that you want to delete. The GENOPT name matches the system ID for the associated Zeke system.

b

Enter DELETE on the Command line, and press Enter.

If a confirmation pop-up displays the name of the GENOPT to be deleted, follow the instructions to confirm the delete request. (See “Setting the Delete Confirmation Option” on page 294 for instructions on how to implement this feature.) Otherwise: a

Re-enter DELETE on the Command line, and press Enter to confirm the delete request and return to the GENOPTs Directory. Or

b

Enter CANCEL or EXIT to cancel the delete request.

Note:

If the currently active GENOPT is deleted, the GENOPT is marked with an X (instead of an *) in the GENOPTs directory and no further changes can be made to the deleted GENOPT. When a ZRELOAD GENOPT command is issued or Zeke is re-cycled, the Zeke activates the default local GENOPT (********) in place of the deleted one.

293

ASG-Zeke Scheduling for z/OS User’s Guide

Setting the Delete Confirmation Option For added control, you can set an option that specifies whether to display a confirmation pop-up when a user attempts to delete a GENOPT.

To implement or cancel delete confirmations 1

Follow the procedure “Accessing the Zeke Generation Options” on page 281.

2

From the GENOPTs Directory or from any Generations Options detail view, type CONFIRM on the Command line, and press Enter.

The CONFIRM primary command toggles between enabling and disabling the pop-ups. The command enables confirmation pop-ups (if they currently are disabled). Or, if confirmation pop-ups are enabled already, the CONFIRM command disables them. When confirmations are enabled, this pop-up displays when you request to delete a GENOPT: ASG-Zeke GENOPTs Directory Row 15 to 20 of 20 +_________________________ ASG-Zeke __________________________+ ll ===> CSR | Confirm Delete | | Command ===> | | | | Delete pending for GENOPT table: | | TCOM600Z | | | | Set delete confirmation off for GENOPT tables. | | | | Press ENTER to confirm delete. | | Press CANCEL or EXIT to cancel delete. | | | +_____________________________________________________________+ VJCRVTAM *DBCNVT* 01/17/2012 14:38:04 ******** *DBCNVT* 01/17/2012 14:38:04 ******************************* Bottom of data ********************************

See “Deleting a GENOPT” on page 293 for details on deleting a GENOPT.

294

7 Customizing and Maintaining Zeke

Reloading GENOPTS Zeke activates some generation options immediately when you save them, but most options must be reloaded for each system that is affected by the changes. Zeke reloads the generation options automatically during each startup. Or, you can reload the generation options at any time by issuing this command: ZRELOAD GENOPT [FORCE] Note:

See the chapter on operator commands in the ASG-Zeke Scheduling for z/OS Reference Guide for more information on the ZRELOAD command. For most generation options, the changes take effect immediately; however, some options do require a Zeke re-cycle (i.e., at least a ZKILL TRACK re-cycle and, in some cases, a ZKILL COLD re-cycle. A ZKILL WARM re-cycle does not reload the generation options). The required action for each option is noted in the field-level online help and in the chapter on generation options in the ASG-Zeke Scheduling for z/OS Reference Guide. After updating the currently active GENOPT, you have the option to reload the options. When you save the GENOPT changes, this information is provided: •

Name of the GENOPT.

•

Number of updated settings that require Zeke to be re-cycled COLD.

•

Number of updated settings that require Zeke to be re-cycled TRACK.

•

Number of updated settings that you can activate by issuing a ZRELOAD GENOPT command.

•

Name and new value of each updated option, and the required action to activate the new setting.

As an option, you can reload the generation options at this point. This action requires the appropriate user authorization. You also can review any changes that have been made to the currently active GENOPT, but have not been activated yet, without actually reloading the changes. See “Viewing Pending GENOPT Updates” on page 291 for details.

295

ASG-Zeke Scheduling for z/OS User’s Guide

Audit Options The AUDIT utility (in OASIS) tracks Zeke database activity and logs the information in an audit log file. You decide what types of activity that you want to audit. These are some of the actions you can track in an audit log: •

Issued Zeke operator commands

•

Changes to any of these elements: —

Event’s status (e.g. scheduled, active, or EOJ)

—

Zeke variables

—

Event definitions

—

Internal security classes

—

Calendars

—

External security classes

—

Zeke generation options

—

Your company name or address

—

Internal security operator records

—

Passwords

—

Partition definitions

—

Pool records

—

Resource definitions

—

SQRs

When an audited element is updated, the change is recorded automatically in the audit log. You can use audit records to generate reports to review the logged updates. Note:

You must set the XAUDxx option ZEKEADT with the number of Zeke audit logs and allocate the audit log datasets before any activity is be logged. Audit options are global generation options that enable the auditing (i.e., by the OASIS AUDIT utility) of different types of Zeke system activities and record updates (e.g., changes to EMRs, SQRs, variables, calendars, generation options, etc.). You enable the audit option for each type of information that you want to track. Audited activities are logged in a record in the audit log file. See the ASG-OASIS for z/OS Reference Guide for more information on setting up and using the AUDIT utility and on audit reporting. 296

7 Customizing and Maintaining Zeke

To access the audit options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the *GLOBAL GENOPT, then locate the audit options. In ISPF, you can use the LOCATE AUD command to locate the first audit option, or issue CATEGORY ON to sort the display by categories and scroll to the Audit section.

2

Review the audit options and their default values.

3

Update each audit option according to your requirements: Specify Y to enable auditing for the corresponding function. Or

Specify N to disable auditing for the corresponding function. 4

You can reload the audit options by re-cycling Zeke using the ZKILL COLD or ZKILL TRACK operator command. See “Reloading GENOPTS” on page 295 for details.

Dispatching Options Dispatching options are local and global generation options that control Zeke dispatching.

To access the dispatching options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the local or *GLOBAL GENOPT, then locate the dispatching options. In ISPF, you can use the LOCATE DISP command to locate the first dispatching option, or issue CATEGORY ON to sort the display by categories and scroll to the Dispatching section.

2

Review the dispatching options and their default values.

3

Update each dispatching option according to your requirements: For many options, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. For other options, you might be required to specify a numeric or character value (e.g., a time, interval, class, disposition, or code), or you can keep the default value.

297

ASG-Zeke Scheduling for z/OS User’s Guide

4

You can reload most dispatching options using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details. Note:

These dispatching options require you to re-cycle Zeke using ZKILL TRACK: Aur DsclTrig Flush (VSE only) Idcams Scommax (VSE only) TapeIO WkTrgdn WkTrgds Updating the PausEoj dispatching option requires you to re-cycle Zeke using ZKILL COLD. The following sections discuss some of the most important options used to control Zeke dispatching and also indicate the additional related generation options that might be required to support a particular dispatching environment or configuration.

Initiator Processing These generation options determine how Zeke uses initiators in your system: Option

Description

ChkSEnv

Indicates whether Zeke performs scheduling environment checking. These are the valid values: Y

Default. Zeke checks each event to be scheduled for the value of the SCHENV field, which indicates the name of the requested scheduling environment. • For job events targeted for the current system and for all other event types, Zeke dispatches the event when the scheduling environment is active. • For job events targeted for a pool, Zeke dispatches the event if the scheduling environment is active on any system in the pool. • For job events targeted for a remote system, Zeke does not check for the scheduling environment.

298

7 Customizing and Maintaining Zeke

Option

Description See “Using Scheduling Environments” on page 105 for more information. Note: For a job event, this value can be inserted (optionally) in the JCL before the job is submitted to JES. See “JOB Card Override” on page 315 for more information. N

Zeke does not check the event to see if a particular scheduling environment is requested.

DefJPrty

Specifies a default job operating system priority (from 0 through 15) to use if a priority is not entered in the Pri field in the EMR. The default value is 1. If the priority should be left unchanged, then enter NO.

DefDspCl

Specifies the default dispatch class that is assumed if the class is not entered on the EMR.

DispDly

Specifies the number of seconds to wait between dispatches of pooled events. The default value is 30. This field is required if the DispSel generation option is set to N, but is ignored if the Posid generation option is set to Y.

DispSel

Indicates whether Zeke selects the initiators. Note: DispSel is ignored if you are using JES3. These are the valid values: N

Zeke does not select initiators and submits jobs to JES regardless of initiator availability.

Y

Default. Zeke selects initiators and submits jobs to JES based on initiator availability. Generally, if you want to set DispSel to Y, you also can define specific job classes to be treated as if DispSel is set to N (e.g., if you use Workload Manager to manager initiators, but you want Zeke to be able to submit certain job classes to JES without having to wait for initiator availability).

UserCls

Optional. Indicates whether to use the EMR class for job submission. These are the valid values: N

Do not use the EMR class; select initiators using the Zeke class selection process.

299

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description Y

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, then Zeke selects initiators using the regular class selection process.

Dispatching Events and Messages These generation options are related to dispatching events and issuing related messages: Option

Description

Note: In this table, the term priority refers to the Zeke dispatching priority, not the operating system job priority. DefDPrty

Specifies a default dispatch priority (from 0 through 99) to use if a dispatch priority is not entered on the EMR. The default value is 50. This value displays in the Dprty field on the EMR.

Dispdly

Specifies the number of seconds to wait between dispatches of pooled events. The default value is 30. This field is required if the DispSel generation option is set to N, but is ignored if the Posid generation option is set to Y.

Msgwait

Specifies the time interval (in HH:MM format) that Zeke waits between issuing messages for events waiting in the dispatch queue. The default value is 01:00 (i.e., one hour). This option affects these messages: Z0601I Z0602I Z0611I Z0615I Z0617I Z0618I Z0628I Z0631I Z0634I

Mspintrl

Specifies the time (near dispatch) interval (in HH:MM format) when an event is given a higher dispatch priority. A job is given a higher dispatch priority if its ‘must start’ or ‘not after’ times are within the interval. The default value is 01:00 (i.e., one hour).

Operok

Indicates whether Zeke is to wait for an operator OK before dispatching any event. You can override this option for an individual event on the EMR (OPEROK). These are the valid values: N

300

Default. Dispatch events without an operator OK

7 Customizing and Maintaining Zeke

Option

Description Y

Prilate

Wait for an operator OK; a message is issued when an event is placed in the dispatch queue

Specifies whether to dispatch late events with a higher dispatch priority. These are the valid values: N

Default. Dispatch events in the schedule time sequence (regardless of late time).

Y

Dispatch late events before other events (regardless of the schedule time).

These are the default dispatching messages that are issued by Zeke: Z0308I EVENT nnnnnn yyyyddd VER vvvvv RESCHEDULED FOR ... Z05C18I Event nnnnnn yyyyddd ver vvvvv issued ... Z05C18I ZEKESET Job jjjjjjjj issued ... Z0603I nnnnnn yyyyddd ver vvvvv Dispatched Type=... Z0604I Event nnnnnn yyyyddd ver vvvvv Dispatched Job=... Z0620I Event nnnnnn yyyyddd ver vvvvv VCOM Dispatch Requested Z0683I Event nnnnnn yyyyddd ver vvvvv Dispatched Exec=...

where: nnnnnn is the event number. yyyyddd is the schedule date. vvvvv is the version number. jjjjjjjj is the jobname.

Retaining Events These generation options are related to retaining events: Option

Description

CommCtl

Indicates whether to retain work centers in the schedule until they are completed (EOJ) or disabled. These are the valid values: N

Discard work centers the next day, regardless of status.

Y

Default. Retain work centers until completed or disabled.

301

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description If this option is set to N and the Retain field in the EMR is set to Y, then this option overrides the Retain value the EMR for work centers only. If this option is set to N and the Retain field in the EMR is set to Y, but the LoadComm generation option is set to Y, then the work center is retained.

DropSel

Indicates whether to drop completed events from the current schedule when selection parameters are included with the SCHEDULE ACTIVATE command for a new schedule run. These are the valid values: N

The SCHEDULE function drops from the current schedule all completed events regardless of whether they match the selection parameters included with the new SCHEDULE ACTIVATE command. This option prevents completed events from accumulating with the creation of each new schedule.

Caution! Because incomplete events are discarded during each schedule run if they have Retain set to N in the EMR, if you run multiple SCHEDULE commands per day with selection parameters, this option could cause some incomplete events to be dropped unintentionally. Y

Default. The SCHEDULE function drops from the schedule only the completed events that match the selection parameters included with the SCHEDULE ACTIVATE command.

Caution! This option enables completed events to remain in the schedule indefinitely (which could impact performance). Review the SCHEDULE job output routinely for message Z08D8I (which indicates completed events retained in the database). Retain

RetDays

302

Indicates whether to retain incomplete (i.e. non dispatched) events. This option determines the default value for the Retain field on the EMR. These are the valid values: N

Discard non dispatched events during the next schedule run.

Y

Default. Retain events for the next schedule run.

Specifies the number of days to retain pending or failed (AEOJ) job events. The default value is 002. If you specify 000, then events are dropped at the next day’s schedule load.

7 Customizing and Maintaining Zeke

Option

Description

RetDone

Indicates whether to retain completed events in the schedule. Note: If using EOG, you must retain completed events. These are the valid values:

Retpend

N

Discard completed events after EOJ.

Y

Default. Retain completed events.

Indicates whether to retain an SQR until the event is completed. These are the valid values: Y

Default. Retain SQRs until they are completed (i.e., EOJ or disabled).

N

Delete SQRs after the event has been dispatched.

Event Triggering These generation options are related to event triggering: Option

Description

DsclTrig

Indicates the dataset dispositions that qualify as triggers for DSN WHEN conditions. These are the valid values: NA

Default. Triggers when a NEW dataset is closed (even by an abending program).

N

Triggers when a NEW dataset is closed. This value can be used alone or in combination with another code (e.g., NO, NM, NOM, etc.).

O

Triggers when an OLD or SHR dataset is closed. Triggers when a NEW dataset is closed. This value can be used alone or in combination with another code (e.g., NO, OM, NOM, etc.).

M

Triggers when a MOD dataset is closed. Triggers when a NEW dataset is closed. This value can be used alone or in combination with another code (e.g., NM, OM, NOM, etc.).

303

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description A

Triggers when a dataset with any of the above dispositions is closed by an abending program. This code can be added to any combination of the codes above. For example, setting DsclTrig to NOMA would trigger on the close of any of the dispositions. Note: If A is not specified, then any of the other disposition codes above do not trigger if the dataset is closed by an abending program.

(blank) Iefu83

Does not allow dataset close triggering.

Indicates whether to dynamically install the SMF IEFU83 exits to trigger events when a newly created dataset is open and closed. Note: Because the Iefu83 option controls whether the Zeke IEFU83 SMF exit ZEKE48G is loaded, changes to this option require a ZKILL COLD restart.

RemTrig

Y

Install the SMF IEFU83 exits to use the DSN dependency

N

Default. Do not install the SMF IEFU83 exits

Specifies 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, then 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, then the system’s current date is sent as the schedule date and run date with the trigger. These are the valid values:

304

ND

Trigger the newest date only.

NT

If multiple dates exist, then do not trigger any date. If only one date exists, trigger that date.

OD

Trigger the oldest date only.

TA

Trigger all dates.

7 Customizing and Maintaining Zeke

Option

Description

TrigDt

Specifies whether a Zeke-controlled job can trigger another event’s WHEN conditions if the schedule or run dates are different. These are the valid values: A

Default. Any event can trigger an event’s WHEN conditions (regardless of the date).

R

The run dates must be the same before an event can trigger another event’s 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.

S

The schedule dates must be the same before an event can trigger another job’s WHEN conditions. The schedule date is the date that an event would have run if it were not a nonworking day (weekend or holiday).

Note: When the schedule is created and a subset of SQRs is to be downloaded to Zeke Agent, the value of the TrigDt option is communicated to Zeke Agent. If this option is changed on Zeke and reloaded, then Zeke Agent continues to use the old TrigDt value until a new schedule is downloaded. TrigJob

Specifies whether a job can trigger another event’s WHEN conditions if the job is not dispatched by this Zeke (or by another Zeke sharing the same database). These are the valid values: A

Default. Any job can satisfy triggers on this Zeke regardless of how/where the job is dispatched.

C

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.

S

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: When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the target of the AT netregid of another scheduler’s trigger), a nonZeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke’s TrigJob option. Both the local and remote Zeke systems ignore the Trigjob option when satisfying cross-schedule triggers.

305

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description

TrigRrn

Specifies whether a job can trigger another event’s WHEN conditions if the job has a rerun designation. These are the valid values:

WkTrgdn

N

A rerun event cannot trigger another event’s WHEN conditions.

Y

Default. Any event can trigger an event’s WHEN conditions, regardless of the rerun designation.

Specifies whether completed events can satisfy the WEOJ/WEOE (weak) WHEN conditions of other events in the schedule. These are the valid values: N

Default. Do not allow completed events to trigger weak WHEN conditions.

Y

Allow completed events to trigger weak WHEN conditions.

Caution! In a Zekeplex (in which multiple Zeke systems share a database), each system must be set to the same WkTrgdn value to prevent excessive database I/O. WkTrgds

Specifies whether disabled events can satisfy the WEOJ/WEOE (weak) WHEN conditions of other events in the schedule. These are the valid values: N

Default. Do not allow disabled events to trigger weak WHEN conditions

Y

Allow disabled events to trigger weak WHEN conditions. Note: Disabling an event will result in the weak triggering of the dependent event. If the disabled event is enabled later, the weak trigger will no longer be satisfied. If multiple events satisfy the weak WHEN condition, all must be disabled for triggering to occur.

Caution! In a Zekeplex (in which multiple Zeke systems share a database), each system must be set to the same WkTrgds value to prevent excessive database I/O. Note: If you update DsclTrig, WkTrgdn, or WkTrgdn, you must re-cycle Zeke using the ZKILL TRACK or ZKILL COLD command. If you update IEFU83, you must re-cycle Zeke using the ZKILL COLD command.

306

7 Customizing and Maintaining Zeke

Pending Events and Messages These generation options are related to pending events and messages: Option

Description

PendInv

Specifies the number of minutes in the pending event interval that Zeke will hold a pending event’s initiator. At the end of this interval, Zeke will place the initiator in the table of available initiators and dispatch other events to it.

PendMsg

Specifies the number of minutes in the pending message interval (between messages that notify you of a pending event). Enter 0 if you do not want a message to be issued.

Checking the Dispatch Queue The EojWake generation option specifies when Zeke will check the dispatch queue. These are the valid values: Code

Meaning

Y

Default. Zeke checks the dispatch queue at EOJ of each job.

N

Zeke checks the dispatch queue every 60 seconds. (This value could delay dispatch of an event for up to one minute.)

Updating this option requires you to re-cycle Zeke using ZKILL COLD or TRACK.

Dispatching Events after Zeke Startup The OprHold generation option specifies whether events are dispatched (or held) after Zeke startup. Verify that this option is set to N (the default) to make Zeke ready to dispatch events after startup. If this value is set to Y, then Zeke cannot dispatch events. ASG recommends that you do not place Zeke on hold with the OprHold option set to Y. If Zeke is placed on hold, you can issue the ZREL SYSTEM command to release Zeke. This option requires you to re-cycle Zeke using ZKILL COLD or TRACK. Caution! If you issue the ZRELOAD GENOPT command to reload the generation options while OprHold is set to Y, then Zeke is placed on hold.

307

ASG-Zeke Scheduling for z/OS User’s Guide

Auto Reply Options Zeke enables you to automatically respond to outstanding replies (WTORs) from your Zeke-controlled jobs which have static or predictable responses. These generation options affect automatic replies: Option

Description

Aur

Indicates whether to enable automatic responses to messages and replies. The automatic reply facility is designed for job events that require message replies.

Aurintv

Specifies the interval (in seconds) to check for automatic replies. The valid values range from 01 through 99. The default value is 1. Note: If you have numerous jobs with auto replies, use a lower value to improve throughput. If you have only a few jobs with auto replies, use a higher value to decrease system overhead.

Aurmsg

Indicates whether the operator is notified of issued auto replies.

Tape Options The Calctap option automatically tracks the number of tape drives used by a job. If Calctap is set to Y, then the calculated value is displayed on the EMR with an asterisk (*) to indicate that it is an Zeke-calculated value. (A value without an asterisk indicates that it is a user-assigned value.) If the Tapes field on the EMR is specified, the specified number of tape drives must be available before Zeke will dispatch the job. Zeke keeps a running count of all tape mounts for a job, not just the tape drives. For example, if a job mounts two tapes in the same step or one tape per step in a two-step job, the calculated tape value is 2. Zeke does not recognize that the tape mounts are probably done on one drive. (If you need a better way to handle this situation, use logical resources. See Chapter 6, “Resources,” on page 257.) Note:

If DispSel is set to N, then Calctap is ignored if it is set to Y. To deactivate automatic calculation of tape drive usage, specify N to deactivate tracking and recording the number of tape drives used by a job.

308

7 Customizing and Maintaining Zeke

Exit Options Exit options are local and global generation options that control exits.

To access the exit options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the local or *GLOBAL GENOPT, then locate the exits options. In ISPF, you can use the LOCATE EX command to locate the first exits option, or issue CATEGORY ON to sort the display by categories and scroll to the Exits section.

2

Review the exits options and their default values.

3

Update each exits option according to your requirements: For many options, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. For other options, you might be required to specify a numeric or character value (e.g., a name) or you can keep the default value.

4

Options related to security exits can be reloaded using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details. Most other exits options require you to re-cycle Zeke using ZKILL TRACK or COLD.

General Options General options are local and global generation options that control a variety of functions.

To access the general options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the local or *GLOBAL GENOPT, then locate the general options. In ISPF, you can use the LOCATE GEN command to locate the first general option, or issue CATEGORY ON to sort the display by categories and scroll to the General section.

2

Review the general options and their default values.

3

Update each general option according to your requirements: For many options, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. 309

ASG-Zeke Scheduling for z/OS User’s Guide

For other options, you might be required to specify a numeric or character value (e.g., a name) or you can keep the default value. 4

Some general options can be reloaded using the ZRELOAD GENOPT operator command. Others might require you to re-cycle Zeke using ZKILL TRACK or COLD. See “Reloading GENOPTS” on page 295 for details.

The following sections discuss some important general options and also indicate the additional related generation options that might be required to support a particular Zeke environment or configuration.

Network Registration ID The Netregid generation option specifies the unique DMS logical Netregid (network registration ID) used to identify the local Zeke system. Remote events dispatched by other Zeke systems to be monitored by this Zeke system specify this Netregid in the remote event’s Target field. If you update this option, re-cycle Zeke using the ZKILL TRACK or COLD command.

Inter-product Communications Zeke can communicate with other ASG products (e.g., Zebb) via API interfaces. You can control whether EMR messages are enabled or suppressed. You can set to ZPRDcom option to indicate whether to activate inter-product communication (i.e., communication with other ASG products via APIs.). If you do so, for example, any added or deleted events in Zeke are reflected in Zebb. A COPY or COPYALL performed in Zeke also are reflected in Zebb. Note:

If ZPRDcom is set to 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 (e.g., CICS, TSO, etc.) that can add or delete events. If you update the ZPRDcom option, you must re-cycle Zeke using ZKILL TRACK or COLD.

Inter-product EMR Messages You can set the ZPRDsemr option to indicate whether to suppress inter-product EMR messages. If you activate this option, messages regarding EMR changes are not sent to other products (e.g., Zebb) and only SQR messages are set. Otherwise (if this option is set to N), both EMR and SQR messages are sent.

310

7 Customizing and Maintaining Zeke

Note:

For this option to effective, the ZPRDcom generation option also must be set to Y.

Building EDB Indexes If you commonly add events to the schedule using the ZADD command (especially when based on event or jobname), EDB indexes help to improve Zeke performance. Zeke provides these options for building EDB indexes: Option

Description

DSPIndex

Indicates whether to build a data space for a full EDB index for each event in the Zeke database. These are the valid values: Y

Default. Build a full EDB index for each event in a data space. The maximum size is 2 GB. ASG recommends this setting for large databases for these reasons: • Improves ZADD command processing • Improves online browsing and retrieval of jobs • Enables the PATH, PREDECESSOR, and SUCCESSOR functions from the EMR Note: The data space is named IX and is owned by the OASIS address space (which enables it to be maintained across a ZKILL WARM).

N EDBindex

Do not build a full EDB index.

Indicates whether to build a reduced version of the EDB index in core. These are the valid values: Y

Default. Build a reduced version of the EDB index in core. This process requires approximately 20 bytes of above-the-line CSA storage for each event in the Zeke database. This setting can improve speed and efficiency of ZADD command processing. Note: This setting is required to track externally submitted jobs (i.e., jobs whose JCL is contained in the JES job queue).

N

Do not build a reduced version of the EDB index in core.

311

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

Setting both the DSPIndex and EDBindex options to Y can help to maximize the efficiency of ZADD processing. If you update either of these options, you must re-cycle Zeke using ZKILL TRACK or COLD.

Database Options The MultSys 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. If more than one system is sharing the same Zeke database, these generation options must be set to the same values for each Zeke system sharing the database: •

Posid

•

Posidend

•

TrigDt

•

Trigjob

•

Wktrgdn

If you update either of these options, you must re-cycle Zeke using ZKILL TRACK or COLD.

JCL Options JCL options are local and global generation options that control JCL sources and processing.

To access the JCL options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the local or *GLOBAL GENOPT, then locate the JCL options. In ISPF, you can use the LOCATE JCL command to locate the first JCL option, or issue CATEGORY ON to sort the display by categories and scroll to the JCL section.

2

Review the JCL options and their default values.

3

Update each JCL option according to your requirements: For many options, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it.

312

7 Customizing and Maintaining Zeke

For other options, you might be required to specify a numeric or character value (e.g., a name) or you can keep the default value. 4

Some JCL options can be reloaded using the ZRELOAD GENOPT operator command. Others might require you to re-cycle Zeke using ZKILL TRACK or COLD. See “Reloading GENOPTS” on page 295 for details.

The following sections discuss some important JCL options and also indicate the additional related generation options that might be required to support a particular Zeke environment or configuration.

JCL Source Options You can store JCL for events in the Zeke database; however, this is not necessary if you have a JCL library facility. Zeke can retrieve JCL from a variety of JCL library facilities (e.g., Bim-Edit, CMS, CA Librarian, CA Panvalet, and PDS). Before you can retrieve JCL for an event, you must first define your installed JCL libraries to Zeke. You use the JCL generation options to identify to Zeke the JCL libraries to be used. Each library type requires some steps to be performed by the systems programmer. See the section on JCL library support in your ASG-Zeke Scheduling for z/OS Installation Guide for information on link-editing the third-party libraries or installing PDS or CMS support. Depending on the JCL libraries you use, update these options: Library

Generation Options

Librarian

Librarian support enables Zeke to retrieve JCL from the Librarian database and submit the JCL for processing by the operating system. If you do not know your Librarian number or codes, contact your Librarian vendor. Update these fields when you install Zeke, and again if you update Bim-Edit (you also must link-edit the Librarian library interface and provide file information for the Librarian library): FairMod

Used only for Librarian 3.1 or later. Librarian modification number.

FairOpn

Used only for Librarian 3.1 or later. Librarian options code.

FairRec

Used only for Librarian 3.1 or later. Librarian record code.

LibrBlk

Librarian library block size. Zeke uses this number to determine the amount of storage required for Librarian subroutines. The default value is 12800.

313

ASG-Zeke Scheduling for z/OS User’s Guide

Library

Generation Options LibrDtf

Bim-Edit

Condor

Panvalet

DD name of the Librarian library Zeke uses to retrieve JCL. The default value is OMITTED. (The name LIBRJCL is reserved and cannot be used.)

Update these fields when you install Zeke, and again if you update Bim-Edit (you also must link-edit the Bim-Edit library interface): BimAppl

Optional. Bim-Edit application name (up to eight characters long) to be associated with Zeke.

BimPasw

Unique BIM password (up to six characters long).

BimUid

User ID Zeke passes to Bim-Edit to receive JCL. The default value is OMIT.

Update these fields when you install Zeke, and again if you update Condor (you also must link-edit the Zeke/Condor support program): CondrVer

Your Condor version number. The default value is 1.

CondrLb

Library that Zeke will pass to Condor to receive JCL. The default value is OMIT.

If Panvalet support is installed, Zeke can search for JCL in up to 99 Panvalet libraries. Update these fields when you install Zeke, and again if you update Panvalet (you also must link-edit the Panvalet support program): PanDisk

Code indicating the DASD type of the disk where the Panvalet library resides. This field cannot contain blanks. These are the valid values: FBA 3340 3350 3375 3380 (default) 3390 3331 (3330-11 disk devices)

314

PanDtf

DD name of the first (or only) Panvalet library to be searched. If a value is not entered, Zeke searches for DD names of PANDDxx. The default value is OMITTED.

PanMem

Amount of memory Zeke requires to obtain the Panvalet work area. The default value is 0240.

7 Customizing and Maintaining Zeke

Library

Generation Options

PDS

Pdsdd

DD name in the Zeke started task procedure of the partitioned dataset to retrieve JCL.

VM/CMS JCL

Userid

Name of the CMS JCL machine.

In the DefJcl option, specify the default JCL source type. The default JCL source type is used if none is specified on the EMR. These are the valid values: Code

Meaning

BIM

Bim-Edit

CMS

CMS file

CONDOR

Condor

LIBR

CA Librarian

PAN

CA Panvalet

PDS

Partitioned dataset member

ZEKE

Zeke JCL

Z14C

Source not supported by Zeke (JCL is supplied by the ZEKE14C user exit)

In the JCL1 generation option, specify one of the JCL sources listed above. You can enter additional JCL sources in the remaining fields JCL2 through JCL5. These options determine the JCL fields that are displayed on the Event Master Definition screen.

JOB Card Override These generation options enable information on the JOB card for Zeke-dispatched jobs to be overridden using information from the event’s EMR.

315

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

Zeke processes all options, except RepJName, after any ZEKE14B/N and ZEKE14E/N user exits are invoked. Zeke processes the RepJName option before any user exits have been invoked. Option

Description

RepJGrp

Indicates whether the GROUP= keyword on the JOB card should be inserted (or replaced) by the Secgroup value from the event’s EMR. These are the valid values:

RepJName

RepJSEnv

N

(Never). Default. Do not modify the JOB card.

A

(Always) If the JOB card already has a GROUP= value, replace it with the Secgroup value from the EMR; if the JOB card does not have a GROUP= keyword, add it with the Secgroup value from the EMR. If a Secgroup value is not specified in the EMR, the JOB card is not modified.

C

(Conditional) If the JOB card already has a GROUP= value, do not modify it; if the JOB card does not have a GROUP= keyword, add it with the Secgroup value from the EMR. If a Secgroup value is not specified in the EMR, the JOB card is not modified.

Indicates whether the jobname on the JOB card should be replaced by the jobname from the event’s EMR. These are the valid values: N

Default. Do not modify the JOB card.

Y

Replace the jobname on the JOB card. (Only the first JOB card in the JCL is modified.) If the jobname from the EMR is longer than the jobname on the JOB card, Zeke makes room for the longer name by splitting the card at a comma that separates operands.

Indicates whether to allow Zeke to insert (or replace) the SCHENV keyword on the job card before the job event is submitted to JES. (Zeke retrieves the SCHENV value from the SQR.) Note: Depending on how you set this value, the SCHENV value could differ in a job event’s SQR and its JCL. In this case, Zeke schedules and dispatches the event according to the environment specified in the SQR. If a different environment is specified on the job card (and is undefined or inactive), the job is held in the JES input queue or fails with a JCL error. If a job event has a JCL source of JESQ, Zeke does not modify the job card. The value the RepJSEnv option is assumed to be N. These are the valid values:

316

7 Customizing and Maintaining Zeke

Option

Description

RepJUser

N

Default. (Never) Zeke does not insert/replace the SCHENV keyword on the job card.

A

(Always) Zeke always inserts/replaces the SCHENV keyword on the job card.

C

(Conditional) Zeke inserts the SCHENV keyword on the job card only if no keyword exists. Zeke does not replace an existing keyword.

Indicates whether the USER= keyword on the JOB card should be inserted (or replaced) by the user ID from the event’s EMR. These are the valid values: N

Default. (Never) Do not modify the JOB card.

A

(Always) If the JOB card already has a USER= value, replace it with the user ID value from the EMR; if the JOB card does not have a USER= keyword, add it with the user ID value from the EMR. If a user ID is not specified in the EMR, the JOB card is not modified.

C

(Conditional) If the JOB card already has a USER= value, do not modify it; if the JOB card does not have a USER= keyword, add it with the user ID value from the EMR. If a user ID is not specified in the EMR, the JOB card is not modified.

Note:

RACF surrogate processing must be set up before the RepJGrp and RepJUser options can be used. See the ASG-Zeke Scheduling for z/OS Installation Guide for details.

Job Networking Options These generation options are related to job networking: Option

Description

Posid

Indicates whether to assign a unique POSID (positive event ID) to each Zeke-controlled job event. The job is tracked by its jobname and assigned POSID until the job is done. Note: All Zeke systems that share the same database must have the same Posid value. These are the valid values: N

Do not assign a unique ID and track jobs by jobname only.

317

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description Y

Default. Assign a unique POSID (positive event ID) to each Zeke job event. The job is tracked by its jobname and the assigned POSID until the job is done. If this option is set to Y, 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. 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. When this option is set to Y, only the first job of an event is considered a Zeke job. All other jobs in the same event are considered nonZeke jobs; therefore, each job should be defined in a separate event. Note: A POSID cannot be used with the JCL sources CMS or JCLMAN. If using either of these services, set this option to N or set the Control field in the EMR to N for those jobs to be submitted from these sources. Also, to override the Posid option for a specific event, use the Control field on the EMR. When Control is set to N, Zeke does not recognize the event as Zeke-controlled, and marks the job as EOJ at dispatch. If you update this option, you must re-cycle Zeke. Posidend

Indicates whether Posid information is placed at the beginning or end of Zeke-controlled jobs. Note: All Zeke systems that share the same database must have the same Posidend value. These are the valid values: Y

318

POSID is placed at the end of the job (as the last step).

7 Customizing and Maintaining Zeke

Option

Description N

Default. POSID is placed at the start of the job (as the first step).

For most jobs, the POSID is acceptable in either location; however, there are cases where one location could 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 (e.g, JOBLIB), then the job will fail if Posidend is set to N. If a job has in-stream data (i.e., SYSIN DD *) containing an imbedded job, then the job will fail if Posidend is set to Y. If a remote job is dispatched to another Zeke system via DMS, then the Posidend generation option on the execution system governs POSID placement. If a remote job is dispatched to another system through NJE, then the dispatching Zeke’s Posidend generation option governs POSID placement. Zekectl

Indicates whether Zeke inserts //*ZEKECTL comment statements into the JCL when submitting a job. This option is required to enable Zeke’s ThruPut Manager interface (see Appendix B, “Interface to ThruPut Manager,” on page 431 for details). If you do not use ThruPut Manager, these comment statements still can be useful because they enable Zeke event information to be referenced in JES job logs. These are the valid values: Y

Default. Zeke inserts //*ZEKECTL comment statements into the JCL when submitting a job. If the Posid generation option is set to Y, then the comment statements are inserted in front of the ZEKECTL POSID job step. The value of the Posidend generation option determines whether the comment statements are inserted at the beginning or end of the JCL.

N

Zeke does not insert //*ZEKECTL comment statements.

Message Options Message options are mostly local generation options that control the occurrence of alarms and the issuing of messages related to Zeke system activities. For example, you can enable console alarms, specify whether a console message is issued under certain circumstances, and control message routing.

To access the message options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the local or *GLOBAL GENOPT, then locate the message options. In ISPF, you can use the LOCATE MES command to locate the first message option, or issue CATEGORY ON to sort the display by categories and scroll to the Messages section. 319

ASG-Zeke Scheduling for z/OS User’s Guide

2

Review the message options and their default values.

3

Update each message option according to your requirements. Generally, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. For a few options, you might be required to specify a numeric value (e.g., a time, interval, or a percentage) or you can keep the default value.

4

Most message options can be reloaded using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details.

Scheduling Options Scheduling options are global generation options that you can use to control Zeke event scheduling.

To access the scheduling options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the *GLOBAL GENOPT, then locate the scheduling options. In ISPF, you can use the LOCATE SCH command to locate the first scheduling option, or issue CATEGORY ON to sort the display by categories and scroll to the Scheduling section.

2

Review the scheduling options and their default values.

3

Update each scheduling option according to your requirements. Generally, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. For some options, you might be required to specify a numeric value (e.g., a time, interval, or a percentage), or you can keep the default value.

4

320

Scheduling options can be reloaded using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details.

7 Customizing and Maintaining Zeke

These tables discuss some of the most important options used to control Zeke dispatching and also describe the additional related generation options that might be required to support a particular scheduling environment or configuration: Option

Description

DropSel

Indicates whether that you want the SCHEDULE function to drop all past, completed events when selection parameters are included with the SCEHDULE ACTIVATE command. Otherwise, only past, completed events that match the selection parameters are dropped. If the SCHEDULE function is run without any selection parameters, then the DropSel option has no effect. These are the valid values: N

Default. The SCHEDULE function will drop from the schedule all past, completed events regardless of whether they match the selection parameters included with the SCHEDULE ACTIVATE command.

Y

The SCHEDULE function will drop from the schedule only past, completed events that match the selection parameters included with the SCHEDULE ACTIVATE command.

Caution! Specifying this option enables past, completed events to remain in the schedule indefinitely (which could impact performance). MultAp

MultGr

Specifies how to handle a ZADD by application ID when multiple events have the same application ID. These are the valid values: A

Add all the matching events.

F

Default. Add the first matching event and end the search; this is the most efficient.

N

Do not add any events; list all matching events on the console.

Specifies how to handle a ZADD by group ID when multiple events have the same group ID. These are the valid values: A

Add all the matching events.

F

Default. Add the first matching event and end the search; this is the most efficient.

N

Do not add any events; list all matching events on the console.

321

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description

MultHit

Indicates whether an event is to be scheduled multiple times when there is a nonworking day. This option determines the default value for the Multhit field on the EMR. These are the valid values:

MultJn

MultEn

MultUs

N

Allow only one SQR.

Y

Default. Allow multiple SQRs. For example, if Monday is a holiday, then Zeke schedules the jobs to run twice on Tuesday, if they are supposed to run on Monday and Tuesday.

Specifies how to handle a ZADD by jobname when multiple events have the same name. These are the valid values: A

Add all the matching events.

F

Default. Add the first matching event and end the search; this is the most efficient.

N

Do not add any events; list all matching events on the console.

Specifies how to handle a ZADD by event name when multiple events have the same name. These are the valid values: A

Add all the matching events.

F

Default. Add the first matching event and end the search; this is the most efficient

N

Do not add any events; list all matching events on the console

Specifies how to handle a ZADD by user ID when multiple events have the same user ID. These are the valid values: A

add all the matching events.

F

Default. Add the first matching event and end the search; this is the most efficient.

N

Do not add any events; list all matching events on the console.

Note: The options MultAp, MultGr, MultJn, MultEn, and MultUs work together to determine which jobs are added with the ZADD command. If multiple criteria are used on the same ZADD command, then the option with the most restricted value is applied. For example, if a ZADD by jobname and application ID is requested and MultJn is set to A (all) and MultAp is set to N (i.e., none), then no events are added since the most restricted is none.

322

7 Customizing and Maintaining Zeke

Option

Description

LoadComm

Indicates whether to load work centers to the schedule queue table (SQT) storage. ASG recommends that you activate this option if you use work centers that are loaded into the schedule queue at schedule load time. This setting 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 operator command. These are the valid values: N

Do not load work centers to the schedule queue table.

Y

Default. Load work centers to the schedule queue table. This option loads the work center more efficiently, but requires more above-the-line common storage. Note: This option must be set to Y to access or complete work centers from an OpsCentral console.

Note: This option is set to Y, a work center event is flagged as late if the current time is greater than the event’s ‘late end’ time and the completion process has not started on the event (i.e., if it is not in a Pending or Success status). If this option is set to N, the ‘late end’ time does not cause a work center event to enter a late status. To load work centers to the current schedule queue, enter ZRELOAD SCHD on the Command line, and press Enter. Nonwkday

Specifies whether to schedule an event if the OCCURS clause is true for a nonworking day. This option sets the default value used on the EMR (Nwday field). These are the valid values: A

Default. Schedule the event after the nonworking day. For example, if Monday is a holiday, all events scheduled for Monday are scheduled for Tuesday.

B

Schedule the event before the nonworking day

N

Do not schedule the event

O

Schedule the event on the nonworking day

323

ASG-Zeke Scheduling for z/OS User’s Guide

Option

Description

Refevent

Specifies whether REFEVENT references from one EMR to another EMR by event number are allowed. A REFEVENT reference defined in an EMR schedules the event according to the calendar (including nonworking days) and OCCURS clause of another event. (You can specify the event that you want to reference either by event number or event name.)

Caution! Event numbers are unique; however, because Zeke assigns the event numbers automatically and can reassign available, previously used numbers to new events, ASG recommends you reference other events by event name to avoid unintended references. These are the valid values: A

Default. Allow. REFEVENT references from one event to another by event number are valid.

F

Fail. A REFEVENT reference from one event to another by event number is not allowed. The event is not scheduled.

W

Warn. Issue a warning when a REFEVENT reference from one event to another by event number is found. The event is scheduled normally.

Security Options Security options are global generation options that manage security.

To access the security options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the *GLOBAL GENOPT, then locate the security options. In ISPF, you can use the LOCATE SEC command to locate the first security option, or issue CATEGORY ON to sort the display by categories and scroll to the Security section.

2

Review the security options and their default values.

3

Update each security option according to your requirements: For some options, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. For other options, you might be required to specify a numeric or character value (e.g., an ID) or you can keep the default value.

324

7 Customizing and Maintaining Zeke

4

Security options can be reloaded using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details.

Before setting the security options, be sure to review Chapter 9, “Security,” on page 369.

Trace Options Trace options are local generation options that enable trace messages to be generated for many different types of system activities. You select each type of information to log by enabling the corresponding trace option. Trace messages are logged to a data space that can be dumped to a dataset and used in troubleshooting. See the ASG-OASIS for z/OS Reference Guide for more information on data space logging.

To access the trace options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the desired local GENOPT, then locate the Traces options. In ISPF, you can use the LOCATE TRA command to locate the first Traces option, or issue CATEGORY ON to sort the display by categories and scroll to the Traces section.

2

Review the Traces options and their default values.

3

Update each Traces option according to your requirements: Specify Y to enable trace messages to be logged to a data space for the corresponding function. Or

Specify N to disable trace messages for the corresponding function. 4

Traces options can be reloaded using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details.

User Interface Options User interface options are mostly global generation options that affect the ISPF and online facilities.

To access the user interface options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the local or *GLOBAL GENOPT, then locate the user interface options.

325

ASG-Zeke Scheduling for z/OS User’s Guide

In ISPF, you can use the LOCATE USER command to locate the first user interface option, or issue CATEGORY ON to sort the display by categories and scroll to the User Interface section. 2

Review the user interface options and their default values.

3

Update each user interface option according to your requirements: For many options, you enable or disable the option by specifying Y to enable the corresponding function or N to disable it. For other options, you might be required to specify a numeric or character value (e.g., a name) or you can keep the default value.

4

You can reload user interface options using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details.

Variables Options Variables options are global generation options that activate variable substitution.

To access the variables options 1

Follow the procedure in “Editing a GENOPT” on page 290 to access the *GLOBAL GENOPT, then locate the variables options. In ISPF, you can use the LOCATE VAR command to locate the first variables option, or issue CATEGORY ON to sort the display by categories and scroll to the Variables section.

2

Review the variables options and their default values.

3

Update each variables option according to your requirements. You can enable or disable the option by specifying Y to enable the corresponding function or N to disable it. The SubData option enables variable substitution to be performed in your JCL before the job is submitted to JES. If this option is not activated, errors will occur in jobs submitted with Zeke and OASIS variable names in the JCL. The Jclcol71 option is used to limit variable substitution to columns 1 through 71.

4

You can reload variables options using the ZRELOAD GENOPT operator command. See “Reloading GENOPTS” on page 295 for details.

Before setting the variables options, see Chapter 8, “Variables,” on page 345. 326

7 Customizing and Maintaining Zeke

Defining Schedule Download Agents Zeke enables you to download a subset of SQRs in the Zeke schedule to a 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 ===>

Schedule Download Agents List

Row 1 of 3 Scroll ===> PAGE

NETREGID ===> Primary Commands: ADD DELETE EDIT END Line Commands: D - Delete E - Edit NETREGID Description ****************************************************************************** UNIXAGNT ZEKE AGENT UNIX ******************************* Bottom of data *******************************

3

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Add a new agent

1 Enter ADD on the Command line. 2 Enter the Netregid on the NETREGID line. 3 Press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 4.

Update an existing agent for which you know the Netregid

1 Enter EDIT on the command line. 2 Enter the Netregid on the NETREGID line. 3 Press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 5.

Update an existing agent Enter E next to the appropriate Netregid and press Enter. The for which you do not know Schedule Download Agent Specification screen is displayed. the Netregid Go to step 5.

327

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Delete an agent for which you know the Netregid

1 Enter DELETE on the Command line. 2 Specify the Netregid on the NETREGID line. 3 Press Enter. The Schedule Download Agent Specification screen is displayed. Re-enter DELETE on the Command line to confirm. The Netregid that you selected is deleted and the Schedule Download Agents List screen is displayed. This procedure is complete. 1 Enter D next to the appropriate Netregid and press Enter. The Schedule Download Agent Specification screen is displayed.

Delete an agent for which you do not know the Netregid

2 Re-enter DELETE on the Command line to confirm and press Enter. The Netregid that you selected is deleted and the Schedule Download Agents List screen is displayed.

The Schedule Download Agent Specification screen is displayed: ASG-Zeke Command ===>

Schedule Download Agent Specification

Primary commands: CANCEL END NETREGID: NTAGENT

4

Description:

In the Description field, enter the description of the agent and press Enter. Note:

You cannot 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 ===>

Schedule Download Agents List

Agent added Scroll ===> PAGE

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 ********************************

328

7 Customizing and Maintaining Zeke

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 utility program or the online, as in this procedure.

To obtain a new operating password 1

Verify that you have a signed License Agreement.

2

Obtain this 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 (e.g., 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

Contact ASG Customer Support.

4

After you receive your new password, log on to the Zeke online facility.

329

ASG-Zeke Scheduling for z/OS User’s Guide

5

From the Zeke Primary Menu, enter 4.2 on the Option line. The Operating Password Information screen is displayed: ASG-Zeke Command ===>

Operating Password Information

Primary Commands:

BROWSE

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

Enter EDIT on the Command line, and press Enter.

7

Specify 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.

Database Maintenance Database maintenance includes these tasks: •

Allocating and cataloging datasets.

•

Backing up the database. Note:

ASG recommends you use the BACKUP command of the ZEKE utility program to back up your database at least daily.

330

•

Moving or enlarging a database.

•

Recovering from a hardware failure.

•

Recovering the contents of a destroyed database.

•

Running Zeke using electronic vaulting.

7 Customizing and Maintaining Zeke

For an existing database, you can generate a database status report that provides details about the database (e.g., its size and event capacity, as well as the dates it was created, last backed up, and last restored). See the ASG-Zeke Scheduling for z/OS Reference Guide for details.

Creating the Zeke Databases (Primary and Vault) Note:

You must perform this procedure before using Zeke for the first time. You create the Zeke databases using the CREATE function of the ZEKE utility program. 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. Note:

Because it is independent of the operating system, the ZEKE utility program requires that OASIS is active. You can activate OASIS without Zeke being active. This is a normal condition during the process of installing Zeke.

To create the Zeke databases 1

Start the OASIS started task, using this syntax: START procname,S=subsys,OASIS='(aa,bb)'

where: procname is the name of the OASIS start-up procedure. subsys is the OASIS subsystem name. (aa,bb) is the OASISxx options member name suffix and console option. 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 this sample. See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed information on the CREATE function and parameters.

331

ASG-Zeke Scheduling for z/OS User’s Guide

This job allocates and catalogs the dataset:

//ZFRMT //ZALLOC //ZNEW // //* //ZUTL //ZEKENEW //ZEKECAT //SYSIN CREATE /*

3

332

,MSGLEVEL=(1,1),CLASS=A PGM=IEFBR14 DSN=ZEKE.DATABASE,DISP=(NEW,CATLG), UNIT=SYSDA,VOL=SER=PERMVL,SPACE=(CYL,(10),,CONTIG)

EXEC DD DD DD

ZEKEUTL,PARM=’SUBSYS=ZDEV’ DSN=ZEKE.DATABASE,DISP=OLD DSN=ZEKE.DATABASE,DISP=OLD *

For electronic vaulting, run the CREATE function using a jobstream similar to this sample. See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed information on the CREATE function and parameters. 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 /*

4

JOB EXEC DD

EXEC DD DD EXEC DD 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

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.

7 Customizing and Maintaining Zeke

Note:

Regardless of the value for the ESIActv generation option, an external security call always is made to the SAF Security Interface using the resource class of Z$CATAL with a resource name of CREATE## and ALTER authority. If this class information is not defined in your security product, then the SAF action and return code are determined by your security product. If you do not have a security product using SAF, then Zeke’s internal security (which allows the request by default) is used. If you have a ZEKE15B user exit in place, then the exit can override any external security return code (depending on how you have coded ZEKE15B).

Backing Up the Zeke Database You back up the Zeke database to a tape or disk file using the BACKUP function of the ZEKE utility program. The BACKUP command copies the contents of the Zeke database in case it must be restored later. Use the BACKUP command to back up your database at least once daily. ASG recommends backing up the database prior to each scheduling run. The database is copied in these two formats: •

Logical (default). The database copy follows the pointers to the different types of database records and groups all the elements of an event together. Two logical backups can be merged into one database.

•

Physical. The database copied to tape is an exact copy of the database on disk.

The Zeke database is enqueued for the duration of the physical backup. ASG recommends you schedule the backup during the time period with the least CPU activity. Caution! The Zeke database is not an ordinary sequential file. Most third-party backup/copy utilities do not back up the Zeke database successfully. Be sure to use only the ZEKE utility program’s BACKUP and RESTORE functions for this purpose. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on the BACKUP function and parameters.

To back up the Zeke database 

Run a job to back up the Zeke database. See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed information on the BACKUP function and parameters.

333

ASG-Zeke Scheduling for z/OS User’s Guide

The Zeke database BACKUP DD name is ZEKEBK. In the ZEKEUTL jobstream, enter the Zeke backup file dataset name. Because this is a sequential file, it does not matter how you allocate it. When the Zeke backup process writes to the file, it will alter the LRECL and block size of the file as needed. This is sample JCL to back up the Zeke database to disk:

//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 /*

Note:

Regardless of the value for the EsiActv generation option, an external security call always is made to the SAF Security Interface using the resource class of Z$CATAL with a resource name of BACKUP## and ALTER authority. If this class information is not defined in your security product, then the SAF action and return code are determined by your security product. If you do not have a security product using SAF, Zeke’s internal security (which allows the request by default) is used. You can use the parameter DATASPACE with the BACKUP function to improve backup processing performance.

Restoring the Zeke Database You restore the Zeke database from a backup using the BACKUP, CREATE, and RESTORE functions of the ZEKE utility program. The backup copy must have been produced by the BACKUP function of the ZEKE utility program. You can use this procedure to recover the contents of a destroyed database and to move and/or enlarge the database. Caution! Do not use the RESTORE function to restore an active database. These are the methods you can use to restore the database from a backup:

334

•

Logical (default). This method reorganizes the database, which enables you to restore the database to a larger dataset or merge two databases.

•

Physical. This method restores the physical portion of the backup to the disk space, which results in an exact copy of the backed up database.

7 Customizing and Maintaining Zeke

Before you perform this procedure, be sure to allocate contiguous space in cylinders for the new Zeke database dataset (i.e., no secondary extents). Allocate more space if you are enlarging the database. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information on determining the Zeke database size. Note:

If a Zeke database containing SQRs that were downloaded to Zeke Agent is restored from a backup, either the RESTORE NOSCHED option must be used or the SQRs must be removed from the Zeke Agent that is maintaining copies of them.

To restore the Zeke database 1

Run a job to back up the Zeke database or use a previous backup. See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed information on the RESTORE function and parameters. This sample JCL illustrates backing up the database:

//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) *

2

Terminate Zeke by issuing the ZKILL COLD command. Do not use the ZKILL WARM or ZKILL TRACK command.

3

Terminate any other active Zeke systems that share the database. Caution! Do not use the OASIS STOP command.

4

Terminate any other OASIS-supported ‘Z’ products that share the OASIS subsystem.

5

Be sure that all products have been terminated, and terminate OASIS using the XKILL command.

6

Allocate a new Zeke database and rename the old database (as a precautionary measure).

7

Restart OASIS. OASIS becomes active without activating Zeke.

335

ASG-Zeke Scheduling for z/OS User’s Guide

8

Run a ZEKE batch utility job using the CREATE control statement to allocate a new Zeke database. ZEKENEW and ZEKECAT must both point to the new database. This is a sample of the database CREATE jobstream:

//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 DATABASE INITIALIZATION COMPLETE is displayed when the job is complete. 9

Perform a logical restore. This sample JCL restores an existing database:

//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.

336

10

Edit the started task procedure and change the ZEKECAT DD statement to point to the new database (if applicable).

11

If Zeke vaulting is being used, preallocate the vault database to be contiguous and have the same attributes (e.g., size, cylinder boundary, device type) as the new database. Copy (i.e., DITTO) the Zeke database to the Zeke vault dataset.

12

ASG recommends that you re-cycle OASIS at this point.

13

Start Zeke.

7 Customizing and Maintaining Zeke

Moving the Vault Database At times, it might 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 safeguard prevents Zeke from being initialized with the wrong dataset, which could cause the vault to become out of synchronization 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 these procedures.

To move the vault database (recommended) 1

Create the new vault database as instructed in “Creating the Zeke Databases (Primary and Vault)” on page 331.

2

Using the ZEKE utility program, disable the old vault by specifying VAULT DISABLE in the SYSIN (ZEKEVLT DD points to the original vault DSN). This action clears the vault dataset name and volume information in the primary database.

3

Terminate all active Zekes sharing this primary database/vault database pair (using the ZILL COLD or ZKILL TRACK command).

4

Restart your Zeke with the ZEKEVLT DD pointing to the new vault DSN.

The first Zeke that starts also initializes the new vault dataset from the primary database and writes the new dataset name and volume information to the primary database.

To move the vault database (emergency procedure) 1

Create the new vault database as instructed in “Creating the Zeke Databases (Primary and Vault)” on page 331.

2

Enter the ZDISABLE VAULT operator command from any Zeke that shares the old vault dataset. Vaulting is then disabled on all systems sharing the old vault.

3

Zeke is now running without electronic vaulting recovery services. ASG recommends that you schedule hourly database backups 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: a

Terminate all active Zekes sharing the database (using the ZKILL COLD command).

337

ASG-Zeke Scheduling for z/OS User’s Guide

b

Start Zeke with ZEKEVLT DD pointing to the new vault DSN.

The first Zeke starts also initializes the new vault dataset from the primary database.

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. Zeke’s 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 (vault) databases must have the same allocation size. For example, if a database allocates 250 contiguous cylinders for the primary Zeke database, then the Zeke vault database must have 250 contiguous cylinders as well. The vault 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 this procedure. If you must recover more quickly than you can copy the Zeke database, use the partial recovery procedure; however, you will have to bring Zeke back down at the first opportunity to complete the recovery. Note:

ASG strongly recommends 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 340 for details). Otherwise, issue the ZKILL COLD command. If this fails, cancel Zeke.

2

Use the OASIS batch utility program to issue the STOP ZEKE command. Note:

If you see message X00224E, this does not indicate a problem; it simply means that Zeke code has already been pulled for the subsystem. 3

338

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.

7 Customizing and Maintaining Zeke

4

Copy (i.e., IEBGENER or FDR) the undamaged vault database to the new dataset on the same DASD device type.

5

Change the started task JCL so that ZEKECAT points to the newly copied database and ZEKEVLT remains pointing to the undamaged vault database.

6

Start Zeke.

7

Resume processing.

To partially recover electronic vaulting 1

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.)

2

Terminate Zeke by issuing the ZKILL COLD command. If this fails, cancel Zeke.

3

Use the OASIS batch utility program to issue the STOP ZEKE command. Note:

If you see message X00224E, this does not indicate a problem; it simply means that the Zeke code has already been pulled for the subsystem. 4

Rename the vault dataset.

5

Change the started task JCL so that ZEKECAT points to the renamed vault database and comment out the ZEKEVLT DD.

6

Start Zeke. Zeke issues message Z0129R during startup, which is normal.

7

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 1).

8

Resume processing.

9

Zeke is now running without electronic vaulting recovery services. Schedule hourly backups of the Zeke database until you can restore electronic vaulting.

339

ASG-Zeke Scheduling for z/OS User’s Guide

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.

b

Format the new dataset as a database using the batch utility CREATE function.

c

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.

d

Change the started task JCL by adding the ZEKEVLT DD to point to the newly created database.

e

Start Zeke. The first Zeke system that is started initializes the vault dataset from the primary database.

f

Resume processing.

Continuous Job Tracking Zeke can track relevant system and event activities during periods when both the Zeke and OASIS subsystem have been terminated. This capability 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 you terminate Zeke (and even OASIS), the system activities are recorded. When you restart Zeke, 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.

340

7 Customizing and Maintaining Zeke

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 the section on ZKILL in the ASG-Zeke Scheduling 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 these conditions: —

If Zeke is restarted on a different database than it is currently using.

—

If the database is 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.

Note:

When you upgrade to a different PTF level within the same release, some PTFs could require you to terminate Zeke (either before or after applying the maintenance). For these PTFs, the PTF instructions will indicate whether you can use ZKILL TRACK or ZKILL WARM instead of ZKILL COLD.

SMF Recording Mode This section provides considerations for using SMF recording mode.

Limitations These Zeke and OASIS services are suspended while Zeke is in tracking mode (i.e., has been shut down using ZKILL TRACK): •

Auto replies for jobs that are active when Zeke enters tracking mode (even after Zeke is restarted)

•

Resource management for jobs that are active when Zeke enters tracking mode (even after Zeke is restarted)

•

JCL error tracking 341

ASG-Zeke Scheduling for z/OS User’s Guide

•

NOTDURING (WHEN condition) processing

•

Zeke condition code processing for any job active while Zeke is in recording mode. Condition code processing cannot resume for an affected 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.

These services are not available if OASIS also is terminated: •

Zeke and OASIS batch utilities

•

Report Writer

Database Considerations If multiple Zeke systems share a database, consider these points: •

A Zeke in record mode does not make schedule updates. The other Zekes are 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 are 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 this warning: Z48R4W Zeke SMF Recording: 2.0 MB ECSA remaining Z48R5W Zeke SMF recording will halt with 1.0 MB ECSA remaining 342

7 Customizing and Maintaining Zeke

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 this 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 is used—a 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.

//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 2012/006 000001 16:54:01 16:54:11 16:54:11 16:54:01 2012/006 000002 16:54:01 16:54:11 16:54:11

VER

00000

00000

343

ASG-Zeke Scheduling for z/OS User’s Guide

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 to reload these modules. If OASIS is terminated also, all OASIS modules are unloaded so that maintenance can 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 can 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 6.0 Z600A000 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

344

Chapter 8:

Variables

8 Variables are user-defined keywords that represent values, and enable Zeke to carry out a wide variety of specialized operations automatically. With variables, you can automate many important tasks (e.g., JCL modifications, job triggering, and console response handling). This chapter discusses these topics: Topic

Page

Zeke Variables Naming Zeke Variables Setting Zeke Variable Values Maintaining Variable Documentation

346 346 346 351

OASIS Variables Naming OASIS Variables Setting OASIS Variable Values Temporary OASIS Variables

355 357 357 358

System-dependent Variables

359

Uses for Zeke Variables 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

359 360 361 362 363 366 366

345

ASG-Zeke Scheduling for z/OS User’s Guide

Zeke Variables A Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned numeric or character value. Zeke supports these types of variables: •

Zeke variables

•

OASIS variables (see the ASG-OASIS for z/OS Reference Guide)

•

System-dependent variables

Naming Zeke Variables ASG recommends that you name variables according to the related jobstream, application, or function. Standard naming conventions can help prevent questions about the purpose of a specific variable. For example, for a restart variable that relates to JOBA, you might name it $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 (i.e., hexadecimal value ‘7F’ or less) in variable names, because Zeke assumes that these characters are the end of the name during variable substitution. After the dollar sign, use only the numerics from 0 through 9, and characters from A through Z.

Setting Zeke Variable Values You do not need to define a Zeke variable before you specify it in JCL or in a work center SET statement. Variables remain in the Zeke database, where they are accessible to all systems that share the database, until they are 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.

346

8 Variables

You can establish or change Zeke variable values using any of these 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 /*

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on defining variables using the SET VARIABLE function. •

ZSET operator command. For example: ZSET VAR $XYZ EQ 0 ZSET VAR $OPERFLG EQ NO

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using the ZSET operator command. •

Calling the ZEKEVAR API. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information.

•

User programs (using a supplied API).

•

Work center events (see “Work Centers” on page 149).

•

Zeke online facilities. The ISPF online facility is illustrated in this procedure.

Note:

You cannot use this procedure for OASIS variables (which are contained in the OASIS database). To access the OASIS variable maintenance functions, you can issue the OVAR primary command from any Command line in the Zeke ISPF online facility. See “OASIS Variables” on page 355 for more information.

347

ASG-Zeke Scheduling for z/OS User’s Guide

To define and maintain a Zeke variable 1

From the Zeke Primary Menu, enter 8 and press Enter. The Variable Selection Criteria screen is displayed: ASG-Zeke Command ===>

Variable Selection Criteria

Variable Name ===> Primary commands: ADD Enter Clear * -is ? -is

BROWSE

DOCUMENT

EDIT

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:

2

COPY DELETE

*

C - character, N - numeric

-

(MM/DD/YYYY) or (DD/MM/YYYY) (HH:MM:SS)

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Define a new variable

1 Enter ADD on the Command line. 2 Enter the variable name in the Variable Name field. 3 Press Enter. Go to step 3.

Update a variable for which you know the name

1 Enter EDIT on the Command line. 2 Enter the variable name in the Variable Name field. 3 Press Enter. Go to step 3.

Update a variable for which you do not know the name

1 Type any information you know about the variable in any of the Selection Field Masks fields. 2 Press Enter.

348

8 Variables

The Variable Name Directory screen is displayed: ASG-Zeke Command ===>

Variable Name Directory

Row 1 to 6 of 6 Scroll ===> PAGE

Variable name ===> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit Variable Name Appl Grp UserID $ED $KATHYG $KATHYG1 $KATHYG2 $KATHYG3 $STPNAME ***************************** Bottom of data

3

O - dOcument

Date Time System 01/30/2012 12:13:35 ZEQA 02/08/2012 14:53:44 ZEQA 02/07/2012 16:54:40 ZEQA 02/07/2012 16:54:48 ZEQA 02/07/2012 16:55:57 ZEQA 01/20/2012 15:16:32 ZEQA ******************************

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Update the variable

Enter E in the unlabeled selection field to the left of the variable that you want to edit, and press Enter.

View the variable value

Enter B in the unlabeled selection field to the left of the variable that you want to view, and press Enter.

Delete the variable

1 Enter D in the unlabeled selection field to the left of the variable to be deleted, and press Enter. The Variable Name Record Functions screen is displayed. 2 Type DELETE on the Command line, and press Enter. 3 Press Enter again to confirm. This procedure is complete.

349

ASG-Zeke Scheduling for z/OS User’s Guide

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

Appl: PAYROLL GroupID: CHK Desc: STARTING CHECK NUMBER Desc2:

DOCUMENT

EDIT

UserID: KAC

Curr Value: 1001 Force upper: Y Value set by: U (J=Job P=Program U=User) Name: ALICE Date/Time: 01/30/2012 14:39:55 System: SYSD Part/Init: TSO Prev Value: 1001 Value set by: U (J=Job P=Program U=User) Name: ALICE Date/Time: 01/30/2012 14:39:51 System: SYSD Part/Init: TSO

4

Optional. Enter a description of the variable in the Desc/Desc2 fields. This description is used to identify the variable on summary screens and reports.

5

If you want to set the initial value of the variable, enter the value in the Curr Value field.

6

In the Force Upper field, specify whether the Current Value includes alpha characters. These are the valid codes: Code

Meaning

Y

Forces the Current Value string to uppercase.

N

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 field is a numeric-only value, the Force Upper option is ignored. 7

350

Complete these fields (which are used to organize variables for selection, display, and reporting): Field

Description

Appl

Identifies the application with which the variable is associated. Report Writer, work centers, and Zeke operator commands use this field to sort and select variables.

8 Variables

8

Field

Description

GroupID

This user-assigned code identifies the group with which the variable is associated. This field can be used as a subset of the application ID.

Userid

User ID (up to eight characters long) associated with the variable against, which determines which users can access the variable and can be used in a selection mask. The user ID is case-sensitive; be sure to enter the value correct case (i.e., upper, lower, or mixed).

Press Enter to save the changes.

Maintaining Variable Documentation Zeke enables you to maintain and store Zeke variable-related documentation for the variables that you are authorized to access. Note:

This procedure cannot be used for OASIS variables. To access the OASIS variable maintenance functions, you can issue the OVAR primary command from any Command line in the Zeke ISPF online facility. See “OASIS Variables” on page 355 for more information.

To access and maintain variable documentation 1

From the Zeke Primary Menu, enter option 8 and press Enter.

2

Access the Variable Name Directory screen, as described in, “To define and maintain a Zeke variable” on page 348: ASG-Zeke Command ===>

Variable Name Directory

Row 1 to 6 of 6 Scroll ===> PAGE

Variable name ===> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit Variable Name Appl Grp UserID $ED $KATHYG $KATHYG1 $KATHYG2 $KATHYG3 $STPNAME ***************************** Bottom of data

O - dOcument

Date Time System 01/30/2012 12:13:35 ZEQA 02/08/2012 14:53:44 ZEQA 02/07/2012 16:54:40 ZEQA 02/07/2012 16:54:48 ZEQA 02/07/2012 16:55:57 ZEQA 01/20/2012 15:16:32 ZEQA ******************************

351

ASG-Zeke Scheduling for z/OS User’s Guide

3

Enter the line command O to the left of the Variable Name field and press Enter. The Document Segments screen is displayed: ASG-Zeke Option ===>

Documentation Segments

EDIT

Primary Command: DELETE Variable: $KATHYG1 System: ZEQA User:

Group:

Appl:

Documentation Record Selection Options 1 2 3

SCRATCH TEXT NOTE

Scratch pad Text information Note pad information

This screen enables you to access the different types of documentation for Zeke variables. Note:

If an asterisk (*) is displayed to the left of the documentation type, then documentation already exists for the variable. 4

352

Enter one of these codes on the Command line to select the type of documentation you want to access: Desired Result

Action

Access scratch pad documentation

Enter 1 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 353.

Access text documentation

Enter 2 and press Enter. Go to “Maintaining Text Documentation” on page 354.

Access note documentation

Enter 3 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 353.

8 Variables

Maintaining Scratch Pad or Note Documentation You can add, browse, edit, or delete Scratch or Note documentation for a variable. The related screens enable you to define or browse up to 10 lines of information for each variable. These documentation areas are like a “sticky note” and can be used for quick reference information, or to pass notes from shift to shift or from one department to another. An operator should always review any associated scratch pad or note pad information before a job runs. 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 are identical.

To maintain scratch pad or note documentation 1

Access the Documentation Scratch Pad or Note screen as instructed in “Maintaining Variable Documentation” on page 351: ASG-Zeke Command ==>

Documentation Scratch Pad

Primary Commands: BROWSE

CANCEL

DELETE

ED

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:

2

To delete the scratch pad or note information, enter DELETE on the Command line and press Enter. Re-enter DELETE on the Command line, and press Enter to confirm.

3

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.

4

When you have finished adding or updating information on the Scratch Pad or Note screen, press Enter to update the data.

353

ASG-Zeke Scheduling for z/OS User’s Guide

Maintaining Text Documentation You can add, browse, edit, or delete text documentation for a variable. This documentation area enables 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 351: 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 **************************

354

2

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.

3

When you have finished adding or updating information on the Text screen, press Enter to update the data.

8 Variables

OASIS Variables OASIS variable values can be substituted in the same areas as Zeke variables (e.g., JCL, ZEKESET, SCOM, etc.), but they differ from Zeke variables in this aspects: •

OASIS variables reside in an OASIS database on DASD, and, therefore, are retained across system outages and IPLs. All OASIS-supported ‘Z’ products that use the same subsystem can access the OASIS database, so you can use OASIS variables to communicate information between your ‘Z’ products.

•

OASIS variable values can range from zero through 255 characters long. They can contain any displayable character in the EBCDIC character set (e.g., 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 system where you can define, edit, and view OASIS variables and their values.

•

You can base the value substituted in an OASIS variable on one or more of these qualifiers: —

Schedule date

—

Run date

—

Application ID

—

Group ID

—

User ID

—

Event number

—

Version number

—

Jobname

—

System name

—

Netregid

This enables multiple values to be valid for a single variable (an unqualified variable can have only one value associated with it).

355

ASG-Zeke Scheduling for z/OS User’s Guide

•

Various types of formatting for substitution are allowed. One type of formatting enables you to substitute the entire variable value (or just a portion of it). For example, you could specify that only the last two characters of the value are substituted, or only the second word of the value. You also can pad the substituted value with extra characters. These are the substitution functions can be performed on OASIS variables: Substitution Function

Description

DATE

Converts a date to a specified format and return the result.

EXEC

Calls an EXEC and returns its value.

ITEM

Returns the value of a qualifier.

LEFT

Returns the left-most positions of the string.

RIGHT

Returns the right-most positions of the string.

SUBSTR

Returns a substring of the string.

SUBWORD

Returns one or more specified words from the string.

UPPER

Returns the string in upper case.

VALUE

Return the value of a variable whose name is obtained from the value of another variable or a nested function call.

•

You can perform various operations on OASIS variables using the SSS0UTV utility program. You can use SSS0UTV to create new variable value records, replace or delete existing value records, and list variable definition records and value records.

•

The TVSET function enables 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 (i.e., for the current job run). See “Temporary OASIS Variables” on page 358 for more information.

See the ASG-OASIS for z/OS Reference Guide for detailed information before you use OASIS variables for the first time.

356

8 Variables

Naming OASIS Variables OASIS variable names can be up to 64 characters long. The first character can be any of these symbols: •

Dollar sign ($)

•

Underscore (_)

•

Pound sign (#)

•

At sign (@)

•

Any capital letter (from A through Z)

The remaining characters can be any of the above characters or numerics from 0 through 9. Imbedded blanks are not allowed in variable names.

Setting OASIS Variable Values OASIS variable values are set using any of these methods: •

SSS0UTV utility program

•

OASIVAR Application Programming Interface (API) (see the ASG-OASIS for z/OS Reference Guide for detail)

•

OASIS online (as shown in the following procedure)

To maintain OASIS variables 

Issue the OVAR primary command from any Command line in the Zeke ISPF online facility. The OASIS Variable Maintenance screen is displayed: OASIS Variable Maintenance OPTION ===> 02/20/12 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

357

ASG-Zeke Scheduling for z/OS User’s Guide

From this screen, you can add, edit, delete, or browse variable definition records and value records.

Temporary OASIS Variables The TVSET function (which is unique to OASIS variables) enables you to perform these tasks: •

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} Note:

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 this 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 used in JCL, the //*TVSET statement appears in the output stream when it runs, so the statement 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 with an 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.

358

8 Variables

System-dependent Variables System-dependent variables enable 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, you use three dollar signs ($$$) as the first three characters of the variable name (e.g., $$$NAME). Zeke replaces the third dollar sign with the one-character ID of the dispatching CPU. These are examples of system-dependent variables: Job Control Variable Name

CPUID

Actual Name Used

$$$PRFLGG

A

$$APRFLG

$$$OPER1

C

$$COPER1

$$$VAR01

B

$$BVAR01

$$$TEST

A

$$ATEST

Note:

System-dependent variables cannot be used with Zeke operator commands (e.g., 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 (e.g., $$AFLAG instead of $$$FLAG). System-dependent variables can be used in ZEKESET statements and by programs that call the ZEKEVAR API.

Uses for Zeke Variables Zeke and OASIS variables are powerful job management tools. These are some of the uses of Zeke variables: •

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 z/OS and JES JCL statements at submission time

•

Pass information from one job, job step, or program to another

•

Document cancellation reason 359

ASG-Zeke Scheduling for z/OS User’s Guide

•

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 124 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 (e.g., 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. This is the WHEN condition to establish this job: WHEN (VAR $PRDATA1 EQ YES)

Also, this jobstream is not processed until the PREDIT job is processed with no errors. When the results of PREDIT are satisfactory, and the PRUPDT job can be processed, the operator simply informs Zeke by entering this command: ZSET VAR $PRDATA1 EQ YES

This command satisfies the job dependency for PRUPDT, and if the early/schedule time has been reached, Zeke moves the event to the dispatch queue. Zeke dispatches when all resource requirements are available. Additionally, the variable $PRDATA1 needs to be reset to NO when PRUPDT is complete. You can accomplish this using a ZEKESET program SET statement after the last step in the jobstream. The variable $PRDATA1 could be set to YES in any of these ways: •

Using a ZEKESET program SET statement.

•

Using the ZEKEVAR API. This facility enables programs to make decisions that can affect the dispatching of subsequent events.

•

Using the Zeke online facility for work centers.

Note:

OASIS variables cannot be used to trigger jobs.

360

8 Variables

Using Variables to Control Jobstream Flow You can use variables to control the flow of MVS job streams. As a simple example, this jobstream consists of four steps to be 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

GENOPTs Directory

Row 1 to 4 of 4 Scroll ===> CSR

Zeke System: Primary Commands: ADD BROWSE CONFIRM COPY DELETE EDIT PENDING Line Commands: B - Browse C - Copy D - Delete E - Edit System * Description Last updated by - -------- - -------------------------------- ---------------------------*ACTIVE In-memory values (ZEKE60A ) *ZEKEUP* 01/10/2012 13:21:28 *GLOBAL Zekeplex global options ZEKEUSER 12/05/2011 19:14:48 ZEKE60A * Zeke 6.0 component on SYSA ZEK60JOB 11/29/2011 15:53:54 ******** Default local system options *DBCNVT* 11/10/2011 13:05:28 ******************************* Bottom of data *******************************

8

Enter E to the left of the GENOPT with the system name *GLOBAL (which contains the security options), and press Enter. The Generation Options EDIT screen is displayed with the options in alphabetical order: ASG-Zeke Command ===>

Generation Options

Zeke System: *GLOBAL

Description: Zekeplex global options

Option --------Abhold: AddInact: AuditCls: AuditCmd: AuditCnd: AuditEcd: AuditEmr: AuditEvt: AuditGop: AuditNam: AuditOpr: AuditPas: AuditPin: AuditPoo: AuditRes: AuditSqr: AuditVar:

9

Row 1 to 17 of 143 Scroll ===> CSR

Description --------------------------------------------------------(Y,N) Yes to hold recurring events if abended (Y,N) Yes to allow ZADD of inactive event (Y,N) Yes to log Security Class changes (Y,N) Yes to log Zeke operator commands (Y,N) Yes to log Calendar changes (Y,N) Yes to log ESI Class changes (Y,N) Yes to log EMR changes (Y,N) Yes to log event flow (Y,N) Yes to log Generation Option (GENOPT) changes (Y,N) Yes to log Name/Address changes (Y,N) Yes to log Zeke Operator changes (Y,N) Yes to log Zeke Operating Password changes (Y,N) Yes to log Partition/Initiator changes (Y,N) Yes to log Pool changes (Y,N) Yes to log Resource changes (Y,N) Yes to log SQR changes (Y,N) Yes to log Variable changes

To quickly find the options in the security category, you can use these primary commands (see “Viewing GENOPT Details” on page 283 for more information): a

384

Value ---------N N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

EDIT

Enter CAT ON on the Command line, and press Enter to switch to category view.

9 Security

b

Enter LOC SEC on the Command line, and press Enter to scroll to the security options.

Or

To quickly find a particular field, you also can use the primary commands FIND (a string) or LOCATE (a line containing a string). For example, either of these commands would scroll to the DefOpid field: LOC DEFO FIND OPID

Or, you can simply use the F8 (down) and F7 (up) keys to scroll, as necessary. This is an example of the detail view by category for the same GENOPT: ASG-Zeke Command ===>

Generation Options

EDIT

Row 116 to 132 of 154 Scroll ===> CSR

Zeke System: *GLOBAL

Description: Zekeplex global options

Option Value --------- ---------==================== BatOprid: BATCH BatSec: N DefOpid: OPERATOR ESIActv: N

Description --------------------------------------------------------Security ================================================ (xxxxxxxx) Default security batch operator id (VSE) (Y,N) Yes for Zeke to perform batch security (VSE) (xxxxxxxx) Default operator id (MVS), online only (VSE) (Y,N) Yes to activate External Security Interface (SAF) ReqOpid: N (Y,N) Yes to require authorized operator id for logon SecFail: C (C,I) C(ancel) or I(gnore) if batch security fails SecHide1: N (Y,N) Yes to hide records when access is denied SecHide2: N (Y,N) Yes to hide sub-records when access is denied SecSel: Y (Y,N) Yes to security check using select criteria SecUInit: N (Y,N) Yes to init event UserID and SecGroup fields SecULock: N (Y,N,E) Lock event UserID and SecGroup fields Y(es), (N)o, E(SI-controlled) ==================== Traces ================================================== ==================== User Interface ==========================================

10

To require that a user is defined in the Zeke database as an Zeke operator ID before access to the Zeke online system can be granted, locate or scroll to the ReqOpid field. Enter Y in the ReqOpid field and press Enter (see “ReqOpid” on page 382 for more information). Or

To allow access for users who are not defined to Zeke, take these actions:

385

ASG-Zeke Scheduling for z/OS User’s Guide

11

a

Locate or scroll to the DefOpid field, specify a valid operator ID (see “Defining Operator Records” on page 389), and press Enter. Because the default value OPERATOR specifies the operator ID that Zeke uses associates with any user that accesses a system console without a logon requirement, ASG recommends that you define a separate operator ID to use as the DefOpid value

b

Verify that the ReqOpid field is set to N.

Specify whether that you want to cancel a batch job when an unauthorized request is encountered: a

Locate or scroll to the SecFail field.

b

To specify that the job be cancelled, enter C. Or

To specify that the unauthorized request be ignored and for processing to continue with the next input statement, enter I. c

Press Enter.

12

If you plan to use a ZEKE15B user security exit, locate or scroll to the SecExitw field. Specify the number of bytes of storage allocated to call the security exit routine (ZEKE15B), and press Enter.

13

To activate the updated options, enter ZRELOAD GENOPT on the Command line, and press Enter.

Defining Class Records A class ID is used to grant or deny access to specific online functions and operator commands for a group of operator IDs. The default class ID is A (which allows WRITE access to all online functions and operator commands); however, ASG recommends that this level be reserved for the Zeke security administrator.

386

9 Security

To create or maintain class records 1

From the Zeke Primary Menu, enter option 6.2. The Directory of Command Classes screen is displayed: 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 ******************************

2

Perform the steps in the Action column (depending on the desired result). Desired Result

Action

Add a new class ID

1 Enter ADD on the Command line. 2 Specify the new class ID in the Class ID field. The valid values range from A through Z. 3 Press Enter. Go to step 3.

Update an existing class ID

1 Enter E to the left of the class ID that you want to update. 2 Press Enter. Go to step 3.

Copy a class ID

1 Enter C to the left of the class ID that you want to copy, and press Enter. 2 Specify the new class ID in the Class field, and press Enter. This procedure is complete.

Delete an existing class ID

1 Enter D to the left of the class ID that you want to delete, and press Enter. 2 Enter DELETE on the Command line to confirm, and press Enter. This procedure is complete.

387

ASG-Zeke Scheduling for z/OS User’s Guide

The Class Detail screen is displayed: ASG-Zeke Command ===>

Class Detail

EDIT

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

3

4

388

BROWSE

CANCEL

Work CenterSecurity Document Variable -

W W W W

COPY

DELETE

EDIT

(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

To the right of each function (the main Zeke online functions are shown on this screen), specify the level of access allowed for this class ID. These are the valid authority level codes: Code

Meaning

W

(WRITE allowed) Zeke allows an operator assigned to this class to browse and maintain records in this online function.

R

(READ only) Zeke allows an operator assigned to this class to browse records in this online function. Not valid for the work center function.

N

(Not allowed) Zeke denies access to this online function by an operator assigned to this class.

A

(Auto entry in WRITE mode) Zeke displays the first screen in this online function when the operator logs on. You can assign this code to only one online function.

To the right of each operator command, specify whether access is allowed for this class ID. These are the valid codes: Code

Meaning

Y

Allow an operator assigned to this class to execute this command.

9 Security

Code

Meaning

N

Default. Do not allow an operator assigned to this class to execute this command.

Note:

You can further limit access to the online functions as granted by the class ID. To do so, you can specify user IDs on the operator record (see “Defining Operator Records” on page 389 for more information). 5

Press Enter to save the changes.

Defining Operator Records Operator records control access to the various types of database records (e.g., SQRs, EMRs, work centers, documentation, and variables). You assign an operator ID to each authorized user and assign each operator ID to a class that specifies the functions and commands that are allowed for users with that operator ID. You can restrict access further by the user ID (which controls user access to specific event and variable records).

To create or maintain operator records 1

From the Zeke Primary Menu, enter option 6.1. The Directory of Operator IDs screen is displayed: ASG-Zeke Command ===>

Directory of Operator IDs

Row 1 to 1 of 1 Scroll ===> PAGE

Operator ID: Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: E - Edit B - Browse C - Copy Operator ID

D - Delete

Class

Date Date Last Added Updated OPERATOR A 01/16/2012 01/30/2012 L003J A 01/24/2012 02/04/2012 ****************************** Bottom of data *****************************

389

ASG-Zeke Scheduling for z/OS User’s Guide

2

Perform the steps in the Action column (depending on the desired result): Desired Result

Action

Add a new operator ID

1 Enter ADD on the Command line. 2 Specify the new operator ID in the Operator ID field. 3 Press Enter. Go to step 3. 1 Enter E to the left of the operator ID to update.

Update an existing operator ID

2 Press Enter. Go to step 3. 1 Enter C to the left of the operator ID to copy and press Enter.

Copy an operator ID

2 Specify the new operator ID in the Operator ID field and press Enter. This procedure is complete. 1 Enter D to the left of the operator ID to delete and press Enter.

Delete an existing operator ID

2 Enter DELETE on the Command line to confirm and press Enter. This procedure is complete.

The Operator Detail screen is displayed: ASG-Zeke Command ===>

Operator Detail

ADD Scroll ===> PAGE CAPS ===> ON

Primary Commands: ADD BROWSE COPY DELETE EDIT Operator ID: SECADMIN

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 ********

3

390

Zcom

Event

Work

W

W

W

Documentation W

Variable W

In the Class ID field, specify the ID of the class to which you want to assign this operator.

9 Security

Note:

The default class ID is A (which allows WRITE access to all online functions and operator commands). ASG recommends that this level be reserved for the Zeke security administrator. See “Defining Class Records” on page 386 for information on defining class IDs. 4

In the User ID field, enter a user ID to either limit or grant access to Zeke database records. You can enter a specific or a generic user ID or mask (e.g. you could specify PAY***** to control access to all events with a user ID beginning with PAY). You can enter ******** to grant access to all events. Zeke supports mixed-case user IDs. You can use the ISPF command CAPS to toggle between mixed and upper case modes. The current mode is displayed in the upper right portion of the screen. The authorized user IDs are checked in columnar sequence. For example, you could allow access to user ID BILL0501, but deny access to any other user ID beginning with BILL. To do so, you would enter user ID BILL0501 early in the list (allowing access), and then enter user ID BILL**** later in the list (denying access). Zeke also enables you to specify blank user IDs (i.e., composed of all spaces) in operator records, and allows user ID masks containing leading spaces, embedded spaces, trailing spaces, or all spaces. Note:

When you create variables with a blank user ID, you must specify the blank user ID to have WRITE access to variables and work centers. 5

6

Below each online function, indicate the level of authority access. These are the valid codes: Code

Meaning

W

(WRITE allowed) Zeke allows users assigned to this operator ID to browse and maintain records using this online function.

R

Default. (READ only) Zeke allows users assigned to this operator ID to browse records using this online function. Not valid for the work center function.

N

(Not allowed) Zeke denies users assigned to this operator ID access to this online function.

Press Enter to save the changes.

391

ASG-Zeke Scheduling for z/OS User’s Guide

External Security Zeke external security offers added benefits over internal security by enabling more comprehensive security at a more detailed level and providing more flexibility in establishing access criteria. Zeke uses ESI to pass security information to the SAF security interface. This enables you to use a third-party security product (e.g., RACF or CA-ACF2) to control access to resources for specific Zeke functions. You must have installed and be familiar with your external security package before using this option. Also, be familiar with Zeke internal security because you can use a combination of internal and external security for your system. See “Zeke Security Processing” on page 372 for an overview. 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 used to access those structures. A few external security classes are function-oriented because, in certain situations, securing a process could be more appropriate than securing the structure. This provides you the flexibility to set up the most effective security system for your environment. For example, access to SQRs can be controlled by function (where access to the ZCOM online screen and the Zeke operator commands is restricted) or by object (where access to the SQRs themselves is restricted). Access to both functions and objects is controlled by a security class. Because privileges and restrictions provided by classes could overlap, it typically is not necessary to activate all classes to achieve 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 any of these methods: •

The Variable option in the online system

•

A Zeke command (ZSET VAR)

•

The ZEKESET program (SET VAR)

•

Completion of a work center

These are some of the different ways you could secure access to variables:

392

•

Using the Z$VAR class secures access to variable records that is attempted by requests made through the online system, a Zeke command, the ZEKESET program, or by completion of a work center.

•

Using the Z$ONLINE class controls who can access the ZCOM, variable, and work center menu options in the online system.

9 Security

•

Using the Z$SET class controls who can issue the special commands available in the ZEKESET utility program.

•

Using the Z$CMD class controls who can issue certain commands.

Security Classes and Resource Names In external security, classes are used to identify each resource type. The internal class name is used for all references to that resource type in ESI (e.g., documentation, messages, and commands) and cannot be changed. For example, the internal class name for EMRs is Z$EMR. 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 X1FOFSEL page of the ESI Customization screen. These are the types of resource name elements: Element Type Description Fields

Most elements that can 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 eligible elements would include EVENTNAME, APP, and GROUP.

Structures

Some elements are structures that are associated with the Zeke database (e.g., catalog ID and the system where Zeke are running).

Constants

These elements get their values from a set of constants applicable to that element (e.g., 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

User-defined constants and delimiter characters are also eligible elements.

393

ASG-Zeke Scheduling for z/OS User’s Guide

These are the most commonly used elements: Element

Description

Catalog ID

Unique, catalog identifier (up to eight characters long) determined when the Zeke database 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 database is restored from a backup dataset.

Command

Command verb issued. For example, Z$CMD class (e.g., ZID, ZDISPLAY, ZALTER, etc.) or Z$SET class (e.g., SET, CDATE, etc.). When a command verb element is used in the resource name for a security class, only the command name is included in the security call made by the Zeke command processor, not the command text.

Command code

394

Type of command issued from an SCOM event. These are the valid codes: C

System command

R

System response (VSE only)

Z

Zeke command

V

VM command

P

VSE/POWER command

Command text

Full text of an entered command.

Function

Name of the online function to which access is being requested.

Record type

Subordinate record type to which access is requested (e.g., JCL or DOC are sub-records for an EMR).

Source

Source of the request that caused the security call to be made (e.g., if a command is entered from the console, then the value of the source field is CONSOLE.)

Subsystem name

OASIS subsystem under which this Zeke system is running. Multiple subsystems enable the user to run more than Zeke system on the same operating system. This value is displayed in ZID command output.

9 Security

These are the Zeke security classes, along with their resource names and authority levels (see “Authority Levels” on page 372 for an explanation of the different authority levels by class): Zeke Security Classes

Class

Description

Authority Levels

Z$ACCESS

Controls these types of requests or behaviors:

GENERICS

(READ access required) • Use of generic selection criteria (e.g., for application ID, group ID, system ID, or user ID). Resource name: SCHEDULE.GENERICS

ACTIVATE

(ALTER access required) EMRFIELD

• Use of the CLEAR keyword with the SCHEDULE function. (UPDATE access required) Resource name: SCHEDULE.CLEAR • Whether selected EMR fields are locked and unable to be modified (i.e., the SecULock generation option is set to E). Resource name: EMRFIELD.fieldname.subsysname.userid.applid. grpid.eventname.eventtype

Z$CATAL

Secures access to the database as a whole.

READ

Resource names:

(enables STATUS and BACKUP functions)

CREATE BACKUP RESTORE STATUS BLOCK CLEARCPU

Z$CLASS

Secures access to Zeke internal security class records.

ALTER (enables CREATE, RESTORE, and BLOCK functions) READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$CMD

Secures access to Zeke operator commands.

READ

Resource name: command-verb Z$CND

Secures access to calendar records.

READ/UPDATE/ALTER

Resource name: calendar-ID Z$DOWNLD

Secures access to the schedule download agents list.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$ECDR

Secures access to the external class definition records (ECDRs). READ/UPDATE/ALTER Resource name: Zeke-catalog-ID

395

ASG-Zeke Scheduling for z/OS User’s Guide

Zeke Security Classes

Class

Description

Authority Levels

Z$EMR

Secures access to the EMRs.

READ/UPDATE/ALTER

Resource name: userid.rectype Z$GOPT

Secures access to the generation option records.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$NAME

Secures access to the customer name records.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$ONLINE

Secures access to the Zeke online functions. Typically, this option is not necessary if all of the desired records have been secured.

READ

Note: Options to which you do not have access are not displayed on the Zeke Primary Menu.

UPDATE

(enables READ mode for that section of the online) (enables WRITE mode)

Resource name: menu-option-name Z$OPER

Secures access to operator records used in internal security.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$PASS

Secures access to the operating passwords.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$PINT

Secures access to the partition/initiator records.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$POOL

Secures access to the pool definition records.

READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID Z$RESRC

Secures access to the resource definition records. Resource name: Zeke-catalog-ID

396

READ/UPDATE/ALTER

9 Security

Zeke Security Classes

Class

Description

Authority Levels

Z$SCHED

Secures access to the SCHEDULE function.

READ

(if ACTIVATE is not specified) Note: Object-oriented security is not applied because a security call would be required for each attempt to access a record.

ALTER

(if ACTIVATE is specified)

Because the SCHEDULE function involves reading all EMRs, calendars, and variables in the Zeke database, then creating SQRs, the resulting number of security calls have a substantial impact on performance. Resource name: user-ID Note: Parameters provided by the user are used to build the resource name for one SAF call. Z$SET

Secures access to the ZEKESET functions.

READ

Resource name: command-verb Z$SIM

Not used. (Zeke simulation)

n/a

Resource name: user-ID Z$SQR

Secures access to the SQRs.

READ/UPDATE/ALTER

Resource name: user-ID Z$VAR

Secures access to variables.

READ/UPDATE/ALTER

Resource name: user-ID Z$XCOM

Secures access to individual commands within an SCOM event. CONTROL Resource name: command-code

397

ASG-Zeke Scheduling for z/OS User’s Guide

Implementing External Security ASG recommends fully implementing external security for a single internal class before implementing ESI for other classes. This enables you to complete the implementation process (including testing) for a smaller segment of your Zeke 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 might want to deactivate or combine some classes into the same external class name, or you might want to activate the Z$ONLINE class.

Modifying ESI Classes All of the ESI classes provide the flexibility of changing the external class name, the process option, and the resource name format (except 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 in the Zeke online system, review the ESI chapter of the ASG-OASIS for z/OS Reference Guide (particularly the section about setting up ESI).

398

9 Security

To modify ESI class definition records 1

From the Zeke Primary Menu, enter option 6.3. The ESI Customization screen displays the X1SELECT page: ESI Customization

BROWSE SCROLL ===> PAGE X1SELECT

COMMAND ===>

Primary Commands: DOWN UP EDIT BROWSE END RETURN Line Commands: F - Resource name format C - Copy to discrete ECDR D - Delete discrete ECDR

System

"Copy to" System

******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ******** ********

Internal Class

External Class

Process Option

Z$ACCESS Z$CATAL Z$CLASS Z$CMD Z$CND Z$DOWNLD Z$ECDR Z$EMR Z$GOPT Z$NAME Z$ONLINE Z$OPER Z$PASS Z$PINT

Z$ACCESS Z$CATAL Z$CLASS Z$CMD Z$CND Z$DOWNLD Z$ECDR Z$EMR Z$GOPT Z$NAME Z$ONLINE Z$OPER Z$PASS Z$PINT

N4 Y4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4 N4

Each line represents an ESI class definition record that is uniquely defined by the system ID and the internal class name. 2

Perform these actions (depending on the desired result): Desired Result

Action

Change the external class name

1 Enter EDIT on the Command line, and press Enter. 2 In the External Class field for the class to change, specify the new external class name (which must also be defined in your external security product) that is used for SAF calls. 3 Press Enter. Go to step 6.

399

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Copy a class record with 1 Enter C to the left of the record to copy. all of its attributes to 2 Specify the new system ID in the “Copy to” System field. another system (that shares the same Zeke database) 3 Press Enter. 4 Perform any additional actions in this table (depending on the desired result) to customize the new class record. Go to step 6. Delete a class record with all of its attributes

Enter D to the left of the record to delete, and press Enter. Go to step 6.

Note: You cannot delete class records for the default system (********). Change the process option for a security class

Note: If you change the external class name or resource name format, keep the process option set to N4 until you have tested the implementation. 1 Enter EDIT on the Command line, and press Enter. 2 Specify the process option in the Process Option field for the class to change. These are the valid process options:

400

N0

Do not call SAF. Grant all access requests.

N4

Do not call SAF. Use internal security to determine whether to grant the access request. If internal security has not been implemented, grant access.

N8

Do not call SAF. Deny all access requests.

Y0

Call SAF. If the SAF return code is 4, grant the access request.

Y4

Call SAF. If the SAF return code is 4, use internal security to determine whether to grant the access request. If internal security has not been implemented, grant access.

Y8

Call SAF. If the SAF return code is 4, deny the access request.

9 Security

Desired Result

Action 3 Press Enter. Go to step 6.

Change the resource name format for a security class

Enter F to the left of the class name to change, and press Enter. Go to step 3.

The ESI Customization screen displays the X1FRMAT1 page with the current list of elements for the specified resource name format. This example shows the default resource name format for the Z$EMR class: ********.Z$EMR/Z$EMR COMMAND ===>

ESI Customization

Primary Commands: DOWN UP EDIT BROWSE RESET Line Commands: A - Insert element after D - Delete element

BROWSE SCROLL ===> PAGE X1FRMAT1 END RETURN CANCEL B - Insert element before

--+---1----+----2----+----3----+----4----+----5----+----6----+----7---+--8 aaaaaaaa.bbbbbbbb Start a 001 . 001 b 001 **END**

3

Length 008 001 008

Field Description

3 elements

User ID Delimiter character Record type

Perform the steps in the Action column (depending on the desired result) Desired Result

Action

Add an element

1 Enter EDIT on the Command line, and press Enter. 2 Specify the code to the left of an element to position the new element. These are the valid codes: A

Add the new element after the selected element.

B

Add the new element before the selected element.

3 Press Enter. Go to step 4.

401

ASG-Zeke Scheduling for z/OS User’s Guide

Desired Result

Action

Change a portion of an element to be included in the resource name format

1 Enter EDIT on the Command line, and press Enter. 2 Specify the beginning position in the Start field. 3 Specify the element length in the Length field. For example, if the element value is ABCDEDFG (i.e., has a start position of 1 and length of 8), and that 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 want to cancel them, Enter RESET on the Command line, and press Enter.

Exit screen without saving changes made to the format

If you have made changes to the format that you do not want to keep and have not saved them, Enter CANCEL on the Command line, and press Enter.

Delete an existing element 1 Enter EDIT on the Command line, and press Enter. 2 Enter D to the left of the element that you want to delete. 3 Press Enter. Go to step 6.

The ESI Customization screen displays the X1FOFSEL page with a list of eligible elements for this class. This example shows the eligible fields for the Z$EMR 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

402

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)

9 Security

4

To add the element to the resource name format, enter C to the left of the desired element and press Enter.

5

After all the desired elements are included in the resource name format, press F3.

6

For each class that you updated, issue the OASIS operator command RELOAD to replace the in-storage ESI class definition record. Include the corresponding internal class name for the record to be replaced. For example, this command reloads the Zeke operator commands: XRELOAD ECDR Z$CMD

Activating ESI To activate ESI 1

From the Zeke Primary Menu, enter option 4.1. The GENOPTs Directory screen displays a listing of all GENOPTs in the Zeke database: ASG-Zeke Command ===>

GENOPTs Directory

Row 1 to 4 of 4 Scroll ===> CSR

Zeke System: Primary Commands: ADD BROWSE CONFIRM COPY DELETE EDIT PENDING Line Commands: B - Browse C - Copy D - Delete E - Edit System * Description Last updated by - -------- - -------------------------------- ---------------------------*ACTIVE In-memory values (ZEKE60A ) *ZEKEUP* 01/10/2012 13:21:28 *GLOBAL Zekeplex global options ZEKEUSER 12/05/2011 19:14:48 ZEKE60A * Zeke 6.0 component on SYSA ZEK60JOB 11/29/2011 15:53:54 ******** Default local system options *DBCNVT* 11/10/2011 13:05:28 ******************************* Bottom of data *******************************

2

Enter E to the left of the GENOPT with the system name *GLOBAL (which contains the security options) and press Enter.

403

ASG-Zeke Scheduling for z/OS User’s Guide

The Generation Options EDIT screen displays the options in alphabetical order: ASG-Zeke Command ===>

Generation Options

Zeke System: *GLOBAL

Description: Zekeplex global options

Option --------Abhold: AddInact: AuditCls: AuditCmd: AuditCnd: AuditEcd: AuditEmr: AuditEvt: AuditGop: AuditNam: AuditOpr: AuditPas: AuditPin: AuditPoo: AuditRes: AuditSqr: AuditVar:

3

Value ---------N N Y Y Y Y Y Y Y Y Y Y Y Y Y Y Y

EDIT

Row 1 to 17 of 143 Scroll ===> CSR

Description --------------------------------------------------------(Y,N) Yes to hold recurring events if abended (Y,N) Yes to allow ZADD of inactive event (Y,N) Yes to log Security Class changes (Y,N) Yes to log Zeke operator commands (Y,N) Yes to log Calendar changes (Y,N) Yes to log ESI Class changes (Y,N) Yes to log EMR changes (Y,N) Yes to log event flow (Y,N) Yes to log Generation Option (GENOPT) changes (Y,N) Yes to log Name/Address changes (Y,N) Yes to log Zeke Operator changes (Y,N) Yes to log Zeke Operating Password changes (Y,N) Yes to log Partition/Initiator changes (Y,N) Yes to log Pool changes (Y,N) Yes to log Resource changes (Y,N) Yes to log SQR changes (Y,N) Yes to log Variable changes

To quickly find the options in the security category, you can use these primary commands (see “Viewing GENOPT Details” on page 283 for more information): a

Enter CAT ON on the Command line, and press Enter to switch to category view.

b

Enter LOC SEC on the Command line, and press Enter to scroll to the security options.

Or

To quickly find a particular field, you also can use the primary commands FIND (a string) or LOCATE (a line containing a string). For example, either of these commands would scroll to the DefOpid field: LOC DEFO FIND OPID

Or, you can simply use the F8 (down) and F7 (up) keys to scroll, as necessary.

404

9 Security

This is an example of the detail view by category for the *GLOBAL GENOPT: ASG-Zeke Command ===>

Generation Options

EDIT

Row 116 to 132 of 154 Scroll ===> CSR

Zeke System: *GLOBAL

Description: Zekeplex global options

Option Value --------- ---------==================== BatOprid: BATCH BatSec: N DefOpid: OPERATOR ESIActv: N

Description --------------------------------------------------------Security ================================================ (xxxxxxxx) Default security batch operator id (VSE) (Y,N) Yes for Zeke to perform batch security (VSE) (xxxxxxxx) Default operator id (MVS), online only (VSE) (Y,N) Yes to activate External Security Interface (SAF) ReqOpid: N (Y,N) Yes to require authorized operator id for logon SecFail: C (C,I) C(ancel) or I(gnore) if batch security fails SecHide1: N (Y,N) Yes to hide records when access is denied SecHide2: N (Y,N) Yes to hide sub-records when access is denied SecSel: Y (Y,N) Yes to security check using select criteria SecUInit: N (Y,N) Yes to init event UserID and SecGroup fields SecULock: N (Y,N,E) Lock event UserID and SecGroup fields Y(es), (N)o, E(SI-controlled) ==================== Traces ================================================== ==================== User Interface ==========================================

4

For the ESIActv generation option, set the value to Y to activate ESI.

5

For the DefOpid generation option, specify the default Zeke operator ID to be assigned when an undefined operator logs on (see “DefOpid” on page 382 for more information). 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 provides 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.

6

Security verification for batch functions is enabled by default. Determine how to proceed when an unauthorized request from a batch job is encountered: •

To cancel the batch job, verify that the SecFail option is set to C.

•

To ignore the unauthorized request and continue processing with the next input statement to that batch program, verify that SecFail is set to I.

405

ASG-Zeke Scheduling for z/OS User’s Guide

7

8

Determine whether to enable primary records (e.g., events) to be displayed for users that have been denied access: •

To display primary records, verify that the SecHide1 option is set to N.

•

To hide primary records, verify that SecHide1 is set to Y. Any Zeke online screen that displays a directory of records will only display those records for which the user has at least READ access.

Determine whether to enable subordinate records (e.g., WHEN conditions) to be displayed for users that have been denied access: •

To display subordinate records, verify that the SecHide2 option is set to N.

•

To hide subordinate records, verify that SecHide2 is set to Y. Any Zeke online screen that displays a directory of records will only display those subordinate records for which the user has at least READ access. For example, when as asterisk (*) is displayed in the DOC column on the Event Master Directory screen, this indicates a subordinate record exists for the EMR.

9

To activate the updated options, enter ZRELOAD GENOPT on the Command line, and press Enter.

10

If you have not defined the external class name, see “Modifying ESI Classes” on page 398.

You now are ready to test the implementation. For information on testing ESI with ESITRACE, see the ASG-OASIS for z/OS Reference Guide.

406

Zeke Web Services

Chapter 10:

10 Zeke’s Web Services enable you to access to work center functions from a Web browser instead of requiring you to establish access to Zeke through an online facility (e.g., TSO or ISPF) or an OpsCentral client. This chapter discusses these topics: Topic

Page

Web Services Overview

407

Accessing Zeke Web Services Setting Zeke Web Services as Your Home Page

408 409

Managing Work Centers from the Web Accessing Scheduled Work Centers Creating and Maintaining Custom Views Completing a Work Center Enabling or Disabling a Work Center Refreshing a Work Center

409 409 412 418 423 424

Web Services Overview Web Services takes advantage of the Zeke server to enable remote access to Zeke from a Web browser using Hypertext Transport Protocol (HTTP). The Zeke server is a subtask that runs in the Zeke address space and includes an embedded HTTP/HTTPS server to provide Web Services. The Zeke server accepts requests and responds with dynamic XML data and static documents (i.e., CSS, GIF, ICO, JS, XSL). A Web browser, or an application such as ASG’s Business Service Platform (BSP) Enterprise Workload Automation solution, processes the XML data to create dashboard-type objects to provide an overview of the systems you are monitoring. Access to Zeke through a Web browser can be secured (i.e,. through SAF) or unsecured (i.e., controlled based only on the default operator ID). See the ASG-Zeke Scheduling for z/OS Installation Guide for details on configuring the Zeke server to enable Web Services.

407

ASG-Zeke Scheduling for z/OS User’s Guide

Accessing Zeke Web Services Before you begin, be sure the system and setup requirements have been met and that the Zeke server has been enabled and configured for HTTP/HTTPS. See the ASG-Zeke Scheduling for z/OS Installation Guide for details.

To access Zeke Web Services 1

Point your Web browser to this URL: http://your.mainframehost:nnnn/zeke/

where: your.mainframehost is the host name or IP address for Zeke Web services. nnnn is the port number for Zeke services. Note:

These values are defined as environment variables in the ZENVIRN environment file. See the ASG-Zeke Scheduling for z/OS Installation Guide for details. 2

If an authentication process is in force for allowing access to Zeke, a prompt appears and requests your mainframe user ID and password. Enter your mainframe user ID and password. The Zeke Web Services home page appears and lists the available Zeke functions:

From this page, you can access either the list of scheduled work centers or the page for maintaining custom views of the work center list. See “Managing Work Centers from the Web” on page 409 for detailed procedures.

408

10 Zeke Web Services

Setting Zeke Web Services as Your Home Page You can set the Zeke Web Services home page as your default home page.

To set Zeke Web Services as your home page 

In the server root path, create an index.html document with these contents:

ASG-Zeke Web Services

Loading Zeke Web Services, please wait.

This document returns for the root path ‘/’ and then redirects your browser to the Zeke Web Services (‘/zeke/’) page.

Managing Work Centers from the Web Zeke Web Services enable you to view and manage Zeke work center events from a Web browser. A work center is a special type of event that is not dispatched by Zeke and requires operator intervention. Typically, work centers are prerequisites for other events. For a complete discussion on work center events (including how they are defined and the types of functions they can perform), see “Work Centers” on page 149.

Accessing Scheduled Work Centers This section explains how to access schedules work centers through Zeke Web Services.

To access the work centers list 1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click Work Center List.

409

ASG-Zeke Scheduling for z/OS User’s Guide

The system default view appears:

By default, the list shows all work centers in the current schedule. You can sort any column (in ascending or descending alphanumeric order) by clicking on the column heading. You can use these additional options to control which information is displayed (and how it appears): •

Filters enable you to narrow down the number of work centers in the list only to those that meet specific criteria (e.g., a specific completion status).

•

You can display or hide particular columns and change how they are sorted by default.

See “Creating and Maintaining Custom Views” on page 412 for instructions on creating and customizing different views.

410

10 Zeke Web Services

These are the default column headings: Heading

Description

Status

Status of the work center activity. These are the valid statuses: (gray) Not done (green) Pending (yellow) Disabled (blue) Completed Note: You also can move your cursor over a status icon for a verbal status.

Event

Event number. You can click the event number to access the work center details and documentation.

Appl

Application ID.

Group

Group ID.

Event Name

Event name.

System

System ID.

Version

Event version number.

Sched Time

Schedule time.

Sched Date

Schedule date.

From the Work Center List, you can access and edit the attributes of the current view (see “Updating a View” on page 416), delete it (see “Deleting a View” on page 418), or create a new view using any existing view as a template (see “Creating a New View” on page 412).

To switch to a different view 

Select an existing view from the Views: drop down list, and click Select.

411

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

Views are listed according to their name and whether they are defined for use by the current user only or by all users. View names are displayed like this: viewname:viewdescription For example: WC:Not Done Only After you select a different view, you can view the work center list under this view, edit the view (see “Updating a View” on page 416), use it as a template for creating a new view (see “Creating a New View” on page 412), or delete it (see “Deleting a View” on page 418).

Creating and Maintaining Custom Views A view controls the types of information that are shown for the work centers in the list. You can create a custom view and indicate which column headings you want to appear in that view (and in what sequence you want them to appear). You can create and save multiple views for later use, and easily switch between different views. A view can be defined and saved for use only under a particular user ID or it can be shared by multiple users. A filter controls which work centers are selected for display. You can create custom filters based on an application, group, system, or user ID, or a status. You also can bookmark filters for later use. See “Accessing Scheduled Work Centers” on page 409 for an example of the default system view (which is unfiltered and shows all work centers in the current schedule).

Creating a New View Typically, you create and manage views through the View Maintenance function. You also can create a new view (from an existing view) directly from the Work Center List.

To create a new view

412

1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click View Maintenance.

10 Zeke Web Services

The All Views list appears:

The All Views list displays this information: Column

Description

Type

Type of view, where wc indicates the view is a work center view.

Name

User-defined name of the view.

Description

Description of the contents of the view.

Level

Access level for the view. These are the valid levels: Personal

The view is available to the current user only. Note: Personal views are saved under the name of the user.

3

Shared

The view is available to all users.

System

This is the predefined, default view.

Click on the default system view to use it as a template for creating the new view: Type

Name

Description

Level

wc

default

default view

system

Note:

The default system view is used as a template in this example. All existing views can be copied to create new personal or shared views.

413

ASG-Zeke Scheduling for z/OS User’s Guide

Note:

You also could click on any other existing view to use it as a template instead of the default view. The Zeke View Maintenance customization screen appears:

From this screen, you can edit the default system view to create a new view. Or

You can switch to another view. Select one from the Views: drop down list, and click Select.

414

10 Zeke Web Services

4

5

In the Select View Columns section, choose the information that you want to display in this view. You can select a maximum of 13 columns, which will appear in the view in the sequence indicated by the column numbers. a

For Column # 01, select a heading from the drop-down list to indicate the information you want to appear in the first column.

b

Select the Visible check box to enable the column to appear in the view.

c

Repeat steps a and b for each additional column you want to add to the view.

In the Select Filters section, complete these fields: Field

Description

Status

Display only the work centers with the specified status. Select one of these statuses from the drop-down list:

Event

All

Default. All work centers.

Not Done

Work centers waiting to be completed.

Pending

Work centers that are currently being processing and are pending completion.

Done

Work centers that have been completed.

Disabled

Work centers that have been disabled.

Display only the work centers with the specified event number.

You can specify wildcard characters in any of the filtering criteria below: • Specify * to match one or more characters. • Specify ? to match any single character value.

6

Appl

Display only the work centers with the specified application ID.

Group

Display only the work centers with the specified group ID.

Event Name

Display only the work centers with the specified event name.

System

Display only the work centers with the specified system ID.

Version

Display only the work centers with the specified version number.

User

Display only the work centers with the specified user ID.

Select the Enabled check box to enable the specified filters. 415

ASG-Zeke Scheduling for z/OS User’s Guide

7

In the Update View section, complete these fields: Field

Description

View Name

Specify a name for the new view.

Description

Specify a description for the new view.

8

Select the Shared check box if you want to make this view available to all users.

9

Click Save to create the new view and return to the All Views list. The default system view is retained.

Updating a View Typically, you manage and update views through the View Maintenance function. You also can access and update a view directly from the Work Center List.

To update a view 1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

Click on the highlighted Name of the view you want to update. The Zeke View Maintenance customization screen appears. From this screen, you can update the selected view. Or

You can switch to another view. Select a view from the Views: drop down list, and click Select. 3

416

In the Select View Columns section, update the information you want to display in this view. You can select a maximum of 13 columns (which will appear in the view in the sequence indicated by the column numbers). a

For Column # 01, select a heading from the drop-down list to indicate the information you want to appear in the first column.

b

Select the Visible check box to enable the column to appear in the view.

c

Repeat steps a and b for each additional column you want to add to the view.

10 Zeke Web Services

4

In the Select Filters section, update these fields: Field

Description

Status

Display only the work centers with the specified status. Select one of these statuses from the drop-down list:

Event

All

Default. All work centers.

Not Done

Work centers waiting to be completed.

Pending

Work centers that are currently being processing and are pending completion.

Done

Work centers that have been completed.

Disabled

Work centers that have been disabled.

Display only the work centers with the specified event number.

You can specify wildcard characters in any of the filtering criteria below: • Specify * to match one or more characters. • Specify ? to match any single character value. Appl

Display only the work centers with the specified application ID.

Group

Display only the work centers with the specified group ID.

Event Name

Display only the work centers with the specified event name.

System

Display only the work centers with the specified system ID.

Version

Display only the work centers with the specified version number.

User

Display only the work centers with the specified user ID.

5

Select the Enabled check box to enable the specified filters.

6

In the Update View section, update the View Name or Description, as desired. Note:

If you update the view name or description, a new view is created with these attributes and the existing view is retained with its previous name (and can be deleted later, if desired). 7

Update the Shared setting indicating whether you want to make the view available to other users. 417

ASG-Zeke Scheduling for z/OS User’s Guide

8

Click Save to update the view and return to the All Views list.

Deleting a View Typically, you manage views (including deleting them) through the View Maintenance function. You also can access and delete a view directly from the Work Center List.

To delete a view 1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click View Maintenance. The All Views list appears.

3

Click on the highlighted Name of the view you want to delete. The Zeke View Maintenance customization screen appears.

4

Click Delete to delete the view and return to the All Views list.

Completing a Work Center Completing a work center requires one of these actions from the operator: •

Manually verifying and indicating that the work center’s required conditions or actions have been met.

•

Setting a variable value. Note:

Some variables are read-only and cannot be changed.

To complete a work center

418

1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click Work Center List.

3

Optional. Select a view from the Views drop-down list to narrow down the list of work centers (e.g., only the work centers that are not completed yet).

10 Zeke Web Services

4

Locate the work center that you want to complete, and right-click the work center for a context-menu:

5

Select Complete Work Center to mark the work center for completion. The work center status changes to Pending. This status enables you to review documentation or update variables, if necessary.

6

If you have already performed the required work center activity, skip to step 7 on page 420. Or

If you need to review the work center information or documentation, or the work center activity requires you to update a variable, click the event number.

419

ASG-Zeke Scheduling for z/OS User’s Guide

The Work Center View appears:

Note:

At any time, you can click Cancel to cancel any changes and return the work center to its previous state (i.e., Pending or Not Done), and return to the Work Center list. 7

Click Complete to complete the work center. The work center status changes to Complete.

Viewing Documentation You can view work center text, scratch, or note documentation from a Web browser; however, you cannot edit the documentation.

To view work center documentation

420

1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click Work Center List.

10 Zeke Web Services

3

Locate the work center for which you want to view documentation.

4

Click on the Name of the work center event. Or

Right-click for a context-menu and select View Work Center. The Work Center View screen appears. 5

Click on the appropriate tab for the type of documentation you want to view. These figures illustrate the documentation tab for each documentation type: Figure 3 • Sample Scratch Pad Doc

Figure 4 • Sample Text Doc

Figure 5 • Sample Note Doc

\

421

ASG-Zeke Scheduling for z/OS User’s Guide

6

From this screen, you can view the documentation or you can complete, enable/disable, or refresh the work center. Or

Click Cancel to return to the Work Center List.

Setting a Variable Successfully completing a work center could include requiring the operator to set a variable value.

To set a variable

422

1

Select the Variables tab:

2

Click Complete. This enables the New Value field.

3

In the New Value field, enter the new variable value.

4

Click Submit.

10 Zeke Web Services

The work center Status is changed to Complete.

Enabling or Disabling a Work Center You can disable a work center that is in any status other than Complete. Disabling a work center event leaves it in the schedule, but Zeke proceeds with event dispatching as if that event were not in the schedule. Disabling an event can affect dependencies, but does not affect the EMR or prevent the event from being included in a future schedule. You can enable a work center that has been disabled (which treats the event normally again).

Disabling a Work Center You can disable a work center that has not been completed yet, so that Zeke proceeds with event dispatching as if the event were not in the schedule.

To disable a work center 1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click Work Center List.

3

Optional. Select a view from the Views drop-down list to narrow down the list of work centers.

4

Locate the work center that you want to disable and right-click for a context-menu.

5

Click Disable Work Center.

The work center’s status is changed to Disabled.

Enabling a Work Center You can enable a work center that has been disabled.

To enable a work center 1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click Work Center List.

3

Optional. Select a view from the Views drop-down list to narrow down the list of work centers.

423

ASG-Zeke Scheduling for z/OS User’s Guide

4

Locate the disabled work center that you want to enable and right-click for a context-menu.

5

Click Enable Work Center.

The work center is enabled and its status is changed to Not Done.

Refreshing a Work Center Refreshing a work center resets its status to Not Done. You can refresh a work center that is Pending, Disabled, or Complete. All prerequisite conditions must be satisfied again.

To refresh a work center 1

Start the Web interface as described in “Accessing Zeke Web Services” on page 408.

2

From the Zeke Web Services home page, click Work Center List.

3

Locate the work center you want to refresh. a

Click on the Name of the work center event. The Work Center View screen appears.

b

Click Refresh.

Or

c

Right-click for a context-menu and select Refresh Work Center.

The work center is refreshed and its status is changed to Not Done.

424

A

Appendix A:

Appendix A Zeke “Agentless”

The Zeke Agentless program (ZEKE6NOA) enables you to run Zeke jobs on other platforms without the need to install OASIS/DMS or a Zeke Agent on the target machine. It utilizes scp (for secure remote file copy) and ssh (for remote login and command execution) to send a job defined in Zeke to another system. Unlike when sending jobs to an actual Zeke Agent, Zeke uses JES and an initiator to dispatch the job to the target machine rather than dispatching it directly to the target machine. Note:

The scheduled event download feature (available with Zeke Agent) is not available with the Agentless program. Any target platform that has ssh on it is supported. For example, Linux and Unix have ssh as part of the operating system; ssh is available as an add-on for many other operating systems. All standard ssh implementations are supported. If you have current Zeke Agents that you want to replace with the Agentless program, you must update your Zeke jobs to call the Agentless program and pass the correct information. When executed, the Agentless program sends the job script to the remote box and issues the commands necessary to execute it. The program then waits until the script finishes and returns a status; this status is passed back to Zeke. Note:

The job status passed to Zeke is dependent on the return code that is returned by the ssh command to the calling program. If the status is greater than 4095, the return status is reflected as 4095, and you must check the logs for the exact error.

425

ASG-Zeke Scheduling for z/OS User’s Guide

System Requirements These are the system requirements for using the Zeke Agentless program: •

USS must be configured on the z/OS system.

•

At least one user account must be configured to use the HFS file system.

•

ssh must be configured on the z/OS system and on all target machines that will receive work through the Agentless program. The ssh protocol must be version 2.

•

Because Zeke does not know a user’s password, ssh must be configured so that it does not require a password. Caution! Keep in mind that if the ssh approved user logs on to USS, the user can send any command to ssh on the configured box.

•

Scripts for the jobs must be located in the HFS file system.

•

Output from the jobs either must be directed to the HFS file system or must not be trapped.

Installation and Configuration This section provides instructions for installing and configuring the Zeke Agentless program (ZEKENOA).

To install Zeke Agentless 1

Be sure that USS is configured on the z/OS system.

2

Copy the ZEKE6NOA executable from the Zeke LINKLIB to the HFS system. You can copy the executable into any directory (as long as the necessary protection is set to allow access to approved users). For example, if your Zeke LINKLIB is named ZEKE.LINKLIB and the target directory for the executable is /var, you can use this TSO command: OPUTX 'ZEKE.LINKLIB(ZEKE6NOA)' '/var/zeke6noa' ASIS

A response similar to this will appear: Linking 'ZEKE.LINKLIB(ZEKE6NOA)' as /var/zeke6noa

3

426

Configure ssh on the z/OS system and all target machines that will receive work through the Agentless program. (Refer to your operating system documentation for the z/OS and target platforms for details.)

Appendix A - Zeke “Agentless”

4

Log on to the USS side of the LPAR where Zeke runs. Be sure to log on as an authorized user for running the jobs.

5

Generate the set of keys to allow ssh to operate. For example, on an AIX machine, enter this command: $ ssh-keygen -t dsa Note:

This example creates a dsa key set; however, you also can use rsa. When you are prompted to enter a passphrase, do not enter one. Sample output (where mysystem is the hostname): Generating public/private dsa key pair. Enter file in which to save the key (/u/user1/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /u/user1/.ssh/id_dsa. Your public key has been saved in /u/user1/.ssh/id_dsa.pub. The key fingerprint is: a9:77:ba:74:22:3d:0e:b3:d7:04:01:81:d9:24:6b:46 user1@mysystem

6

Export the public key. For example, on an AIX machine, enter this command: $ ssh-keygen -f $HOME/.ssh/id_dsa.pub -e > public.export

7

Use FTP to transfer the file public.export to the target machine in ASCII format.

8

Log on to the target machine as the user under which the jobs will run.

9

Import the key. For example, on an AIX machine, enter this command: ssh-keygen -i -f public.export >> $HOME/.ssh/authorized_keys

10

Because Zeke does not know a user’s password, you first must call ssh to the target machine and provide the necessary passwords. Log on to the USS side of the LPAR as in step 4, then run an ssh command. If you are prompted whether you want to continue connecting, enter yes. When you are prompted, enter the user’s password. For example, on an AIX machine, enter this command: ssh -l user1 mysystem "uname -a"

427

ASG-Zeke Scheduling for z/OS User’s Guide

where mysystem is the hostname. Sample output: The authenticity of host 'mysystem (10.107.15.45)' can't be established. RSA key fingerprint is 5f:ae:92:87:01:71:ee:ae:77:56:5f:75:3c:ca:2c:e1. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'mysystem,10.107.15.45' (RSA) to the list of known hosts. User1@mysystem's password:

11

Rerun the command. If the configuration is correct, you are not prompted to answer any questions. For example: ssh -l user1 mysystem "uname -a"

12

Repeat this procedure for all users and all target machines.

13

Place your job scripts in the HFS file system. Output from the jobs must either be directed to the HFS file system or must not be trapped. See “JCL Requirements” on page 428 for details.

JCL Requirements Note:

Due to IBM restrictions, the Zeke Agentless program (ZEKE6NOA) can be run only from the USS environment. Your Zeke JCL must satisfy these requirements: •

Your scripts must be specified by a DD statement for STDIN and must reside in the HFS.

•

If you want the output from the jobs, you must define DD statements for STDOUT and STDERR and they must reside in the HFS.

•

The jobs must run under a user ID that has been set up in ssh.

•

The Zeke and OASIS LINKLIBs must either be STEPLIB’d in the JCL or be defined in the user’s USS login procedure.

•

The scripts must include parameters for the Zeke subsystem name, destination, and username: —

428

The Zeke subsystem name is the name of the Zeke subsystem that submitted the job (which is used to verify that Zeke is running).

Appendix A - Zeke “Agentless”

—

The destination is the IP address or hostname of the target machine where the job is to be sent.

—

The user name is the user ID that the job will run under on the target machine.

Figure 6 is a sample script: Figure 6 • Sample Script

//ASGSSH // //STEP1 // //STDIN // // //STDOUT // // //STDERR // // //

JOB (10039),CLASS=A,MSGCLASS=X,NOTIFY=ASGU1, USER=ASGU1 EXEC PGM=BPXBATCH, PARM='sh /var/zeke6noa ZEKA mysystem.mycompany.com user1' DD PATH='/u/asgu1/script.sh', PATHOPTS=(ORDONLY), PATHMODE=SIRWXU DD PATH='/u/asgu1/script.stdout', PATHOPTS=(OWRONLY,OCREAT,OTRUNC), PATHMODE=SIRWXU DD PATH='/u/asgu1/script.stderr', PATHOPTS=(OWRONLY,OCREAT,OTRUNC), PATHMODE=SIRWXU

where: ASGU1 is the ID of the mainframe user running the job. This user must have authority to issue ssh commands to the target machine. mysystem.mycompany.com is the target machine. /var/zeke6noa is the path to the Zeke Agentless program. ZEKA is the Zeke subsystem name. user1 is the user ID on the target machine. /u/asgu1/script.sh is the script to be run on the target machine. /u/asgu1/script.stdout is the output of the command. /u/asgu1/script.stderr is the error output of the command.

429

ASG-Zeke Scheduling for z/OS User’s Guide

ZEKE6NOA Command This section explains how to use the ZEKE6NOA command.

Syntax zeke6noa [-dlwV] zekesubsystem destination username [home]

Parameters These are the valid parameters for the ZEKE6NOA command:

430

Parameter

Description

zekesubsystem

The subsystem name for the Zeke executing the command.

destination

The machine where the script is to be sent.

username

The user ID under which the script is to be run.

home

Optional. The home directory for the user on the Windows box (if applicable). Include this parameter only if ssh does not know home directory already.

-d

Optional. This flag indicates to print debugging information.

-l

This flag indicates that you do not want output returned.

-w

This flag indicates a Windows job (if applicable). This causes .bat files to be created and prevents ??? from being appended to the command (as is done normally for UNIX). Some ssh on Windows (e.g., OpenSSH) require this flag.

-V

This flag indicates to print the version number.

B

Appendix B:

Appendix B Interface to ThruPut Manager

If you use ThruPut Manager (by MVS Solutions) to automate your batch workflow, Zeke event scheduling information can be made available to ThruPut Manager at the time that Zeke submits the job. For any JCL that is submitted from the Zeke started task, relevant job scheduling data can be specified in JCL comment statements. Even if you do not use ThruPut Manager, inserting relevant Zeke event scheduling data in your JCL can be useful because it enables the JES job log to reference this information. See “Job Networking Options” on page 317 for more information using the ZekeCtl generation option to enable this capability. Note:

Any JCL from CMS, JESQ, or submitted by a user exit (which are not submitted by the Zeke started task) is not supported by this interface. See your ThruPut Manager documentation for more information.

Enabling the ThruPut Manager Interface To enable Zeke’s interface with ThruPut Manager 1

Verify that your ThruPut Manager installation is at the appropriate PTF level to enable the Zeke interface. Note:

Be sure to keep your ThruPut product updated (i.e., to recognize new name/value pairs as they become available).

431

ASG-Zeke Scheduling for z/OS User’s Guide

ZEKECTL Statements When submitting a job event to JES, Zeke inserts comment statements (containing name/value pairs) into the JCL according to these rules: •

Name/value pairs cannot extend past column 71.

•

Name/value pairs are listed alphabetically.

•

Comment statements are inserted after the job statements, except in these cases:

•

•

•

If the PosidEnd generation option is set to Y, then the comment statements are inserted at the end of the job.

•

If the Posid generation option is set to Y, then the comment statements are inserted in front of the Zeke POSID step.

Name/value pairs can contain character, numeric or logic (i.e., true/false) data. •

If the data is logic, then only the name is present (i.e., to indicate a true condition). No name indicates a false condition.

•

All character values are enclosed in single quotes.

Zeke does not supply a name/value pair if its value blank or zero.

Note:

All possible name/value pairs might not be present for all jobs. These are examples of the comment statements that Zeke inserts into the JCL: //*ZEKECTL CAL='A',CATID='C4E6ACDA',DISPID='C8B149BE',DISPSYS='SYSA' //*ZEKECTL DUR=0:01,EVT=1,EVTSYS='SYSA',SDATE=2011/322,SUBSYS='SSSI'

If a ZEKECTL comment statement is present in the JCL, the logic descriptor $ZEKE is set to true to indicate that the job is a Zeke job. Note:

If the JCL is resubmitted manually outside Zeke, then ThruPut Manager will falsely identify the job as a Zeke job. If the job must be resubmitted outside Zeke, you must remove the //*ZEKECTL statements.

432

Appendix B - Interface to ThruPut Manager

Zeke Names This table describes the valid Zeke names in the name/value pairs to be used by ThruPut Manager to create $ZEKE descriptors: Name

Format

Description

Note: An asterisk (*) indicates that the name/value pair always is present in the JCL. character

Event’s application ID from the SQR.

* CAL

character

Event’s calendar ID from the EMR.

* CATID

character

Catalog ID of the Zeke database containing the job event. (This is the same value that is displayed in the CATID field when the ZID operator command is issued.)

CLASSES

character

Event’s job classes from the SQR.

CPU

numeric time mmmmmm:ss

Event’s average CPU time (in minutes and seconds from the EMR. If only seconds, the value will include a leading 0 (zero). For example:

APPL

0:12

* DISPID

character

A unique value that identifies the dispatch of the event (i.e., different dispatches of the same SQR will have different DISPID values).

* DISPSYS

character

Zeke system that dispatched the event.

DPRTY

numeric

Event’s dispatch priority value from the SQR.

DRL

numeric

Event’s disaster recovery level value from the EMR.

DUR

numeric time mmmmmm:ss

Event’s average duration from the SQR. If only seconds, the value will have a leading 0 (zero). For example: 0:03

* EVT

EVTNAME * EVTSYS

GRP

numeric

Event number from the SQR.

character

Event name from the SQR.

character

Event’s system ID from the SQR.

character

Event’s group ID from the SQR.

433

ASG-Zeke Scheduling for z/OS User’s Guide

Name

Format

Description

JCLOVRD

logic

Present (i.e., true) if the event’s JCL was overridden in the SQR; otherwise, not present (i.e., false).

LATESTART

numeric time hh:mm

Event’s ‘late start’ time from the SQR. The possible values are from 00:00 through 48:00.

MANUAL

logic

Present (i.e., true) if the event was added to the schedule manually; otherwise, not present (i.e., false).

MILESTONE

logic

Present (i.e., true) if the event is a milestone; otherwise, not present (i.e., false).

MUSTSTART

numeric date/time yyyy/ddd. hh:mm

The time by which the job must start running in order not to be late. This value is based on the ‘late start’ time in the SQR. If there is no late start time specified, then it is based on the ‘must end’ time minus the average duration in the SQR. If there is no late start or must end time, then MUSTSTART is not present. If MUSTSTART is present, ThruPut Manager will calculate the values of these two descriptors when it evaluates the job:

$ZEKE_MUSTSTART_WITHIN

Number of minutes until the job’s ‘must start’ time. This value is calculated by ThruPut Manager when it evaluates the job (i.e., by subtracting the current time from the MUSTSTART time). This value is set to zero if the result of the calculation is negative. If MUSTSTART is not present, this value defaults to 9999 if $ZEKE is true, or 0000 if $ZEKE is false.

434

Appendix B - Interface to ThruPut Manager

Name

Format

Description

$ZEKE_MUSTSTART_LATE_BY

Number of minutes after the job’s ‘must start’ time. This value is calculated by ThruPut Manager when it evaluates the job (i.e., by subtracting the MUSTSTART time from the current time. This value is set to zero if the result of the calculation is negative. If MUSTSTART is not present, this value defaults to 0000.

These calculated descriptors can be used in ThruPut Manager JAL to give priority to a job based on its ‘must start’ time. For example: Evaluate Zeke_Job $Zeke_MustStart_Late_By $Zeke_Muststart_Within … If (Zeke_Job) If (Very_Late) Set Priority( 15 ) OrIf (Slightly_Late) Set Priority( 14 ) OrIf (Soon) Set Priority( 12 ) OrIf (Pretty_Soon) Set Priority( 10 ) OrIf (Next_Shift) Set Priority( 8 ) Otherwise Set Priority( 6 ) EndIf EndIf

($Zeke(Yes)) 0,Not_Late,1,Slightly_Late,30,Very_Late 0,Soon,60,Pretty_Soon,240,Next_Shift,480,Long_Time

PDSDD

character

DD name of the PDS file that contains the event’s JCL from the SQR. The DD name is not present if the event’s JCL source is not PDS.

PDSMEM

character

Name of the member in the PDS file specified by PDSDD that contains the event’s JCL from the SQR. It is not present if the event’s JCL source is not PDS.

RESTART

logic

Present (i.e., true) if the event was restarted; otherwise, not present (i.e., false).

SCHED

numeric time hh:mm

Event’s schedule time from the schedule record. The possible value are from 00:00 through 48:00.

* SDATE

numeric date yyyy/ddd

Event’s schedule date from the schedule SQR.

435

ASG-Zeke Scheduling for z/OS User’s Guide

Name

Format

Description

* SUBSYS

character

Zeke subsystem that dispatched the event. (This is the same value that is displayed in the SUBSYS field when the ZID operator command is issued.)

USERID

character

Event’s user ID from the SQR.

VER

numeric

Eevent’s version number from the SQR.

ThruPut Manager Descriptors ThruPut Manager translates the name/value pairs into descriptors, which then can be used in Job Action Language (JAL) and Detailed Action Language (DAL). The descriptor names use this format: $ZEKE_name

where name is the name in the name/value pair. For example, the Zeke name/value EVT=1 becomes $ZEKE_EVT with a value of 1. If a name/value pair is not present, the descriptor’s value is zero (for a numeric descriptor), blank (for a character descriptor), or false (for a logic descriptor), unless noted otherwise in “Zeke Names” on page 433. If a name/value pair is not known to ThruPut Manager or contains a syntax error, then ThruPut Manager issues a warning message and the associated descriptor does not become available in ThruPut Manager; however, the job continues to execute normally.

$ZEKE_JECL_OK ThruPut Manager uses the logic descriptor $ZEKE_JECL_OK to indicate successful parsing. A value of true for this descriptor indicates a successful parse. If a problem occurs, ThruPut Manager will set $ZEKE_JECL_OK to false. In this case, for example, the user could fail the job in JAL or simply ignore all $ZEKE descriptors.

436

Index

Symbols * (asterisk) used with generic names for dependencies 128, 130 job types 59 special calendars 44 A adding events by path 55–57, 252 alerts OpsCentral 238 ALTER, Schedule View command 194 Audit Log Facility logging in the Audit Log database 296 job’s status changes 296 Zeke operator commands 296 tracking Zeke database activity 296 updating audit actions 296 audit options 296 auto replies disabling 164 displaying 163 enabling 163 managing Zack Fastpath/Autoreply tables from Zeke 36 responding to outstanding replies 159 setting generation options 159–160 using the AUTORPLY function 161 Automation option, managing Zack Fastpath/Autoreply tables from Zeke 36 B backing up the database 333 using a dataspace 334 C calculating tape drive usage 308 calendars accessing online 40 adding a calendar 41 deleting a calendar 41 description of 8 special calendars 43 standard calendars 42 user accounting calendars 44

overview of user accounting periods 46 CAPS mode 391 class records defining 386 CLIST commands 198 colors, changing ISPF screen 36 commands CLIST 198 command events 89 in SCOM events 366 ISPF 32–33, 53, 85, 170, 228, 354 JCL 217–218 operator 13, 69, 73, 76, 87–90, 93–94, 97, 154, 160, 163, 191, 239–241, 296, 359, 370 auto reply 160 security 377 POWER 89 REXX 198 Schedule View 13, 191, 225 securing 371 system 89 VM 89 ZADD, for Schedule View 247 Zeke start-up 30 ZEKE6NOA 430 ZKILL 31 communication, inter-product controlling 310 completing work centers 155–157 condition codes 11, 143–146 controlling jobstream flow using variables 361 conventions page xi CREATE batch utility setting up Z$CATAL class 376 creating Zeke database 331 cross-platform dependencies 10, 129 D database backup using a dataspace 334 creating Zeke database 331 Zeke started task 336 29

ASG-Zeke Scheduling for z/OS User’s Guide

job information contained in 3 moving the vault database 337 recovery, Zeke started task 339 retrieving JCL 84 shared 312 dataset triggering 134 hold code 208 dataspace database backups using a 334 running simulation against a 190 date format, Schedule View 224 defining permanent events 99 recurring events 99 deleting GENOPTS 293–294 dependencies cross-platform scheduling 10, 129 dataset triggering 134 defining 139 description of 10 EOG (end of group) 135, 137 extended dependencies 124, 138 generic event names 130 grouping multiple phrases 131 maintaining from the EMR (all versions) 140 multiple 130, 133 multiple job versions 124 Not Active 128 see also logical resources processing of 124 referencing started tasks 131 satisfied 124 using variables 131 viewing from the EMR (all versions) 140 WEAK conditions 126 dispatch queue, checking 307 dispatching description of 9 generation options 297 list of prerequisites 10 messages and jobs 300 see also dependencies displaying fields in Schedule View 222 documentation calendars note pad 48 scratch pad 48 text 49 events 164 jobs 30

datasets 170 note pad 168 scratch pad 168 summary of types 7 text 169 variables note pad 353 scratch pad 353 text 354 downloading, setting up a job for 6, 83–84 E early warning alerts, OpsCentral 238 ECDRs, modifying 399 electronic vaulting considerations for using 338 database allocation 338 description of 17 full recovery procedure 338 partial recovery procedure 339 ESI, see security, external security event activating an event 56 adding events to the schedule manually 247 command events 89 copying an event 67 from a template 65 creating from a template 65 deactivating an event 54 job events 69 routing to another system or platform for execution 79 master record accessing 58–59 permanent 5, 98–106 recurring 5, 97–106 resources, accessing 215 routing a job event to another system or platform 79 status codes, in Schedule View 203 templates creating events from a template 65 defining a template 63 work centers 149 event record directory screen 59 exit generation options 309 exporting database records 20 extended dependencies, see under dependencies external security see security

Index

F Fastpath, managing Zack Fastpath/Autoreply tables from Zeke 36 forecasting the schedule 15 G general generation options 309 generation options accessing 281 audit 296 AUR 308 AURINTV 308 AURMSG 308 Calctap 308 COMMCTL 301 DEFDPRTY 300 Defopid 386, 405 DISPDLY 300 DISPSEL 308 DSPIndex 54–55 Eojwake 307 global dispatching 297 exit 309 general 309 JCL 312 scheduling 320 security 324 user interface 325 variables 326 IEFU83 304 Loadcomm 323 local dispatching 297 exit 309 general 309 JCL 312 messages 319 traces 325 MSGWAIT 300 MSPINTRL 300 MULTAP 321 MULTEN 322 MULTGR 321 Multsys 312 MULTUS 322 Netregid 79, 83 Nonwkday 323 OPEROK 300 Posid 79, 83 POSIDEND 318 PRILATE 301

reloading 295 REMTRIG 304 RepJGrp 316 RepJName 316 RepJUser 317 Reqopid 385 RETAIN 302 RETDAYS 302 RETDONE 303 RETPEND 303 Secexitw 386 Secfail 405 Sechide1 406 Sechide2 406 security options 381 Subdata 326 TRIGDT 305 TRIGJOB 305 TRIGRRN 306 WKTRGDN 306 GENOPTs 280–326 accessing 281 adding 287 deleting 293–294 editing 290 reloading 295 viewing pending updates 291 global options dispatching 297 exit 309 general 309 JCL 312 scheduling 320 security 324 user interface 325 variables 326 group overriding on JOB card 316 H help, accessing Zeke ISPF online 32 holding an event 250, 253 I IF clauses within SET statements 366 importing database records 20 initializing the database 331 initiators adding a system 263 specifications 263 copying an initiator record 264 defining initiators 262

31

ASG-Zeke Scheduling for z/OS User’s Guide

deleting a single initiator 264 all initiators for a system 264 determining processing 298 editing an existing initiator 263 system availability 264 installation, setting up Z$CATAL class before running CREATE 376 interfaces, Zebb restart management 197 internal security generation options 381 see security inter-product communication, controlling 310 ISPF menu screens event record directory 59 ISPF online facility changing colors on screens 36 commands 32–33, 53, 85, 170, 228, 354 common fields 33 features 32 logging on 33 screen format 33 Zeke primary menu 36 see also under online J JCL displaying actual execution JCL 197 generation options 312 JCLR, Schedule View line command 195 line commands 217–218 override 228, 316 performing one-time overrides for job events 226 retrieving JCL from the Zeke database 84 substituting variable values 363 syntax checking 236 with JCLPREP 231–233 with JOB/SCAN 233–235 using variables to control jobstream flow 361 to restart a job 362 to trigger jobs 360 validation using ZSCAN 236 with JCLPREP 231 with JOB/SCAN 233 Zeke job control statements 19 JCLPREP, invoking from Schedule View 231–233 job 32

adding jobs to the schedule 251, 255 checking the dispatch queue 307 creating and adding to the schedule at the same time 191 defining 51 dispatching messages and jobs 300 EMR accessing 58 definition of 4 event 69 setting up for downloading 6, 83–84 log, displaying 197 MSG jobs 86 name, overriding on JOB card 316 PCOM jobs 89 predecessors, viewing in Schedule View 196 on the EMR 54–55 refreshing jobs 196 scheduled job, changing via Schedule View 194 SCOM jobs 89–90 successors, viewing in Schedule View 196 on the EMR 54 on the master 56 templates defining 63 VCOM jobs 89 versions, dependencies for 124 ZCOM jobs 89 JOB/SCAN, invoking from Schedule View 233–235 JPREP line command 233 JSCAN line command 22, 235 L late events, early warning alerts in OpsCentral 238 line commands see commands loading the work center to SQT 323 local options dispatching 297 exit 309 general 309 JCL 312 messages 319 trace 325 Logical Day scheduling examples 9, 74, 182 logical resources

Index

copying a resource 272 defining a resource to Zeke 272 defining resources for an event 274 deleting a resource 273 deleting resources for an event 277 description of 257 editing an existing resource 272 maintaining 271

defining 121 grouping multiple phrases 108 list of keywords 107 multiple phrases 107 processing 107 sample clauses 115 scheduling for holidays and weekends 118 using parentheses in 108

logon ISPF online 33 M menus OASIS Primary Menu 35 Zeke Primary Menu 36 messages dispatching 300 display system 197 generation options 319 MSG job 86 multiple Zeke versions 2 MVS User ID 378 N NETREGID 133 Network Hold status 210 NOTDURING processing reason code 210 using logical resources 271 WHEN conditions 127, 134, 197 O OASIS started task 29 starting the 331 starting multiple tasks 29 without Zeke 27 subsystem requirements 2 terminating 30 variables accessing 32 in SET clauses 150 naming 357 overriding variable values temporarily 358 overview 355 setting with XVAR and ?XVAR 150 temporary variables 358 OASIS Primary Menu 35 OCCURS clauses

online see also ISPF online facility operator commands 13, 69, 73, 76, 87–90, 93–94, 97, 154, 160, 163, 191, 239– 241, 296, 359, 370 auto reply 160 securing 377 ZKILL 27 operator hold on an event 250, 253 operator IDs mixed case 391 operator records defining 389 OpsCentral early warning alerts 238 OVAR 32 overriding JCL 195, 228, 316 overriding the group on the JOB card 316 overriding the job name on the JOB card 316 overriding the user ID on the JOB card 317 P partitions determining partition processing 298 PATH master primary command 54 Schedule View line command 196 PathFinder adding events by path 55–57, 252 displaying different levels in the hierarchy 243 non-Zeke jobs in a path 243 PCOM job 89 PDS override, Zeke started task option 229 permanent events 5, 98–106 defining 99 physical resources defining initiators to Zeke 262 defining pools 268 pools adding a pool 269 a system ID 270

33

ASG-Zeke Scheduling for z/OS User’s Guide

definition of 15 deleting a single pool 270 all pools for a system 269 editing an existing pool 269 an existing system 270 POSIDEND 318 POWER commands 89 predecessors, viewing in Schedule View 196 on the EMR 54–55 prerequisites, see dependencies primary commands see commands primary database versus secondary database 338 see also under database primary menu, Zeke 36 R RACF surrogate processing 317 random scheduling dates, creating calendar for 43 reason codes in Schedule View 203 recovery, see disaster recovery level, electronic vaulting recurring events 5, 97–106 defining 99 refreshing jobs 196 refreshing Schedule View 218 reloading GENOPTs 295 remote dependencies 10, 129 RepJGrp generation option 316 RepJName generation option 316 RepJUser generation option 317 rerunning a scheduled job 250, 254 resources checking before dispatch 11 see also logical resources, physical resources restarting jobs using variables 362 Zeke 27 restoring the database 334 RESTORE batch utility setting up Z$CATAL class 376 restricting number of jobs selected 251 system availability initiators 264 retrieving JCL for updating 195 JCL from the Zeke database 84

34

return codes see also condition codes REXX commands 198 RSTRT, interface to Zebb 197 RUN, Schedule View line command 197 S schedule adding a newly created job to the schedule 191 adding events by path 252 event scheduling 247 forecasting 15 job scheduling 251, 255 number 186 record, rerunning 250, 254 SCHEDADD parameter 191 scheduled job definition of 5 displaying 191 recreating 250, 254 status, changing 249, 253 simulation 15, 187 schedule download displaying agents 6, 83 setting up a job for downloading 6, 83–84 schedule queue record, definition of 5 Schedule View accessing event master record information 225 online documentation 225 other online information 224 PathFinder 225 resources for an event 215 work center information 225 adding events to the schedule 247, 251, 255 ALTER line command 194 changing amount of storage for an event 204 class or class list for an event 204 dispatch priority 203 number of tape drives 204 number of times an event is dispatched 204 schedule time 203 scheduled job status 249, 253 sort sequence 220 system or pools 204

Index

way JCL is submitted and executed 205 commands 191 date format 224 description of 13 display fields 222 displaying schedule queue record information 13 scheduled jobs 191 invoking JCLPREP 231–233 invoking JOB/SCAN 233–235 line commands 13, 191, 194, 203, 225 SYSJ, SYSL, and SYSM 197, 236 maintaining JCL 226 placing an operator hold on an event 250, 253 primary commands 192 recreating the scheduled job 250, 254 refreshing the screen 218 repeating the last command entered 206 rerunning a scheduled job 250, 254 restricting the number of jobs selected 251 setting display characteristics 218 sort sequence, changing 221 validating JCL 236 ZCOM option, entering operator commands 240 ZOOM line command 13, 232, 234 scheduling generation options 320 SCOM jobs 89–90 variable substitution within SCOM jobs 366 SECEXITW - specifies work area size 386 SECHIDE1, displaying primary records 406 SECHIDE2, displaying subordinate records 406 secondary database versus primary database 338 see also under database security authority levels 372 building a Zeke security team 370 calls to ZEKE15A 372 sources of 374 commands 371 exit SECEXITW option 386 SECFAIL - what to do if security fails 405

ZEKE15B 376, 386 external security activating ESI 403 advantages over internal security 372 cancelling unauthorized batch job(s) 405 changing the external class name 399 changing the process option, internal class 400 copying an ECDR 400 deleting an ECDR 400 displaying primary records 406 displaying subordinate records 406 elements 393 hard-coded calls 375 main focus 392 modifying ECDRs 399 replacing the ESI class definition record, internal class 403 resource name format 393, 401–403 security class 392 generation options 324 group, overriding on JOB card 316 implementing 370 internal security defining logon ID to Zeke database 385 IDs used 377 not restricting logon access 385 record types used 377 using Zeke security 17 operator commands 377 processing 372 logic 375 securing by function 371 securing by object 370 tracing processing 376 SET clause 150 IF clause within 366 simulation running against a dataspace 190 schedule 15, 187 SMFPRMxx 131 sorting Schedule View 220 SQR, definition of 5 started task OASIS 29 starting 331 Zeke 27–28, 30

35

ASG-Zeke Scheduling for z/OS User’s Guide

database creation 336 database recovery 339 including the Zebb load library 310 PDS override option 229 terminating 31 starting multiple tasks OASIS started task 29 Zeke batch utility 29 Zeke started task 28, 30 start-up commands 30 status, event status in Schedule View 203 STOP command 31 successors, viewing in Schedule View 196 on the EMR 54 on the master 56 surrogate processing 317 SYS1.PARMLIB SMFPRMxx 131 SYSJ, SYSL, and SYSM line commands 197, 236 system commands 89 operating criteria, changing 16, 280 system-dependent variables 359 T tape drives, calculating usage 308 tasks, Zeke started tasks 30 templates creating an event from a template 65 defining 63 temporary OASIS variables 358 terminating OASIS 30 the Zeke started task 31 Zeke 31 using STOP 31 using ZKILL 31 ThruPut Manager interface to Zeke 431–436 traces generation options 325 triggering events, hold code 208 tutorial, accessing Zeke ISPF online 32 TVSET function (temporary variable set) 358 U user ID mixed case 391 overriding on JOB card 317 user interface

36

generation options 325 V validating JCL 226, 231 VAR and ?VAR keywords 150 variables as an event prerequisite 131, 359 controlling jobstream flow using variables 361 deleting a variable 349 generation options 326 in dependencies 360 OASIS, see under OASIS variables overriding variable values temporarily 358 restarting a job using variables 362 setting values 158 setting with VAR and ?VAR 150 substitution activating variable substitution 326 activating/deactivating 365 in JCL 363 within SCOM jobs 366 summary of features 11 system-dependent variables 359 temporary OASIS variables 358 triggering jobs using variables 360 vault database, moving 337 vaulting, see electronic vaulting VCOM job 89 VM commands 89 W WEAK conditions 126 Web Services for work centers 407–424 WHEN conditions see dependencies work centers 149 adding or updating a variable value 158 completing 155–157 confirming variable values 159 disabling an event 157 displaying variables for an event 157 enabling a disabled event 157 loading the work center to SQT 323 managing through the Web 407–424 refreshing an event 157 SET clause 150 setting up work centers 151

Index

X XEOJ/XEOE keywords 124, 138 XVAR and ?XVAR keywords 150 Z Zack, managing Fastpath/Autoreply tables from Zeke 36 ZADD command 247 ZCOM job 89 ZCOM option 247 entering operator commands 240 Zebb load library in the Zeke started task 310 restart management interface 197 Zeke multiple versions of Zeke 2 restarting 27 starting multiple tasks 30 start-up commands 30 terminating 31 using STOP 31 using ZKILL 31 Zeke "Agentless" 425–430 Zeke JCL override 228 Zeke started task 28 database creation 336 database recovery 339 including the Zebb load library 310 PDS override option 229 terminating 31 ZEKE15A 372 ZEKE6NOA command, Zeke Agentless program 430 ZEKE6NOA, Zeke Agentless program 426 ZEKECAT 331 ZEKENEW 331 ZEKEOL command 38 ZEKEXUTL (import/export utility) 20 ZKILL ZKILL COLD command 31 ZKILL TRACK command 31 ZKILL WARM command 31 ZOOM, Schedule View line command using to invoke JCLPREP 232 using to invoke JOB/SCAN 234

37

ASG-Zeke Scheduling for z/OS User’s Guide

38

ASG Worldwide Headquarters Naples Florida USA | asg.com

CD Contents