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


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


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


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


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


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


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


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


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


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


•

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


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


•

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


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


•

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


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


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


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


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


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


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 *

<== If required


Terminating Zeke If multiple OASIS-supported ‘Z’ products are active in the address space, you can use the MVS system command STOP to terminate all active products along with the started task. When you terminate the last (or only) active product in the address space, the started task is terminated automatically.

To terminate Zeke using the STOP command 

Using the STOP command, specify the name of the started task procedure. For example, issue this command to terminate a Zeke started task: STOP ZEKE Note:

The STOP command is the equivalent of the ZKILL COLD command. The ZKILL command terminates Zeke only; any other products in the address space remain active. ZKILL releases Zeke-owned storage and system resources and terminates its subtasks. The COLD, WARM, and TRACK parameters dictate how the ZKILL is processed.

To terminate Zeke using ZKILL 

Issue one of these ZKILL commands to terminate Zeke (depending on the desired result): Command

Result

ZKILL COLD

Terminate all Zeke processing and release all Zeke program and table storage. Any other products in the same address space remain active.

ZKILL WARM

Terminate Zeke dispatching only. Zeke continues to perform all event tracking, triggering, and updates. Any other products in the same address space remain active. Note: If Zeke is cancelled during a COLD start (before the schedule has been loaded for the first time or while a schedule reload is in progress), then the schedule is freed and Zeke is terminated completely.

ZKILL TRACK

Terminate Zeke in the same manner as ZKILL COLD, but keep the SMF exits for Zeke active, and place Zeke in SMF recording mode.

See “ZKILL Command” on page 324 for more information. 31


Using the ISPF Interface The Zeke online facility is a dialog that runs under ISPF/PDF. Because it is a dialog, all ISPF functions (e.g., SPLIT SCREEN and JUMP) are available. You can enter any valid ISPF command on the Command or Option lines. You also can control the PF key settings.

ISPF Features This section describes the key features of the ISPF online facility.

Online Help The online facility includes a tutorial and help system.

To access the tutorial 

Enter T from the Zeke Option Menu.

To access help 

Press F1 from any Zeke online screen.

Primary Commands Primary commands (e.g., ADD, DELETE, BROWSE, and EDIT) are available on most screens. Enter these commands on the Command or Option line to change the mode for the current screen or to switch to another screen. Any screens that enable editing also support all standard ISPF editing commands (e.g., SAVE, EDIT, CANCEL, and END). Note:

A few commands (e.g., CANCEL, COPY, and EDIT) have the same name in ISPF as in Zeke. When you issue these commands in Zeke, they are processed as Zeke commands (not ISPF commands). To use the ISPF command in Zeke when there is a Zeke command by the same name, you must issue it as part of the ISPF EDIT command BUILTIN (e.g., BUILTIN CANCEL). Otherwise, the system assumes you are issuing a Zeke command. See your ISPF documentation for more information on the BUILTIN command.

OVAR Although it is not listed on the screen with the Primary Commands, the OVAR primary command is available from the Command line of any screen. This command enables you to access the OASIS Variable Maintenance screen where you can add, browse, edit, or delete OASIS variables. See the ASG-OASIS for z/OS Reference Guide for details. 32


Line Commands Line commands (e.g., I for Insert, R for Repeat, and D for Delete) are listed under the Line Commands heading on applicable screens. You enter line commands in the Sel field to the left of the corresponding item. Zeke screens that support line commands also support all standard ISPF editing commands (e.g., C for Copy, CC for Copy Block, and TF for Text Flow).

General Screen Information This section describes the standard format of the Zeke ISPF screens (including the fields common to most screens). ASG-Zeke Command or Option Primary command entry line Command ===> Screen Name Varies depending on screen purpose Primary Commands Zeke primary commands Varies by screen function Standard ISPF commands 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


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


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


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


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


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


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


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


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


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


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


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


Desired Result

Action

Access text documentation

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

Access note documentation


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


49


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


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


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


OCCDate


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


OCCDate


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


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


OCCDate


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


OCCDATE


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


OCCDATE


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


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


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


3


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


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


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


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


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


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


EDIT


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


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


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


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


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


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


2

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


EDIT


Class:


3


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


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


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:


83


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


5


6


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


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:


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


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


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


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


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


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.


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


5


6


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


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


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


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


Field

Description

Sched


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


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


5


6


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


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


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


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


95


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


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


5


6


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


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


EDIT


Class:


99


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


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


4


5


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


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


4


5


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


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


EDIT


2

Class:


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


4


5


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


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


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


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


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


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


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


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


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:


2


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


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


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


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


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


•

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


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


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


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


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


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


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


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:


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


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


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


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




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


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.


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




Jobname: SPTEXD11

Operators: Actions: Stepname EOJ CC STEP3 ********

146

System: ZEQA


******** ********

Operator

EQ GT



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




Jobname: SPTEXD11

Operators: Actions:

System: ZEQA


Stepname

Procstep

EOJ CC STEP3 STEP5

******** ********

Operator GT EQ LE


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




Jobname: SPTEXD11

Operators: Actions: Stepname EOJ CC STEP3 STEP5 ********

System: ZEQA


******** ******** ********

Operator

EQ LE GT


RA =Range O = Ok - Range Low High 4 8 0

Action

O O F

147


This is the same scenario, but with a procstep defined: ASG-Zeke Command ===>




Jobname: SPTEXD11

Operators: Actions: Stepname


EOJ CC STEP3 STEP5 ********

System: ZEQA

Operator

PSTEP3 ******** ********


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




Jobname: SPTEXD11

Operators: Actions:

148

System: ZEQA


Stepname

Procstep

Operator

EOJ CC MYSTEP ********

********

EQ GT



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


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


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


2

Complete these fields (as applicable) to define a work center: Field

Description

Template


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


3


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


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


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


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


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


7

Press Enter. The Work Center Control Function screen is displayed in Update mode: ASG-Zeke Command ===>


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


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


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


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


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


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


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

<== <==

MM/DD/YYYY MM/DD/YYYY

The Automatic Reply Element Number is the Zeke-assigned number that identifies the reply element. When there are multiple replies to the same message text, Zeke issues the elements in sequence starting with the lowest number and flags the element as used. If the message is issued more times than there are replies, the last used element is repeated. If a message is defined with only one reply, Zeke issues that reply as many times as needed. 5


Description

Msg Text

Specify the message to which to reply. This does not need to be the whole message (just enough to make a unique match). The message ID usually is a unique identifier.

Reply

Specify the reply that Zeke issues to the message. For example: To enter a null reply

Leave the Reply field blank.

To enter a static reply

Enter a value (e.g., YES).

To use a variable for a reply Enter a variable (e.g., $CURDATE). To use a variable with constant values in a reply

Enter a variable and any appropriate static text. For example: YESTERDAY WAS $(PREVDATE)

Effective As Of

162

Specify the date (MM/DD/YYYY) that the reply becomes effective.

4 Events

6

Field

Description

Effective Until

Specify the date (MM/DD/YYYY) that the reply expires.

JOB STEP NAME

Specify the z/OS job stepname that issues the message text. The auto reply is valid only if this job step issues the message.

Program (EXEC)

Specify the program name that issues the message text. The auto reply is valid only if this program issues the message.


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

Displaying Auto Replies (ZDISPLAY) You can use the ZDISPLAY operator command to perform a wide variety of functions. For example, you can display the active automatic reply elements for a given jobname. If a job event is running, Zeke displays the messages and replies that are active for that job event.

To display active automatic reply elements 

Issue the ZDISPLAY operator command, and include the JOBNAME and REPLY parameters. For example, to display messages and replies for jobname TESTXYZ, issue this command: ZDISPLAY JOB TESTXYZ REPLY

Enabling Auto Replies (ZENABLE) You can use the ZENABLE operator command to perform these actions. •

To reactivate or enable one or more events that were previously disabled using the ZDISABLE operator command.

•

To reactivate the automatic reply elements for an event that had automatic replies disabled.

A disabled event that was scheduled for a prior day will most likely have been dropped by the current day's first schedule update.

163


To enable an auto reply for an event 

Issue the ZENABLE operator command, and include the REPLY and EVENT parameters. For example, to enable previously disabled auto replies for event 55, issue this command: ZENABLE EV 55 REP

Disabling Auto Replies (ZDISABLE) You can use the ZDISABLE operator command to perform these functions: •

To deactivate or disable one or more events that were previously enabled using the ZENABLE operator command. The ZDISABLE operator command prevents WHEN conditions for that event from being satisfied.

•

To deactivate the automatic reply elements for an event that had automatic replies enabled.

To disable an auto reply for an event that is not running 

Issue the ZDISABLE operator command, and include the REPLY and EVENT parameters. For example, to disable the auto reply for event 77, issue this command: ZDISABLE REP EV 77

Event Documentation You can use event documentation to store useful information about an event. These are the areas where you can store event documentation:

164

Documentation Type

Description

Dataset

Stores names of datasets used by a job event

Note

Stores brief notes up to 10 lines

Scratch

Stores brief notes up to 10 lines

Text

Stores up to approximately 450 records

4 Events

Accessing Event Documentation You can maintain event documentation through the Event, Schedule View, Documentation, and Work options in the Zeke online facility. You can use all of these options to access the same documentation record. This section describes the Documentation option.

To access event documentation 1

From the Zeke Primary Menu, enter option 7. The Documentation Selection Criteria screen is displayed.

2


Action

Update documentation for which you know the event number

1 Enter EDIT on the Command line. 2 Specify the event number in the Event field. 3 Press Enter. The Documentation Segments screen is displayed. Go to step 4.

Update documentation for which you do not know the event number

1 Enter any character next to the appropriate event type under Event Types and any information you know for any of the Selection Field Masks fields. 2 Press Enter.

165


The Event Documentation Directory is displayed: ASG-Zeke Command ===>

Event Documentation Directory Scroll ==> PAGE

Line Commands: E/E1/E4 - Edit B/Bn - Browse D/D1/D4 - Delete n = 1 through 4 for specific types of documentation

Event -Event Name000001 ZEKE60TST1 000002 ZEKE60TST2 000003 ZEKE60TST3 000004 ZEKE60TST4 000005 ZEKE60TST5 000006 KTEST1 000007 KTEST2 000008 KTEST3 000009 KTEST4 000010 KTEST5 000011 ZEKE60CC 000012 ZEKE60CC 000013 000014 000015 000016

Jobname

TSKKGUT1 TSKKGUT2 TSKKGUT3 TSKKGUT4 TSKKGUT5 SPTEXD11 SPTEXD12

Type MSG MSG MSG MSG MSG JOB JOB JOB JOB JOB JOB JOB WORK VCOM ZCOM SCOM

1 Scratch *

2 Text *

*

*

3 Tape *

4 Note * *

*

*

*

*

*

*

*

*

*

An asterisk (*) indicates the types of documentation that exist for the event. 3


Action

Edit scratch pad documentation for the event

Enter E1 to the left of the Event field, and press Enter.

Edit text documentation for the event


Edit dataset documentation for the event


Edit note documentation for the event

166

Go to “Maintaining Scratch Pad or Note Documentation” on page 168.

Go to “Maintaining Text Documentation” on page 169.

Go to “Maintaining Dataset Documentation” on page 170. Enter E4 to the left of the Event field, and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 168.

4 Events

Desired Result

Action

Delete the specified documentation for the event

Enter Dn to the left of the Event field, and press Enter (where n indicates the documentation type). These are the valid values: 1

Scratch Pad

2

Text

3

Dataset Name List

4

Note Pad The asterisk (*) indicating that documentation for the event exists is deleted, and the message: DOCUMENT RECORD DELETED is displayed.

The Documentation Segments screen is displayed: ASG-Zeke Option ===>


EDIT

Primary Command: DELETE Event: 000031 Jobname: A2345678

Event Name: TESTNAME

System: A

Appl:

Documentation Record Selection Options 1 * SCRATCH 2 * TEXT 3 TAPE 4 * NOTE

Scratch pad Text information Dataset name information Note pad information

An asterisk (*) indicates the types of documentation that exist for the event. 4

Enter one of these codes on the Command line to select the type of documentation to work with: Desired Result

Action


Enter 1, and press Enter.




Go to “Maintaining Text Documentation” on page 169.

167


Desired Result

Action

Access dataset or tape documentation




Go to “Maintaining Dataset Documentation” on page 170.


Maintaining Scratch Pad or Note Documentation Scratch Pad and Note documentation each enable you to define up to 10 lines of information for an event. These documentation areas are like “sticky notes.” They are used to pass notes from shift to shift, or from one department to another. An operator should always review scratch pad or note information before an event runs. These areas also can be used for “quick reference” information. Besides being displayed online and on Zeke reports, you can display this data for events in the current schedule through the Schedule View screen, and even directly at the system console by issuing one of these commands: ZDISPLAY EVENT 99 NOTE Or ZDISPLAY EVENT 99 SCRATCH Note:

Although there are separate documentation areas for scratch pad and note information, the screen layouts, number of lines of text, and fields displayed are identical. This section explains how to maintain both areas.

168

4 Events


Access the Documentation Scratch Pad or Note screen as instructed in “Accessing the Event Definition” on page 58. ASG-Zeke Command ==> Primary Commands: BROWSE


CANCEL

DELETE

EDIT

EDIT

Line 1 SCRATCH TEXT FOR 30-BYTE NAME JOB 2 3 4 5 6 7 8 9 10 Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: A Desc : 30-CHAR NAME NOM Desc2: Early: Sched: 00:00 Late: Freq: Times: 0001 Vmem : 0* Tapes: 000 Average run time: :00 Jcl: ZEKE

2

When adding or updating scratch pad or note information, enter text information in the Line area. You can enter up to 60 characters per line, and up to 10 lines of text.

3


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

169



Access the Text Documentation screen, as instructed in “Accessing Event Documentation” on page 165. ASG-Zeke Command ===> Event: ****** ==MSG> ==MSG> 000001 ******


Scroll ===> PAGE

000031 Jobname: A2345678 Event Name: TESTNAME System: A *************************** Top of Data ***************************** -Warning- The UNDO command is not available until you change your edit profile using the command RECOVERY ON. tHIS JOB USES TEH 30-CHAR NAME. REVIEW ALL 30 CHAR *************************** Bottom of Data **************************

2

Enter the text to the right of the column placeholder field. You can enter up to 80 characters per line, and up to several hundred lines of text. Use standard ISPF editing commands to edit the text.

3

Optional. Press F8 to page forward to access an additional screen. Repeat, as necessary.

4


