ASG-Zeke™ Scheduling for z/OS

User’s Guide
Version 6.1
Publication Number: AZM0200-61
Publication Date: March 2014

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

All names and products contained herein are the trademarks or registered trademarks of their respective holders.

ASG Worldwide Headquarters Naples Florida USA | asg.com | info@asg.com

1333 Third Avenue South, Naples, Florida 34102 USA Tel: 239.435.2200 Fax: 239.263.3692 Toll Free: 800.932.5536 (USA only)
 Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
About this Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ix
E-mail User Forum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
Publication Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Worldwide Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
Intelligent Support Portal (ISP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
Product Support Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiv
ASG Documentation/Product Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiv

Chapter 1: Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Zeke Processing (Multisystem Support) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
Online Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Event Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Event Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Event Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Schedule Monitoring and Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Operator Commands (ZCOM Option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Job Restart/Rerun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Zeke Web Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Workload Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Configuration and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Database Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Batch Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ZEKE Batch Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

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

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

Chapter 2: Starting Zeke and Using the Online Facility. . . . . . . . . . . . . . . . . . . . . 25

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

Chapter 3: Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Calendar Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Accessing the Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Standard Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Special Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
User Accounting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Calendar Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Maintaining Scratch Pad or Note Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Chapter 4: Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Event Master Records (EMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Event Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Accessing an EMR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Generic Selection Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
EMR Primary Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

ii
 Contents

Adding an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Updating an Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Using Event Templates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Copying an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Job Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Defining a Job Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
Defining an Externally Submitted Job (JESQ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Processing Remote Work Requests from Zena. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Routing a Job to Another System or Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Downloading a Job to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Retrieving JCL from the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Message Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Command Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
REXX Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Defining a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Using Variables in a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Completing a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Scheduling and Dispatching Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
Schedule Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Multiple Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Recurring and Permanent Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Milestone Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Scheduling Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Condition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Defining Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Managing Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Accessing Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Maintaining Scratch Pad or Note Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Maintaining Dataset Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Viewing Event Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Maintaining Job Duration Statistics, Alerts, and Failures. . . . . . . . . . . . . . . . . . . . . . . 175

Chapter 5: Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 183

Logical Day (48-hour Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184

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

Creating the Zeke Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

Creating the Schedule Manually . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Creating the Schedule Automatically . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
Downloading the Schedule to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Forecasting and Simulating the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Forecasting the Schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Simulating the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
Creating and Adding an Event to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Using Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Schedule View Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Displaying Scheduled Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Updating a Scheduled Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Displaying or Updating an Event Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Managing WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
Managing Event Resources. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
Accessing an Expanded SQR (Using ZOOM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Customizing Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224
Accessing Other Zeke Online Functions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Managing JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Zeke Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Dispatch Priority . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Late Dispatch Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
Early Warning Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244
ZCOM Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 246
Issuing Zeke Commands through ZCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Issuing Zeke Commands outside of ZCOM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
Modifying PF Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 248
PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Manually Adding Events to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Using the ZADD Operator Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
Using the ADD Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Adding Events By Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261

Chapter 6: Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265

Physical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Initiator Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 266
Defining Pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277
Logical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
Defining or Updating a Logical Resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
Assigning Resources to an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283
Deleting Resources for an Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287

iv
 Contents

Chapter 7: Customizing and Maintaining Zeke. . . . . . . . . . . . . . . . . . . . . . . . . . . 289

Zeke Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
GENOPTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290
Accessing the Zeke Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Adding a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297
Editing a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300
Viewing Pending GENOPT Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301
Deleting a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303
Reloading GENOPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305
Audit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306
Dispatching Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 308
Exit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
JCL Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 322
Message Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 330
Scheduling Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331
Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335
Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
User Interface Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 336
Variables Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337
Defining Schedule Download Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338
Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 340
Generating Database and System Table Status Reports . . . . . . . . . . . . . . . . . . . . . . . . 340
Creating the Zeke Databases (Primary and Vault) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343
Backing Up the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Restoring the Zeke Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 346
Moving the Vault Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349
Recovery Using Electronic Vaulting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350
Continuous Job Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352
Terminating Zeke using ZKILL TRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
SMF Recording Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353
Applying Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356
SMF Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356

Chapter 8: Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 357

Zeke Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Naming Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Setting Zeke Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 358
Maintaining Variable Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363
OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 366
Naming OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368
Setting OASIS Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Temporary OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
System-dependent Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
v
 ASG-Zeke Scheduling for z/OS User’s Guide

Uses for Zeke Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371

Using Variables to Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371
Using Variables to Control Jobstream Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Using Variables to Restart a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 373
Substituting Variable Values in JCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375
IF Clauses On SET Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378
Variable Substitution in SCOM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 378

Chapter 9: Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 381

Preparing for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382
Zeke Security Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Security Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384
Authenticating Operator Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 388
Security Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Internal Security Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 389
Online Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Operator Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 391
Class Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Batch Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392
Implementing Internal Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
External Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405
Security Classes and Resource Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 406
Implementing External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 411

Chapter 10: Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 421
Accessing Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 422
Setting Zeke Web Services as Your Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Accessing Events through the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Displaying an Event Directory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 423
Displaying an Event Detail Listing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 427
Managing Work Centers through the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Accessing Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
Creating and Maintaining Custom Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Completing a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 442
Enabling or Disabling a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 447
Refreshing a Work Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 448

Appendix A: Zeke “Agentless” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 451

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

vi
 Contents

Installation and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 452

JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454
ZEKE6NOA Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456

Appendix B: Interface to ThruPut Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457

Enabling the ThruPut Manager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 457
ZEKECTL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 458
Zeke Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 459
ThruPut Manager Descriptors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462
$ZEKE_JECL_OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 462

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 463

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

viii
 Preface

This ASG-Zeke Scheduling for z/OS User’s Guide explains the procedures for using
ASG-Zeke Scheduling (herein called Zeke) for enterprise-wide workload management.
This guide assumes that the appropriate components have been installed at your site.

About this Publication

This publication consists of these chapters:
• Chapter 1, “Introducing Zeke,” introduces you to the basic concepts of using Zeke.
• Chapter 2, “Starting Zeke and Using the Online Facility,” explains how to start and
log on to Zeke.
• Chapter 3, “Calendars,” describes the various types of calendars and how to use
them.
• Chapter 4, “Events,” explains the elements 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 customized 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 to
access events and work center functions from a Web browser (instead of through a
Zeke online facility).

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

E-mail User Forum

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

To subscribe to Autoops

 Visit the Autoops Info Page at http://usdenlist.asg.com/mailman/listinfo/autoops

and complete the form under “Subscribing to Autoops”.

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

x
 Preface

Related Publications
The documentation library for Zeke consists of these publications (where nn represents
the product version number):
• 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.
• 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.

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

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

lowercase italic Information that you provide according to your particular situation.
monospace 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.

xii
 Preface

Convention Usage

Vertical separator bar ( | ) Indicates options available with the default value underlined
with underline (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

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.

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

This table outlines the support response times you can expect:

Expected Support
Severity Meaning 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 Within 4 hours

work-around solution

4 “How-to” questions and enhancement requests Within 4 hours

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.

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’s features and contains these topics:

Topic Page

Overview 2
Zeke Processing (Multisystem Support) 2
Online Facilities 3
Event Management 3
Event Terminology 4
Event Scheduling 8
Event Dispatching 9
Event Activity Accounting 12
Schedule Monitoring and Intervention 12
Schedule View 12
Operator Commands (ZCOM Option) 13
PathFinder 14
Job Restart/Rerun 14
Web Services 14
Workload Management 14
Configuration and Maintenance 15
Generation Options 15
Database Maintenance 16
Security 16
Batch Utilities 17
ZEKE Batch Utility 17
Report Writer 18
Auditing 18
ZEKESET Utility 19
ZEKEXUTL Import/Export Utility 19
Zeke Interfaces to other ASG Products 20
‘Z’ Products 20
Cross-platform Schedule Management 20
JCL Validation 22
Workload Analysis and Planning 22
ASG-Automation Center (Problem Tracking Support) 23
ASG-Cortex-Pdb Plug to Zeke 23

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

Overview
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—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 20).

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.

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.

2
 1 Introducing Zeke

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

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.

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

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 Records (EMRs)” on page 51 for more information.

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

4
 1 Introducing Zeke

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 “Multiple Event Versions” on page 142 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 “Recurring and Permanent Events” on page 145 and “Milestone Events” on page 150
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.

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.

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

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.

See “Routing a Job to Another System or Platform” on page 77.

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.

See “Defining an Externally Submitted Job (JESQ)” on page 72.

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 to Zeke Agent” on page 81 for more information.

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

6
 1 Introducing Zeke

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 166 for more information.

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.

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

See “Work Centers” on page 96 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 49 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 37 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).

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 184 for more information.

8
 1 Introducing Zeke

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 110 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)
• 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 “Schedule Time” on page 146 for more information.

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

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.

See “WHEN Conditions” on page 126 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.

10
 1 Introducing Zeke

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 265 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. Zeke can also
store and process condition codes defined for a z/OS job task submitted by a remote
originating system (e.g., Zena) through ASG-Enterprise Automation Services (described
on page 21).

See “Condition Codes” on page 155 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

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 357 for more information.

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

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 161 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 173 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 183.

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 SQR on one screen.

12
 1 Introducing Zeke

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

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

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 249 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 20 for more information.

Zeke Web Services

Zeke Web Services enables you to access events and work center functions through a
Web browser instead through a Zeke online facility (e.g., TSO or ISPF) or from 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).

You can secure Zeke access from a Web browser (i.e,. through SAF) or allow security to
be controlled based only on the default operator ID.

See Chapter 10, “Zeke Web Services,” on page 421 for more information.

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

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 265 for mor information.

14
 1 Introducing Zeke

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 “Scheduling Environments” on page 153 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 352 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 189 for more information.

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.

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

See “Zeke Generation Options” on page 290 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 340 for more information.

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

16
 1 Introducing Zeke

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

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

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

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 changes in an audit log (which can be a data space
log). You define the actions be logged through the Zeke generation options.

These are the types of actions that you can have audited and logged by the AUDIT utility:
• Issued console commands.
• Event scheduling and dispatching activities, event flow, and status changes.
• Requested, acquired, and released logical resources.
• Activated/deactivated EMRs and updated EMRs.
• Updates others types of database records (e.g., calendars, GENOPTs, resources,
systems, pools, security definitions, etc.)
• Zeke variables updates, and variable values set through a work center.
• Users that log on and off through any Zeke online facility or from OpsCentral.

You can archive the audit records and generate reports from active or backup files.

See “Audit Options” on page 306 for more information on setting audit options.

See the ASG-OASIS for z/OS Reference Guide for details on using the AUDIT utility.

18
 1 Introducing Zeke

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.

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.

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

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.

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

This section describes additional ASG products that 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

20
 1 Introducing Zeke

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 451 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 works with ASG-Zena (herein called Zena), the distributed workload management
and process automation solution, in a number of ways. For example:
• Through the separately-licensed ASG-Enterprise Automation Services, Zeke
operates as a remote agent for processing Zena work requests on the mainframe.
Zeke can process a z/OS job task defined and sent from Zena (along with any
triggers) and return status information back to the remote Zena server. See
“Processing Remote Work Requests from Zena” on page 75 for details.
• Zeke can utilize Zena agents to run system commands on behalf of Zeke through
ASG-Zena Bridge.
• Zeke can communicate with Zena via Zeke Agent for Windows. 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 a Zena task or process.
Likewise, Zeke jobs can be used to trigger tasks scheduled on Zena. Refer to your
Zeke Agent and Zena documentation for more information on how these types of
cross-platform job dependencies are defined and satisfied.

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.

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

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.

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.

22
 1 Introducing Zeke

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

ASG-Automation Center (Problem Tracking Support)

Zeke provides problem tracking support through a user exit to interface with
ASG-Automation Center (herein called Automation Center), or by interfacing with
third-party problem tracking systems. The problem tracking interfacing user exit
ZEKE03X is called and a tracking record is produced for each abnormal end-of-event
(AEOE), abnormal end-of-job (AEOJ), abnormal end-of-program (AEOP), and abnormal
end-of-step (AEOS).

For Automation Center, when an event ends abnormally, the exit calls Automation Center
and issues an open command consisting of the command ZEKJOB followed by the
jobname and the event number. You can set up the exit to assign tickets to different
people or groups based on jobnames.

ASG-Cortex-Pdb Plug to Zeke

ASG-Cortex-Pdb documents application objects and attributes in a production database
that is compatible with any hardware or software environment. It is also a powerful
compiler that generates standardized JCL and process flows. For example, it generates
procedures, parameter streams, and job scheduling information for multiple environments
(tests, acceptance, production, etc.) and platforms (z/OS, UNIX, etc.). In addition,
Cortex-Pdb streamlines the process of moving your application JCL or other command
language into production.

The Zeke module ZEKEXAPI enables Zeke to bridge to Cortex-Pdb.

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

24
 Chapter 2: Starting Zeke and Using the

2 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. This
chapter contains these topics:

Topic Page

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

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

Starting Zeke
You use the SSS4001 program to initialize Zeke. If the specified OASIS subsystem is not
initialized already, then SSS4001 initializes it first. Generally, you set Zeke to be
initialized automatically after an IPL, so that Zeke is always active.

This is a sample procedure for starting Zeke:

//*
//Z610A PROC OASIS=(00,L),ZK=(??,L),R=0M,S=SSSI,XP=OASISSTC
//ZEKE EXEC PGM=SSS4001,REGION=&R,TIME=1440,
// PARM=('ZEKE=&ZK',
// 'OASIS=&OASIS','SUBSYS=&S','XPROC=&XP',END)
//SYSPRINT DD SYSOUT=*
//SYSOUT DD SYSOUT=*
//SYSMDUMP DD DISP=MOD,DSN=*SYSMDUMP*
//ZEKERDR DD SYSOUT=(A,INTRDR)
//ZEKECAT DD DISP=SHR,DSN=*ZEKECAT*
//PARMLIB DD DISP=SHR,DSN=*PARMLIB*
//*
//STDERR DD SYSOUT=*
//STDOUT DD SYSOUT=*
//**ZEKEVLT DD DISP=SHR,DSN=*ZEKEVLT* IF SELECTED
//**ZEKEAD1 DD DISP=SHR,DSN=*ZEKEAD1* IF SELECTED
//**ZEKEAD2 DD DISP=SHR,DSN=*ZEKEAD2* IF SELECTED
//STEPLIB DD DISP=SHR,DSN=*ZPFX*.SZEKLMD0
// DD DISP=SHR,DSN=*OPFX*.SALTLMD0
//*
...

See the ASG-Zeke for z/OS Installation Guide for detailed instructions on setting up the
Zeke started task procedure, and initializing the Zeke started task automatically.

Restarting Zeke
Because it runs as a started task in the operating system; Zeke must be restarted after each
IPL or after an upgrade. Zeke is initialized for processing and stays active until the started
task is terminated.

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 20 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 Zeke is terminated with the ZKILL command or the MVS command STOP (i.e.,
P stcname), you can enter this command from the operator console to restart Zeke:

26
 2 Starting Zeke and Using the Online Facility

To restart Zeke (when OASIS is already running)

 Issue this command from the operator console:

START stcname
where stcname is the name of the Zeke started task procedure. For example:

START ZEKE610

Or

Issue an MVS system MODIFY command to the address space using this syntax:

F procname,STPROD ZEKE

The Zeke address space locates its schedule tables and determines whether to perform a
WARM or COLD start.

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 that address space.

Starting OASIS Only

Because Zeke requires the OASIS subsystem to be active, OASIS is always started when
Zeke is started (unless OASIS is already active). You can start OASIS without starting
Zeke. Typically, this is necessary during the installation or upgrade process when you
need to create a Zeke database since the ZEKE utility program can be used for Zeke
database maintenance without Zeke being active.

To start the OASIS subsystem

 Issue the START command using this syntax:

START oasisstc,S=subsys,OASIS='(aa,bb)'
where:
oasisstc is the name of the OASIS started task 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 values for the S and OASIS symbolic parameters,
you can omit those parameters from the START command.

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

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

Starting Multiple Tasks

You can use multiple Zeke started tasks where separate databases exist on a single CPU.
You must create the Zeke and OASIS started task procedures for each system. See the
ASG-Zeke Scheduling for z/OS Installation Guide and 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.

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 ,MSGLEVEL=(1,1),CLASS=A

//SOASIS EXEC PROC=OASIS,REGION=1024K,S=sssi
//SYSPRINT DD SYSOUT=A
//STEPLIB DD DSN=OASIS.LINKLIB,DISP=SHR
//SYSIN DD *
TERMINATE
/*

28
 2 Starting Zeke and Using the Online Facility

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 332 for more information.

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

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.
30
 2 Starting Zeke and Using the Online Facility

ZCOM Command
Although it is not listed on the screen with the primary commands, the ZCOM primary
command is available from the Command line of any screen. This command enables you
to access the Zeke command shell where you can issue any Zeke operator command. See
“Issuing Zeke Commands outside of ZCOM” on page 247 for more information.

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

Command or Option ASG-Zeke Condition Code Validation ADD

Primary command entry line Command ===> Scroll ===> PAGE
Screen Name
Varies depending on Primary commands: BROWSE CANCEL DELETE EDIT
screen purpose Line commands: D Delete line I Insert line R Repeat line
Primary Commands
Zeke primary commands Event: 000006 Jobname: TSKKGUT1 System: ZEQA Event Name: ZEKE51TST6
Varies by screen function
Standard ISPF commands Operators: EQ NE LE LT GE GT RA =Range
also are available Actions: F = Fail, C = Cancel, O = Ok
Line Commands
Zeke line commands Stepname Procstep Operator - Range - Action
Varies by screen function Low High
Standard ISPF commands EOJ CC
also are available
STEP01 GT 8 F
Screen Mode STEP02 NE 16 O
Action allowed
on this screen

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.

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

To access the Zeke ISPF online facility

1 Access the ISPF Primary Option Menu:

Menu Utilities Compilers Options Status Help TSO-Access ASG

ISPF Primary Option Menu

Option ===> ASG
More: +
0 Settings Terminal and user parameters User ID . : ASGUSER
1 View Display source data or listings Time. . . : 13:28
2 Edit Create or change source data Terminal. : 3278
3 Utilities Perform utility functions Screen. . : 1
4 Foreground Interactive language processing Language. : ENGLISH
5 Batch Submit job for language processing Appl ID . : ISR
6 Command Enter TSO or Workstation commands TSO logon : $TSASG
7 Dialog Test Perform dialog testing TSO prefix: TSOUSR
8 LM Facility Library administrator functions System ID : SYSD
9 IBM Products IBM program development products MVS acct. : ACCT
10 SCLM SW Configuration Library Manager Release . : ISPF 6.1
11 Workplace ISPF Object/Action Workplace
S SDSF System Display and Search Facility
ASG ASG ASG Product Panel

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 AFI ASG-FAVORITES FOR MAXIMZING ISPF PRODUCTIVITY

3 STEST ALLEN SYSTEMS DEBUGGING FACILITY
4 ESW ASG-ESW EXISTING SYSTEMS WORKBENCH
5 zTEAM ZEKE, ZEBB AND ZARA
F SMUF/APTS SMUF/APAR PTF TRACKING
PM PRODMAN PRODUCT-MANUFACTURING

-----MISC UTILITIES----- -------------DESCRIPTION---------------------

A DASD/QUICKREF DASD FREE SPACE INFORMATION OPTION S
J JCLPREP JCLPREP (JCL VALIDATOR)
Q MVS/QUICKREF QUICK REF (ONLINE ERRORS/MESSAGES/SYNTAX)
C CICSPLEX CICSPLEX SYSTEM MANAGER
D DB2 / Other ADMIN, SPUFI, QMF, Ditto ...
ST SYSTOOLS SYSTEM- AND SUBSYSTEM-TOOLS
TM TMON INFO CENTER TMON INFO CENTER FOR DEVELOPER

X EXIT RETURN TO ISPF MAIN MENU

32
 2 Starting Zeke and Using the Online Facility

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

ASG Product Selection Menu

OPTION ===> OASIS Subsystem ===> SSSI
USERID - ASGUSER
ZA ASG-Zack - Automated Operations TIME - 13:26
ZB ASG-Zebb - Rerun/Restart Management
ZE ASG-Zeke - Scheduling for z/OS
ZR ASG-Zara - Tape Management
ZX ASG-OASIS - OASIS Variables and Audit

WP ASG-WP - Workload Planner (BETA 44)

WA ASG-WA - Workload Analyzer (BETA 45)

X EXIT - Return to previous menu

Enter END command to return to the previous menu.

Copyright (C) 2013 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 ASG-Zeke Primary Menu Z610A000

Option ===>

1 Event Event Master Record

2 Schedule View Schedule View / Scheduling Commands
3 Calendar Calendar Maintenance
5 Work Work Center Control Functions
6 Security Security Control Functions
7 Documentation Documentation for Events
8 Variable Variable Maintenance
F Automation Fastpath Tables Maintenance
C Control Schedule View Display Characteristics
T Tutorial Information about using ASG-Zeke
X Exit Exit the ASG-Zeke Application

Copyright (C) 2013 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.

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

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

To exit the Zeke ISPF online facility

 From the ASG-Zeke Primary Menu, type X on the Option line and press Enter.
The ISPF Primary Option Menu is displayed:

ASG-Zeke ASG-Zeke Primary Menu Z610A000

Option ===>

1 Event Event Master Record

2 Schedule View Schedule View / Scheduling Commands
3 Calendar Calendar Maintenance
5 Work Work Center Control Functions
6 Security Security Control Functions
7 Documentation Documentation for Events
8 Variable Variable Maintenance
F Automation Fastpath Tables Maintenance
C Control Schedule View Display Characteristics
T Tutorial Information about using ASG-Zeke
X Exit Exit the ASG-Zeke Application

Copyright (C) 2013 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.

34
 2 Starting Zeke and Using the Online Facility

To change Zeke ISPF online screen colors

1 From the Zeke Primary Menu, enter option C.1 and press Enter. The User Color
Select Screen is displayed:

ASG-Zeke User Color Select Screen

Command ==>

Primary Commands: 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 Labels that identify the fields. Field names and column headings
Heading 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.

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

Data Type Description

Accented Input Data Fields available for entry (and highlighted for emphasis).

Input Field In Error Not used.

Warning Field Not used.

Exception Field Not used.

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

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

5 Enter SAVE on the Command line and press Enter.

Starting the Zeke Online Facility under TSO

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

To start the Zeke online facility under TSO

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

Note:
The ZEKEOL command is not supported as a called program from TSO.

If you are running multiple versions of Zeke, you must include the subsystem:

TSO ZEKEOL SUBSYS=subsystem

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

36
 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 37
Accessing the Calendar Facility 38
Standard Calendars 40
Special Calendars 41
User Accounting Calendars 42
Calendar Documentation 45
Maintaining Scratch Pad or Note Documentation 46
Maintaining Text Documentation 47

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.

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

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

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

Accessing the Calendar Facility

To access the calendar facility

1 From the Zeke Primary Menu, enter option 3. Press Enter. The Calendar Selection
Criteria screen is displayed:

ASG-Zeke Calendar Selection Criteria

Command ===>

Calendar ID==> Year==> Type==>

Primary commands: ADD BROWSE COPY 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 => STD- Standard SPC- Special USR- User
Date Range => - (MM/DD/YYYY) or (DD/MM/YYYY)

2 Press Enter. The Calendar Directory is displayed:

ASG-Zeke Calendar Directory Row 1 to 3 of 3

Command ===> Scroll ==> PAGE

Calendar id==> Year==> Type==>

Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT
Line Commands: E Edit B Browse C Copy D Delete O dOcument

Calendar Workdays Start End Last

Name Year Type MTWTFSS Date Date Used
A **** STD YYYYYNN 01/20/2013
ACCTG1 2013 USR YYYYYNN 01/01/2013 06/30/2013
USER1 2013 SPC N/A 01/01/2013 12/31/2013

38
 3 Calendars

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 Move the cursor to the unlabeled selection field to the left of the
calendar calendar you want to update and enter E.

Delete an existing Move the cursor to the unlabeled selection field to the left of the
calendar calendar you want to delete and enter D. A pop-up panel prompts
you to confirm the delete request. If the calendar currently is
specified in any EMR definitions, a warning message is displayed.
To confirm the deletion, press Enter; otherwise, you can cancel the
deletion in order to review and make any necessary changes to the
EMRs that would be affected by the deletion of the calendar.
Before deleting a calendar, you can search the Zeke database using
the Calendar filter on the Event Master Selection Criteria screen to
find events that reference the calendar. See “Accessing an EMR”
on page 52.
This procedure is complete.

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

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

Standard Calendars
Standard calendars define the normal workdays and holidays and indicate the first month
of the fiscal year for your company. Most events are associated with a standard calendar.
Zeke’s default calendar A is a standard calendar that can be updated to accommodate
your normal schedule. You can define as many standard calendars as necessary, each
with different workdays and holidays.

In this example, an event defined with the OCCURS clause WORKDAYS using calendar
A is scheduled five times per week, and an event using calendar B is scheduled six times
per week. Also, calendar A adjusts the scheduling of an event in case of a holiday, while
calendar B does not recognize any holidays.

Calendar A Workdays Monday through Friday

Holidays 01/01/****, 07/04/****, 12/24/****, 12/25/****,

05/28/2014, 09/03/2014, 11/22/2014, 11/23/2014

Calendar B 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 38.

ASG-Zeke Calendar Maintenance Functions BROWSE

Command ===>

Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT

Calendar ID==> A Year==> **** Type==> STD

Mon Tue Wed Thu Fri Sat Sun

Work Days: YES YES YES YES YES NO NO

MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY

Holidays:

Fiscal start month: 01

Calendar expire date: 12/31/2013 Date last accessed: 04/26/2013
Calendar start date: Calendar end date :

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

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

To maintain a special calendar

1 Access the Calendar Maintenance Functions screen as instructed in “Accessing the

Calendar Facility” on page 38.

ASG-Zeke Calendar Maintenance Functions BROWSE

COMMAND ===>

Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT

ZEKE Calendar ID==> USER1 Year==> 2013 Type==> SPC

1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
January . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
February . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
March . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
April . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
May . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
June . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
July . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
August . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
September . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
October . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
November . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
December * * * * * * * * * * * * * . . . . . . . . . . . . . . . . . .

Calendar Expire Date: Date Last Accessed:

Calendar Start Date: 01/01/2013 Calendar End Date: 12/31/2013

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

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

ASG-Zeke Calendar Maintenance Functions BROWSE

Command ===>

Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT PERIODS
Calendar ID==> ACCTG1 Year==> 2013 Type==> USR

Mon Tue Wed Thu Fri Sat Sun

Work Days: YES YES YES YES YES NO NO

MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY

Holidays:

Calendar expire date: Date last accessed:

Calendar start date: 01/01/2013 Calendar end date : 06/30/2013

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.

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

5 If you are updating an existing calendar, enter PERIODS on the Command line,
and press Enter.

ASG-Zeke User Calendar Periods BROWSE

COMMAND ===>

Primary Commands: BROWSE CANCEL EDIT

Calendar start date: 01/01/2013 Calendar end date : 06/30/2013

ZEKE Calendar ID==> ACCTG1 Year==> 2013 Type==> USR

Period 01: 28 Period 02: 28 Period 03: 35

Period 04: 28 Period 05: 28 Period 06: 35
Period 07: Period 08: Period 09:
Period 10: Period 11: Period 12:
Period 13: Period 14: Period 15:
Period 16: Period 17: Period 18:
Period 19: Period 20: Period 21:
Period 22: Period 23: Period 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 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.

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

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

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

Option ===>

Primary Command: DELETE

Calid: A
Year: **** Type: STD Sdate: Edate:

Documentation Record Selection Options

1 SCRATCH Scratch pad

2 * TEXT Text information
3 NOTE Note pad information

3 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 Enter 1 and press Enter. Go to “Maintaining Scratch Pad or
documentation Note Documentation” on page 46.

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

Desired Result Action

Access text Enter 2 and press Enter. Go to “Maintaining Text

documentation Documentation” on page 47.

Access note Enter 3 and press Enter. Go to “Maintaining Scratch Pad or

documentation Note Documentation” on page 46.

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

ASG-Zeke Documentation Scratch Pad EDIT

Command ==>

Primary Commands: BROWSE CANCEL DELETE EDIT

Line 1 USE THIS CALENDAR FOR ALL LEVEL 4 JOBS AND

2 FOR SPECIAL LEVEL 3 JOBS.
3
4
5
6
7
8
9
10

Calendar id : B Calendar year : **** Calendar type : STD

Workdays : YYYYNNY Start date : 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.

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

ASG-Zeke Text Documentation EDIT

Command ===> Columns 000 000 Scroll ===> PAGE

Calid: A Year: **** Type: STD Sdate: Edate:

****** *************************** Top of Data *****************************
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000001 SVP OR HIGHER SIGNATURE REQUIRED TO AUTHORIZE CHANGING THIS CALENDAR
****** ************************** Bottom of Data ***************************

2 Enter text to the right of the column placeholder field. You can enter up to 80
characters per line, and up to several hundred lines of text.

3 Use standard ISPF editing commands to edit the text.

4 Press F8 to page forward and access an additional screen.

5 Press Enter to save the changes.

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

48
 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 Records (EMRs) 51

Event Types 51
Accessing an EMR 52
Generic Selection Criteria 53
EMR Primary Commands 54
Adding an Event 59
Updating an Event 60
Using Event Templates 62
Copying an Event 65
Job Events 67
Defining a Job Event 68
Defining an Externally Submitted Job (JESQ) 72
Processing Remote Work Requests from Zena 75
Routing a Job to Another System or Platform 77
Downloading a Job to Zeke Agent 81
Retrieving JCL from the Zeke Database 83
Message Events 84
Command Events 87
REXX Events 92
Work Centers 96
Defining a Work Center 97
Using Variables in a Work Center 100
Completing a Work Center 102

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

Topic Page

Scheduling and Dispatching Criteria 107

Schedule Time 107
OCCURS Clauses 110
WHEN Conditions 126
Multiple Event Versions 142
Recurring and Permanent Events 145
Milestone Events 150
Scheduling Environments 153
Condition Codes 155
Auto Replies 161
Defining Auto Replies 162
Managing Auto Replies 164
Event Documentation 166
Accessing Event Documentation 166
Maintaining Scratch Pad or Note Documentation 169
Maintaining Text Documentation 170
Maintaining Dataset Documentation 171
Event Activity Accounting 173
Viewing Event Accounting Information 173
Maintaining Job Duration Statistics, Alerts, and Failures 175

50
 4 Events

Event Master Records (EMRs)

You can define an event master record (EMR) 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.

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

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

Accessing an EMR
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 Event Master Selection Criteria

Command ===>

Event ===>

Primary Commands: ADD BROWSE DELETE EDIT

Event Types Selection Field Masks

Job: Job Name:
Msg: Event Name:
Pcom: Application:
Work: Group ID:
Vcom: User ID:
Zcom: Drl ID:
Scom: System:
REXX: Calendar:
Occurs:
Properties When:
Template: Resource:
Permanent:
Milestone:

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

52
 4 Events

3 Press Enter. The Event Master Directory is displayed:

ASG-Zeke Event Master Directory

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

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

Note:
Although a user ID value in an event definition must be specified in the correct
case, the user ID value you specify as selection criteria performs a case-insensitive
comparison.

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

You can use an asterisk (*) as a wildcard for any number of characters. A wildcard
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).

You can use a question mark (?) as a placeholder to match any single character.

Wildcards and placeholders can be used in combination.

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

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.

54
 4 Events

Command Action

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

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

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.

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

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

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

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

VERsion Specifies the version of the event for which to display

predecessor/successor information. For example:
PATHADD LEV 5
The default value is 0 (if the VerLoad generation option is set to
0). Otherwise, the default value is 1.

PREd View the predecessors of the event.

Note:
The DSPIndex generation option must be set to Y to enable the PRED
command (see “Building EDB Indexes” on page 321).

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

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

VERsion Specifies the version of the event for which to display predecessor
information. For example:
PRED VER 3
The default value is 0 (if the Verload generation option is set to
0). Otherwise, the default value is 1.

56
 4 Events

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

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

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

VERsion Specifies the version of the event for which to view predecessor
information.
PREDADD LEV 3
The default value is 0 (if the Verload generation option is set to
0). Otherwise, the default value is 1.

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

scheduled.

RESOurce Maintain logical resource control information for a job event.

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

SUcc View the successors of the event.

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

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

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

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

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

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

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

VERSION Specifies the version of the event for which to view successor
information.
SUCCADD LEV 3
The default value is 0 (if the Verload generation option is set to
0. Otherwise, the default value is 1).

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

58
 4 Events

Adding an Event
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.

2 Enter ADD on the Command line, and press Enter. The Add Event Record Function
screen is displayed:

ASG-Zeke Add Event Record Function

Option ===>

Use Template: Y Template

1 Job Add a Job Event JCLTEMPLATE
2 Msg Add a Message Event MSGTEMPLATE
3 Pcom Add a Pcom Event PCOMTEMPLATE
4 Work Add a Work Center Event WORKTEMPLATE
5 Vcom Add a Vcom Event VCOMTEMPLATE
6 Zcom Add a Zcom Event ZCOMTEMPLATE
7 Scom Add a Scom Event SCOMTEMPLATE
8 REXX Add a REXX Event 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 63.

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, see the appropriate procedure:
• For job events, see “Job Events” on page 67.
• For message events, see “Message Events” on page 84.
• For command events, see “Command Events” on page 87.
• For work center events, see “Work Centers” on page 96.
• For REXX events, see “REXX Events” on page 92.

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

Updating an Event
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 1 Enter EDIT on the Command line.

based on event number
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 61.

Update an existing event 1 Enter any character in the appropriate Event Types
(without the event number) 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 61.

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

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

60
 4 Events

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

Desired Result Action

Update the EMR Enter E to the left of the event that you want to
update, and press Enter. The Event Master Definition
screen for the selected event is displayed in Edit mode.
Perform the appropriate update procedure for the event
type you are updating:
• See “Job Events” on page 67.
• See “Message Events” on page 84.
• See “Command Events” on page 87.
• See “REXX Events” on page 92.
• See “Work Centers” on page 96.

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

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

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

Update event logical resources Enter E4 to the left of the event that you want to
update, and press Enter. Continue to “Assigning
Resources to an Event” on page 283.

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

Update the OCCURS clause for Enter E6 to the left of the event that you want to
an event update, and press Enter. Continue to “Defining an
OCCURS Clause” on page 124.

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

Desired Result Action

Update the WHEN conditions for Enter E7 to the left of the event that you want to
an event update, and press Enter. Continue to “Defining a
WHEN Condition” on page 141.

Using Event Templates

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.

Defining an Event Template

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 an EMR” on page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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 Class: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y
Bim: Mbr:
JESQ (Y, D=dynamic):

62
 4 Events

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 “Job Events” on page 67.
• See “Message Events” on page 84.
• See “Command Events” on page 87.
• See “REXX Events” on page 92.
• See “Work Centers” on page 96.

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.

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

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

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 62 for details on defining event templates.

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

To create an event from an existing template

1 Access the Add Event Record Function screen, as described in “Accessing an EMR”
on page 52 for details:

ASG-Zeke Add Event Record Function

Option ===>

Use Template: Y Template

1 Job Add a Job Event JCLTEMPLATE
2 Msg Add a Message Event MSGTEMPLATE
3 Pcom Add a Pcom Event PCOMTEMPLATE
4 Work Add a Work Center Event WORKTEMPLATE
5 Vcom Add a Vcom Event VCOMTEMPLATE
6 Zcom Add a Zcom Event ZCOMTEMPLATE
7 Scom Add a Scom Event SCOMTEMPLATE
8 REXX Add a REXX Event 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 an EMR” on page 52), 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.

64
 4 Events

The Event Master Definition screen for the selected event type is displayed in
Update mode (this example illustrates a job event):

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y
Bim: Mbr:
JESQ (Y, D=dynamic):

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

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

specify any additional event scheduling criteria.

9 Optional. Perform the procedure, “Defining a WHEN Condition” on page 141 to

specify any event dispatching prerequisites.

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.

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

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 63 for details.

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

1 Access the Event Master Definition screen (see “Accessing an EMR” on page 52)
for the event that you want to copy:

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y
Bim: Mbr:
JESQ (Y, D=dynamic):

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

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.

66
 4 Events

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.

Job Events
A job event is the most commonly used event type, and executes a specified jobstream.
This section describes how to define a Zeke job event.

This section also describes these additional scenarios under which Zeke can send jobs to
other systems while continuing to manage and track them, as well as control the
dispatching and tracking of remote jobs received from other systems:
• You can define job events in Zeke that will originate from an external source, and
Zeke dispatches and tracks the event just like any other Zeke event. See “Defining
an Externally Submitted Job (JESQ)” on page 72.
• Zeke can act as an agent for Zena through EA Services. See “Processing Remote
Work Requests from Zena” on page 75.
• Zeke can route an individual job event (or send its JCL) to a Zeke Agent on another
platform for execution and tracking (or simply to another system for execution).
See “Routing a Job to Another System or Platform” on page 77.

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

• You can download a subset of scheduled jobs in the Zeke schedule to Zeke Agent
on UNIX, where Zeke Agent dispatches and tracks the jobs in the same manner as
Zeke. See “Downloading a Job to Zeke Agent” on page 81.

Defining a Job Event

To define or maintain a job event

1 Access the Event Master Definition screen for job events, as described in “Accessing
an EMR” on page 52.

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

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

Field Description

Template Y | N. Indicate whether you are defining a message event template. See
“Defining an Event Template” on page 62 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.

68
 4 Events

Field Description

Usrid Specify the user ID (up to eight characters long) for the user authorized to
access the job event.
Because Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (i.e., 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). You can specify *ANY to indicate a pool that
includes all Zekes in the Zekeplex.

Note:
This is the Zeke system or pool that will dispatch the event, and not
necessarily the Zeke 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 “Multiple Event Versions” on page 142 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.

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

Field Description

Sched Specify the normal schedule time for the event. The default value is 00:00
(i.e., the event is dispatched according to WHEN conditions instead of by
time).
See “Schedule Time” on page 107 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).

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.

70
 4 Events

Field Description

You can enable Zeke to calculate this value automatically through the
Calctap generation option (see “Tape Options” on page 318), 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 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.

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

Field Description

Class Specify up to six job classes for the job event. Before dispatching the event,
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 271.

JCL Specify the JCL source library and member information.

See “Retrieving JCL from the Zeke Database” on page 83 for more
information about JCL sources.
See “Overriding JCL” on page 232 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 124 to specify when
Zeke schedules the job event.

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

Defining an Externally Submitted Job (JESQ)

You can define job events in Zeke 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.

72
 4 Events

To define an externally submitted job

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

2 Specify the information indicated in “Job Events” on page 67.

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.

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

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.

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 (ISPF only) 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).

74
 4 Events

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

• The EDBindex generation option must be set to Y (see page 321). 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.
• 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.

Additional JESQ Processing Considerations

• If the DispSel generation option is set to Y (see page 309), 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.)
• Zeke does not support the ZSCAN, SCAN, JCLR, and JPREP commands in
Schedule View (ISPF only) for SQRs that have the JCL source JESQ.
• You cannot create override JCL from OpsCentral.

Processing Remote Work Requests from Zena

ASG-Enterprise Automation Services (herein called EA Services) expands the scope of
Zena’s distributed workload management and process automation by enabling Zeke to act
as an agent of a remote originating system (i.e., a Zena server). Through EA Services,
Zeke can process a z/OS job task defined and submitted from Zena (along with any
triggers) and return status information back to the originating system.

EA Services is enabled through the Zeke server (which runs in the Zeke started task). In a
Zekeplex, all Zekes operate as agents for Zena, and every Zeke started task in the
Zekeplex must be configured to run the Zeke server as a remote agent. By default, any
Zeke server in the Zekeplex can receive the remote task (unless the remote task specifies
a system or pool ID).

The available Zeke system receives the remote work request originating from a Zena
server (via TCP/IP), stores it in the Zeke database as a dynamically-created event,
executes the job, and returns status information (that also references the resulting
SYSOUT) to the originating Zena system.

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

Along with the basic job definition, Zeke receives, stores and processes these types of
event attributes and information for a task (as defined on the originating Zena system):
• Job and step level condition codes
• Auto replies
• Variables. Zeke performs variable substitution in this order (if multiple variables
exist with the same name):
— Event-level variables
— Originator variables
— Zeke variables
• JCL source, which can be a JCL stream; or a Librarian, Panvalet, or PDS/PDSE
ddname (which can supplied through a Zeke variable).
• REXX execs. A remote task can be used to run a REXX exec, which is
accomplished through the OASIS REXX services batch program SSS2REXX. See
the ASG-OASIS for z/OS Reference Guide for more information.
• Job card overrides (e.g., job priority, job class, security group, WLM scheduling
environment, etc.)
• Triggers. Zeke returns status information to the originating system for these types
of remote triggers:
— Dataset close (DSN)
— BOJ, EOJ, AEOJ
— BOP, EOP, AEOP
— EOS, and AEOS
— BOE, EOE, AEOE

Zeke dispatches and tracks a remote task according to its time, dispatching and resource
requirements, just like any other Zeke event. If you use Zebb, the remote task can also be
designated for Zebb restart when necessary.

See the ASG-Zeke Scheduling for z/OS Installation Guide for the requirements and
instructions for enabling EA Services and configuring the Zeke server.

76
 4 Events

Routing a Job to Another System or Platform

Zeke can route a job event (or send its JCL) to another system or platform for execution.
For example, you can route JCL from one z/OS to another, or from a z/OS system to an
AS/400. When the job completes execution, completion information or any resulting data
can be sent back to the original Zeke for triggering other events.

Zeke provides support for these functions during remote job dispatching:
• Condition codes processing (described in “Condition Codes” on page 155), except
if *Rmtlim is specified in step 4 on page 78.
• Logical resources usage (see “Logical Resources” on page 280).
• Triggering (see “WHEN Conditions” on page 126) based on all trigger types except
dataset name and variable name.
• Update of accounting information in the EMR (see “Event Activity Accounting” on
page 173).

Note:
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 328.)

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

2 Access the Event Master Definition screen for a job event, as described in
“Accessing an EMR” on page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

3 Specify the information indicated in “Job Events” on page 67.

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 the job routing option.

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.

78
 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
to Zeke Agent” on page 81 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 Similar to *REMOTE. Zeke dispatches and submits the

*RMTFUL 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 Similar to *REMOTE. Zeke dispatches and submits the

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

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

Field Description

Note:
The values *REMOTE, *RMTFUL, and *RMTLIM can be used only when
Zeke routes the job to a remote system on the same platform as the
dispatching system. If you want to route a job from a z/OS system to a
system on VSE, AIX, or AS/400, you must specify netregid as the target.
If you want to route a job to the same platform (e.g., from one VSE system
to another), you can specify either netregid or *REMOTE as the target.

Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent a user from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of events
being scheduled unintentionally during the next schedule build cycle. This
change requires you to press the Tab key after typing eight characters in the
Target field to move to the Verload field. If you attempt to type beyond the
end of the Target field, your keyboard locks, and you must press Reset and
then the Tab key to continue.

Platform Indicate the operating system on which the event is executed. The default
values is the value of the DefPltfm generation option. These are the valid
values:
AIX (see Note below)
DCOSX (Pyramid)
HPUX (see Note below)
MVS (i.e., z/OS)
OS2
OS400
SUN (see Note below)
TANDEM
UNIX (e.g., AIX, AT&T, HPUX, NCR, SCO, SunOS, Sun Solaris, etc.)
USYS
VMS
VSE
WINDOWS (i.e., all supported versions)

Note:
Although the AIX, HPUX, and SUN platform codes are supported, ASG
recommends that you use the UNIX platform code.

Zeke does not download jobs (to a remote system) that have a platform of
MVS or VSE.

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

80
 4 Events

6 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

Downloading a Job 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 to Another System or Platform” on page 77 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 328.)

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

2 Access the Event Master Definition screen for a job event, as described in Specify
the information indicated in “Job Events” on page 67.“Accessing an EMR” on
page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

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

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

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

5 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

82
 4 Events

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 232 for instructions on retrieving and updating JCL.from
Schedule View.

To retrieve and maintain JCL stored in the Zeke database

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

2 Access the Event Master Definition screen as instructed in “Accessing an EMR” on

page 52.

ASG-Zeke Event Master Definition EDIT

Command ===>

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 Class: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

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

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

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

84
 4 Events

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 an EMR” on page 52.

ASG-Zeke Event Master Definition BROWSE

Command ===>

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 Msg1: END TAPE OFFSITE; DEPENDENT ON GOOD END OF JOB

Oper Msg2:
Oper Msg3:
Oper Msg4:
Oper Msg5:
Oper Msg6:

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

Field Description

Template Y | N. Indicate whether you are defining a message event template. See
“Defining an Event Template” on page 62 for more information.

Desc/Desc2 Specify a description of the message event. This description is displayed on

summary screens and printed on reports.

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

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

Field Description

Usrid Specify the user ID (up to eight characters long) for the user authorized to
access the message event.
Because Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (i.e., 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 Zeke system (or pool) that will dispatch the event, and not
necessarily the Zeke 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 “Multiple Event Versions” on page 142 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.

86
 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 “Schedule Time” on page 107 for a detailed explanation of schedule
time.

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.

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

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

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

5 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

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

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

Type Description

SCOM Any command that can be issued from a console. You can specify an unlimited
number of commands in an SCOM event.

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.

Zeke makes a security call for each individual command line in an SCOM event. See
“Security Calls” on page 384 for more information.

Zeke performs variable substitution for each individual command line in an SCOM event
(except when a statement appears to set a Zeke variable). For example, Zeke would not
perform variable substitution for this statement:

ZSET VAR $TESTVAR EQ ‘DONE’

This procedure describes how to define an SCOM event. You define all of the other
command event types in a similar manner.

88
 4 Events

To define and maintain a system command event

1 Access the Event Master Definition screen for SCOM events, as instructed in
“Accessing an EMR” on page 52:

ASG-Zeke Event Master Definition BROWSE

Command ===>

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

Code => C=Sys Cmd R=Sys Response Z=Zeke Cmd V=VM Cmd P=VSE/POWER Cmd
__ Code: C 001 D T
__ Code: C 002 $DI
__ Code: Z 003 ZINFO
__ Code: Z 001 ZADD EV 27 VER 1 REBUILD
__ Code: Z 002 ZADD EV 28 VER 1 REBUILD
__ Code: Z 003 ZADD EV 28 VER 2 REBUILD
__ Code: Z 004 ZADD EV 29 VER 1 REBUILD

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

Field Description

Template Y | N. Indicate whether you are defining a message event template. See
“Defining an Event Template” on page 62 for more information.

Desc/Desc2 Specify a description of the command event. This description is displayed

on summary screens and printed on reports.

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

Usrid Specify the user ID (up to eight characters long) for the user authorized to
access the command event.
Because Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (i.e., upper, lower, or mixed).

Note:
This user ID is for Zeke internal security only.

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

Field Description

System Specify the system or pool that owns the command event (which can be
associated with only one system).

Note:
This is the Zeke system (or pool) that will dispatch the event, and not
necessarily the Zeke 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 “Multiple Event Versions” on page 142 for details on multiple event
versions.

Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of
events being scheduled unintentionally during the next schedule build.

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

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

C System command

P VSE/POWER command

90
 4 Events

Field Description

R System response

V VM command

Z Zeke command

Line 001 Specify up to 60 characters of commands or responses per line. Only the
through line first line is required.
005
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.

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

Field Description

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

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

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

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

5 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

REXX Events
A REXX event enables you to dispatch and monitor REXX execs.

If you plan to use REXX events, review the chapter on Zeke REXX services in the
ASG-Zeke Scheduling for z/OS Installation Guide and the chapter on OASIS REXX
services for your ‘Z’ products (which discusses OASIS/ECF and the SSS2REXX batch
utility) in the ASG-OASIS for z/OS Reference Guide.

To define and maintain REXX events

1 Access the Event Master Definition screen for REXX events, as instructed in
“Accessing an EMR” on page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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 Y | N. Indicate whether you are defining a REXX event template. See
“Defining an Event Template” on page 62 for more information.

Desc/Desc2 Specify a description of the REXX event. This description is displayed on

summary screens and printed on reports.

92
 4 Events

Field Description

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.
Because Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (i.e., upper, lower, or mixed).

Note:
This user ID is for Zeke internal security only.

System Specify the system or pool that owns the REXX event (which can be
associated with only one system).

Note:
This is the Zeke system (or pool) that will dispatch the event, and not
necessarily the Zeke 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.

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

Field Description

See “Multiple Event Versions” on page 142 for details on multiple event
versions.

Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of
events being scheduled unintentionally during the next schedule build.

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

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

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.

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

94
 4 Events

Field Description

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

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.

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

Field Description

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

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

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

5 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

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

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 are typically set up by scheduling personnel, and completed by data center
operators. 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; for example,
Zeke lets you know when an event is late.
• Running request jobs exactly when you need them. Operator notification or
intervention is not necessary.
• Approving an event for processing.
• Setting Zeke/OASIS variable values.
• Triggering other events 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 work center events through a Web
browser. See “Managing Work Centers through the Web” on page 433 for more
information.

96
 4 Events

Defining a Work Center

To define or maintain a work center

1 Access the Event Master Definition screen, as instructed in “Accessing an EMR” on

page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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 Line 1: OBTAIN MGMT OK FOR CHECK RUN

WorkCtr Line 2:
WorkCtr Line 3:
WorkCtr Line 4:
WorkCtr Line 5:
WorkCtr Line 6:

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

Field Description

Template Y | N. Indicate whether you are defining a message event template. See
“Defining an Event Template” on page 62 for more information.

Desc/Desc2 Specify a description of the work center event. This description is

displayed on summary screens and printed on reports.

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

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

Field Description

Usrid Specify the user ID (up to eight characters long) for the user
authorized to access the work center event.
Because Zeke supports mixed-case user IDs, be sure to specify the
desired user ID in the correct case (i.e., 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 Zeke system (or pool) that will dispatch the event, and not
necessarily the Zeke system where the EMR was defined.

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 “Multiple Event Versions” on page 142 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.

98
 4 Events

Field Description

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.

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

Field Description

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

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

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

5 To set up a SET clause for this work center, enter WHEN on the Command line, and
press Enter. The Event Master Record Function screen is displayed:

ASG-Zeke Event Master Record Function EDIT

Command ===> Scroll ===> PAGE

Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN

Evt: 000246 Type: WORK Job: Evt Name: CASH0199 Calid: A

Ver: 00000 Info:
***** ***************************** Top of Data ****************************
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000001 (?VAR $JOB1KG EQ XXXXXX)
***** **************************** Bottom of Data **************************

A SET clause is used instead of a WHEN condition for work center events.

6 Specify the SET clause (enclosed in parentheses).

See "SET Clauses" on page 100 for more information. See “IF Clauses On SET
Statements” on page 378 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.

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

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

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

Using Variables in a Work Center

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

100
 4 Events

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

Note:
If OASIS variables are secured by SAF (through OASIS/ESI), the
operator must have ALTER authority to OASIS variable value records
to be able to set a variable value. See the ASG-OASIS for z/OS Reference
Guide for more information on OASIS variables security.

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.

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.

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

Completing a Work Center

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 Work Center Selection Criteria

Option ===>

1 Not Done Directory of scheduled Work Centers not completed

2 All Directory of all matching scheduled Work Centers
3 Done Directory of scheduled Work Centers completed

.-------- Selection Criteria --------.

| |
| UserID => KAC |
| App => |
| Group => |
| System => |
| |
'------------------------------------'

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 “Generic Selection Criteria” on
page 53). 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.
Because Zeke supports mixed-case user IDs, be sure to specify the
search criteria in the correct case (i.e., upper, lower, or mixed).

102
 4 Events

Field Description

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

5 Press Enter. The Directory of Work Center Events is displayed:

ASG-Zeke Directory of Work Center Events Row 1 to 2 of 2

Command ===> Scroll ===> PAGE

Line Commands: A disAble B Browse C Complete N eNable O dOcumentation

R Refresh

Today :04/19/2013 Time :12:46:55 (36:46:55)

Event Work Date Versn Sched Event Name Appl Grp System Set Status
000202 06/17/2013 00000 00:00 EANTST TSO45 Y NOT DONE
000205 06/17/2013 00000 00:00 EANTST05 TSO45 Y NOT DONE
000833 06/17/2013 00000 00:00 TEST OVAR APPL GRX TSO45 Y NOT DONE
***************************** Bottom of data ******************************

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

Desired Result Action

Browse the event Enter B to the left of the Event field.

Use this command before completing the work center if
SET=N.

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.

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

Desired Result Action

Display the Work Center Enter O to the left of the Event field. See “Accessing Event
Doc. Segments Screen Documentation” on page 166.

The Work Center Control Function screen is displayed in Browse mode:

ASG-Zeke Work Center Control Function

Command ===>

Primary Commands: COMPLETE DISABLE DOCUMENT ENABLE REFRESH

Event: 000229 Event Name: PAYCHECK System: A

Appl: PAY Group: PAY UserID: KAC Set ver: 00000

Schd: 00:00 Sdate: 01/30/2013 Rdate: 01/30/2013 Today:01/30/2013

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.

104
 4 Events

7 Press Enter. The Work Center Control Function screen is displayed in Update mode:

ASG-Zeke Work Center Control Function

Command ===>

Depress the enter key to accept the new value, or depress PF3 to
maintain the current value.

Event: 000229 Appl: PAY Group: PAY UserID: KAC

Event Name: PAYCHECK System: A Set ver: 00000

Schd: 00:00 Sdate: 01/30/2013 Rdate: 01/30/2013 Today: 01/30/2013

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.

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

10 Press Enter. A verification screen is displayed after all the variables are set:

ASG-Zeke Work Center Control Function Row 1 to 2 of 2

Command ===> Scroll ===> PAGE

Primary Commands: COMPLETE CANCEL

Event: 000229 Ver: 00000 Sdate: 01/30/2013 Rdate: 01/30/2013

Today :01/30/2013 Time :15:59:27 (39:59:27) Set Ver: 00000
--------------------------------------------------------------------------
Variable: $PAYCHECK
?Value: '1051'
****************************** Bottom of data*******************************

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

Desired Result Action

Confirm that the values are correct, Enter COMPLETE on the Command line, and
and complete the work center. press Enter.
The Work Center Directory is displayed. Zeke
updates the event status to Done.

Do not set the values, or do not Enter CANCEL on the Command line, and press
complete the work center. Enter.
The Work Center Directory is displayed. The
event status is unchanged.

106
 4 Events

Scheduling and Dispatching Criteria

This section describes the various types of scheduling criteria and dispatching
prerequisites you can specify in the EMR. You can assign any of these requirements (or a
combination) to any type of Zeke event:
• Starting and ending time requirements for an event. See “Schedule Time” on
page 107.
• Which days (according to the designated calendar) to schedule the event. See
“OCCURS Clauses” on page 110.
• Dependencies on other events or system activities. See “WHEN Conditions” on
page 126.
• Number of versions of an event that can exist the same schedule. See “Multiple
Event Versions” on page 142.
• Number of occurrences of an event in the schedule. See “Recurring and Permanent
Events” on page 145.
• Key events that affect the workflow. See “Milestone Events” on page 150.
• Active scheduling environment (i.e., a collection of resources that are required to
meet a specified state). See “Scheduling Environments” on page 153.

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.

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

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

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 In the Sched field, specify the normal schedule time for the event.
specific time
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).

Set the earliest time Zeke In the Early field, specify the earliest time that Zeke can dispatch the
can dispatch an event 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.
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 ‘must
end’ time, Zeke issues a console message and removes the event
from the dispatch queue.
For example, let’s suppose the Mustend value 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.

Set the latest time Zeke In the Notafter field, specify the latest time that Zeke can dispatch an
can dispatch an event event. Prior to dispatch, Zeke compares the current system time and
the ‘not after’ time. If the ‘not after’ 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.

108
 4 Events

Desired Result Action

Set the time Zeke In the Latestart field, specify the time by which Zeke must dispatch
considers an event as late the event. The valid values range from 00:00 through 47:59.
(based on its start time) The event is flagged as late if the current system time is past the ‘late
start’ time and Zeke has not dispatched the event. (If the ‘late start’
time is reached before Zeke dispatches the event, Zeke issues
message Z0302I. See “Late Dispatch Messages” on page 244 for
more information.)
For example, if an event is scheduled to run at 12:00 P.M. with a
Latestart value 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

‘late start’ 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 ‘late start’ time is reached.
• If an event is projected to start late, Zeke does not prevent the
event from being dispatched until the event’s ‘not after’ 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 In the Lateend field, specify the time by which the event must finish.
considers an event as late The valid values range from 00:00 through 47:59. The event
(based on its end time) is flagged as late if the current time is past the ‘late end’ time and the
event has not completed yet. (If the ‘late end’ time is reached before
the event has completed, Zeke issues message Z0302I. See “Late
Dispatch Messages” on page 244 for more information.)
Zeke predicts whether an event might not be completed before its
‘late end’ 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 ‘must end’ time is
violated.
• If an event is projected to finish late, Zeke does not flag the
event as late until the event’s ‘late end’ time is reached.

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

Desired Result Action

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

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

110
 4 Events

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)

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

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

Instead, this clause is valid:

(WORKDAYS AND (MONDAY OR TUESDAY))

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.

+ 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:
(plus)
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.

- 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:
(minus)
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.

112
 4 Events

Keyword Description

THURSDAY Schedules on Thursdays.

FRIDAY Schedules on Fridays.

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.

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.

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

Keyword Description

EOM Schedules on last day of the month.

EOM-xx Schedules xx days before last day of the month.

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.

114
 4 Events

Keyword Description

DATE xx Schedules on the specified date if the relationship is true, where:

mm/dd/yyyy
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/2013)
Schedules on any date less than or equal to December 31, 2013.

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.

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

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 Schedules every xxx days beginning on the specified date. Zeke does not
DAYS schedule the event before the specified date.
BEGINNING
mm/dd/yyyy Note:
You also can use the date format dd/mm/yyyy if your OASISxx options
member specifies the start-up option DATE=DDMM.

EVERY xxx Schedules every xxx workdays before and after the specified date (when
WDAYS FROM scheduling events for the future).
mm/dd/yyyy
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 Schedules according to the calendar (including nonworking days) and the
eventname/ OCCURS clause of another event. If you update the OCCURS clause or
number 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.

116
 4 Events

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

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.

WEEKENDS Schedules on weekends.

HOL/WEEK Schedules on holidays and weekends.

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

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.

VAR Schedules if the specified Zeke variable is true. Use with AND. For example:
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/2013)

Occurs every Wednesday before January 31, 2013.

OCCURS (MONDAY.1 OR MONDAY.3)

Occurs the first and third Monday of each month or period.

OCCURS (EVERY 14 DAYS BEGINNING 02/12/2013)

Occurs every other Tuesday starting on February 12, 2013.

OCCURS (EVERY 5 WDAYS FROM 03/26/2013)

Occurs every Wednesday before and after March 26, 2013.

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.

118
 4 Events

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.

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

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.

120
 4 Events

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

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

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)

122
 4 Events

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

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

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 an EMR” on page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

2 Enter OCCURS on the Command line, and press Enter. The Event Record Occurs
Clause screen is displayed:

ASG-Zeke Event Record Occurs Clause EDIT

Command ===>

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

124
 4 Events

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 193 or “Using the ZADD Operator
Command” on page 255.

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 110 for a full discussion of OCCURS clauses. See
“OCCURS Keywords” on page 112 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 Occurs Hit Resolution EDIT

Command ===>

Primary Commands: BROWSE EDIT NMONTH PMONTH NYEAR PYEAR

Month: 03 Year: 2013 Event: 000006 Ename: ZEKE60TST6 Calid: A

M O N T U E W E D T H U F R I S A T S U N
1 W 2 W
3 4 * 5 * 6 7 8 W 9 W
10 11 * 12 * 13 14 15 W 16 W
17 18 * 19 * 20 21 22 W 23 W
24 25 * 26 * 27 28 29 W 30 W
31

Ver: 00000
Occurs: (TUESDAY OR WEDNESDAY OR DAY.11)

W = Weekend H = Holiday S = Slack day * = Event scheduled on this date

*X = Event scheduled x times on this date

An asterisk (*) marks the days the event is scheduled to occur.

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

Zeke uses these codes to indicate the status of each day in the current month:

Code Meaning

W Weekend day

H Holiday

S Slack day (i.e., day in the period between accounting calendars)

6 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 Enter NMONTH on the Command line, and press Enter.
the next month

View the schedule for Enter PMONTH on the Command line, and press Enter.
the previous month

View the schedule for Enter NYEAR on the Command line, and press Enter.
the next year

View the schedule for Enter PYEAR on the Command line, and press Enter.
the previous year

View the schedule for Specify the number of the month (e.g., 01 for January, 12 for
a specific month December) in the Month field, and press Enter.

View the schedule for Specify the year in the Year field, and press Enter.
a specific year

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

126
 4 Events

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

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

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

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

128
 4 Events

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

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

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

Note:
Resource control is a another effective way that you can ensure that conflicting events do
not run at the same time. See “Defining or Updating a Logical Resource” on page 281 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 271). 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 310).

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

Cross-system JCL Error Checking

When you enable NOTDURING processing across a Zekeplex, JCL errors in a
Zeke-controlled job are recognized when the job fails on a different system than the one
where it was dispatched.

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.

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.

130
 4 Events

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.

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

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

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

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

132
 4 Events

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)

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.

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

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

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

134
 4 Events

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

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)

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

WHEN Condition Keywords

These are the available keywords that you can use with the WHEN parameter to define
WHEN conditions:

Keyword Description

AT (Target) Specify the Netregid (up to eight characters long) for the remote system
netregid 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 131 for more information.

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 308)
controls the dataset dispositions that qualify as triggers for DSN WHEN
conditions.

136
 4 Events

Keyword Description

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)

NOTDURIN (Not during) Specify the program name or jobname. This prevents jobs/programs
G 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 129 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.

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

Keyword Description

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.

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)

138
 4 Events

Keyword Description

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 134 for a detailed
explanation on using variables in WHEN conditions.

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.

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

Keyword Description

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 129 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 129 for more information.

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

140
 4 Events

Keyword Description

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.

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 an EMR” on page 52.

ASG-Zeke Event Master Definition EDIT

Command ===>

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: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y
Bim: Mbr:
JESQ (Y, D=dynamic):

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

2 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 Event Master Record Function EDIT

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

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

Multiple Event Versions

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.
142
 4 Events

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.

For an event that originates from Zena and is processed through EA Services (see
“Processing Remote Work Requests from Zena” on page 75), the version number is used
as a JCL filter ID, which is used to customize the JCL at dispatch time.

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
an EMR” on page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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 Class: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

2 Enter WHEN * on the Command line, and press Enter.

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

If there are WHEN conditions defined for the event, the WHEN/SET Clause
Directory screen is displayed:

ASG-Zeke WHEN/SET Clause Directory

Command ===> Scroll ===> PAGE

Primary Commands: ADD

Line Commands: E - Edit B - Browse D - Delete

Evt: 000032 Type: JOBJob: NOMTEST Evt Name: TESTADDNM Calid: A

Info: Platform: MVS
Version Clause (partial) More
==========================================================================
00000 (EOJ TESTJOB0)
00002 (EOJ TESTJOB0 OR VAR $TESTVAR EQ YES)
00003 (EOJ TESTJOB2)
00004 (EOJ TESTJOB0 AND EOJ TESTJOB2 VER 2)
******************************Bottom of data******************************

All the WHEN conditions that have been defined for the event are listed, with their
corresponding version numbers.

If a dependency is longer than the width of the screen (indicated by a '>' symbol in
the More column), you must access the Event Master Record Function screen to
view the remainder of the statement. To do so, use the Browse line command as
described in the next step.

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

Desired Result Action

Add a dependency for a Enter ADD ver# on the Command line (where ver# is the
new version number 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 141 for
further instructions.

Browse the WHEN Enter B to the left of the dependency that you want to
conditions for a particular browse. Press Enter.
version of the event
The Event Master Record Function screen is displayed in
Browse mode.

Delete the WHEN Enter D to the left of the dependency that you want to delete.
conditions for a particular
The Event Master Record Function screen is displayed and
version of the event
you are asked to confirm the deletion. Enter DELETE on the
Command line, and press Enter to confirm, or press F3 to
cancel.
Or

144
 4 Events

Desired Result Action

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.

Recurring and Permanent Events

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 (i.e., Notafter value) specified, and the
calculated start time is greater than the Notafter value, 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.

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

Permanent Events
Zeke never removes a permanent event from the schedule, so the event always is
available to respond to triggers (even during schedule load processing). A permanent
event can run an unlimited number of times. You activate a permanent event by adding it
to the schedule with the ZADD operator command. The event occurs across every
schedule period until you remove it using the ZDELETE operator command.

Zeke processes permanent events in the same manner as recurring events, with these
exceptions:
• Zeke forces the OCCURS clause to REQUEST.
• Zeke ignores nonworking day options in the calendar.
• Only one version can be active (the Verload field is set to 0).
• The event can be triggered by any date. The values of the Zeke generation options
TrigDt, DsnTrig, and RemTrig are treated as “any” (i.e., A or TA).
• Zeke ignores any Multhit generation options.

Schedule Time
Zeke uses only the schedule time (Sched) to time-satisfy a permanent event, and ignores
any other time specifications (e.g., early time).

Each time Zeke executes (and then reschedules) a permanent event, the run date
increments, so that the schedule time stays under 24:00. (Normally, when the schedule
time passes 24:00, the run date increments and the schedule time is reduced by 24 hours.)

You can set the schedule time, or any other time that increments at rescheduling (e.g.,
Late, Mustend, or Notafter), above 24:00 in the EMR for a permanent event. The first
time Zeke reschedules the event, the run date increments so that the updated schedule
time is below 24:00.

Freqcalc is S (Schedule Time)

When Zeke reschedules a permanent event (with the Freqcalc value set to S) Zeke
updates the event’s run date and schedule time to its previous run date and schedule time
(added to the event’s frequency).

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

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

Defining a Recurring or Permanent Event

To define a recurring or permanent event

1 Access the Event Master Definition screen, as instructed in “Accessing an EMR” on

page 52.

ASG-Zeke Event Master Definition EDIT

Command ===>

Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N Permanent: N Milestone: N Platform: MVS
Evt: 163 Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL Verload: 0 Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00
Dprty: 50 Operok: N Times: 3 Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON

Job: CGCJOBA Class: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

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

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

Field Description

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

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.

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

148
 4 Events

Field Description

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

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.

Trig 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 8:00
time

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

Field Description

Zeke schedules the event to run at 8:00 A.M.

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

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

4 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

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

Milestone Event Statuses

If you use OpsCentral or ASG-Unified Management Architecture (herein called UMA),
Zeke can send milestone event statuses via the Zeke server for display from an
OpsCentral client or in a UMA dashboard.

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.

150
 4 Events

These are the milestone event statuses:

Status Description

n/a Indicates whether the milestone event is in the current schedule.

(gray)

Normal Indicates whether Zeke expects the milestone event to process normally in the
(green) event flow.

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

Missed Indicates whether the milestone event has failed or violated a time constraint
(red) (according to its ‘late start’, ‘late end’, ‘not after’, or ‘must end’ times).

At-risk Indicates whether the milestone event is at risk because of a problem with a
(yellow) 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 2011134 ver 00001 JOBKAC is at risk due
to predecessor events:
Event 000083 2011134 ver 00001: Failed

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.

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

Defining a Milestone Event

To define a milestone event

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

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

Code Meaning

N Default. Do not designate the event as a milestone.

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

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

4 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

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

152
 4 Events

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 308)
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 (ISPF only). See
“Using Schedule View” on page 193.
• 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.

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

To specify a scheduling environment for an event

1 Access the Event Master Definition screen as instructed in “Accessing an EMR” on

page 52.

ASG-Zeke Event Master Definition EDIT

Command ===>

Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N Permanent: N Milestone: N Platform: MVS
Evt: 163 Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL Verload: 0 Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00 Lateend: 00:00
Dprty: 50 Operok: N Times: 3 Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0 Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON

Job: CGCJOBA Class: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

2 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 326 for more information.

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

4 Perform the procedure, “Defining an OCCURS Clause” on page 124, to specify

when Zeke schedules the event.

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

154
 4 Events

Condition Codes
This section explains how to add, update or delete condition codes for an event.
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.

To define condition codes for an event

1 Access the Event Master Definition screen for the event, as instructed in “Accessing
an EMR” on page 52.

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

2 From the Event Master Definition, enter CCODE on the Command line, and press
Enter. The Condition Code Validation screen is displayed:

ASG-Zeke Condition Code Validation EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line

Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE60CC

Operators: EQ NE LE LT GE GT RA =Range
Actions: F = Fail, C = Cancel, O = Ok

Stepname Procstep Operator - Range - Action

Low High
EOJ CC
STEP01 ******** GT 8 F
STEP02 ******** NE 16 O
******** ******** GT 0 C

3 Perform the steps in the Action column (depending upon the desired result):

Desired Result Action

Add a new or edit an Enable Edit mode (if necessary).

existing condition code
Go to step 4.

Delete a single condition Enter D to the left of the condition code that you want to
code 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.

Note:
You cannot insert lines before the line EOJ CC.

Repeat this line Enter R to the left of the line that you want to repeat, and
press Enter.

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.

156
 4 Events

Field Description

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

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.

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

Field Description

O Continue processing.

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

6 Press Enter to save the changes.

Sample Condition Code Entries

These sample screens illustrate a few different scenarios to assist in defining condition
codes.

In this example, Stepname Procstep ******** ******** acts as a generic condition

code, and applies to all steps except STEP3. If STEP3 receives a condition code 4, job
processing continues; but if any other step gets a condition code greater than zero, the job
is marked AEOJ and is cancelled:

ASG-Zeke Condition Code Validation EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line

Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE60CC

Operators: EQ NE LE LT GE GT RA =Range
Actions: F = Fail, C = Cancel, O = Ok

Stepname Procstep Operator - Range - Action

Low High
EOJ CC
STEP3 ******** EQ 4 O
******** ******** GT 0 C

158
 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 Condition Code Validation EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line

Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE60CC

Operators: EQ NE LE LT GE GT RA =Range
Actions: F = Fail, C = Cancel, O = Ok

Stepname Procstep Operator - Range - Action

Low High
EOJ CC GT 0 F
STEP3 ******** EQ 4 O
STEP5 ******** LE 8 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 Condition Code Validation EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line

Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE60CC

Operators: EQ NE LE LT GE GT RA =Range
Actions: F = Fail, C = Cancel, O = Ok

Stepname Procstep Operator - Range - Action

Low High
EOJ CC
STEP3 ******** EQ 4 O
STEP5 ******** LE 8 O
******** ******** GT 0 F

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

This is the same scenario, but with a procstep defined:

ASG-Zeke Condition Code Validation EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line

Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE60CC

Operators: EQ NE LE LT GE GT RA =Range
Actions: F = Fail, C = Cancel, O = Ok

Stepname Procstep Operator - Range - Action

Low High
EOJ CC
STEP3 PSTEP3 EQ 4 O
STEP5 ******** LE 8 O
******** ******** GT 0 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 Condition Code Validation EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line

Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE60CC

Operators: EQ NE LE LT GE GT RA =Range
Actions: F = Fail, C = Cancel, O = Ok

Stepname Procstep Operator - Range - Action

Low High
EOJ CC
MYSTEP EQ 4 O
******** ******** GT 0 F

160
 4 Events

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.

Related Generation Options

These 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 318, 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.

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

Defining Auto Replies

This procedure explains how to define or maintain auto replies for a job event.

To define or maintain automatic replies

1 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 318.
• 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 164.

2 Access the Event Master Definition screen, as instructed in “Accessing an EMR” on

page 52.

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 Auto Reply Summary

COMMAND ===> SCROLL ===> PAGE Z1113000

Primary Commands: ADD DELALL

Line Commands: B - Browse D - Delete E - Edit

Event: 000019 Jobname: SPTEXD19 System: ZEQA Event Name: EKGSTRT1

NUM ----------------------- Message Text ----------------------- PROGRAM
001 TEST MSG
001 ENTER GO TO PROCESS
***************************** Bottom of data ******************************

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

Desired Result Action

Add an auto reply element Enter ADD on the Command line, and press Enter.

Delete all auto reply 1 Enter DELALL on the Command line, and press Enter.
elements
2 Press Enter again to confirm.

162
 4 Events

Desired Result Action

Browse the auto reply Enter B to the left of the NUM field, and press Enter.
detail

Edit the auto reply element Enter E to the left of the NUM field, and press Enter.

Delete the specific Enter D to the left of the NUM field, and press Enter.
auto reply element
Press Enter again to confirm.

The Auto-Reply Function screen is displayed:

ASG-Zeke Auto-Reply Function EDIT Update complete

Command ===>

Primary Commands: ADD BACK BROWSE DELALL DELETE EDIT NEXT

Event: 000019 Jobname: SPTEXD19 System: ZEQA Event Name: ZEKE60CC

Desc: EKGSTRT1
Desc2:

Automatic Reply Element Number: 001

Msg text: ENTER GO TO PROCESS

Reply: GO

Effective as of: 01/01/2013 <== MM/DD/YYYY

Effective until: 06/01/2013 <== MM/DD/YYYY
Job step name: STEP1
Program (Exec):

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 Complete these fields (as applicable):

Field Description

Msg Text Required. Specify the message text (up to 60 characters long) for
which Zeke will search. When it finds a match, Zeke issues the
appropriate auto reply.
You do not have to specify the whole message, but just enough to
make a unique match. The message ID usually is a unique identifier.

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

Field Description

Reply Required. Specify the reply (up to 60 characters long) that Zeke
issues in response to the message found. For example:

For a null reply Leave this field blank.

For 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 Enter a variable and any appropriate

constant values in a reply static text. For example:
YESTERDAY WAS $(PREVDATE)

Effective as of Optional. Specify the date (MM/DD/YYYY) that the reply becomes
effective.

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

Job step name Optional. Specify the MVS job stepname (up to eight characters
long) that issues the message text. The auto reply is valid only if this
job step issues the message.

Program (Exec) Optional. Specify the program name (up to eight characters long)
that issues the message text. The auto reply is valid only if this
program issues the message.

6 Press Enter to save the changes.

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:

164
 4 Events

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.

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

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

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

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

Accessing Event Documentation

You can maintain event documentation through the Event, Schedule View (ISPF only),
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 Perform the steps in the Action column (depending on the desired result):

Desired Result Action

Update documentation 1 Enter EDIT on the Command line.

for which you know the
2 Specify the event number in the Event field.
event number
3 Press Enter. The Documentation Segments screen is
displayed.
Go to step 4.

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

166
 4 Events

The Event Documentation Directory is displayed:

ASG-Zeke Event Documentation Directory

Command ===> Scroll ==> PAGE

Line Commands: E/E1/E4 - Edit B/Bn - Browse D/D1/D4 - Delete

n = 1 through 4 for specific types of documentation

1 2 3 4
Event -Event Name- Jobname Type Scratch Text Tape Note
000001 ZEKE60TST1 MSG * * * *
000002 ZEKE60TST2 MSG
000003 ZEKE60TST3 MSG * * *
000004 ZEKE60TST4 MSG
000005 ZEKE60TST5 MSG
000006 KTEST1 TSKKGUT1 JOB
000007 KTEST2 TSKKGUT2 JOB *
000008 KTEST3 TSKKGUT3 JOB
000009 KTEST4 TSKKGUT4 JOB
000010 KTEST5 TSKKGUT5 JOB * * * *
000011 ZEKE60CC SPTEXD11 JOB
000012 ZEKE60CC SPTEXD12 JOB
000013 WORK * * * *
000014 VCOM
000015 ZCOM
000016 SCOM

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

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

Desired Result Action

Edit scratch pad Enter E1 to the left of the Event field, and press Enter.
documentation for the event
Go to “Maintaining Scratch Pad or Note Documentation”
on page 169.

Edit text documentation for Enter E2 to the left of the Event field, and press Enter.
the event
Go to “Maintaining Text Documentation” on page 170.

Edit dataset documentation Enter E3 to the left of the Event field, and press Enter.
for the event
Go to “Maintaining Dataset Documentation” on page 171.

Edit note documentation for Enter E4 to the left of the Event field, and press Enter.
the event
Go to “Maintaining Scratch Pad or Note Documentation”
on page 169.

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

Desired Result Action

Delete the specified Enter Dn to the left of the Event field, and press Enter
documentation for the event (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 Documentation Segments EDIT

Option ===>

Primary Command: DELETE

Event: 000031
Jobname: A2345678 Event Name: TESTNAME System: A Appl:

Documentation Record Selection Options

1 * SCRATCH Scratch pad

2 * TEXT Text information
3 TAPE Dataset name information
4 * NOTE 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

Access scratch pad Enter 1, and press Enter.

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

Access text documentation Enter 2, and press Enter.

Go to “Maintaining Text Documentation” on page 170.

168
 4 Events

Desired Result Action

Access dataset or tape Enter 3, and press Enter.

documentation
Go to “Maintaining Dataset Documentation” on page 171.

Access note documentation Enter 4, and press Enter.

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

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 Schedule View (ISPF only), 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.

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

To maintain scratch pad or note documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in “Accessing

an EMR” on page 52.

ASG-Zeke Documentation Scratch Pad EDIT

Command ==>

Primary Commands: BROWSE CANCEL DELETE EDIT

Line 1 SCRATCH TEXT FOR 30-BYTE NAME JOB

2
3
4
5
6
7
8
9
10

Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: A

Desc : 30-CHAR NAME NOM
Desc2:
Early: Sched: 00:00 Late: Freq: Times: 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 Press Enter to save the changes.

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 (ISPF only), and
Documentation options. Through the Work Center option, you can only browse text
documentation.

170
 4 Events

To maintain text documentation

1 Access the Text Documentation screen, as instructed in “Accessing Event

Documentation” on page 166.

ASG-Zeke Text Documentation EDIT

Command ===> Columns 000 000 Scroll ===> PAGE

Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: A

****** *************************** Top of Data *****************************
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000001 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 Press Enter to save the changes.

Maintaining Dataset Documentation

You can access dataset documentation for an event through the Events, Schedule View
(ISPF only), 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 166.

ASG-Zeke Data Set Name List EDIT

Command ===> Scroll ===> PAGE

Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat

Event: 000031 Jobname: A2345678 System: A Event Name: TESTNAME

I/O T/D Ver --------------Dataset Name------------------

I T 001 JNM.TAPE.STORE
***************************** Bottom of data ******************************

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

2 Complete these fields (as applicable):

Field Description

I/O Specify the dataset type. These are the valid values:

I Default. Input dataset.

O Output dataset

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

T Default. Tape.

D Disk

Ver 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 Specify the dataset name.

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

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

4 Press Enter to save the changes.

172
 4 Events

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 an EMR” on

page 52:

ASG-Zeke Event Master Definition EDIT

Command ===>

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 Class: Pri: 0

JCL--> PDS: Member: CMS: Ftype:

Zeke JCL (Y=Yes): Y JESQ (Y, D=dynamic):

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

2 Enter ACC on the Command line, and press Enter. The Event Master Record
Accounting screen is displayed:

ASG-Zeke Event Master Record Accounting BROWSE

Command ===>

Primary Commands: BROWSE EDIT

Evt: 000333 Type: JOB Job: MBCBR14 Ename: ZEKEKMCASG System: ZEQA

Avgdur: 00:12:15 Enable Duration Alerts: Job ran 20 Times

Alert Tolerance: 50 Fail if short or long:
Normal Range: 00:05:10 - 00:19:20 Clear Duration Stats Y

Dispatched 6 Times Last Update: 01/14/2013 15:33 by BOB

Start: 01/14/2013 17:37:00 End: 01/14/2013 17:37:30 Job ID: JOB00006
Version: 1 Sched Date: 01/14/2013 Status: F/FAIL

Dispatch Date 01/14/2013 at 17:37:00 Tapes: 0 Vmem: 0

Dur: 00:00:30 Cputime: 00:00:01 Comp.code C0000 Status: F/FAIL

Dispatch Date 01/07/2013 at 11:31:00 Tapes: 0 Vmem: 0

Dur: 00:21:55 Cputime: 00:00:01 Comp.code C0000 Status: Fail Long

Dispatch Date 01/02/2013 at 12:25:00 Tapes: 0 Vmem: 0

Dur: 00:14:02 Cputime: 00:00:01 Comp.code C0000 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.)

174
 4 Events

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

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

Average Duration
Zeke calculates the average duration by adding the current duration to the last 10
execution times, then dividing by 11. 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 is a value ranging 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

176
 4 Events

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 178). You also can override these
global settings for specific events (see “Enabling or Disabling Job Duration Alerts and
Failures” on page 179).

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

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:
• 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 (ISPF only), 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).

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

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

178
 4 Events

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 291 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 178. You use the procedure is this section to override the generation options for
selected events.

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

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

ASG-Zeke Event Master Record Accounting BROWSE

Command ===>

Primary Commands: BROWSE EDIT

Evt: 000333 Type: JOB Job: MBCBR14 Ename: ZEKEKMCASG System: ZEQA

Avgdur: 00:12:15 Enable Duration Alerts: Job ran 20 Times

Alert Tolerance: 50 Fail if short or long:
Normal Range: 00:05:10 - 00:19:20 Clear Duration Stats Y

Dispatched 6 Times Last Update: 01/14/2013 15:33 by BOB

Start: 01/14/2013 17:37:00 End: 01/14/2013 17:37:30 Job ID: JOB00006
Version: 1 Sched Date: 01/14/2013 Status: F/FAIL

Dispatch Date 01/14/2013 at 17:37:00 Tapes: 0 Vmem: 0

Dur: 00:00:30 Cputime: 00:00:01 Comp.code C0000 Status: F/FAIL

Dispatch Date 01/07/2013 at 11:31:00 Tapes: 0 Vmem: 0

Dur: 00:21:55 Cputime: 00:00:01 Comp.code C0000 Status: Fail Long

Dispatch Date 01/02/2013 at 12:25:00 Tapes: 0 Vmem: 0

Dur: 00:14:02 Cputime: 00:00:01 Comp.code C0000 Status: Success

2 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 175 for details about how Zeke calculates
these values, and how they interact with each other.

180
 4 Events

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 Press Enter to save the changes.

Note:
See “Duration Alerts and Failures” on page 177 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.

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

182
 Chapter 5: Creating and Monitoring the

5 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) 184

Creating the Zeke Schedule 185
Creating the Schedule Manually 186
Creating the Schedule Automatically 188
Downloading the Schedule to Zeke Agent 189
Forecasting and Simulating the Schedule 189
Forecasting the Schedule 190
Simulating the Schedule 190
Creating and Adding an Event to the Schedule 193
Using Schedule View 193
Schedule View Commands 193
Displaying Scheduled Events 203
Updating a Scheduled Event 208
Displaying or Updating an Event Status 211
Managing WHEN Conditions 217
Managing Event Resources 221
Accessing an Expanded SQR (Using ZOOM) 222
Customizing Schedule View 224
Accessing Other Zeke Online Functions 230
Managing JCL 232

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

Topic Page

Zeke Dispatching 243

Dispatch Priority 243
Late Dispatch Messages 244
Early Warning Alerts 244
ZCOM Function 246
Issuing Zeke Commands through ZCOM 247
Issuing Zeke Commands outside of ZCOM 247
Modifying PF Keys 248
PathFinder 249
Manually Adding Events to the Schedule 255
Using the ZADD Operator Command 255
Using the ADD Function 258
Adding Events By Path 261

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 8-hour period of shift 3 is
considered to be part of the same logical workday as shifts 1 and 2.

184
 5 Creating and Monitoring the Schedule

When the SCHEDULE function runs, it selects every event within 48 hours to be part of
the day’s schedule. For example, if the schedule runs on Monday at 08:00, events are
selected if their OCCURS clauses match MONDAY and the schedule time is between
00:00 and 47:59.

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.
• Analyzes each event defined in the Zeke database and determines whether the event
is scheduled to occur during the upcoming schedule period.
• Immediately marks events that have no dispatch time (and are not scheduled for a
future date) as time-satisfied.

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

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

Note:
Zeke does not dispatch any newly-scheduled events until the entire schedule is loaded.

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

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.

186
 5 Creating and Monitoring the Schedule

The schedule load is complete when this message appears on the console:

Z5G03I SCHEDULE LOAD COMPLETE

Caution! Do not execute multiple SCHEDULE TODAY ACTIVATE functions

simultaneously in the same batch job, or while any system is in WARM
mode (ZKILL WARM). Unpredictable results 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 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.

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

5 Optional. You can specify the use of a by the SCHEDULE function when
processing SQRs. If you use the DATASPACE option, a temporary is created when
the SCHEDULE function starts, and again before any schedule reports are
generated. See the ASG-Zeke Scheduling for z/OS Reference Guide for more
information.

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

To set up a job that creates the schedule automatically

1 Define a job event as described in “Job Events” on page 67.

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

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

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, 2013, issue this command:
ZADD EV 100 DATE 2013363 RDATE 2013363

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.

188
 5 Creating and Monitoring the Schedule

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.

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 to Zeke Agent" on page 81 and “Defining Schedule Download
Agents” on page 338 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 124 for more
information.

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

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

Method Description

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.

For example:

//ZEKESCHD JOB
//SCHED EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’
//SYSIN DD*
SCHEDULE DATE 08/23/2013 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.

190
 5 Creating and Monitoring the Schedule

You can generate these types of simulation reports (depending on which keyword you
specify):

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

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

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

COPY FROMDD=INCAT TODD=OUTCAT

SIMULATE STARTDATE 01/01/2013 STARTTIME 23:00
STOPDATE 01/02/2013 STOPTIME 22:59
DATABASEDD OUTCAT
SATISFY ALL
INITIATORS 10
TAPEDRIVES 5
SYSTEM MVSSPA
REPORT ALL

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

COPY FROMDD=INCAT TODD=DATASPACE

SIMULATE STARTDATE 01/01/2013 STARTTIME 23:00
STOPDATE 01/02/2013 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 .

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.

192
 5 Creating and Monitoring the Schedule

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.

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

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 258 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 203 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 208 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 Display the Event Master Selection Criteria screen.

194
 5 Creating and Monitoring the Schedule

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

WORK Display the Work Center Selection Criteria screen.

These additional ISPF primary commands are valid on the Command line in Schedule
View and can be used in navigating the Schedule View display:

Command Action

eXclude Suppress all lines from the display. For example:

EX
X ALL
You use the RESET command to re-display all lines.

Note:
The exclude state is reset automatically when the display is refreshed.

RESet Re-display all lines that were previously suppressed using the EXCLUDE
command.

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

Command Action

Find Find and move the cursor to the beginning of the specified text string. This is
the command format:
FIND string
Search is not case sensitive.

Note:
You must enclose string in single quotes only if it contains embedded
blanks.

You can include one of these optional keywords to control the search
direction:

ALL Find all occurrences of the specified text string.

FIRST Find the first occurrence of the specified text string.

LAST Find the last occurrence of the specified text string.

NEXT Find the next occurrence of the specified text string.

PREV Find the previous occurrence of the specified text string.

Note:
The FIND command does not search across columns.

You can include one of these optional keywords to indicate whether to search
only excluded lines or only non-excluded lines; otherwise, all lines are
searched:

NX Limit the search to non-excluded lines only.

X Limit the search to excluded lines only.

RFIND Find and highlight the next occurrence of the text string specified on the
previous FIND string command.

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.

196
 5 Creating and Monitoring the Schedule

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.

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

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

Command Action

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 222
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 237 for more information.

Note:
This command is not supported for SQRs that have JESQ as the JCL source.

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.

198
 5 Creating and Monitoring the Schedule

Command Action

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 249 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 249 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 221 for more information.

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

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

Command Action

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

WHEN Display and update the WHEN conditions for the selected event during this
schedule run.
See “Managing WHEN Conditions” on page 217 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 211 for more
information.

WOK Satisfy all WHEN conditions for the selected event.

See “Managing WHEN Conditions” on page 217 for more information.

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

200
 5 Creating and Monitoring the Schedule

Command Action

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 222 for more
information.

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

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

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

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

202
 5 Creating and Monitoring the Schedule

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 Schedule Information Selection Criteria

Command ===>

1 Schedule View Schedule Display and Modification Facility

2 ZCOM List Scheduling System Commands
3 ADD Function Select Event Records "TO ADD" to Schedule
4 ADD by path Select Event Records by path

Event ===> Permanently save criteria ===> N

Event Types Selection Field Masks ---- Event Status ----

Job: Job Name: Actv: Y Done: Y
Msg: Event Name: Pend: Y ABOK: Y
Pcom: Application: Sched: Y Fail: Y
Work: Group ID: Hold: Y FBOK: Y
Vcom: User ID: Late: Y FSucc: Y
Zcom: System: / OperOk: N
Scom: Disp Class: Needs - TimeOk: N %Actv:
REXX: Sched Date: EQ \ WhenOk: N
Run Date: EQ
Target:
Permanent:
Milestone:

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

Field Description

Event Types Specify any character (except a space) next to the event types that you
want to display.

Note:
Schedule View can include multiple event types in the same view; in
this case, any displayed fields that are not relevant for a particular event
type appear blank.

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

Field Description

Selection Field Specify any additional information about the events that you want to
Masks select.
You can use wildcard and placeholder characters in your selection
criteria (see “Generic Selection Criteria” on page 53).
These are the available filtering options:

Job Name Selects events with the specified jobname.

Event Name Selects events with the specified event name.

Application Selects events with the specified application name.

Group ID Selects events with the specified group name.

User ID Selects events with the specified user name.

System Selects events defined with the specified Zeke system ID.

Disp class Selects job events with the specified job class.

Sched Date Selects events for the specified schedule date.

You can specify an explicit date (in yyddd or yyyyddd
format) or a date relative to the current date.
To specify a relative date, enter an operator + (plus sign)
or - (minus sign) followed by a number of days relative
to the current date. The valid values range from -32767
through +32767 to indicate the number of days prior to
or after the current date, where 0 represents the current
date. (Zeke automatically converts the value to an explicit
date.)
When specifying the date, you also can set the relational
operator to one of these values:

EQ Default. Selects events with the specified

(explicit or relative) schedule date.

LE Selects events with a schedule date earlier

than or equal to the specified (explicit or
relative) schedule date.

LT Selects events with a schedule date earlier

than the specified (explicit or relative)
schedule date.

204
 5 Creating and Monitoring the Schedule

Field Description

GT Selects events with a schedule date later than

the specified (explicit or relative) schedule
date.

GE Selects events with a schedule date that is

later than or equal to the specified (explicit or
relative) schedule date.

NE Selects events with a schedule date not equal

to the specified (explicit or relative) schedule
date.

Run Date Selects events for the specified run date.

You can specify an explicit date or a date or range relative
to the current date.
To specify a relative date, enter an operator + (plus sign)
or - (minus sign) followed by a number of days relative
to the current date. The valid values range from -32767
through +32767 to indicate the number of days prior to
or after the current date, where 0 represents the current
date. (Zeke automatically converts the relative value to an
explicit date.)
When specifying the date, you also can set the relational
operator to one of these values:

EQ Default. Selects events with the specified

(explicit or relative) run date.

LE Selects events with a run date earlier than or

equal to the specified (explicit or relative) run
date.

LT Selects events with a run date earlier than the

specified (explicit or relative) run date.

GT Selects events with a run date later than the

specified (explicit or relative) run date.

GE Selects events with a run date later than or

equal to the specified (explicit or relative) run
date.

NE Selects events with a run date not equal to the

specified (explicit or relative) run date.

Target Selects events with the specified target (NETREGID).

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

Field Description

Permanent Specifies whether to select events that are designated as

permanent (always in the schedule), where Y selects only
permanent events, and N selects only events that are not
permanent (or leave blank to select events regardless of
whether they are permanent or not).

Milestone Specifies whether to select events that are designated as

milestones in an event flow, where Y selects only
milestone events, and N selects only events that are not
milestones (or leave blank to select events regardless of
whether they are milestones or not).

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:

Hold All events on hold.

Late All events that are late.

Needs All events waiting for an operator OK.

OperOK

Needs All events waiting for a certain time.

TimeOK

Needs All events waiting for particular WHEN

WhenOK conditions to be satisfied.

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

206
 5 Creating and Monitoring the Schedule

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 Schedule View EDIT

Command ===> Scroll ===> PAGE

Event ===> System=SYSC Selected=000022 2014.036

17:07
Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ?
Line Commands: Del Delete Wh When cond ? to list other Line Commands

Line Event Sched Job Evnt Event Event Status

Cmd No. Date Name Type Name Reason Code
===============================================================================
000011 2013325 ASGJOBA JOB EVENTA Success
000012 2013325 ASGJOBB JOB EVENTB Success
000013 2013325 ASGJOBC JOB EVENTC Success
000014 2013325 ASGJOBD JOB EVENTD Success
000029 2013326 ZCOM ZCOMEVENT Queued Multiple Systems
000152 2013345 ZCOM ZOKEVENT Dispatching Pending
000068 2013346 ASGDEMOB JOB DEMOB Success
000069 2013346 ASGDEMOC JOB DEMOC Success
000070 2013346 ASGDEMOD JOB DEMOD Success
000071 2013346 ASGDEMOE JOB DEMOE Fail S806
000072 2013346 WORK DEMOA Scheduled Time OK
000073 2013346 ASGDEMOF JOB DEMOF Scheduled Time OK
000074 2013346 MSG DEMOG Success

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.

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

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

To update a scheduled event through Schedule View

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

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.

Note:
Schedule View displays columns of fields that events of all types, you can only
update fields that are valid for the particular event type.

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

Desired Result Action

Display a list of all valid line Enter ? in any Line Cmd field, and press Enter.
commands

Change the event’s dispatch Type over the value in the Dp field, and press Enter.
priority

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

208
 5 Creating and Monitoring the Schedule

Desired Result Action

You can update any of these fields to alter other schedule

time information:
• ‘Late start’ time
• Early time
• ‘Must end’ time
• ‘Not after’ time
• Average duration
• ‘Late end’ time

Change the Zeke system or Type over the value in the System field, and press Enter.
pool where the job can run

Change the number of times 1 Type over the value in the Cnt field to indicate the
Zeke dispatches an event 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 “Recurring
and Permanent Events” on page 145 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 Valid for job events only. Specify the name of the class in
for the job the Dsptch Class field, and press Enter.

Change the number of Valid for job events only. Specify the number of tape drives
required tape drives in the No. Tap field, and press Enter. The valid values range
from 0 through 255.

Change the amount of Valid for job events only. Specify the amount of storage in
storage required by the event the Virt Mem field, and press Enter.

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

Desired Result Action

Change the way Zeke Specify the code indicating the type of job processing to use
submits and executes JCL 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.

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

Change the required Type over the environment name in the Scheduling
scheduling environment 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 Type over the value in the Target field, and press Enter.
Zeke downloads the event 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.

210
 5 Creating and Monitoring the Schedule

Desired Result Action

Repeat the last command 1 Enter any valid line command that already has been
entered 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 1 Enter ALT in the Line Cmd field for the event that you
subsequent lines 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.

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

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

Event Status Code Description

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.

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.

212
 5 Creating and Monitoring the Schedule

Reason Code Description

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

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.

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.

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

Reason Code Description

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.

Late End/Must End The ‘late end’ or ‘must end’ time has been reached.

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

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.

No local license The event is a local event, but Zeke is not licensed for local event
processing.

No remote license The event is a remote event, and Zeke is not licensed for remote
event processing (through EA Services).

214
 5 Creating and Monitoring the Schedule

Reason Code Description

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.

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.

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

Reason Code Description

Unobt. Resource Hold The event is on hold because it needs a resource that is unobtainable
for one of these reasons:
• Resource is not defined in the Zeke database.
• Resource is unavailable on the designated system.
• Event requires a larger share count than is defined for the
resource.

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

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

Option ===>

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

Option ===>

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

216
 5 Creating and Monitoring the Schedule

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 Perform the steps in the Action column (depending on the desired result):

Desired Result 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 In the Tabular When Conditions section, enter any

individual WHEN condition 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:

* Zeke satisfied the condition.

+ An operator command was used to manually

satisfy the condition.

# The condition is satisfied because the event is not

in the schedule.

Satisfy or complete all WHEN In the Event Status section, enter any character to the left
conditions 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 221.

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

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

Note:
To change a WHEN condition permanently, you must update the condition in the EMR.

See “WHEN Condition Keywords” on page 136 for the valid keywords.

To manage WHEN conditions through Schedule View

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

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

Option ===>

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 Perform the steps in the Action column (depending on the desired result):

Desired Result Action

Update existing WHEN 1 In the English When Conditions section, tab to the
conditions 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.

218
 5 Creating and Monitoring the Schedule

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 Tab to the blank space in front of the condition in the
condition Tabular When Conditions section, and enter any
character.
These symbols indicate describe the status of the
prerequisite:

* Zeke satisfied the condition.

+ An operator command was used to manually

satisfy the condition.

# The condition is satisfied because the event is not

in the schedule.

Satisfy all WHEN conditions Enter WOK in the Line Cmd field for the selected event
on the Schedule View screen.

4 Press Enter.

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

Note:
If you enter WH for a selected work center event, this screen is displayed:

ASG-Zeke Schedule View

Option ===>

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.

220
 5 Creating and Monitoring the Schedule

Managing Event Resources

From Schedule View, you can display the status of a resource required for an event, and
release a held resource, if necessary.

See “Assigning Resources to an Event” on page 283 for more information on how
resources are defined for an event.

To manage event resources through Schedule View

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

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

OPTION ===>

Event = 000028 Event Name = ZEKEEVTST6 Jobname = TSKKGUT1

Line Commands: Who - Show holder(s) Rel - Release the resource

Count Mode Sta Event Ver Date Scp Resource Name

============<============================================================>
1 SHR 000028 00000 2013053 GBL INIT1
3 SHR ??? 000028 00007 2013053 ??? INIT2
******************************** BOTTOM OF DATA ***************************

The screen provides information on the resources that are assigned to the event. For
example:
• Resource access mode (i.e., whether access to the resource must be exclusive,
can be shared, etc.).
• Scope (i.e.,whether the resource is defined only for one Zeke system or for
multiple systems).
• Resource status. These are the possible statuses:

Status Description

KPT After the resource was acquired, and while the resource was in use, a
failure occurred. The resource is being held.

ACQ Resource has been acquired by an event and is in use.

HLD Resource is being held by an event until all of the required resources
are available.

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

Status Description

??? Resource cannot be obtained because it is undefined in the Zeke

database or is undefined for the designated system ID, or the event
requires more of this resource than the maximum share count defined
for the resource.

If there are no resources defined for the event, this message is displayed:

**** NO RESOURCE DEFINED ****

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

Desired Result Action

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

Display the event currently using To the left of the resource, enter WHO, and press Enter.
the resource

If there are no resources currently being held for the event, this message is
displayed:

**** RESOURCE NOT HELD ****

4 Press F3 to return to the main Schedule View screen.

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 ZOOM screen. The fields on the Schedule
View and ZOOM screens are the same for SQRs of any event type; however, you can
only update fields or enter field values that are valid for that event type.

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 232 for more
information.

222
 5 Creating and Monitoring the Schedule

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

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

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 Schedule View Record Expand Function BROWSE

Command ===>
Platform: MVS
Evt: 000028 Job: TSKKGUT1 JES2 Job Id:

Sched date: 2013053 Run date: 2013053 Version: 00000

STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK

Type: JOB EventName: ZEKEEVTST6 App: Grp: Usrid:

System: ZEQA Class: Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit 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 Press F3 to return to the main Schedule View screen.

To update a scheduled event

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

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

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

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

The Schedule View Record Expand Function screen is displayed:

ASG-Zeke Schedule View Record Expand Function BROWSE

Command ===>
Platform: MVS
Evt: 000028 Job: TSKKGUT1 JES2 Job Id:

Sched date: 2013053 Run date: 2013053 Version: 00000

STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK

Type: JOB EventName: ZEKEEVTST6 App: Grp: Usrid:

System: ZEQA Class: Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> Zeke JCL

Note:
See “Accessing an Expanded SQR (Using ZOOM)” on page 222 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 232.

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.

224
 5 Creating and Monitoring the Schedule

Refreshing the Screen

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

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

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 3,660 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.

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

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.

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 Schedule View Sort Setup Row 1 to 16 of 33

Command ===> Scroll ===> PAGE

Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET

Line Commands: nnn - Move to/after nnn; 0 - Don't use; A/D - direction

nnn Order A/D Field Description

--- --------- --------------------------------------------------------------
10 A Status/Reason Code
20 D Schedule Date
30 A Event Number
----- Sort uses fields above; fields below are not used -----
Application Identification
Average Duration
40 A 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.

226
 5 Creating and Monitoring the Schedule

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.

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.

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

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 Schedule View Display Setup Row 17 of 33

Command ===> Scroll ===> PAGE

Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET

Line Commands: nnn - Move to/after nnn; 0 - Don't show

nnn Order Field Description *Date Format: YYYYDDD

--- ----- ------------------------------------------------------------------
170 Version Number
180 Frequency Calc
190 Trigger Type
200 Long Job Name
210 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 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.

228
 5 Creating and Monitoring the Schedule

c To reorder fields, specify a new value next to the desired fields, and press
Enter.

Order values begin at 10, and increment by 10. This enables you to position
multiple fields in between existing fields, if necessary.

Each time a field is included in or removed from the display sequence, or fields are
reordered, the Order values are recalculated for the entire list.

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

In this example, the Event Number appears in Field 1, the Schedule Date in Field 2,
the Sched Time in Field 3, and the Status/Reason Code in Field 4. The remaining
fields are marked for removal because their nnn value has been set to 0. When you
press Enter, those fields are moved below the separator line to indicate that they are
not displayed:

ASG-Zeke Schedule View Display Setup Row 1 of 33

Command ===> Scroll ===> PAGE

Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET

Line Commands: nnn - Move to/after nnn; 0 - Don't show

nnn Order Field Description *Date Format: YYYYDDD

--- ----- ------------------------------------------------------------------
10 Event Number
20 Schedule Date *
30 Schedule Time
40 Status/Reason Code
0 50 Job Name
0 60 Event Type
0 70 Event Name
0 80 DP (Dispatch Priority)
0 90 Late Dispatch Time
0 100 System Identification
0 110 Run Date *
0 120 Freq (dispatch interval)
0 130 CNT (number of times)
0 140 Status Time
0 150 Early Dispatch Time
0 160 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.

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

Changing the Date Display Format

You can specify the format for selected dates displayed in Schedule View. Entries that
you make on the Date Selection screen affect the fields marked with an asterisk (*) on the
Schedule View Display Setup screen.

To change date display format

1 From the Zeke Primary Menu, enter option C.4. The Date Selection screen is
displayed. The selected format is marked by an asterisk (*) in the Current Format
column:

ASG-Zeke Date Selection

OPTION ===>

Current
OPT Format Format Description

1 * YYYYDDD Use 7 digit Julian date (default)

2 YYDDD Use 5 digit Julian date
3 MM/DD/YYYY Use 10 character Gregorian date
4 MM/DD/YY Use 8 character Gregorian date

2 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 From the Zeke Primary Menu, enter option 2.1. The Schedule View screen is
displayed.

230
 5 Creating and Monitoring the Schedule

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

Desired Result Action

Access EMRs Enter EMR on the Command line, and press Enter. The Event
Master Selection Criteria screen is displayed.
Or
Enter EMR in the Line Cmd field for an event, and press Enter.
The Event Master Definition screen is displayed in Browse
mode.
See “Event Master Records (EMRs)” on page 51 for more
information.

Access online Enter DOC on the Command line, and press Enter. The
documentation 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 166 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 96 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 249 for more information.

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

Desired Result Action

Access Zebb Enter one of these line commands in the Line Cmd field to
access the appropriate Zebb function:

ZEBB Display the Job Functions Menu.

DSN Display the Step/DD Level Information screen.

LDSN Display the List DSN Detail Information screen.

RSTRT Display the Job Restart Management screen.

Note:
This function requires Zebb to be active on this Zeke system.

Display SQR information Enter ZOOM in the Line Cmd field for the selected event, and
on one screen press Enter.
See “Accessing an Expanded SQR (Using ZOOM)” on
page 222 for more information.

Edit or override JCL for a Enter ZOOM in the Line Cmd field for the selected event, and
job event press Enter.
See “Overriding JCL” on page 232 for more information.

3 Press F3 to return to the main Schedule View screen.

Managing JCL
For job events, you can access JCL from Schedule View for one-time overrides, as well
as validate the JCL that you have created or edited.

Overriding JCL
For job events, Schedule View enables you to retrieve the actual JCL from the JCL
source, and insert it in the SQR so that you can view it or make temporary overrides. This
enables authorized users access to a copy of the executable JCL to update parameters and
correct abends. The updated copy of the JCL is attached to the event’s schedule entry for
subsequent runs. If you override the JCL for a recurring event, all subsequent runs for that
schedule day will use the override JCL (unless the override copy is manually deleted).
When the event is completed successfully, the JCL override copy is purged with the event
at the next schedule load.

Note:
If JESQ is the JCL source for the SQR, you cannot override the JCL from Zeke.

232
 5 Creating and Monitoring the Schedule

To modify the JCL for an event

1 Access Schedule View, and locate the event for to which you want to access the JCL
(as described in “Displaying Scheduled Events” on page 203).

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 Schedule View Record Expand Function BROWSE

Command ===>
Platform: MVS
Evt: 000028 Job: TSKKGUT1 JES2 Job Id:

Sched date: 2013053 Run date: 2013053 Version: 00000

STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK

Type: JOB EventName: ZEKEEVTST6 App: Grp: Usrid:

System: ZEQA Class: Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> Override present in SQR Delete after next use (Y/N) N

JCL--> Zeke JCL

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

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

7 The additional JCL field contains the name of the specified JCL source for the job.
Update this field, if necessary. Changes to this field are permanent, and affect the
EMR for this event.
The Zeke JCL Override screen is displayed:

ASG-Zeke JCL Override EDIT Event 00029

COMMAND ===> SCROLL ===> PAGE
****** *************************** Top of Data ****************************
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000001 //ZEKTST29 JOB (26010,200),'JOHN DOE X9999',CLASS=A,MSGCLASS=A,
000002 // USER=PDDOE,PASSWORD=WHILEOUT
000003 //*
000004 //ZEKE EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000005 //STEPLIB DD DISP=SHR,DSN=ZEKE.PDDOE.LINKLIB
000006 // DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000007 // DD DISP=SHR,DSN=OASIS.LINKLIB
000008 //SYSPRINT DD SYSOUT=*
000009 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
000011 //SYSIN DD *
000012 SET WAIT 1
000013 //*
****** ************************** Bottom of Data **************************

8 Make any necessary changes, and press F3 to save the changes and return to the
Schedule View Record Expand Function screen.

Note:
A few editing commands have the same name in ISPF as in Zeke (e.g., CANCEL,
COPY, and EDIT). When these commands are issued from Zeke, they are
processed as Zeke commands (rather than as ISPF commands). To use the ISPF
command when there is a Zeke command by the same name, you must issue it as
part of the ISPF EDIT command BUILTIN (e.g., BUILTIN CANCEL). Otherwise,
it is assumed that you are issuing a Zeke command (and not an ISPF command).
See your ISPF documentation for details about the BUILTIN command.

9 Press F3 again to return to the Schedule View screen.

10 Optional. You can check your JCL for syntax errors without affecting the actual
SQR. See “Validating JCL” on page 237.

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.

234
 5 Creating and Monitoring the Schedule

Zeke’s PDS override option provides an alternative to the standard JCL override function
in Schedule View. This override option copies the JCL that is pointed to by the
DDNAME/member name combination in the SQR to a PDS that is pointed to by the
OVERRIDE DD in the Zeke started task. The SQR is updated to point to that DDNAME
OVERRIDE. You can then edit the JCL through the ZOOM screen in Schedule View.

The OVERPDS command allocates the datasets pointed to by the DDNAME in the Zeke
started task based on the DDNAME found in the current SQR.

For information on how to install and configure the PDS JCL override option, see the
ASG-Zeke Scheduling for z/OS Installation Guide.

To perform a Zeke PDS override for a job

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

2 Enter ZOOM in the Line Cmd field to the left of the job, and press Enter.

ASG-Zeke Schedule View BROWSE

Command ===> Scroll ===> PAGE

Event ===> System=SYSD Selected=0000034 2013.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 2013067 DOWN0001 JOB DOWNLOAD0001 Queued Download Hold
zoom 000021 2013069 ZEK806 JOB ABEND806 Fail S806
000025 2013065 ZEKXDCA JOB JOBTEMPLATE Queued Need Oper OK
000076 2013057 ZEKJCL JOB ZEKEJCLTEST Success
000079 2013065 ZEKJCL2 JOB ZEKEJCLTEST Fail Forced
001014 2013068 KATHYG01 JOB KATHYG01 Fail JCL Error
001098 2013067 TRACK04 JOB TRACK0000004 Active 6900%
001694 2013067 SCOM EOJTRACK75 Success
********************************** BOTTOM OF DATA *************************

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

The Schedule View Record Expand Function screen is displayed:

ASG-Zeke Schedule View Record Expand Function BROWSE

Command ===> OVERPDS
Platform: MVS
Evt: 000021 Job: ZEK806 JES2 Job Id: JOB09781

Sched date: 2013069 Run date: 2013069 Version: 00000

STATUS TIME: 01:06 STATUS/REASON: Fail S806

Type: JOB EventName: ABEND806 App: A2345678 Grp: G23 Usrid: U2345678
System: SYSD Class: A Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> PDS: ZEKEJCL Member: ABEND806

3 On the Command line, enter OVERPDS.

ASG-Zeke Schedule View Record Expand Func Override successful

Command ===>
Platform: MVS
Evt: 000021 Job: ZEK806 JES2 Job Id: JOB09781

Sched date: 20132013069 Run date: 2013069 Version: 00000

STATUS TIME: 01:06 STATUS/REASON: Fail S806

Type: JOB EventName: ABEND806 App: A2345678 Grp: G23 Usrid: U2345678
System: SYSD Class: A Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> PDS: ZEKEJCL Member: ABEND806

After the datasets are allocated, OVERPDS copies the member (indicated in the
SQR) to a dataset pointed to by the OVERRIDE DD in the Zeke started task. A
ZALTER command is issued against the SQR to change the SQR to point to the
OVERRIDE DD.

4 Exit, and then re-access, the zoom screen to see the change in the SQR.

236
 5 Creating and Monitoring the Schedule

5 Optional. Enter E to the left of the JCL-->PDS: OVERRIDE Member field to

edit the override JCL.
ASG-Zeke Schedule View Record Expand Function BROWSE
Command ===>
Platform: MVS
Evt: 000021 Job: ZEK806 JES2 Job Id: JOB09781

Sched date: 2013069 Run date: 2013069 Version: 00000

STATUS TIME: 01:06 STATUS/REASON: Fail S806

Type: JOB EventName: ABEND806 App: A2345678 Grp: G23 Usrid: U2345678
System: SYSD Class: A Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit 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.

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

Note:
The JPREP line command can be used to populate OASIS event-related items
(XQxxxxx). JPREP invokes the ZJCLPREP REXX exec (which requires site-specific
modifications).

After you edit JCL from the ZOOM display, you can validate the JCL while still in EDIT
mode using the FPREP EDIT macro. Both methods for accessing JCLPREP are
described in this section.

See the ASG-Zeke Scheduling for z/OS Installation Guide for information on configuring
JCLPREP for JCL management, and for important setup procedures that must be
performed before you can invoke JCLPREP from Schedule View.

Note:
This feature is not supported for SQRs which have JESQ as the JCL source.

To invoke JCLPREP using Schedule View ZOOM

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

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 Schedule View Record Expand Function BROWSE

Command ===>
Platform: MVS
Evt: 000028 Job: TSKKGUT1 JES2 Job Id:

Sched date: 2013053 Run date: 2013053 Version: 00000

STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK

Type: JOB EventName: ZEKEEVTST6 App: Grp: Usrid:

System: ZEQA Class: Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> Zeke JCL

238
 5 Creating and Monitoring the Schedule

3 To access the JCL, enter E in front of the JCL field, and press Enter. The JCL screen
is displayed:

ASG/Zeke JCL EDIT Event 00054

Command ===> Scroll ===> PAGE
****** **************************** Top of Data ****************************
==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF).
==MSG> Data has valid standard numbers.
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000100 //ZEKTST30 JOB (10038),'J SMITH',
000200 // MSGCLASS=Y,CLASS=A,
000300 // REGION=4M
000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000610 //STEPLIB DD DISP=SHR,DSN=OASIS.LINKLIB.MVS1
000620 //* DD DISP=SHR,DSN=OASIS.LINKLIB.DVLP
000630 // DD DISP=SHR,DSN=OASIS.LINKLIB
000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB
000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB
000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB
000670 // DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000680 // DD DISP=SHR,DSN=ZEKE.LINKLIB
000690 //* DD DISP=SHR,DSN=ZEBB.TEST.LINKLIB
000691 // DD DISP=SHR,DSN=ZEBB.LINKLIB
000700 //SYSPRINT DD SYSOUT=*
000800 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
000900 //SYSIN DD *

4 Enter FPREP on the Command line, and press Enter to invoke the JCLPREP EDIT
macro. JCLPREP is invoked to check the JCL syntax.

After JCLPREP completes the check, the JCLPREP output is displayed.

5 When you finish reviewing the JCLPREP output, press F3 to exit the output screen.

To invoke JCLPREP using the JPREP line command

1 From the Schedule View screen, enter JPREP in the Line Cmd field to the left of
the event, and press Enter. JCLPREP is invoked to check the JCL syntax.

After JCLPREP completes the check, the JCLPREP output is displayed.

2 When you finish reviewing the JCLPREP output, press F3 to exit the output screen.

Invoking JOB/SCAN
From Schedule View, you can invoke the JCL management tool, ASG-JOB/SCAN, in
either of two ways: through the ZOOM feature, or by entering the JSCAN line command.
Both methods for accessing ASG-JOB/SCAN (herein called JOB/SCAN) are described
in this section.

JOB/SCAN can only be used for jobs that have existing JCL.

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

See the ASG-Zeke Scheduling for z/OS Installation Guide for information on configuring
JOB/SCAN for JCL management, and for important setup procedures that must be
performed before you can invoke JOB/SCAN from Schedule View. Also refer to your
JOB/SCAN documentation series for more information.

To invoke JOB/SCAN using the ZOOM feature of Schedule View

Note:
For SQRs with JESQ as the JCL source, the JCL cannot be viewed or edited.

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

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 Schedule View Record Expand Function BROWSE

Command ===>
Platform: MVS
Evt: 000028 Job: TSKKGUT1 JES2 Job Id:

Sched date: 2013053 Run date: 2013053 Version: 00000

STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK

Type: JOB EventName: ZEKEEVTST6 App: Grp: Usrid:

System: ZEQA Class: Target: *LOCAL

Early: Sched: 00:00 LateStrt: Mustend: Notafter:

LateEnd: 00:00

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A

Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> Zeke JCL

240
 5 Creating and Monitoring the Schedule

3 To access the JCL, enter E in front of the JCL field and press Enter. The JCL screen
is displayed:

ASG/Zeke JCL EDIT Event 00054

Command ===> Scroll ===> PAGE
****** **************************** Top of Data ****************************
==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF).
==MSG> Data has valid standard numbers.
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000100 //ZEKTST30 JOB (10038),'J SMITH',
000200 // MSGCLASS=Y,CLASS=A,
000300 // REGION=4M
000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000610 //STEPLIB DD DISP=SHR,DSN=OASIS.LINKLIB.MVS1
000620 //* DD DISP=SHR,DSN=OASIS.LINKLIB.DVLP
000630 // DD DISP=SHR,DSN=OASIS.LINKLIB
000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB
000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB
000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB
000670 // DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000680 // DD DISP=SHR,DSN=ZEKE.LINKLIB
000690 //* DD DISP=SHR,DSN=ZEBB.TEST.LINKLIB
000691 // DD DISP=SHR,DSN=ZEBB.LINKLIB
000700 //SYSPRINT DD SYSOUT=*
000800 //SYSABEND DD SYSOUT=*
000900 //SYSIN DD *

4 Enter JEM on the command line, and press Enter to invoke the JOB/SCAN EDIT
macro. JOB/SCAN is invoked to check the JCL syntax.

After JOB/SCAN completes the check, the JOB/SCAN output is displayed.

5 When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.

To invoke JOB/SCAN using the JSCAN line command

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

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.

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

Using ZSCAN
You can check your JCL for syntax errors through the OS facility. This function is the
same as issuing the Zeke operator command ZSCAN and follows the same guidelines as
the JCL feature TYPRUN=SCAN. Your job card must have a MSGCLASS= value that
will hold the output on the spool. Otherwise, you cannot view the system messages.

Note:
To validate JCL on another system, you must specify the system name. Use the ZSCAN
operator command to do so. See the ASG-Zeke Scheduling for z/OS Reference Guide for
details).

Note:
This feature is not supported for SQRs which have JESQ as the JCL source.

To check your JCL for syntax errors using ZSCAN

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

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

242
 5 Creating and Monitoring the Schedule

Zeke Dispatching
This section describes how Zeke evaluates scheduled events in order to manage event
dispatching, as well as the types of alerts Zeke generates when identifying a delay.

Dispatch Priority
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 ‘late start’ time (Latestart value). Zeke considers,
as applicable, an event’s ‘not after’ time (Notafter value), ‘must end’ time
(Mustend), average duration (Avgdur value), and the value of the Mspintrl
generation option (see page 311). 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 value 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 value 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 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.

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

Note:
An event’s ‘late end’ time (Lateend value) does not affect its dispatching sequence.

See “Job Events” on page 67 for information on schedule times and other event attributes
that affect event dispatching.

See “Dispatching Events and Messages” on page 310 for details on the generation
options that control dispatching.

Late Dispatch Messages

Zeke first issues the late dispatch message Z0302I when the event becomes late based on
its ‘late start’ or ‘late end’ time, whichever comes first. Zeke reissues the message hourly
for all late events in the schedule, as well as for events that are already late whenever
Zeke is cycled (i.e., ZKILL COLD or TRACK).

Zeke does not issue the message after a late event that has violated its ‘late start’ time has
been dispatched (i.e., has reached a pending, active, success, or failed status). Likewise,
Zeke does not issue the message after a late event that has violated its ‘late end’ time has
completed (i.e., has reached a success or failed status).

An OpsCentral alert is issued only the first time Zeke issues the late message and
whenever Zeke is cycled.

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

244
 5 Creating and Monitoring the Schedule

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. Zeke
considers only triggers that can be matched to an SQR in the schedule, and ignores these
types of triggers:
• 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 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).

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

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

ZCOM Function
The ZCOM function provides options that enable you to issue Zeke operator commands
or update the values of Zeke variables.

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.

In addition to using the ZCOM function, you also can issue Zeke operator commands
using any of these methods:
• From the system console or SDSF.
• From any command line in the Zeke ISPF online facility (with the exception of the
ZKILL command). See “Issuing Zeke Commands through ZCOM” on page 247.
• From a command shell. See “Issuing Zeke Commands outside of ZCOM” on
page 247.
• Through an SCOM or ZCOM event. See “Command Events” on page 87.
• Using a ZEKESET command (i.e., SET SCOM or SET ZCOM). See the ASG-Zeke
Scheduling for z/OS Reference Guide.
• Using a Zeke host command (i.e., a REXX ADDRESS ZEKE ZCOM command).
See the ASG-Zeke Scheduling for z/OS Installation Guide.
• Using the ZEKECMD API. See the ASG-Zeke Scheduling for z/OS Installation
Guide.
• From an OpsCentral console. See the ASG-Zeke Plug-in for OpsCentral User’s
Guide.

246
 5 Creating and Monitoring the Schedule

Issuing Zeke Commands through ZCOM

To issue a Zeke operator command through ZCOM

1 From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions
screen is displayed:

ASG-Zeke Schedule Control Function BROWSE

Option ===>

Please enter a valid Zeke operator command

Opt Description Opt Description

1 ZD 13
2 ZD JOB 14
3 ZD MSG 15
4 ZD SCOM 16
5 ZD ZCOM 17
6 ZD WAIT 18
7 ZD DONE 19
8 ZD LATE 20
9 ZD HOLD 21
10 ZD AV 22
11 ZID 23
12 ZMAP 24

Cmd: Add - ZADD Function

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). You can modify or replace those
commands, as well as enter new commands in the open option fields.

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.

Issuing Zeke Commands outside of ZCOM

You can issue Zeke commands outside of ZCOM (with the exception of the ZKILL
command).

To issue a Zeke command outside of ZCOM

 Issue the Zeke operator command from any command line in the Zeke ISPF online
facility.

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

Or

 From a command shell, issue the ZCOM command from any ISPF command line to
open a command shell where you can issue commands up to 200 characters long.
The command shell also enables you to retrieve the last ten commands that were
issued (from the command shell).

ASG-Zeke Command Shell

===>

Place cursor on choice and press enter to retrieve command

=>
=>
=>
=>
=>
=>
=>
=>
=>
=>

Cmd: Add - ZADD Function

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.

248
 5 Creating and Monitoring the Schedule

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.

When you press Enter, the corresponding Zeke Command Output Display screen is
displayed detailing the selected criteria:

ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 17 of 30

Command ===> Scroll ==> PAGE

Please enter a valid Zeke operator command or option number.

Press PF3/PF15 key to return to the schedule control function panel.

--------------------------------------------------------------------------
Z0922I DATE RDATE VER TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS
000006 2013053 2013053 000 JOB TSKKGUT1 50 00:00 1 T
000008 2013053 2013053 000 JOB TSKKGUT3 50 00:00 1 T
000011 2013053 2013053 000 JOB SPTEXD11 50 00:00 1 T
000018 2013053 2013053 000 JOB SPTEXD18 50 00:00 1 T
000019 2013053 2013053 000 JOB SPTEXD19 50 00:00 1 T
000020 2013053 2013053 000 JOB SPTEXD20 50 00:00 1 T
000021 2013053 2013053 000 JOB SPTEXD21 50 00:00 1 T
000022 2013053 2013053 000 JOB SPTEXD22 50 00:00 1 T
000023 2013053 2013053 000 JOB SPTEXD23 50 00:00 1 T
000024 2013053 2013053 000 JOB SPTEXD24 50 00:00 1 T
000025 2013053 2013053 000 JOB SPTEXD25 50 00:00 1 T
000026 2013053 2013053 000 JOB SPTEXD26 50 00:00 1 T
000028 2013053 2013053 000 JOB TSKKGUT1 50 00:00 1 T
000029 2013053 2013053 000 JOB SPTEXD29 50 00:00 1 T
000030 2013053 2013053 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 193 for information on activating PathFinder
through Schedule View.

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

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.

To activate PathFinder using Zeke operator commands

1 From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions
screen is displayed.

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

Desired Result Action

Display predecessors for Issue one of these commands from the Option line:
an event at all levels
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 Issue one of these commands from the Option line:
event at all levels
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

250
 5 Creating and Monitoring the Schedule

Desired Result Action

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.

Display nonZeke jobs in The generation option Trigjob must be set to A so that any job
path 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 Enter LEV followed by a space and the number of levels you
the hierarchy 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!! ***

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

Display Successor Example

This diagram and screen display show all events that are dependent on an event named
MYTEST (i.e., its successors):

MYTEST
(Level 0)

ALHJOB2
(Level 1)

DONETST ZTSRPT9T
(Level 2) (Level 2)

ZTSERAXT
(Level 3)

ZTSBKUP ZTSDONE
(Level 4) (Level 4)

If you issue this command:

ZD SU LEV * JOB MYTEST

then, a screen similar to this one is displayed:

ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 5 of 5

Command ===> Scroll ==> PAGE

Please enter a valid Zeke operator command or option number.

Press PF3/PF15 key to return to the schedule control function panel.

-----------------------------------------------------------------------------
ZD SU LEV * JOB MYTEST
Z09ADI SUCCESSORS FOR THE REQUESTED EVENT:
LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR
0 MYTEST JOB 000008 2013053 0000 T 00:00
-----------------------------------------------------------------------------
>>1 ALHJOB2 JOB 000002 2013045 0000 EOJ MYTEST T 00:00
2 DONETST JOB 000053 2013045 0000 WEOG ALHJOB2 00:00
2 ZTSRPT9T JOB 000067 2013045 0000 WEOG ALHJOB2 00:23
3 ZTSERAXT JOB 000003 2013045 0000 WEOJ ZTSRPT9T 00:03
4 ZTSBKUP JOB 000708 2013045 0000 WEOJ ZTSERAXT 00:20
4 ZTSDONE JOB 000930 2013045 0000 WEOJ ZTSERAXT 00:10
******************************* Bottom of data *******************************

252
 5 Creating and Monitoring the Schedule

Display Predecessor Example

This diagram and screen display show all events on which the event MYTEST is
dependent (i.e., its predecessors):

ZTSVLDTT ZSJOBAT
(Level 5) (Level 5)

ZTSJOBBT ZTSVLDTT
(Level 4) (Level 4)

ZTSVLDTT ZTSJOBDT
(Level 3) (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 REQUESTED EVENT:

LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR
3*ZTSVLDTT JOB 001005 2013038 0000 * 00:00
5*ZTSVLDT3 JOB 001009 2013038 0000 * 00:00
5*ZSJOBAT JOB 001010 2013038 0000 * 00:00
4 ZTSJOBBT JOB 001007 2013038 0000 EOJ ZTSVLDT3 T 00:00
EOJ ZSJOBAT
4*ZTSVLDT2 JOB 001008 2013038 0000 * 00:00
3 ZTSJOBDT JOB 001006 2013038 0000 EOJ ZTSJOBBT T 00:00
EOJ ZTSVLDT2
2 ZTSJOBKT JOB 001004 2013038 0000 EOJ ZTSVLDTT T 00:00
EOJ ZTSJOBDT
>>1 ZEKTST04 JOB 001003 2013038 0000 EOJ ZTSJOBKT T SCHD 00:00
------------------------------------------------------------------------------
0 MYTEST JOB 001002 2013038 0000 EOJ ZEKTST04 T 00:00
******************************* Bottom of data ********************************

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

Display Predecessor and Successor Example

This is an example that shows all of the other events that event ZEKEEVTST3 is
dependent on (i.e., its predecessors), and all of the events that are dependent on event
ZEKEEVTST3 (i.e., its successors.

If you issue this command:

ZD PRE SU LEV * EV 3

then, a screen similar to this one is displayed:

ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 17 of 131

Command ===> Scroll ==> PAGE

Please enter a valid Zeke operator command or option number.

Press PF3/PF15 key to return to the schedule control function panel.

-----------------------------------------------------------------------------
ZD 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 2013053 0000 *
predecessors 2 KATHYG *** NOT IN THE SCHEDULE OR NOT A ZEKE JOB ***
2*ZEKEEVTST1 MSG 000001 2013053 0000 *
2*ZEKEEVTST1 MSG 000034 2013053 0000 *
>>1 ZEKEEVTST2 MSG 000002 2013053 0000 EOJ KATHYG T
EOE ZEKEEVTST1
>>1*ZEKEEVTST1 MSG 000034 2013053 0000 *
-----------------------------------------------------------------------------
0 ZEKEEVTST3 MSG 000003 2013053 0000 EOE ZEKEEVTST2 T
EOE ZEKEEVTST1
-----------------------------------------------------------------------------
>>1 ZEKEEVTST4 MSG 000004 2013053 0000 EOE ZEKEEVTST3 T
successors 2 ZEKEEVTST5 MSG 000005 2013053 0000 EOE ZEKEEVTST4 T
3 SPTEXD11 JOB 000011 2013053 0000 EOE ZEKEEVTST5 T 00:00
2 SPTEXD29 JOB 000029 2013053 0000 EOE ZEKEEVTST5 T 00:00

254
 5 Creating and Monitoring the Schedule

Manually Adding Events to the Schedule

Normally, the SCHEDULE function (a ZEKE batch utility program) automatically
schedules all of the required events. If you occasionally need to add an individual event
or a list 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

When you need to add multiple events, consider any predecessor/successor relationships
before you submit the request. If you are attempting to add multiple events that have
predecessor/successor relationships, you must use a single ZADD command to ensure
that all of the events are added to the schedule before Zeke dispatches any of them. If you
specify related events on separate ZADD commands, a predecessor event could be
completed before a successor has been added to the schedule (resulting in missed
triggers).

Note:
If you manually add a job event to the schedule that has Zeke Agent as its target, then
Zeke dispatches the event, or downloads the event (if the agent is configured in Zeke as a
download agent), 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.

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

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 Schedule Control Function BROWSE

Option ===>

Please enter a valid Zeke operator command

Opt Description Opt Description

1 ZD 13
2 ZD JOB 14
3 ZD MSG 15
4 ZD SCOM 16
5 ZD ZCOM 17
6 ZD WAIT 18
7 ZD DONE 19
8 ZD LATE 20
9 ZD HOLD 21
10 ZD AV 22
11 ZID 23
12 ZMAP 24

Cmd: Add - ZADD Function

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

Desired Result Action

To add an event by event number Issue this command:

ZADD EV event-num

Add multiple events by number Issue this command:

ZADD EV (event-num, event-num, ...)

Note:
When any of the events to be added have
predecessor/successor relationships, be sure to
add them using a single ZADD command.

To add one version of an event by event Issue this command:

number
ZADD EV event-num VER version-num

To add a job event by jobname Issue this command:

ZADD JOB name

To add any event by event name Issue this command:

ZADD ENAME name

256
 5 Creating and Monitoring the Schedule

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 Zeke Command Output Display BROWSE Row 1 to 7 of 7

Command ===> Scroll ==> PAGE

Please enter a valid Zeke operator command or option number.

Press PF3/PF15 key to return to the schedule control function panel.

--------------------------------------------------------------------------
ZADD EV 18
Z0952E EVENT 000018 SCHEDULE RECORD ALREADY EXISTS WITH SAME DATE/VERSN
Z0929I ZEKE COMMAND PROCESSED
Z0922I DATE RDATE VER TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS
000018 2013053 2013053 000 JOB SPTEXD18 50 00:00 1 T
000018 2013055 2013055 000 JOB SPTEXD18 50 00:00 1 T
Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00002 SYSTEM ZEQA
****************************** Bottom of data *****************************

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

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 ADD Event Record Selection Criteria

Command ===> 2014.038
14:48
Options: Auto: N (Y/N) Enable: N (Y/N) Hold: N (Y/N) Rebuild: N (Y/N)
Rerun: N (Y/N) Refresh: N (Y/N) Run: N (Y/N) Addok: N (Y/N)

Schedule Date: 2014038 (YYYYDDD) Run Date: 2014038 (YYYYDDD)

Event ===>

Enter a selection mask in any field(s) to be compared for selection.

Event Types Selection Field Masks

Job: Job Name:
Msg: Event Name:
Pcom: Application:
Work: Group ID:
Vcom: User ID:
Zcom: Drl ID:
Scom: System:
REXX: Calendar:
Properties Occurs:
Permanent: When:
Milestone: Resource:

2 Specify these options 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.

258
 5 Creating and Monitoring the Schedule

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.

Addok Indicates to require an operator approval before the added SQR can be
dispatched.

3 If you are adding only one event, you can specify the event number in the Event field.
259
 ASG-Zeke Scheduling for z/OS User’s Guide

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.

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 wildcard and placeholder characters in your selection criteria (see “Generic
Selection Criteria” on page 53).

5 Press Enter. The Schedule View Event Add List screen is displayed:

ASG-Zeke Schedule View Event Add List

Command ===> 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 2013053 MSG ZEQA
000002 ZEKEEVTST2 2013053 MSG ZEQA
000003 ZEKEEVTST3 2013053 MSG ZEQA
000004 ZEKEEVTST4 2013053 MSG ZEQA
000005 ZEKEEVTST5 2013053 MSG ZEQA
000006 KTEST1 2013053 JOB ZEQA KTEST TSKKGUT1
000007 KTEST2 2013053 JOB ZEQA KTEST TSKKGUT2
000008 KTEST3 2013053 JOB ZEQA KTEST TSKKGUT3
000009 KTEST4 2013053 JOB ZEQA KTEST TSKKGUT4
000010 KTEST5 2013053 JOB ZEQA KTEST TSKKGUT5
000011 ZEKEEVCC 2013053 JOB ZEQA SPTEXD11
000012 ZEKEEVCC 2013053 JOB ZEQA SPTEXD12
000013 2013053 WORK ZEQA
000014 2013053 VCOM ZEQA
000015* today ZCOM ZEQA
000016 2013053 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.

260
 5 Creating and Monitoring the Schedule

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 ADD Event Record By Path Selection Criteria

Command ===>

Criteria:

Event ==>
Version ==> (omit for default)
Occurs Date ==> 2014038 (YYYYDDD)
Level ==> 1
Type ==> B (P=pred, S=succ, B=both)

ZADD options:

Run Date ==> (YYYYDDD)

Auto: N (Y/N) Enable: N (Y/N) Hold: N (Y/N)

Rebuild: N (Y/N) Refresh: N (Y/N) Rerun: N (Y/N)
Run: N (Y/N) AddOk: N (Y/N)

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

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

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.

262
 5 Creating and Monitoring the Schedule

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.

Addok Indicates to require an operator approval before the added SQR can be
dispatched.

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.

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

The Schedule View Event Add List screen is displayed:

ASG-Zeke Schedule View Event Add List

Command ===>

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 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00W JOB00W JOB 000025 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00U JOB00U JOB 000023 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BA JOB00BA JOB 000029 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BH JOB00BH JOB 000036 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BJ JOB00BJ JOB 000038 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BQ JOB00BQ JOB 000045 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00BL JOB00BL JOB 000040 2013094 00000 SYSTEM1 PATHAPP PTH
*1 EVENT00BF JOB00BF JOB 000034 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BI JOB00BI JOB 000037 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BJ JOB00BJ JOB 000038 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00BH JOB00BH JOB 000036 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BJ JOB00BJ JOB 000038 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BK JOB00BK JOB 000039 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00BI JOB00BI JOB 000037 2013094 00000 SYSTEM1 PATHAPP PTH
1 EVENT00BG JOB00BG JOB 000035 2013094 00000 SYSTEM1 PATHAPP PTH

0 EVENT00BE JOB00BE JOB 000033 2013094 00000 SYSTEM1 PATHAPP PTH

*1 EVENT00BC JOB00BC JOB 000031 2013094 00000 SYSTEM1 PATHAPP PTH

2 EVENT00BA JOB00BA JOB 000029 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00Y JOB00Y JOB 000027 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00Z JOB00Z JOB 000028 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BL JOB00BL JOB 000040 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00BB JOB00BB JOB 000030 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00Z JOB00Z JOB 000028 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BA JOB00BA JOB 000029 2013094 00000 SYSTEM1 PATHAPP PTH
*1 EVENT00BD JOB00BD JOB 000032 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00BB JOB00BB JOB 000030 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00Z JOB00Z JOB 000028 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BA JOB00BA JOB 000029 2013094 00000 SYSTEM1 PATHAPP PTH
2 EVENT00BC JOB00BC JOB 000031 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BA JOB00BA JOB 000029 2013094 00000 SYSTEM1 PATHAPP PTH
3 EVENT00BB JOB00BB JOB 000030 2013094 00000 SYSTEM1 PATHAPP PTH

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

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

Initiator Processing 266
Defining Pools 277
Logical Resources 280
Defining or Updating a Logical Resource 281
Assigning Resources to an Event 283
Deleting Resources for an Event 287

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

Physical Resources
These are the key types of physical resources that Zeke can use:

Type Description

Initiators An initiator is a physical resource that is required by every MVS event. To

optimize the use of system resources, you can configure Zeke to submit
events to a system only when an initiator of the correct class is available.

Note:
Zeke does not support initiator selection for JES3.

Systems and pools The actual system where an event is processed is a physical resource.
Systems can be combined into pools that share the same database (which
enables Zeke to select the appropriate system for each event).

Tape drives Tape drives are a physical resource used for job events.
To ensure sufficient tape drives are available before an event executes, you
can specify the number of required tape drives on the job’s EMR. See “Job
Events” on page 67. 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 318.

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

266
 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 (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 class from the EMR
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 the ZEKExx 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.

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

This flowchart illustrates the process that occurs before an event is dispatched to an
initiator, where DispSel is set to N.

Figure 1 • Zeke Initiator Selection Process (DispSel is No)

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:

268
 6 Resources

• If no class list is supplied, Zeke updates the job card with the highest priority class
defined to the initiator and submits the job.
• If there is a class list, Zeke checks the value of the generation option UserCls:
— If UserCls is set to Y, Zeke updates the job card with the EMR class that caused
the initiator to be selected and submits the job.
— If UserCls is set to N, Zeke updates the job card with the highest priority class
defined to the initiator and submits the job.

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

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)

270
 6 Resources

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 274 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 308 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 270.)

To define initiators

1 From the Zeke Primary Menu, enter 4.3 and press Enter. The System
Initiator/Partition Directory is displayed:

ASG-Zeke System Initiator/Partition Directory Row 1 to 7 of 7

Command ===> Scroll ===> PAGE

System ===> System type ===> ("MVS", "VSE" or "VSE/ESA")

Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: B - Browse C - Copy D - Delete E - Edit

System JES/POWER ID System Type Description

_ ******** MVS
_ *GLOBAL MVS GLOBAL JOB CLASS CAP
_ LZ56 MVS
_ PLEX55 MVS
_ QA27 MVS
_ SM27 MVS
_ 55QA MVS
******************************* Bottom of data ****************************

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

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

Desired Result Action

Add a new system and 1 Enter ADD on the Command line.

initiator specifications
2 Enter the name of the new system in the System field; this
is the value of the NAME parameter in the OASISxx
options member.
3 Enter MVS in the System Type field to indicate the
operating system.

Edit initiator information Enter E to the left of the system that you want to update.
for an existing system

3 Press Enter. The System Initiator Specification screen is displayed:

ASG-Zeke System Initiator Specification EDIT

Command ===> Scroll ==> PAGE

Zeke System: ******** System type: MVS

JES System ID: 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

Initid MTWTFSS
_ A NNNNNNN
_ T004 NNNNNNN
_ T03 NNNNNNN
_ T2 NNNNNNN
_ 1 NNNNNNN
_ 2 NNNNNNN
_ B NNNNNNN
_ C NNNNNNN
_ D NNNNNNN
_ E NNNNNNN
_ F NNNNNNN
_ G NNNNNNN

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

Desired Result Action

Add an initiator In the Initid field, enter the ID to be assigned to the initiator. Use
the same name as when it was defined to JES. Press Enter.
To add availability detail for the initiator, enter E to the left of
the initiator.

272
 6 Resources

Desired Result Action

Edit existing initiator Enter E to the left of the initiator that you want to update.
information

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 a system name 1 Enter DELETE on the Command line, and press Enter.
and all initiator
2 Re-enter DELETE on the Command line, and press Enter
specifications
to confirm.
Go to step .

5 Press Enter. The System Initiator Detail screen is displayed:

ASG-Zeke System Initiator Detail EDIT

COMMAND ===>

System Id : EDMVS Initiator Id: A1

Primary commands: BROWSE CANCEL EDIT

Start End Start End Start End Start End

Monday time ranges:
Tuesday time ranges:
Wednesday time ranges:
Thursday time ranges:
Friday time ranges:
Saturday time ranges:
Sunday time ranges:

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

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

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.

274
 6 Resources

To specify job class capacities for a system

1 From the Zeke Primary Menu, enter 4.3 and press Enter. The System
Initiator/Partition Directory is displayed:

ASG-Zeke System Initiator/Partition Directory Row 1 to 7 of 7

Command ===> Scroll ===> PAGE

System ===> System type ===> ("MVS", "VSE" or "VSE/ESA")

Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: B - Browse C - Copy D - Delete E - Edit

System JES/POWER ID System Type 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:

• A particular, named local system.
• All local systems that are not defined explicitly (********).
• All systems in the Zekeplex (*GLOBAL).

The *GLOBAL entry defines the default capacities for all z/OS systems in a
Zekeplex. (You can override capacities for a specific system by specifying them
either in the GENSYS entry for the system or in the ******** GENSYS.). The
*GLOBAL entry cannot be deleted.

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.

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

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 System Initiator Specification EDIT

Command ===> Scroll ==> PAGE

Zeke System: ******** System type: MVS

JES System ID: Description:

Primary command: ADD BROWSE CANCEL CAPACITY COPY EDIT DELETE (All initiators)
Line commands: B - Browse initiator detail E - Edit initiator detail
D - DELETE A LINE R - REPEAT A LINE I - INSERT A LINE

Initid MTWTFSS
_ A NNNNNNN
_ T004 NNNNNNN
_ T03 NNNNNNN
_ T2 NNNNNNN
_ 1 NNNNNNN
_ 2 NNNNNNN
_ B NNNNNNN
_ C NNNNNNN
_ D NNNNNNN
_ E NNNNNNN
_ F NNNNNNN
_ G NNNNNNN

3 At the Command line, enter CAP. The Job Class Capacity screen is displayed:

ASG-Zeke Job Class Capacity EDIT

Command ===>

Zeke System: ******** System type: MVS

JES System ID: Description:

Primary commands: BROWSE CANCEL EDIT

Class Max Class Max Class Max Class Max Class Max Class Max
----- --- ----- --- ----- --- ----- --- ----- --- ----- ---
A NO B 9 C 99 D 999 E NO F 9
G 99 H 999 I NO J 9 K 99 L 999

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

276
 6 Resources

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.

See “Scheduling Environments” on page 153 for instructions on how to specify the
scheduling environment for an event.

Defining Pools
Every job belongs either to a system that shares the Zeke database or to 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. In a pool, any of the
systems can dispatch the event; the event simply is dispatched by the first available
system.

The System field on the EMR specifies the owning system or pool for the job. The system
name corresponds to the NAME parameter in the OASISxx 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.

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

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 System Pool Directory Row 1 to 1 of 1

Command ===> Scroll ===> PAGE

Pool id ===> POOL1

Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: B - Browse C -Copy D - Delete E - Edit

Pool ID Description
**************************************************************************
POOL1 TEST POOL
MAIN PROD1 POOL
***************************** Bottom of data ******************************

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

Desired Result Action

Add a new pool 1 Enter ADD on the Command line.

2 Enter the name of the new system in the Pool ID field.

Note:
Do not use any Zeke operands, parameters, or keywords (or
abbreviations of these) to name your systems or pools. For example,
do not name a system or pool AB (which is short for the parameter
ABEND).

Edit an existing Enter E to the left of the pool that you want to update, and press
pool 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 279.

278
 6 Resources

3 Press Enter. The System Pool Specification screen is displayed:

ASG-Zeke System Pool Specification EDIT

Command ===> Scroll ==> PAGE

Pool ID: POOL1 Desc: TEST POOL

Primary command: ADD BROWSE CANCEL COPY DELETE EDIT

Line commands: D - Delete a line I - Insert a line R - Repeat a line

SYSTEM
TSO45

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

Desired Result Action

Add a system to a In the System field, enter a name for the new system name.
new pool
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 1 Enter I in the unlabeled selection field next to a system name,
existing pool press Enter. A blank line is added.
2 Enter the new system name on the blank line.

Edit an existing Complete the changes to the system that you want to update.
system

Delete a system Enter D to the left of the system name, and press Enter.
from a pool

5 Press Enter to update the pool record.

6 Re-cycle Zeke for the changes to take effect.

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

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

280
 6 Resources

Defining or Updating a Logical Resource

This section describes how to define logical resources to the Zeke database, or modify
resource definitions. 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 Resource Specification Row 1 to 8 of 8

Command ===> Scroll ===> CSR

Resource name ===>

System ===>

Primary Commands: ADD COPY DELETE LOCATE

Line Commands: C - Copy D - Delete
Maximum
Resource name System Shared Active?
AN.ISPF.RESOURCE (GLOBAL) 00001 YES
Z.TEST.LAST.ENTRY (GLOBAL) 00001 YES
EDR2 MEDA 00001 YES
EDR2 TSO61 00001 YES
EDR3 (GLOBAL) 00001 YES
INIT1 (GLOBAL) 00005 YES
TAPE (GLOBAL) 09901 YES
TAPEDRIVE HLPDESK 00001 YES
***************************** Bottom of data ******************************

2 Perform the steps outlined in the Action column (depending on the desired result):

Desired Result Action

Define a resource to the 1 Enter ADD on the Command line.

Zeke database
2 Enter the resource name in the Resource Name field, and
press Enter.

Caution! Do not use spaces in the resource name.

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

Desired Result Action

Locate an existing You can simply scroll through the pages on the Resource
resource in the list Specification screen. Or, to quickly find a particular resource
in the list, enter this command on the Command line, and
press Enter:
LOCATE string
The command locates the first line that begins with the
specified text string and scrolls to the associated resource
name (or the closest matching line).

Note:
You cannot use the LOCATE command to scroll to
subsequent lines that begin with the string; the command
locates only the first line.

Edit an existing resource To update the Maximum Shared or Active fields, type over
the existing information, and press Enter.

Copy an existing resource 1 Enter COPY on the Command line.

to create a new one
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.

Delete a resource from the 1 Enter DELETE on the Command line.

Zeke database
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.
Before deleting a resource, verify whether any Zeke events
will attempt to use the resource to be deleted. You can search
the Zeke database using the Resource filter on the Event
Master Selection Criteria screen to find events that reference
a named resource. See “Accessing an EMR” on page 52.

Caution! Although Zeke does not prevent you from

deleting a resource that is specified for an event,
an event that attempts to acquire a deleted
resource will not be dispatched.

282
 6 Resources

3 The Resource Detail screen is displayed:

ASG-Zeke Resource Detail

Command ===> Scroll ===> PAGE

Resource name: 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 system name defined for
the job is assigned to a pool, keep the default value to ensure proper dispatching.

4 In the Max Share Count field, enter a number that quantifies the resource’s
availability.

5 In the Active field, enter the code that indicates whether the resource is active:

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.

6 When you have finished adding or updating information on the Resource Detail
screen, press Enter to save the changes.

Assigning Resources to 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 according to the
specified quantity.

Caution! You must define the logical resource (see “Defining or Updating a Logical
Resource” on page 281) before you specify the resource for an event. If you
specify a resource for an event before you have defined the resource, the event
will be unable to acquire the resource and be dispatched properly.

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

To assign a resource to an event

1 Access the EMR for the event, or the Event Master Directory as described in
“Accessing an EMR” on page 52.

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 Resource Control EDIT

Command ===> Scroll ===> PAGE

Primary Commands: BROWSE DELETE EDIT

Evt: 000007 Type: JOB Job: TSKKGUT2 Evt Name: KTEST2 System: ZEQA

Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S)

--------------Resource Name----------------- Cnt --Codes-
Md H E A
==========================================================================
INIT1 001 SR N R N

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

284
 6 Resources

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.

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

Code Meaning

SR Allow multiple events to access this event

For example, three jobs execute nightly at around the same time (which causes
performance problems).
You could avoid contention (in this example) by taking these steps:
• Set up a logical resource with a maximum share count of 100.
• Set up each job with a resource mode of SR and a count of 50.

Note:
Zeke allows only two of these jobs to run simultaneously. The third job must
wait for one of the other jobs to complete (so that at least 50 of the resource is
available). In this example, the resource must be defined with a maximum
share count of 100.

8 In the H field, specify whether resources should be held. These are the valid codes:

Code Meaning

Y Hold the resource if it is available and is in the correct mode; however, the
resource can be “stolen” by another event with a higher dispatch priority.
For example, Job A requires four resources prior to dispatch, but other jobs
require only one. If the H field is set to Y, then Job A holds each resource as it
becomes available until it has all four resources. The other jobs must wait until
Job A releases the hold on the resources before they can run.

N Default. Do not hold the available resource.

For example, Job A requires four resources prior to dispatch, but other jobs
require only one. If the H field is set to N, the other jobs continue to obtain one
of the resources, as needed. Job A waits and does not hold any resources until
all four resources are available at the same time.

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

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

N Do not use resource for a restart.

S The event assumes the resource only from itself (if the event abends).

11 Press Enter to save the changes.

Deleting Resources for an Event

You can delete one or more resources for an event.

Note:
Deleting a resource from an event definition does not affect the resource definition in the
Zeke database.

To delete one or more resources for an event

1 Access the EMR or the Event Master Directory, as described in, “Accessing an
EMR” on page 52.

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.

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

The Resource Control screen is displayed:

ASG-Zeke Resource Control EDIT

Command ===> Scroll ===> PAGE

Primary Commands: BROWSE DELETE EDIT

Evt: 000007 Type: JOB Job: TSKKGUT2 Evt Name: KTEST2 System: ZEQA

Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S)

--------------Resource Name----------------- Cnt --Codes-
Md H E A
==========================================================================
INIT1 001 SR N R N
EDTR2 002 SR N R N

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.

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

GENOPTs 290
Accessing the Zeke Generation Options 291
Adding a GENOPT 297
Editing a GENOPT 300
Viewing Pending GENOPT Updates 301
Deleting a GENOPT 303
Reloading GENOPTS 305
Audit Options 306
Dispatching Options 308
Exit Options 319
General Options 319
JCL Options 322
Message Options 330
Scheduling Options 331
Security Options 335
Trace Options 336
User Interface Options 336
Variables Options 337
Defining Schedule Download Agents 338
Database Maintenance 340
Generating Database and System Table Status Reports 340
Creating the Zeke Databases (Primary and Vault) 343
Backing Up the Zeke Database 345
Restoring the Zeke Database 346
Moving the Vault Database 349
Recovery Using Electronic Vaulting 350

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

Topic Page

Continuous Job Tracking 352

Terminating Zeke using ZKILL TRACK 353
SMF Recording Mode 353
Applying Maintenance 356
SMF Playback 356

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:

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.

290
 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 305), 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 305), 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.

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

The GENOPTs Directory screen displays a listing of all GENOPTs in the Zeke
database:

ASG-Zeke GENOPTs Directory Row 1 to 4 of 4

Command ===> 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/2013 13:21:28
*GLOBAL Zekeplex global options ZEKEUSER 12/05/2012 19:14:48
ZEKE60A * Zeke 6.0 component on SYSA ZEK60JOB 11/29/2012 15:53:54
******** Default local system options *DBCNVT* 11/10/2012 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.

292
 7 Customizing and Maintaining Zeke

Viewing GENOPT Details

A detailed view of each GENOPT displays the current setting of each generation option
field. The fields are listed alphabetically by default. The CATEGORY primary command
enables you to sort and view the display by functional categories.

If you sort the display by category, these are the predefined categories under which the
generation option fields are organized:

Category Description

Audit Audit options.

Dispatching Options that affect event dispatching.

Exits Options that affect Zeke and operating system exits.

General All options that do not fall under another category.

JCL Options related to JCL sources and processing.

Messages Options that control the issuing of messages.

Scheduling Options that affect event scheduling.

Security Options that control security.

Traces 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 “Adding a GENOPT” on page 297.

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.

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

The Generation Options screen displays (in browse mode) the options and settings
for the selected GENOPT. This is an example of the default (alphabetical) detail
view:

ASG-Zeke Generation Options BROWSE Row 1 to 17 of 141

Command ===> Scroll ===> CSR

Zeke System: ******** Description: (active)

Option Value Description

--------- ---------- ---------------------------------------------------------
Aur: Y (Y,N) Yes to enable automatic responses
AurIntv: 1 (1-99) Number of seconds to check auto responses
AurMsg: Y (Y,N) Yes to inform operator auto. response issues
BimAppl: (xxxxxxxx) Bimedit application name
BimPasw: (xxxxxx) Bimedit access password
BimUid: OMIT (xxxx) Bimedit access userid
CalcMem: Y (Y,N) Yes to calculate virtual memory
CalcTap: Y (Y,N) Yes to calculate tape drive usage
ChgVal: Y (Y,N) Yes to display Variable update message
CmdCons: Y (Y,N) Yes to route command response to console
CondrDv: SYS000 (xxxxxx) Condor camlib device name
CondrLb: OMIT (xxxx) Condor camlib qualifier
CondrVer: 001 (xxx) Condor version id
DispDly: 30 (nnnnn) Seconds to delay dispatching pooled events
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

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.

294
 7 Customizing and Maintaining Zeke

This is an example of the detail view by category for the same GENOPT:

ASG-Zeke Generation Options BROWSE Row 1 to 17 of 152

Command ===> Scroll ===> CSR

Zeke System: JCRZEKEA Description:

Option Value Description

--------- ---------- ---------------------------------------------------------
==================== Audit ===================================================
==================== Dispatching =============================================
Aur: Y (Y,N) Yes to enable automatic responses
AurIntv: 1 (1-99) Number of seconds to check auto responses
CalcMem: Y (Y,N) Yes to calculate virtual memory
CalcTap: Y (Y,N) Yes to calculate tape drive usage
DispDly: 30 (nnnnn) Seconds to delay dispatching pooled events
DispSel: Y (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

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

Command Description

LOCATE Locates the first line that begins with the specified text string and
scrolls to the associated field. This is the command format:
LOCATE string
When fields are displayed alphabetically, this command scrolls to the
first field that contains the string. When the fields are sorted by
category, this command scrolls to the first category name that contains
the string.
For example, this command scrolls to the JclBrows option field if the
fields are listed alphabetically:
LOCATE JCL
The same command scrolls to the JCL category if the fields are sorted
by category.

Note:
You cannot use the LOCATE command to scroll to subsequent lines
that begin with the string; the command locates only the first line.

RFIND Finds and highlights the next occurrence of the text string specified on
the last FIND string command. This is the command format:
RFIND

For example, this is the result when you issue the command FIND DISP:

ASG-Zeke Generation Options EDIT Found 'DISP'

Command ===> Scroll ===> CSR

Zeke System: KACZ610A Description: Adding a GENOPT Proc Test

Option Value Description

--------- ---------- ---------------------------------------------------------
Aur: Y (Y,N) Yes to enable automatic responses
AurIntv: 1 (1-99) Number of seconds to check auto responses
AurMsg: Y (Y,N) Yes to inform operator auto. response issues
BimAppl: (xxxxxxxx) Bimedit application name
BimPasw: (xxxxxx) Bimedit access password
BimUid: OMIT (xxxx) Bimedit access userid
CalcMem: Y (Y,N) Yes to calculate virtual memory
CalcTap: N (Y,N) Yes to calculate tape drive usage
ChgVal: Y (Y,N) Yes to display Variable update message

296
 7 Customizing and Maintaining Zeke

This is the result when you issue the command FIND DISP when the screen is in
category mode (i.e., CAT ON):

ASG-Zeke Generation Options EDIT Row 2 to 18 of 152

Command ===> Scroll ===> CSR

Zeke System: KACZ610A Description: Adding a GENOPT Proc Test

Option Value Description

--------- ---------- ---------------------------------------------------------
==================== Dispatching =============================================
Aur: Y (Y,N) Yes to enable automatic responses

This is the result when you issue the command LOCATE DISP:

ASG-Zeke Generation Options EDIT Row 14 to 30 of 141

Command ===> Scroll ===> CSR

Zeke System: KACZ610A Description: Adding a GENOPT Proc Test

Option Value Description

--------- ---------- ---------------------------------------------------------
DispDly: 30 (nnnnn) Seconds to delay dispatching pooled events

5 In the Zeke ISPF online facility, you can press F1 for field-level help for a particular
option. See the ASG-Zeke for z/OS Reference Guide for an alphabetical reference of
all Zeke generation option fields.

6 Enter END on the Command line, and press Enter to return to the GENOPTs
Directory.

Adding a GENOPT
You can add a new GENOPT based on the default local GENOPT (********) or from
a copy of another existing GENOPT.

Note:
You cannot add a new GENOPT based on the *GLOBAL or *ACTIVE GENOPTs.

To add a GENOPT based on the default local GENOPT

1 Follow the procedure in “Adding a GENOPT” on page 297.

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

Or

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

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

3 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 Generation Options ADD Initial values loaded

Command ===> Scroll ===> CSR

Zeke System: Description:

Option Value Description

--------- ---------- ---------------------------------------------------------
Aur: Y (Y,N) Yes to enable automatic responses
AurIntv: 1 (1-99) Number of seconds to check auto responses
AurMsg: Y (Y,N) Yes to inform operator auto. response issues
BimAppl: (xxxxxxxx) Bimedit application name
BimPasw: (xxxxxx) Bimedit access password
BimUid: OMIT (xxxx) Bimedit access userid
CalcMem: Y (Y,N) Yes to calculate virtual memory
CalcTap: Y (Y,N) Yes to calculate tape drive usage
ChgVal: Y (Y,N) Yes to display Variable update message
CmdCons: Y (Y,N) Yes to route command response to console
CondrDv: SYS000 (xxxxxx) Condor camlib device name
CondrLb: OMIT (xxxx) Condor camlib qualifier
CondrVer: 001 (xxx) Condor version id
DispDly: 30 (nnnnn) Seconds to delay dispatching pooled events
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

4 If you did not already do this from the directory (in step 2 on page 297), 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 294, or to
quickly locate an option or category, see step on page 295.

298
 7 Customizing and Maintaining Zeke

7 On the Command line, type SAVE to save the new GENOPT and remain on the
screen in edit mode, or type END to save the GENOPT and return to the GENOPTs
Directory.

Note:
You can type CANCEL to cancel adding the new GENOPT, if necessary.

Press Enter. The new GENOPT is added to the Zeke database.

To copy an existing GENOPT

1 Follow the procedure in “Editing a GENOPT” on page 300.

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 294, or to quickly locate an option or category, see step
on page 295.

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

6 On the Command line, type SAVE to save the new GENOPT and remain on the
screen in edit mode, or type END to save the GENOPT and return to the GENOPTs
Directory.

Note:
You can type CANCEL to cancel adding the new GENOPT, if necessary.

Press Enter. The new GENOPT is added to the Zeke database.

Editing a GENOPT
You can edit all existing GENOPTs except *ACTIVE (which is generated automatically
by Zeke).

To edit a GENOPT

1 Follow the procedure in “Editing a GENOPT” on page 300.

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 294, or to quickly locate an option or category, see step
on page 295.

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.

300
 7 Customizing and Maintaining Zeke

Note:
You can enter CANCEL to cancel the changes the GENOPT, if necessary.

Press Enter. The GENOPT is updated in the Zeke database.

If you updated the currently active GENOPT, a pop-up panel displays the options
that were changed, the new values, and the action required to activate each updated
option:

ASG-Zeke Generation Options EDIT

+---------------- ASG-Zeke Generation Options ----------------+
| Pending GENOPT Changes Row 1 to 6 of 6 |
| Command ===> ______________________________________________ |
| |
| You have made changes to the active GENOPT, ********. |
| |
| No options require Zeke to be recycled COLD. |
| 4 options require Zeke to be recycled TRACK. |
| 2 options can be activated with ZRELOAD GENOPT. |
| _ Issue the ZRELOAD command |
| |
| Option Action New value |
| ---------- ------- -------------------------------------- |
| Aur TRACK N |
| BatSec ZRELOAD N |
| PbTrack TRACK Y |
| Posid TRACK Y |
+-------------------------------------------------------------+
Condrdv: SYS000 (xxxxxx) Condor camlib device name
Condrlb: OMIT (xxxx) Condor camlib qualifier
Condrver: 001 (xxx) Condor version id
Datasub: Y (Y or N) Yes for Zeke to substitute DOS JCL

6 Optional. To issue the ZRELOAD GENOPT command at this point, enter any
nonblank character in the Issue the ZRELOAD command field or enter the
ZRELOAD GENOPT command on the Command line. This command requires the
appropriate user authorization.

Viewing Pending GENOPT Updates

When you update and save the currently active GENOPT, a pop-up panel displays the
options that were changed, the new values, and the action required to activate each
updated option.

You also can quickly view any changes that are pending (i.e., that have not been made
active yet by an options reload or a Zeke re-cycle) for the currently active GENOPT.

To view pending updates to the active GENOPT

1 Follow the procedure in “Viewing Pending GENOPT Updates” on page 301.

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

2 Enter PENDING on the Command line, and press Enter.

ASG-Zeke Generation Options EDIT Row 1 to 17 of 141

+________________ ASG-Zeke Generation Options ________________+ ll ===> CSR
| Pending GENOPT Changes Row 1 to 1 of 1 |
| Command ===> Scroll ===> CSR |
| |
| Changes are pending to the current GENOPT, JCR600B. |
| |
| No options require Zeke to be recycled COLD. |
| No options require Zeke to be recycled TRACK. |
| 1 options can be activated with ZRELOAD GENOPT. |
| Issue the ZRELOAD command |
| |
| Option Action New value Gbl |
| -------- ------- ----------------------------------- --- |
| DSPBatch ZRELOAD N - |
| ********************* Bottom of data ********************** |
| |
| |
| |
| |
+_____________________________________________________________+
DispSel: Y (Y,N) Yes for Zeke to select initiators
(Yes is ignored for JES3)
DSPBatch: N (Y,N) Yes to use a dataspace for ZEKE batch program

The Pending GENOPT Changes pop-up displays these details:

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

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

302
 7 Customizing and Maintaining Zeke

Deleting a GENOPT
You can delete any GENOPT except the special ones (i.e., ********, *GLOBAL, and
*ACTIVE).

To delete a GENOPT

1 Follow the procedure in “Editing a GENOPT” on page 300. The Generation Options
screen displays the options and settings for the selected GENOPT. Skip to step 3b.

Or

Follow the procedure “Editing a GENOPT” on page 300.

2 Enter D in the selection field to the left of the GENOPT that you want to delete.

Or

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.

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

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

Setting the Delete Confirmation Option

For added control, you can set an option that specifies whether to display a confirmation
pop-up when a user attempts to delete a GENOPT.

To implement or cancel delete confirmations

1 Follow the procedure “Deleting a GENOPT” on page 303.

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: |
| TCOM610Z |
| |
| Set delete confirmation off for GENOPT tables. |
| |
| Press ENTER to confirm delete. |
| Press CANCEL or EXIT to cancel delete. |
| |
+_____________________________________________________________+
VJCRVTAM *DBCNVT* 01/17/2013 14:38:04
******** *DBCNVT* 01/17/2013 14:38:04
******************************* Bottom of data ********************************

See “Deleting a GENOPT” on page 303 for details on deleting a GENOPT.

304
 7 Customizing and Maintaining Zeke

Reloading GENOPTS
Zeke activates some generation options immediately when you save them, but most
options must be reloaded for each system that is affected by the changes.

Zeke reloads the generation options automatically during each startup. Or, you can reload
the generation options at any time by issuing this command:

ZRELOAD GENOPT [FORCE]

Note:
See the chapter on operator commands in the ASG-Zeke Scheduling for z/OS Reference
Guide for more information on the ZRELOAD command.

For most generation options, the changes take effect immediately; however, some options
do require a Zeke re-cycle (i.e., at least a ZKILL TRACK re-cycle and, in some cases, a
ZKILL COLD re-cycle. A ZKILL WARM re-cycle does not reload the generation
options). The required action for each option is noted in the field-level online help and in
the chapter on generation options in the ASG-Zeke Scheduling for z/OS Reference Guide.

After updating the currently active GENOPT, you have the option to reload the options.
When you save the GENOPT changes, this information is provided:
• Name of the GENOPT.
• Number of updated settings that require Zeke to be re-cycled COLD.
• Number of updated settings that require Zeke to be re-cycled TRACK.
• Number of updated settings that you can activate by issuing a ZRELOAD GENOPT
command.
• Name and new value of each updated option, and the required action to activate the
new setting.

As an option, you can reload the generation options at this point. This action requires the
appropriate user authorization.

You also can review any changes that have been made to the currently active GENOPT,
but have not been activated yet, without actually reloading the changes. See “Viewing
Pending GENOPT Updates” on page 301 for details.

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

Audit Options
Zeke uses the OASIS Audit service to track updates to the Zeke database. Audit
information is recorded by the OASIS data space log facility for online browsing, and the
data can be archived to permanent storage.

You decide which types of Zeke activities that you want to audit. These are some of the
actions you can track in audit records:
• Issued console commands (i.e., Zeke operator, server, or address space commands),
including objects modified by the command.
• Event scheduling and dispatching activities, event flow, and status changes:
— A event added to (or deleted from) the schedule.
— Event flow and status changes (e.g. scheduled, time-satisfied, active, EOJ, etc.)
— SQR field updates
— Satisfied triggers
— SMF calls
• Activated/deactivated EMRs and updated EMRs. Field-level audit is available for
these audited EMR segments:
— Base definitions
— Logical resources
— Condition codes
— OCCURS clauses
— WHEN conditions
— Auto replies
— JCL
— Documentation
• Requested, acquired, and released logical resources.
• Updates to these types of database records:
— Calendars (including calendar documentation)
— GENOPT records (including changes to generation option values)
— Field-level updates to database records (e.g., base EMR definitions, GENOPT
records, and calendars)
— Resource definitions
— Initiator/partition (GENSYS) records

306
 7 Customizing and Maintaining Zeke

— Pool records
— Internal security class and operator records, and external security classes
— Customer information
— Download agent definitions
• Zeke variables updates, and variable values set through a work center.
• Users that log on and off through any Zeke online facility or from OpsCentral.

Audit options are global generation options that enable the OASIS AUDIT utility to log
various types of Zeke system activities and database updates. You enable the audit option
for each type of information that you want to track.

As database activities are audited, when an audited element is updated, the change is
logged automatically in an audit record. You can use the audit records to generate
after-the-fact reports to review the logged activities. You also can view the information in
real time through the OASIS ISPF online facility.

See the ASG-OASIS for z/OS Reference Guide for information on setting up and using the
AUDIT utility, audit reporting, and using the data space log facility.

See the ASG-OASIS for z/OS Installation Guide for information on enabling the Audit
and data space log facilities, setting the number of audit logs, and allocating the audit log
datasets.

To access the audit options

1 Follow the procedure in “Editing a GENOPT” on page 300 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 305 for
details.

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

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 300 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 simply specify Y to enable the corresponding function or N
to disable it.

For other options, you must specify a numeric or character value (e.g., a time,
interval, class, disposition, or code), or you can keep the default value.

4 You can reload most dispatching options using the ZRELOAD GENOPT operator
command. See “Reloading GENOPTS” on page 305 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.

308
 7 Customizing and Maintaining Zeke

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.

See “Scheduling Environments” on page 153 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 326 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:

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

Option Description

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 were set to N (e.g., if you use Workload
Manager to manage 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 submittal. These are
the valid values:

N Do not use the EMR class; select initiators using the Zeke class selection
process.

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

310
 7 Customizing and Maintaining Zeke

Option Description

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
‘late start’ or ‘late end’ 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 Default. Dispatch events without an operator OK

Y Wait for an operator OK; a message is issued when an event is placed in

the dispatch queue

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

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

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.

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

312
 7 Customizing and Maintaining Zeke

Option Description

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

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

RetDone Indicates whether to retain completed events in the schedule.

Note:
If using EOG, you must retain completed events.

These are the valid values:

N Discard completed events after EOJ.

Y Default. Retain completed events.

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

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

Option Description

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

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) Does not allow dataset close triggering.

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

Y Install the SMF IEFU83 exits to use the DSN dependency

N Default. Do not install the SMF IEFU83 exits

RemTrig 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, Zeke ignores this option and
applies the TrigDt option to the dates to process the trigger.
If the remote trigger was satisfied by a Zeke-controlled job, then Zeke sends the
SQR’s schedule and run dates with the trigger.
If the remote trigger was satisfied by a non Zeke job on a Zeke system, then Zeke
sends the system’s current date as the schedule date and run date with the trigger.
These are the valid values:

ND Trigger the newest date only.

314
 7 Customizing and Maintaining Zeke

Option Description

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.

TrigDt Specifies whether a Zeke-controlled job can trigger another event’s WHEN con-
ditions 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.

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

Option Description

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.

TrigRrn Specifies whether a job can trigger another event’s WHEN conditions if the job
has a rerun designation. These are the valid values:

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.

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

316
 7 Customizing and Maintaining Zeke

Option Description

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.

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

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

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.

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

Note:
If DispSel is set to N, then Calctap is ignored if it is set to Y.

318
 7 Customizing and Maintaining Zeke

To deactivate automatic calculation of tape drive usage, specify N to deactivate tracking

and recording the number of tape drives used by a job.

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 300 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 simply specify Y to enable the corresponding function or N
to disable it.

For other options, you must 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 305 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 300 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:

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

For many options, you simply specify Y to enable the corresponding function or N
to disable it.

For other options, you must 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 305 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.

320
 7 Customizing and Maintaining Zeke

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.

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 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 . 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 is named IX and is owned by the OASIS address space (which
enables it to be maintained across a ZKILL WARM).

N Do not build a full EDB index.

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

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

Option Description

N Do not build a reduced version of the EDB index in core.

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

322
 7 Customizing and Maintaining Zeke

3 Update each JCL option according to your requirements:

For many options, you simply specify Y to enable the corresponding function or N
to disable it.

For other options, you must 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 305 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.

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

Library Generation Options

LibrBlk Librarian library block size. Zeke uses this number to determine
the amount of storage required for Librarian subroutines. The
default value is 12800.

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

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

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

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

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.

324
 7 Customizing and Maintaining Zeke

Library Generation Options

PanMem Amount of memory Zeke requires to obtain the Panvalet work

area. The default value is 0240.

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.

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

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.

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:

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.

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

326
 7 Customizing and Maintaining Zeke

Option Description

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

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.

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

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

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.

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.

328
 7 Customizing and Maintaining Zeke

Option Description

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 POSID is placed at the end of the job (as the last step).

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 through OASIS/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. These comment statements enable Zeke event information to be
referenced in JES job logs.
This option is required to enable Zeke’s ThruPut Manager interface (see Appendix
B, “Interface to ThruPut Manager,” on page 457 for details).

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

Option Description

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

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 305 for details.

330
 7 Customizing and Maintaining Zeke

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 300 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 Scheduling options can be reloaded using the ZRELOAD GENOPT operator

command. See “Reloading GENOPTS” on page 305 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 to drop completed events from the current schedule when
selection parameters are included with the SCHEDULE ACTIVATE command
for a new schedule run.

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

Option Description

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

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

MultGr Specifies how to handle a ZADD by group ID when multiple events have the
same group ID. These are the valid values:

A Add all the matching events.

F Default. Add the first matching event and end the search; this is the most
efficient.

N Do not add any events; list all matching events on the console.

332
 7 Customizing and Maintaining Zeke

Option Description

MultHit Indicates whether an event is to be scheduled multiple times when there is a non-
working day. This option determines the default value for the Multhit field on
the EMR. These are the valid values:

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.

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

A Add all the matching events.

F Default. Add the first matching event and end the search; this is the most
efficient.

N Do not add any events; list all matching events on the console.

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

A Add all the matching events.

F Default. Add the first matching event and end the search; this is the most
efficient

N Do not add any events; list all matching events on the console

MultUs Specifies how to handle a ZADD by user ID when multiple events have the
same user ID. These are the valid values:

A add all the matching events.

F Default. Add the first matching event and end the search; this is the most
efficient.

N Do not add any events; list all matching events on the console.

Note:
The options MultAp, MultGr, MultJn, MultEn, and MultUs work together to determine which
jobs are added with the ZADD command. If multiple criteria are used on the same ZADD
command, then the option with the most restricted value is applied. For example, if a ZADD by
jobname and application ID is requested and MultJn is set to A (all) and MultAp is set to N
(i.e., none), then no events are added since the most restricted is none.

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

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

334
 7 Customizing and Maintaining Zeke

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

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

4 Security options can be reloaded using the ZRELOAD GENOPT operator

command. See “Reloading GENOPTS” on page 305 for details.

Before setting the security options, be sure to review Chapter 9, “Security,” on page 381.

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 300 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 305 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 300 to access the local or
*GLOBAL GENOPT, then locate the user interface options.

336
 7 Customizing and Maintaining Zeke

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 simply specify Y to enable the corresponding function or N
to disable it.

For other options, you must 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 305 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 300 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 305 for details.

Before setting the variables options, see Chapter 8, “Variables,” on page 357.

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

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 Schedule Download Agents List Row 1 of 3

Command ===> Scroll ===> PAGE

NETREGID ===>

Primary Commands: ADD DELETE EDIT END

Line Commands: D - Delete E - Edit

NETREGID Description
******************************************************************************
UNIXAGNT ZEKE AGENT UNIX
******************************* Bottom of data *******************************

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

Desired Result Action

Add a new agent 1 Enter ADD on the Command line.

2 Enter the Netregid on the NETREGID line.
3 Press Enter. The Schedule Download Agent Specification
screen is displayed.
Go to step 4.

Update an existing agent 1 Enter EDIT on the command line.

for which you know the
2 Enter the Netregid on the NETREGID line.
Netregid
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.

338
 7 Customizing and Maintaining Zeke

Desired Result Action

Delete an agent for which 1 Enter DELETE on the Command line.

you know the Netregid
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.

Delete an agent for which 1 Enter D next to the appropriate Netregid and press Enter.
you do not know the The Schedule Download Agent Specification screen is
Netregid displayed.
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 Schedule Download Agent Specification

Command ===>

Primary commands: CANCEL END

NETREGID: NTAGENT Description:

4 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 Schedule Download Agents List Agent added

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

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

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.

Generating Database and System Table Status Reports

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

A database status report displays the amount on used and available space in the Zeke
database) to help you determine the number of events that can be added to the Zeke
database based on the number of available directory records.

A system tables status report displays the number of SQRs and WHEN conditions, and
the amount of storage required to load the schedule in memory).

To generate a database or system status report

1 From the Zeke Primary Menu, enter 4.4 on the Option line. The Status Report
Selection Criteria screen is displayed:

ASG-Zeke Status Report Selection Criteria

Option ===>

1 Database - Display database status report

2 Tables - Display tables status report

2 For a database status report, enter 1 on the Option line, and press Enter.

340
 7 Customizing and Maintaining Zeke

Or

For a system tables status report, enter 2 on the Option line, and press Enter.

This is an example of the Database Status Report:

ASG-Zeke Database Status Report

Command ==>

Database created: 08/18/2000 ------ Event Records -----

Last restore: 03/13/2013 Active: 145 Deac: 0
Last backup: 12/06/2013 11:32:28 Used: 145 Unused: 1,039
Release level: 6.00 Capacity: 1,184
Zeke pgm runs: 9 Percent in use: 12%

Database blocks: 1,575 ---- Variable Records ----

Blocks in use: 331 Total Var in use: 72
Blocks free: 1,244
% Blocks used: 21%

---- Event Totals by Type ----

Job: 117 Scom: 3
Msgs: 14 Work: 3
Pcom: 0 Vcom: 0
ZCOM: 4 REXX: 4

The Database Status Report provides this information:

• Dates the database was created and last restored, and the date and time the database
was last backed up.
• Zeke release level and total number of Zeke program executions.
• Total number of database blocks (i.e., allocated database size).
• Number of blocks being used by Zeke records.
• Number of free blocks.
• Percentage of blocks used (i.e., number of used blocks divided by the number of
total available blocks).
• Statistics based on the existing number of events in the database:
— Number of active and inactive EMRs
— Number (and percentage) of EMRs in use, and number of unused EMRs
— Total capacity for EMRs based on the database size
— Total number of events (grouped by type) owned by this system
• Statistics based on the existing number of variables in the database:
— Number of variables records in use (i.e., defined in the database).
— Number of variable directory blocks these records use.

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

This is an example of the System Table Status Report:

ASG-Zeke System Table Status Report

Command ==>

+--------------------+--------------------+--------------------+
| Number of | Number of | |
| Schedule Records | When conditions | |
| in the database | for the SQRs | |
+--------------------+--------------------+ Non work center |
| 9 | 5 | <== Events |
+--------------------+--------------------+ Work center |
| 0 | N/A | <== Events |
+--------------------+--------------------+--------------------+
| Storage needed | Storage needed | |
| for loading | for the | Total |
| SQRs to memory | When conditions | |
+--------------------+--------------------+--------------------+
| 10,288 bytes | 7,868 bytes | 18,156 bytes |
+--------------------+--------------------+--------------------+

The System Table Status Report provides this information:

• Number of schedule records in the database. The first line displays the number of
non-work center events in the schedule. The second line displays the number of
work center events in the schedule.
• Storage (in bytes) required to load the SQRs to memory

Note:
Work center events are counted in this number only if the LoadComm generation
option is set to Y.

• Number of WHEN conditions for the SQRs

• Number of event segments that trigger other events.

Note:
The reported value does not include work centers, which do not use WHEN
conditions.

• Number of bytes required to load the WHEN condition records.

• Total required amount of storage.

Note:
The Systbl generation option specifies a maximum value; however, only the
required storage is loaded. This amount can be larger without impacting your
system.

342
 7 Customizing and Maintaining Zeke

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.

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

This job allocates and catalogs the dataset:

//ZFRMT JOB ,MSGLEVEL=(1,1),CLASS=A

//ZALLOC EXEC PGM=IEFBR14
//ZNEW DD DSN=ZEKE.DATABASE,DISP=(NEW,CATLG),
// UNIT=SYSDA,VOL=SER=PERMVL,SPACE=(CYL,(10),,CONTIG)
//*
//ZUTL EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’
//ZEKENEW DD DSN=ZEKE.DATABASE,DISP=OLD
//ZEKECAT DD DSN=ZEKE.DATABASE,DISP=OLD
//SYSIN DD *
CREATE
/*

3 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 EXEC PGM=IEFBR14

//ZNEW DD DSN=ZEKE.PRIMARY.DATABASE,DISP=(NEW,CATLG),
// UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG)
//ZVAULT DD DSN=ZEKE.VAULT.DATABASE,DISP=(NEW,CATLG),
// UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG)
//ZUTLP EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’
//ZEKENEW DD DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
//ZEKECAT DD DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
//SYSIN DD *
CREATE
/*
//ZUTLV EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’
//ZEKENEW DD DSN=ZEKE.VAULT.DATABASE,DISP=SHR
//ZEKECAT DD DSN=ZEKE.VAULT.DATABASE,DISP=SHR
//SYSIN DD *
CREATE
/*

4 Start Zeke with the ZEKECAT DD pointing to the primary database and the
ZEKEVLT DD pointing to the vault dataset.

344
 7 Customizing and Maintaining Zeke

Note:
Regardless of the value for the ESIActv generation option, an external security call
always is made to the SAF Security Interface using the resource class of Z$CATAL with
a resource name of CREATE## and ALTER authority. If this class information is not
defined in your security product, then the SAF action and return code are determined by
your security product. If you do not have a security product using SAF, then Zeke’s
internal security (which allows the request by default) is used.

If you have a ZEKE15B user exit in place, then the exit can override any external security
return code (depending on how you have coded ZEKE15B).

Backing Up the Zeke Database

You back up the Zeke database to a tape or disk file using the BACKUP function of the
ZEKE utility program.

The BACKUP command copies the contents of the Zeke database in case it must be
restored later. Use the BACKUP command to back up your database at least once daily.
ASG recommends backing up the database prior to each scheduling run.

Note:
When you back up the database, the BACKUP function automatically generates a
database backup report to help you determine the optimum block size and number of
cylinders for the Zeke database. See the ASG-Zeke Scheduling for z/OS Reference Guide
for details.

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.

To back up the Zeke database

 Run a job to back up the Zeke database.

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

See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed information on
the BACKUP function and parameters.

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:
• Logical (default). This method reorganizes the database, which enables you to
restore the database to a larger dataset or merge two databases.

346
 7 Customizing and Maintaining Zeke

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

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

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

7 Restart OASIS. OASIS becomes active without activating Zeke.

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 JOB ,MSGLEVEL=(1,1),CLASS=A

//ZUTL EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’
//ZEKENEW DD DSN=new database name,
// DISP=(NEW,CATLG),UNIT=SYSDA,
// VOL=SER=ZEKEVL,
// SPACE=(CYL,(10),,CONTIG)
//SYSIN DD *
CREATE
/*

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.

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.

348
 7 Customizing and Maintaining Zeke

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

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

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.

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

4 Restore electronic vault support at the next available opportunity:

a Terminate all active Zekes sharing the database (using the ZKILL COLD
command).

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

350
 7 Customizing and Maintaining Zeke

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

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

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.

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.

352
 7 Customizing and Maintaining Zeke

Note:
Logged system activity is not maintained across an IPL.

Terminating Zeke using ZKILL TRACK

Use the ZKILL TRACK operator command to terminate the Zeke system and place it in
SMF recording mode. Zeke issues an informational message indicating that system
activity is being recorded. Termination continues as it would for a traditional ZKILL
COLD, except that only the IEFUJV SMF exit is de-installed. See 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)

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

• Resource management for jobs that are active when Zeke enters tracking mode
(even after Zeke is restarted)
• JCL error tracking
• 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.

354
 7 Customizing and Maintaining Zeke

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

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 JOBNAME PROCSTEP TRIGGER TIME SCHED DATE EVENT VER

ZEKE ZEKEAG53 EOS 16:53:42
ZEKEAG53 ZEKEAG53 EOJ 16:53:42
JCLPREP SPTJX1A EOS 16:53:43
SPTJX1A SPTJX1A EOJ 16:54:08
QATST01 QATST01 BOJ 16:54:00 2013/006 000001 00000
QAUTIL QATST01 BOP 16:54:01
STEPUSI QATST01 EOS 16:54:11
QATST01 QATST01 EOJ 16:54:11
QATST02 QATST02 BOJ 16:54:01 2013/006 000002 00000
QAUTIL QATST02 BOP 16:54:01
STEPUSI QATST02 EOS 16:54:11
QATST02 QATST02 EOJ 16:54:11

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

Applying Maintenance
When you issue ZKILL TRACK, all Zeke modules are unloaded so that maintenance can
be applied, except:
• ZEKE48B
• ZEKE48C
• ZEKE48D
• ZEKE48F
• ZEKE48G

After maintenance is applied, terminate Zeke again using ZKILL COLD, then restart
Zeke to reload these modules.

If OASIS is terminated also, all OASIS modules are unloaded so that maintenance can be
applied.

SMF Playback
When Zeke restarts, it initiates playback. Activity within an individual job is played back
in the order it occurred. The order between different jobs is not preserved. Playback time
is compressed as much as possible so that Zeke can resume its normal dispatching. Job
accounting information, however, reflects the actual start time, end time, and duration of
the job run. After playback is complete, various messages are issued to indicate the
amount of activity and storage used during recording.

Z0140I GENOPT record A successfully loaded

Z03B03I SYSGEN record ******** successfully loaded
Z0401I Zeke Variable Monitor initialized
Z0701I Zeke System startup successful 6.1 Z610A000
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

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

Naming Zeke Variables 358
Setting Zeke Variable Values 358
Maintaining Variable Documentation 363
OASIS Variables 366
Naming OASIS Variables 368
Setting OASIS Variable Values 369
Temporary OASIS Variables 369
System-dependent Variables 370
Uses for Zeke Variables 371
Using Variables to Trigger Events 371
Using Variables to Control Jobstream Flow 372
Using Variables to Restart a Job 373
Substituting Variable Values in JCL 375
IF Clauses On SET Statements 378
Variable Substitution in SCOM Events 378

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

Zeke Variables
A Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned
numeric or character value. Zeke supports these types of variables:
• Zeke variables
• OASIS variables (see the ASG-OASIS for z/OS Reference Guide)
• System-dependent variables
• Originator variables (e.g., from a remote Zena server)

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 alpha
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 through +2,147,483,647.

358
 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 96).
• 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 366 for more information.

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

To define and maintain a Zeke variable

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

ASG-Zeke Variable Selection Criteria

Command ===>

Variable Name ===>

Primary commands: ADD BROWSE COPY DELETE DOCUMENT EDIT

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 *

Variable:
Type: C - character, N - numeric
System:
Appl:
GroupID:
UserID:
Date Range: - (MM/DD/YYYY) or (DD/MM/YYYY)
Time Range: - (HH:MM:SS)

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

Desired Result Action

Define a new variable 1 Enter ADD on the Command line.

2 Enter the variable name in the Variable Name field.
3 Press Enter.
Go to step 3.

Update a variable for which 1 Enter EDIT on the Command line.

you know the name
2 Enter the variable name in the Variable Name field.
3 Press Enter.
Go to step 3.

Update a variable for which 1 Type any information you know about the variable in
you do not know the name any of the Selection Field Masks fields.
2 Press Enter.

360
 8 Variables

The Variable Name Directory screen is displayed:

ASG-Zeke Variable Name Directory Row 1 to 6 of 6

Command ===> Scroll ===> PAGE

Variable name ===>

Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT

Line Commands: B - Browse C -Copy D - Delete E - Edit O - dOcument

Variable Name Appl Grp UserID Date Time System

$ED 01/30/2013 12:13:35 ZEQA
$KATHYG 02/08/2013 14:53:44 ZEQA
$KATHYG1 02/07/2013 16:54:40 ZEQA
$KATHYG2 02/07/2013 16:54:48 ZEQA
$KATHYG3 02/07/2013 16:55:57 ZEQA
$STPNAME 01/20/2013 15:16:32 ZEQA
***************************** Bottom of data ******************************

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

Desired Result Action

Update the variable Enter E in the unlabeled selection field to the left of the
variable that you want to edit, and press Enter.

View the variable value Enter B in the unlabeled selection field to the left of the
variable that you want to view, and press Enter.

Delete the variable 1 Enter D in the unlabeled selection field to the left of the
variable to be deleted, and press Enter. The Variable Name
Record Functions screen is displayed.
2 Type DELETE on the Command line, and press Enter.
3 Press Enter again to confirm.
This procedure is complete.

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

The Variable Name Record Functions screen is displayed:

ASG-Zeke Variable Name Record Functions EDIT

Command ===>

Variable Name: $PAYCHECK

Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT

Appl: PAYROLL GroupID: CHK UserID: KAC

Desc: STARTING CHECK NUMBER
Desc2:

Curr Value: 1001

Force upper: Y
Value set by: U (J=Job P=Program U=User) Name: ALICE
Date/Time: 01/30/2013 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/2013 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 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.

362
 8 Variables

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

8 Press Enter to save the changes.

Maintaining Variable Documentation

Zeke enables you to maintain and store Zeke variable-related documentation for the
variables that you are authorized to access.

Note:
This procedure cannot be used for OASIS variables. To access the OASIS variable
maintenance functions, you can issue the OVAR primary command from any Command
line in the Zeke ISPF online facility. See “OASIS Variables” on page 366 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 360:

ASG-Zeke Variable Name Directory Row 1 to 6 of 6

Command ===> Scroll ===> PAGE

Variable name ===>

Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT

Line Commands: B - Browse C -Copy D - Delete E - Edit O - dOcument

Variable Name Appl Grp UserID Date Time System

$ED 01/30/2013 12:13:35 ZEQA
$KATHYG 02/08/2013 14:53:44 ZEQA
$KATHYG1 02/07/2013 16:54:40 ZEQA
$KATHYG2 02/07/2013 16:54:48 ZEQA
$KATHYG3 02/07/2013 16:55:57 ZEQA
$STPNAME 01/20/2013 15:16:32 ZEQA
***************************** Bottom of data ******************************

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

3 Enter the line command O to the left of the Variable Name field and press Enter.
The Document Segments screen is displayed:

ASG-Zeke Documentation Segments EDIT

Option ===>

Primary Command: DELETE

Variable: $KATHYG1
System: ZEQA User: Group: Appl:

Documentation Record Selection Options

1 SCRATCH Scratch pad

2 TEXT Text information
3 NOTE 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 Enter one of these codes on the Command line to select the type of documentation
you want to access:

Desired Result Action

Access scratch pad Enter 1 and press Enter. Go to “Maintaining Scratch

documentation Pad or Note Documentation” on page 365.

Access text documentation Enter 2 and press Enter. Go to “Maintaining Text

Documentation” on page 366.

Access note documentation Enter 3 and press Enter. Go to “Maintaining Scratch

Pad or Note Documentation” on page 365.

364
 8 Variables

Maintaining Scratch Pad or Note Documentation

You can add, browse, edit, or delete Scratch or Note documentation for a variable. The
related screens enable you to define or browse up to 10 lines of information for each
variable. These documentation areas are like a “sticky note” and can be used for quick
reference information, or to pass notes from shift to shift or from one department to
another. An operator should always review any associated scratch pad or note pad
information before a job runs.

Note:
Even though there are separate documentation areas for Scratch Pad and Note
information, the procedures have been combined because the screen layouts, number of
lines of text, and fields are identical.

To maintain scratch pad or note documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in “Maintaining

Variable Documentation” on page 363:

ASG-Zeke Documentation Scratch Pad ED

Command ==>

Primary Commands: BROWSE CANCEL DELETE EDIT

Line 1 PASS THIS TO 3RD SHIFT

2
3
4
5
6
7
8
9
10

Variable name: $TAPUG1

System: ZEQA Userid: Groupid: Appl:

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.

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

Maintaining Text Documentation

You can add, browse, edit, or delete text documentation for a variable. This
documentation area enables you to define a sizeable amount of information for a variable
(up to approximately 450 records).

To maintain text documentation

1 Access the Text Documentation screen as instructed in “Maintaining Variable

Documentation” on page 363:

ASG-Zeke Text Documentation EDIT

Command ===> Columns 000 000 Scroll ===> PAGE

Variable: $KATHYG1 System: ZEQA User: Grup:

****** *************************** Top of Data *****************************
==MSG> -Warning- The UNDO command is not available until you change
==MSG> your edit profile using the command RECOVERY ON.
000001 IF YOU NEED TO UPDATE THIS VARIABLE MORE THAN 3 TIMES PER SHIFT, (NOT
000002 PER DAY), NOTIFY THE SHIFT SUPERVISOR. THE BASE VALUE WILL NEED TO BE
000003 RECONFIGURED BASED ON NUMBER OF OCCUPIED SEATS AND AVAILABLE LINES.
****** *************************** Bottom of Data **************************

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.

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

366
 8 Variables

For example:

$(OASVAR1)
• OASIS has its own online system where you can define, edit, and view OASIS
variables and their values.
• Access to OASIS variables can be restricted by SAF security (through OASIS/ESI).
If security is in effect for OASIS variables, an operator must have at least READ
authority to be able to browse variable definition or value records, and ALTER
authority to be able to add, update, or delete variable records or set a value (e.g.,
through a work center event). See the ASG-OASIS for z/OS Reference Guide for
more information on OASIS variables security.
• 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).
• 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.

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

Substitution
Function Description

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 369 for more information.

See the ASG-OASIS for z/OS Reference Guide for detailed information before you use
OASIS variables for the first time.

Naming OASIS Variables

OASIS variable names can be up to 64 characters long. The first character can be any of
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.

368
 8 Variables

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

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.

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

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.

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

370
 8 Variables

Job Control Variable Name CPUID Actual Name Used

$$$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 submittal
• Pass information from one job, job step, or program to another
• Document cancellation reason
• Establish relationships between jobs

Using Variables to Trigger Events

A dependency is a condition that must exist before an event can be dispatched.
Dependencies include a job that must process, a dataset that must close, or a variable that
must be set to a specific value. See “WHEN Conditions” on page 126 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.

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

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.

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,

372
 8 Variables

// 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 EXEC PGM=PROG4 <== Step 4

//TAPEIN DD DSN=SOME.DATASET,DISP=OLD,UNIT=TAPE
//RPTSIN DD DSN=&&AR.REPORTS,DISP=(OLD,DELETE),UNIT=SYSDA

//SYSPRINT DD SYSOUT=A
//*
//CHKEXCP EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’
//SYSPRINT DD SYSOUT=A
//SYSIN DD *
SET CODE 20 IF $$$ARFLG NE YES <== Bypass Step 5 if variable=NO
/*
//ARSTP5 EXEC PGM=PROG5,=(0,NE,CHKEXCP) <== Step 5
//EXCPFILE DD DSN=AR.EXCPS,DISP=(OLD,DELETE)
//SYSPRINT DD SYSOUT=A
//

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.

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

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.

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

374
 8 Variables

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.

Because variable substitution is performed while Zeke is submitting the jobstream to JES,
the variables must contain the proper values at job dispatch time. Because of the timing,
these limitations exist for setting a value:
• A value cannot be set in one job step and the new value be substituted into a
subsequent statement in the same job. The substitution for that statement was
already done before the job started (using 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.

This search order is used to retrieve the variable (if multiple variables with the same name
exist):

1 Event-level variable

2 Originator variable (i.e., in a remote work task received by Zeke)

3 Database variable

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

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

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

Sample Resolved
Statement Statement Explanation

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

//$X..$Y //PR01P001.74 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.

//$X JOB, //PR01P001 JOB, If the variable value is longer than the name, the
PAYROLL.EDIT 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).

376
 8 Variables

Sample Resolved
Statement Statement Explanation

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

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

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

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

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

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

378
 8 Variables

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

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

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

Zeke Security Processing 384
Security Calls 384
Authenticating Operator Commands 388
Security Tracing 389
Internal Security 389
Internal Security Terms 389
Online Access 391
Operator Record 391
Class Record 392
Batch Access 392
Operator Commands 392
Implementing Internal Security 393
External Security 405
Security Classes and Resource Names 406
Implementing External Security 411

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

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:

Internal External
Objects Security Security

Zeke database 

EMRs  

SQRs  

Variables  

382
 9 Security

Internal External
Objects Security Security

Calendars 

Generation options (GENOPT) 

Initiator definitions (GENSYS) 

Company name and address 

Pool definitions 

Internal security (class and operator) records 

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 External
Functions Security Security

Primary Menu options  

Batch equivalents of Primary Menu options  

SCHEDULE function 

ZEKESET commands 

Individual SCOM command lines 

Zeke operator commands  

Online event ADD (by event type) 

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

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 389 and “External Security” on page 405 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).

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

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

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 Zeke operator, address space, or server command
• 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

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

386
 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

Does genopt N N Does ESI say to N

ESIActv=Y? revert to internal?

Y Y

N Does internal N
Does ESI apply
to this call? security apply?

Y Y

Call ESI Internal security Call user security

verification exit (if applicable)

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

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

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

Authenticating Operator Commands

Zeke operator commands (prefixed with Z) are authenticated through Zeke internal
security, as well as external security (if enabled).

Zeke address space commands (prefixed with #) and Zeke server commands (prefixed
with $) are authenticated only through external security (if enabled).

By default, commands are authenticated against profiles created in the Z$CMD class in
the external security product.

388
 9 Security

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:

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

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

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.

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

390
 9 Security

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.
• If ReqOpid is set to N, Zeke allows any user to access the Zeke online system.

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.

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

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

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.

392
 9 Security

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

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:
• Define class IDs to group individuals who need similar access to the online
functions and commands. See “Defining Class Records” on page 399.
• Define an operator ID for each user to be granted access to Zeke. See “Defining
Operator Records” on page 402.
• Define which online functions and operator commands can be accessed by an
operator ID by assigning a class ID.

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.

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

Option Description

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.

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.

394
 9 Security

Option Description

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 Security Control Functions

Option ===>

1 Operators List Operator Information by Operator ID

2 Classes List Class Information by Class ID
3 ExtSec External Security Interface (ESI) Customization
X Return Return to main Zeke menu

2 Enter 1 on the Option line, and press Enter. The Directory of Operator IDs screen
is displayed:

ASG-Zeke Directory of Operator IDs Row 1 to 4 of 4

Command ===> ADD Scroll ===> PAGE
Operator ID: SECADMIN

Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: E - Edit B - Browse C - Copy D - Delete

Operator ID Class Date Date Last

Added Updated
DVNEKG A 08/30/2011 04/17/2012
DVNEKG1 B 09/06/2011 05/29/2013
OPERATOR A 09/19/2011 08/30/2012
SPTLRS1 B 06/18/2013 06/18/2013
******************************* Bottom of data ********************************

3 Enter ADD on the Command line.

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

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

5 Press Enter. The Operator Detail screen is displayed:

ASG-Zeke Operator Detail ADD

Command ===> 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 Zcom Event Work Documentation Variable

6 In the Class ID field, enter a valid class ID (see “Defining Operator Records” on
page 402), 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).

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 GENOPTs Directory Row 1 to 4 of 4

Command ===> 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/2013 13:21:28
*GLOBAL Zekeplex global options ZEKEUSER 12/05/2012 19:14:48
ZEKE60A * Zeke 6.0 component on SYSA ZEK60JOB 11/29/2012 15:53:54
******** Default local system options *DBCNVT* 11/10/2012 13:05:28
******************************* Bottom of data *******************************

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

396
 9 Security

The Generation Options EDIT screen is displayed with the options in alphabetical
order:

ASG-Zeke Generation Options EDIT Row 1 to 17 of 143

Command ===> Scroll ===> CSR

Zeke System: *GLOBAL Description: Zekeplex global options

Option Value Description

--------- ---------- ---------------------------------------------------------
Abhold: N (Y,N) Yes to hold recurring events if abended
AddInact: N (Y,N) Yes to allow ZADD of inactive event
AuditCls: Y (Y,N) Yes to log Security Class changes
AuditCmd: Y (Y,N) Yes to log Zeke operator commands
AuditCnd: Y (Y,N) Yes to log Calendar changes
AuditEcd: Y (Y,N) Yes to log ESI Class changes
AuditEmr: Y (Y,N) Yes to log EMR changes
AuditEvt: Y (Y,N) Yes to log event flow
AuditGop: Y (Y,N) Yes to log Generation Option (GENOPT) changes
AuditNam: Y (Y,N) Yes to log Name/Address changes
AuditOpr: Y (Y,N) Yes to log Zeke Operator changes
AuditPin: Y (Y,N) Yes to log Partition/Initiator changes
AuditPoo: Y (Y,N) Yes to log Pool changes
AuditRes: Y (Y,N) Yes to log Resource changes
AuditSqr: Y (Y,N) Yes to log SQR changes
AuditVar: Y (Y,N) Yes to log Variable changes

9 To quickly find the options in the security category, you can use these primary
commands (see “Viewing GENOPT Details” on page 293 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.

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

This is an example of the detail view by category for the same GENOPT:

ASG-Zeke Generation Options EDIT Row 116 to 132 of 154

Command ===> Scroll ===> CSR

Zeke System: *GLOBAL Description: Zekeplex global options

Option Value Description

--------- ---------- ---------------------------------------------------------
==================== Security ================================================
BatOprid: BATCH (xxxxxxxx) Default security batch operator id (VSE)
BatSec: N (Y,N) Yes for Zeke to perform batch security (VSE)
DefOpid: OPERATOR (xxxxxxxx) Default operator id to use for internal security
ESIActv: N (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 395 for more
information).

Or
To allow access for users who are not defined to Zeke, take these actions:

a Locate or scroll to the DefOpid field, specify a valid operator ID (see “Defining
Operator Records” on page 402), 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.

11 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

398
 9 Security

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.

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 Directory of Command Classes Row 1 to 2 of 2

Command ===> Scroll ===> PAGE

Class ID==>

Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: B - Browse C - Copy D - Delete E - Edit

Class Event Zcom Cal Opt Work Sec Doc Var Res

A W W W W W W W W W
B W N W W W W W W W
***************************** Bottom of data ******************************

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

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

Desired Result Action

Add a new 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.

400
 9 Security

The Class Detail screen is displayed:

ASG-Zeke Class Detail EDIT

Command ===>

Class Id: A

Primary Commands: ADD BROWSE CANCEL COPY DELETE EDIT

Allowed functions
Event - W Work Center- W (R=Read only W=Write allowed)
Zcom - W Security - W (A=Auto entry in write mode)
Calendar - W Document - W (N=Not allowed)
Options - W Variable - W
Restart - W

Schedule control (OPERATOR) commands allowed (Y=Yes, N=No)

ZADD - Y ZID - Y ZSET - Y
ZALTER - Y ZKILL - Y ZSTATUS - Y
ZDELETE - Y ZMAP - Y ZSCAN - Y
ZDISABLE - Y ZOK - Y ZRESOURCE DISPLAY - Y
ZDISPLAY - Y ZREFRESH - Y ZRESOURCE ALTER - Y
ZENABLE - Y ZRELEASE - Y ZRESOURCE RELEASE - Y
ZHOLD - Y ZRELOAD - Y ZPLEX - Y

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

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

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

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 402 for more information).

5 Press Enter to save the changes.

Defining Operator Records

Operator records control access to the various types of database records (e.g., SQRs,
EMRs, work centers, documentation, and variables).

You assign an operator ID to each authorized user and assign each operator ID to a class
that specifies the functions and commands that are allowed for users with that operator
ID. You can restrict access further by the user ID (which controls user access to specific
event and variable records).

To create or maintain operator records

1 From the Zeke Primary Menu, enter option 6.1. The Directory of Operator IDs
screen is displayed:

ASG-Zeke Directory of Operator IDs Row 1 to 1 of 1

Command ===> Scroll ===> PAGE
Operator ID:

Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: E - Edit B - Browse C - Copy D - Delete

Operator ID Class Date Date Last

Added Updated
OPERATOR A 01/16/2013 01/30/2013
L003J A 01/24/2013 02/04/2013
****************************** Bottom of data *****************************

402
 9 Security

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

Desired Result Action

Add a new operator ID 1 Enter ADD on the Command line.

2 Specify the new operator ID in the Operator ID field.
3 Press Enter.
Go to step 3.

Update an existing operator ID 1 Enter E to the left of the operator ID to update.

2 Press Enter.
Go to step 3.

Copy an operator ID 1 Enter C to the left of the operator ID to copy and

press Enter.
2 Specify the new operator ID in the Operator ID field
and press Enter.
This procedure is complete.

Delete an existing operator ID 1 Enter D to the left of the operator ID to delete and
press Enter.
2 Enter DELETE on the Command line to confirm and
press Enter.
This procedure is complete.

The Operator Detail screen is displayed:

ASG-Zeke Operator Detail ADD

Command ===> 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 Zcom Event Work Documentation Variable

******** W W W W W

3 In the Class ID field, specify the ID of the class to which you want to assign this
operator.

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

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

6 Press Enter to save the changes.

404
 9 Security

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 384 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:
• 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.

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

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

406
 9 Security

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

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

These are the Zeke security classes, along with their resource names and authority levels
(see “Authority Levels” on page 384 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). ACTIVATE
(ALTER access required)
Resource name: SCHEDULE.GENERICS
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 ALTER
RESTORE
STATUS (enables CREATE, RESTORE,
BLOCK and BLOCK functions)
CLEARCPU

Z$CLASS Secures access to Zeke internal security class records. 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

408
 9 Security

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 READ
option is not necessary if all of the desired records have been (enables READ mode for that
secured. section of the online)

Note: UPDATE

Options to which you do not have access are not displayed on (enables WRITE mode)
the Zeke Primary Menu.

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$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. READ/UPDATE/ALTER

Resource name: Zeke-catalog-ID

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

Zeke Security Classes

Class Description Authority Levels

Z$SCHED Secures access to the SCHEDULE function. READ

(if ACTIVATE is not specified)
Note:
ALTER
Object-oriented security is not applied because a security call
would be required for each attempt to access a record. (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

410
 9 Security

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

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

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

COMMAND ===> SCROLL ===> PAGE X1SELECT

Primary Commands: DOWN UP EDIT BROWSE END RETURN

Line Commands: F - Resource name format
C - Copy to discrete ECDR D - Delete discrete ECDR

"Copy to" Internal External Process

System System Class Class Option

******** Z$ACCESS Z$ACCESS N4

******** Z$CATAL Z$CATAL Y4
******** Z$CLASS Z$CLASS N4
******** Z$CMD Z$CMD N4
******** Z$CND Z$CND N4
******** Z$DOWNLD Z$DOWNLD N4
******** Z$ECDR Z$ECDR N4
******** Z$EMR Z$EMR N4
******** Z$GOPT Z$GOPT N4
******** Z$NAME Z$NAME N4
******** Z$ONLINE Z$ONLINE N4
******** Z$OPER Z$OPER N4
******** Z$PINT Z$PINT 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 1 Enter EDIT on the Command line, and press Enter.
name
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.

412
 9 Security

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 Enter D to the left of the record to delete, and press Enter.
all of its attributes
Go to step 6.

Note:
You cannot delete class records for the default system (********).

Change the process option Note:

for a security class 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:

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.

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

Desired Result Action

3 Press Enter.
Go to step 6.

Change the resource name Enter F to the left of the class name to change, and press
format for a security class 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 ESI Customization BROWSE

COMMAND ===> SCROLL ===> PAGE X1FRMAT1

Primary Commands: DOWN UP EDIT BROWSE RESET END RETURN CANCEL

Line Commands: A - Insert element after B - Insert element before
D - Delete element

--+---1----+----2----+----3----+----4----+----5----+----6----+----7---+--8
aaaaaaaa.bbbbbbbb

Start Length Field Description 3 elements

a 001 008 User ID

. 001 001 Delimiter character
b 001 008 Record type
**END**

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

414
 9 Security

Desired Result Action

Change a portion of an 1 Enter EDIT on the Command line, and press Enter.
element to be included in
2 Specify the beginning position in the Start field.
the resource name format
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 If you have saved changes to the format and want to cancel
format to the default them, Enter RESET on the Command line, and press Enter.

Exit screen without saving If you have made changes to the format that you do not want
changes made to the to keep and have not saved them, Enter CANCEL on the
format 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 ESI Customization EDIT

COMMAND ===> SCROLL ===> PAGE X1FOFSEL

Primary Commands: DOWN UP END RETURN

Line Commands: C - Copy field

Length Field Description

001 Delimiter character

1-8 Literal value ===> __________ (quoted)
008 User ID
008 Application ID
003 Group ID
012 Event name
008 Job name
008 System name
004 Event type
008 Record type
008 Target
008 Platform
007 Source
002 Disaster recovery level
008 Zeke internal catalog ID
004 Subsystem name

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

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 GENOPTs Directory Row 1 to 4 of 4

Command ===> 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/2013 13:21:28
*GLOBAL Zekeplex global options ZEKEUSER 12/05/2012 19:14:48
ZEKE60A * Zeke 6.0 component on SYSA ZEK60JOB 11/29/2012 15:53:54
******** Default local system options *DBCNVT* 11/10/2012 13:05:28
******************************* Bottom of data *******************************

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

416
 9 Security

The Generation Options EDIT screen displays the options in alphabetical order:

ASG-Zeke Generation Options EDIT Row 1 to 17 of 143

Command ===> Scroll ===> CSR

Zeke System: *GLOBAL Description: Zekeplex global options

Option Value Description

--------- ---------- ---------------------------------------------------------
Abhold: N (Y,N) Yes to hold recurring events if abended
AddInact: N (Y,N) Yes to allow ZADD of inactive event
AuditCls: Y (Y,N) Yes to log Security Class changes
AuditCmd: Y (Y,N) Yes to log Zeke operator commands
AuditCnd: Y (Y,N) Yes to log Calendar changes
AuditEcd: Y (Y,N) Yes to log ESI Class changes
AuditEmr: Y (Y,N) Yes to log EMR changes
AuditEvt: Y (Y,N) Yes to log event flow
AuditGop: Y (Y,N) Yes to log Generation Option (GENOPT) changes
AuditNam: Y (Y,N) Yes to log Name/Address changes
AuditOpr: Y (Y,N) Yes to log Zeke Operator changes
AuditPin: Y (Y,N) Yes to log Partition/Initiator changes
AuditPoo: Y (Y,N) Yes to log Pool changes
AuditRes: Y (Y,N) Yes to log Resource changes
AuditSqr: Y (Y,N) Yes to log SQR changes
AuditVar: Y (Y,N) Yes to log Variable changes

3 To quickly find the options in the security category, you can use these primary
commands (see “Viewing GENOPT Details” on page 293 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.

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

This is an example of the detail view by category for the *GLOBAL GENOPT:

ASG-Zeke Generation Options EDIT Row 116 to 132 of 154

Command ===> Scroll ===> CSR

Zeke System: *GLOBAL Description: Zekeplex global options

Option Value Description

--------- ---------- ---------------------------------------------------------
==================== Security ================================================
BatOprid: BATCH (xxxxxxxx) Default security batch operator id (VSE)
BatSec: N (Y,N) Yes for Zeke to perform batch security (VSE)
DefOpid: OPERATOR (xxxxxxxx) Default operator id to use for internal security
ESIActv: N (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 394 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.

418
 9 Security

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

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

You now are ready to test the implementation. For information on testing ESI with
ESITRACE, see the ASG-OASIS for z/OS Reference Guide.

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

420
 Zeke Web Services
Chapter 10:

10
Zeke Web Services enables you to access Zeke events and 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

Overview 421
Accessing Zeke Web Services 422
Setting Zeke Web Services as Your Home Page 423
Accessing Events through the Web 423
Displaying an Event Directory 423
Displaying an Event Detail Listing 427
Managing Work Centers through the Web 433
Accessing Work Centers 433
Creating and Maintaining Custom Views 436
Completing a Work Center 442
Enabling or Disabling a Work Center 447
Refreshing a Work Center 448

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

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

See the ASG-Zeke Scheduling for z/OS Installation Guide for details on configuring the
Zeke server to enable Web Services.

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 Web 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 use links to access either the list of scheduled work centers
or the page for maintaining custom views of the work center list. You also can
access Zeke events by specifying the appropriate URL.

422
 10 Zeke Web Services

See “Accessing Events through the Web” on page 423 and “Managing Work
Centers through the Web” on page 433 for detailed procedures.

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:

<!DOCTYPE html SYSTEM “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<html xmlns=”http://www.w3.org/1999/xhtml”>
<head>
<title>ASG-Zeke Web Services</title>
<META HTTP-EQUIV=”Refresh” CONTENT=”0; URL=/zeke/”>
</head>
<body>
<p>Loading <a href=”/zeke/”>Zeke Web Services</a>, please wait.</p>
</body>
</html>

This document returns for the root path ‘/’ and then redirects your browser to the Zeke
Web Services (‘/zeke/’) page.

Accessing Events through the Web

Zeke Web Services enables you to access EMRs using a Web browser.

For more information on events (including how they are defined), see Chapter 4,
“Events,” on page 49.

Displaying an Event Directory

This section explains how to access a directory of events through Zeke Web Services.

To access the event directory

1 Optional. Start the Web interface as described in “Accessing Zeke Web Services” on
page 422. The Zeke Web Services home page appears.

2 Point your Web browser to this URL:

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

http://your.mainframehost:nnnn/zeke/event/dir[type]
[?query-variables]
where:
your.mainframehost is the host name or IP address for Zeke Web Services.
nnnn is the port number for Zeke Web Services.
type is the optional request type. The valid values are .html (default), .text,
and .xml.
query-variables specifies the optional query variables to use for selecting
which events to display in the directory. Consider these points when using variables
to specify selection criteria in the request path:
— When you append multiple query variables to the request path, precede the first
one with a question mark (?) and precede all subsequent ones with an
ampersand (&). For example, this path would create a directory of all scheduled
job events that also displays the jobname and JCL source type for each event:

.../zeke/event/dir?type=job&select=jobname,jcltype
— When specifying multiple values for a variable that allows it, use a comma to
separate the values.
— You can specify ranges of values.
— You can use wildcard and placeholder characters.
These are the valid query variables, which you can use to specify basic identifying
information for the events you want to include in the directory:

Note:
You also can point your Web browser to this URL to display a list of valid query
variables you can include on the request path:

http://your.mainframehost:nnnn/zeke/event/help

Variable Description

activated= Specify whether the EMR is activated (i.e., can be scheduled). These are
the valid values:

0 Select only events that currently are not activated (i.e.,

false cannot be added to the schedule).
no

1 Select only events that currently are activated (i.e., can

true be added to the schedule).
yes

424
 10 Zeke Web Services

Variable Description

For example:
.../zeke/event/dir?activated=yes

appl= Specify the application ID (up to 8 alphanumeric characters long) to

match. For example:
.../zeke/event/dir?appl=asg001-asgl99,xappl*,zappl*

calid= Specify the calendar ID (up to 8 alphanumeric characters long) to match.

For example:
.../zeke/event/dir?calid=a

drl= Specify the disaster recovery level (up to 2 digits long) to match. The
valid values range from 1 through 99. For example:
.../zeke/event/dir?drl=1-10

ename= Specify the event name (up to 12 alphanumeric characters) to match. For
example:
.../zeke/event/dir?ename=asgmsgevt1,asgcmdevt1

etype= Specify the event type to match. These are the valid values:

1 Job event.
job

2 Message event.
msg

3 Power command event.

pcom

4 Work center event.

comment

5 VM CP command.
vcom

6 Zeke command event.

zcom

7 System command event.

scom

8 REXX event.
rexx

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

Variable Description

For example:
.../zeke/event/dir?etype=msg,cmd

events= Specify the event number (up to 6 digits long) to match. For example:
.../zeke/event/dir?events=1,6,10-20

groupid= Specify the group ID (up to 3 alphanumeric characters) to match. For

example:
.../zeke/event/dir?groupid=arl

jobname= Specify the jobname (up to 8 alphanumeric characters) to match. For

example:
.../zeke/event/dir?jobname=testjob1

select= Specifies the fields to include in the directory.

If you do not specify any fields, the default fields (as specified in the
ZENVIRN environment file) are displayed. See the ASG-Zeke
Scheduling for z/OS Installation Guide for details.
These are the valid values:

ACTIVATED Whether the EMR is activated (i.e., can be scheduled).

APPL Application ID

CALID Calendar ID

DRL Disaster recovery level

ENAME Event name

ETYPE Event type

EVENTS Event number

GROUP Group ID

JCLTYPE JCL source type

JOBNAME Jobname

MILESTONE Whether the event is flagged as a milestone.

PERMANENT Whether the event remains in the schedule

permanently

426
 10 Zeke Web Services

Variable Description

SYS System ID

TEMPLATE Whether the event is a template

USER User ID associated with the event

For example:
.../zeke/event/dir?type=job&select=jobname,jcltype

The event directory displays the requested information (or the default information if
no fields were specified) for the selected events:

Displaying an Event Detail Listing

This section explains how to access details for selected events through Zeke Web
Services.

To display event details

1 From the event directory, you can select an event and click its event number to
display details.

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

Point your Web browser to this URL:

http://your.mainframehost:nnnn/zeke/event/list[type][?query
variables]
where:
your.mainframehost is the host name or IP address for Zeke Web Services.
nnnn is the port number for Zeke Web Services.
type is the optional request type. The valid values are .html (default), .text,
and .xml.
variables specifies the optional query variables to use for selecting which
events to include in the detailed listing. Consider these points when using variables
to specify selection criteria in the request path:
— When you append multiple query variables to the request path, precede the first
one with a question mark (?) and precede all subsequent ones with an
ampersand (&). For example, this path would list details for events numbered
1 through 20 that currently are active (running):

.../zeke/event/list?events=1-20&active=yes
— When specifying multiple values for a variable that allows it, use a comma to
separate the values.
— You can specify ranges of values.
— You can use wildcard and placeholder characters.
These are the valid query variables, which you can use to specify basic identifying
information for the events you want to include in the event detail list:

Note:
You also can point your Web browser to this URL to display a list of valid query
variables you can include on the request path:

http://your.mainframehost:nnnn/zeke/event/help

Variable Description

activated= Specify whether the EMR is activated (i.e., can be scheduled). These are
the valid values:
These are the valid values:

0 Select only events that currently are not activated (i.e.,

false cannot be added to the schedule).
no

428
 10 Zeke Web Services

Variable Description

1 Select only events that currently are activated (i.e., can

true be added to the schedule).
yes

For example:
.../zeke/event/list?activated=yes

appl= Specify the application ID(s) to match. For example:

.../zeke/event/list?appl=asg001-asgl99,xappl*,zappl*

calid= Specify the calendar ID(s) to match. For example:

.../zeke/event/list?calid=a

ename= Specify the event name(s) to match. For example:

.../zeke/event/list?ename=asgmsgevt1,asgcmdevt1

etype= Specify the event type(s) to match. These are the valid values:

1 Job event.
job

2 Message event.
msg

3 Power command event.

pcom

4 Work center event.

comment

5 VM CP command.
vcom

6 Zeke command event.

zcom

7 System command event.

scom

8 REXX event.
rexx

For example:
.../zeke/event/list?etype=msg,cmd

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

Variable Description

events= Specify the event number(s) to match. For example:

.../zeke/event/list?events=1-20

groupid= Specify the application ID to match. For example:

.../zeke/event/list?groupid=arl

jobname= Specify the jobname(s) to match. For example:

.../zeke/event/list?jobname=testjob1

limit= Maximum number of events to display. The valid values range from 1
through 1000. For example:
.../zeke/event/list?limit=20
If you do not specify a limit, the default value (as specified in the
ZENVIRN environment file) is used. See the ASG-Zeke Scheduling
for z/OS Installation Guide for details.

quiet Suppresses error messages from the event detail list results (if any errors
occur during record access). For example:
.../zeke/event/list?quiet

select= Specifies the fields to include in the directory.

If you do not specify any fields, the default fields (as specified in the
ZENVIRN environment file) are displayed. See the ASG-Zeke
Scheduling for z/OS Installation Guide for details.
These are the valid values:

ACCTG Displays the early dispatch time for the event.

ACTIVE Indicates whether the event is active (i.e., currently

running).

CALID Displays the calendar ID.

CLASS Displays the job class for a job event.

DESC Displays a description of the event.

DOC Displays the documentation (of any type) for the event.

DSN Displays the dataset name for a job event.

EARLY Displays the early dispatch time for the event.

ENAME Displays the event name.

430
 10 Zeke Web Services

Variable Description

EVENT Displays the event number.

EXEC Displays the EXEC name contained in a REXX event.

GROUP Displays the group ID.

JCL Displays the JCL source type for job events.

JOBNAME Displays the jobname for job events.

LATE Displays the late dispatch time for the event.

NEXTDATE Applies the current query to the next schedule date.

NOTEPAD Displays the note pad documentation for the event.

OCCURS Displays the OCCURS clause for the event.

OPEROK Indicates whether an operator approval is required to

enable the event to run.

PRIORITY Displays the Zeke dispatching priority.

REPLY Displays the auto reply elements for the event.

RESOURCE Displays the assigned resource name for the event.

REXX Indicates whether the event is a REXX event.

SCHENV Displays the name of the scheduling environment.

SCOM Displays the system command for an SCOM event.

SCRATCHPAD Displays the scratch pad documentation for the event.

SECGROUP Displays the name of the security group (for MVS job
events).

START Displays the start time for the event.

SYSTEM Displays the system ID.

TAPES Displays the number of tape drives required.

TARGET Displays the routing option or Netregid for the remote

system.

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

Variable Description

TEXTPAD Displays the text documentation for the event.

TIME Displays the early dispatch time for the event.

USERID Displays the user ID associated with the event.

VCOM Displays the VM CP command for a VCOM event.

WHEN Displays the WHEN conditions for the event.

WORK Displays the comment lines for a work center event.

ZCOM Displays the Zeke command for a ZCOM event.

year= Specify the year to determine the OCCURS hit information for the
selected events. The default value is the current year. For example:
.../zeke/event/list?year=2014

The event detail list displays the requested information (or the default information if
no fields were specified) for the selected events:

432
 10 Zeke Web Services

Displaying an Event Detail Listing for the Following Day

You can use a shortcut to apply the current query to the following day’s schedule and
view the results.

To display event details for the next date

1 Point your Web browser to this URL:

http://your.mainframehost:nnnn/zeke/event/nextdate[type]
where:
your.mainframehost is the host name or IP address for Zeke Web Services.
nnnn is the port number for Zeke Web Services.
type is the optional request type. The valid values are .html (default), .text,
and .xml.

The current query is applied to the next day’s schedule:

Managing Work Centers through the Web

Zeke Web Services enables you to view and manage Zeke work center events using 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 96.

Note:
The Zeke generation option LoadComm must be set to Y to enable work centers to be
accessed through Zeke Web Services.

Accessing Work Centers

This section explains how to access 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 422.

2 From the Zeke Web Services home page, click Work Center List.

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

The Work Center list appears in its default view:

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 436 for instructions on
creating and customizing different views.

434
 10 Zeke Web Services

These are the default column headings:

Heading Description

Status Status of the work center activity. These are the valid statuses:

(gray) Not Done

(green) Pending

(blue) Done

(yellow) Disabled

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 440), delete it (see “Deleting a View” on
page 442), or create a new view using any existing view as a template (see
“Creating a New View” on page 436).

To switch to a different view

 Select an existing view from the Views: drop down list, and click Select.

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

Note:
Views are listed according to their name and whether they are defined for use by the
current user only or by all users. View names are displayed like this:

viewname:viewdescription

For example:

WC:Not Done Only

After you select a different view, you can view the work center list under this view,
edit the view (see “Updating a View” on page 440), use it as a template for creating
a new view (see “Creating a New View” on page 436), or delete it (see “Deleting a
View” on page 442).

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 Work Centers” on page 433 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

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

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

436
 10 Zeke Web Services

The All Views list appears:

The All Views list displays this information:

Column Description

Type Type of view, where wc indicates the view is a work center view.

Name User-defined name of the view.

Description Description of the contents of the view.

Level Access level for the view. These are the valid levels:

Personal The view is available to the current user only.

Note:
Personal views are saved under the name of the
user.

Shared The view is available to all users.

System This is the predefined, default view.

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

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

Note:
You also could click on any other existing view to use it as a template instead of the
default view.

The Zeke View Maintenance customization screen appears:

From this screen, you can edit the default system view to create a new view.

Or
You can switch to another view. Select one from the Views: drop down list, and
click Select.

438
 10 Zeke Web Services

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

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

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.

Event Display only the work centers with the specified event number.

You can specify these wildcard and placeholder characters in any of the filtering criteria
described below:
• Specify * to match any number of 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.

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

6 Select the Enabled check box to enable the specified filters.

7 In the Update View section, complete these fields:

Field Description

View Name Specify a name for the new view.

Description Specify a description for the new view.

8 Select the Shared check box if you want to make this view available to all users.

9 Click Save to create the new view and return to the All Views list. The default system
view is retained.

Updating a View
Typically, you manage and update views through the View Maintenance function. You
also can access and update a view directly from the Work Center List.

To update a view

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

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

440
 10 Zeke Web Services

4 In the Select Filters section, update these fields:

Field Description

Status Display only the work centers with the specified status. Select one of
these statuses from the drop-down list:

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.

Event Display only the work centers with the specified event number.

You can specify these wildcard and placeholder characters in any of the filtering criteria
described below:
• Specify * to match any number of characters.
• Specify ? to match any single character.

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

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

7 Update the Shared setting indicating whether you want to make the view available
to other users.

8 Click Save to update the view and return to the All Views list.

Deleting a View
Typically, you manage views (including deleting them) through the View Maintenance
function. You also can access and delete a view directly from the Work Center List.

To delete a view

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

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

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

2 From the Zeke Web Services home page, click Work Center List.

3 Optional. Select a view from the Views drop-down list to narrow down the list of
work centers (e.g., only the work centers that are not done yet).

442
 10 Zeke Web Services

4 Locate the work center that you want to complete, and right-click the work center for
a context-menu:

5 Select Complete Work Center to mark the work center for completion.
The work center status changes to Pending. This status enables you to review
documentation or update variables, if necessary.

6 If you have already performed the required work center activity, skip to step 7 on
page 444.

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.

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

The Work Center View appears:

Note:
At any time, you can click Cancel to cancel any changes and return the work center
to its previous state (i.e., Pending or Not Done), and return to the Work Center
list.

7 Click Complete to complete the work center. The work center status changes to
Done.

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

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

444
 10 Zeke Web Services

2 From the Zeke Web Services home page, click Work Center List.

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

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

Figure 5 • Sample Note Doc

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.

446
 10 Zeke Web Services

To set a variable

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

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

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

Disabling a Work Center

You can disable a work center that has not been completed yet, so that Zeke proceeds
with event dispatching as if the event were not in the schedule.

To disable a work center

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

2 From the Zeke Web Services home page, click Work Center List.

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

4 Locate the work center that you want to disable and right-click for a context-menu.

5 Click Disable Work Center.

The work center’s status is changed to Disabled.

Enabling a Work Center

You can enable a work center that has been disabled.

To enable a work center

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

2 From the Zeke Web Services home page, click Work Center List.

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

4 Locate the 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 in Pending, Disabled, or Done status. All prerequisite conditions must be satisfied
again.

448
 10 Zeke Web Services

To refresh a work center

1 Start the Web interface as described in “Accessing Zeke Web Services” on page 422.

2 From the Zeke Web Services home page, click Work Center List.

3 Locate the work center you want to refresh.

a Click on the Name of the work center event.

The Work Center View screen appears.

b Click Refresh.

Or

c Right-click for a context-menu and select Refresh Work Center.

The work center is refreshed and its status is changed to Not Done.

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

450
 Appendix A
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.

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

System Requirements
These are the system requirements for using the Zeke Agentless program:
• USS must be configured on the z/OS system.
• At least one user account must be configured to use the HFS file system.
• ssh must be configured on the z/OS system and on all target machines that will
receive work through the Agentless program. The ssh protocol must be version 2.
• Because Zeke does not know a user’s password, ssh must be configured so that it
does not require a password.

Caution! Keep in mind that if the ssh approved user logs on to USS, the user can
send any command to ssh on the configured box.
• Scripts for the jobs must be located in the HFS file system.
• Output from the jobs either must be directed to the HFS file system or must not be
trapped.

Installation and Configuration

This section provides instructions for installing and configuring the Zeke Agentless
program (ZEKENOA).

To install Zeke Agentless

1 Be sure that USS is configured on the z/OS system.

2 Copy the ZEKE6NOA executable from the Zeke LINKLIB to the HFS system. You
can copy the executable into any directory (as long as the necessary protection is set
to allow access to approved users).

For example, if your Zeke LINKLIB is named ZEKE.LINKLIB and the target
directory for the executable is /var, you can use this TSO command:

OPUTX 'ZEKE.LINKLIB(ZEKE6NOA)' '/var/zeke6noa' ASIS

A response similar to this will appear:

Linking 'ZEKE.LINKLIB(ZEKE6NOA)' as /var/zeke6noa

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

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

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

where mysystem is the hostname.

Sample output:

The authenticity of host 'mysystem (10.107.15.45)' can't be established.

RSA key fingerprint is 5f:ae:92:87:01:71:ee:ae:77:56:5f:75:3c:ca:2c:e1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mysystem,10.107.15.45' (RSA) to the list of
known hosts.
User1@mysystem's password:

11 Rerun the command. If the configuration is correct, you are not prompted to answer
any questions. For example:

ssh -l user1 mysystem "uname -a"

12 Repeat this procedure for all users and all target machines.

13 Place your job scripts in the HFS file system. Output from the jobs must either be
directed to the HFS file system or must not be trapped. See “JCL Requirements” on
page 454 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:
— The Zeke subsystem name is the name of the Zeke subsystem that submitted
the job (which is used to verify that Zeke is running).

454
 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 JOB (10039),CLASS=A,MSGCLASS=X,NOTIFY=ASGU1,

// USER=ASGU1
//STEP1 EXEC PGM=BPXBATCH,
// PARM='sh /var/zeke6noa ZEKA mysystem.mycompany.com user1'
//STDIN DD PATH='/u/asgu1/script.sh',
// PATHOPTS=(ORDONLY),
// PATHMODE=SIRWXU
//STDOUT DD PATH='/u/asgu1/script.stdout',
// PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
// PATHMODE=SIRWXU
//STDERR 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.

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

ZEKE6NOA Command
This section explains how to use the ZEKE6NOA command.

Syntax
zeke6noa [-dlwV] zekesubsystem destination username [home]

Parameters
These are the valid parameters for the ZEKE6NOA command:

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.

456
 Appendix B
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 328 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).

2 Be sure that the global Zeke generation option ZekeCtl is set to Y (the default
value).

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

ZEKECTL Statements
When submitting a job event to JES, Zeke inserts comment statements (containing
name/value pairs) into the JCL according to these rules:
• Name/value pairs cannot extend past column 71.
• Name/value pairs are listed alphabetically.
• Comment statements are inserted after the job statements, except in these cases:
• If the PosidEnd generation option is set to Y, then the comment statements
are inserted at the end of the job.
• If the Posid generation option is set to Y, then the comment statements are
inserted in front of the Zeke POSID step.
• Name/value pairs can contain character, numeric or logic (i.e., true/false) data.
• If the data is logic, then only the name is present (i.e., to indicate a true
condition). No name indicates a false condition.
• All character values are enclosed in single quotes.
• Zeke does not supply a name/value pair if its value blank or zero.

Note:
All possible name/value pairs might not be present for all jobs.

These are examples of the comment statements that Zeke inserts into the JCL:

//*ZEKECTL CAL='A',CATID='C4E6ACDA',DISPID='C8B149BE',DISPSYS='SYSA'

//*ZEKECTL DUR=0:01,EVT=1,EVTSYS='SYSA',SDATE=2012/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.

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

APPL 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 Event’s average CPU time (in minutes and seconds from
mmmmmm:ss the EMR. If only seconds, the value will include a leading
0 (zero). For example:
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 Event’s average duration from the SQR. If only seconds,
mmmmmm:ss the value will have a leading 0 (zero). For example:
0:03

* EVT numeric Event number from the SQR.

EVTNAME character Event name from the SQR.

* EVTSYS character Event’s system ID from the SQR.

GRP character Event’s group ID from the SQR.

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

Name Format Description

JCLOVRD logic Present (i.e., true) if the event’s JCL was overridden in the
SQR; otherwise, not present (i.e., false).

LATESTART numeric time Event’s ‘late start’ time (Latestart value) from the SQR.
hh:mm The possible values range 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 The time by which the job must start running in order not to
date/time be late. This value is based on the ‘late start’ time in the
yyyy/ddd. SQR. If there is no Latestart value specified in the SQR,
hh:mm then the ‘must start’ time is calculated as the average
duration subtracted from the Mustend value 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.

460
 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(Yes))

$Zeke_MustStart_Late_By 0,Not_Late,1,Slightly_Late,30,Very_Late
$Zeke_Muststart_Within 0,Soon,60,Pretty_Soon,240,Next_Shift,480,Long_Time
…
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

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 Event’s schedule time from the schedule record. The
hh:mm possible value are from 00:00 through 48:00.

* SDATE numeric date Event’s schedule date from the schedule SQR.
yyyy/ddd

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

Name Format Description

* SUBSYS character Zeke subsystem that dispatched the event. (This is the same
value that is displayed in the SUBSYS field when the ZID
operator command is issued.)

USERID character Event’s user ID from the SQR.

VER numeric Event’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 459.

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.

462
 Index

A class records
ADD Event Record by Path Selection defining 399
Criteria screen 261 CLIST commands 202
Add Event Record Function screen 59 colors, changing ISPF screen 34
ADD Event Record Selection Criteria commands
screen 258 CLIST 202
adding events by path 56–58, 261 command events 87
alerts in SCOM events 378
alert tolerance 176 ISPF 30–31, 54, 84, 171, 234, 366
job duration 176 JCL 223–224
OpsCentral 178, 244 operator 13, 68, 72, 85, 87–89, 91, 93,
ALTER, Schedule View command 197 95, 99, 143, 161, 164, 193, 246–
audit options 306 250, 371, 382
auto replies auto reply 161
disabling 165 security 389
displaying 164 POWER 87
enabling 165 REXX 202
managing Zack Fastpath/Autoreply Schedule View 12, 193, 231
tables from Zeke 34 securing 383
responding to outstanding replies 161 system 88
setting generation options 161–162 VM 88
using the AUTORPLY function 162 ZADD, for Schedule View 256
Auto Reply Function screen 162 ZEKE6NOA 456
Auto Reply Summary screen 162 ZKILL 29
Automation option, managing Zack communication, ’Z’ product
Fastpath/Autoreply tables from controlling 320
Zeke 34 completing work centers 102–103
Auto-Reply Function screen 163 Condition Code Validation screen 156
condition codes 11, 155–158
B controlling jobstream flow using
backing up the database 345 variables 372
using a data space 346 conventions page xii
CREATE batch utility
C setting up Z$CATAL class 388
calculating tape drive usage 318 creating the Zeke database 343
Calendar Selection Criteria screen 38 cross-platform dependencies 10, 131
calendars
accessing online 38 D
adding a calendar 39 data space
deleting a calendar 39 database backups using a 346
description 8 running simulation against a 192
special calendars 41 database
standard calendars 40 backup using a data space 346
user accounting calendars 42 creating 348
overview of user accounting creation 343
periods 44 job information contained in 3
CAPS mode 404 moving the vault database 349

463
ASG-Zeke Scheduling for z/OS Installation Guide

recovery, Zeke started task 351 variables

retrieving JCL 83 note pad 365
shared 322 scratch pad 365
variables 375 text 366
dataset triggering 136 Documentation Segments screen 45, 166,
hold code 213 168
date format, Schedule View 230 Documentation Selection Criteria
Date Selection screen 230 screen 166, 231
deleting downloading, setting up a job for 6, 68, 81–
GENOPTS 303–304 82
dependencies
cross-platform scheduling 10, 131 E
dataset triggering 136 early warning alerts, OpsCentral 244
defining 141 ECDRs, modifying 412
description 10 electronic vaulting
EOG (end of group) 137, 140 considerations for using 350
extended dependencies 127, 141 database allocation 350
generic event names 132 description 16
grouping multiple phrases 133 full recovery procedure 350
maintaining moving the database 349
from the EMR (all partial recovery procedure 351
versions) 143 ESI Customization screen 412, 414–415
multiple 133, 135 ESI, see security, external security
multiple job versions 127 event
Not Active 130 activating an event 57
see also logical resources adding events to the schedule
processing 126 manually 255
referencing started tasks 134 command events 87
satisfied 127 copying an event 65
using variables 134 from a template 63
viewing creating from a template 63
from the EMR (all deactivating an event 54
versions) 143 job events 68
WEAK conditions 129 routing to another system or
Detailed Action Language (DAL) 462 platform for
dispatch queue, checking 317 execution 67, 77
dispatching master record
description 9 accessing 52, 59
generation options 308 permanent 5, 146–154
list of prerequisites 10 recurring 5, 145–154
messages and jobs 310 resources, accessing 221
see also dependencies routing a job event to another system
displaying fields in Schedule View 228 or platform 67, 77
documentation status codes (in Schedule View) 208
calendars templates
note pad 46 creating events from a
scratch pad 46 template 63
text 47 defining a template 62
events 166 work centers 96
jobs event directory 427
datasets 171 Event Master Definition screen 231
note pad 169 Event Master Record Accounting
scratch pad 169 screen 174
summary of types 7 Event Master Record Function screen 99,
text 170 144

464
 Index

Event Master Selection Criteria screen 52, MSGWAIT 310

60, 231 MSPINTRL 311
event record directory screen 53 MULTAP 332
Event Record Occurs Clause screen 124 MULTEN 333
events MULTGR 332
permanent 147 Multsys 322
recurring MULTUS 333
defining 147 Netregid 77, 81
exit Nonwkday 334
generation options 319 OPEROK 311
exporting database records 19 Posid 77, 81
extended dependencies, see dependencies POSIDEND 329
external security PRILATE 311
see security reloading 305
REMTRIG 314
F RepJGrp 326
Fastpath, managing Zack Fastpath/Autoreply RepJName 326
tables from Zeke 34 RepJUser 327
forecasting the schedule 15 Reqopid 398
RETAIN 313
G RETDAYS 313
general generation options 319 RETDONE 313
generation options RETPEND 313
accessing 291 Secexitw 399
audit 306 Secfail 418
AUR 318 Sechide1 419
AURINTV 318 Sechide2 419
AURMSG 318 security options 394
Calctap 318 Subdata 337
COMMCTL 312 TRIGDT 315
DEFDPRTY 310 TRIGJOB 315
Defopid 398, 418 TRIGRRN 316
DISPDLY 310 WKTRGDN 316
DISPSEL 318 Generation Options EDIT screen 417
DSPIndex 55–56 Generation Options screen 294, 297
Eojwake 317 generic names 42, 53, 131, 133
global GENOPTs 290–337
dispatching 308 accessing 291
exit 319 adding 297
general 319 deleting 303–304
JCL 322 editing 300
scheduling 331 reloading 305
security 335 viewing pending updates 301
user interface 336 GENOPTs Directory screen 292, 416
variables 337 global options
IEFU83 314 dispatching 308
Loadcomm 334 exit 319
local general 319
dispatching 308 JCL 322
exit 319 scheduling 331
general 319 security 335
JCL 322 user interface 336
messages 330 variables 337
group

465
ASG-Zeke Scheduling for z/OS Installation Guide

overriding on JOB card 326 retrieving JCL from the Zeke

database 83
H substituting variable values 375
help, accessing Zeke ISPF online 30 syntax checking 242
holding an event 259, 262 with JCLPREP 237–239
host name 422 with JOB/SCAN 239–241
HTTP/HTTPS 421 using variables
to control jobstream flow 372
I to restart a job 373
IF clauses within SET statements 378 to trigger jobs 371
importing database records 19 validation
initializing the database 343 using ZSCAN 242
initializing the Zeke database 343 with JCLPREP 237
initiators with JOB/SCAN 239
adding Zeke job control statements 19
a system 272 JCL screen 84, 239, 241
specifications 272 JCLPREP, invoking from Schedule
copying an initiator record 273 View 237–239
defining initiators 271 JES job log 457
deleting job
a single initiator 273 adding jobs to the schedule 260, 264
all initiators for a system 273 checking the dispatch queue 317
determining processing 309 creating and adding to the schedule at
editing an existing initiator 272 the same time 193
system availability 273 defining 49
installation, setting up Z$CATAL class dispatching
before running CREATE 388 messages and jobs 310
internal security EMR
generation options 394 accessing 52
see security definition 4
IP address 422 event 68
ISPF menu screens setting up for downloading 6,
event record directory 53 68, 81–82
ISPF online facility log, displaying 200
changing colors on screens 34 MSG jobs 84
commands 30–31, 54, 84, 171, 234, name, overriding on JOB card 326
366 PCOM jobs 87
common fields 31 predecessors, viewing
features 30 in Schedule View 199
logging on 31 on the EMR 55–56
screen format 31 refreshing jobs 199
Zeke primary menu 34 scheduled job, changing via Schedule
see also under online View 197
SCOM jobs 88–89
J successors, viewing
JCL in Schedule View 199
displaying actual execution JCL 200 on the EMR 55
generation options 322 on the master 57
JCLR, Schedule View line templates
command 198 defining 62
line commands 223–224 VCOM jobs 88
override 234, 326 versions, dependencies for 127
performing one-time overrides for job ZCOM jobs 88
events 232 Job Action Language (JAL) 462

466
 Index

Job Class Capacity screen 276 reason code 215

job duration using logical resources 280
alerts 176 WHEN conditions 129, 137, 199
failures 177
JOB/SCAN, invoking from Schedule O
View 239–241 OASIS
JPREP line command 239 started task, starting 343
JSCAN line command 22, 241 starting without Zeke 27
subsystem requirements 2
L terminating 28
late events, early warning alerts in variables
OpsCentral 244 accessing 30
line commands in SET clauses 100
see commands naming 368
loading the work center to SQT 334 overriding variable values
local options temporarily 369
dispatching 308 overview 366
exit 319 setting with XVAR and
general 319 ?XVAR 101
JCL 322 temporary variables 369
messages 330 OASIS Primary Menu 33
trace options 336 OCCURS clauses
Logical Day defining 124
scheduling examples 8, 107, 184 grouping multiple phrases 111
logical resources list of keywords 110
copying a resource 282 multiple phrases 110
defining a resource to Zeke 281 processing 110
defining resources for an event 283 sample clauses 118
deleting a resource 282 scheduling for holidays and
deleting resources for an event 287 weekends 121
description 265 using parentheses in 111
editing an existing resource 282 online
maintaining 280 see also ISPF online facility
logon operator commands 13, 68, 72, 85, 87–89,
ISPF online 31 91, 93, 95, 99, 143, 161, 164, 193,
246–250, 371, 382
M authenticating 388
menus auto reply 161
OASIS Primary Menu 33 securing 389
Zeke Primary Menu 34 ZKILL 27
messages operator hold on an event 259, 262
dispatching 310 operator IDs
display system 200 mixed case 404
generation options 330 operator records
MSG job 84 defining 402
multiple OpsCentral
Zeke versions 2 early warning alerts 244
MVS User ID 390 originator variables 358, 375
OVAR 30
N overriding JCL 198, 234, 326
NETREGID 136 group on the JOB card 326
Network Hold status 214 job name on the JOB card 326
NOTDURING processing user ID on the JOB card 327

467
ASG-Zeke Scheduling for z/OS Installation Guide

P reloading GENOPTs 305

partitions processing 309 remote dependencies 10, 131
PATH RepJGrp generation option 326
master primary command 55 RepJName generation option 326
Schedule View line command 199 RepJUser generation option 327
PathFinder rerunning a scheduled job 259, 263
adding events by path 56–58, 261 Resource Control screen 284, 288
displaying Resource Detail screen 282–283
different levels in the Resource Specification screen 281
hierarchy 251 resources
non-Zeke jobs in a path 251 checking before dispatch 10
PCOM job 87 see also logical resources, physical
PDS override, Zeke started task option 235 resources
permanent events 5, 146–154 restarting
physical resources jobs using variables 373
defining initiators to Zeke 271 Zeke 27
defining pools 277 restarting after a ZKILL 26
pools RESTORE batch utility
adding 278 setting up Z$CATAL class 388
adding a system ID 279 restoring the database 346, 388
definition 14 restricting
deleting number of jobs selected 260
a single pool 279 system availability
all pools for a system 278 initiators 273
editing retrieving
an existing pool 278 JCL for updating 198
an existing system 279 JCL from the Zeke database 83
port 422 REXX commands 202
POSIDEND 329
POWER commands 87 S
predecessors, viewing SAF 421
in Schedule View 199 schedule
on the EMR 55–56 adding a newly created job to the
prerequisites, see dependencies schedule 193
primary commands adding events by path 261
see commands event scheduling 255
primary database forecasting 15
versus secondary database 350 job scheduling 260, 264
see also database number 189
primary menu, Zeke 34 record, rerunning 259, 263
product communication 320 SCHEDADD parameter 193
scheduled job
R definition 4
RACF surrogate processing 327 displaying 193
random scheduling dates, creating calendar recreating 259, 263
for 41 status, changing 258, 262
reason codes (in Schedule View) 208 simulation 15, 189
recovery, see disaster recovery level, Schedule Control Function screen 256
electronic vaulting Schedule Control Functions screen 247, 250
recurring events 5, 145–154 schedule download
permanent events, defining 147 displaying agents 6, 81
refreshing jobs 199 setting up a job for downloading 6,
refreshing Schedule View 225 68, 81–82

468
 Index

Schedule Download Agent Specification repeating the last command

screen 338–339 entered 211
Schedule Download Agents List rerunning a scheduled job 259, 263
screen 338–339 restricting the number of jobs
Schedule Information Selection Criteria selected 260
screen 203 setting display characteristics 224
schedule queue record, definition 4 sort sequence, changing 227
Schedule View validating JCL 242
accessing ZCOM option, entering operator
event master record commands 247
information 231 ZOOM line command 12, 238, 240
online documentation 231 Schedule View Display Setup screen 228
other online information 230 Schedule View Event Add List screen 260,
PathFinder 231 264
resources for an event 221 Schedule View Record Expand Function
work center information 231 screen 223–224, 233, 236, 238, 240,
adding events to the schedule 255, 242
260, 264 Schedule View screen 227, 230
ALTER line command 197 Schedule View Sort Setup screen 226
changing Schedule View—Resource screen 217, 221
amount of storage for an Schedule View—When Conditions
event 209 screen 218
class or class list for an Schedule View—WHY screen 216
event 209 scheduling generation options 331
dispatch priority 208 SCOM jobs 88–89
number of tape drives 209 variable substitution within SCOM
number of times an event is jobs 378
dispatched 209 SECEXITW
schedule time 208 work area size 399
scheduled job status 258, 262 SECHIDE1, displaying primary records 419
sort sequence 226 SECHIDE2, displaying subordinate
system or pools 209 records 419
way JCL is submitted and secondary database
executed 210 versus primary database 350
commands 193 see also database
date format 230 security
description 12 authority levels 384
display fields 228 building a Zeke security team 382
displaying calls to ZEKE15A 384
scheduled jobs 193 sources 386
displaying SQR information 12 commands 383
event statuses 208 exit
invoking JCLPREP 237–239 SECEXITW option 399
invoking JOB/SCAN 239–241 SECFAIL
line commands 12, 193, 196, 208, 231 what to do if security
SYSJ, SYSL, and SYSM 200, fails 418
242 ZEKE15B 388, 399
maintaining JCL 232 external security
placing an operator hold on an activating ESI 416
event 259, 262 advantages over internal
primary commands 194 security 384
recreating the scheduled job 259, 263 cancelling unauthorized batch
refreshing the screen 225 job(s) 418

469
ASG-Zeke Scheduling for z/OS Installation Guide

changing the external class on the master 57

name 412 surrogate processing 327
changing the process option, SYS1.PARMLIB
internal class 413 SMFPRMxx 134
copying an ECDR 413 SYSJ, SYSL, and SYSM line
deleting an ECDR 413 commands 200, 242
displaying primary records 419 system
displaying subordinate commands 88
records 419 operating criteria, changing 15, 290
elements 406 system-dependent variables 370
ESI class definition record 416 variables 370
hard-coded calls 387 System Initiator Detail screen 273
main focus 405 System Initiator Specification screen 272,
modifying ECDRs 412 276
resource name format 406, 414– System Pool Specification screen 279
416 system-dependent variables 358
security class 405
generation options 335 T
group, overriding on JOB card 326 tape drives, calculating usage 318
implementing 382 templates
internal security creating an event from a template 63
defining logon ID to Zeke defining 62
database 398 temporary OASIS variables 369
IDs used 390 terminating
record types used 389 OASIS 28
restricting logon access 398 Zeke 29
using Zeke security 16 using STOP 29
operator commands 389 using ZKILL 29
processing logic 384, 387 ThruPut Manager interface to Zeke 457–462
securing by function 383 trace options
securing by object 382 local 336
tracing processing 389 triggering events, hold code 213
SET clause 100 tutorial, accessing Zeke ISPF online 30
IF clause within 378 TVSET function (temporary variable
simulation set) 369
running against a data space 192
schedule 15, 189 U
SMFPRMxx 134 User Color Select Screen 35
sorting Schedule View 226 user ID
SQRs 4 mixed case 404
started task overriding on JOB card 327
OASIS 343 user interface
Zeke 26, 348 generation options 336
database recovery 351
including the Zebb load V
library 320 validating JCL 232, 237
PDS override option 235 VAR and ?VAR keywords 101
terminating 29 variables
Status Report Selection Criteria screen 340 as an event prerequisite 134, 371
status, event status (in Schedule View) 208 controlling jobstream flow using
STOP command 29 variables 372
successors, viewing database 375
in Schedule View 199 deleting a variable 361
on the EMR 55

470
 Index

generation options 337 Z

in dependencies 371 Zack, managing Fastpath/Autoreply tables
OASIS, see OASIS variables from Zeke 34
originator 358, 375 ZADD command 256
overriding variable values ZCOM job 88
temporarily 369 ZCOM option 255
restarting a job using variables 373 entering operator commands 247
setting values 105 ZCOM Output screen 247
setting with VAR and ?VAR 101 Zebb
substitution load library in the Zeke started
activating variable task 320
substitution 337 Zeke
activating/deactivating 377 database creation 343
in JCL 375 multiple versions of Zeke 2
within SCOM jobs 378 restarting 27
summary of features 11 terminating 29
system-dependent variables 358, 370 using STOP 29
temporary OASIS variables 369 using ZKILL 29
triggering jobs using variables 371 Zeke "Agentless" 451–456
vaulting, see electronic vaulting Zeke Command Output Display screen 249
VCOM job 88 Zeke JCL 234
VM commands 88 Zeke JCL Override screen 234
Zeke server
W Zeke Web Services 422
WEAK conditions 129 Zeke started task 348, 351
Web Services 422 including the Zebb load library 320
for work centers 433–449 PDS override option 235
WHEN conditions terminating 29
see dependencies Zeke View Maintenance customization
WHEN/SET Clause Directory screen 144 screen 438, 440
Work Center Control Functions screen 101 ZEKE15A 384
Work Center Function screen 103 ZEKE6NOA command (Zeke Agentless
Work Center Selection Criteria screen 102, program) 452, 456
231 ZEKECAT 343
Work Center View screen 445 ZekeCtl generation option 457
work centers 96 ZEKECTL statements 458
adding or updating a variable ZEKENEW 343
value 105 ZEKEOL command 36
completing 102–103 ZEKEXUTL (import/export utility) 19
confirming variable values 106 ZENVIRN environment file 426
disabling an event 103 ZKILL
displaying variables for an event 104 restarting Zeke after 26
enabling a disabled event 103 ZKILL COLD command 29
loading the work center to SQT 334 ZKILL TRACK command 29
managing through the Web 433–449 ZKILL WARM command 29
refreshing an event 103 ZOOM, Schedule View line command
SET clause 100 using to invoke JCLPREP 238
setting up work centers 96 using to invoke JOB/SCAN 240

X
XEOJ/XEOE keywords 127, 141
XML 421
XVAR and ?XVAR keywords 101

471
ASG-Zeke Scheduling for z/OS Installation Guide

472
ASG Worldwide Headquarters Naples Florida USA | asg.com

CD Contents