Maintaining Dataset Documentation You can access dataset documentation for an event through the Events, Schedule View, and Documentation options.

To maintain dataset documentation for an event 1

Access the Data Set Name List screen, as instructed in “Accessing Event Documentation” on page 165. ASG-Zeke Command ===>

Data Set Name List

Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line Event: 000031

EDIT

Jobname: A2345678 System: A

R Repeat Event Name: TESTNAME

I/O T/D Ver --------------Dataset Name-----------------I T 001 JNM.TAPE.STORE ***************************** Bottom of data ******************************

170

4 Events

2


Description

I/O

Specify the dataset type. These are the valid values:

T/D

Ver

I

Default. Input dataset.

O

Output dataset

Specify the dataset media type. These are the valid values: T

Default. Tape.

D

Disk

Specify the dataset version number. The valid values are 001 for the current dataset, 002 for the next most recent dataset, etc. The default value is 001. This field is a required field for input datasets; otherwise, you can leave this field blank.

Dataset Name

3

4

Specify the dataset name.


Action

Delete a line

Enter D to the left of the I/O field, and press Enter.

Insert a new line after this line

Enter I to the left of the I/O field, and press Enter.

Repeat this line

Enter R to the left of the I/O field, and press Enter.


171


Event Activity Accounting Zeke provides you with a record of event accounting information, so you can view the last date and time an EMR was updated (and who updated it). Event accounting also includes information on the last three dispatches of the event, the average duration of the event, and the normal range of durations for the event.

Viewing Event Accounting Information This section explains how to view event accounting information.

To view event accounting information 1

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


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: 333 Desc: TEST JOB KMC Type: JOB Desc2: Event Name: ZEKEKMCASG 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: MBCBR14 JCL--> PDS: Member: Zeke JCL (Y=Yes): Y

172

Class:


4 Events

2

Enter ACC on the Command line, and press Enter. The Event Master Record Accounting screen is displayed: ASG-Zeke Command ===>

Event Master Record Accounting

BROWSE

Primary Commands: BROWSE EDIT Evt: 000333

Type: JOB

Avgdur: 00:12:15 Alert Tolerance: 50

Job: MBCBR14

Ename: ZEKEKMCASG

System: ZEQA

Enable Duration Alerts: Job ran 20 Times Fail if short or long: Normal Range: 00:05:10 - 00:19:20 Clear Duration Stats Y

Dispatched 6 Times Last Update: 01/14/2012 15:33 by BOB Start: 01/14/2012 17:37:00 End: 01/14/2012 17:37:30 Job ID: JOB00006 Version: 1 Sched Date: 01/14/2012 Status: F/FAIL Dispatch Date 01/14/2012 at 17:37:00 Dur: 00:00:30 Cputime: 00:00:01

Tapes: 0 Comp.code C0000

Vmem: 0 Status: F/FAIL

Dispatch Date 01/07/2012 at 11:31:00 Dur: 00:21:55 Cputime: 00:00:01


Vmem: 0 Status: Fail Long



Vmem: 0 Status: Success

Note:

You also can access this screen from the OCCURS screen in the EMR. The screen displays this event activity information: •

Average duration of the job.

•

Whether the DurAlert generation option has been overridden for the event.

•

Number of job runs included in the job’s current duration statistics.

•

Alert tolerance (used to calculate the acceptable range of duration times for the event).

•

Whether the DurFail generation option has been overridden for the event.

•

Acceptable range of duration times for the event. If duration alerts and/or duration failure are enabled for the event, executions that run shorter or longer than this range will generate an alert and/or be marked as failed.

•

Number of times the event has been dispatched.

•

Last date/time the EMR was updated (and the user who updated it).

•

Start date/time of the last execution that ran to completion. (If the job has never dispatched, this field does not appear.)

173


•

Status of the last execution that ran to completion: —

SUCCESS indicates that the event completed successfully (or the event completed successfully after failing once).

—

FAIL indicates that the event ended abnormally.

—

F/SUCC indicates that the event was forced to a successful completion (or the event was forced to a successful completion after failing once).

—

F/FAIL indicates that the event was forced to an abnormal completion.

—

FAIL LONG indicates that the event completed, but was marked as failed because it ran longer than its acceptable range of duration times.

•

End date and end time of the last execution that ran to completion. (If the job has never dispatched, this field does not appear.)

•

Details about the last three dispatches.

Note:

Zeke evaluates and expresses most time values in hours and minutes only; however, because they affect whether (and when) any dependent events are triggered, Zeke evaluates and expresses dispatch and end times in hours, minutes, and seconds. This is especially important for certain extended dependencies. For example, let’s suppose that Job B has an extended dependency on Job A. When Zeke loads Job B into the schedule, Zeke checks 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 otherwise ready to run at 10:30:40 A.M. today (during the same minute), then the XEOJ dependency would be satisfied. If Job A did not end until 10:30:56 A.M. (during the same minute), the XEOJ would not be satisfied and the dependency is treated as an EOJ.

Maintaining Job Duration Statistics, Alerts, and Failures This section explains how Zeke calculates average duration, and how to specify acceptable ranges so that alerts are generated when exceptions occur.

Calculations Done by Zeke The duration of a job event can vary from run to run. Zeke calculates each job event’s average duration and displays this value in the Avgdur field. You can configure Zeke to alert you if a job runs much longer than or shorter than its average duration. You also can configure Zeke to mark these jobs as failed after they are completed. To use either of these features, you must tell Zeke how much variation is acceptable from the average duration.

174

4 Events

Average Duration Zeke calculates a job’s average duration by adding the last 10 execution times, and dividing by 10. If the job has not been dispatched 10 times yet, the sum is divided by the number of times dispatched. (If a job abends, Zeke does not include it in the average duration calculation.) In addition to calculating the Avgdur value, Zeke uses the last 10 runs of a job to calculate the standard deviation, which is a measure of the spread of a series of run durations around the average duration. If a job’s durations are tightly clustered around the average duration, the standard deviation is small; if a job’s durations vary widely, the standard deviation is large. If you want to enable duration alerts and/or failures, you must tell Zeke the amount of deviation that should trigger an alert or failure. This is specified using the Alert Tolerance field.

Alert Tolerance Alert Tolerance a value that ranges from 0 through 100 that Zeke uses to calculate the acceptable range of durations for a job: •

An Alert Tolerance value of 0 indicates that there is no tolerance for deviation from the average duration. Zeke considers any job that runs longer or shorter than the average duration to have run too long or too short. Because this setting is likely to generate many alerts/failures, ASG does not recommended it.

•

An Alert Tolerance value of 100 enables a job deviate from the Avgdur value up to three times the standard deviation. This setting is likely to generate very few alerts.

•

An Alert Tolerance value of 33 enables a job to deviate from the Avgdur value approximately equal to the standard deviation.

•

The default Alert Tolerance value is 50.

When you specify an Alert Tolerance value, Zeke uses the Avgdur, the standard deviation, and the Alert Tolerance to calculate the acceptable range of durations for the job (which are reflected in the Normal Range field). You can experiment with different values in the Alert Tolerance field to see how the Normal Range is affected. You also can modify the Normal Range values directly. In general, the smaller the Alert Tolerance value, the more likely it is that the job will generate a duration alert. ASG recommends that you set this number high enough to avoid frequent alerts—set a low tolerance for critical events, and a high tolerance for noncritical events with a duration that is unpredictable or inconsistent. Because the Alert Tolerance, Normal Range, and Avgdur fields are interdependent, if you attempt to modify more than one field at once, Zeke honors or ignores the changes based on this priority order—Alert Tolerance, then Normal Range (high), then Normal Range (low), then Avgdur. For example, if you change all of these fields, Zeke accepts only the change made to Alert Tolerance and then automatically calculates the Normal Range

175


values. If you change only the Normal Range low value, Zeke calculates the Normal Range high value and the Alert Tolerance. If you change only the Normal Range high value, Zeke calculates the Normal Range low value and the Alert Tolerance. Note:

If you update the Avgdur field, Zeke automatically resets the Job ran xx Times value to 1, and resets the standard deviation to 25 percent of the average duration.

Duration Alerts and Failures You can enable or disable duration alerts and/or failures on a global level for all events (see “Global Duration Alert/Failure Options” on page 177). You also can override these global settings for specific events (see “Enabling or Disabling Job Duration Alerts and Failures” on page 178). Note:

Enabling duration failures does not cause jobs to be cancelled. When a job ends, if its duration fell outside the Normal Range, Zeke marks the job as failed, and issues message Z8T02I. If a job abended or failed due to a condition code record, Zeke does not mark the job as failed (due to its duration). Zeke marks a job as failed only due to its duration if it otherwise would have been marked successful. Zeke marks these jobs as failed to prevent them from triggering successor jobs. Because Zeke needs sufficient history data to determine a job’s normal duration range, you must specify the minimum number of times a job must run before it is eligible to trigger alerts or be failed for running outside its normal range. This is done through the DurCount generation option (see page 177). If a job has not run enough times to satisfy the Durcount generation option, you can increase the Job ran xxx Times value to start generating duration alerts/failures sooner. Keep in mind that the average duration and normal range calculated from only a few runs might not be truly representative of the job’s normal duration, and so the alerts/failures generated might not be appropriate. When a job runs too short or too long, Zeke provides these indications:

176

•

If duration alerts are enabled, Zeke issues message Z0319W to alert that the event is running long, ran long and completed, or ran short and completed.

•

In Schedule View, Zeke highlights the event status if the job is running longer than its Normal Range.

•

On the Schedule View WHY screen, the reason code Event ran long/short indicates that the event has completed, but its duration was longer than or shorter than the acceptable range of duration times (i.e., Normal Range). The reason code Event is running long indicates that the event is active, and is running longer than the acceptable range of duration times (i.e., Normal Range).

4 Events

•

If duration failures are enabled for the event, Zeke issues message Z8T02I to alert that the event failed because it ran outside of its acceptable range of durations.

•

If duration failures are enabled for the event, Zeke assigns the Fail Job Ran Long status when the event is completed. This indicates that the event failed because it ran longer than its acceptable range of duration times (i.e., Normal Range).

•

If duration failures are enabled for the event, Zeke assigns the Fail Job Ran Short status when the event is completed. This indicates that the event failed because it ran shorter than its acceptable range of duration times (i.e., Normal Range).

•

If duration failures are enabled for the event, the Status field on the Event Master Record Accounting screen indicates FAIL LONG for jobs that were marked as failed because the duration was too long, and FAIL SHORT for jobs marked as failed because the duration was too short.

•

If enabled, alerts are also generated in OpsCentral. (OpsCentral alerts are only generated on z/OS systems that have the Zeke server enabled and active.)

Note:

If duration alerts are enabled, each Zeke system in a sysplex issues the alert.

Global Duration Alert/Failure Options These Zeke generation options control (at a system wide level) whether Zeke issues alerts when jobs run long or short, whether Zeke marks jobs that run long or short as failed, and the minimum number of times a job must run before it is eligible to trigger alerts or fail for running outside its Normal Range: Option

Description

DurAlert

Indicates whether Zeke issues a console message (Z0319W) and OpsCentral alerts if a job runs longer or shorter than the acceptable range of duration times. Note: You can override this option for a specific event using the Enable Duration Alerts field in the EMR.

DurCount

Specifies the minimum number of times a job must run before Zeke performs either of these actions: • Uses the event’s duration history to generate duration alerts. • Fails a job that runs longer or shorter than the acceptable range of duration times (the jobs fails only if the DurFail generation option is set to Y, or if the Fail field in the EMR is enabled). 177


Option

Description The default value is 10. Be sure not to specify a value that is too small, so that Zeke has sufficient history data to determine the job’s normal duration range.

DurFail

Indicates whether Zeke fails jobs that run longer or shorter than the acceptable range of duration times. Zeke marks these jobs as failed to prevent them from triggering successor jobs. Note: This option does not cause a job to be cancelled. When a job ends, if its duration fell outside the Normal Range, Zeke marks the job as failed and issues message Z8T02I. If a job abended or failed due to a condition code record, Zeke does not fail the job (due to its duration). Zeke fails a job due to its duration only if it otherwise would have been marked successful. Note: You can override this option for a specific event using the Fail if short or long field in the EMR.

See “Accessing the Zeke Generation Options” on page 281 for details on how to set these options.

Enabling or Disabling Job Duration Alerts and Failures You can enable or disable job duration alerts or failures for a specific event. Note:

You also can enable or disable duration alerts and/or failures globally for all events using the generation options described in, “Global Duration Alert/Failure Options” on page 177. You use the procedure is this section to override the generation options for selected events.

178

4 Events

To enable or disable job duration alerts or failures 1

Access the Event Master Record Accounting screen, as described in “Viewing Event Accounting Information” on page 172: ASG-Zeke Command ===>

Event Master Record Accounting

BROWSE

Primary Commands: BROWSE EDIT Evt: 000333

Type: JOB

Avgdur: 00:12:15 Alert Tolerance: 50

Job: MBCBR14

Ename: ZEKEKMCASG

System: ZEQA

Enable Duration Alerts: Job ran 20 Times Fail if short or long: Normal Range: 00:05:10 - 00:19:20 Clear Duration Stats Y

Dispatched 6 Times Last Update: 01/14/2012 15:33 by BOB Start: 01/14/2012 17:37:00 End: 01/14/2012 17:37:30 Job ID: JOB00006 Version: 1 Sched Date: 01/14/2012 Status: F/FAIL

2



Vmem: 0 Status: F/FAIL



Vmem: 0 Status: Fail Long



Vmem: 0 Status: Success

If the DurAlert generation option is set to Y, and you want to turn alerts off for an event, enter N in the Enable Duration Alerts field. Or

If the DurAlert generation option is set to N, and you want to turn alerts on for an event, enter Y in the Enable Duration Alerts field. 3

If the DurFail generation option is set to Y, and you want to turn the failure option off for an event, enter N in the Fail if short or long field. Or

If the DurFail generation option is set to N, and you want to turn the failure option on for an event, enter Y in the Fail if short or long field. 4

Optional. You can alter the Alert Tolerance, Normal Range, and/or Avgdur values. See “Calculations Done by Zeke” on page 174 for details about how Zeke calculates these values, and how they interact with each other.

179


Note:

If the job has not run enough times to satisfy the DurCount generation option, and you want to start generating duration alerts/failures sooner, you can increase the Job ran xxx Times value to match the DurCount value. Keep in mind that Avgdur and Normal Range values that have been calculated from only a few runs might not be truly representative of the job’s normal duration, and so the generated alerts/failures might not be appropriate. 5


Note:

See “Duration Alerts and Failures” on page 176 for more information on these options.

Considerations for Remote or Downloaded Jobs Duration alerts work for remote jobs (where the SQR target is an OASIS/DMS Netregid or *R) by measuring the time since the BOJ trigger arrived from the execution system. The Fail if job runs short or long option works for remotely dispatched jobs (where the target is a DMS Netregid) only if the target is not configured as a download agent. If the target agent sends the optional NRSJBDUR (job duration) NTU with the EOJ trigger when the job ends, this is used as the basis for the job’s duration. If not, the job’s duration is estimated as the interval between the arrival times of the job’s BOJ and EOJ triggers. (The NRSJBDUR NTU is supported on z/OS and VSE jobs.) Zeke does not issue duration alerts for downloaded jobs; however, you can activate the Fail if job runs short or long option for downloaded jobs.

180

Chapter 5:

5

Creating and Monitoring the Schedule

The main purpose of Zeke is to ensure that your jobs are dispatched in the most efficient and timely order possible. To accomplish this, Zeke enables you to create a schedule of events using the SCHEDULE function. Along with creating a daily schedule of actual events, Zeke also provides ways to forecast a schedule for a future date and to simulate the run of a schedule complete with initiators, tape drives, and any defined logical resources. You can monitor the progress of your scheduled events, as well as intervene, through the ISPF online facility, Schedule View. This chapter discusses these topics: Topic

Page

Logical Day (48-hour Clock)

182

Creating the Zeke Schedule Creating the Schedule Manually Creating the Schedule Automatically

183 184 186

Downloading the Schedule to Zeke Agent

186

Forecasting and Simulating the Schedule Forecasting the Schedule Simulating the Schedule

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

181


Topic

Page

Zeke Dispatching Early Warning Alerts

237 238

/ZCOM Option Modifying PF Keys

239 240

PathFinder

241

Manually Adding Events to the Schedule Using the ZADD Operator Command Using the ADD Function Adding Events By Path

247 247 249 252

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

Logical Day Time

Shift

Start

End

Start

End

1

8:00 A.M.

3:00 P.M.

08:00

15:00

2

3:00 P.M.

11:00 P.M.

15:00

23:00

3

11:00 P.M.

8:00 A.M.

23:00

32:00

In the example, using a logical day, shift 1 starts at 08:00, shift 2 at 15:00, and shift 3 at 23:00. You will notice that the end time for shift 3 is 32:00 as compared to 8:00 A.M. on the normal 12-hour clock. This indicates that the entire eight-hour period of shift 3 is considered to be part of the same logical workday as shifts 1 and 2. When the SCHEDULE function runs, it selects every event within 48 hours to be part of the day’s schedule. For example, if the schedule runs on Monday at 08:00, events are selected if their OCCURS clauses match MONDAY and the schedule time is between 00:00 and 47:59.

182

5 Creating and Monitoring the Schedule

Note:

Zeke never dispatches an event with a schedule time of 48:00 because 47:59 is the cutoff time for dispatching. Use a schedule time of 48:00 for events that you want to place in the schedule, but do not want to dispatch except by operator command. Zeke processes an event that is defined as OCCURS(MONDAY) at 27:00 at the same time as an event that is defined as OCCURS(TUESDAY) at 3:00 A.M. The difference is that the first event is included in Monday’s schedule run, and is considered Monday’s event, while the second event is included in Tuesday’s run: Event

Weekday

Time

Schedule Run Date

A

Monday

27:00

Monday (actually runs on Tuesday)

B

Tuesday

03:00

Tuesday

Creating the Zeke Schedule Zeke uses schedule queue records (SQRs) control scheduling and dispatching. The schedule contains all of the SQRs that have been created for each Zeke system. Zeke creates the SQRs when you execute the SCHEDULE function of the ZEKE batch utility. When you execute the SCHEDULE function, Zeke performs these actions: •

Deletes completed jobs and retains uncompleted events from the previous day’s schedule. Note:

Zeke dispatches events that have no other outstanding dependencies immediately after completing the schedule load. •

Analyzes each event defined in the Zeke database and determines whether the event is scheduled to occur during the upcoming schedule period. Note:

Zeke immediately marks events that have no dispatch time (and are not scheduled for a future date) as time-satisfied.

183


•

Analyzes each scheduled event and determines whether the event needs to be downloaded to a remote Zeke Agent system for processing. Note:

When a schedule is created that contains job events that are specified to be downloaded to a remote Zeke Agent, Zeke compares the subset of the schedule to be downloaded with any existing schedules on the Zeke Agent target before downloading the events. Zeke provides the ZEKE02MX user exit, which enables you to change various fields in the SQRs during the schedule build. See the ASG-Zeke Scheduling for z/OS Installation Guide for more information.

Creating the Schedule Manually When necessary, you can use the SCHEDULE function of the ZEKE batch utility to create the schedule manually. Generally, ASG recommends that you set up Zeke to create the schedule automatically (see “Creating the Schedule Automatically” on page 186).

To execute the SCHEDULE function to create the daily schedule 1

Run a job using the SCHEDULE control statement to create the schedule at least once a day:

//ZEKESCHD JOB //SCHED EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’ //SYSIN DD* SCHEDULE TODAY ACTIVATE DATASPACE /*

Note:

See the ASG-Zeke Scheduling for z/OS Reference Guide for the additional parameters you can use with the SCHEDULE function. 2

Ensure that the schedule load is complete before you execute any other batch schedule runs. The schedule load is complete when this message appears on the console: Z5G03I SCHEDULE LOAD COMPLETE

184


Caution! Do not execute multiple SCHEDULE TODAY ACTIVATE functions simultaneously in the same batch job, or while any system is in WARM mode (ZKILL WARM). Unpredictable results could occur during a schedule load in these cases. Note:

In a Zekeplex (where multiple systems share a database), each Zeke system runs its schedule table load simultaneously with the schedule creation process by the SCHEDULE function. Each Zeke system’s schedule is updated (through communication records) as the SQRs are updated in the Zeke database. After the SCHEDULE function is complete, one Zeke system satisfies weak, EOG, extended, and variable WHEN conditions, and then the schedule load becomes complete on all systems. Zeke does not perform a separate schedule load process (and data space creation) for each system that shares the database. Simultaneous schedule load—or Simuload—occurs automatically under these conditions: •

The Zekexx startup option PLEXENQ=YES has been specified.

•

The Zekexx startup option PLEXCOMM=XCFONLY has been specified. Or

The Zeke generation option MultSys is set to N. •

The SCHEDULE function keyword DATASPACE is specified (or is the default).

3

Optional. You can use the REPORT parameter with subparameters to produce specific scheduling reports. If you do not specify the REPORT parameter, then all the scheduling reports are produced. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on generating scheduling reports using Report Writer.

4

Optional. You can use the OVERRIDE parameter to include and exclude various events, regardless of their OCCURS clauses. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on selecting events using the OVERRIDE parameter.

5

Optional. You can specify the use of a data space by the SCHEDULE function when processing SQRs. If you use the DATASPACE option, a temporary data space is created when the SCHEDULE function starts, and again before any schedule reports are generated. Note:

See the ASG-Zeke Scheduling for z/OS Reference Guide for more information. 185


Creating the Schedule Automatically ASG recommends that you set Zeke up to create the schedule automatically. Note:

When necessary, you can use the SCHEDULE function to create the schedule manually (see “Creating the Schedule Manually” on page 184).

To set up a job that creates the schedule automatically 1

Define a job event as described in “Defining a Job Event” on page 69. On the EMR, specify the start time plus 24 hours. For example, if you want the schedule to be created every day at 8:00 A.M., enter a start time of 32:00.

2

Specify the appropriate JCL source to include the JCL, as described in “Creating the Schedule Manually” on page 184.

3

Add the OCCURS clause DAILY, so that the job that creates the schedule will run each day. See “Defining an OCCURS Clause” on page 121.

4

This step only has to be performed the first time. Use the ZADD operator command to add the job event with yesterday’s Julian date. For example, if the event number is 100 and today’s date is December 30, 2012, issue this command: ZADD EV 100 DATE 2012363 RDATE 2012363

The schedule job is placed in the queue with yesterday’s date specified as the schedule date and run date. When the start time is reached, the schedule load runs, and then loads itself into the queue for the next day.

Downloading the Schedule to Zeke Agent When it creates the schedule, Zeke checks whether any events in the schedule are specified to be downloaded to a remote Zeke Agent. Zeke checks the Netregid in the SQR (which indicates the event’s target) to determine whether to download the event. Zeke first sends a message to the specified Zeke Agent to determine whether to download the set of events that have been identified for downloading. Zeke generates and uses a unique schedule number to track and synchronize each schedule downloaded to Zeke Agent. If a newly generated schedule number differs from the number of the schedule that currently is downloaded and processing on Zeke Agent, then Zeke downloads the new schedule to Zeke Agent. If the new schedule number matches the number of the current Zeke Agent schedule, then Zeke does not download the schedule.

186


While the SQRs are being downloaded, each event’s download status is reported back to Zeke. If Zeke is unable to download an SQR to its Zeke Agent target, the event is tracked and updated like any other event until it is ready to dispatch. Then, instead of dispatching the event, Zeke places the event on download hold. Later, when Zeke resumes communication with Zeke Agent, Zeke downloads the event and releases it from hold. See "Downloading a Job Event to Zeke Agent" on page 83 and “Defining Schedule Download Agents” on page 327 for more information on how events are downloaded from Zeke to Zeke Agent.

Forecasting and Simulating the Schedule Zeke provides several ways to predict how the schedule will flow without having to actually run the schedule or dispatch events. You can find missing prerequisite conditions, set up a logical schedule flow, and even plan for unusual system downtime or hardware maintenance. Zeke provides these methods for planning or forecasting your schedule (depending on your specific needs): Method

Description

OCCURS hit resolution Enables you to display a calendar showing the days the event will be scheduled. See “Defining an OCCURS Clause” on page 121 for more information. Schedule forecast

Creates a schedule for a future date, which enables you to forecast the schedule and make any necessary changes.

Schedule simulation

Enables you to specify the date, time, system, and resources for an event in the simulation JCL, and then run a schedule simulation.

Forecasting the Schedule To forecast the schedule for a future date, you simply create the schedule without activating and running it.

To create a schedule for a future date 1

Run a job using the SCHEDULE control statement of the ZEKE utility program: •

Include the DATE parameter followed by the future date (in MM/DD/YYYY format) that you want to forecast.

•

Do not include the ACTIVATE parameter. 187


For example:

//ZEKESCHD JOB //SCHED EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’ //SYSIN DD* SCHEDULE DATE 08/23/2012 DATASPACE /*

2

Submit the JCL.

For more information on using the ZEKE utility program to forecast the schedule, see the ASG-Zeke Scheduling for z/OS Reference Guide.

Simulating the Schedule You can perform a simulation creating and running a simulation job (separately from the Zeke program) that specifies the date, time, system, and resources for an event. The Zeke database is copied to another dataset, and then the job flow is simulated against that dataset. (The simulation database must be contiguous.) Caution! Do not run a simulation against your production database; this will destroy the database. Run a simulation only against a database that has been copied for that purpose. Also, ensure that no other Zeke system is running against the same database as a simulation. You can generate these types of simulation reports (depending on which keyword you specify):

188

Keyword

Description

Console

Generate a report of the messages produced during simulation.

Exception

Generate a report of the exceptions that occurred during simulation.

Schedule

Generate the schedule reports (if a schedule run was requested).

Jobflow

Generate a chart of initiator usage.


To run a schedule simulation 1

Execute the SSS4001 program using the SIMULATE control statement (of the ZEKE batch utility program) in the SYSIN. Note:

To simulate schedules accurately, Zeke uses the same programs that process actual schedules. The program used to invoke simulation, SSS4001, also is used to start Zeke. When requesting a simulation, you must specify the SIM option in the ZEKE parameter that specifies the ZEKExx PARMLIB options member; otherwise, Zeke attempts to process an actual schedule. 2

Specify the date, time, and conditions for the simulated schedule using the appropriate parameters. Note:

The attributes STARTDATE, STOPDATE, STARTTIME, and STOPTIME are specified according to a 24-hour clock; however, Zeke dispatches events scheduled on a 48-hour clock at the correct time. 3

Ensure that a ZKSMLOG DD statement with the DCB parameters (i.e., LRECL=256, BLKSIZE=5124, and RECFM=VB) is included in the JCL. This is the simulation log that Zeke uses to generate the reports after completing the simulation. To simulate your current schedule, set the SCHEDRUN and SCHEDCLR parameters to OFF; otherwise, Zeke builds a new schedule, by default.

4

Execute the SIMULATE COPY function to copy the Zeke database before starting the simulation. For example:

COPY SIMULATE

FROMDD=INCAT TODD=OUTCAT STARTDATE 01/01/2012 STARTTIME 23:00 STOPDATE 01/02/2012 STOPTIME 22:59 DATABASEDD OUTCAT SATISFY ALL INITIATORS 10 TAPEDRIVES 5 SYSTEM MVSSPA

REPORT ALL

189


If you want to run the simulation in a data space, use DATASPACE as the value for both the TODD and DATABASEDD parameters. For example:

COPY SIMULATE

FROMDD=INCAT TODD=DATASPACE STARTDATE 01/01/2012 STARTTIME 23:00 STOPDATE 01/02/2012 STOPTIME 22:59 DATABASEDD DATASPACE SATISFY ALL INITIATORS 10 TAPEDRIVES 5 SYSTEM MVSSPA

REPORT ALL

See the ASG-Zeke Scheduling for z/OS Reference Guide for information about running a simulation in a data space. 5

Optional. You can use the REPORT parameter with subparameters to run specific simulation reports. To print simulation reports from a previous run without re-running the simulation, ensure that you save the ZKSMLOG dataset from the previous run. Specify only REPORT parameters in the SYSIN control statements, and point the ZKSMLOG DD to the saved log.

6

Submit the JCL.

For more information on using the ZEKE batch utility to simulate the schedule (including a complete list of simulation parameters), see the ASG-Zeke Scheduling for z/OS Reference Guide.

190


Creating and Adding an Event to the Schedule You also can use the ZEKE batch utility to define a new event, and add it to the schedule at the same time.

To add a new event to the schedule 1

Define the event using the EVENT function of the ZEKE batch utility. See the ASG-Zeke Scheduling for z/OS Reference Guide for more information (including valid parameters).

2

Insert the SCHEDADD parameter at the end of the event definition (as shown in this sample JCL):

//SYSIN DD DATA,DLM=$$ EVENT ADD JCL TESTJOB1 PDS PRODLIB2 MEM TESTJCL2 OCC (MONDAY) SCHEDADD $$

3

Submit the JCL.

Using Schedule View Schedule View displays all scheduled events (SQRs) in the current schedule. From Schedule View, you can monitor, and temporarily update, the events in the schedule using simple line commands. You also can issue Zeke operator commands from the Command line in Schedule View (just like a primary command). Note:

Any changes that you make to an SQR are temporary and only are effective for the current schedule run of the event; no changes are made to the EMR.

Schedule View Commands This section describes the Schedule View commands.

191


Primary Commands You can issued these primary commands from the Command line in Schedule View: Command

Action

ADD

Add events to the schedule through the Add wizard. See “Using the ADD Function” on page 249 for more information.

AUTO

Enable or disable the automatic monitoring function. These are the valid parameters: ON

Default. Monitor the current schedule and automatically refresh the screen with any schedule changes according to a specified time interval.

OFF

Disable the automatic monitoring function. (You also can press any key to disable this function.)

Note: The AUTO command cannot function properly if you are operating in split-screen mode. BROWSE

View the events in the current schedule. See “Displaying Scheduled Events” on page 200 for more information.

DOC

Display the Documentation Segments screen.

EDIT

Update an existing event in the current schedule. See “Updating a Scheduled Event” on page 203 for more information.

INT

Display the two values that control automatic monitoring mode, where the first value, rate, is the number of seconds between automatic refreshes, and the second value, wait. indicates how often Zeke checks for a request to exit AUTO mode. To change the timing of screen refreshes, you can enter this command: INT rate wait

where rate is a range from the wait value to 3660 seconds, and wait is a value ranging from 1 through 255. The default values of both optional parameters is 5. Also, the rate value must be a multiple of the wait value; however, Zeke calculates and adjusts this automatically. For example, to refresh the screen every 10 seconds, and check for an exit AUTO mode request every 5 seconds, enter this command: INT 10 5

EMR

192

Display the Event Master Selection Criteria screen.


Command

Action

SELECT

Refresh the screen with any schedule changes. When you include an event number, then only the specified event is refreshed. Note: When the schedule is refreshed, the cursor remains on the same line number; however, this might not be the same SQR (if the schedule changed during the refresh). See “Refreshing the Screen” on page 218 for more information.

SORT

Rearrange the sequence of the fields on the screen based on the SORT parameters. This action is effective only for the current session. Note: Enter SORT HELP on the command line to display a complete list of SORT parameters and their abbreviations. For more information and to change the display order permanently, see “Sorting Schedule View Information” on page 219.

WORK

Display the Work Center Selection Criteria screen.

These ISPF primary commands are valid on the Command line in Schedule View: Command

Action

X ALL

Exclude all displayed lines.

F ‘STRING’ NEXT

Find the next occurrence of a specified string of text.

F ‘STRING’ FIRST

Find the first occurrence of a specified string of text.

F ‘STRING’ LAST

Find the last occurrence of a specified string of text.

F ‘STRING’ ALL

Find all occurrences of a specified string of text. Note: The FIND ALL command does not display the total number of strings found.

RESET

Re-display a group of lines that were previously suppressed using the EXCLUDE command.

193


Line Commands You can enter one or more of these line commands in the Line Cmd field to update a scheduled event. You can enter line commands for more than one event, and the commands are stacked in the order they appear on the screen. Each time you press F3 or Enter, the next command is executed. These are the valid line commands in Schedule View: Command

Action

?

Display the complete list of line commands.

=

Repeat the last command. You can enter any valid line command for an event, and then enter the equal sign (=) to flag multiple additional events. Each time you press PF3/END, the same line command is issued for the next flagged event.

ADDOK

Add a NEED OPEROK requirement to the selected event’s WHEN conditions (without rebuilding the event).

ALTer

Make any changes directly to the selected event by typing over the existing information. You can apply the same change to any subsequent lines using the equal sign (=) line command.

DEL

Delete the selected event from the schedule.

DIS

Disable the selected event, and remove it from the schedule. To enable the event, you can use the EN line command. Note: The DIS command prevents the event’s WHEN conditions from being satisfied.

DSN

Valid for job events only. Display the Step/DD Level Information screen for the selected event. Note: This function requires Zebb to be active on this Zeke system. Press F3 or Enter to return to Schedule View.

194


Command

Action

EMR

Display the EMR for the selected event. From this display, you also can make changes to its EMR. You can use the REB line command to see the changes to the EMR reflected in Schedule View.

EN

Enable the selected disabled event, and re-add the event to the schedule.

FDEL

Release the resources for the selected event, and then delete the SQR.

FDONE

Force the status of the selected event to DONE (regardless of the status of the resources).

FFAIL

Force the status of the selected event to Failed.

FREB

Release the selected event’s resources, and then re-add the event to the schedule.

FREF

Release the selected event’s resources, refresh the SQR, and then re-add the event to the schedule.

FSUCC

Force the status of the selected event to Success.

Hold

Place an operator hold on the selected event. You can use the REL line command to release the hold.

JCLR

Valid for job events only. Retrieve the actual JCL (from the JCL source) for the selected event, so that you can view or update it. The JCL must reside on the same system where you issue the command. You can issue the ZOOM line command for the same event to display the Schedule View Record Expand Function screen where you can view, update, or delete the JCL. See “Accessing an Expanded SQR (Using ZOOM)” on page 216 for more information. Note: This command is not supported for SQRs that have JESQ as the JCL source.

JPREP

Valid for job events only. Invoke JCLPREP for JCL scanning. See “Invoking ASG-JCLPREP” on page 231 for more information. Note: This command is not supported for SQRs that have JESQ as the JCL source.

195


Command

Action

LDSN

Valid for job events only. Display the List DSN Detail Information screen. Note: This function requires Zebb to be active on this Zeke system. Press F3 or Enter to return to Schedule View.

NOTE

Display any available note text for the selected event.

OK

Enable Zeke to dispatch the selected event. If the OperOk generation option is set to Y, then Zeke requires an operator to issue this command to approve event dispatching.

PATH

Display the Pathfinder screen for the selected event’s predecessors and successors. Specify the number of levels to display. The valid values range from 1 through 9, or you can enter an asterisk (*) to display all levels. For example, to display four levels of predecessor and successor information, issue this command: PATH4

See “PathFinder” on page 241 for more information. PRED

Display the Pathfinder screen to display the events on which the selected event or job is dependent. See “PathFinder” on page 241 for more information.

REB

Rebuild the SQR for the selected event, and re-assign its current status. Note: Rebuilding an event has the same effect as deleting the event from the schedule, and re-adding it.

REBH

Rebuild the SQR for the selected event, and place the event on hold.

REF

Refresh the SQR for the selected event by resetting the event as if it had not yet run. Zeke places a refreshed event on operator hold automatically. You must issue the REL line command to release the event to enable Zeke to dispatch the event.

REL

Release an operator hold on the selected event.

RESO

Display the selected event’s resources, update resource detail, or release a resource from control by an event or system. See “Managing Event Resources” on page 215 for more information.

196


Command

Action

RSTRT

Valid for job events only. Display the Job Restart Management screen for the selected event. Note: This function requires Zebb to be active on this Zeke system. Press F3 or Enter to return to Schedule View.

RUN

Satisfy all conditions for the selected event, and dispatch the event. Note: Zeke ignores any NOTDURING WHEN conditions for the event (until you rebuild the SQR from the EMR).

SCAN

Valid for job events only. Scan and validate the selected event’s JCL that is to be submitted by Zeke. See “Validating JCL” on page 231 for more information. Note: This command is not supported for SQRs that have JESQ as the JCL source.

SUCC

Display the Pathfinder screen for events that are dependent on the selected event or job. See “PathFinder” on page 241 for more information.

SYSx

View the JES2 job output information for the selected event, where x is one of these codes: L

Display all job log information.

M

Display any generated messages.

J

Display the actual, executed JCL.

The SYSM, SYSL, and SYSJ commands are valid only if all of these conditions are met: • You are running an MVS release that supports IBM’s spool browse facility. • You are running JES release 4.x or later. • The job is in the JES spool. TOK

Satisfy the time requirements for the selected event.

197


Command

Action

WHEN

Display and update the WHEN conditions for the selected event during this schedule run. See “Managing WHEN Conditions” on page 213 for more information.

WHY

Display the reasons why the selected event is awaiting execution, and update the WHEN conditions to change the status, if necessary. See “Displaying or Updating an Event Status” on page 206 for more information.

WOK

Satisfy all WHEN conditions for the selected event. See “Managing WHEN Conditions” on page 213 for more information.

WORK

Valid for work center events only. Display the Work Center Selection Criteria menu.

ZEBB

Valid for job events only. Display the Job Functions Menu. Note: This function requires Zebb to be active on this Zeke system. Press F3 or Enter to return to Schedule View.

ZOom

Display the Schedule View Record Expand Function screen for the selected event. This ZOOM screen is similar to the EMR screen, except that changes on the Schedule View Record Expand Function screen are temporary (i.e., only for the current schedule run). See “Accessing an Expanded SQR (Using ZOOM)” on page 216 for more information.

. . . .

Create your own CLIST or REXX command that can be executed from Schedule View. See “Custom Line Commands” on page 199 for more information.

198


Custom Line Commands You can create custom CLIST and REXX commands and execute them from Schedule View). Schedule View line commands can be from 3 to 5 characters long.

To execute a 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

In the Line Cmd field to the left of the selected event, specify the Schedule View line command or the name of a user-defined CLIST or REXX command, and press Enter. The command is executed. This example illustrates the parameters that are passed (using the ZUSER sample in the Zeke SZEKINS0 library): EVENT NUMBER = 00021 VERSION = 00000 SCHEDULE DATE = 2012053 JOB NAME = TSKKGUT1 EVENT TYPE = JOB EVENT NAME = KTEST1 STATUS/REASON CODE = SCHEDULED TIME OK DISPATCH PRIORITY = 50 START TIME = 00:00 LATE DISPATCH TIME = SSYSTEM = ZEQA RUN DATE = 2012053 FREQUENCY = NUMBER OF TIMES = 1 STATUS TIME = 00:00 EARLY DISPATCH TIME = MUST END TIME = NOT AFTER TIME = USER ID = APPLICATION ID = KTEST GROUP IDENTIFICATION = DISPATCHING CLASSES = A NUMBER OF TAPES REQUIRED = VIRTUAL MEMORY REQUIRED = AVERAGE DURATION = 00:00 JES NUMBER = TARGET DESIGNATION = *LOCAL FREQUENCY CALC = S TRIGGER TYPE = A SUBSYSTEM = ZEQA

199


Displaying Scheduled Events You can display all scheduled events in Schedule View, or specify selection criteria to display only a subset of scheduled events.

To display scheduled events in Schedule View 1

From the Zeke Primary Menu, enter option 2. The Schedule Information Selection Criteria screen is displayed: ASG-Zeke Command ===> 1 1 2 3 4

Schedule Information Selection Criteria

Schedule View ZCOM ADD Function ADD by path Event ===>

Schedule Display and Modification Facility List Scheduling System Commands Select Event Records "TO ADD" to Schedule Select Event Records by path Permanently save criteria ===> N

Event Types Selection Field Masks Job: Job Name: Msg: Event Name: Pcom: Application: Work: Group ID: Vcom: User ID: Zcom: System: Scom: Disp Class: REXX: Sched Date: Run Date: Target: Permanent: Milestone:

2

---- Event Status ---Actv: Y Done: Y Pend: Y ABOK: Y Sched: Y Fail: Y Hold: Y FBOK: Y Late: Y FSucc: Y / OperOk: N Needs - TimeOk: N %Actv: \ WhenOk: N

To display all events in the current schedule, enter 1 on the Command line, and press Enter. Schedule View displays all SQRs in the current schedule. Or

To display a selection of events, enter selection criteria in any of these fields, and press Enter:

200

Field

Description

Event Types

Enter any character next to the event types that you want to display.


Field

Description

Selection Field Masks

Enter any information you know about the events that you want to select (e.g., jobname, user ID, run date, etc.). You can use wildcard characters in your selection criteria. You can use an asterisk (*) to represent multiple characters, and/or a question mark (?) to represent a single character. For example: This entry in the Job Name field selects all events with a jobname that begins with ABC: ABC*

This entry in the Job Name field selects all events that begin with A, and end with C, with any character in the second position. A?C

Event Status

For each status, indicate whether that you want to display events with this status. These are the valid values: N

Do not select events with this status for display.

Y

Select events with this status for display.

These are the valid event status codes: Actv

Active events.

Pend

Pending events.

Sched

All scheduled events. To narrow down the selection, you can specify N, and then specify any of these secondary statuses:

Done

Hold

All events on hold.

Late

All events that are late.

Needs OperOK

All events waiting for an operator OK.

Needs TimeOK

All events waiting for a certain time.

Needs WhenOK

All events waiting for particular WHEN conditions to be satisfied.

Events with a status of EOJ or AEOJ. To narrow down the selection, you can specify N, and then specify any of these secondary statuses:

201


Field

Description ABOK

All successful events that failed once. This status is displayed in Schedule View like this: Success Failed Once

Fail

All events that failed. This status is displayed in Schedule View like this: Forced

FBOK

All events that failed once, and then were forced to EOJ. This status is displayed in Schedule View like this: Success Forced Failed Once

FSucc

All events forced to EOJ. This status is displayed in Schedule View like this: Success Forced

Schedule View displays only the SQRs that match the selection criteria: ASG-Zeke Command ===> Event ===>

Schedule View

System=SYSD

BROWSE Scroll ===> PAGE Selected=0000004

2012.022 15:45

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 2012053 MSG ZEKEEVTST1 Queued Need Oper OK 000002 2012053 MSG ZEKEEVTST2 Scheduled Time OK 000003 2012053 MSG ZEKEEVTST3 Scheduled Time OK 000004 2012053 MSG ZEKEEVTST4 Scheduled Time OK 000005 2012053 MSG ZEKEEVTST5 Scheduled Time OK 000006 2012053 TSKKGUT1 JOB KTEST1 Scheduled Time OK 000007 2012053 TSKKGUT2 JOB KTEST2 Success 000008 2012053 TSKKGUT3 JOB KTEST3 Active 90% 000009 2012053 TSKKGUT4 JOB KTEST4 Success 000010 2012053 TSKKGUT5 JOB KTEST5 Success 000011 2012053 SPTEXD11 JOB ZEKEEVCC Scheduled Time OK 000012 2012053 SPTEXD12 JOB ZEKEEVCC Scheduled Time OK 000013 2012053 WORK Scheduled Time OK

From the main Schedule View screen, you can scroll left and right, and up and down, to display all of the SQR fields (depending on how you set your display characteristics). Use the normal ISPF scroll commands LEFT and RIGHT to view additional fields. 202


Schedule View displays a variety of information about each scheduled event (including the event’s status and the reason the event is waiting to execute, if applicable). If an event is running longer than its normal range, Zeke highlights its status. Also, if applicable, Schedule View indicates whether the Zeke system is in a hold state.

Updating a Scheduled Event You can quickly update a scheduled event’s scheduling and dispatching requirements from the main Schedule View screen. If you need to review an entire SQR, and make necessary changes, see “Accessing an Expanded SQR (Using ZOOM)” on page 216.

To update a scheduled event through Schedule View 1


2

Enter EDIT on the Command line, and press Enter to enable Edit mode. From the main Schedule View screen, you can scroll left and right, and up and down, to display all of the SQR fields (depending on how you set your display characteristics). Use the normal ISPF scroll commands LEFT and RIGHT to view additional fields.

3


Action

Display a list of all valid line commands

Enter ? in any Line Cmd field, and press Enter.

Change the event’s dispatch priority

Type over the value in the Dp field, and press Enter.

Change the time the event is scheduled to run

Type over the value in the Start Time field, and press Enter. A value of 00:00 indicates that Zeke dispatches the event according to the WHEN conditions.

203


Desired Result

Action You can update any of these fields to alter other schedule time information: • Late start • Early time • Must time • After time (Notafter) • Average duration • Late end

Change the Zeke system or pool where the job can run

Type over the value in the System field, and press Enter.

Change the number of times Zeke dispatches an event

1 Type over the value in the Cnt field to indicate the number of times that you want Zeke to dispatch the event. Note: Increasing the count will cause the event to run the indicated number of times in this schedule run, but does not give the SQR all of the characteristics of a recurring event (which you can specify only in the EMR). Zeke resets the WHEN conditions for a recurring event at dispatch time, and a recurring event can become WHEN-satisfied even while it is active. See “Defining a Recurring or Permanent Event” on page 97 for more information. 2 Specify the amount of time to wait between dispatches in the Freq field. Note: If you do not enter a time in the Freq field, Zeke dispatches the event as soon as the previous run has completed. 3 Press Enter.

Change the class or class list for the job

Specify the name of the class in the Dsptch Class field, and press Enter.

Change the number of required tape drives

Specify the number of tape drives in the No. Tap field, and press Enter. The valid values range from 0 through 255.

Change the amount of Specify the amount of storage in the Virt Mem field, and storage required by the event press Enter.

204


Desired Result

Action

Change the way Zeke submits and executes JCL

Specify the code indicating the type of job processing to use in the Target field, and press Enter. These are the valid values: *LOCAL Execute the JCL for the job on the dispatching system. *RL

(Remote Limited processing) Dispatch and submit the JCL on one system, and execute the JCL on another system. This option does not support condition code processing.

Change the required scheduling environment

*RF

(Remote Full processing) Dispatch and submit the JCL on one system, and execute the JCL on another system.

*R

(Remote processing) Zeke determines whether to use RL or RF processing based on the job’s minimum required support.

other

OASIS/DMS Netregid of another Zeke system or Zeke Agent where Zeke will dispatch or download the SQR.

Type over the environment name in the Scheduling Environment field with the name (up to 16 characters long) of a different scheduling environment, and press Enter. If you want to remove the requirement and force the job to run, simply clear the environment name. The event will run as soon as its other dispatching requirements are met.

Change the target where Zeke downloads the event

Type over the value in the Target field, and press Enter. From the Schedule Information Selection Criteria screen, enter REB in the Line Cmd field, and press Enter. Zeke rebuilds the schedule and downloads it to Zeke Agent. Note: You can change the Target field only if the event has not been downloaded yet.

205


Desired Result

Action

Repeat the last command entered

1 Enter any valid line command that already has been executed for an event, followed by =, in the Line Cmd Field to flag any additional events for the same action. 2 Press Enter. 3 Continue to press Enter to issue the command for each subsequent, flagged event.

Repeat the last change for subsequent lines

1 Enter ALT in the Line Cmd field for the event that you want to update. 2 Enter = in the Line Cmd field to flag any subsequent lines where that you want to apply the same changes. 3 Press Enter. 4 Continue to press Enter to apply the change to each subsequent, flagged event (until you execute a different line command).

Note:

If you want Zeke to download an event that has been updated to Zeke Agent, then you must rebuild the SQR first.

Displaying or Updating an Event Status Schedule View displays the status of each event in the schedule, the reason an event is awaiting execution, and any WHEN conditions that have not been satisfied for an event version. If necessary, you can display more detailed event status information, and update an event status by satisfying its dispatching requirements and dependencies manually.

206


Event Statuses This table describes the event status codes that Zeke displays in Schedule View: Event Status Code

Description

Active

The event is currently running. The percentage of the event’s average duration is displayed to the right of the status. Zeke highlights the Active status if the event has run beyond its average duration, as displayed on the Event Master Record Accounting screen (see “Viewing Event Accounting Information” on page 172).

Dispatching

Zeke currently is submitting the job event to JES.

Fail

The event ended abnormally.

Fail Forced

The event was forced to an abnormal completion.

Fail Job Ran Long

The event completed, but was marked as failed because it ran longer than its acceptable range of duration times (i.e., its Normal Range).

Fail Job Ran Short

The event completed, but was marked as failed because it ran shorter than its acceptable range of duration times (i.e., its Normal Range).

Queued

The event is in the dispatch queue, but is not yet running.

Scheduled

The event is scheduled, but has not been dispatched yet.

Success

The event has completed successfully.

Success Failed Once

The event ended abnormally, was refreshed, and then finished successfully.

Success Forced

The event was forced to a successful completion.

Success Forced Failed Once

The event was forced to a successful completion after failing once.

207


Event Reason Codes This table describes the codes that Zeke displays in Schedule View to indicate the reason that an event is waiting to be dispatched: Reason Code

Description

Awaiting Retry

Zeke attempted to dispatch the event, but the event failed with a recoverable error. Zeke will attempt to dispatch the event again.

Class Cap

The job event is on hold because the job class maximum capacity has been reached. Zeke will submit the job event to JES when the number of jobs of that class falls below the limit.

Comm Record Wait

The event currently is under multisystem processing. The event is available for dispatching after the associated communication record is processed.

Delayed Dispatch Wait

Zeke has delayed event dispatching due to multisystem processing requirements.

Disabled

The event is disabled, and cannot be dispatched. Note: An active event that has been disabled using the ZDISABLE operator command continues to run to completion, but Zeke ignores it for the purposes of triggering (and no longer tracks it). In this case, the event appears in Schedule View with this status (even after it is completed): ACTIVE DISABLED

208

Download Hold

The event is being downloaded to a Zeke Agent.

DSN Hold

There are multiple SQRs in the schedule with the same event number and the same DSN trigger specified. Because the DsnTrig generation option is set to NT, Zeke did not trigger any of the events, and the events are on hold.

Event ran long/short

The event completed, but its duration was longer than or shorter than its acceptable range of duration times (i.e., its Normal Range).

Event is running long

The event is active, and is running longer than its acceptable range of duration times (i.e., its Normal Range).

Failed Once

The event failed, was refreshed, was rerun, and finished successfully.


Reason Code

Description

Forced

The event was forced to completion without actually being dispatched or run.

Held Class

The job event is on hold because an operator hold was placed on the job class. The job is not be submitted to JES until the operator hold on the job class is released. Note: A held class prevents Zeke from submitting jobs to JES for this job class. This does not prevent jobs from running in that class if they are submitted by a source other than Zeke.

Hold

The event is on hold.

Internal Hold

The event was placed on hold due to an internal Zeke processing error.

JESQ Held Job Wait

The event is on hold in the dispatch queue until a job is found in the JES queue with a matching jobname.

Late

For an event that has not dispatched, either its Late Start time has passed, or based on its average duration, the event is projected to run past its Late End time. For a dispatched event, the event did not complete by its Late End time.

Manual Schedule Wait

The event is one of a group of events that were manually scheduled by a single ZADD command. The event is waiting for the other events in the group to be added, and for any weak and variable conditions to be checked.

Multiple Systems

This status occurs only in a Zekeplex (where the XCFONLY=YES start-up option is specified in the ZEKExx PARMLIB options member). Because event’s specified system ID is a pool, the event can be in multiple dispatch queues. You can issue the WHY command to view the wait statuses across all systems.

Need Initiator

The event is waiting for an available initiator.

Need Logical Resources

The event is waiting for resources. You can issue the ZRESOURCE operator command to display the resources.

Need Oper Ok

The event requires an operator OK before it can be dispatched. You can issue the ZOK operator command to approve dispatching.

209


Reason Code

Description

Need Tape Drives

The required number of tape drives are not available.

Network Hold

The event is on hold due to a networking error. Zeke releases a network hold when the remote scheduler or agent re-registers with Zeke.

Network Time Out

OASIS/DMS timed out while waiting for a response.

New DQT Entry

The event has been newly added to the dispatch queue.

Not After/Must End

The Not After time or the Must End time has been reached.

Notduring Wait

The event is waiting for the completion of a program or job that is specified in the event’s WHEN condition.

OASIS REXX Hold

The REXX event (submitted through OASIS/ECF) abended, and the event is on hold.

Operator Hold

The event is on operator hold because a ZHOLD operator command was issued.

Pending

The event has been dispatched, and is ready to execute.

Posid=No/Rem Hold

The Posid generation option is set to N, and the Control field on the EMR is set to Y. Because these settings prevent Zeke from tracking a remote job event, the event was placed on hold. For Zeke to track a remote job event, Posid must be set to Y; otherwise, Control must be set to N, so that Zeke does not attempt to track the remote job event.

Ready

The event is ready to be dispatched.

Refresh Hold

A ZREFRESH operator command was issued for this event. This event is refreshed, and is on operator hold.

Security Hold

The job is not authorized to run on the platform where it was submitted. The event is on hold.

SCHENV Wait

The job is waiting on the required scheduling environment to become active.

SJCL Hold

Zeke encountered an error reading the JCL while attempting to dispatch the event. The event is on hold.

System Hold

The Zeke dispatching system is on hold. You can issue the ZRELEASE operator command (with the SYSTEM parameter) to release the hold.

210


Reason Code

Description

Time OK

The event has met the schedule time requirements.

VSE Pool Hold

Zeke has attempted to dispatch a pool event on a VSE system when the DispSel generation option is set to N. The event is on hold.

Wait Sched Load

There is a new SQR entry being added to the schedule by the current schedule load. The SQR is available for dispatching when the schedule load is complete.

Weak Resolution Wait

The event has been updated by a communications record, but its weak and variable conditions have not been checked yet.

When OK

All prerequisites have been satisfied.

To display or update event status information 1

Access Schedule View, and locate the desired event (as described in “Displaying Scheduled Events” on page 200).

2

Enter WHY in the Line Cmd field to the left of the selected event version, and press Enter. The Schedule View—WHY screen is displayed: ASG-Zeke Option ===>

Schedule View

Event = 000116 Event Name = MYBR14 Jobname = ZEKBR14 When Vr = 00000 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Event Status <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< Needs Time OK Event is LATE ****** ************************** BOTTOM OF DATA ***************************

For example, for an event with the status Queued, and the reason code Multiple Systems, issuing the WHY command displays the wait reasons for all systems: ASG-Zeke Option ===>

Schedule View

Event = 000005 Event Name = EVENT5 Jobname = ZEKWTOR5 When Vr = N/A >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Event Status <<<<<<<<<<<<<<<<<<<<<<<<<<<<<< ASGSYSD Need Oper OK ASGSYSB System Hold Event was scheduled for system POOLBD or pool POOLBD Needs Operator OK Needs Resource(s) ****** ************************** BOTTOM OF DATA ***************************

211


If the information in the Event Status section includes a system name (e.g., ASGSYSD), this indicates that the SQR is waiting in the dispatch queue on that system. If the status information is not preceded by a system name, this indicates the base SQR on any system. Note:

Zeke uses this screen format only for pooled SQRs in a Zekeplex (where the start-up option PLEXCOMM=XCFONLY has been specified in the ZEKExx options member for all Zekes). In this case, Zeke always displays the system name (even for nonpooled events). 3


Action

Satisfy an individual condition

In the Event Status section, enter any character to the left of the condition that you want to satisfy, and press Enter.

Satisfy or complete an individual WHEN condition

In the Tabular When Conditions section, enter any character to the left of the condition that you want to satisfy or complete, and press Enter. These symbols are displayed to describe the status of the condition:

Satisfy or complete all WHEN conditions

*

Zeke satisfied the condition.

+

An operator command was used to manually satisfy the condition.

#

The condition is satisfied because the event is not in the schedule.

In the Event Status section, enter any character to the left of the statement Needs WHEN OK, and press Enter. If the job is waiting for resources, the Schedule View— Resource screen is displayed. See “Managing Event Resources” on page 215.

4

212

Press F3 to return to the main Schedule View screen.


Managing WHEN Conditions You can satisfy WHEN conditions manually, or update them, through Schedule View. The changes you make are effective only for the current schedule run. Note:

To change a WHEN condition permanently, you must update the condition in the EMR. See “WHEN Condition Keywords” on page 133 for the valid keywords.

To manage WHEN conditions through Schedule View 1


2

Enter WH in the Line Cmd field to the left of the selected event version, and press Enter. The Schedule View—When Conditions screen is displayed: ASG-Zeke Option ===>

Schedule View

Event = 000116 Event Name = MYBR14 Jobname = ZEKBR14 When Vr = 00000 CAPS: ON >>>>>>>>>>>>>>>>>>>>>>>>>> When Conditions <<<<<<<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>>>> English When Conditions <<<<<<<<<<<<<<<<<<<<<<<<< (EOE EVEX VER 2 OR EOJ JOBEO VER 3 OR EOE EVFF VER 2) >>>>>>>>>>>>>>>>>>>>>>>>> Tabular When Conditions <<<<<<<<<<<<<<<<<<<<<<<<< EOE 'EVEX' VER 2 EOJ 'JOBEO' VER 3 EOE 'EVFF' VER 2 ******************************* BOTTOM OF DATA ****************************

3


Action

Update existing WHEN conditions

1 In the English When Conditions section, tab to the blank field after the existing statement. 2 Enter AND or OR, and the specify another WHEN condition (which is appended to the existing statement). Do not add a closing parenthesis to the existing statement.

213


Desired Result

Action The maximum length of a WHEN conditions is 17 lines, or approximately 1360 characters, in total. Zeke removes the blank update field from this section when the maximum is reached. Note: When updating an existing condition in Schedule View, you can add only approximately 120 characters (because of buffer requirements). If you need to specify a dataset dependency that uses a dataset name longer than 120 characters, you must use a Zeke operator command to update the WHEN condition.

Satisfy an individual WHEN condition

Tab to the blank space in front of the condition in the Tabular When Conditions section, and enter any character. These symbols indicate describe the status of the prerequisite:

Satisfy all WHEN conditions

4

214

Press Enter.

*

Zeke satisfied the condition.

+

An operator command was used to manually satisfy the condition.

#

The condition is satisfied because the event is not in the schedule.

Enter WOK in the Line Cmd field for the selected event on the Schedule View screen.


Note:

If you enter WH for a selected work center event, this screen is displayed: ASG-Zeke Option ===>

Schedule View

Event = 000117 Event Name = CLEANERS Jobname = When Vr = 00000 CAPS: ON >>>>>>>>>>>>>>>>>>>>>>>>> When Conditions <<<<<<<<<<<<<<<<<<<<<<<<<< >>>>>>>>>>>>>>>>>>>>>>>>> English Set Conditions <<<<<<<<<<<<<<<<<<<<<<<<< (?XVAR TEST1 EQ 'THIS IS A TEST') >>>>>>>>>>>>>>>>>>>>>>>>> Tabular Set Conditions <<<<<<<<<<<<<<<<<<<<<<<<< ?VAR TEST1 EQ 'THIS IS A TEST' ******************************** BOTTOM OF DATA ***************************

You can follow the same procedures for updating and satisfying WHEN conditions when that you want to update or satisfy SET statements.

Managing Event Resources From Schedule View, you can display the status of a resource required for an event, and release the resource, if necessary. See “Defining Resources for an Event” on page 274 for more information on how resources are defined for an event.

To manage event resources through Schedule View 1


2

Enter RESO in the Line Cmd field to the left of the selected event, and press Enter. The Schedule View—Resource screen is displayed: ASG-Zeke OPTION ===> Event = 000028

Schedule View

Event Name = ZEKEEVTST6

Line Commands: Who - Show holder(s)

Jobname = TSKKGUT1 Rel - Release the resource

Count Mode Sta Event Ver Date Scp Resource Name ============<============================================================> 1 SHR 000028 00000 2012053 GBL INIT1 ******************************** BOTTOM OF DATA ***************************

215


Note:

If there are no resources defined for the event, this message is displayed: **** NO RESOURCE DEFINED **** 3


Action

Release the resource

To the left of the resource, enter REL, and press Enter.

Display the event currently using the resource

To the left of the resource, enter WHO, and press Enter.

Note:

If there are no resources currently being held for the event, this message is displayed: **** RESOURCE NOT HELD **** 4


Accessing an Expanded SQR (Using ZOOM) Schedule View’s ZOOM feature enables you to expand an SQR, so that you can view all information for a selected event, and make any necessary changes. The expanded SQR (i.e., ZOOM screen) looks similar to the EMR, and is maintained in the same way, except that any changes to the event that you make in ZOOM mode are temporary, and only for the current schedule run. Although you can update event information from the Schedule View screen, generally, it is more convenient to edit fields from the Schedule View Record Expand Function screen. For job events, you can browse or edit the job’s JCL directly from the ZOOM screen when the JCL is stored in the Zeke database, a PDS, a Panvalet library, or a Librarian library. To view JCL stored in other repositories, you can request JCL retrieval (which stores a temporary copy in the event). See “Overriding JCL” on page 226 for more information. Note:

See the ASG-Zeke Scheduling for z/OS Installation Guide for information about activating Panvalet and Librarian support in Zeke.

216


To display all information for a scheduled event 1

Access Schedule View, and locate the event that you want to display (as described in “Displaying Scheduled Events” on page 200).

2

Enter ZOOM in the Line Cmd field to the left of the selected 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

D - Delete

Grp:

Mustend:

Notafter:

Freqcalc: S Virt Mem: E - Edit

Usrid:

Trig: A

R - Retrieve

JCL--> Zeke JCL

Note:

If JCL exists for an event, you can browse, delete, edit, or retrieve it from this screen. The screen provides line commands, and indicates the JCL source. 3


To update a scheduled event 1


2

Enter EDIT on the Command line, and press Enter to enable Edit mode. In Edit mode, you can edit any of the highlighted fields. You can scroll left or right to access additional fields. Or

From the Schedule View screen, enter ZOOM in the Line Cmd field beside the desired event and press Enter.

217


The Schedule View Record Expand Function screen is displayed: ASG-Zeke Command ===> Evt: 000028


BROWSE


Job: TSKKGUT1


Dprty: 50 Cntrl: Y

Sched: 00:00

Times: Tapes:

1

LateStrt: LateEnd: 00:00

Freq: AvgDur: 00:00


D - Delete

Grp:

Usrid:

Mustend:


Notafter:

Trig: A

R - Retrieve

JCL--> Zeke JCL

Note:

See “Accessing an Expanded SQR (Using ZOOM)” on page 216 for more information on updating an SQR in ZOOM mode. 3

Update the fields, as necessary, and press Enter.

4

To display or update the event’s JCL, in the blank field to the left of the JCL—> field, enter one of the available JCL line commands. Press Enter. Caution! Changes made to JCL using this method are applied to the EMR. For one-time JCL overrides, see “Overriding JCL” on page 226.

5

Press F3 to return to the Schedule View screen.

Customizing Schedule View You can choose the information that you want to be displayed in Schedule View and the placement of the fields. You also can change the way information is sorted. Any changes that you make to display characteristics are valid only for the current user and are saved in the user’s ISPF profile. Each user can set up Schedule View according to their preferences.

Refreshing the Screen Schedule View monitors the current schedule and automatically refreshes the screen (at specified intervals) with any schedule changes. 218


You can enable or disable the automatic monitoring function, and change the screen refresh rate (when this feature is enabled).

To change the automatic refresh options 1

Access Schedule View (as described in “Displaying Scheduled Events” on page 200).

2

The AUTO ON setting is the default automatic monitoring and refresh mode. To disable this setting, enter AUTO OFF on the Command line. Or

If automatic monitoring and schedule refresh currently are disabled, enter AUTO ON on the Command line to enable these settings. Press Enter. 3

To view the current refresh rate when the automatic monitoring function is enabled, enter INT on the Command line, and press Enter. Two values are displayed, where the first value, rate, is the number of seconds between automatic refreshes, and the second value, wait, indicates how often Zeke checks for a request to exit AUTO mode.

4

To change the timing of screen refreshes, enter INT rate wait where rate is a range from the wait value to 3660 seconds, and wait is a value ranging from 1 through 255. The default values of both optional parameters is 5. Also, the rate value must be a multiple of the wait value; however, Zeke calculates and adjusts this automatically. For example: To refresh the screen every 10 seconds, and check for an exit AUTO mode request every 5 seconds, enter INT 10 5. To refresh the screen every 14 seconds, and check for an exit AUTO mode request every 4 seconds, you could enter INT 14 4; however, Zeke automatically adjusts the refresh rate to 12.

Sorting Schedule View Information You can change the way scheduled event information is sorted in Schedule View. You can set up a default sort sequence, so that your preferred settings are used each time you log in to Zeke. You also can change the sort settings only for the current session, where your default settings are restored the next time you log in to Zeke.

219


To change the default sort sequence 1

From the Zeke Primary Menu, enter option C.3. The Schedule View Sort Setup screen is displayed: ASG-Zeke Command ===>

Schedule View Sort Setup


Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't use; A/D - direction nnn ---

Order A/D --------10 A 20 D 30 A

40

A

Field Description -------------------------------------------------------------Status/Reason Code Schedule Date Event Number ----- Sort uses fields above; fields below are not used ----Application Identification Average Duration CNT (number of times) Dispatching Classes Download Status DP (Dispatch Priority) Early Dispatch Time Event Name Event Type Freq (dispatch interval) Frequency Calc Group Identification

This line serves as a separator on this screen: ----- Sort uses fields above; fields below are not used -----

The fields listed above the line are used for sorting in the user-specified sort order. Unused fields (below the line) are listed alphabetically, for convenience. 2

In the nnn field, perform these steps: a

To remove a field as a sort field, specify the line command 0 next to the field, and press Enter. This moves the field down to the not used section of the table.

b

To include a field as a sort field, enter any value (other than 0) next to the field, and press Enter. This to moves the field up to the used section. The value determines the field’s placement in the sort order.

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 sort sequence, or fields are reordered, the Order values are recalculated for the entire list.

220


In the previous example, the scheduled events are designated to be sorted first by Status/Reason Code, then by Schedule Date, and then by Event Number. The user has specified to use Cnt as the last sort option. 3

Enter A or D in the A/D field to specify an ascending or descending order for the sort, and press Enter. Ascending numerical and alphabetical order is the default sequence. In the example, Status/Reason Code, Event Number, and Cnt will sort in ascending order, and Schedule Date will sort in descending order.

4

Enter END on the Command line to save the changes and return to the previous screen.

To change the sorting sequence temporarily 1

From the Zeke Primary Menu, enter option 2.1. The Schedule View screen is displayed.

2

Enter SORT (followed by a space) and the abbreviation for the fields that you want to use to sort, and press Enter. Separate each field with a comma and no space.

3

Optional. Enter SORT HELP on the Command line, and press Enter to display a list of SORT parameters and their correct syntax.

4

Enter END on the Command line to save the changes and return to the previous screen.

221


Selecting Fields to Display You can select the fields that you want to display in Schedule View, and reorder the placement of those fields.

To format the Schedule View screen layout 1

From the Zeke Primary Menu, enter option C.2. The Schedule View Display Setup screen is displayed: ASG-Zeke Command ===>

Schedule View Display Setup

Row 17 of 33 Scroll ===> PAGE

Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't show nnn ---

Order ----170 180 190 200 210

Field Description *Date Format: YYYYDDD -----------------------------------------------------------------Version Number Frequency Calc Trigger Type 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.


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


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


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.


2


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


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


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


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


BROWSE


Job: TSKKGUT1


Dprty: 50 Cntrl: Y

Sched: 00:00

Times: Tapes:

1


Freq: AvgDur: 00:00


D - Delete

JCL--> Override present in SQR JCL--> Zeke JCL

4

Grp:

Usrid:

Mustend:


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


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


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


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


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


Freq: AvgDur: 00:00


Version: 00000

D - Delete

Grp: G23 Usrid: U2345678

Mustend:


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


Early:

Dprty: 50 Cntrl: Y

Sched: 00:00

Times: Tapes:

1



Freq: AvgDur: 00:00


D - Delete

Mustend:


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

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



Freq: AvgDur: 00:00


Version: 00000

D - Delete


Mustend:


Notafter:

Trig: A

R - Retrieve

e JCL--> PDS: OVERRIDE Member: ABEND806

Validating JCL After you create or edit JCL, you can check it for syntactical errors using one of 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


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


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


BROWSE


Job: TSKKGUT1


Sched: 00:00

Dprty: 50 Cntrl: Y

Times: Tapes:

1


JCL Line Commands: B - Browse JCL--> Zeke JCL

232

D - Delete

Grp:

Mustend:

Notafter:


Usrid:

Trig: A

R - Retrieve


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


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


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


BROWSE


Job: TSKKGUT1


Sched: 00:00

Dprty: 50 Cntrl: Y

Times: Tapes:

1


JCL Line Commands: B - Browse JCL--> Zeke JCL

234

D - Delete

Grp:

Mustend:

Notafter:


Usrid:

Trig: A

R - Retrieve


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


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


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


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.


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


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


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


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


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


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


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


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


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


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


BROWSE


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


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


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


BROWSE


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


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


2


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


BROWSE


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


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


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.


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


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.


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


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


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


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


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


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


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


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


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


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


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


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


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




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


EDIT


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


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


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


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


3

Press Enter. The System Pool Specification screen is displayed: ASG-Zeke Command ===> Pool ID:

System Pool Specification


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


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


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


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


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


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


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


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


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


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


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


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


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


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


This is an example of the detail view by category for the same GENOPT: ASG-Zeke Command ===>

Generation Options

Zeke System: JCRZEKEA

Description:

BROWSE


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


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


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



Option Value --------- ---------==================== Aur: Y

EDIT


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




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


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


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

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


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


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


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.


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


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.


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


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


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


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


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


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


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


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


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


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.


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


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.


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


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


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


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


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


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


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


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


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


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.


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


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


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


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


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


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.


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


F


N


321


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


F


N


Specifies how to handle a ZADD by event name when multiple events have the same name. These are the valid values: A


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


N


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


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


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


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


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


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


NETREGID ===> Primary Commands: ADD DELETE EDIT END Line Commands: D - Delete E - Edit NETREGID Description ****************************************************************************** UNIXAGNT ZEKE AGENT UNIX ******************************* Bottom of data *******************************

3


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


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


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


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.


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


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.


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


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.


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


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.


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


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.


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


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


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


•

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


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


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


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


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)


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


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


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


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


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


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


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


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




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



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.


Access the Documentation Scratch Pad or Note screen as instructed in “Maintaining Variable Documentation” on page 351: ASG-Zeke Command ==>


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


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


Access the Text Documentation screen as instructed in “Maintaining Variable Documentation” on page 351: ASG-Zeke Command ===>


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


•

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


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


•

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 <== Begin with variable=NO /* //ARSTP1 EXEC PGM=PROG1 <== Step 1 //INFILE DD DSN=AR.MASTER.TAPE,DISP=OLD,UNIT=TAPE, // VOL=SER=ARTAPE,LABEL=(1,SL) //SYSPRINT DD SYSOUT=A //* //ARSTP2 EXEC PGM=PROG2 <== Step 2 //OUTFILE DD DSN=AR,MASTER.TAPE,DISP=(NEW,KEEP),UNIT=TAPE, // VOL=SER=ARTAPE,LABEL=(1,SL) //EXCPFILE DD DSN=AR.EXCPS,DISP=(NEW,CATLG),UNIT=SYSDA, // SPACE=(132,(2000,500)) //SYSPRINT DD SYSOUT=A //ARSTP3 EXEC PGM=PROG3 <== Step 3 //RPTS DD DSN=&&AR.REPORTS,UNIT=SYSDA,DISP=(NEW,PASS), // SPACE=(132,(2000,500)) //SYSPRINT DD SYSOUT=A //* //ARSTP4 //TAPEIN //RPTSIN

EXEC DD DD

PGM=PROG4 <== Step 4 DSN=SOME.DATASET,DISP=OLD,UNIT=TAPE DSN=&&AR.REPORTS,DISP=(OLD,DELETE),UNIT=SYSDA

//SYSPRINT //* //CHKEXCP //SYSPRINT //SYSIN SET CODE 20 /* //ARSTP5 //EXCPFILE //SYSPRINT //

DD

SYSOUT=A

EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’ DD SYSOUT=A DD * IF $$$ARFLG NE YES <== Bypass Step 5 if variable=NO EXEC DD DD

PGM=PROG5,=(0,NE,CHKEXCP) <== Step 5 DSN=AR.EXCPS,DISP=(OLD,DELETE) SYSOUT=A

361


In this jobstream, these actions occur: •

An system-dependent variable named $$$ARFLG is set to NO early in the jobstream, so that step 5 normally is skipped.

•

The ZEKEVAR API updates the value of $$$ARFLG if Step 2 (program PROG2) creates the special exceptions file that needs to be processed.

•

If the variable is still set to NO, the CHKEXCP step terminates with a condition code of 20. Otherwise, the condition code is zero.

•

The MVS JCL parameter on the EXEC statement for Step 5 tests the condition code of the previous step. If the condition code is 20, Step 5 is bypassed.

Using Variables to Restart a Job Variables can be used to restart a job at a cancelled step. A variable can save the name of the last job step processed in a jobstream. If any step abends, the job can be restarted at that step. This facility works best when used with a COND=ONLY step. The step which specifies COND=ONLY is executed if any previous step in the jobstream abends. If no abend occurs, the operating system bypasses the step. If an abend occurs, the COND=ONLY step sets up the information for the restart. For example, in this jobstream, the variable $CL01P043STEP saves the restart step name:

//CL01P043 JOB ,MSGLEVEL=(1,1),RESTART=$CL01P043STEP ... JCL FOR STEP 1 /* ... JCL FOR STEP 2 /* ... JCL FOR STEP 3 Last normal step //EOF EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’ Normal end of job //SYSPRINT DD //SYSIN DD * SET VAR $CL01P043STEP EQ * For next job run /* //ABEND EXEC PGM=ZEKESET,COND=ONLY EXEC ONLY IF ABEND OCCURRED //SYSPRINT DD //SYSIN DD * Only if job abends SET VAR $CL01P043STEP EQ LASTSTEP Set VAR to prior step * At this point, you can set a variable * to a value that dispatches a recovery job /* // END OF JOB

The JOB statement contains an MVS restart parameter. This starts job processing at the named step. Because the parameter is a Zeke variable, Zeke supplies the value through the internal reader when the job is submitted. 362

8 Variables

If the job completes normally, ZEKESET sets the variable to asterisk (*); the operating system starts the jobstream at the first job step the next time it runs. The last job step specifies COND=ONLY on its execute statement. If the job completes normally, the operating system bypasses this step. If an abend occurs, this statement sets the variable to the name of the step which abended. When this job is restarted by the ZREFRESH operator command, the first step executed is the one that previously failed (the value of $CL01P043STEP). No external action is necessary. To restart at a step other than the one that abends, issue the ZSET command to set $CL01P043STEP to the desired restart step name. For example, the above jobstream abends in step CLSTP3, but the jobstream needs to be restarted at step CLSTP2. Enter this command to begin processing at CLSTP2 the next time it runs: ZSET VAR $CL01P043STEP EQ CLSTP2

The operating system does not execute the COND=ONLY step (even if the job did not run properly) in any of these conditions: •

A JCL error occurs (i.e., a dataset is missing)

•

The operator cancels the job (i.e., system S222 abend)

•

A complete system failure (i.e., power failure)

If these conditions have an impact on system reliability, use this alternate restart technique. Execute the ZEKESET program between each of the normal job steps in a jobstream. The restart variable can be set to the name of the step that is about to be executed (the step after the ZEKESET step). This ensures that the variable always is set to the step to be restarted (even on full system failures).

Substituting Variable Values in JCL Zeke and OASIS variables can be used in both JCL and non JCL statements submitted to the system by Zeke. If the SubData generation option is set to Y, Zeke scans all statements as the jobstream is submitted through JES. If a variable is found, it is replaced with its current value.

363


Variable substitution is performed while Zeke is writing JCL statements to the JES internal reader. The variables must contain the proper values at job dispatch time. Because of the timing, it is not valid to set values in these ways: •

In one job step and expect the new value to be substituted into a subsequent statement in the same job. The substitution for that statement was already done before the job started with the value of the variable at that time.

•

For statements in procedures that are called from the dispatched job. Zeke does not see the actual statements in the procedure, only the EXEC statement.

To use the variable values on statements in a procedure, code the Zeke or OASIS variable as the value of a parameter on the EXEC statement. Zeke substitutes the value into the EXEC statement and the procedure can substitute this value into the statements in the procedure (e.g., EXEC PROC=TEST1, PARM1=$VAR). During variable substitution, trailing spaces are truncated from character values to a maximum of one trailing space, and leading zeros are truncated from numeric values, leaving one zero if the numeric value is zero. Note:

When variable substitution occurs on JCL statements with line numbers in columns 72 through 80, the line numbers might be shifted to the left if the value substituted in for the variable is shorter than the variable name itself. You can use the Jclcol71 generation option to limit variable substitution to columns 1 through 71. See the ASG-Zeke Scheduling for z/OS Reference Guide for details. These are examples of variable statements and the actual values. Assume that the variables have these values: $X = PR01P001 $Y = 0074

364

Sample Statement

Resolved Statement

//$X.$Y

//PR01P00174

To concatenate two variables, enter a period (.) between them. Zeke discards the period and joins the values of the variables. You also can use variable concatenation to create a variable longer than 64 characters. For example, if $A is 64 characters and $B is 16 characters, then $A.$B = an 80-character value.

//$X $Y

//PR01P001 74

This example leaves a space between the variables.

Explanation

8 Variables

Sample Statement

Resolved Statement

//$X..$Y

//PR01P001.74

//$X JOB, PAYROLL.EDIT

//PR01P001 JOB, If the variable value is longer than the name, the PAYROLL.EDIT data following the variable shifts to the right. If the value is shorter than the name, the data following the variable shifts to the left.

Y EQ $Y

Y EQ 74

The leading zeros are dropped.

$X.ABC

PR01P001ABC

ABC is appended to the value of $X (concatenation).

$X,

PR01P001,

A comma after the variable name is retained with the value.

word$Y

word74

A word adjacent to the variable name remains adjacent to the value.

Explanation If you want the variable and the value to be separated by a period after concatenation, enter two periods between the variable and the value.

You can use these control statements (beginning in column 1) to activate or deactivate variable substitution: Statement

Purpose

ZEKE-CTL NOSUB

Deactivate substitution.

ZEKE-CTL SUB

Reactivate substitution.

During the jobstream submission, Zeke discards the control statement and either activates or deactivates the variable substitution facility accordingly. If the variable substitution facility is deactivated, it remains deactivated until the end of the jobstream, or until a new ZEKE-CTL statement reactivates it. For example, if you use the default substitution prefix and suffix specification VDELIMS=(‘$(‘:’)’) then substitution could be performed on some JCL statements (i.e., generation dataset relative numbers) inadvertently. If you do not want to redefine your substitution prefix and suffix, you can deactivate substitution by including these control statements around the lines on which you do not want substitution performed. For example: ZEKE-CTL NOSUB // DD DISP-SHR,DSN=A.B.C$(nnn) ZEKE-CTL SUB 365


As an alternative, you could code the affected lines using a nested quoted literal, for example: //

DD DISP=SHR,DSN=A.B.C$(‘$(+0)’)

When the SubData generation option is set to Y, variable substitution always is in effect for each new jobstream being submitted (unless the control statements are input to the program ZEKESET). The variable substitution control statements cannot be combined with the Zeke PDS library control statements. Both control statements use the verb ZEKE-CTL, but the operands of the two statements cannot be specified on a single statement. If both statements are desired in a single jobstream, code two separate statements. If you are executing ZEKESET in a PROC and the JCL calling the PROC is passing a SET VAR $... statement in the SYSIN DATA, the calling JCL should contain the ZEKE-CTL NOSUB statement after the EXEC statement to prevent variable substitution on the variables name in the SET VAR $... statements. Note:

The difference between using OPTION NOSUB and ZEKE-CTL NOSUB to turn off variable substitution is that OPTION NOSUB turns it off at statement execution time, while ZEKE-CTL NOSUB turns it off at variable substitution time (just prior to when the event is dispatched). See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on OPTION NOSUB.

IF Clauses On SET Statements IF clauses on SET statements can check certain special names in addition to checking variables. Some of the special names that can be used are JOBNAME, CPUID, TIME, DATE, DAY (of week), and ZEKESTEP. See the ASG-Zeke Scheduling for z/OS Reference Guide for a full list of the special names available. Note:

The difference between special names and Zeke variables is that special names are predefined to Zeke; while Zeke variables are user-defined, and begin with a dollar sign ($).

Variable Substitution in SCOM Events An SCOM event can contain a maximum of 60 characters of commands or responses per line. When using variable substitution in an SCOM, the length of each line must be no longer than 60 bytes (including the values).

366

8 Variables

For example, if you submit this SEND command from an SCOM: SE ‘THIS IS A TEST TEST TEST TEST TEST TEST.’,USER=($ABCVAR)

and this is the value of the variable $ABCVAR: ABCABCABCABCABC

The length of the command as it appears above is exactly 60 bytes. After variable substitution is performed for $ABCVAR, the length of the line will exceed 60 characters. In this case, the line must be modified to be 60 characters or less (including the value).

367


368

Chapter 9:

Security

9 Zeke provides an internal security function as well as 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). Note:

Before attempting to implement Zeke security, read this entire section and the ESI chapter of your ASG-OASIS for z/OS Reference Guide (particularly the section about planning and implementing ESI). This will ensure that you choose the security method that best meets your needs. This chapter discusses these topics: Topic

Page

Preparing for Implementation

370

Zeke Security Processing Security Calls Security Tracing

372 372 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 Security Classes and Resource Names Implementing External Security

392 393 398

369


Preparing for Implementation Securing information for any computer system can be a complex task, requiring knowledge of the security package, the information to be protected, and the application that stores the information. With this in mind, ASG recommends that your Zeke security team be made of people who are familiar with Zeke, system programming functions, and, if applicable, your security product. In general, you must answer these questions before deciding on a security approach: •

What exactly needs to be secured? —

Access to information (e.g., objects like the Zeke database and specific records).

—

Access to Zeke (e.g., functions like primary menu options and Zeke operator commands).

—

Access to a combination of information and the Zeke functions.

•

Do that you want to use Zeke internal security, an external security package, or a combination?

•

How will you determine who is granted access and to what authority level?

Before you can decide what needs to be secured, you must understand these different security approaches used by Zeke: •

Object security controls access to the information contained in a data structure (e.g., a record or file). This includes controlling access to individual EMRs, SQRs, and variables. Securing by object protects the information regardless of how access is attempted (i.e., by command, batch utility, or online facility). For example, securing EMRs as objects protects them regardless of whether access is attempted from the Event Master Record online function, the EVENT batch command, or the LIST EVENTS function of Report Writer. These are the specific objects that can be protected:

Objects

Internal Security



Zeke database

370

External Security

EMRs





SQRs





Variables





9 Security

Objects

•

Internal Security

External Security

Calendars



Generation options (GENOPT)



Initiator definitions (GENSYS)



Company name and address



Pool definitions



Internal security (class and operator) records



Operating passwords



Logical resource records



ESI definition records



Function security controls access to commands, programs, and online screens. These functions provide access to information and also control Zeke processing. For example, securing access to Zeke commands by function controls access to records like variables (ZSET VAR), EMRs (ZADD EV), and SQRs (ZALTER EV) and also controls access to Zeke processes that do not use records (e.g., ZHOLD SYS and ZKILL). These are the specific functions that can be protected: Internal Security

External Security

Primary Menu options





Batch equivalents of Primary Menu options





Functions

SCHEDULE function



ZEKESET commands



Individual SCOM command lines



Zeke operator commands Online event ADD (by event type)



 

371


Zeke Security Processing Although Zeke has its own internal security facility, you can control access to Zeke objects and functions from any SAF-compliant security product through ESI. Additionally, you can use a combination of both security methods (which is why it is important that you understand both internal and external security before deciding on an approach). External security offers increased benefits over internal security by enabling more comprehensive security at a more detailed level and providing more flexibility in establishing access criteria. This section gives a general overview of Zeke security processing (whether you are using internal or external security, your own security exit, or a combination). See the sections, “Internal Security” on page 377 and “External Security” on page 392 for detailed discussions on each method.

Security Calls When a user attempts to access a Zeke object or function, Zeke calls the security processing routine ZEKE15A to determine whether to allow the request.

Authority Levels Zeke governs security calls using this hierarchy of authority levels (from lowest to highest): Authority Level

Description

READ

Allows the user to browse, display, and list records.

UPDATE

Allows the user to modify existing records, along with all of the authority of READ access.

ALTER

Allows the user to add and delete records, along with all of the authority of UPDATE access.

CONTROL

Allows the user to perform the requested command (only applies to individual SCOM command lines).

Each security call specifies the minimum authority level required for the request. For example, if a user has been granted UPDATE access to a record and the user is requesting READ access only, then Zeke allows the request (because READ access is assumed to be granted for a user with UPDATE access).

372

9 Security

Note:

Internal security considers only READ access and WRITE access (i.e., a combination of UPDATE and ALTER); therefore, if a user is granted WRITE access, internal security allows the user to add and delete records, as well as update existing records.

Multiple Calls Sometimes a single user request results in more than one security call. For example, if a user issues the operator command ZALTER EV 1 WHENOK, then Zeke makes these two security calls: •

A call to determine whether the user is authorized to issue ZALTER operator commands.

•

A call to determine whether the user is authorized to update the SQR for event 1.

In this example, the user must be authorized for both requests or the request is denied. Additionally, if a single user request requires access to multiple records, even more security calls could be generated. For example, if a user issues the command ZDISPLAY JOB, Zeke makes these calls: •

A call to determine whether the user is authorized for the ZDISPLAY command.

•

A call for every SQR to determine which ones the user is authorized to display (i.e., READ access).

In this example, if the user is authorized for the ZDISPLAY command, then Zeke displays only the records for which the user has READ access. If the user is not allowed to issue ZDISPLAY operator command, then Zeke denies the entire request.

373


Origination Sources A security call can originate from any of these sources: Source

Description

Batch

A request from a batch program or job (i.e., ZEKE or ZEKESET utility program): • Logging on (i.e., first Zeke access attempt) • Accessing a function that is the batch equivalent of one of the online functions • Invoking a batch-only function (e.g., SCHEDULE or LIST) • Accessing a specific record or group of records • Using SET ZCOM to issue command (e.g., ZDISPLAY) • Issuing a command using SET SCOM within an execution of ZEKESET • Invoking a global database function (e.g., BACKUP or RESTORE) • Logging off Zeke in this initiator

Console

A request from the system console: • Issuing a command (e.g., ZDISPLAY) • Accessing a specific Zeke record or group of records

Online

A request from the Zeke online system: • Logging on • Accessing one of the Primary Menu options • Accessing a specific record or group of records • Issuing a command (e.g., ZDISPLAY) • Invoking a special command (e.g., a database status) • Adding or updating commands in an SCOM event • Logging off

374

ZEKECMD

A request from the ZEKECMD API (e.g., issuing a command). This request can originate from a batch program, a TSO or CMS user’s address space, or a multiuser address space (CICS).

ZEKEVAR

A request from the ZEKEVAR API (e.g. accessing a variable). This request can originate from a batch program, a TSO or CMS user’s address space, or a multiuser address space (CICS).

9 Security

Processing Logic This flowchart represents the general flow of Zeke security processing and how Zeke determines which security functions are invoked:

Access request

Y

Is it a hard-coded ESI call? A N

Does genopt ESIActv=Y?

N N

Y

Does ESI say to revert to internal?

N

Y

Does ESI apply to this call?

Y

N

Does internal security apply?

N

Y

Call ESI

A

Internal security verification

Call user security exit (if applicable)

Allow/Deny request

Every request is assumed to be allowed until it is denied by one of the three security processes (i.e., ESI, internal security, or a user exit).

External Calls Security calls to ESI have been hard-coded for these Zeke global database functions— CREATE, RESTORE, BACKUP, and STATUS—to provide the most security when the integrity of the database is in question and security criteria might not be accessible.

375


If you have an external security product on your system, you might be required to set up and define authorized users for the Z$CATAL external class before you can run the CREATE or RESTORE functions. To do so, grant at least one user ALTER-level authority to these resource (entity) names: •

BACKUP##

•

CREATE##

•

RESTORE#

•

BLOCK###

•

STATUS##

If you do not define the class and authorized users, your request could be denied (depending how your security product handles calls with undefined classes). If the return code generated and passed to SAF from your security product is 0 or 4, then Zeke allows the request without the class and resource names. If the return code is not 0 or 4, then Zeke denies the request. Also, if a user security exit exists, the request could be denied. See “Security Classes and Resource Names” on page 393 for important details about the Z$CATAL class. External security for other calls are activated by the generation option ESIActv. If ESIActv is set to N, there are no calls to external security (except for Z$CATAL) and, instead, they are passed to internal security. Even when using external security, there could be situations when the administrator wants to revert to internal security. This is especially useful for backup in situations when the security product is disabled. The user security exit ZEKE15B (if present) is called after all other security verification has occurred. This exit can only deny requests that (up to this point) are allowed or change the user ID to be used for the internal security logon. The exit cannot allow requests that have already been denied.

Security Tracing You can trace the Zeke security processing flow using the operator command ZD SECURITY. The trace displays the security parameter list contents at various key points during processing. This is the same parameter list that is passed to any existing user security exits (e.g., ZEKE15B). Use the security trace to help determine this information:

376

•

Whether a security exit is being called and what effect it has on the security decision.

•

Which element of the security process is making the allow/deny decision.

•

Whether internal and external security processing are being performed for a specific call.

9 Security

•

The values of various fields passed to and from the user security exit.

Internal Security This section explains how Zeke internal security processing works. Internal security is enabled by default, unless external security is enabled. This is controlled by the Zeke generation option ESIActv: •

If ESIActv is set to N (i.e., do not enable external security), then internal security is called (by default).

•

If ESIActv is set to Y, then the process option for each defined external security class determines whether internal security is called for that class. If external security has not been set up, then the default process option (N4) for each class will call internal security. See “Implementing External Security” on page 398 for more information.

Internal Security Terms Zeke internal security uses these record types (stored in the Zeke database) to control access: •

Operator records control access to records (i.e., objects) in the database (e.g., EMRs, calendars, work centers, documentation, variables, etc.).

•

Class records control access to Zeke maintenance functions accessed from the Zeke Primary Menu options (e.g., EMRs, calendars, work centers, documentation, variables, etc.) and Zeke operator commands.

These are the terms that identify the ID types related to internal security: Term

Description

Class ID

Name of a class record. The operator record Zeke uses for internal security also points to a class record in the Zeke database. The class record extends the security of the operator record by specifying which types of access are available to the major Zeke functions and which Zeke operator commands the operator is authorized to use. Multiple operator records can specify the same class record. Note: Keep in mind that class has a different meaning in internal security than in external security and the two concepts are unrelated.

377


Term

Description

MVS User ID

User ID that identifies a user, job, or address space in the MVS environment (and also might be referred to as a TSO or ROSCOE user ID, a SAF user, or a RACF user ID). Zeke uses the MVS user ID to determine which security records in the Zeke database to use for internal security.

Operator ID

Name of the operator record in the Zeke database that Zeke uses for the MVS user ID associated with the current operation. Zeke attempts to find an operator record with a name that matches the MVS user ID. If it does not find a match, Zeke searches for a default operator record to use for internal security as determined by Zeke generation option settings. As a result, the operator ID is either the same as the MVS user ID or the same as the default operator ID. The operator record in use contains the name of a class record in the Zeke database to use for determining access to Zeke functions. It also contains a list of one or more user ID masks to use for determining access to particular events and variables.

User ID

Event and variable records in the Zeke database contain a user ID field that is used for internal security. Zeke does not map the user IDs in the event and variable records to the actual MVS user ID; instead, Zeke matches the user IDs against the user ID masks in the operator record.

In summary, the MVS user ID determines which operator record to use to control a user’s access. The operator record defines the user’s access to Zeke functions (by authorizing access to events and variables based on the user ID on those records and by specifying an authorization class).

Online Access The ReqOpid generation option controls access to the Zeke online system. You can use this option to restrict users from accessing the online system: •

If ReqOpid is set to Y, only users that have an MVS user ID that matches the name of an existing operator ID (i.e., the name of the operator record) can access the Zeke online system. Otherwise, a user is assigned a default operator ID and cannot use the Zeke online system. Caution! Before setting ReqOpid to Y, be sure that at least one user has an MVS user ID that matches an operator ID that is authorized to access the Zeke online system. Also, ensure that the assigned operator ID specifies a class ID that grants WRITE access to security records.

•

378

If ReqOpid is set to N, Zeke allows any user to access the Zeke online system.

9 Security

Caution! Because you must create and maintain operator and class records using screens in the Zeke online system, be sure that at least one user always has WRITE access to security records.

Operator Record The operator record controls which EMRs, SQRs, and variable records a user can access and to what authority level. Complete these steps to enable this type of security: •

The event or variable record definition must contain a user ID. Multiple event and variable records can specify the same user ID.

•

The user ID (or a mask that will select that user ID) must be defined in the operator record so that it can be compared when a user attempts to access the event or variable record. For each user ID or mask in the operator record, you can specify the authority level (i.e., NONE, READ, or WRITE) for each record type.

•

Zeke tests the list of user IDs (or masks) in the operator record from the top, downward, and uses the first match. If no match is found, Zeke denies access to the event or variable record.

Class Record The operator record that Zeke associates with a user specifies which class record to use to determine access to Zeke main functions (through Zeke Primary Menu options) and also controls which Zeke operator commands the user is authorized to issue. For operator commands, several levels of access could be required (depending on the function of the command). A user must be authorized to issue a command, but also could require access to database records and the ZCOM online function. The user’s authorization depends on whether the command requires access to database records and whether the command verb implies WRITE access. For example, to be fully authorized to issue the operator command ZADD EV 1, the user must have these levels of authorization: Function Access

Authority Level

ZADD command

YES

ZCOM menu option

WRITE

Event 1

WRITE

379


Batch Access Zeke associates a batch job (issued through the ZEKE or ZEKESET utility programs) with the MVS user ID of the submitter, and uses the MVS user ID to select the operator and class records to use for securing access. For batch jobs, Zeke also must determine what action to take when access to a command or function is denied (which is controlled by the SecFail generation option): •

If SecFail is set to C, the job is cancelled.

•

If SecFail is set to I, the request is denied and processing continues.

Note:

You do not control security for the SCHEDULE function through internal security. You must secure the SCHEDULE function either using external security or ZEKE15B user security exits.

Operator Commands Zeke uses the MVS user ID to determine the security records to use for authorization of commands (e.g., issued through Zeke online systems, batch jobs, system consoles, or SDSF) as for any other function. Some system consoles are not associated with an MVS user ID; these consoles do not require a logon. When a user issues a Zeke operator command from this type of system console, Zeke uses the operator record named OPERATOR for internal security. Be sure that you define the OPERATOR operator record and its associated class record to provide an appropriate level of authority to users that might already have access to such consoles.

Implementing Internal Security Before implementing internal security, review and change (if necessary) the relevant generation options (see “Setting the Internal Security Generation Options” on page 381). When you enable internal security, all functions initially are allowed by default. If you decide to structure your internal security with restrictive access, you must define class IDs and operator IDs using this general procedure:

380

•

Define class IDs to group individuals who need similar access to the online functions and commands. See “Defining Class Records” on page 386.

•

Define an operator ID for each user to be granted access to Zeke. See “Defining Operator Records” on page 389.

•

Define which online functions and operator commands can be accessed by an operator ID by assigning a class ID.

9 Security

Updating the ZEKExx Options Member (SECWARN) The ZEKExx PARMLIB options member provides the startup option SECWARN, which assists you in converting from Zeke 5.6 or earlier. These are the valid values: Option

Description

SECWARN=YES

Enables internal security tracing. When both of these conditions exist, Zeke allows actions that normally would be disallowed by internal security in the earlier Zeke release: • The source of the action is other than the Zeke online system (e.g., a batch command, the system console, a Zeke API, etc.) • The associated MVS user ID does not match an operator record in the Zeke database. When internal security allows an action based on this option, Zeke issues warning messages that enable you to make necessary changes to your internal security setting during the conversion process. For example: Z151NW SECWARN=YES ZEKE INTERNAL SECURITY RC CHANGED FROM DENY TO ALLOW Z151OW SRC=BATCH,TYP=Z,USER=OP0005

,OPERATOR=NEWOPR

Note: During startup of the Zeke started task, messages are issued to remind you that this security option is activated. After all security records have been reviewed (and updated, if necessary) according to the internal security rules in Zeke 6.0 and later, you can change this setting to SECWARN=NO to disable internal security tracing for future startups. SECWARN=NO

Default. Disables internal security tracing; Zeke operates according to normal internal security rules.

Setting the Internal Security Generation Options This section explains how to access and update these generation options that control Zeke internal security processing: Option

Description

Batch function security requirements: SecFail

Indicates the action for Zeke to take if batch security verification fails.

381


Option

Description

Online facility security requirements: DefOpid

Specifies the default operator ID (operator record name) to use when the user’s MVS user ID does not match an existing operator record (i.e., the user is unknown to Zeke). The default value is OPERATOR. If the specified value does not match an existing operator record, then Zeke denies access to all functions by any user that is associated with this operator ID. Zeke does not use the DefOpid value for commands issued from a system console that does not require a user logon (i.e., the user does not have an associated MVS user ID). Zeke always uses the operator ID OPERATOR for users that issue commands from this type of console. Because you cannot change the operator ID used for this type of console, ASG recommends that you change the DefOpid value to the name of an existing operator ID.

ReqOpid

Only affects access to the online system. If Reqopid is set to Y, Zeke requires a matching operator ID to grant a user access to the Zeke online system. If Reqopid is set to N, Zeke grants an unknown user access to the Zeke online system based on the default operator ID.

Caution! Do not change ReqOpid to Y unless at least one operator ID is defined to Zeke with at least WRITE authority for the security function. Otherwise, all users are denied access to the Zeke online system. SecExitw=xxxx Number of bytes of storage allocated to call the Zeke security exit routine (ZEKE15B).

To set the internal security options 1

From the Zeke Primary Menu, enter option 6. The Security Control Functions screen is displayed: ASG-Zeke Option ===>

Security Control Functions

1 2 3 X

382

Operators Classes ExtSec Return

List Operator Information by Operator ID List Class Information by Class ID External Security Interface (ESI) Customization Return to main Zeke menu

9 Security

2

Enter 1 on the Option line, and press Enter. The Directory of Operator IDs screen is displayed: ASG-Zeke Directory of Operator IDs Command ===> ADD Operator ID: SECADMIN Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: E - Edit B - Browse C - Copy Operator ID

Class

Date Added DVNEKG A 08/30/2007 DVNEKG1 B 09/06/2007 OPERATOR A 09/19/2006 SPTLRS1 B 06/18/2012 ******************************* Bottom of


D - Delete

Date Last Updated 04/17/2008 05/29/2012 08/30/2007 06/18/2012 data ********************************

3

Enter ADD on the Command line.

4

Specify the new default operator ID in the Operator ID field.

5

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

6

Zcom

Event

Work

Documentation

Variable

In the Class ID field, enter a valid class ID (see “Defining Operator Records” on page 389), or keep the default class A, and press Enter. By default, this class record enables access to all Zeke functions and operator commands (unless the specified class has been modified).

383


7

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



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


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




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


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


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


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


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


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


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


2


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.


391


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


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


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


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


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


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



2

Enter E to the left of the GENOPT with the system name *GLOBAL (which contains the security options) and press Enter.

403


The Generation Options EDIT screen displays the options in alphabetical order: ASG-Zeke Command ===>

Generation 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


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




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


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


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 <META HTTP-EQUIV=”Refresh” CONTENT=”0; URL=/zeke/”>

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


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


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


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


2

From the Zeke Web Services home page, click View Maintenance.


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


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


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


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


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.


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


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


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


2


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


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


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


2



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


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.


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


2


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


2


3

Optional. Select a view from the Views drop-down list to narrow down the list of work centers.

423


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


2


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


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


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


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


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


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


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


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


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


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


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


38

ASG Worldwide Headquarters Naples Florida USA | asg.com

CD Contents

Zeke 6.0 Users Guide.pdf

Recommend Documents