Zeke 6.0 Users Guide PDF

ASG-Zeke Scheduling for z/OS
Users Guide
Version 6.0
Publication Number: AZM0200-60
Publication Date: September 2012
The information contained herein is the confidential and proprietary information of Allen Systems Group, Inc. Unauthorized use of this information and disclosure to third parties
is expressly prohibited. This technical publication may not be reproduced in whole or in part, by any means, without the express written consent of Allen Systems Group, Inc.
Copyright 2012 Allen Systems Group, Inc. All rights reserved.
All names and products contained herein are the trademarks or registered trademarks of their respective holders.
ASG Worldwide Headquarters Naples Florida USA | asg.com | 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x
Publication Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xi
Worldwide Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Intelligent Support Portal (ISP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii
Product Support Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii
ASG Documentation/Product Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiv
Chapter 1:
Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Zeke Processing (Multisystem Support) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Facilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2
2
3
Event Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Event Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Event Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Event Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Schedule Monitoring and Intervention . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schedule View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operator Commands (ZCOM Option) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Job Restart/Rerun . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workload Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
13
13
14
14
14
15
Configuration and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Database Maintenance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
16
16
17
Batch Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ZEKE Batch Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
ASG-Zeke Scheduling for z/OS Users Guide
Auditing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
ZEKESET Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
ZEKEXUTL Import/Export Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Zeke Interfaces to other ASG Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z Products. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cross-platform Schedule Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JCL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Workload Analysis and Planning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ASG-Automation Center (Problem Tracking Support) . . . . . . . . . . . . . . . . . . . . . . . . .
ASG-Cortex-Pdb Plug to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 2:
20
20
21
22
22
23
23
Starting Zeke and Using the Online Facility. . . . . . . . . . . . . . . . . . . . . 25

Starting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Restarting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Starting OASIS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Starting Multiple Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Terminating OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Terminating Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Using the ISPF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISPF Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Screen Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Logging On and Off . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Changing the ISPF Color Scheme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
32
33
33
36
Starting the Zeke Online Facility under TSO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Chapter 3:
Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Calendar Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Accessing the Calendar Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
Standard Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Special Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
User Accounting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Calendar Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Maintaining Scratch Pad or Note Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Chapter 4:
Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Event Master Record (EMRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Event Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
EMR Primary Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
ii
Contents
Specifying Generic Selection Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Accessing the Event Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Adding an Event Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Updating an Event Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Defining an Event Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Creating an Event From a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Copying an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Defining a Job Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Defining a Message Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Defining a Command Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Defining a REXX Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Defining a Recurring or Permanent Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Defining a Milestone Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Using Scheduling Environments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
OCCURS Clause Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sample OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scheduling Events on Holidays and Weekends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining an OCCURS Clause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
107
107
115
118
121
WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Job and Program WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WHEN Conditions for Multiple Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Extended Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WEAK Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
NOTDURING Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Cross-platform Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Generic Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Multiple WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Specifying Started Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Zeke Variables as WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
WHEN Condition Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining a WHEN Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing WHEN Conditions for All Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . .
124
124
124
124
126
127
129
130
130
131
131
133
139
140
Condition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Defining Condition Codes for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Variables in Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Completing Work Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
149
150
151
155
Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

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

Maintaining Dataset Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Viewing Event Accounting Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
Maintaining Job Duration Statistics, Alerts, and Failures. . . . . . . . . . . . . . . . . . . . . . . 174
Chapter 5:
Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 181

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

Early Warning Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
/ZCOM Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Modifying PF Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Manually Adding Events to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the ZADD Operator Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using the ADD Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding Events By Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 6:
247
247
249
252
Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
Physical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Initiator Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
Defining Pools. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
iv
Contents
Logical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining a Logical Resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Defining Resources for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting Resources for an Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 7:
271
272
274
277
Customizing and Maintaining Zeke. . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Zeke Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GENOPTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing the Zeke Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Adding a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Editing a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Viewing Pending GENOPT Updates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Deleting a GENOPT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reloading GENOPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Audit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dispatching Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Exit Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
General Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JCL Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Message Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Scheduling Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Security Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Trace Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
User Interface Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Variables Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
280
280
281
287
290
291
293
295
296
297
309
309
312
319
320
324
325
325
326
Defining Schedule Download Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Obtaining Operating Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 329
Chapter 8:
Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating the Zeke Databases (Primary and Vault) . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Backing Up the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Restoring the Zeke Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Moving the Vault Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Recovery Using Electronic Vaulting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
330
331
333
334
337
338
Continuous Job Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Terminating Zeke using ZKILL TRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SMF Recording Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applying Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SMF Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
340
341
341
344
344
Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345
Zeke Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Naming Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting Zeke Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Maintaining Variable Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
346
346
346
351
v
OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Naming OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Setting OASIS Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Temporary OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
355
357
357
358
System-dependent Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Uses for Zeke Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Variables to Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Variables to Control Jobstream Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Using Variables to Restart a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Substituting Variable Values in JCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
IF Clauses On SET Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Variable Substitution in SCOM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Chapter 9:
359
360
361
362
363
366
366
Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369
Preparing for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370
Zeke Security Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Security Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372
Security Tracing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 376
Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Internal Security Terms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Online Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operator Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Class Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Batch Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementing Internal Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
377
377
378
379
379
380
380
380
External Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Security Classes and Resource Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 393
Implementing External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 398
Chapter 10: Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Web Services Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407
Accessing Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 408
Setting Zeke Web Services as Your Home Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 409
Managing Work Centers from the Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessing Scheduled Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Creating and Maintaining Custom Views . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Completing a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enabling or Disabling a Work Center . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Refreshing a Work Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
409
409
412
418
423
424
Appendix A: Zeke Agentless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

vi
Contents
System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

Installation and Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426
JCL Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 428
ZEKE6NOA Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 430
Appendix B: Interface to ThruPut Manager. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431

Enabling the ThruPut Manager Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 431
ZEKECTL Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 432
Zeke Names. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 433
ThruPut Manager Descriptors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
$ZEKE_JECL_OK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 436
Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
vii
viii
Preface
This ASG-Zeke Scheduling for z/OS Users Guide explains the procedures for using
ASG-Zeke Scheduling (herein called Zeke) for enterprise-wide workload management.
This guide assumes that the appropriate components have been installed at your site.
About this Publication

This publication consists of these chapters:
Chapter 1, Introducing Zeke, introduces you to the basic concepts of using Zeke.
Chapter 2, Starting Zeke and Using the Online Facility, explains how to start and
log on to Zeke.
Chapter 3, Calendars, describes the various types of calendars and how to use
them.
Chapter 4, Events, explains the components of an event master record (EMR) and
how to create and modify them.
Chapter 5, Creating and Monitoring the Schedule, provides sample JCL for
creating the daily schedule and explains how to monitor the schedule with Schedule
View or using the ZCOM function, and intervene, if necessary.
Chapter 6, Resources, explains the differences between physical and logical

resources and how to use both for more efficient job processing.
Chapter 7, Customizing and Maintaining Zeke, explains how to create and

maintain the Zeke database (as well as providing procedures for the most
commonly changed generation options).
Chapter 8, Variables, describes the different types of variables and provides

examples.
Chapter 9, Security, provides conceptual and procedural information for both

internal and external security.
Chapter 10, Zeke Web Services, explains how to use Zeke Web Services (which
enable you to access to work center functions from a Web browser instead of
requiring you to establish access to Zeke through an online facility).
ix
E-mail User Forum

To share information, ask questions, receive tips, or compare notes, consider joining the
Zeke e-mail user group, Autoops. It is easy to join and, if needed, easy to unsubscribe.
To subscribe to Autoops
Visit the Autoops Info Page at http://usdenlist.asg.com/mailman/listinfo/autoops

and complete the form under Subscribing to Autoops.
After your request is received, you will receive an e-mail confirming your membership.
As a member, you will receive a copy of all new messages sent by other members of the
group. An archive of past messages is also available on the Autoops Info Page.
Related Publications
The documentation library for Zeke consists of these publications (where nn represents
the product version number):
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 Users Guide (AZM0200-nn) explains the

procedures for using Zeke for enterprise scheduling.
ASG-Zeke Scheduling for z/OS Installation Guide (AZM0300-nn) defines Zeke

system requirements, provides instructions for installing Zeke, and explains the
optional features you can activate after installing Zeke.
ASG-Zeke Scheduling for z/OS Reference Guide (AZM0400-nn) provides a

reference for using Zeke batch programs and operator commands, and for
generating reports.
ASG-Zeke Scheduling Messages and Codes Guide (AZM1200-nn) lists the Zeke
messages, describes their meanings, causes, and resolutions, and provides return
code explanations.
ASG-OASIS for z/OS Enhancement Summary (AZO0100-nn) describes new

OASIS features, updated functions, and performance improvements.
ASG-OASIS for z/OS Installation Guide (AZO0300-nn) provides information on

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

OASIS commands, options, and other functions.
Preface
ASG-OASIS Messages and Codes Guide (AZO1200-nn) lists and explains OASIS
messages. It also provides return code explanations.
Note:
To obtain a specific version of a publication, contact ASG Customer Support.
Publication Conventions
ASG uses these conventions in technical publications:
Convention
Usage
Arrow ( )
Used in a procedure to indicate commands within menus.

Also used to denote a one-step procedure.
Bold
Indicates that case-sensitive usage is required for a directory, path,

file, dataset, member, database, program, command, or parameter
name.
Verify the settings in the asg.conf file.

Capitalization
For system element names, this varies according to the product

interface and its operating environment.
Mainframe file names use uppercase, for example:
Allocate a JSOPTEM member in the JLRCL library.

Windows file names use mixed case, for example:
Create a text file named SECLIST.txt in the

C:\Program Files\ASG\config directory.
UNIX file names use mixed case, for example:
Edit the databaseID.ACC file in the /database directory.

Typical product and operating system elements include:
Directory, path, file, dataset, member, database, program,
command, and parameter names.
Window, field, field group, check box, button, panel (or screen),
and option labels.
Names of keys. A plus sign (+) is inserted for key combinations
(e.g., Alt+Tab).
xi
Convention
Usage
lowercase italic
monospace
Information that you provide according to your particular situation.

For example, you would replace filename with the actual name of
the file.
Monospace
Characters you must type exactly as they are shown (e.g., code, JCL,
file listings, or command/statement syntax).
Also used for denoting brief examples in a paragraph.
Underline
Denotes a cursor-selectable field or line.
Vertical separator bar ( | )

with underline
Indicates options available with the default value underlined

(e.g., Y|N).
Worldwide Customer Support

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

The ASG Intelligent Support Portal (ISP) provides online support at http://isp.asg.com.
Log on to the ISP with this information:
Customer ID = NNNNNNNNN
Password = XXXXXXXXXX
xii
Preface
where:
NNNNNNNNN is your customer ID supplied by ASG Product Distribution.
XXXXXXXXXX is your unique password supplied by ASG Product Distribution.
If you do not have your logon information, contact your local support center.
This table outlines the support response times you can expect:
Meaning
Expected Support
Response Time
Production down, critical situation
Within 30 minutes
Major component of product disabled
Within 2 hours
Problem with the product, but customer has

work-around solution
Within 4 hours
How-to questions and enhancement requests
Within 4 hours
Severity
Product Support Policy

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

Submit all product and documentation suggestions to ASGs product management team
at http://www.asg.com/asp/emailproductsuggestions.asp.
Include your name, company, work phone, e-mail ID, and the name of the ASG product
you are using. For documentation suggestions, include the publication number located on
the publications front cover.
xiv
Chapter 1:
Introducing Zeke
1
This chapter provides an overview of Zeke and contains these topics:
Topic
Introducing Zeke
OASIS
Zeke Processing (Multisystem Support)
Online Facilities
Page
2
2
2
3
Event Management
Event Terminology
Event Scheduling
Event Dispatching
Event Activity Accounting
3
4
8
9
12
Schedule Monitoring and Intervention

Schedule View
Operator Commands (ZCOM Option)
PathFinder
Job Restart/Rerun
Web Services
Workload Management
12
13
13
14
14
14
15
Configuration and Maintenance

Generation Options
Database Maintenance
Security
16
16
16
17
Batch Utilities
ZEKE Batch Utility
Report Writer
Auditing
ZEKESET Utility
ZEKEXUTL Import/Export Utility
17
17
18
18
19
20
Zeke Interfaces to other ASG Products

Z Products
Cross-platform Schedule Management
JCL Validation
Workload Analysis and Planning
ASG-Automation Center (Problem Tracking Support)
ASG-Cortex-Pdb Plug to Zeke
20
20
21
22
22
23
23
1
Introducing Zeke
You use Zeke to define and maintain the database of events (i.e., computer processes)
that run in your data center.
Zeke automates your production workload by dynamically scheduling and dispatching
events. It monitors all aspects of your processing schedule to optimize performance and
efficiency, while also providing you with data processing control and flexibility.
Zeke is supported on z/OS and VSE operating systems and extends its functions to many
other distributed platforms.
OASIS
OASISOpen Architecture System Integration Solutionis the subsystem that provides
the common functions for your ASG enterprise workload management Z products.
OASIS/Distributed Management Server (DMS) enables Zeke to communicate with other
Zekes running on different systems or platforms, as well as enabling cross-platform
scheduling (see Cross-platform Schedule Management on page 21).
Zeke Processing (Multisystem Support)

Database Sharing
Zeke can schedule up to 24 computer systems from a single Zeke database (any
combination of VSE, CMS, and z/OS systems can share a database). This capability
enables multiple operating systems to communicate about events occurring on one
system that might affect events on other systems.
All Zeke systems that share the same database register at startup and check out on
termination. When a system becomes active again, recovery is automatic.
See the ASG-Zeke Scheduling for z/OS Installation Guide for more information.
PolyZeke
OASIS enables multiple copies or versions of Zeke to operate on a single z/OS operating
system. PolyZeke facilitates testing a new release on a single CPU or supporting multiple
users with separate Zeke databases.
1 Introducing Zeke
Note:
Although multiple Zekes (at the same release level) can reference the same database,
ASG strongly recommends that multiple Zekes running on the same system each have a
separate database.
With a second subsystem, you can test a new PTF or release level on the same CPU
during normal working hours without affecting the production environment and without
terminating other applications. The second subsystem enables the same applications to
access more than one database.
By providing users with a separate Zeke database to decentralize Zeke, you can prevent
users from accessing, or possibly corrupting, other production databases.
Online Facilities
Zekes online facility is a full-screen, menu-driven system that makes schedule
management easy. The Zeke online facility runs under these environments:
CICS
IDMS
CMS
TSO
ROSCOE
ISPF
Zeke provides full security for its online facility and allows authorized only users to
access the scheduling database. You can set up different levels of access for each
authorized operator. See Security on page 17 for more information.
Event Management
You can define events to the Zeke database through the Zeke online system or using the
ZEKE batch utility program. The database retains this information about each event:
Detailed scheduling information (i.e., OCCURS clause)
Prerequisite conditions (i.e., schedule time and WHEN conditions)
Resource requirements (i.e., number of tape drives and, initiator class)
This information ensures that Zeke schedules the event properly and does not dispatch the
event until the prerequisites have occurred and the required resources are available.
Zeke provides a wide range of options for defining events and controlling how they are
managed and processed.
Event Terminology
This section provides an overview of some of the key concepts related to Zeke events.
Event Types
These are the Zeke event types:
Type
Description
JOB
Batch jobstream
MSG
Console message
WORK
Work center (i.e., an offline task that triggers other system-related events)
VCOM
VM/CP command
ZCOM
Zeke operator command
SCOM
System command or system response.
PCOM
(VSE only) POWER command
REXX
(z/OS only) REXX EXEC
Event Master Records (EMRs)

Zeke reads and interprets the event definitions in the Zeke database, which are known as
event master records (EMRs). You can create EMRs from scratch or from a template or
copy of another event. The EMR contains information such as the date the event is to be
scheduled, prerequisite conditions for dispatch, and resource requirements. Zeke uses
these records to create the daily schedule.
See Event Master Record (EMRs) on page 52 for more information.
1 Introducing Zeke
Schedule Queue Records (SQRs)

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

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

You can define an event to occur multiple times within the same schedule run. These
events are referred to as recurring events. You define the frequency or time interval and
the specified number of times. You can set a recurring event to trigger another event each
time it runs, or you can set it to trigger only on the first or last occurrence.
A permanent event is never removed from the schedule, so it is always available to
respond to triggers (even during schedule load processing). The event occurs across every
schedule period until you deactivate it.
A milestone event is a significant event in a job flow (in which events have
predecessor/successor relationships) that must process on time to avoid a significant
delay in the completion of the entire flow. Events flagged as milestones are not processed
any differently than other events; this flag is simply a way to easily identify events that
you consider to be milestones in a job flow.
See Defining a Recurring or Permanent Event on page 97 and Defining a Milestone
Event on page 102 for more information.
Critical Path
Milestone events are an essential element in the concept of a critical path. The critical
path is the sequence of predecessor/successor events that will take the longest to
complete. The critical path represents the minimum amount of time to complete the event
flow from the event with the earliest start through the event that finishes last.
The critical path could change from time to time as events are completed ahead of or
behind schedule. Typically, delays along the critical path imply that additional time is
required to complete the event flow. This information helps you monitor the completion
of the current schedule to ensure there is no conflict with the start of the next schedule.
Nonexecutable Events
You can define an event as nonexecutable, simply to use it as a predecessor to other
events. Zeke schedules nonexecutable events just like any other event, but never submits
the event to JES for JCL execution. After dispatching the event, Zeke automatically
updates its status to Success and triggers any dependent events.
From the EMR or Schedule View, or using a Zeke operator command, you can flag an
event in an intricate event flow as nonexecutable without having to change the event
flow. This action helps to eliminate the need to delete an event and change all of its
successors prerequisites.
Remote Job Events

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

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

Zeke enables you to download a subset of scheduled jobs in the Zeke schedule
cross-platform to ASG-Zeke Agent (herein called Zeke Agent), which then tracks and
dispatches the SQRs in the same manner as Zeke. Zeke Agent satisfies the time and
WHEN conditions for the downloaded jobs and dispatches the jobs when those
conditions are met. The downloaded schedule can run stand-alone on Zeke Agent, even
when the OASIS/DMS connection to Zeke is interrupted, as long as Zeke Agent can
satisfy the predecessors for the SQR locally.
Zeke also can schedule an individual event directly to a Zeke Agent system running on
another platform. Zeke Agent can receive, track, schedule, execute, and reroute a
scheduled job from Zeke (or another source) to another platform in your enterprise, as
necessary.
See Downloading a Job Event to Zeke Agent on page 83 for more information.
1 Introducing Zeke
On-Request Events
You can define on-request events in the Zeke database, which enables you to add them to
the schedule (as needed) using an operator command. Zeke dispatches these events as if
they were scheduled normally (including checking prerequisites and resource
requirements).
JCL Sources
Zeke provides simultaneous support for multiple JCL libraries. Zeke can retrieve JCL
from any of these sources:
Bim-Edit
CA Driver
CA Librarian
CA Panvalet
CA Vollie
Condor
JCLMAN
ICCF
OWL
VM/CMS file
VSE/POWER SLI
Zeke JCL
Event Documentation
Zeke enables you to provide full documentation of an event through these facilities:
Text facility (which retains a sizeable amount of text)
Scratch pad and note facilities (which provide an easy method for leaving short
notes for an operator)
Dataset facility (which displays the volume serial numbers and datasets required to
run a job)
See Event Documentation on page 164 for more information.
Work Centers
Zeke enables you to define associated offline tasks, called work centers, and schedule
their completion by relating them to online tasks and integrating them with processes
occurring throughout the Zeke system.
When you create a work center, you associate it with a user ID, which specifies the
operator responsible for completing or validating the offline task. You can issue a Zeke
operator command or run a batch report to list the scheduled work centers by user ID.
When an operator flags the event as completed, Zeke removes it from the display, sets
any variables (as necessary), and triggers any dependent events.
See Work Centers on page 149 for more information.
Event Scheduling
Zekes 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 days completed events and adds the current days events. Zeke
adds an event to the schedule if the scheduling criteria are met or when it receives an
operator request.
See Chapter 4, Events, on page 51 for more information.
Calendars
Calendars enable you to customize your processing schedule. You simply set up one or
two standard calendars to distinguish among workdays, weekends, and holidays.
Typically, one standard calendar is all you need for most events; however, you also can
create user accounting calendars to tie events to the periods of your accounting year and
special calendars for those events with random scheduling criteria.
Zeke provides predefined calendars that accommodate most scheduling situations
(including perpetual calendars that enable you to define dates far into the future).
See Chapter 3, Calendars, on page 39 for more information.
Schedule Time
Schedule time is an optional dispatching prerequisite that must be met before a scheduled
event can be dispatched. You specify schedule time options in the EMR (see Time
Requirements on page 9).
1 Introducing Zeke
Logical Day (DaySpan)

Zeke supports a 48-hour clock, which enables you to schedule according to a logical day
(known as DaySpan). If you have events that run past midnight, you still can consider
those events to be part of the previous days schedule run.
When the SCHEDULE function runs, it selects every event within 48 hours to be part of
the days schedule. For example, if the schedule runs on Monday at 08:00, Zeke selects
each event that has an OCCURS clause that matches Monday and a schedule time
between 00:00 and 47:59.
Zeke nevers dispatches an event with a schedule time of 48:00 because 47:59 is the
dispatching cutoff time. You can use a schedule time of 48:00 for events that you want to
place in the schedule, but do not want to dispatch except by operator command.
See Logical Day (48-hour Clock) on page 182 for more information.
OCCURS Clauses
Zeke determines when to add an event to the schedule based on the events OCCURS
clause. The OCCURS clause contains keywords (e.g., DAILY, WORKDAYS,
MONDAY, JANUARY, WEEKENDS, and HOLIDAY) that indicate when to schedule
the event.
See OCCURS Clauses on page 107 for more information.
Event Dispatching
Zeke monitors system activities to detect actions that will trigger an event. When an
events 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 Specifying a Schedule Time on page 73 for more information.
WHEN Conditions
Similar to an OCCURS clause, a WHEN condition is a statement containing keywords
that indicate prerequisites that Zeke must validate before dispatching a particular event.
Zeke can make dispatching of an event contingent on any combination of these
circumstances:
Normal or abnormal end for these occurrences:
A job
A job step
A program
An event
A group of events
Beginning of a job or program
Close of an output dataset
Current execution of a job or program
Availability of variables or resources
Cross-platform Scheduling Dependencies

Zeke provides cross-system triggering by enabling certain WHEN conditions to be
satisfied based on remote jobs. Cross-platform scheduling dependencies are prerequisites
that are satisfied based on a job that runs on a remote system (i.e., a Zeke system or
another scheduler, such as ASG-Zena).
Extended Dependencies
Two WHEN conditions, XEOJ and XEOE, provide the ability to trigger jobs across
multiple schedules. For example:
JOB_A is dependent on JOB_B (which ran a few weeks ago).
You can use the XEOJ keyword to locate JOB_B in the Zeke database and
determine whether it has run since the last time JOB_A ran.
10
1 Introducing Zeke
See WHEN Conditions on page 124 for more information.
Resource Checking
Zeke checks resource requirements and availability before dispatching an event.
You define physical resources (e.g., number of tape drives and initiator class) in the
EMR. You define logical resources in the Zeke database.
Zeke enables you to specify the days and times each initiator is available for processing
and then dynamically selects the systems and initiators to use. Zeke also compares
resource names across systems to prevent an excessive number of events from using the
same resource.
As required, Zeke also ensures that the correct number of tape drives are available before
dispatching an event.
See Chapter 6, Resources, on page 257 for more information.
Condition Code Validation

Through SMF, Zeke checks and validates individual job and step-level condition codes
during job processing to determine whether a job should be cancelled or marked as
abended based on the condition codes (or return codes). You define an unlimited number
of condition codes for an event in the EMR through the online facility.
See Condition Codes on page 143 for more information.
Variables
Zeke automates variable calculation and substitution. You can use variables to perform or
enable a variety of specialized operations automatically:
Controlling jobstream flows (i.e., bypassing segments)
Triggering other events
Preventing other events from occurring
Documenting cancellation reasons
Substituting values in z/OS and JES JCL statements at execution time
Automating JCL modifications
Triggering event scheduling and dispatching
Responding to console data
11
You can use OASIS variables in the same areas as Zeke variables. Because they reside in
an OASIS database on DASD, OASIS variables are retained across system outages and
IPLs. Because the OASIS database is accessible to all of your Z products that use the
same subsystem, you can use OASIS variables to communicate information between
your Z products. OASIS has its own online facility for maintaining variables. See the
ASG-OASIS for z/OS Reference Guide for more information.
See Chapter 8, Variables, on page 345 for more information.
Auto Replies
Automatic replies (i.e., auto replies) enable you to predefine responses and then respond
automatically to outstanding messages from your Zeke events that have static or
predictable responses, or job events that require intervention. When a message is issued,
Zeke responds to the console read with the predefined reply (substituting any variables
before the reply is issued).
See Auto Replies on page 159 for more information.

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

After your events are defined to Zeke, you are ready to create the schedule. You can
monitor the progress of your scheduled events, as well as intervene and make changes,
through the ISPF online Schedule View function.
See Chapter 5, Creating and Monitoring the Schedule, on page 181.
12
1 Introducing Zeke
Schedule View
Schedule View, available only through ISPF, displays all relevant information for the
currently scheduled events on a single screen and highlights exceptions automatically.
From this display, you can monitor and make changes using simple line commands. (You
also can issue Zeke operator commands from Schedule View.)
You can choose color schemes for your displays, select the screen update interval, and
determine your own field column layout, sort sequences and selection criteria. Changes to
display characteristics are valid for the current user and are saved in the users ISPF
profile. Each user can set up Schedule View according to their preferences.
The ZOOM feature enables you to view or edit the information in the EMR that was used
to build the SQR for a selected event.
Note:
Any changes you make to a SQR are temporary and only for the current schedule run (no
changes are made to the EMR).
For jobs, you can display messages from a jobs 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 events schedule
entry for subsequent runs.
See Using Schedule View on page 191 for more information.
Operator Commands (ZCOM Option)

Zeke provides a full range of operator commands to monitor schedule processing and
intervene, as necessary. You can issue Zeke operator commands through any authorized
operating system console (similar to JES commands), or through the ZCOM option in the
online facility. These are some of the common operations that you can perform using
Zeke operator commands:
Add an event to the schedule
Delete an event from the schedule
Display or update information for a scheduled event
Override or validate JCL
Display event statuses, predecessor and successor events, and remote prerequisites
Provide an operator approval
Enable or disable a scheduled event, or refresh an event
13
Place a hold (on an event, an initiator, or the Zeke system), or release a hold
Display database information, or disable electronic vaulting
Display information about an initiator, or update its availability
Display, enable, or disable automatic replies
Display information on variables, or set a value
Display generation options, or reload updated options
Display tracing messages
Terminate Zeke
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using
the ZEKE batch utility.
PathFinder
PathFinder shows all predecessor and successor relationships for any given event. This
display is accessed through Schedule View (available through ISPF only) or by issuing a
Zeke operator command. You can analyze at a glance what needs to occur before a job
can run and what will happen after it runs. Additionally, PathFinder can help you uncover
predecessor loop conditions.
See PathFinder on page 241 for more information.
Job Restart/Rerun
You can specify the necessary restart parameters (including what type of restart should be
performed after the restart package's database is updated).
See ASG-Zebb (Automated Job Restart/Rerun) on page 21 for more information.
Web Services
Web Services enable you to access to work center functions from a Web browser instead
of requiring you to establish access to Zeke through an online facility (e.g., TSO or ISPF)
or an OpsCentral client. Web Services takes advantage of the Zeke server to enable
remote access to Zeke from a Web browser using Hypertext Transport Protocol (HTTP).
Access to Zeke through a Web browser can be secured (i.e,. through SAF) or unsecured
(i.e., controlled based only on the default operator ID).
See Chapter 10, Zeke Web Services, on page 407 for more information.
14
1 Introducing Zeke
Workload Management
Whether you have one system, or multiple systems worldwide, Zeke optimizes your
workload by providing workload balancing and efficiency.
Zeke provides effective real-time, logical and physical resource management and control
(see Resource Checking on page 11).
Logical Pooling. Multiple CPUs (real and virtual) can share a single Zeke database.
Each event is owned by one of the systems sharing the database. Sometimes an event is
not limited to just one system. For those events, you can define a group of systems,
known as a pool. Zeke selects the system to be used for each event based on the system or
pool defined for the event and also selects the initiator within that system.
See Chapter 6, Resources, on page 257 for mor information.
Scheduling Environments. Zeke supports IBM Workload Manager (WLM)
scheduling environments for dispatching all Zeke event types. You can define Zeke as a
resource in a WLM scheduling environment.
See Chapter 6, Resources, on page 257 for mor information.
Continuous Tracking. Zeke can track certain relevant system and event activity, even
during periods when both Zeke and the OASIS subsystem have been terminated (e.g., to
apply maintenance). These are the types of activity that Zeke tracks in recording mode:
Starting of jobs, job steps, and programs
Ending of jobs, job steps, and programs
Datasets that are closed
When it restarts, Zeke uses the recorded activities to update the schedule, as appropriate
(e.g., Zeke satisfies triggers for jobs that completed while Zeke and/or OASIS were
inactive).
See Continuous Job Tracking on page 340 for more information.
Forecasting and simulation. Simulation creates a forecast of your schedule to
uncover any missing prerequisites and help you plan a logical schedule flow. Simulation
performs many of the same functions as Zeke (e.g., specifying tape drive and initiator
quantities, reporting, and message generation) without affecting the actual schedule.
See Forecasting and Simulating the Schedule on page 187 for more information.
15
Configuration and Maintenance

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

Note:
ASG recommends you use the BACKUP command of the ZEKE utility program to
back up your database at least daily.
Moving or enlarging a database.
Recovering from a hardware failure.
Recovering the contents of a destroyed database.
Running Zeke using electronic vaulting.
For an existing database, you can generate a database status report that provides details
about the database (e.g., its size and event capacity, and the dates it was created, last
backed up, and last restored).
See Database Maintenance on page 330 for more information.
16
1 Introducing Zeke
See the ASG-Zeke Scheduling for Z/OS Reference Guide for details on using the ZEKE
batch utility for performing database maintenance tasks.
Disaster Recovery
As part of a disaster recovery plan, electronic vaulting provides the ability to allocate a
secondary DASD unit and maintain a copy of the Zeke database that is no more than one
I/O behind the primary database. When Zeke writes a record to the primary database, the
electronic vaulting option writes a duplicate record to the secondary vault dataset.
Security
You can define Zeke security using its internal security function or through the OASIS
External Security Interface (ESI). Zekes versatility enables you to control access to Zeke
objects and functions from another vendors security product, or your own, as long as the
product uses the System Authorization Facility (SAF) interface. You even can use a
combination of internal and external security packages. ASG recommends that you
understand Zeke internal and external security features completely before implementing
either (or both).
Zeke supports SAF security through the OASIS/External Security Interface (ESI). ESI
provides the ability to use a third-party security product (e.g., RACF or CA-ACF2) to
control access to Zeke or other installed OASIS-supported Z products.
See Chapter 9, Security, on page 369 for instructions on implementing Zeke security.
See the ASG-OASIS for z/OS Reference Guide for more information on ESI.
Batch Utilities
This section describes the Zeke batch utility programs.
ZEKE Batch Utility

The ZEKE batch utility provides batch functions that enable you to perform these Zeke
scheduling and maintenance tasks:
Scheduling tasks:
Create the daily schedule.
Generate schedule reports.
Create a simulation of the Zeke schedule.

17
Maintenance tasks:
Create, back up, and restore the Zeke database (or restore an individual EMR
from a backup file), or generate a database status report.
Add, update, and delete calendars.
Add, update, and delete event definitions.
Add and delete local GENOPTs (and update specific field values).
Copy documentation or JCL from an outside source into the Zeke database.
Update your customer ID or Zeke password.
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
Report Writer.
Auditing
Zeke tracks database activity and logs the information. You define the actions be logged
through the Zeke generation options.
You can generate audit reports using the AUDIT utility.
These are the types of actions that you can have audited and logged:
18
Operator commands that are issued from the console and the online facility
1 Introducing Zeke
Changes to any of these elements:
Event status
Variable value
EMR
SQR
Internal security operator or class record
Calendar record
External security class definition record
Resource definition record
Pool record
Generation option
Your company name or address
Password
See Audit Options on page 296 for more information on setting audit options. See the
ASG-OASIS for z/OS Reference Guide for more information on using the AUDIT utility.
ZEKESET Utility
You can control jobstream flow by using the ZEKESET utility to perform these tasks:
Set variables
Set the step condition code
Set a user abend code
Execute Zeke operator commands
Execute z/OS commands, JES commands, or VM commands
The ZEKESET batch utility enables extensive date manipulation and calculation using
Zeke variables, which provides the ability to create any desired format based on dates.
When used together with variable substitution, this utility can automatically create
program date cards.
19
ZEKEXUTL Import/Export Utility

Zeke provides import/export facilities to ease migration across Zeke implementations or
move from test to production environments. You use the import/export utility program
ZEKEXUTL to perform these procedures:
Export these types of Zeke database records as XML data:
Event master records (EMR)
Variable records (VAR)
Calendar records (CAL)
Import event, variable, and calendar XML records into the Zeke database.
Change key values in the records being imported or exported.
Filtering control statements enable you to select which records to import or export.
Change control statements enable you to change fields within the records being imported
or exported.
Zeke Interfaces to other ASG Products

Zeke extends its workload management functions by providing interfaces with several
additional ASG products.
Z Products
These are the OASIS-supported, enterprise workload management, or Z products.
ASG-Zack (Automated Operations)

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

ASG-Zara is an online media management system which secures, audits, and monitors
valuable IT data in a z/OS environment, while providing real-time access to tape
management data.
20
1 Introducing Zeke
ASG-Zebb (Automated Job Restart/Rerun)

The Zeke online facility can interface with ASG-Zebb (herein called Zebb) or third-party
restart package through Schedule View. You can then specify the necessary restart
parameters (including what type of restart should be performed after the restart package's
database is updated). Zeke uses OASIS to communicate event changes (additions,
deletions, and SQR status changes) to Zebb so that Zebb can make the appropriate
changes to its database. Likewise, Zebb uses OASIS to communicate back to Zeke.
Cross-platform Schedule Management

These ASG products extend Zekes cross-platform schedule management capabilities.
Zeke Agent
Zeke Agent provides a mainframe-centric approach to enterprise scheduling and enables
cross-platform schedule downloading.
You can download a subset of scheduled jobs in the Zeke schedule (across platforms) to
Zeke Agent, which then dispatches and tracks the SQRs in the same manner as Zeke.
Zeke Agent satisfies the time and WHEN conditions for the downloaded jobs and
dispatches the jobs when those conditions are met. The downloaded schedule can run
stand-alone on Zeke Agent (even when the OASIS/DMS connection to Zeke is
interrupted) as long as Zeke Agent can satisfy the predecessors for the SQR locally.
Zeke also can schedule and dispatch specified job events to be sent one at a time to a Zeke
Agent running on another platform. Zeke Agent can receive, execute, track, and even
reroute the jobs from Zeke (or another source) to another system, as necessary.
Note:
See Appendix A, Zeke Agentless, on page 425 for details on how to run Zeke jobs on
other platforms without implementing DMS or a Zeke Agent on the target system.
ASG-Zena
Zeke communicates via Zeke Agent for Windows with ASG-Zena (herein called Zena),
the distributed workload management and process automation solution.
Zeke uses Zeke Agent to communicate any cross-platform job dependencies to Zena. A
Zeke job can have a WHEN condition that is based on the status of Zena job or process.
Likewise, Zeke jobs can trigger jobs scheduled on Zena. Refer to your Zeke Agent and
Zena documentation for more information on how cross-platform job dependencies are
defined and satisfied.
21
ASG-OpsCentral
ASG-OpsCentral (herein called OpsCentral) enables centralized management of
enterprise scheduling workloads from a client workstation. The ASG-Zeke Scheduling
Plug-ins for OpsCentral maintain communication between your Zekes and OpsCentral
and enable Zeke functions to be available under the OpsCentral client console.
JCL Validation
Zeke provides several ways to scan the JCL associated with your jobs events for
accuracy. These ASG products provide JCL validation services:
ASG-JCLPREP
ASG-JCLPREP (herein called JCLPREP) interfaces with Zeke through the Schedule
View line command JPREP. JCLPREP also can be invoked while editing the event JCL
from the Schedule View ZOOM display by issuing the JCLPREP edit macro FPREP.
ASG-JOB/SCAN
ASG-JOB/SCAN is a JCL validation and standards enforcement tool that helps single
LPAR data centers (with COBOL or Assembler expertise for JCL standards programs)
operate an error-free production JCL environment. Maintaining JCL through its lifecycle
is vital to any IT operation, but especially when running mission-critical applications
driven by JCL on z/OS. Using ASG-JOB/SCAN, you can eliminate costly reruns, meet
service level agreements, automatically enforce site standards, reduce backlog at
production turnover, and improve the overall JCL maintenance cycle.
Zeke interfaces with ASG-JOB/SCAN using the Schedule View line command JSCAN.
ASG-PRO/JCL
ASG-PRO/JCL is an advanced JCL validation and standards enforcement tool that helps
multiple LPAR data centers (with REXX expertise for JCL standards programs) achieve
and operate an error-free, standardized, and optimized production JCL environment.
Workload Analysis and Planning

These ASG products provide workload analysis and planning.
22
1 Introducing Zeke
ASG-Workload Analyzer
ASG-Workload Analyzer is a PC-based analysis tool that tracks and analyzes batch
processing performance, detects problem areas, and presents an analysis of processing in
a graphic format that is easy to understand. Workload Analyzer reduces the need for
time-consuming data analysis. Specifically, it displays executed jobs and identifies where
jobs were abended or where time was lost. It graphically captures job runtime data from
SMF, thereby expediting analysis of processing trends, resolving bottlenecks, and
improving operational productivity in a z/OS environment.
ASG-Workload Planner
ASG-Workload Planner helps you to better understand complex schedules from a variety
of mainframe scheduling systems. Workload Planner extracts information from a
scheduling system database and translates it into interactive, comprehensive or
specialized graphic flowcharts of your workflow, including ones that predict the
performance of schedule processing.
ASG-Automation Center (Problem Tracking Support)

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

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

Online Facility
This chapter explains how to start and terminate Zeke and OASIS. It also describes the
ISPF interface to Zeke and explains how to access and exit the Zeke online system. It
contains these topics:
Topic
Page
Starting Zeke
26
Restarting Zeke
27
Starting OASIS Only
27
Starting Multiple Tasks
28
Terminating OASIS
30
Terminating Zeke
31
Using the ISPF Interface

ISPF Features
General Screen Information
Logging On and Off
Changing the ISPF Color Scheme
32
32
33
33
36
Starting the Zeke Online Facility under TSO
38
25
Starting Zeke
The SSS4001 program initializes Zeke. If the specified OASIS subsystem is not
initialized already, then SSS4001 initializes it first.
To start Zeke
Submit a job similar to this one:
//ZEKE PROC R=0M,S=Z600,

// XP=ZEKECOM,OASIS=(aa,bb),
// ZK=YES
//STEPNAME EXEC PGM=SSS41,REGION=&R,TIME=1440,
// PARM=('OASIS=&OASIS,ZEKE=&ZK,XPROC=&XP,SUBSYS=&S,END)
//STEPLIB DD DISP=SHR,DSN=Zeke-load-library
//
DD DISP=SHR,DSN=OASIS-load-library
//ZEKERDR DD SYSOUT=(A,INTRDR)
//SYSPRINT DD SYSOUT=*
//SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
//xxxxxxxx DD DISP=SHR,DSN=any necessary DD statements
where:
Code
Meaning
aa
OASISxx options member name suffix.
bb
Console option.
Note:
This controls console display and conversation only; the options always are
listed in the JESMSGLG and SYSLOG.
These are the valid options:
26
List all option values on the console.
Start an operator dialogue (e.g., to list the values, override values

for this startup, or cancel the startup); do not list option values on
the console.
LC
List all option values on the console, then start an operator

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

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

Or
Issue an MVS system MODIFY command to the address space using this syntax:
F procname STPROD ZEKE
When you start Zeke, the Zeke address space locates its schedule tables (either in
common storage or in a data space) and determines whether to perform a WARM or
COLD start.
Starting OASIS Only

You can start OASIS without starting Zeke. Typically, this is done when you need to
create a Zeke database.
To start the OASIS subsystem
Issue the START command using this syntax:

START procname,S=subsys,OASIS='(aa,bb)'
where:
procname is the name of the OASIS start-up procedure.
subsys is the OASIS subsystem name.
(aa,bb) is the OASISxx options member name suffix and console option.
27
Note:
If the start-up procedure provides values for the S and OASIS symbolic parameters,
you can omit those parameters from the START command.
This is an example of a typical OASIS startup and the messages issued in response to the
command:
S OASISSTC,S=SSSI,OASIS='(00,N)'
$HASP100 OASISSTC ON STCINRDR
$HASP373 OASISSTC STARTED
IEF403I OASISSTC - STARTED - TIME=14.39.30
X00032I EXECPARM OASIS=(00,N),SUBSYS=SSSI
X00353I Program SSS2SV2 installed as SVC 245
X00000I SET UP COMMAND PREFIX LENGTH
X00008I SSSI Host System Interface initialized CPU=1B02095570600000 ID=A Name=A
X00025I OASIS/HSI X300A000 z/OS 1.10 JES2
X00903I OASIS command processor enabled
Starting Multiple Tasks

These examples illustrate the modifications made to the Zeke started task, the ZEKE
batch utility program (ZEKEUTL), and the OASIS procedures for an alternate subsystem
name of ZDOC.
See the ASG-OASIS for z/OS Installation Guide for more information on modifying the
Zeke and OASIS procedures to run multiple versions of Zeke on a single operating
system.
This example shows the modified Zeke started task procedure:
//*
ZEKE : ALTERNATE STARTED TASK PROC
//ZK56ALT PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS300
//ZK56ALT EXEC PGM=SSS4001,REGION=&R,
//
TIME=1440,PARM=OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END
//SYSPRINT DD
SYSOUT=*
//SYSMDUMP DD
DISP=SHR,DSN=* Your Dump Dataset Name *
//ZEKERDR DD
SYSOUT=(A,INTRDR)
//ZEKECAT DD
DISP=SHR,DSN=* Alternate Zeke Database *
//PARMLIB DD
DSN=library-containing-OASIS00-member,DISP=SHR
//STEPLIB DD
DISP=SHR,DSN=* Your Zeke Load Library Name *
//
DD
DISP=SHR,DSN=* Your OASIS Load Library Name *
//*
28
Each Zeke must have its own unique ZEKExx and OASISxx options members. In each
Zeke started task procedure, change the these parameters:
OASIS=(00,L)
ZEKE=(00,L)
to:
OASIS=(xx,L)
ZEKE=(xx,L)
where xx is the last two characters of the OASISxx or ZEKExx options member for
that particular Zeke.
This example shows the modified ZEKE batch utility (ZEKEUTL) procedure:
//*
ZEKE
//ZEKEUTL
//ZUTL
//ZEKECAT
//STEPLIB
//
//SYSPRINT
//SYSMDUMP
//SORTWK01
//
//SORTWK02
//
//SORTWK03
//
//*
: BATCH UTILITY PROC

PROC R=0M,P='SUBSYS=ZDOC'
EXEC PGM=ZEKE,PARM='&P',REGION=&R
DD
DISP=SHR,DSN=* Alternate Zeke Database *
DD
DD
DD
SYSOUT=*
DD
DD
DSN=&&SORTWK01,DISP=(NEW,DELETE),
SPACE=(CYL,(2,2)),UNIT=SYSDA
DD
DD
This example shows the modified OASIS started task procedure:
//*
ZEKE
//OASISALT
//OASISALT
//PARMLIB
//SYSPRINT
//SYSMDUMP
//STEPLIB
//
: OASIS ALTERNATE SUPPORT PROC

PROC
R=0M,OASIS=(00,L),S=ZDOC
EXEC
PGM=SSS0UTL,REGION=&R,PARM=OASIS=&OASIS,SUBSYS=&S,END
DD
DSN=ASG.PARMLIB,DISP=SHR
DD
SYSOUT=*
DD
DD
DD
29
This example shows the changes to use a single Zeke started task procedure to access
multiple Zeke database and OASIS subsystems:
//ZEKE
PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS300,
//
DB='ZEKE.DATABASE.NAME;'
//ZEKE
EXEC PGM=SSS4001,REGION=&R,
//
TIME=1440,PARM=OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END
//SYSPRINT DD
SYSOUT=*
//SYSMDUMP DD
//ZEKERDR DD
SYSOUT=(A,INTRDR)
//ZEKECAT DD
DISP=SHR,DSN=&DB
//PARMLIB DD
DSN=library-containing-OASIS00-member,DISP=SHR
//STEPLIB DD
//
DD
//*
Use these Zeke startup commands to start the Zeke primary production system using an
alternate database:
S ZEKE
Starts PROD system
S ZEKE,S=ZDOC,DB='ZEKE.TEST.DATABASE',OASIS=(01,L) Starts ALT database
Terminating OASIS
Do not terminate OASIS if any other OASIS-supported Z products are running in the
same OASIS subsystem. You must terminate all products in the subsystem before you
terminate OASIS.
This is a sample jobstream to terminate OASIS (where xxxx is the subsystem):
//ZOASIS
JOB
//SOASIS
EXEC
//SYSPRINT DD
//STEPLIB DD
//SYSIN
DD
TERMINATE
/*
30
,MSGLEVEL=(1,1),CLASS=A
PROC=OASIS,REGION=1024K,S=xxxx
SYSOUT=A
DSN=OASIS.LINKLIB,DISP=SHR
*
<== If required
Terminating Zeke
If multiple OASIS-supported Z products are active in the address space, you can use the
MVS system command STOP to terminate all active products along with the started task.
When you terminate the last (or only) active product in the address space, the started task
is terminated automatically.
To terminate Zeke using the STOP command
Using the STOP command, specify the name of the started task procedure. For
example, issue this command to terminate a Zeke started task:
STOP ZEKE
Note:
The STOP command is the equivalent of the ZKILL COLD command.

The ZKILL command terminates Zeke only; any other products in the address space
remain active. ZKILL releases Zeke-owned storage and system resources and terminates
its subtasks. The COLD, WARM, and TRACK parameters dictate how the ZKILL is
processed.
To terminate Zeke using ZKILL
Issue one of these ZKILL commands to terminate Zeke (depending on the desired
result):
Command
Result
ZKILL COLD
Terminate all Zeke processing and release all Zeke program and table
storage. Any other products in the same address space remain active.
ZKILL WARM
Terminate Zeke dispatching only. Zeke continues to perform all event

tracking, triggering, and updates. Any other products in the same
address space remain active.
Note:
If Zeke is cancelled during a COLD start (before the schedule has
been loaded for the first time or while a schedule reload is in
progress), then the schedule is freed and Zeke is terminated
completely.
ZKILL TRACK
Terminate Zeke in the same manner as ZKILL COLD, but keep the
SMF exits for Zeke active, and place Zeke in SMF recording mode.
See ZKILL Command on page 324 for more information.

31
Using the ISPF Interface

The Zeke online facility is a dialog that runs under ISPF/PDF. Because it is a dialog, all
ISPF functions (e.g., SPLIT SCREEN and JUMP) are available. You can enter any valid
ISPF command on the Command or Option lines. You also can control the PF key
settings.
ISPF Features
This section describes the key features of the ISPF online facility.
Online Help
The online facility includes a tutorial and help system.
To access the tutorial
Enter T from the Zeke Option Menu.
To access help
Press F1 from any Zeke online screen.
Primary Commands
Primary commands (e.g., ADD, DELETE, BROWSE, and EDIT) are available on most
screens. Enter these commands on the Command or Option line to change the mode for
the current screen or to switch to another screen.
Any screens that enable editing also support all standard ISPF editing commands (e.g.,
SAVE, EDIT, CANCEL, and END).
Note:
A few commands (e.g., CANCEL, COPY, and EDIT) have the same name in ISPF as in
Zeke. When you issue these commands in Zeke, they are processed as Zeke commands
(not ISPF commands). To use the ISPF command in Zeke when there is a Zeke command
by the same name, you must issue it as part of the ISPF EDIT command BUILTIN (e.g.,
BUILTIN CANCEL). Otherwise, the system assumes you are issuing a Zeke command.
See your ISPF documentation for more information on the BUILTIN command.
OVAR
Although it is not listed on the screen with the Primary Commands, the OVAR primary
command is available from the Command line of any screen. This command enables you
to access the OASIS Variable Maintenance screen where you can add, browse, edit, or
delete OASIS variables. See the ASG-OASIS for z/OS Reference Guide for details.
32
Line Commands
Line commands (e.g., I for Insert, R for Repeat, and D for Delete) are listed under
the Line Commands heading on applicable screens. You enter line commands in the Sel
field to the left of the corresponding item.
Zeke screens that support line commands also support all standard ISPF editing
commands (e.g., C for Copy, CC for Copy Block, and TF for Text Flow).
General Screen Information

This section describes the standard format of the Zeke ISPF screens (including the fields
common to most screens).
ASG-Zeke
Command or Option
Primary command entry line Command ===>
Screen Name
Varies depending on
screen purpose
Primary Commands
Zeke primary commands
Varies by screen function
Standard ISPF commands
also are available
Line Commands
Zeke line commands
Varies by screen function
Standard ISPF commands
also are available
Screen Mode
Action allowed
on this screen
ADD
Scroll ===> PAGE
Primary commands: BROWSE CANCEL DELETE EDIT

Line commands: D Delete line I Insert line R Repeat line
Event: 000006
Jobname: TSKKGUT1
Operators:
Actions:
Stepname
EOJ CC
STEP01
STEP02
System: ZEQA
EQ NE LE LT GE GT
F = Fail, C = Cancel,
Procstep
Operator
GT
NE
Event Name: ZEKE51TST6
RA =Range
O = Ok
- Range Low High
8
16
Action
F
O
Logging On and Off

This section explains how to access the Zeke ISPF online facility.
Note:
All remaining online procedures in this publication start from the Zeke Primary Menu.
33
To access the Zeke ISPF online facility

1
Access the ISPF Primary Option Menu:

Menu
Utilities
Compilers
Options
Status
Help
TSO-Access
ASG
ISPF Primary Option Menu

Option ===> ASG
0
1
2
3
4
5
6
7
8
9
10
11
S
ASG
Settings
View
Edit
Utilities
Foreground
Batch
Command
Dialog Test
LM Facility
IBM Products
SCLM
Workplace
SDSF
ASG
More:
Terminal and user parameters
Display source data or listings
Create or change source data
Perform utility functions
Interactive language processing
Submit job for language processing
Enter TSO or Workstation commands
Perform dialog testing
Library administrator functions
IBM program development products
SW Configuration Library Manager
ISPF Object/Action Workplace
System Display and Search Facility
ASG Product Panel
+
User ID . :
Time. . . :
Terminal. :
Screen. . :
Language. :
Appl ID . :
TSO logon :
TSO prefix:
System ID :
MVS acct. :
Release . :
ASGUSER
13:28
3278
1
ENGLISH
ISR
$TSASG
TSOUSR
SYSD
ACCT
ISPF 6.1
Enter X to Terminate using log/list defaults
Type ASG in the Option field and press Enter. The ASG Product Menu is displayed:
-------------------------- ASG PRODUCT MENU ---------------------------------SELECTION ===> 5
------ASG PRODUCTS------------------DESCRIPTION--------------------2
3
4
5
F
PM
AFI
STEST
ESW
zTEAM
SMUF/APTS
PRODMAN
-----MISC UTILITIES----A DASD/QUICKREF

J JCLPREP
Q MVS/QUICKREF
C CICSPLEX
D DB2 / Other
ST SYSTOOLS
TM TMON INFO CENTER
X
34
EXIT
ASG-FAVORITES FOR MAXIMZING ISPF PRODUCTIVITY

ALLEN SYSTEMS DEBUGGING FACILITY
ASG-ESW EXISTING SYSTEMS WORKBENCH
ZEKE, ZEBB AND ZARA
SMUF/APAR PTF TRACKING
PRODUCT-MANUFACTURING
-------------DESCRIPTION--------------------DASD FREE SPACE INFORMATION OPTION S
JCLPREP (JCL VALIDATOR)
QUICK REF (ONLINE ERRORS/MESSAGES/SYNTAX)
CICSPLEX SYSTEM MANAGER
ADMIN, SPUFI, QMF, Ditto ...
SYSTEM- AND SUBSYSTEM-TOOLS
TMON INFO CENTER FOR DEVELOPER
RETURN TO ISPF MAIN MENU
Type 5 in the SELECTION field and press Enter. The ASG Product Selection
Menu is displayed:
ASG Product Selection Menu
OPTION
===>
ZA
ZB
ZE
ZR
ZX
ASG-Zack
ASG-Zebb
ASG-Zeke
ASG-Zara
ASG-OASIS
WP
WA
ASG-WP
ASG-WA
- Workload Planner (BETA 44)

- Workload Analyzer (BETA 45)
EXIT
Automated Operations
Rerun/Restart Management
Scheduling for z/OS
Tape Management
OASIS Variables and Audit
OASIS Subsystem ===> SSSI

USERID
- ASGUSER
TIME
- 13:26
- Return to previous menu
Enter END command to return to the previous menu.

Copyright (C) 2012 Allen Systems Group, Inc. All rights reserved.
Enter ZE in the OPTION field.
Type the subsystem name in the OASIS Subsystem field. The default subsystem is
SSSI.
Press Enter. The ASG-Zeke Primary Menu is displayed:
ASG-Zeke
Option ===>
1
2
3
4
5
6
7
8
F
C
T
X
Event
Schedule View
Calendar
Options
Work
Security
Documentation
Variable
Automation
Control
Tutorial
Exit
ASG-Zeke Primary Menu
Z600A000
Event Master Record

Schedule View / Scheduling Commands
Calendar Maintenance
Options and Passwords Maintenance
Work Center Control Functions
Security Control Functions
Documentation for Events
Variable Maintenance
Fastpath Tables Maintenance
Schedule View Display Characteristics
Information about using ASG-Zeke
Exit the ASG-Zeke Application
From this menu, type the option number on the Option line and press Enter to select
the corresponding online function.
35
Note:
If you have Zack (or the Zeke Automation Option) installed, the Automation
Fastpath Tables Maintenance option enables you to manage Fastpath and Autoreply
tables in Zack (directly from Zeke). If Zack is active, the option activates the Zack
Fastpath Table Maintenance function and displays a directory listing of table
names, types (i.e., message, reply, dataset), and statistics, where you can add,
browse, copy, delete, or edit a specific table. See the ASG-Zack publication library
for more information.
To exit the Zeke ISPF online facility
From the ASG-Zeke Primary Menu, type X on the Option line and press Enter.
The ISPF Primary Option Menu is displayed:
ASG-Zeke
Option ===>
1
2
3
4
5
6
7
8
F
C
T
X
Event
Schedule View
Calendar
Options
Work
Security
Documentation
Variable
Automation
Control
Tutorial
Exit
ASG-Zeke Primary Menu
Z600A000
Event Master Record

Schedule View / Scheduling Commands
Calendar Maintenance
Options and Passwords Maintenance
Work Center Control Functions
Documentation for Events
Variable Maintenance
Fastpath Tables Maintenance
Schedule View Display Characteristics
Information about using ASG-Zeke
Exit the ASG-Zeke Application
Changing the ISPF Color Scheme

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

1
From the Zeke Primary Menu, enter option C.1 and press Enter. The User Color
Select Screen is displayed:
ASG-Zeke
Command ==>
Primary Commands:
User Color Select Screen
INIT SAVE
Description
Color
Hilite
Screen Title
Field and Column Heading
Normal Text
Accented Text
Normal Output Data
Accented Output Text
Normal Input Data
Accented Input Data
Input Field in Error
Warning Field
Exception Field
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
Colors: Red, Blue, Green, Yellow, White, Pink, Turq

Hilite Keywords: Reverse, Uscore, Blink, or leave blank
Consider the types of data you want to change. This table provides is a description
of each type:
Data Type
Description
Screen Title
First line of the screen.
Field and Column

Heading
Labels that identify the fields. Field names and column headings
are treated the same (whether the fields are arranged in a column
or placed next to the field name that applies to them).
Normal Text
Descriptive or narrative text that usually explains or introduces

other information displayed on the screen.
Accented Text
Descriptive or narrative text that is highlighted for emphasis

(e.g., the line command abbreviation to enter in the Select field).
Normal Output Data
Displayed information that has been entered previously, or has

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

been calculated by the system (and has been highlighted for
emphasis).
Normal Input Data
Fields available for entry.

37
Data Type
Description
Accented Input Data
Fields available for entry (and highlighted for emphasis).
Input Field In Error
Not used.
Warning Field
Not used.
Exception Field
Not used.
In the Color field, enter the first letter of the color you want to use.
In the Hilite field, enter the first letter of the attribute you want to use.
Enter SAVE on the Command line and press Enter.
Starting the Zeke Online Facility under TSO

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

1
Issue the command ZEKEOL (or its alias ZOL) from any full screen terminal.
Note:
The ZEKEOL command is not supported as a called program from TSO.

If you are running multiple versions of Zeke, you must include the subsystem:
TSO ZEKEOL SUBSYS=subsystem
Note:
If you use the default subsystem (SSSI), including it in the command is optional.
38
Chapter 3:
Calendars
3
When it creates a schedule of events, Zeke uses calendars to distinguish a workday, from
a weekend day, from a holiday. This distinction is important because it determines the
meaning of some of the OCCURS keywords. For example, if you define your workdays
as Monday through Friday, then the OCCURS keyword WORKDAYS means to schedule
the event on Monday through Friday. However, if you define your workdays as Monday
through Saturday, the OCCURS keyword WORKDAYS means to schedule the event on
Monday through Saturday.
Topic
Page
Calendar Types
39
Accessing the Calendar Facility
40
Standard Calendars
42
Special Calendars
43
User Accounting Calendars
44
Calendar Documentation
Maintaining Scratch Pad or Note Documentation
Maintaining Text Documentation
47
48
49
Calendar Types
These are the calendar types:
Calendar
Description
Standard
Defines normal workdays and holidays.
Special
Defines the exact days an event is to run. You would use a special calendar
only when events have run dates that are random.
User accounting
Defines normal workdays and holidays, and establishes accounting periods.
39
Most companies only need one or two Zeke calendars to meet all of their scheduling
needs; however, you can define as many calendars as necessary. Zeke provides for an
unlimited number of calendars to be defined. Each calendar must have a unique ID.
Note:
If you define a calendar for a specific year to begin processing on the first day or week of
the year, you also must set up a calendar for the previous year for Zeke to reference when
determining the previous workday. This also is true for calendar processing on the last
day or week of the year. You must set up a calendar for the next year that Zeke can use
for reference.
Accessing the Calendar Facility

To access the calendar facility
1
From the Zeke Primary Menu, enter option 3. Press Enter. The Calendar Selection
Criteria screen is displayed:
ASG-Zeke
Command ===>
Calendar Selection Criteria
Calendar ID==>
Year==>
Primary commands: ADD
BROWSE
COPY
Type==>
DELETE
EDIT
DOCUMENT
Enter SELECTION MASK in any field to be compared for selection.

Clear any field that is not to be used for selection.
* - is a prefix/suffix indicator.
? - is a wild/place holder character.
*
SELECTION FIELD MASKS
Calendar ID =>
Calendar Type =>
Date Range =>
40
STD- Standard
-
SPC- Special USR- User

(MM/DD/YYYY) or (DD/MM/YYYY)
3 Calendars
Press Enter. The Calendar Directory is displayed:

ASG-Zeke
Command ===>
Calendar Directory
Row 1 to 3 of 3
Scroll ==> PAGE
Calendar id==>
Primary Commands: ADD
Line Commands: E Edit
Year==>
Type==>
BROWSE COPY DELETE DOCUMENT EDIT
B Browse C Copy D Delete O dOcument
Calendar
Workdays
Start
End
Last
Name
Year Type MTWTFSS
Date
Date
Used
A
**** STD
YYYYYNN
01/20/2012
ACCTG1
2012 USR
YYYYYNN
01/01/2012
06/30/2012
USER1
2012 SPC
N/A
01/01/2012
12/31/2012
******************************Bottom of data*******************************
Perform the steps in the Action column (depending on the desired result).
Desired Result
Action
Add a new calendar
1 Enter ADD on the Command line.

2 Enter the new calendar ID (up to eight alphanumeric
characters long) in the Calendar id field.
3 Enter the calendar year in the Calendar Year field.
Note:
For standard and special calendars, you can enter **** to indicate
a generic year. User accounting calendars require a specific year.
4 Enter the calendar type in the Type field. Press Enter.
These are the valid types:
STD
Standard calendar
SPC
Special calendar
USR
User accounting calendar
Update an existing
calendar
Move the cursor to the unlabeled selection field to the left of the
calendar you want to update and enter E.
Delete an existing
calendar
Move the cursor to the unlabeled selection field to the left of the
calendar you want to update and enter D. The Calendar
Maintenance Functions screen displays the calendar to be deleted.
Enter DEL and press Enter to confirm.
This procedure is complete.
Press Enter. The Calendar Maintenance Functions screen for the appropriate type of
calendar is displayed.
41
Standard Calendars
Standard calendars define the normal workdays and holidays and indicate the first month
of the fiscal year for your company. Most events are associated with a standard calendar.
Zekes default calendar A is a standard calendar that can be updated to accommodate
your normal schedule. You can define as many standard calendars as necessary, each
with different workdays and holidays.
In this example, an event defined with the OCCURS clause WORKDAYS using calendar
A is scheduled five times per week, and an event using calendar B is scheduled six times
per week. Also, calendar A adjusts the scheduling of an event in case of a holiday, while
calendar B does not recognize any holidays.
Calendar A
Calendar B
Workdays
Monday through Friday
Holidays
01/01/****, 07/04/****, 12/24/****, 12/25/****,

05/28/2012, 09/03/2012, 11/22/2012, 11/23/2012
Workdays
Monday through Saturday
Holidays
None
To maintain a standard calendar

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

Calendar Facility on page 40.
ASG-Zeke
Command ===>
Calendar Maintenance Functions

Calendar ID==> A
Work Days:
Mon
YES
Tue
YES
MM/DD/YYYY
BROWSE
Wed
YES
CANCEL COPY DELETE

Year==> ****
Thu
YES
Fri
YES
MM/DD/YYYY
Sat
NO
BROWSE
DOCUMENT EDIT
Type==> STD
Sun
NO
MM/DD/YYYY
MM/DD/YYYY
MM/DD/YYYY
Holidays:
Fiscal start month: 01

Calendar expire date: 12/31/2012
Calendar start date:
42
Date last accessed: 04/26/2012

Calendar end date :
3 Calendars
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.
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.
Press Enter to save the calendar information.
Special Calendars
You can use a special calendar for events that have random scheduling dates for which no
other calendar type or OCCURS clause can pinpoint the correct schedule dates. First, you
must associate the event with a standard or user accounting calendar. If you need to
consider an additional, special calendar to establish the correct run dates, then you specify
the special calendar in the OCCURS clause for the event.
Note:
A special calendar is the only calendar type that you can use in an OCCURS clause.
For example, this OCCURS clause schedules an event on every selected date on the
special calendar:
OCCURS (CALENDAR CAL1 AND DAILY)
You can use one special calendar for several events, then use keywords to specify dates in
the OCCURS clause. For example, this OCCURS clause schedules an event on selected
dates that fall on Monday:
OCCURS (CALENDAR CAL1 AND MONDAY)
43
To maintain a special calendar

1

ASG-Zeke
COMMAND ===>

ZEKE Calendar ID==> USER1
January
February
March
April
May
June
July
August
September
October
November
December
1
.
.
.
.
.
.
.
.
.
.
.
*
2
.
.
.
.
.
.
.
.
.
.
.
*
3
.
.
.
.
.
.
.
.
.
.
.
*
4
.
.
.
.
.
.
.
.
.
.
.
*
5
.
.
.
.
.
.
.
.
.
.
.
*
6
.
.
.
.
.
.
.
.
.
.
.
*
7
.
.
.
.
.
.
.
.
.
.
.
*
8
.
.
.
.
.
.
.
.
.
.
.
*
9
.
.
.
.
.
.
.
.
.
.
.
*
BROWSE
CANCEL COPY DELETE

Year==> 2012
DOCUMENT EDIT
Type==> SPC
1
0
.
.
.
.
.
.
.
.
.
.
.
*
1
4
.
.
.
.
.
.
.
.
.
.
.
.
2
5
.
.
.
.
.
.
.
.
.
.
.
.
1
1
.
.
.
.
.
.
.
.
.
.
.
*
1
2
.
.
.
.
.
.
.
.
.
.
.
*
1
3
.
.
.
.
.
.
.
.
.
.
.
*
Calendar Expire Date:

Calendar Start Date: 01/01/2012
BROWSE
1
5
.
.
.
.
.
.
.
.
.
.
.
.
1
6
.
.
.
.
.
.
.
.
.
.
.
.
1
7
.
.
.
.
.
.
.
.
.
.
.
.
1
8
.
.
.
.
.
.
.
.
.
.
.
.
1
9
.
.
.
.
.
.
.
.
.
.
.
.
2
0
.
.
.
.
.
.
.
.
.
.
.
.
2
1
.
.
.
.
.
.
.
.
.
.
.
.
2
2
.
.
.
.
.
.
.
.
.
.
.
.
2
3
.
.
.
.
.
.
.
.
.
.
.
.
2
4
.
.
.
.
.
.
.
.
.
.
.
.
2
6
.
.
.
.
.
.
.
.
.
.
.
.
2
7
.
.
.
.
.
.
.
.
.
.
.
.
2
8
.
.
.
.
.
.
.
.
.
.
.
.
2
9
.
.
.
.
.
.
.
.
.
.
.
.
3 3
0 1
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Date Last Accessed:

Calendar End Date: 12/31/2012
Enter an asterisk (*) or slash (/) for the days you want the job to be scheduled. The
days are listed across the screen and the months are listed down the left column to
create a matrix of dates.
To deselect a date, replace the asterisk or slash with a period (.) or blank.
Press Enter to save your changes.
User Accounting Calendars

If you want to schedule events based on your company accounting schedule, you can set
up user accounting calendars to match the days in your accounting periods.
You associate an event with a user accounting calendar using the Cal field in the EMR,
like you do for a standard calendar. When you specify a user accounting calendar, the
keywords refer to periods instead of months. In an OCCURS clause, you must use the
keyword PERIODS instead of MONTHS for events that will use a user accounting
calendar.
44
3 Calendars
For example, this OCCURs clause selects the last Monday in period 2:
MONDAY.L AND PERIOD.2
To maintain a user accounting calendar

1

ASG-Zeke
Command ===>
Primary Commands: ADD BROWSE

Calendar ID==> ACCTG1
Work Days:
Mon
YES
Tue
YES
MM/DD/YYYY
Wed
YES
CANCEL COPY DELETE

Year==> 2012
Thu
YES
Fri
YES
MM/DD/YYYY
Sat
NO
BROWSE
DOCUMENT EDIT
PERIODS
Type==> USR
Sun
NO
MM/DD/YYYY
MM/DD/YYYY
MM/DD/YYYY
Holidays:
Calendar expire date:

Calendar start date: 01/01/2012
Date last accessed:

Calendar end date : 06/30/2012
The default workdays are Monday through Friday and weekends are Saturday and
Sunday. There are no default holidays.
2
Update the Work Days portion of the screen, if your workdays are different from the
default days. Use the Tab key to access each of the workday fields. For each day of
the week, enter YES if it is a workday; enter NO if it is not a workday.
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.
If you are adding a new calendar, specify the date the calendar becomes effective in
the Calendar Start Date field and the date it is no longer effective in the Calendar
Expire Date field and press Enter.
Note:
Set the Calendar Expire Date for six days after the desired expiration date to ensure
proper calculation of OCCURS hits.
45
If you are updating an existing calendar, enter PERIODS on the Command line,
and press Enter.
ASG-Zeke
COMMAND ===>
Primary Commands:
User Calendar Periods
BROWSE CANCEL EDIT
Calendar start date: 01/01/2012

ZEKE Calendar ID==> ACCTG1
Period
Period
Period
Period
Period
Period
Period
Period
01: 28
04: 28
07:
10:
13:
16:
19:
22:
BROWSE
Period
Period
Period
Period
Period
Period
Period
Period
Calendar end date : 06/30/2012

Year==> 2012
Type==> USR
02: 28
05: 28
08:
11:
14:
17:
20:
23:
Period
Period
Period
Period
Period
Period
Period
Period
03: 35
06: 35
09:
12:
15:
18:
21:
24:
Number of slack days between periods:

Enter number of days (01-90) in each period and number of slack days (00-40)
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.
46
If there are extra days between the end of this fiscal year and the start of the next one,
enter that number in the Number of Slack Days field. If slack days are needed and
are not entered, an error occurs when the SCHEDULE function is run.
3 Calendars
Calendar Documentation
The Calendar facility enables you to store and maintain calendar-related documentation.
There are three types of calendar documentation that can be stored.
Type
Description
Scratch
Scratch pad and note documentation each enable you to store up to ten lines
of information for a calendar. These documentation areas are like sticky notes
and are used to pass notes from shift to shift, or from one department to
another. They also can be used for quick reference information. The
operator should always review scratch pad or note pad information before an
event runs.
Note
Text
Stores up to approximately 450 records
To access calendar documentation

1
From the Zeke Primary Menu, enter 3 and press Enter.Access the Calendar
Maintenance Functions screen as instructed in Accessing the Calendar Facility on
page 40.
Enter DOCUMENT on the Command line and press Enter. The Documentation
Segments screen is displayed. If an asterisk (*) is displayed to the left of the
documentation type, that type of documentation exists for the calendar.
ASG-Zeke
Option ===>
Documentation Segments
Primary Command: DELETE

Calid: A
Year: ****
Type: STD
Sdate:
Edate:
Documentation Record Selection Options

1
SCRATCH
2 * TEXT
3
NOTE
Scratch pad
Text information
Note pad information
Enter one of these codes on the Command line to select the type of documentation
you want to add or update:
Desired Result
Action
Access scratch pad

documentation
Enter 1 and press Enter. Go to Maintaining Scratch Pad or

Note Documentation on page 48.
47
Desired Result
Action
Access text
documentation
Enter 2 and press Enter. Go to Maintaining Text

Documentation on page 49.
Access note
documentation
Enter 3 and press Enter. Go to Maintaining Scratch Pad or

Note Documentation on page 48.

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

ASG-Zeke
Command ==>
Primary Commands: BROWSE
Documentation Scratch Pad
CANCEL
DELETE
EDIT
EDIT
Line 1 USE THIS CALENDAR FOR ALL LEVEL 4 JOBS AND

2 FOR SPECIAL LEVEL 3 JOBS.
3
4
5
6
7
8
9
10
Calendar id : B
Workdays
: YYYYNNY
48
Calendar year : ****

Start date :
Calendar type : STD

End date :
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.
Press Enter to save the changes.
3 Calendars

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

1
Access the Text Documentation screen, as described in Calendar Documentation

on page 47.
ASG-Zeke
Command ===>
Calid:
******
==MSG>
==MSG>
000001
******
Text Documentation
EDIT
Columns 000 000
Scroll ===> PAGE
A
Year: **** Type: STD Sdate:
Edate:
*************************** Top of Data *****************************
-Warning- The UNDO command is not available until you change
your edit profile using the command RECOVERY ON.
SVP OR HIGHER SIGNATURE REQUIRED TO AUTHORIZE CHANGING THIS CALENDAR
************************** Bottom of Data ***************************
Enter text to the right of the column placeholder field. You can enter up to 80
characters per line, and up to several hundred lines of text.
Use standard ISPF editing commands to edit the text.
Press F8 to page forward and access an additional screen.
49
50
Chapter 4:
Events
4
An event is a unit of work (e.g., a batch process, program, command, message, etc.)
defined to Zeke and scheduled to occur under a particular set of circumstances. You
create an event master record (EMR) in the Zeke database that defines information for the
event. The EMR includes the date and time to schedule the event, prerequisite conditions
for dispatch, and resource requirements.
This chapter discusses these topics:
Topic
Page
Event Master Record (EMRs)

Event Types
EMR Primary Commands
Specifying Generic Selection Criteria
Accessing the Event Definition
Adding an Event Definition
Updating an Event Definition
Defining an Event Template
Creating an Event From a Template
Copying an Event
Defining a Job Event
Defining a Message Event
Defining a Command Event
Defining a REXX Event
Defining a Recurring or Permanent Event
Defining a Milestone Event
Using Scheduling Environments
52
53
53
57
58
59
61
63
65
67
69
86
89
93
97
102
105
OCCURS Clauses
OCCURS Clause Format
Sample OCCURS Clauses
Scheduling Events on Holidays and Weekends
Defining an OCCURS Clause
107
107
115
118
121
WHEN Conditions
Job and Program WHEN Conditions
WHEN Conditions for Multiple Event Versions
WEAK Conditions
NOTDURING Conditions
124
124
124
124
126
127
51
Topic
Cross-platform Dependencies
Specifying Generic Names
Specifying Multiple WHEN Conditions
Specifying Started Tasks
Using Zeke Variables as WHEN Conditions
WHEN Condition Keywords
Defining a WHEN Condition
Viewing WHEN Conditions for All Event Versions
Page
129
130
130
131
131
133
139
140
Condition Codes
Defining Condition Codes for an Event
143
144
Work Centers
Using Variables in Work Centers
Defining a Work Center
Completing Work Centers
149
150
151
155
Auto Replies
Defining Auto Replies
Managing Auto Replies
159
160
163
Event Documentation
Accessing Event Documentation
Maintaining Dataset Documentation
164
165
168
169
170

Viewing Event Accounting Information
Maintaining Job Duration Statistics, Alerts, and Failures
172
172
174
Event Master Record (EMRs)

You can define an event through either of these facilities:
Event Master Record Definition screens in the Zeke online facility
EVENT function of the ZEKE batch utility program
This chapter describes the procedures as you would perform them using the online
facility. For information on performing the same general procedures using the ZEKE
batch utility program, see the ASG-Zeke Scheduling for z/OS Reference Guide.
52
4 Events
Event Types
These are the Zeke event types:
Type
Description
JOB
Jobstream event
MSG
Console operator message event
WORK
Work center event
VCOM
VM CP command event
ZCOM
Zeke operator command event
SCOM
System command or system response event
PCOM
(VSE only) POWER command event
REXX
(z/OS only) REXX EXEC
EMR Primary Commands

These are the primary commands that are available from most Event Master Definition
screens (and their corresponding functions):
Note:
Uppercase characters indicate the commands minimum abbreviation.

Command
Action
ACCT
Maintain the event accounting history.
ADD
Add an event definition.
AUTorply
Maintain auto reply elements for a job event.
BROwse
Browse an event definition.
CCode
Maintain condition code information for a job event.
COPY
Copy the basic identifying information and OCCURS/WHEN information

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

create a new event. (Zeke generates the new event number.)
DEACt
Deactivate an event, so that Zeke does not include it in the schedule.
DELete
Delete an event definition from the Zeke database. (Zeke requires you to
confirm the action.)
Note:
You can delete an event definition only if there are no existing schedule
queue records (SQRs) already in the schedule based on the event definition.
(Otherwise, you must delete the existing SQRs first.)
DISPlay
Display the event definition in Browse mode.
DOCument
Define or maintain event documentation.
EDit
Display the event information in Edit mode.
JCL
Display JCL that is stored in the Zeke database.
OCCurs
Maintain the OCCURS clause for the event.
PATH
View the predecessors and successors of the event.

Note:
The DSPIndex generation option must be set to Y to enable the PATH
command (see Building EDB Indexes on page 311).
These are the optional command keywords:
LEVel
Specifies the level of depth to display for the path. The valid
values range from 1 through 999, or you can enter an asterisk
(*) to display all levels. The default value is *.
OCCDate
Specifies the Julian date for Zeke to use to resolve the OCCURS
clause. The default value is the current date.
VERsion
Specifies the version of the event for which to display

predecessor/successor information. For example:
PATH VER 3
The default value is 0 (if the Verload generation option is set

to 0). Otherwise, the default value is 1.
54
4 Events
Command
Action
PATHADD
Invoke the Schedule View Add-by-Path wizard, which enables you to list
predecessors and successors for an event and then schedule events from the
list. Zeke auto-fills the event, depth level, OCCURS date, version, and path
type.
Note:
The DSPIndex generation option must be set to Y to enable the PATHADD
LEVel
OCCDate
VERsion

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

PREd
View the predecessors of the event.

Note:
The DSPIndex generation option must be set to Y to enable the PRED
LEVel
OCCDate
VERsion

predecessor information. For example:
PRED VER 3

55
Command
Action
PREDADD
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
LEVel
OCCDate
VERsion
Specifies the version of the event for which to view predecessor

information.
PREDADD LEV 3

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

scheduled.
RESOurce
Maintain logical resource control information for a job event.
RESTart
Request the restart facility (e.g., Zebb) for the job event.
SUcc
View the successors of the event.

Note:
The DSPIndex generation option must be set to Y to use the SUCC command
(see Building EDB Indexes on page 311).
56
LEVEL
OCCDATE
4 Events
Command
Action
VERSION
Specifies the version of the event for which to view successor

information.
SUCC VER 3

SUCCADD
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
LEVEL
OCCDATE
VERSION
Specifies the version of the event for which to view successor

information.
SUCCADD LEV 3

to 0. Otherwise, the default value is 1).
WHEN
Maintain the WHEN conditions (i.e., prerequisites or dependencies) for the

event (or for a particular version of the event).
Specifying Generic Selection Criteria

When using a Zeke online function that enables you to select events in the Zeke database,
you can use wildcard or placeholder characters in your selection criteria. These are the
most common event attributes that enable the use of wildcards and placeholders:
Application ID
Event name
Group ID
Jobname
System ID
User ID
57
An asterisk (*) can be used as a wildcard for one or more characters and functions in
these ways:
An asterisk at the end of an operand string (e.g., ABC*) selects any name (of any
valid length) that begins with the specified characters.
An asterisk at the beginning of an operand string (e.g., *ABC) selects any name (of
any valid length) that ends with the specified characters.
An asterisk in the middle of an operand string performs a wildcard search for any
name matching the specified beginning and ending characters (plus any characters
in between).
A question mark (?) can be used as a placeholder for any unknown, single character.
Wildcards and placeholders can be used in combination.
Accessing the Event Definition

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

1
From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria
screen is displayed:
ASG-Zeke
Command ===>
Event Master Selection Criteria
Event ===>
Primary Commands:
ADD BROWSE DELETE EDIT
Place any character other than

a space next to Event Types to
be selected.
Event Types
Job:
Msg:
Pcom:
Work:
Vcom:
Zcom:
Scom:
REXX:
Template:
Permanent:
Milestone:
58
Enter a selection mask in any field(s)

to be compared for selection.
Selection Field Masks
Job Name:
Event Name:
Application:
Group ID:
User ID:
Drl ID:
System:
Calendar ID:
Occurs:
When:
4 Events
Optional. To a list of existing templates for a specific event type, perform these steps:
a
Enter Y in the Template field.
Enter Y in the appropriate Event Types field.
Press Enter. The Event Master Directory is displayed:

ASG-Zeke
Command ===>
Event Master Directory

Scroll ===> PAGE

Line Commands: E/En - Edit B/Bn - Browse D/Dn - Delete
n = 1 through 7 for the specific part of Event as listed below.
1
2
3
4
5
6
7
Event
Event
Jobname
Evt
DOC JCL Auto Rsrc Cond
Occ
Whn
Number
Name
Type
Repl
Codes
=============================================================================
000001
ZEKE60TST1
MSG
*
*
000002
ZEKE60TST2
MSG
*
*
000003
ZEKE60TST3
MSG
*
*
000004
ZEKE60TST4
MSG
*
*
000005
ZEKE60TST5
MSG
*
*
000006
ZEKE60TST6
TSKKGUT1 JOB
*
*
*
*
000007
ZEKE60TST7
TSKKGUT2 JOB
*
*
*
*
000008
ZEKE60TST8
TSKKGUT3 JOB
*
*
*
000009
ZEKE60TST9
TSKKGUT4 JOB
*
*
*
000010
ZEKE60TST10
TSKKGUT5 JOB
*
*
*
000011
ZEKE60CC
SPTEXD11 JOB
*
*
*
*
000012
ZEKE60CC
SPTEXD12 JOB
*
*
*
*
000013
WORK
*
*
000014
VCOM
*
An asterisk (*) in any column on the right side of the screen indicates that a record
of that type exists for the corresponding event (e.g., an asterisk in the Cond Codes
column indicates that condition code information exists for the event).
Adding an Event Definition

This section describes the general procedure for adding a new event to the Zeke database
and then directs you to the appropriate procedure for defining the specific event type.
To add a new event definition

1
screen is displayed.
59
Enter ADD on the Command line, and press Enter. The Add Event Record Function
ASG-Zeke
Option ===>
Use Template: Y
1
Job
2
Msg
3
Pcom
4
Work
5
Vcom
6
Zcom
7
Scom
8
REXX
Add Event Record Function
Add
Add
Add
Add
Add
Add
Add
Add
a
a
a
a
a
a
a
a
Job Event
Message Event
Pcom Event
Work Center Event
Vcom Event
Zcom Event
Scom Event
REXX Event
Template
JCLTEMPLATE
MSGTEMPLATE
PCOMTEMPLATE
WORKTEMPLATE
VCOMTEMPLATE
ZCOMTEMPLATE
SCOMTEMPLATE
REXXTEMPLATE
Press PF3/PF15 key to abort the Add request
In the Option field, specify the option number for the type of event that you want to
define.
In the Use Template field, enter N.

Or
If you want to create the event using a template, skip to Creating an Event From a
Template on page 65.
5
Press Enter. The Event Master Definition screen for the selected event type is
displayed in Add mode.
Depending on the type of event that you want to add, continue to the appropriate
procedure:
60
For job events, see Defining a Job Event on page 69.
For message events, see Defining a Message Event on page 86.
For command events (e.g., PCOM, SCOM, VCOM, ZCOM), see Defining a
Command Event on page 89.
For work center events, see Defining a Work Center on page 151.
For REXX events, see Defining a REXX Event on page 93.
4 Events
Updating an Event Definition

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

1
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Update an existing event

based on event number
1 Enter EDIT on the Command line.

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

(without the event number)
1 Enter any character in the appropriate Event Types

field.
2 Enter any additional information about the event in the
Selection Field Masks fields.
3 Press Enter. The Event Master Directory displays
events that match the selection criteria.
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.
Update event documentation, 1 Enter any character in the appropriate Event Types
JCL, auto reply, resource,
field.
condition codes, or
2 Enter any additional information about the event in the
dependency information
3 Press Enter. The Event Master Directory displays
events that match the selection criteria.
61
Desired Result
Action
Update the EMR
Enter E to the left of the event that you want to update, and press
Enter. The Event Master Definition screen for the selected event is
displayed in Edit mode.
Perform the appropriate update procedure for the event type you are
updating:
See Defining a Job Event on page 69.
See Defining a Message Event on page 86.
See Defining a Command Event on page 89.
See Defining a REXX Event on page 93.
See Defining a Work Center on page 151.
Delete the EMR
1 Enter D to the left of the event that you want to update, and press
Enter. The Event Master Definition screen for the selected event
is displayed in Delete mode.
2 Press Enter again to confirm.
Update event
documentation
Enter E1 to the left of the event that you want to update, and press
Enter.
Continue to Accessing Event Documentation on page 165.
Update online event Enter E2 to the left of the event that you want to update, and press
JCL
Enter.
Continue to Overriding JCL on page 226.
Update event auto
reply segments
Enter.
Continue to Defining Auto Replies on page 160.
Update event
logical resources
Enter.
Continue to Defining Resources for an Event on page 274.
Update event
condition codes
Enter.
Continue to Condition Codes on page 143.
62
4 Events
Desired Result
Action
Update the
OCCURS clause
for an event
Enter.
Update the WHEN

conditions for an
event
Enter.
Continue to Defining an OCCURS Clause on page 121.
Continue to Defining a WHEN Condition on page 139.
Defining an Event Template

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

1
Access the Event Master Definition screen for the type of event that you want to
create, as described in Accessing the Event Definition on page 58:
ASG-Zeke
Command ===>
Event Master Definition
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: Y
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: ABC Usrid: ASGTEST DRL: 2
System: SYS1
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: ASGJOBABC
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
JESQ (Y, D=dynamic):
Class:
Pri: 0
CMS:
Ftype:
63
In the Event Name field, enter a name for the template (which is used for selecting
the template to create a new event).
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.
Complete the fields that you want to have common values that are defined by default
for all events that you create using the template. See these procedures for more
information on the fields you can define for each event type:
See Defining a Job Event on page 69.
See Defining a Message Event on page 86.
See Defining a Command Event on page 89.
See Defining a REXX Event on page 93.
See Defining a Work Center on page 151.
Press Enter to save the event template; Zeke assigns it a unique event number.
Optional. ASG recommends that you deactivate the event template by issuing the
DEACT primary command.
Note:
Although it is not necessary to deactivate a template (because templates cannot be

scheduled), ASG recommends that you perform this step so that you cannot
schedule a new event that has been created from a template until you activate the
event.
64
If you want each new event created from this template to share the same OCCURS
clause, perform the procedure, Defining an OCCURS Clause on page 121.
If you want each new event created from this template to share the same WHEN
conditions, perform the procedure, Defining a WHEN Condition on page 139.
4 Events
Creating an Event From a Template

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

1
Access the Add Event Record Function screen, as described in Accessing the Event
Definition on page 58 for details:
ASG-Zeke
Option ===>
Use Template: Y
1
Job
2
Msg
3
Pcom
4
Work
5
Vcom
6
Zcom
7
Scom
8
REXX
Add Event Record Function
Add
Add
Add
Add
Add
Add
Add
Add
a
a
a
a
a
a
a
a
Job Event
Message Event
Pcom Event
Work Center Event
Vcom Event
Zcom Event
Scom Event
REXX Event
Template
JCLTEMPLATE
MSGTEMPLATE
PCOMTEMPLATE
WORKTEMPLATE
VCOMTEMPLATE
ZCOMTEMPLATE
SCOMTEMPLATE
REXXTEMPLATE
Press PF3/PF15 key to abort the Add request
In the Use Template field, enter Y to indicate that you want to create the new event
from an existing template.
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.
On the Option line, enter the option for the type of event that you want to define.
To view a list of existing templates for a specific event type, access the Event
Master Selection Criteria screen (see Accessing the Event Definition on page 58),
and enter Y in the Template field next to the event type.
Note:
If you have multiple templates defined with the same event name and type, Zeke
uses the template with the lowest event number. For example, if you have a job
event template named JOBTEMPLATE that is assigned event number 12, and
another job event template named JOBTEMPLATE this is assigned event number
34, Zeke uses the template with the event number 12.
65
The Event Master Definition screen for the selected event type is displayed in
Update mode (this example illustrates a job event):
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
Class:
Pri: 0
CMS:
Ftype:
All of the information in the template definition is copied to the new event (except
that Zeke resets the Template field in the new event to N).
66
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).
Press Enter to save the event; Zeke assigns it a unique event number.
Optional. If the event template was deactivated, activate the event by issuing the
REACT primary command. Activating the event enables it to be scheduled.
Optional. Perform the procedure, Defining an OCCURS Clause on page 121 to

specify any additional event scheduling criteria.
Optional. Perform the procedure, Defining a WHEN Condition on page 139 to

specify any event dispatching prerequisites.
4 Events
Copying an Event
If you want to define an event that is similar to an existing event, you can create the new
event from a copy of the existing event.
Note:
If you plan to create numerous, similar events, ASG recommends that you create and use
an event template. See Creating an Event From a Template on page 65 for details.
To create a new event from a copy of an existing event

1
Access the Event Master Definition screen (see Accessing the Event Definition on
page 58) for the event that you want to copy:
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: CGCJOBA
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
Pri: 0
CMS:
Ftype:
To copy only the basic EMR (as displayed on this screen), OCCURS clause (i.e.,
scheduling criteria), and WHEN conditions (i.e., dispatching prerequisites), enter
COPY on the Command line.
Or
To copy the entire EMR, enter COPYALL on the Command line.

3
Press Enter. Zeke displays this message:

Z041I EVENT xxxxxx HAS BEEN COPIED TO EVENT yyyyyy
where xxxxxx is the original event number, and yyyyyy is the new event
number. Make note of the new event number.
67
Caution! After the copy is completed, Zeke continues to display the original event (that
was used to create the new event). To avoid inadvertently changing the original
event, access the newly created event before you attempt to make any changes.
4
To access the new event:

a
In the Event field, specify the new event number.
Press F2.
Note:
Zeke automatically deactivates the new event.

c
Edit the event information (as necessary), and press Enter.
Press F3 to return to the Event Master Directory screen.
Locate the new event in the directory.
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.
Edit the event information (as necessary), and press Enter to save the changes.
Note:
If you used this procedure to copy a template, Zeke resets the Template field to N. If
you want the new event to be a template, set this field to Y.
68
4 Events
Defining a Job Event

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

1
Access the Event Master Definition screen for job events, as described in Accessing
the Event Definition on page 58.
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: CGCJOBA
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Pri: 0
CMS:
Ftype:
Complete these fields (as applicable) to define the job event:

Field
Description
Template
Indicate whether you are defining a message event template. The valid
values are Y and N. See Defining an Event Template on page 63 for more
information.
Desc/Desc2
Specify a description of the job event. This description is displayed on

summary screens and printed on reports.
Event Name
Specify the name of the job event. The event name is displayed on Zeke
online screens and reports, and can be used as selection criteria. The event
name also can be specified in end-of-event (EOE), abnormal-end-of-event
(AEOE) and end-of-group (EOG and AEOG) WHEN conditions.
69
Field
Description
Usrid
Specify the user ID (up to eight characters long) for the user authorized to
access the job event.
Since Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (upper, lower, or mixed).
Note:
This user ID is for Zeke internal security only.
System
Specify the system or pool that owns the job event (which can be associated
with only one system).
Note:
This is the system where the event is dispatched, and not necessarily the
system where the EMR was defined.
Verload
Specify the number of versions of this job event that Zeke loads during
schedule build. The valid values range from 0 through 32767. The default
value is 0.
For example, if Verload is set to 3, Zeke adds EMRs to the schedule for
three versions of the event during schedule build (i.e., versions 1, 2, and 3).
If Verload is set to 0, then only one version of the event (version zero) can
be in the schedule at a time.
If Verload is set to 1, Zeke loads only one version during the schedule
build, but you can use the ZADD operator command to add multiple
versions (up to 32,767) to the schedule after the schedule load.
Note:
ASG recommends that you run no more than 1,000 versions of a single
event.
See Creating Multiple Versions of an Event on page 76 for details on
multiple event versions.
Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of
events being scheduled unintentionally during the next schedule build.
70
4 Events
Field
Description
Sched
Specify the normal schedule time for the event. The default value is 00:00
(i.e., the event is dispatched according to WHEN conditions instead of by
time).
See Specifying a Schedule Time on page 73 for a detailed explanation of
schedule time.
Control
Specify the code that indicates whether the Zeke dispatches and tracks the
job event as a Zeke-controlled event.
Note:
Zeke does not support multiple jobs as a single event. You must define
each job as a separate event. Zeke considers any additional jobs in the
same event as nonZeke jobs.
These are the valid codes:
Y
Default. Zeke recognizes the job event as a Zeke-controlled job.

Zeke-controlled jobs are tracked throughout their entire execution.
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 events successors).
71
Field
Description
Tapes
Specify the number of physical tape drives that the job event requires. Zeke
dispatches the event when the specified number of drives are available. If it
becomes time to dispatch the event, and the required drives are not free,
Zeke indicates that the event is waiting on drives.
You can enable Zeke to calculate this value automatically through the
Calctap generation option (see Tape Options on page 308), or you can
enter a value. The valid values range from 0 through 255. The default
value is 0.
Note:
If you keep the default value (zero), but tapes are required, then operator
intervention might be necessary the first time the event runs under Zekes
control.
If the Calctap generation option is set to Y, then Zeke automatically
calculates the number of tapes based on the last time the job ran. Zeke
displays an asterisk (*) next to the value if is Zeke-calculated.
You also can enter a Tapes value that overrides the Zeke-calculated
number.
Note:
If Calctap is set to Y, and you manually override the Zeke-calculated
value, then Zeke does not calculate the tape value again until you reset the
Tapes value to 0. To reset the tape value, enter three blank spaces in the
Tapes field.
Secgroup
Valid for z/OS job events only. Specify the security group (up to eight
characters long).
If the SecULock generation option is enabled, you cannot update this field.
If the SecUInit generation option is enabled, Zeke automatically populates
this field. (This overrides any entered value or value obtained from an event
template.)
If the RepJGrp generation option is enabled, Zeke replaces the
GROUP= keyword parameter on the JOB card with this value when the
job is submitted.
For more information on these generation options, see the ASG-Zeke
Scheduling for z/OS Reference Guide.
Job
72
Specify the name of the job event in the JCL. The jobname displays on Zeke
online screens and messages, and is used by Zeke to track the event during
execution. This value must match the jobname on the job card for accurate
tracking.
4 Events
Field
Description
Class
Specify up to six job classes for the job event. When the event is ready to
run, Zeke selects an initiator according to the defined classes. This field is
valid only if the generation option DispSel is set to Y (i.e., the default).
If you do not specify a class, then Zeke uses the value of the DefDspCl
generation option.
If no value is defined for the DefDspCl generation option, then Zeke selects
any free, defined initiator. See Defining Initiators to Zeke on page 262.
JCL
Specify the JCL source library and member information.

See Retrieving JCL from the Zeke Database on page 84 for more
information about JCL sources.
See Overriding JCL on page 226 for more information on making
one-time JCL overrides.
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.
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.
Perform the procedure Defining an OCCURS Clause on page 121 to specify when
Zeke schedules the job event.
Perform the procedure Defining a WHEN Condition on page 139 to specify any
prerequisites that must occur before Zeke dispatches the job event.
Specifying a Schedule Time

Schedule time is an optional dispatching prerequisite that must be met before Zeke can
dispatch an event. The schedule time fields are: Sched, Early, Latestart, Lateend,
Mustend, and Notafter. If the precise time that Zeke dispatches the event is not important,
then you can leave these fields blank (i.e., 00:00). However, if Zeke must dispatch the
event by a certain time, or cannot dispatch the event after a certain time, or if the event
must finish by a certain time, you use the schedule times fields to place restrictions on the
time.
73
Note:
For an explanation of Zekes 48-hour clock (known as DaySpan), which lets you
schedule according to a logical day, see Logical Day (48-hour Clock) on page 182.
Use this table to help you to determine how to define the schedule time fields to meet
your scheduling requirements for an event:
Desired Result
Action
Schedule the event at a

specific time
In the Sched field, specify the normal schedule time for the event.
Set the earliest time Zeke

can dispatch an event
In the Early field, specify the earliest time that Zeke can dispatch the
event. Zeke dispatches the event at its early time as long as the
WHEN conditions are satisfied. When multiple events are eligible to
be dispatched early, Zeke dispatches the events by their schedule
time sequence.
If you specify a time value greater than 24:00, Zeke processes the
event the next day. The default value is 00:00 (which indicates
that Zeke schedules the event according to WHEN conditions
instead of by time).
For example, you could set an event to run normally at 12:00 P.M.,
but also enable it to run as early as 11:00 A.M., if an initiator is
available.
Note:
You can use the early time to schedule a group of related events that
normally run together, or are dependent on each other. Specify the
same early time for each of the events, and specify the schedule
time for each event in the required sequence. If the events become
eligible to be dispatched early, then Zeke still processes the events
in the correct sequence. This also makes the SCHEDULE command
output more easy to read.
Set the time the event
In the Mustend field, specify the latest time the event can complete
must complete processing processing. Prior to dispatch, Zeke adds the current system time to
the events average duration. If the result is greater than the Mustend
time, Zeke issues a console message and removes the event from the
dispatch queue.
For example, lets suppose the Mustend time is 14:00, the system
time is 13:00, and the average duration of the event is two hours.
Because the event would not complete until 15:00, Zeke does not
dispatch event.
74
4 Events
Desired Result
Action
Set the latest time Zeke

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

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

considers an event as late
(based on its end time)
In the Lateend field, specify the time by which the event must finish.
The valid values range from 00:00 through 47:59. The event
is flagged as late if the current time is past the Lateend time, and the
event has not completed yet. (If the Lateend time is reached before
the event has completed, Zeke issues message Z0302I.)
Zeke predicts whether an event might not be completed before its
Lateend time (based on its average duration).
If an event is projected to finish late, Zeke does not prevent the
event from being dispatched until the events Mustend time is
violated.
If an event is projected to finish late, Zeke does not flag the
event as late until the events Lateend time is reached.
75
Desired Result
Action
Note:
If the Zeke generation option PriLate is set to Y, Zeke dispatches
late events before other events that are not late (regardless of the
schedule time).
Creating Multiple Versions of an Event

You can define an event to have multiple SQRs with the same schedule date. These are
referred to as versions of the event. An event can have up to 32,767 versions; however,
ASG recommends running no more than 1,000 versions of a single event.
Each version of an event operates independently of all other versions of the same event.
For example, you can add a JCL override for one version without affecting other versions
of the same event.
Each version of an event shares the same OCCURS clause, but can have different WHEN
conditions. You can issue Zeke operator commands that select events by version number
for processing. You also can define WHEN conditions to trigger based on version
numbers.
Multiple versions of the same event all have the same jobname; therefore, they cannot
execute concurrently due to JES limitations. (Zeke provides a user exit, ZEKE02OX, to
enable you to change the jobnames while the events are added to the schedule. See the
ASG-Zeke Scheduling for z/OS Installation Guide for more information on ZEKE02OX.)
You use the Verload field on the Event Master Definition screen to define the number of
versions for an event. Then, you can define WHEN conditions based on a specific version
number of the event.
Defining a Externally Submitted Job Event (JESQ)

You can define job events that will come from an external source. These events do not
have JCL associated with them; instead, their EMRs indicate that the JCL is contained in
the JES job queue. This enables a job event to originate from any source, and enables
Zeke to dispatch and track the event just like any other Zeke event.
To define an externally submitted job
76
Access the Event Master Definition screen for a job event, as described in
Accessing the Event Definition on page 58.
Specify the information indicated in Defining a Job Event on page 69.
4 Events
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
Indicates that Zeke must create the events 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.
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 SQRs JCL source to, or from, JESQ.
If you change an EMRs JCL source from JESQ to a different JCL source,
while an existing associated SQR has JESQ as the JCL source, the SQR does
not dispatch or track the JESQ job.
JESQ Job Processing

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

If Zeke cannot locate a matching SQR, and if the EMR is set to JESQ=D, Zeke
dynamically adds an SQR to the schedule. In this case, the JES job ID of the JES queue
job is added to the newly created SQR, and this SQR becomes the only one that can
dispatch the job.
For triggering purposes, an event defined with JESQ=D ignores version numbers; the
event triggers, and is triggered by, another event (regardless of that events version
number).
If you have an EMR defined with JESQ=D, and the job abends, you must refresh the
SQR that is in a failed status before resubmitting the job to the JES queue. Otherwise,
Zeke dynamically adds a new SQR when the job is resubmitted.
Held Jobs
A job can be submitted to the JES queue on hold (or not on hold). If the job is not on hold,
Zeke places it on hold, and re-queues the job to the JES job queue (where it can be
controlled by the JESQ event). Zeke dispatches a held job by releasing it from the JES
queue.
If the JES queue contains a held job with a matching jobname, Zeke releases it. If there
are multiple matching jobs, Zeke dispatches the job with the lowest JES job ID. If there is
no matching held job, the event remains in the dispatch queue until a matching job arrives
(or until the event is removed from the dispatch queue). In this state, Zeke assigns the
event the event reason code JESQ Held Job Wait in Schedule View and in ZD
WAIT operator command output.
If a dynamically created SQR is deleted before it dispatches and releases the held job, the
held job is orphaned. In this case, you must manually release the held job. Zeke then
places the job on hold, re-queues it, and dynamically creates a new SQR for it.
Note:
You can use the ZPLEX DISPLAY operator command to display the held jobs in the JES
queue (and whether they have been assigned to an SQR).
The JES queue is scanned every 30 seconds for new held jobs, so it could take up to 30
seconds for Zeke to dispatch or dynamically create a new SQR for a new JES queue job.
JESQ Processing Requirements
78
The EDBindex generation option must be set to Y (see page 311). Zeke matches
the jobname to a JESQ event using the EDB index; therefore, after you add JESQ
job event (or change the event to JESQ), Zeke does not dynamically add or identify
the SQR on another system until the other system processes the EMR
communication record.
4 Events
SVC 34 (console 0) is used to issue the JES commands to release a held job and to
requeue an job that is not on hold. The Zeke started task and the Zeke IEFUJI SMF
exit must have authority to issue these commands.
The system that dispatches the job must have access to the JES queue that contains
the job. Ensure that the system ID in the SQR is a system (or pool of systems) that
has appropriate access.
JESQ Processing Considerations
If the DispSel generation option is set to Y (see page 299), Zeke does not dispatch a
JESQ event until an initiator of the specified class is available. (The initiator classes
are those specified in the EMR, not those defined on the JES job card.)
The ZSCAN, SCAN, JCLR, and JPREP commands in Schedule View are not
supported for SQRs that have the JCL source JESQ.
You cannot create override JCL from OpsCentral.
Routing a Job Event to Another System or Platform

Zeke can route or send the JCL for a job event to another system or platform for
execution. When the job has finished executing, the data or information can be sent back
to the original Zeke for triggering other events. For example, you can route JCL from one
z/OS to another, or from a z/OS system to an AS/400.
Zeke remote jobs support condition code processing (except if *Rmtlim is specified,
see below) as well as logical resource usage. Zeke supports all trigger types except
dataset name and variable name, and updates all accounting information in the EMR.
Zeke does not support auto replies for remote jobs and NOTDURING conditions that
reference remote jobs.
To route a job to another system or platform, you specify the target and platform
information in the EMR.
To route a job event to another system or platform

1
Ensure that the Posid and Netregid generation options for your system are set
appropriately, with Posid set to Y, and a valid, nonblank Netregid. (Generally, your
system programmer defines these options. See Job Networking Options on
page 317.)
79
Accessing the Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: CGCJOBA
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Pri: 0
CMS:
Ftype:
Specify the information indicated in Defining a Job Event on page 69.

Note:
If the remote system is secured, the Usrid field must specify a valid user ID on the
remote system.
4
Complete these fields to specify the routing information:

Field
Description
Target
Valid for job events only. Specify a value to indicate how to handle routing.
Note:
Although the Target field appears in the EMR screen for all event types, it
currently applies to job events only, and defaults to *LOCAL for all other
event types.
These are the valid values:
netregid
Indicates the OASIS/DMS logical name (Netregid) for

the remote Zeke or Zeke Agent system.
Note:
This is the only type of remote processing where the
dispatching and execution platform can be different
from each other.
80
4 Events
Field
Description
Zeke dispatches an individual job to OASIS/DMS, which
routes the job to the specified remote system. The remote
system submits the job for execution, and monitors it).
The level of communication between the dispatching
Zeke and the job on the remote system is based on the
jobs condition code processing requirements.
Note:
If the remote system is a Zeke Agent defined as a
download agent, then the SQRs that specify this system
are downloaded via OASIS/DMS and then executed and
tracked on the remote system. See Downloading a Job
Event to Zeke Agent on page 83 for more information.
*R or *REMOTE
Indicates that the job instructions must contain the

necessary Network Job Entry (NJE) statements or
parameters to route the job. Zeke dispatches and submits
the job on the same system; then, NJE routes the job to
the remote system for monitoring.
The level of communication between the dispatching
Zeke and the remote system is based on the jobs
condition code processing requirements.
*RF or
*RMTFUL
Similar to *REMOTE. Zeke dispatches and submits the

job on the same system. Then NJE routes the job to the
remote system. The executing job waits at each step for a
reply from the dispatching Zeke before continuing. If for
any reason the remote job loses communication with the
dispatcher, it is cancelled at the remote site before trigger
information is lost. This option can result in significantly
more network traffic than *REMOTE. The dispatching
Zeke maintains maximum control over the job.
*RL or
*RMTLIM
Similar to *REMOTE. Zeke dispatches and submits the

job on the same system; then, NJE routes the job to the
remote system. The remote job sends the requested
triggering information back to the dispatching Zeke, but
executes independently. The dispatching Zeke monitors
the execution of the remote job, but does not control it.
Note:
This type of remote job cannot be cancelled due to
condition code processing.
81
Field
Description
Note:
The values *REMOTE, *RMTFUL, and *RMTLIM can be used only when
Zeke routes the job to a remote system on the same platform as the
dispatching system. If you want to route a job from a z/OS system to a
system on VSE, AIX, or AS/400, you must specify netregid as the target.
If you want to route a job to the same platform (e.g., from one VSE system
to another), you can specify either netregid or *REMOTE as the target.
Note:
previous field on the EMR), to prevent a user from overtyping data intended
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.
82
are adding the event, Zeke assigns a unique event number.
4 Events
Perform the procedure, Defining an OCCURS Clause on page 121, to specify

when Zeke schedules the event.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
Downloading a Job Event to Zeke Agent

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

1
Ensure that the Posid and Netregid generation options for your system are set
appropriately, with Posid set to Y, and a valid, nonblank Netregid. (Generally, your
system programmer defines these options. See Job Networking Options on
page 317.)
Access the Event Master Definition screen for a job event, as described in Specify
the information indicated in Defining a Job Event on page 69.Accessing the
Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
83
Note:
If the remote system is secured, the Usrid field must specify a valid user ID on the
remote system.
3
Complete these fields to specify the remote Zeke Agent:

Field
Description
Target
Specify the Netregid of the remote Zeke Agent.

Be sure that the specified Zeke Agent is defined in the Zeke database as a
download agent (see Defining Schedule Download Agents on page 327).
Platform
Specify the operating system where the remote Zeke Agent resides. The
default value is the value of the DefPltfm generation option. Enter UNIX.

Retrieving JCL from the Zeke Database

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

1
84
Verify that ZEKEJCL is defined as a JCL source type. See JCL Source Options on
page 313.
4 Events
Access the Event Master Definition screen as instructed in Accessing the Event
Definition on page 58.
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 60
Desc: TEST JOB ASG
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
Enter JCL on the Command line, and press Enter. The JCL screen is displayed. (If
no JCL exists, the screen is displayed in Add mode):
ASG-Zeke
JCL
EDIT Event 00060
Command ===>
Scroll ===> PAGE
****** **************************** Top of Data ****************************
==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF).
==MSG>
Data has valid standard numbers.
==MSG> -Warning- The UNDO command is not available until you change
==MSG>
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 *
From this screen (which is controlled by the ISPF Text Editor), use standard ISPF
commands to add, delete, or edit the JCL.
Press F3 to save the changes and return to the Event Master Definition screen.
85
Defining a Message Event

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

1
Access the Event Master Definition screen for message events, as instructed in
ASG-Zeke
Command ===>
BROWSE
Event===>
Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT
OCCURS PATH PRED REACT RESOURCE SUCC WHEN
Template: N
Permanent: N
Milestone: N
Evt: 482
Desc: OFFSITE CASH RUN TAPE
Type: MSG Desc2: MONTHLY
Event Name: ZECASTPOFF
App:
Grp:
Usrid:
DRL:
System: ZEQA
Cal: A
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
Route: (3)
Oper
Oper
Oper
Oper
Oper
Oper
86
Msg1: END TAPE OFFSITE; DEPENDENT ON GOOD END OF JOB

Msg2:
Msg3:
Msg4:
Msg5:
Msg6:
4 Events
Complete these fields to (as applicable) to define the message event:

Field
Description
Template
information.
Desc/Desc2
Specify a description of the message event. This description is displayed on

Event Name
Specify the name of the message event. The event name is displayed on
Zeke online screens and reports, and can be used as selection criteria. The
event name also can be specified in end-of-event (EOE and AEOE) and
end-of-group (EOG and AEOG) WHEN conditions.
Usrid
access the message event.
Because Zeke supports mixed-case user IDs, be sure to specify the desired
Note:
System
Specify the system or pool that owns the message event (which can be
associated with only one system).
Note:
Verload
Specify the number of versions of this event that Zeke loads during
value is 0.
If Verload is set to 1, then Zeke loads only one version during the schedule
Note:
event.
87
Field
Description
Note:
Sched
time).
schedule time.
88
Route
Specify the user-defined route code that corresponds to the alternate

console route code.
Oper Msg
Specify the message text (up to six lines long) to issue to the system
console.
Field
Description
App
associated with the message event.
Grp
associated with the message event. This field is a subset of the application ID.

4 Events
Defining a Command Event

A command event issues specified commands to a specified destination. These are the
types of command events that you can define in Zeke:
Type
Description
PCOM
VSE only. Any valid POWER command.
SCOM
Any command that can be issued from a console. You can specify an unlimited
number of commands in an SCOM event.
Zeke makes a security call for each individual command line in an SCOM event.
See Security Calls on page 372 for more information.
VCOM
Any valid VM CP command.
ZCOM
Any valid Zeke operator command (or a combination).
SCOM events are the most versatile command type. You can use SCOM events to issue
any type of console command, and including any of the other command event types (i.e.,
ZCOM, PCOM, and VCOM), which you can use only to issue particular types of
commands.
This procedure describes how to define an SCOM event. You define all of the other
command event types in a similar manner.
89
To define and maintain a system command event

1
Access the Event Master Definition screen for SCOM events, as instructed in
ASG-Zeke
Command ===>
BROWSE
Event===>
Primary Commands: ADD BACK BROWSE COPY COPYALL DEACT DELETE DOC EDIT NEXT
OCCURS PATH PRED REACT RESOURCE SUCC TOPPAGE WHEN
Template: N
Permanent: N
Milestone: N
Evt: 458
Desc: RESUB MJP JOBS
Type: SCOM Desc2:
Event Name: LJDSCOM
App:
Grp:
Usrid:
DRL:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 08:30
Early:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
Control: Y
__
__
__
__
__
__
__
90
Code =>
Code: C
Code: C
Code: Z
Code: Z
Code: Z
Code: Z
Code: Z
C=Sys Cmd R=Sys Response Z=Zeke Cmd

001 D T
002 $DI
003 ZINFO
001 ZADD EV 27 VER 1 REBUILD
V=VM Cmd
P=VSE/POWER Cmd
Complete these fields (as appropriate) to define an SCOM event:

Field
Description
Template
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
4 Events
Field
Description
Usrid
access the command event.
Note:
System
Specify the system or pool that owns the command event (which can be
Note:
Verload
value is 0.
If Verload is set to 1, then Zeke loads only one version during the schedule
Note:
event.
Note:
91
Field
Description
Sched
time).
schedule time.
Code
Line 001
through line
005
Indicate the type of command. These are the valid values:

C
System command
VSE/POWER command
System response
VM command
Zeke command
Specify up to 60 characters of commands or responses per line. Only the

first line is required.
To access additional command lines, position the cursor on any SCOM line
(after the first one), and press Enter. The screen is redisplayed with a new
blank line. (Any existing SCOM lines below the cursor are hidden.) Repeat,
as necessary, to add additional lines. (The new lines are added to the EMR,
and the existing lines are redisplayed.)
When you enter multiple Zeke operator commands on the same line, you
must include the command prefix on the first command only. For example,
if your command prefix is ASG, specify multiple commands in an SCOM
event like this:
C 001 ASGZAD EV 12 HOLD ZAD EV 89 HOLD
When you are using variable substitution in an SCOM event, the length of
each line cannot be greater than 60 bytes (including the variable values).
For example, lets suppose you submit this SEND command from an
SCOM event:
SE THIS IS A TEST TEST TEST TEST TEST.,USER=($ABCVAR)
Lets suppose that the value of the variable named $ABCVAR equals
ABCABCABCABCABC. The length of the command in the example is
exactly 60 bytes; however, when Zeke performs variable substitution for
$ABCVAR, the length of the line will exceed 60 characters.
92
4 Events
Field
Description
App
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.

Defining a REXX Event

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

1
Access the Event Master Definition screen for REXX events, as instructed in
ASG-Zeke
Command ===>
EDIT
Event===>
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
Target: *LOCAL
Verload: 0
Latestart:
Early:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
Control: Y
REXX exec: REXX1
Class: A
Pri: 1
Argument:
Complete these fields (as appropriate) to define a REXX event:

Field
Description
Template
information.
Desc/Desc2
Specify a description of the REXX event. This description is displayed on

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
Usrid
access the REXX event.
Note:
94
4 Events
Field
Description
System
Specify the system or pool that owns the REXX event (which can be
Note:
Verload
value is 0.
Note:
event.
Note:
Sched
time).
schedule time.
95
Field
Description
Control
Specify the code indicating whether this event is executed and tracked as a
Zeke-controlled event. These are the valid values:
REXX exec
Default. Zeke recognizes the event as a Zeke-controlled event.

Zeke-controlled events are tracked throughout the entire execution.
A Zeke-controlled REXX event is completed with either a status of
EOE or AEOE. An EOE status is assigned if the exec completes with
a return code of 0.
Zeke does not recognize this event as Zeke-controlled. A REXX

event that is not Zeke-controlled is completed with a status of EOE.
NX
Zeke recognizes the event as a nonexecutable Zeke-controlled event.
Specify the name of the member that contains the REXX EXEC. The
dataset that contains this member must be defined in the SYSEXEC or
SYSPROC DD concatenation of the OASIS/ECF address space started
task.
Zeke calls the REXX program as a function. A RETURN statement with an
explicit return code is required:
If the return code is 0, Zeke considers the REXX event to be
successful.
If the return code in the RETURN statement is nonzero, is unspecified,
or if the program exits without a RETURN statement, then Zeke
considers the REXX event to have failed.
Note:
Sample member REXSAMP in the Zeke SALTINS0 library contains a
sample REXX program for maintaining control over the event status (i.e.,
EOE or AEOE).
96
Class
Specify the OASIS/ECF EXEC class associated with the REXX EXEC.
The valid classes range from A through Z, and from 0 through 9.
Pri
Specify the OASIS/ECF EXEC queue priority. The valid values range from
1 through 9 (where 1 is the highest priority). The default value is 5.
The priority value is used only if there is no free ECF task for the specified
class when Zeke dispatches event. In this case, the request is queued, and
this priority is used to determine which EXEC for the class executes when
a task is available.
Argument
Specify the argument string to pass to the REXX EXEC when Zeke
dispatches the REXX event. The strings values can be parsed into local
REXX variables in the EXEC.
4 Events
Field
Description
App
associated with the REXX event.
Grp
associated with the REXX event. This field is a subset of the application ID.

Defining a Recurring or Permanent Event

You can define an event to occur multiple times across a particular schedule run, or to
occur across every schedule (until it is removed from the schedule). These events are
referred to as recurring events and permanent events, respectively.
Recurring Events
A recurring event occurs more than once in a single schedule period. For example, a
message that is issued to the operator every hour is a recurring event. You define the
frequency or time interval and the number of occurrences. You can use a recurring event
to trigger other events each time it runs, or only on the first or last occurrence.
Not After Time

If a recurring event has a not after time (Notafter) time specified, and the calculated
start time is greater than the Notafter time, Zeke does not reschedule the event, and
considers it done.
WHEN Conditions
Zeke resets a recurring events WHEN conditions at dispatch time, not at completion
time. The events WHEN conditions can be satisfied even while the event is running.
Recurring Job Status

Recurring events that have reached a Done status at least once, and are scheduled to run
again, display in the output for both the ZD DONE and ZDISPLAY operator commands.
97
Permanent Events
Zeke never removes a permanent event from the schedule, so the event always is
available to respond to triggers (even during schedule load processing). A permanent
event can run an unlimited number of times. You activate a permanent event by adding it
to the schedule with the ZADD operator command. The event occurs across every
schedule period until you remove it using the ZDELETE operator command.
Zeke processes permanent events in the same manner as recurring events, with these
exceptions:
Zeke forces the OCCURS clause to REQUEST.
Zeke ignores nonworking day options in the calendar.
Only one version can be active (the Verload field is set to 0).
The event can be triggered by any date. The values of the Zeke generation options
TrigDt, DsnTrig, and RemTrig are treated as any (i.e., A or TA).
Zeke ignores any MultHit generation options.
Schedule Time
Zeke uses only the schedule time (Sched) to time-satisfy a permanent event, and ignores
any other time specifications (e.g., early time).
Each time Zeke executes (and then reschedules) a permanent event, the run date
increments, so that the schedule time stays under 24:00. (Normally, when the schedule
time passes 24:00, the run date increments and the schedule time is reduced by 24 hours.)
You can set the schedule time, or any other time that increments at rescheduling (e.g.,
Late, Mustend, or Notafter), above 24:00 in the EMR for a permanent event. The first
time Zeke reschedules the event, the run date increments so that the updated schedule
time is below 24:00.
Freqcalc is S (Schedule Time)

When Zeke reschedules a permanent event (with the Freqcalc value set to S) Zeke
updates the events run date and schedule time to its previous run date and schedule time
(added to the events 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 events run date and schedule time
are still likely to be in the past. So, Zeke immediately considers the event to be
time-satisfied (TIMEOK), instead of waiting. Zeke immediately considers the event to be
time-satisfied every time the event is rescheduled, until its run date and schedule time
catch up to the system date and time.
98
4 Events
When a permanent event (with the Freqcalc value set to S) has a run date in the future, is
forced to run, and then is rescheduled, the events updated run date and schedule time
remain in the future. The event becomes time-satisfied when the system date and time
reach the events updated run date and schedule time.
Freqcalc is C (Clock Time)

When Zeke reschedules a permanent event (with the Freqcalc set to C), the events run
date and schedule time are set to the current system date and time (added to the events
frequency).
When Zeke reschedules a permanent event (with the Freqcalc value set to C) that has a
run date in the past, the events run date and schedule time are updated to the current
system date and time (added to the events 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 events run date and schedule time are reset to
the current date and time (added to the events frequency). The event becomes
time-satisfied again when its frequency has expired, instead of waiting for its future run
date (which is reset to today's date).
To define a recurring or permanent event

1
Access the Event Master Definition screen, as instructed in Accessing the Event
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 3
Control: Y Tapes: 0
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
99
Complete these fields (as applicable) to define a permanent or recurring event:

Field
Description
Permanent Indicates whether to retain the event in the schedule permanently (i.e.,
indefinitely). These are the valid values:
Times
Default. Zeke processes the event for each schedule run according
to the OCCURS clause.
The event must be added to the schedule using the ZADD operator
command. After you add the event, it remains in the schedule
(across schedule runs) until you delete the event using the
ZDELETE operator command.
Specify the number of times Zeke dispatches the event per schedule run.
For a recurring event, the valid values range from 2 through 9999.
For a permanent event, you do not specify a Times value; Zeke considers the
number of times to be unlimited. Zeke automatically sets the value to 000.
If you later update a permanent event to remove the permanent specification,
Zeke automatically sets the Times value to 1.
Freq
Specify the amount of time Zeke waits before dispatching a recurring event
again. To determine the next dispatch time, Zeke adds the Freq value to the
current system time or current schedule time (depending on the Freqcalc
value).
Note:
ASG recommends that you specify a Freq time and/or a WHEN condition for
permanent and recurring events.
If you set the Freq value to 00:00, Zeke immediately considers the recurring
or permanent event to be time-satisfied after each completion. When the
WHEN condition (if one exists) becomes satisfied, Zeke dispatches the event.
Note:
For a permanent event, Zeke sets the run date to the current system date
when the next schedule time passes 24:00.
100
4 Events
Field
Description
Freqcalc
Indicate how to calculate the next dispatch time for the recurring or permanent
event. These are the valid values:
Trig
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.
Zeke schedules the event by its start time, regardless of the time the
event actually runs. If the event becomes delayed for any reason,
Zeke dispatches any missed runs immediately.
Indicate how the recurring event satisfies WHEN conditions (i.e., serves as a
trigger) for other events.
Note:
This field is valid for recurring events only; permanent events trigger other
events on all occurrences.
A
Default. The recurring event triggers other events each time it runs.
The recurring event trigger other events only the first time it runs.
The recurring event triggers other events only the last time it runs.
For example, lets suppose that for a recurring event, you specify these values:
Times
24
Freqcalc S (schedule time)

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

Defining a Milestone Event

A milestone event is a significant event in an event flow (that includes
predecessor/successor relationships) that must process on time to avoid a significant
delay in the completion of the entire flow.
Events flagged as milestones are not processed any differently from other eventsthe
milestone flag simply makes these events more easy to identify in the event flow.
In Schedule View (ISPF only), milestone events are indicated by an asterisk in the
Milestone column.
102
4 Events
Note:
In OpsCentral, you can filter events that have been flagged as milestone events. You also
can view (graphically) the positions of milestone events in the event flow.
If you use ASG-Unified Management Architecture (herein called UMA), information
about Zeke milestone events can be sent to UMA automatically.
Through the Zeke server, Zeke communicates these milestone event statuses for display
in Zeke, from an OpsCentral client, or in a UMA dashboard:
Status
Description
n/a
(gray)
Indicates whether the milestone event is in the current schedule.
Normal
(green)
Indicates whether Zeke expects the milestone event to process normally in the
event flow.
Met
(blue)
Indicates whether the milestone was met successfully (i.e., the event completed
successfully within all of its time constraints).
Missed
(red)
Indicates whether the milestone event has failed or violated a time constraint
(according to its Latestart, Lateend, Notafter, or Mustend times).
At-risk
(yellow)
Indicates whether the milestone event is at risk because of a problem with a

predecessor (or other projected time violation).
You can define the criteria that puts a milestone event at risk through this variable
in the ZENVIRN file:
ZEKE_SERVER_MILESTONE_AT_RISK
(See the ASG-Zeke Scheduling for z/OS Installation Guide for details.)
This is an example of an alert that would be issued to OpsCentral if a milestone
were at risk because of a failed predecessor:
Milestone event 000060 2009134 ver 00001 JOBKAC is at risk due
to predecessor events:
Event 000083 2009134 ver 00001: Failed
103
Critical Path
Milestone events are an essential element in the concept of a critical path. The critical
path is the sequence of predecessor/successor events that will take the longest to
complete. The critical path represents the minimum amount of time to complete the event
flow from the event with the earliest start through the event that finishes last.
The critical path could change from time to time as events are completed ahead of or
behind schedule. Typically, delays along the critical path imply that additional time is
required to complete the event flow. This helps you monitor the completion of the current
schedule to ensure that there is no conflict with the start of the next schedule.
To define a milestone event

1
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
Default. Do not designate the event as a milestone.
Designate the event as a milestone, which Zeke flags in Schedule View and
OpsCentral.

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

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

Schedule View on page 191.
By executing the EVENT ADD/UPDATE batch utility and including the SCHENV
parameter. See the ASG-Zeke Scheduling for z/OS Reference Guide for more
information.
By issuing the ZALTER operator command and including the NEWSCHENV

keyword. See the ASG-Zeke Scheduling for z/OS Reference Guide) for more
information.
105
To specify a scheduling environment

1
Access the Event Master Definition screen as instructed in Accessing the Event
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 3
Control: Y Tapes: 0
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
In the SchEnv field, specify the name of the WLM scheduling environment (up to 16
characters long).
Note:
Zeke does not validate this name; an invalid name will cause JES to fail the job.
If you specify a scheduling environment, Zeke schedules the event and the event
waits in the dispatch queue until the scheduling environment becomes active (i.e.,
until the resource states defined in the scheduling environment are matched).
Note:
For a job event, you can insert this value in the JCL before the job is submitted to
JES. See JOB Card Override on page 315 for more information.
106

4 Events
OCCURS Clauses
The OCCURS clause specifies the day or days Zeke schedules an event. The
SCHEDULE function of the ZEKE utility program scans the Zeke database, and select
each event to process on the specified schedule date based on its OCCURS clauses.
Zeke schedules an event when the events OCCURS clause is true. For example, lets
suppose you define an event as OCCURS (MONDAY). When the SCHEDULE function is
processed on a Monday, the OCCURS clause is true. On any other day of the week, the
OCCURS clause is false (in this case, Zeke does not schedule the event).
See OCCURS Keywords on page 109 for a list and description of all OCCURS clause
keywords.
OCCURS Clause Format

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

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

An event can have more than just one OCCURS clause phrase.
For example, this event is scheduled every Monday and Thursday (the event is defined
with two OCCURS clause phrases joined by OR):
OCCURS (MONDAY OR THURSDAY)
107
The keyword OR indicates the event is scheduled when either clause is true.
The keyword AND indicates the event is scheduled only when both OCCURS clauses are
true.
Examples:
This event is scheduled every Monday during January:
OCCURS (MONDAY AND JANUARY)
This event is scheduled only when the current schedule date is Monday, and Thursday:
OCCURS (MONDAY AND THURSDAY)
Because this case is impossible, this OCCURS clause is invalid and Zeke never schedules
the event.
Grouping Multiple OCCURS Clause Phrases

In addition to AND/OR relationships between multiple OCCURS clause phrases, you can
group multiple OCCURS clauses to resolve one group of clauses before resolving the
next, higher group. You use additional sets of parentheses to group multiple clauses.
For example, lets suppose an event is scheduled for any Monday during the first month
of each quarter. The months are January, April, July, and October. You would specify the
OCCURS clause like this:
OCCURS (MONDAY AND (JANUARY OR APRIL OR JULY OR OCTOBER))
Zeke resolves the innermost group first. The inner group is true if the current month is
January or April or July or October. During any other month, the inner group is false.
Because the keyword AND joins the two clauses, Zeke schedules the event only if it is a
Monday in one of the named months.
You use additional sets of parentheses only to separate multiple conditions. For example,
Because MONDAY and TUESDAY are not multiple conditions, it is not necessary to
code the clause like this:
(WORKDAYS AND ((MONDAY) OR (TUESDAY)))
Instead, this clause is valid:

(WORKDAYS AND (MONDAY OR TUESDAY))
108
4 Events
OCCURS Keywords
You can use these symbols in an OCCURS clause that includes keywords:
Symbol
Description
Specifies an occurrence of a keyword. For example:
(period)
OCCURS (MONDAY.L)
Schedules on the last Monday of each month or period.

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

+
(plus)
Adds the specified number of days or workdays. You can use this symbol with the
period (.) keyword followed by L, or a value from 1 through 24. For example:
OCCURS (MONDAY.L + 3 DAY)
Schedules three days after the last Monday of each month or period.
OCCURS (MONDAY.L + 3 WDAY)
Schedules three workdays after the last Monday of each month or period.
(minus)
Subtracts the specified number of days or workdays. You can use this symbol with
the period (.) keyword followed by L, or a value from 1 through 24. For example:
OCCURS (TUESDAY.1 - 5 WDAY)
Schedules five workdays before the first Tuesday of each month or period.
OCCURS (EOM-2)
Schedules two days before the last day of each month.
You can use these keywords in an OCCURS clause:

Keyword
Description
DAILY
Schedules on any day that the SCHEDULE function runs, regardless of

whether the day is a workday, weekend, or holiday.
WORKDAYS
Schedules on any normal working day (not on holidays or weekends).
MONDAY
Schedules on Mondays.
TUESDAY
Schedules on Tuesdays.
WEDNESDAY
Schedules on Wednesdays.
THURSDAY
Schedules on Thursdays.
FRIDAY
Schedules on Fridays.
109
Keyword
Description
SATURDAY
Schedules on Saturdays.
SUNDAY
Schedules on Sundays.
WMONDAY
Schedules on working Mondays.
WTUESDAY
Schedules on working Tuesdays.
WWEDNESDAY
Schedules on working Wednesdays.
WTHURSDAY
Schedules on working Thursdays.
WFRIDAY
Schedules on working Fridays.
WSATURDAY
Schedules on working Saturdays.
WSUNDAY
Schedules on working Sundays.
JANUARY
Schedules if January. Use with AND. For example:

OCCURS (FRIDAY.L AND JANUARY)
Schedules on the last Friday in January.
110
FEBRUARY
Schedules if February. Use with AND.
MARCH
Schedules if March. Use with AND.
APRIL
Schedules if April. Use with AND.
MAY
Schedules if May. Use with AND.
JUNE
Schedules if June. Use with AND.
JULY
Schedules if July. Use with AND.
AUGUST
Schedules if August. Use with AND.
SEPTEMBER
Schedules if September. Use with AND.
OCTOBER
Schedules if October. Use with AND.
NOVEMBER
Schedules if November. Use with AND.
DECEMBER
Schedules if December. Use with AND.
EOM
Schedules on last day of the month.
EOM-xx
Schedules xx days before last day of the month.
4 Events
Keyword
Description
WEOM
Schedules on last working day of the month.
WEOM-xx
Schedules xx working days before last working day of the month.
DAY
Schedules on the specified day of the month.
DAY yy xx
Schedules on the specified day of the month if the relationship is true, where:
yy is an operator (LE, LT, GE, GT, NE, EQ) or period (.).
xx is a number ranging from 01 through 31, L, or L.
For example:
OCCURS (DAY LE 07)
Schedules on any day less than or equal to the seventh day of each
month.
OCCURS (DAY.5)
Schedules on the fifth day of each month.

OCCURS (DAY.L-1)
Schedules on the day before the last day of each month.

WDAY xx yy
Schedules on the specified workday of the month if the relationship is true.

yy is an operator (LE, LT, GE, GT, NE, EQ) or period (.).
xx is a number ranging from 01 through 31, L, or L.
For example:
OCCURS (WDAY EQ 04)
Schedules on the fourth workday of the month.

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

OCCURS (WDAY.L-1)
Schedules on the workday before the last workday of each month.

JDAY
Schedules on the specified day of the current year. JDAY uses the same
format as the keyword DAY, but its period is for the year. JDAY also can be
used to refer to the current Julian day in comparison phrases. For example:
OCCURS (JDAY LE 31)
Schedules on the first 31 days of the year.

OCCURS (JDAY.L)
Schedules on the last day of the year.
111
Keyword
Description
DATE xx
mm/dd/yyyy
Schedules on the specified date if the relationship is true, where:

xx is the operator (i.e., LE, LT, GE, GT, NE, or EQ).
mm/dd/yyyy is an actual date.
For example:
OCCURS (DATE LE 12/31/2012)
Schedules on any date less than or equal to December 31, 2012.

Note:
You also can use the date format dd/mm/yyyy if your OASISxx options
member specifies the start-up option DATE=DDMM.
MONTH
Schedules during the specified month. Use with AND. For example:
OCCURS (MONDAY AND MONTH.11)
Schedules if the day is Monday, and it is the eleventh month of the year.
MONTH.11 is November in a regular calendar, but could be different if
you are using a fiscal or user calendar.
OCCURS (TUESDAY AND MONTH.L)
Schedules if the day is Tuesday, and the month is the last fiscal month.
WEEK
Schedules during the specified week in a month or period. Use with AND.
For example:
OCCURS (MONDAY AND WEEK.3)
Schedules if the day is Monday and it is the third week of the month or
period.
FWEEK
Schedules during the specified week in the month or period that includes
Monday through Sunday. Use with AND. For example:
OCCURS (TUESDAY AND FWEEK.1)
Schedules if the day is Tuesday and is in the first complete week of the
month or period.
WDAYW
Schedules on the working days of the week. For example:

OCCURS (WDAYW.2)
Schedules on the second workday of each week, which is based on the

workdays and holidays specified in the calendar.
WFWEEK
Schedules during the specified full work week in the month or period that
includes all normal workdays in that week. Use with AND. For example:
OCCURS (TUESDAY AND WFWEEK.2)
Schedules if the day is Tuesday and is in the second week of the month
or period that includes all normal workdays.
112
4 Events
Keyword
Description
USEREXIT
Calls a user-written program during OCCURS clause processing. All Zeke

calendar table information is passed to the exit. The USEREXIT keyword
determines whether the event should be scheduled. For example:
OCCURS (USEREXIT TESTOCCUR)
Schedules if the user exit returns a response of true.

See the ASG-Zeke Scheduling for z/OS Installation Guide for more
information on OCCURS clause user exists, and on using this keyword.
EVERY xxx
DAYS
BEGINNING
mm/dd/yyyy
EVERY xxx
WDAYS FROM
mm/dd/yyyy
Schedules every xxx days beginning on the specified date. Zeke does not
schedule the event before the specified date.
Note:
Schedules every xxx workdays before and after the specified date (when
scheduling events for the future).
Note:
REQUEST
Zeke does not add the event to the schedule automatically. You must issue
the ZADD operator command to schedule the event.
REFEVENT
eventname/
number
Schedules according to the calendar (including nonworking days) and the

OCCURS clause of another event. If you update the OCCURS clause or
calendar for the referenced event, Zeke schedules all events that reference
the event according to the changes.
You can specify the event that you want to reference either by event number
or event name. Because an event name might not be unique in the Zeke
database, Zeke selects the first event that matches the event name for the
reference.
Caution! Event numbers are unique; however, because Zeke assigns the
event numbers automatically (and can reuse event numbers),
ASG recommends that you reference other events by event name
to avoid unintended references.
You can use this keyword in combination with other OCCURS keywords.
For example:
OCCURS (REFEVENT ASGJOB1 + 2 WDAY)
Schedules two workdays after the OCCURS of event ASGJOB1.
113
Keyword
Description
NOT
Schedules if the specified keyword condition is false. This keyword can be

used for a single condition or for a compound condition enclosed in
parentheses. For example:
OCCURS (NOT WORKDAYS)
Schedules on any day that is not defined to Zeke as a workday.

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

OCCURS (WORKDAYS AND NOT MONDAY)
Schedules on any working day that is not a Monday.

AND
Schedules if both of the specified conditions are true.
OR
Schedules if either of the specified conditions is true.
BEFORE
Schedules on the working day before the normal selection day (if the day is
a holiday or weekend).
AFTER
Default. Schedules on the working day after the normal selection day (if the
day is a holiday or weekend).
ON
Schedules on the normal selection day even (if normal selection day is a
holiday or weekend).
Note:
You use the keywords BEFORE, AFTER, and ON to schedule an event when it would normally
fall on a holiday or weekend. Place these keywords immediately after another keyword or
compound conditions enclosed in parentheses. If you do not specify BEFORE or ON, Zeke
schedules the event the day after a holiday or weekend (unless the Nwday field in the EMR
specifies differently). See Scheduling Events on Holidays and Weekends on page 118.
PERIOD
Schedules the event according to the specified period. For example:

OCCURS (MONDAY.L AND PERIOD.3)
Schedules on the last Monday in the third period of the calendar.

HOLIDAYS
Schedules on holidays.
Note:
To code an OCCURS clause with a relational reference to a holiday (e.g.,
(HOLIDAYS + 1 DAY)), you must set the Nwday field to O in the EMR,
which indicates to schedule the event on the nonworking day.
114
WEEKENDS
Schedules on weekends.
HOL/WEEK
Schedules on holidays and weekends.
4 Events
Keyword
Description
CALENDAR
Schedules based on the specified criteria, and according to the specified

special calendar. Use with AND. For example:
OCCURS (CALENDAR TEST1 AND WEDNESDAY)
Schedules only for the Wednesdays that are marked in special calendar
TEST1.
Schedules if the specified Zeke variable is true. Use with AND. For example:
VAR
OCCURS (VAR $SUE123 EQ OKAY AND PERIOD.2)
Schedules only if the value for $SUE123 is OKAY, and it is the second
period of the calendar.
Sample OCCURS Clauses

These are some example OCCURS clauses and their descriptions:
OCCURS (WORKDAYS AND MONTH.L)
Occurs every workday in the last fiscal month.

OCCURS (WEDNESDAY AND DATE LT 01/31/2012)
Occurs every Wednesday before January 31, 2012.

OCCURS (MONDAY.1 OR MONDAY.3)
Occurs the first and third Monday of each month or period.

OCCURS (EVERY 14 DAYS BEGINNING 02/12/2012)
Occurs every other Tuesday starting on February 12, 2012.

OCCURS (EVERY 5 WDAYS FROM 03/26/2012)
Occurs every Wednesday before and after March 26, 2012.

OCCURS (DAY.L)
Occurs the last day of each month or period.

OCCURS (WDAY NE 07)
Occurs every workday except the seventh workday of each month or period.
OCCURS (SUNDAY AND WEEK.1)
Occurs Sunday in the first week of each month or period.

OCCURS ((FRIDAY.2 OR FRIDAY.4) AND
(MONTH.3 OR MONTH.6 OR MONTH.9 OR MONTH.12))
Occurs the second and fourth Friday of the third month of each quarter.
OCCURS (WEDNESDAY AND NOT DAY.1)
Occurs every Wednesday unless Wednesday is the first day of the month.
115
OCCURS (WORKDAYS AND NOT WEOM-1)
Occurs every workday except the workday before the last day of the month.
OCCURS (EOM + 5 WDAY)
Occurs five workdays after the last day of the month.

OCCURS (WFWEEK.1 AND NOT MONDAY)
Occurs the first full work week of the month except for Monday.
OCCURS (NOT FWEEK.1 AND DAILY)
Occurs every day of the month (including weekends) except the first full week
(Monday through Sunday) of the month.
OCCURS (MONTH.10 AND WORKDAYS AND NOT FRIDAY)
Occurs every workday in October except Friday.

OCCURS ((WORKDAYS AND NOT FRIDAY) OR (FRIDAY AND WEOM))
Occurs every workday of the week, except for Friday, unless Friday is the last
workday of the month.
OCCURS (MONDAY.L AND PERIOD.1)
Occurs the last Monday of the first period.

OCCURS (WDAYW.3)
Occurs the third workday of each week.

OCCURS ((HOLIDAYS - 1 WDAY) OR (HOLIDAYS - 2 WDAY))
Occurs the 2 workdays preceding a holiday.

OCCURS (WORKDAYS AND NOT (HOLIDAYS - 1 WDAY)
AND NOT (HOLIDAYS - 2 WDAY))
Occurs every workday except the 2 workdays preceding a holiday.

OCCURS (((FRIDAY AND EOM) - 7 DAY) OR ((SATURDAY AND EOM) - 8 DAY)
OR ((SUNDAY AND EOM) - 9 DAY) OR (FRIDAY.L AND NOT EOM AND NOT EOM-1
AND NOT EOM-2))
Occurs the last Friday of the month unless the last Friday is also one of the last 3
days of the month; in that case, occurs on the next-to-last Friday of the month.
OCCURS (((FRIDAY AND HOLIDAYS) - 1 DAY) OR
(FRIDAY AND NOT HOLIDAYS))
Occurs every Friday unless it is a holiday; in that case, occurs on the previous
Thursday.
OCCURS (((((FRIDAY AND HOLIDAYS) - 1 DAY) AND HOLIDAYS) - 1 DAY)
OR (((FRIDAY AND HOLIDAYS) - 1 DAY) AND NOT HOLIDAYS) OR (FRIDAY
AND NOT HOLIDAYS))
Occurs every Friday unless it is a holiday; in that case, occurs on the previous
Thursday. If previous Thursday is also a holiday, occurs the previous Wednesday.
116
4 Events
OCCURS (((MONDAY AND HOLIDAYS) + 2 DAY) OR

((MONDAY AND NOT HOLIDAYS) + 1 DAY))
Occurs every Wednesday following a Monday that is a holiday, and every Tuesday
following a Monday that is not a holiday.
OCCURS (WORKDAYS AND NOT WDAYW.1 AND (NOT HOLIDAYS + 1 DAY))
Occurs every workday unless it is the first workday of the week or the day after a
holiday.
OCCURS (((WDAYW.1 - 2 DAY) AND NOT HOLIDAYS) OR
((MONDAY AND HOLIDAYS) - 1 DAY))
Occurs the second nonholiday day before the first workday of every week, unless
the first workday of the week is a holiday; in that case, occurs the day before the
first workday of the week.
OCCURS ((WORKDAYS AND NOT FRIDAY.2) OR (FRIDAY.2 + 2 DAY))
Occurs every workday of the month except the second Friday; also occurs 2 days
after the second Friday of the month.
OCCURS (WORKDAYS AND NOT (HOLIDAYS AND MONDAY) + 1 DAY)
Occurs every workday except the day following a Monday holiday.

OCCURS (SEPTEMBER AND DAY EQ 28 OR (OCTOBER AND DAY EQ 26 OR (NOVEMBER
AND DAY EQ 23 ON HOLIDAYS OR (DECEMBER AND DAY EQ 28))))
Occurs September 28, October 26, November 23 (even if it is a holiday), and

December 28.
OCCURS ((DECEMBER AND DAY GE 6 AND DAY LE 27) AND WORKDAYS AND NOT
FRIDAY)
Occurs all workdays, except Fridays, from December 6 through December 27

(inclusive).
OCCURS (SATURDAY ON WEEKENDS OR (WORKDAYS AND NOT MONDAY))
Occurs every Saturday and every workday except Monday.

OCCURS (MONDAY ON HOLIDAYS OR (TUESDAY ON HOLIDAYS OR (WEDNESDAY
ON HOLIDAYS OR (THURSDAY ON HOLIDAYS OR (FRIDAY ON HOLIDAYS)))))
Occurs every Monday, Tuesday, Wednesday, Thursday, and Fridayeven if it is a

holiday. OCCURS (NOT SATURDAY ON HOLIDAYS AND NOT SUNDAY ON HOLIDAYS)
would produce the same results.
OCCURS (FRIDAY.1 AND PERIOD.4)
Occurs the first Friday in the fourth period of the calendar.

OCCURS (CALENDAR TEST2 AND WSATURDAY)
Occurs every working Saturday marked in calendar TEST2.
117
OCCURS ((WDAYW.3 AND WDAYW.L) - 1 DAY)
Occurs on the second workday of the week if the third workday is the last workday
in the week (for example, occurs on Tuesday if Thursday and Friday are holidays,
or on Thursday if Monday and Tuesday are holidays).
OCCURS (DAY EQ 15 BEFORE HOL/WEEK)
Occurs the fifteenth day of each month or period unless it is a holiday or weekend;
in this case, occurs on the prior workday.
OCCURS ((DAY.L BEFORE HOLIDAYS ON WEEKENDS OR
((DAY.1 AND HOLIDAYS) + 1 DAY)) OR (DAY.1 AND NOT HOLIDAYS))
Occurs the last day of each month or period (even if it is a weekend) unless it is a
holiday; in this case, occurs on the prior workday. Also occurs the first day of each
month or period unless it is a holiday; in this case, occurs the second day of the
month or period.
OCCURS (JDAY LE 31)
Occurs the first 31 days of the year.

OCCURS (JDAY LE 31 ON HOLIDAYS)
Occurs the first 31 days of the year. Holidays are scheduled for the actual day.
OCCURS (JDAY.60)
Occurs the 60th day of the year, either March 1 of nonleap year, or February 29 in a
leap year.
OCCURS (JDAY.L)
Occurs the last day of the year.

OCCURS (JDAY.L - 1 DAY)
Occurs the penultimate day of the year.

OCCURS (JDAY.L + 1 DAY)
Occurs the first day of the next year. This is valid syntactically, but the event will
never be scheduled. The Julian day is a day within the current year, so it is never
next year. As a result the event cannot be scheduled.
Scheduling Events on Holidays and Weekends

These OCCURS clause keywords are affected by holidays and weekends:
DATE xx mm/dd/yyyy
DAY.
EOM
HOLIDAYS
MONDAY-SUNDAY
DAY EQ xx
EVERY xx DAYS
EOM-xx
118
4 Events
HOL/WEEK
WEEKENDS
An event that you define to occur on a particular day of the week, could hit on a
nonworking day. For example:
OCCURS (EVERY xx DAYS)
However, an event that you define to occur according to any of these conditions is not
affected by holidays or weekends because a workday, by definition, cannot be a holiday
or weekend:
OCCURS (WORKDAYS)
OCCURS (WDAY EQ xx)
OCCURS (WDAY.L-xx OR WEOM-xx)
By default, when an event is defined to occur on a nonworking day, Zeke schedules the
event for the next working day. (You can change this behavior for an event using the
Nwday field in the EMR, or globally using the NonWkday generation option.)
For example, lets 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 Mondays date), and places it in
Tuesdays schedule. Zeke dates the event with Mondays date because there could
already be another scheduled event for Tuesday (e.g., if the event is defined to occur
Monday and Tuesday).
ON, BEFORE, and AFTER Keywords

You can use the these keyword phrases to schedule an event before a holiday or weekend:
BEFORE HOLIDAYS
BEFORE WEEKENDS
BEFORE HOL/WEEK
You can use these same phrases with the keyword ON (instead of BEFORE) to schedule
the event on the hit date (even if it could be a holiday or weekend). For example:
To schedule the event the prior working day, Friday, use this OCCURS clause:
OCCURS (MONDAY BEFORE HOLIDAYS)
To schedule the event Mondays (even if Monday is a holiday), use this OCCURS clause:
OCCURS (MONDAY ON HOLIDAYS)
119
To schedule an event for every Saturday (when Saturday is defined as a weekend), use
this OCCURS clause:
OCCURS (SATURDAY ON WEEKENDS)
You can use the keywords ON, BEFORE, and AFTER outside of parentheses to apply to
all of the keywords that are within parentheses. (This does not apply if there is an
individual holiday or weekend specified.)
For example:
This clause schedules every Monday and Tuesday; however, if Monday is a holiday, it
schedules on the previous workday. If Tuesday is a holiday, it schedules on the next
workday.
OCCURS ((MONDAY BEFORE HOLIDAYS) OR TUESDAY)
This clause schedules Monday or Tuesday. If either is a holiday, it schedules on the

previous workday:
OCCURS ((MONDAY OR TUESDAY) BEFORE HOL)
This clause schedules every Sunday in August, even if Sunday is defined as a weekend
day:
OCCURS ((SUNDAY AND AUGUST) ON WEEKENDS)
Nwday Field/Nonwkday Option

The Nwday field in the events EMR specifies whether to schedule after, before, or on a
holiday (or not at all). When you specify a holiday or weekend in the OCCURS clause, it
overrides the Nwday field in the EMR.
For global OCCURS clause specifications, you can set the NonWkday generation option
(see Scheduling Options on page 320), which specifies the default Nwday value when
you add an EMR.
DAILY Keyword
The DAILY keyword schedules an event on any day that the SCHEDULE function runs,
regardless of whether that day is a workday, weekend, or holiday. The keywords ON,
BEFORE, and AFTER have no effect on the OCCURS clause keyword DAILY.
120
4 Events
Defining an OCCURS Clause

This procedure explains how to define an OCCURs clause for an event in the EMR and
then test the clause to ensure that it schedules the event as expected.
To define and test an OCCURS clause

1
Access the Event Master Definition screen for the desired event, as instructed in
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 6
Desc: TEST JOB
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 3
Control: Y Tapes: 0
Job: TSKKGUT1
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Pri: 0
CMS:
Ftype:
Enter OCCURS on the Command line, and press Enter. The Event Record Occurs
Clause screen is displayed:
ASG-Zeke
Command ===>
Primary Commands :
Event Record Occurs Clause
EDIT
BROWSE EDIT ACCTG OCCHIT
Evt: 000006 Type: JOB

Job: TSKKGUT1 Evt Name: ZEKE60TST6
Calid: A
Ver: 00000
Platform: MVS
Occurs: (TUESDAY OR WEDNESDAY OR DAY.11)
121
In the Occurs field, specify a valid OCCURS clause. You must enclose the OCCURS
clause in parentheses. These are the most common OCCURS keywords:
Keyword
Description
REQUEST
Default. Zeke does not schedule the event automatically. You must add
the event the schedule through Schedule View or using the ZADD
operator command through the ZCOM option.
See Using Schedule View on page 191 or Using the ZADD Operator
Command on page 247.
DAILY
Zeke schedules the event every day, regardless of whether it is a

workday, weekend, or holiday.
WORKDAYS
Zeke schedules the event on workdays (as defined on the calendar

specified for the event).
EOM
(End of month) Zeke schedules the event on last day of each month.
See OCCURS Clauses on page 107 for a full discussion of OCCURS clauses. See
OCCURS Keywords on page 109 for a complete list of valid keywords.
4
Press Enter to save the event with the new OCCURS clause.
Enter OCCHIT on the Command line, and press Enter. The OCCURS Hit
Resolution screen is displays the days of the current month:
ASG-Zeke
Command ===>
Occurs Hit Resolution
EDIT
Primary Commands: BROWSE EDIT NMONTH PMONTH NYEAR PYEAR

Month: 03 Year: 2012
Event: 000006
Ename: ZEKE60TST6
M O N
T U E
W E D
T H U
F R I
3
10
17
24
31
4
11
18
25
5
12
19
26
6
13
20
27
7
14
21
28
*
*
*
*
*
*
*
*
S A
1
8
15
22
29
Calid: A
T
W
W
W
W
W
S U
2
9
16
23
30
N
W
W
W
W
W
Ver: 00000
Occurs: (TUESDAY OR WEDNESDAY OR DAY.11)
W = Weekend
H = Holiday
S = Slack day
*X = Event scheduled x times on this date
* = Event scheduled on this date
An asterisk (*) marks the days the event is scheduled to occur.
122
4 Events
Zeke uses these codes to indicate the status of each day in the current month:
Code
Meaning
Weekend day
Holiday
Slack day (i.e., day in the period between accounting calendars)
Review the results of the OCCURS clause for at least the next 12 months to verify
that the event is hitting the schedule as expected.
Desired Result
Action
View the schedule for

the next month
Enter NMONTH on the Command line, and press Enter.

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

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

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

a specific month
Specify the number of the month (e.g., 01 for January, 12 for

December) in the Month field, and press Enter.

a specific year
Specify the year in the Year field, and press Enter.
123
WHEN Conditions
You use WHEN conditions to specify the conditions that must occur before Zeke
dispatches a scheduled event. Zeke does not dispatch an event until its WHEN conditions
are satisfied. A WHEN condition, also known as a dependency, can be any of these
actions or conditions:
Execution of a specific program, system job, or another Zeke event
Relating a Zeke variable to a certain value
Any combination of multiple WHEN conditions
z/OS dataset creation
If an event does not have a defined dependency, then Zeke dispatches the event according
to the specified schedule time in the EMR.
Work centers do not have WHEN conditions (see Work Centers on page 149).
Job and Program WHEN Conditions

Job and program WHEN conditions become satisfied when the system initiates or
completes the action named in the dependency (e.g., starting or ending a specific job) for
an event. As each dependency is satisfied, Zeke examines the events 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).
The keywords XEOJ (extended end-of-job) and XEOE (extended end-of-event) provide
the ability to trigger job events across multiple schedules. Extended WHEN conditions
can be satisfied by events that have run in the past, but no longer are in the schedule. If a
124
4 Events
job is dependent on another event that might have run as part of an earlier schedule, Zeke
uses the XEOJ keyword to locate the triggering event in the Zeke database, and determine
whether it has run since the last time the dependent job ran.
See WHEN Condition Keywords on page 133 for details on including the XEOJ and
XEOE keywords in a WHEN condition.
If a job has multiple extended WHEN conditions, all conditions must be satisfied at the
same time for the extended triggering to occur.
At schedule load, Zeke searches the EMRs (using the index, if present) and examines the
first matching jobname. If the last run of the event completed successfully since the last
time the job with the extended dependency ran, the dependency is satisfied and marked
by an asterisk (*) (just like an EOJ or EOE). Otherwise, Zeke considers the dependency
as if it were a regular EOJ or EOE, and waits for the triggering job to complete
successfully before satisfying the dependency. Zeke examines extended dependencies
each time an event becomes TIMEOK (i.e., time-satisfied) and WHENOK (i.e.,
dependencies are satisfied).
In extended dependency triggering, Zeke retains the start date and time, the end date and
time, and the event status in the EMR for the last execution of each event (see Event
Activity Accounting on page 172 for details). If the SQR has been requeued, or if Zeke
is not tracking the execution, Zeke retains the information in the SQR for the last
execution instead. If multiple SQRs for an event are executing at the same time,
triggering occurs based on the execution with the latest end date and time.
Note:
Zeke processes extended WHEN conditions in the same manner as if the generation
option TrigJob is set to C, and TrigDt is set to A. This indicates that Zeke (or another
Zeke that shares the database) must have dispatched the triggering event, but the start
date does not have to be the same as the schedule date of the job being triggered.
If the last execution of an event did not complete successfully, the event cannot trigger an
extended dependency. For example, a JCL error is an unsuccessful completion; an EOJ
FORCED status indicates a successful completion. If the execution is unsuccessful, Zeke
still retains the information for that execution in the EMR, but no triggering takes place.
Extended WHEN conditions also can be manually satisfied using the ZALTER
WHENOK operator command.
XEOE Example
Event 2 has an extended dependency (XEOE) on Event 1. When it loads Event 2 into the
schedule, Zeke checks to see whether Event 1 ran since the last time Event 2 ran. If Event
1 last ran successfully a week ago, and Event 2 last ran successfully two weeks ago, then
the XEOE dependency is satisfied, and Zeke dispatches Event 2 (assuming that any
125
additional dependencies also are satisfied). However, if Event 1 ran two weeks ago, and
Event 2 ran only two days ago, the XEOE is not satisfied, and Zeke treats the dependency
as an EOE instead.
XEOJ Example
The job event named Job B has an extended dependency (XEOJ) on Job A. When Zeke
loads Job B into the schedule, Zeke checks to see whether Job A ran since the last time
Job B ran. If Job A just ended today at 10:30:25 A.M., and Job B is ready to run at
10:30:40 A.M. today (during the same minute), then the XEOJ dependency is satisfied,
and Zeke dispatches Job B (assuming that any additional dependencies also are satisfied).
However, if Job A did not end until 10:30:56 A.M. (also during the same minute), then
the XEOJ is not satisfied, and Zeke treats the dependency as an EOJ instead.
WEAK Conditions
You can use WEAK conditions in a dependency to create WHEN conditions that refer to
other events that might not be in the schedule. WEAK conditions enable you to specify
that Zeke must respect the condition if the event is in the schedule; otherwise, Zeke
ignores the condition.
For example, lets suppose that this is a dependency for event 100:
WHEN (WEOJ JOBABC)
If the job event JOBABC is in the schedule, Zeke does not dispatch event 100 until
JOBABC reaches a successful end-of-job (EOJ) status. Zeke continuously checks the
status of the job event JOBABC until it is dispatched.
Zeke verifies whether a dependency has been met because a weak condition was satisfied
(i.e., the event is not in the schedule), or because the dependency has been satisfied (i.e.,
the job ran).
If the job event JOBABC is not in the schedule, Zeke processes the event according to the
Zeke generation option RemovDq:
126
If the Zeke generation option RemovDq is set to Y, Zeke moves event 100 to the
dispatch queue. While event 100 is in the dispatch queue, Zeke still continues to
check the schedule for JOBABC. If JOBABC is added to the schedule (e.g., using
the ZADD operator command), Zeke removes event 100 from the dispatch queue,
and does not queued the event again until JOBABC reaches a successful EOJ. If
JOBABC never is added to the schedule, Zeke dispatches event 100 (which
executes when its resources are available).
If the RemovDq option is set to N, Zeke does not remove the dependent event from
the dispatch queue (once it has been added).
4 Events
NOTDURING Conditions
A NOTDURING condition specifies that Zeke cannot dispatch an event while the
specified programs or jobs are running. The event remains eligible for dispatch until the
NOTDURING conditions are satisfied; then, Zeke immediately dispatches the event.
Zeke ensures that events with conflicting NOTDURING clauses are not dispatched at the
same time. For example, if JOB1 has the status Pending, and JOB2 has a NOTDURING
condition for JOB1, Zeke does not dispatch JOB2 (even though JOB1 is not actually
running). You can disable JOB1 to enable Zeke to dispatch JOB2.
Caution! Zeke does not support NOTDURING conditions while in SMF recording mode
(as initiated by the ZKILL TRACK command).
Note:
Resource control is a another effective way that you can ensure that conflicting events do
not run at the same time. See Defining a Logical Resource on page 272 for more
information.
Enabling NOTDURING Processing

To enable Zeke to process NOTDURING conditions on a single Zeke system, you must
set the Zeke generation option DispSel to Y (see Setting Dispatching Options on
page 262). Additionally, the EojWake generation option determines whether events that
are held due to a NOTDURING condition are reevaluated at each end-of-job (EOJ), or
only at each one-minute, dispatching interval (see Dispatching Events and Messages on
page 300).
To use XCF to process NOTDURING conditions across a Zekeplex, Zeke does not
consider the DispSel option value. Instead, you must specify the start-up option
PLEXNOTD=YES in your ZEKExx options member (see the ASG-Zeke Scheduling for
z/OS Installation Guide for details). This start-up option enables NOTDURING JOB
processing for both JES2 and JES3 (otherwise, only JES2 supports NOTDURING
dependencies). In addition, you also must specify the start-up option PLEXID=value
in your OASISxx options member for the OASIS subsystem for this Zeke system (see
the ASG-OASIS for z/OS Reference Guide for details).
Specifying NOTDURING WHEN Conditions

Its NOTDURING conditions must be satisfied before an event can be dispatched.
Zeke does not use NOTDURING conditions to determine whether an event is
WHENOK. An event could be WHENOK even though a program or job named in an
NOTDURING clause is executing; however, Zeke does not dispatch the event until the
NOTDURING program or job is completed.
127
In a WHEN condition, you must list NOTDURING conditions last (after all other WHEN
conditions). You relate multiple NOTDURING conditions using the AND keyword.
Specifying Generic Names and Wildcards

To specify generic NOTDURING program and jobnames, you can precede the job or
program name with an asterisk (*) followed by up to seven characters. For example,
*ABC would match names beginning with ABC.
To use * as a wildcard character, you can replace any character with *. For example,
PAY**UPD would select all jobs with PAY in the first three positions, any characters in
the fourth and fifth positions, and UPD in the sixth through eighth positions.
Because * could indicate a generic name or a wildcard character, Zeke assumes that an
asterisk in the first position indicates a generic name when fewer than eight characters are
entered. For example, to select all jobs with C in the seventh position, you would enter
******C*, instead of ******C. Because all eight characters are specified, Zeke
assumes the first * is a wildcard character.
Note:
An event cannot have a generic NOTDURING with a pattern that matches the jobname
(e.g., a jobname JOBBC3PX and WHEN (NOTDURING JOB *BC3P).
Examples
These are examples of NOTDURING WHEN conditions:
WHEN (EOJ JOB1 NOTDURING JOB PRODCICS)
The event requires an EOJ on JOB1, but cannot run while job PRODCICS is
running.
WHEN (NOTDURING PGM DFHSIP)
The event cannot run while program DFHSIP is executing.

Note:
Zeke honors the NOTDURING PGM condition regardless of the initiator where the
job is running.
WHEN (NOTDURING JOB *PAY NOTDURING PGM PAY**01A)
The event cannot run with any job that has a jobname beginning with PAY, or
during any program with a name that has PAY in positions 1 through 3, and 01A in
positions 6 through 8.
128
4 Events
Cross-platform Dependencies
Cross-platform scheduling dependencies are prerequisites that are satisfied by a remote
schedulereither a remote Zeke system or another remote scheduling system (e.g.,
ASG-Zena). Only the WHEN conditions EOJ, AEOJ, and BOJ can be shared with remote
systems.
To indicate a cross-schedule dependency, you use the AT keyword followed by the
eight-character Netregid of the remote system. For example:
WHEN(EOJ JOBA AND EOJ JOBB AT SYSB)
In this example, Zeke waits on EOJ from JOBB on system SYSB before dispatching the
event. When JOBB is completed (EOJ), SYSB notifies the originating Zeke system that
the dependency is satisfied. Zeke then satisfies the dependency for all events waiting for
EOJ JOBB from SYSB.
With the AT keyword, a jobname can be up to 30 characters long. The AT keyword does
not support the use of the VER keyword. If you specify a version number, Zeke ignores
it.
Zeke-to-Zeke Cross-schedule Dependencies

When a Zeke system satisfies a cross-platform scheduling trigger for a remote system
(i.e., a Zeke system is the object of the AT netregid of another schedulers 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 SQRs 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 jobs schedule and run dates in the satisfy notification.
When the local Zeke system processes the satisfy notification, the local Zeke applies the
value of TrigDt generation option to the schedule and run dates from the remote system to
decide whether the remote job will satisfy the trigger. If the remote scheduler does not
send the dates in the satisfy notification, the local Zeke system bypasses the TrigDt value
and simply looks for a match on the jobname.
You also can use AT to specify a dependency using the ZALTER operator command. For
example:
To add a remote dependency with an AND relationship:

ZALTER JOB 1 WHENAND (EOJ JOBC AT SYSB)
129
To add a remote dependency with an OR relationship:

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

ZALTER JOB 1 WHENOK (EOJ JOBB AT SYSB)
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on the
ZALTER operator command.
Specifying Generic Names

To specify generic event names for the EOE, AEOE, XEOE, or EOG conditions, you
precede the event name with an asterisk (*), and the characters that you want to match.
Generic names are only valid for event names; you cannot use them for jobnames. For
example, *ABC matches all jobs with event names that begin with ABC.
To use an asterisk as a wildcard character, you replace any character with an asterisk (*).
For example, PAY***UPD selects all events with PAY in the first three positions, any
characters in the fourth through sixth positions, and UPD in the seventh through ninth
positions. If the event name contains spaces, you must specify the name in single quotes.
For example, (EOE '**********').
You can use an asterisk (*) to indicate both a generic name and a wildcard character, so it
is important to understand how Zeke interprets an asterisk. The maximum number of
characters that you can specify in a generic name is 12. If you specify all 12 characters
(with an asterisk in the first position), Zeke assumes the first asterisk is a wildcard. For
example, *KKKKKKKKKKK selects all events with any character in the first position, and
K in the second through twelfth positions. If you specify fewer than 12 characters, Zeke
assumes that an asterisk in the first position indicates a generic name. For example,
*KKKKKKKKKK (one less K than the previous example) selects all events that begin with
ten Ks.
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 Ks.
Specifying Multiple WHEN Conditions

You can define an event to have more than one dependency.
This example shows two WHEN conditions joined with the keyword OR (which
indicates that the event is satisfied when either clause is satisfied):
WHEN (EOJ ABC OR EOJ XYZ)
130
4 Events
The keyword AND indicates that the event is satisfied only when both of the WHEN
conditions are satisfied:
WHEN (EOJ XYZ AND EOJ ABC)
Grouping Multiple WHEN Conditions

In addition to AND/OR relationships between multiple WHEN conditions, you can
enclose multiple WHEN conditions in parentheses. This separates the clauses into
groups, and indicates to resolve one group before resolving the next, higher group.
For example, an event is satisfied when Job A is completed, and either Program A or
Program B is completed:
WHEN (EOJ JOBA AND (EOP PGMA OR EOP PGMB))
The inner group is resolved first. The inner group is satisfied if Program A or Program B
have completed. Because the keyword AND joins the two clauses, the event is only
satisfied if Job A has also completed.
Specifying Started Tasks

These WHEN conditions also can refer to started tasks and programs within started tasks
(if the you make the appropriate specifications in the SMFPRMxx member of
SYS1.PARMLIB):
BOJ
EOJ
BOP
EOP
AEOJ
EOS
AEOP WHEN
See the ASG-Zeke Scheduling for z/OS Installation Guide for more information on SMF
requirements, or ask your system programmer whether your installation supports WHEN
conditions that reference started tasks.
Using Zeke Variables as WHEN Conditions

To use a Zeke variable as a dependency, you specify a variable and the relational operator
to compare to a specified value. Zeke performs variable substitution in WHEN conditions
when the SQR is created (using the SCHEDULE function or the ZADD operator
command).
131
For example, Zeke does not dispatch this event until the value of the variable named
$VARNAM1 is YES:
WHEN (VAR $VARNAM1 EQ YES)
When the variable is set to YES, the dependency is satisfied. The dependency also is
satisfied if the variable is already set to YES when Zeke loads the schedule.
In WHEN conditions, you can use OASIS variables only for substitution in an operand
(e.g., the jobname in a BOJ or EOJ condition, or the expression following EQ in a VAR
condition). OASIS variable substitution is performed using qualifiers from the created
SQR. For example:
WHEN EOJ PRDAA$(CYCLE)
Lets suppose that the value of the OASIS variable CYCLE is 09. When this value is
substituted into the dependency, the jobname becomes PRDAA09.
Zeke does not check WHEN conditions that contain variables for syntax when they are
defined. Syntax checking occurs only after the variable substitution is performed. This is
important in certain situations. For example, if the operand of an EOJ dependency that
contains a variable is longer than eight characters before substitution occurs, this
normally would be invalid because of length limitations. Because Zeke does not perform
syntax checking until after the substitution, the length is valid as long as the value is no
longer than eight characters after substitution occurs.
These are the valid relational operators that you can use in a Zeke variable:
Relational Operator
Description
EQ
EQual to
GE
Greater than or Equal to
GT
Greater Than
LE
Less than or Equal to
LT
Less Than
NE
Not Equal to
You can use either numeric or character literals; however, numeric values are compared
only to numeric variables, and character values are compared only to character variables.
You must express numeric literals explicitly (no delimiters), and enclose character literals
in special character delimiters (if the character string contains other than alpha/numeric
characters).
132
4 Events
For example:
WHEN (VAR $TEST1 EQ PROCEED)
WHEN (VAR $CTR4 EQ 411 AND VAR $CTR3 EQ 77)
WHEN (VAR $SHOWLIT EQ 'IT IS OK TO CONTINUE NOW')
Caution! You cannot use these characters as delimiters:
dollar sign ($)
question mark (?)
number/pound sign (#)
at sign (@)
asterisk (*)
Combining Event Actions and Zeke Variables

You can specify combinations of job, program, and event actions, and Zeke variables as
WHEN conditions for any type of event. For example:
WHEN (EOJ JOBNAME1 AND VAR $VARNAME EQ YES)
WHEN Condition Keywords

These are the available keywords that you can use with the WHEN parameter to define
WHEN conditions:
Keyword
Description
AT
netregid
(Target) Specify the Netregid (up to eight characters long) for the remote system
where the cross-platform prerequisite must occur. For example:
WHEN (EOJ JOBA AND EOJ JOBB AT SYSB)
Note:
When you use the AT keyword, you can specify a dependency on a job with a
jobname up to 30 characters long.
Using the AT keyword does not support use of the VER keyword. If a version
number is specified, Zeke ignores it.
See Cross-platform Dependencies on page 129 for more information.
133
Keyword
Description
DSN
(Dataset name) Dataset triggering is based on the close of a z/OS output dataset.
Zeke dispatches the event when a sequential, nonVSAM dataset that matches the
DSN dependency is closed. For example:
WHEN (DSN DATASET.NAME)
WHEN (DSN DATASET.NAME AND EOJ PAYROLL)
Before using DSN for nonVSAM datasets, ensure that the Zeke generation option
IEFU83 is set to Y, and that your system is creating Type 15 SMF records, or that
Connect:Direct (formerly Network Data Mover, or NDM) is installed and active
with the appropriate RUN TASK statement. See the ASG-Zeke Scheduling for
z/OS Installation Guide for more information on using on using Connect:Direct
with Zeke.
A generation data group (GDG) dataset name with the generation number
'G0000V00' is satisfied when any dataset in its GDG index is created and
closed. For example, this condition is satisfied when any generation in the GDG
'A.B' is created and closed:
WHEN (DSN A.B.G0000V00)
Because the IEFBR14 program does not close a dataset, it cannot trigger a DSN
dependency.
Note:
The DsclTrig generation option (see Dispatching Options on page 297)
controls the dataset dispositions that qualify as triggers for DSN WHEN
conditions.
AEOJ
(Abnormal end of job) Specify the jobname. For example:

WHEN (AEOJ JOB1)
AEOE
(Abnormal end of event) Specify an event of any type (including work centers).
For example:
WHEN (AEOE JOB1)
AEOP
(Abnormal end of program) Specify the program name. For example:

WHEN (AEOP PAYROLL)
AEOS
(Abnormal end of step) Specify the stepname. For example, if the step that failed
does not execute a procedure:
WHEN (AEOS STEP4..JOBX)
If the step that failed executes a procedure, the procname must be included:
WHEN (AE0S STEP2.PROC3.JOBX)
134
4 Events
Keyword
Description
NOTDURIN
G
(Not during) Specify the program name or jobname. This prevents jobs/programs
from running at the same time. If you use this keyword, you must specify it as the
last condition in the WHEN condition statement. For example:
WHEN (NOTDURING JOB JOBNAME)
WHEN (EOJ JOB1 NOTDURING JOB PRODCICS)
WHEN (NOTDURING JOB *PAY NOTAF PGM PAY**01A)
See NOTDURING Conditions on page 127 for a detailed discussion of

NOTDURING WHEN conditions.
BOJ
(Beginning of job) Specify the jobname. For example:

WHEN (BOJ JOB3)
BOP
(Beginning of program) Specify the program name. For example:

WHEN (BOP PGMNME)
EOG
(Successful end of group) Specify the name of the group of events. For example:
WHEN (EOG GRPPAY)
You can use EOG to trigger an event by the completion of multiple events
(including work centers). This dependency is satisfied when all events in the
schedule that match the specified event name are in Done or Disabled status, and
at least one of the matching events is in Done status.
For example, lets 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, lets suppose that an event with an EOG dependency is scheduled at
18:00. At 10:00, two events that match the EOG are in the schedule; and at 12:00,
these events are completed. This satisfies the EOG, but the dependent event is not
scheduled to run until 18:00. At 14:00, an event that matches the EOG dependency
is added to the schedule. The EOG is no longer satisfied and the newly added event
must be completed or disabled before the event with the EOG dependency can be
dispatched.
135
Keyword
Description
Note:
If you specify an EOG dependency in which the dependent event matches the
generic event name specified in the EOG, the dependent event will never be
triggered (because it is dependent on itself as well as other events). For example,
if the WHEN condition specifies EOG *ASG123 and the event name for the
dependent event is ASG12345, all other predecessor events might be completed,
but the successor will never be triggered.
EOE
(Successful end of event) Specify the name of an event of any type. Do not specify
the event number.
This dependency is satisfied when an event in the schedule that matches the
specified event name has reached a EOE or Disabled status.
For example:
WHEN (EOE JOB1)
WHEN (EOE 'JOB TWO')
WHEN (EOE PAYROLL)
WHEN (EOE 'JOB PAYROLL')
EOP
(Successful end of program) Specify the program name. For example:

WHEN (EOP PROGRAM.JOB)
WHEN (EOP PGMNAME1 OR EOP PGMNAME2)
EOS
(Successful end of step) Specify the stepname (i.e., the job step that calls the
cataloged procedure) or the procstep name.
For example, when executing a procedure:
WHEN (EOS STEPNAME.PROCSTEP.JOBNAME)
For example, when not executing a procedure:

WHEN (EOS STEPNAME..JOBNAME)
EOJ
(Successful end of job) Specify the jobname. For example:

WHEN (EOJ JOBNAME1)
WHEN (EOJ JOBNAME1 AND EOJ JOBNAME2 AND BOJ JOBNAME3)
WHEN (EOJ JOB$(CYCLE))
VAR
(Variable) Specify a variable value. Zeke dispatches the event only when the
variable is equal to the specified value. For example:
WHEN (VAR $ABC EQ YES)
See Using Zeke Variables as WHEN Conditions on page 131 for a detailed
explanation on using variables in WHEN conditions.
136
4 Events
Keyword
Description
VER
(Version) Specify the event version. Zeke dispatches the event only at the end of
the specified event version. If you omit this keyword, the default is the same SQR
version. For example, if JOBB version 3 is waiting on EOJ for JOBA, but no
version is specified, JOBB waits on EOJ for JOBA as a version 3 SQR. For
example:
WHEN (EOE JOB4 VER 88)
WHEN (EOJ JOBC AND EOJ JOBC VER 2)
You can use the VER condition for any EOE, EOJ, EOP, EOS, or EOG condition
(including their WEAK counterparts); however, it affects only the SQR that
generates the trigger (i.e., not the job, program, or step).
You can specify an asterisk (*) in the VER condition to trigger from any SQR
version. For example, this event is triggered from the next EOE for EVTB:
WHEN (EOE EVTB VER *)
Note:
Zeke does not support use of the VER keyword for these WHEN conditions
DSN, VAR, ?VAR, XEOJ, and XEOE.
WEOG
(Weak end of group) Specify the group name. For example:

WHEN (WEOG GRPA)
You can use WEOG to trigger an event by the completion of an event group
(which could include work centers). This dependency is satisfied when all events
in the schedule that match the specified group name are in EOE or Disabled status,
and at least of the matching events must be in EOE status.
A WEOG condition can be satisfied even if there are no matching events in the
schedule.
See WEAK Conditions on page 126 for more information.
WEOE
(Weak end of event) Specify the event name; do not specify the event number. For
example:
WHEN (WEOE WC_ABC)
You can use WEOE to trigger an event by the completion of another event
(including work centers).
A WEOE condition can be satisfied even if there are no matching events in the
schedule.
137
Keyword
Description
WEOJ
(Weak end of job) Specify the jobname. For example:

WHEN (WEOJ JOBNAME)
A WEOJ condition can be satisfied even if there are no matching jobs in the
schedule.
XEOE
(Extended end of event) Specify the event name; do not specify the event number.
An XEOE is satisfied when an event (including work centers) in the schedule that
matches the specified event name has reached an EOE or Disabled status since the
last time this event ran. For example, if this dependency is defined for JOBC, then
XEOE is satisfied if job ABC has run to EOE or Disabled status since the last time
JOBC ran:
WHEN (XEOE ABC)
Note:
Zeke does not support the use of the VER keyword with the XEOE keyword.
XEOJ
(Extended end of event) Specify the jobname.

An XEOJ is satisfied when a job event in the schedule that matches the specified
jobname has reached an EOJ or Disabled status since the last time this job event
ran. For example, if this dependency is defined for JOBC, XEOJ is satisfied if
JOBA has run since the last time JOBC ran:
WHEN (XEOJ JOBA)
Note:
Zeke does not support use of the VER keyword with XEOJ. If you specify a
version number, Zeke ignores it and the job is triggered by any version of the
specified job.
138
4 Events
Defining a WHEN Condition

This procedure explains how to define a WHEN condition for an event in the EMR.
To define and maintain a WHEN condition

1
Access the Event Master Definition screen as instructed in the procedure,

ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 6
Desc: TEST JOB
Type: JOB Desc2:
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: TSKKGUT1
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
Pri: 0
CMS:
Ftype:
Enter WHEN # (where # is the version) on the Command line, and press Enter. If
you do not enter a version number, it defaults to the first version.
ASG-Zeke
Command ===>
Event Master Record Function
EDIT
Scroll ===> PAGE
Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN

Evt: 000006 Type: JOB Job: TSKKGUT1 Evt Name: ZEKE60TST6
Calid: A
Ver: 00000
Info:
Platform: MVS
****** ***************************** Top of Data ***************************
==MSG>
000001 (EOE ZEKE60TST5 AND EOE ZEKE60TST4 AND EOE ZEKE60TST1 AND EOE ZEKE60TST2
000002 AND EOE ZEKE60TST3)
****** **************************** Bottom of Data *************************
Use the standard ISPF commands to edit the bottom part of the Event Master Record
Function screen. Enter a valid dependency for this version of the event.
139
The most common WHEN keyword is EOJ jobname which dispatches the
event at the successful end of the specified job. You can combine several WHEN
conditions with the use of the keywords AND and OR. For example:
WHEN (DSN DATASET.NAME AND EOJ PAYROLL)
See WHEN Condition Keywords on page 133 for a complete list of valid
keywords.
4
Press Enter. The event version is updated with the WHEN condition.
To define a dependency for another version of the event, enter ADD # (where # is
the version number) on the Command line. Repeat steps 3 and 4.
You can issue to COPY command to use the same dependency for multiple versions
of an event. For example, to copy the dependency from version 7 to version 8,
display the Event Master Record Function screen for version 7. Enter COPY 8 on
the Command line. The dependency is copied to version 8, and the screen is
displayed in Edit mode for version 8. If you do not specify a version number to
copy to, Zeke selects one for you.
Viewing WHEN Conditions for All Event Versions

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

1
Access the Event Master Definition screen for the event, as instructed in Accessing
the Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
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
Target: *LOCAL
Verload: 4
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: NOMTEST
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
140
Class:
Pri: 0
CMS:
Ftype:
4 Events
Enter WHEN * on the Command line, and press Enter.

If there are WHEN conditions defined for the event, the WHEN/SET Clause
Directory screen is displayed:
ASG-Zeke
Command ===>
WHEN/SET Clause Directory

Scroll ===> PAGE

Line Commands: E - Edit
Evt: 000032
B - Browse
D - Delete
Type: JOB
Job: NOMTEST
Evt Name: TESTADDNM
Calid: A
Info:
Platform: MVS
Version Clause (partial)
More
==========================================================================
00000 (EOJ TESTJOB0)
00002 (EOJ TESTJOB0 OR VAR $TESTVAR EQ YES)
00003 (EOJ TESTJOB2)
00004 (EOJ TESTJOB0 AND EOJ TESTJOB2 VER 2)
******************************Bottom of data******************************
All the WHEN conditions that have been defined for the event are listed, with their
corresponding version numbers.
If a dependency is longer than the width of the screen (indicated by a '>' symbol in
the More column), you must access the Event Master Record Function screen to
view the remainder of the statement. To do so, use the Browse line command as
described in the next step.
3
Desired Result
Action
Add a dependency for a

new version number
Enter ADD ver# on the Command line (where ver# is the

number of the version you are adding). For example, ADD 5.
Press Enter.
The Event Master Record Function screen is displayed in Add
mode. See Defining a WHEN Condition on page 139 for
further instructions.
Browse the WHEN

conditions for a particular
version of the event
Enter B to the left of the dependency that you want to

browse. Press Enter.
The Event Master Record Function screen is displayed in
Browse mode.
141
Desired Result
Action
Delete the WHEN

conditions for a particular
version of the event
Enter D to the left of the dependency that you want to delete.

The Event Master Record Function screen is displayed and
you are asked to confirm the deletion. Enter DELETE on the
Command line, and press Enter to confirm, or press F3 to
cancel.
Or
1 Enter E to the left of the dependency that you want to
edit. The Event Master Record Function screen is
displayed in Edit mode.
2 Re-enter DELETE on the Command line, and press
Enter.
3 Re-enter DELETE on the Command line, and press Enter
to confirm, or press F3 to cancel.
Edit the WHEN conditions Enter E to the left of the dependency that you want to edit.
for a particular version of
The Event Master Record Function screen is displayed in Edit
the event
mode.
When finished editing the dependency, press Enter to save
your changes.
142
4 Events
Condition Codes
You use condition code validation for these purposes:
Flag a job as abended based on end-of-job (EOJ) or end-of-step (EOS) condition

codes
Cancel a job based on EOS condition codes
Define an acceptable range of condition codes based on EOS
Define EOJ and EOS condition code checking for an event
Maintain the maximum condition code at EOJ
Zeke does not consider a condition code to be an abend, unless the operating system
considers it an abend (or unless you manually define it as an abend).
You can define the condition code at the step level or job level. Step-level and EOJ
checking are processed independently. This is useful if there is a maximum condition
code that is valid for the entire job, and in addition, a specific condition code on a specific
step requires an immediate cancellation.
Note:
The MaxCC generation option enables you to specify a default maximum job condition
code for job events that do not have condition codes specified.
Zeke checks any specified step names first; then, after the job is completed, Zeke checks
the maximum condition code for the job.
For every step specified, Zeke searches for the first match on STEP NAME, PROC
STEP, OPERATOR, and RANGE. If a match is found, Zeke performs the specified
action and the search ends. If there is no match, no action is taken.
If an end-of-job condition is specified (i.e., EOJ CC), then that condition is compared at
the end of the job to the maximum condition code from any step in that job. A condition
code value that is acceptable at the step level can be designated as AEOJ at the job level.
Note:
If you have Zebb installed, condition code checking should be performed in Zeke.
143
Defining Condition Codes for an Event

This section explains how to add, update or delete condition codes for an event.
To define condition codes for an event

1
Access the Event Master Definition screen for the event, as instructed in Accessing
From the Event Master Definition, enter CCODE on the Command line, and press
Enter. The Condition Code Validation screen is displayed:
ASG-Zeke
Command ===>
EDIT
Scroll ===> PAGE

Event: 000011
Jobname: SPTEXD11
Operators:
Actions:
System: ZEQA
EQ NE LE LT GE GT
Event Name: ZEKE60CC
RA =Range
O = Ok
Stepname
Procstep
Operator
- Range Low High
Action
EOJ CC
STEP01
STEP02
********
********
********
********
GT
NE
GT
8
16
0
F
O
C
Perform the steps in the Action column (depending upon the desired result):
Desired Result
Action
Add a new or edit an

existing condition code
Enable Edit mode (if necessary).
Delete a single condition

code
Enter D to the left of the condition code that you want to

delete, and press Enter.
Insert a new line
Enter I to the left of the line after which you want to insert
a new line, and press Enter.
Go to step 4.
Note:
You cannot insert lines before the line EOJ CC.
Repeat this line
144
Enter R to the left of the line that you want to repeat, and
press Enter.
4 Events
Complete these fields (as applicable):

Field
Description
Stepname
Specify the JCL step name. If the step is in a procedure, specify the step
name that executes the procedure. If the stepname is nulls or blanks,
specify the procstep name.
You can use an asterisk (*) as a wildcard character to identify a generic
step name. For example, you would enter ***STEP5 to select
stepnames with STEP5 in positions 4 through 8.
Always list the most specific steps first, and the most generic steps last.
For example, list STEP3 before ********. See Sample Condition
Code Entries on page 146 for detailed examples.
Procstep
Specify the stepname within the procedure. If the JCL stepname was
nulls, and you entered the procstep name in the Stepname field, leave
this field blank.
You can use an asterisk (*) as a wildcard character to identify a generic
procstep name. For example, you would enter ***PROC5 to select a
procstep name with PROC5 in positions 4 through 8.
Operator
Indicate when to perform a specified action. These are the valid codes:
EQ
When the condition codes are EQual.
LE
When the condition code is Less than or Equal to the

specified condition code.
LT
When the condition code is Less Than the specified

condition code.
GT
When the condition code is Greater Than the specified

condition code.
GE
When the condition code is Greater than or Equal to the

specified condition code.
NE
When the condition codes are Not Equal.
RA
When the condition code is in the specified RAnge.
Low
If Operator is RA, specify the lowest code in the range to compare.
High
If Operator is RA, specify the highest code in the range to compare.
Action
Indicates the action to take when the condition code meets the specified
criteria. These are the valid codes:
145
Field
Description
F
Flag the job as Failed during end-of-job processing.
Cancel the job at this step, and flag it as Failed, during

end-of-job processing.
Continue processing.
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.
In the Action field, enter F. This is the only valid action for the job level.
Checking is done at end-of-job for the maximum condition code from any step
in this job. This checking is done independently of any specified step-level
checking.
Sample Condition Code Entries

These sample screens illustrate a few different scenarios to assist in defining condition
codes.
In this example, Stepname Procstep ******** ******** acts as a generic condition
code, and applies to all steps except STEP3. If STEP3 receives a condition code 4, job
processing continues; but if any other step gets a condition code greater than zero, the job
is marked AEOJ and is cancelled:
ASG-Zeke
Command ===>
EDIT
Scroll ===> PAGE

Event: 000011
Jobname: SPTEXD11
Operators:
Actions:
Stepname
EOJ CC
STEP3
********
146
System: ZEQA
EQ NE LE LT GE GT
Procstep
********
********
Operator
EQ
GT
RA =Range
O = Ok
- Range Low High
4
0
Action
O
C
4 Events
In this example, EOJ CC takes priority because it is encountered first in the list. The
conditions for STEP3 and STEP5 are ignored, and the job is marked AEOJ, even if
STEP3 receives a condition code 4 or if STEP5 receives a condition code 8:
ASG-Zeke
Command ===>
EDIT
Scroll ===> PAGE

Event: 000011
Jobname: SPTEXD11
Operators:
Actions:
System: ZEQA
EQ NE LE LT GE GT
Stepname
Procstep
EOJ CC
STEP3
STEP5
********
********
Operator
GT
EQ
LE
RA =Range
O = Ok
- Range Low High
0
4
8
Action
F
O
O
If you want to use the previous example as a model, but you want the conditions for
STEP3 and STEP5 to be checked, define the condition codes as shown in this example:
ASG-Zeke
Command ===>
EDIT
Scroll ===> PAGE

Event: 000011
Jobname: SPTEXD11
Operators:
Actions:
Stepname
EOJ CC
STEP3
STEP5
********
System: ZEQA
EQ NE LE LT GE GT
Procstep
********
********
********
Operator
EQ
LE
GT
RA =Range
O = Ok
- Range Low High
4
8
0
Action
O
O
F
147
This is the same scenario, but with a procstep defined:

ASG-Zeke
Command ===>
EDIT
Scroll ===> PAGE

Event: 000011
Jobname: SPTEXD11
Operators:
Actions:
Stepname
EQ NE LE LT GE GT
Procstep
EOJ CC
STEP3
STEP5
********
System: ZEQA
Operator
PSTEP3
********
********
RA =Range
O = Ok
- Range Low High
EQ
LE
GT
Action
4
8
0
O
O
F
In this case, the job is not marked AEOJ if STEP3 PSTEP3 receives a condition code 4,
or if STEP5 receives a condition code less than or equal to 8. Otherwise, if any other
step/program receives a condition code greater than zero, the job is marked AEOJ.
(Consequently, if any program within STEP3 other than PSTEP3 receives a condition
code 4, the job is marked AEOJ.)
If the JCL step name is nulls, and the procedure MYPROC contains the step MYSTEP,
define the condition codes like this:
ASG-Zeke
Command ===>
EDIT
Scroll ===> PAGE

Event: 000011
Jobname: SPTEXD11
Operators:
Actions:
148
System: ZEQA
EQ NE LE LT GE GT
Stepname
Procstep
Operator
EOJ CC
MYSTEP
********
********
EQ
GT
RA =Range
O = Ok
- Range Low High
4
0
Action
O
F
4 Events
Work Centers
Work center events are tasks that require manual operator intervention. For example:
User input (e.g., dates or check numbers)
User approval
Completion of a manual task (e.g., data entry)
Work centers enable an operator to interact with the schedule directly. You can add, alter,
and control your own events without filling out a form, making a phone call, or writing a
note to an operator or your data center.
Work centers are useful for these types of functions:
Scheduling manual tasks that need to be complete by a certain time. Zeke lets you
know, for example, when an event is late.
Running request jobs exactly when you need them. Operator notification or
intervention is not necessary.
Approving an event for processing.
Setting Zeke/OASIS variable values.
Triggering other events in the schedule.
Acting as a prerequisite for another event. Completion of a work center satisfies an

EOE dependency.
Setting a variable through a work center and using that variable with the VAR
keyword in a dependency.
While work centers can be predecessors for other events, they do not have their own
WHEN condition. Instead, work centers can have SET clauses, as explained in this
section.
Work centers do not use resources.
Note:
Zeke Web Services enable you to view and manage Zeke work center events from a Web
browser. See Managing Work Centers from the Web on page 409 for more
information.
149
Using Variables in Work Centers

Work centers are often used to set variables. You can specify for a work center to set a
variable to a specific value and then use that value as the prerequisite for another event.
For example, suppose you are waiting for management approval before running a job.
You can set up a work center to be completed when approval is obtained. Lets say you
set up a variable called $APPROV. Completing the work center sets the variable
$APPROV to the value GO. The work center event would contain the WHEN condition
$APPROV EQ GO. When the work center is completed, $APPROV equals GO and the
dependent job is triggered.
SET Clauses
Zeke or OASIS variables can be set to a specified value when a work center is completed.
The SET clause defines how a variable value is set when a work center is completed. The
format of the SET clause is similar to a WHEN condition that uses the VAR keyword,
except that only an EQUAL condition can be specified. For example:
(VAR $TEST01 EQ PROCEED AND VAR $TEST02 EQ WAIT)
(XVAR TEST03 EQ 'A VALUE WITHIN DELIMITERS')
Use these keywords in the SET clause statement:

Keywords
Zeke
OASIS
Description
VAR
XVAR
Variable is automatically set to the specified value when the work center
is completed. The operator cannot change the value.
(VAR $JOB1 EQ 45)
When the operator completes this work center, the $JOB1 variable is
automatically set to 45.
?VAR
?XVAR
Variable value can be entered by the operator before completion of the

work center; if desired (the operator is not required to change the value).
When the operator completes an event with a ?VAR or ?XVAR, Zeke
displays a screen for entering the variable value.
Example:
(?XVAR DATE EQ 'MM/DD/YYYY')
In this example, 'MM/DD/YYYY' is the default value and is retained

unless the operator enters a new value.
When the operator completes this work center, the next Work Center
Control Functions screen is displayed and prompts the operator to specify
the current date.
150
4 Events
Keywords
Zeke
OASIS
Description
When using OASIS variables in a SET clause, do not enclose the variable name in the substitution
prefix/suffix (the $( ), or additional prefix/suffix defined for your system).
OASIS variables qualified by jobname cannot be used in work centers. (See the ASG-OASIS for
z/OS Reference Guide for detailed information about OASIS variables and qualifiers.)
Keywords can be mixed in the same SET clause. For example:
(?VAR $TEST03 AND XVAR TEST02 EQ 'YES')
When this work center is flagged as complete, the operator is prompted to specify the value for
$TEST03 and Zeke automatically sets the OASIS variable TEST02 to YES.
Defining a Work Center

Work centers are typically set up by scheduling personnel, and completed by data center
operators.
To define or maintain a work center

1
Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
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:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
WorkCtr
WorkCtr
WorkCtr
WorkCtr
WorkCtr
WorkCtr
Line
Line
Line
Line
Line
Line
1:
2:
3:
4:
5:
6:
OBTAIN MGMT OK FOR CHECK RUN
151
Complete these fields (as applicable) to define a work center:

Field
Description
Template
values are Y and N. See Defining an Event Template on page 63 for
more information.
Desc/Desc2
Specify a description of the work center event. This description is

displayed on summary screens and printed on reports.
Event Name
Specify the name of the work center event. The event name is
displayed on Zeke online screens and reports, and can be used as
selection criteria. The event name also can be specified in
end-of-event (EOE), abnormal-end-of-event (AEOE) and
Usrid
Specify the user ID (up to eight characters long) for the user
authorized to access the work center event.
Since Zeke supports mixed-case user IDs, be sure to specify the
desired user ID in the correct case (upper, lower, or mixed).
Note:
System
Specify the system or pool that owns the work center event (which can
be associated with only one system).
Note:
This is the system where the event is dispatched, and not necessarily
the system where the EMR was defined.
152
4 Events
Field
Description
Verload
Specify the number of versions of this event that Zeke loads during the
schedule build. The valid values range from 0 to 32767. The default
value is 0.
For example, if Verload is set to 3, Zeke adds EMRs to the schedule
for three versions of the event during schedule build (i.e., versions 1,
2, and 3).
If Verload is set to 0, then only one version of the event (version zero)
can be in the schedule at a time.
Note:
ASG recommends that you run no more than 1,000 versions of a
single event.
See Creating Multiple Versions of an Event on page 76 for details
on multiple event versions.
Note:
previous field on the EMR), to prevent you from overtyping data
intended for the Target field so that it overflows into the Verload
field. Stray characters in the Verload field could result in an
excessive number of events being scheduled unintentionally during
the next schedule build.
WorkCtr Line
Specify a description of the work center activity. This information

serves as instructions to the work center operator. You can enter up to
six lines of comments. If more lines are needed, you can use the
Documentation facility to add more notes.
153
Field
Description
App
Specify the code (up to eight characters long) to identify the

application ID associated with the work center event.
Grp
associated with the work center event. This field is a subset of the
application ID.
To set up a SET clause for this work center, enter WHEN on the Command line, and
press Enter. The Event Master Record Function screen is displayed:
ASG-Zeke
Command ===>
Event Master Record Function
EDIT
Scroll ===> PAGE
Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN

Evt: 000246 Type: WORK Job:
Evt Name: CASH0199
Calid: A
Ver: 00000
Info:
***** ***************************** Top of Data ****************************
==MSG>
000001 (?VAR $JOB1KG EQ XXXXXX)
***** **************************** Bottom of Data **************************
A SET clause is used instead of a WHEN condition for work center events.
6
Specify the SET clause (enclosed in parentheses).

See "SET Clauses" on page 150 for more information. See IF Clauses On SET
Statements on page 366 for information on defining the prerequisites that must
occur before Zeke dispatches the event.
Press Enter to save the changes. The screen is redisplayed in Update mode.
154
Perform the procedure Defining an OCCURS Clause on page 121 to specify when
Zeke schedules the event.
4 Events
Be sure the operator has Zeke access. You can set up a users Zeke operator ID, so
that when they log on to Zeke, the Work Center Selection Criteria screen is
automatically displayed. See Defining Operator Records on page 389 for more
information.
a
Enter A to create a class ID with auto-entry access to the Work Center

function.
Associate the users operator ID with the class ID and the user ID of the work
center event.
Be sure all operators are aware of their user IDs for their work center events and
how to log on to Zeke.
The next time the SCHEDULE function runs, the work center event is scheduled
(assuming the OCCURS clause is true).
Completing Work Centers

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

1
Depending on how your operator ID is set up, the Work Center Selection Criteria
screen might automatically display when you log on to Zeke. Go to step 3.
If the Work Center Selection Criteria Screen does not automatically display when
you log on to Zeke, then from the Zeke Primary Menu, enter option 5. The Work
Center Selection Criteria screen displays, and enables you to display a directory of
work center events:
ASG-Zeke
Option ===>
1
2
3
Work Center Selection Criteria
Not Done
All
Done
Directory of scheduled Work Centers not completed

Directory of all matching scheduled Work Centers
Directory of scheduled Work Centers completed
.-------- Selection Criteria --------.

|
|
| UserID => KAC
|
| App
=>
|
| Group =>
|
| System =>
|
|
|
'------------------------------------'
155
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).
Optional. Complete these fields (as applicable) to select the work centers that you
want to display:
Note:
You can use wildcards and placeholders (see Specifying Generic Selection
Criteria on page 57). You also can leave a field blank, or enter an asterisk (*) to
omit the field from the selection criteria.
Field
Description
UserID
Specify selection criteria to specify the group of user IDs to select.

Zeke supports mixed-case user IDs. Be sure to specify the search
criteria in the correct case (upper, lower, or mixed).
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
Press Enter. The Directory of Work Center Events is displayed:

ASG-Zeke
Command ===>
Line Commands:
Directory of Work Center Events
A disAble
R Refresh
B Browse
C Complete
Today :04/19/2012
Time
Event
Work Date Versn Sched Event Name
000202 06/17/2012 00000 00:00 EANTST
000205 06/17/2012 00000 00:00 EANTST05
000833 06/17/2012 00000 00:00 TEST OVAR
***************************** Bottom of data
N eNable
Row 1 to 2 of 2
Scroll ===> PAGE
O dOcumentation
:12:46:55 (36:46:55)
Appl
Grp System Set Status
TSO45
Y NOT DONE
TSO45
Y NOT DONE
APPL
GRX TSO45
Y NOT DONE
******************************
Desired Result
Action
Browse the event
Enter B to the left of the Event field.

Use this command before completing the work center if
SET=N.
156
4 Events
Desired Result
Action
Complete the event
Enter C to the left of the Event field. If SET=N, Zeke

updates the event status to Done.
If SET=Y, the Work Center Function screen is displayed,
and prompts you to verify the variable value or enter a new
value.
Go to step 8.
Disable the event
Enter A to the left of the Event field, if the event is not

considered part of the schedule. Zeke updates the event
status to Disabled.
Enable the disabled event
Enter N to the left of the Event field. Zeke updates the

event status to Enabled.
Refresh the event
Enter R to the left of the Event field. Zeke updates the

status of a completed event to Not Done.
Display the Work Center

Doc. Segments Screen
Enter O to the left of the Event field. See Accessing Event

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

ASG-Zeke
Command ===>
Work Center Control Function
Primary Commands:
Event: 000229
Appl: PAY
COMPLETE
DISABLE
DOCUMENT
Event Name: PAYCHECK

Group: PAY
UserID: KAC
ENABLE
REFRESH
System: A
Set ver: 00000
Schd: 00:00 Sdate: 01/30/2012 Rdate: 01/30/2012 Today:01/30/2012

Late:
Times: 0001 Freq:
* Done *
Time:16:01:51 (40:01:51)
Comment Line 1: ENTER THE STARTING CHECK NUMBER AND PRESS ENTER.
Comment Line 2:
Comment Line 3:
Comment Line 4:
Comment Line 5:
Comment Line 6:
Set: (?VAR $PAYCHECK EQ 'NNNN')
Note:
You can press Enter to display additional SET statements when there are multiple
variables.
157
Press Enter. The Work Center Control Function screen is displayed in Update mode:
ASG-Zeke
Command ===>
Depress the enter key to accept the new value, or depress PF3 to
maintain the current value.
Event: 000229 Appl: PAY
Event Name: PAYCHECK
Group: PAY
System: A
UserID: KAC
Set ver: 00000
Schd: 00:00 Sdate: 01/30/2012 Rdate: 01/30/2012 Today: 01/30/2012

Late:
Times: 0001 Freq:
NOT Done
Time: 15:59:27 (39:59:27)
Comment Line 1: ENTER THE STARTING CHECK NUMBER AND PRESS ENTER.
Comment Line 2:
Comment Line 3:
Comment Line 4:
Comment Line 5:
Comment Line 6:
Data-Name: $PAYCHECK
Curr Value: 1001
New Value: 'NNNN'
Force upper: Y
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
Indicates to force the Current Value string to uppercase.
Indicates to keeps the case of the Current Value exactly as entered. Use this
code if you need to allow mixed-case values for variable substitution.
Note:
If the Current Value is numeric only, Zeke ignores the Force Upper option.
158
4 Events
10
Press Enter. A verification screen is displayed after all the variables are set:
ASG-Zeke
Command ===>
Primary Commands: COMPLETE
Row 1 to 2 of 2
Scroll ===> PAGE
CANCEL
Event: 000229
Ver: 00000 Sdate: 01/30/2012
Rdate: 01/30/2012
Today :01/30/2012
Time :15:59:27 (39:59:27) Set Ver: 00000
-------------------------------------------------------------------------Variable: $PAYCHECK
?Value: '1051'
****************************** Bottom of data*******************************
11
Desired Result
Action
Confirm that the values are correct,

and complete the work center.
Enter COMPLETE on the Command line, and

press Enter.
The Work Center Directory is displayed. Zeke
updates the event status to Done.
Do not set the values, or do not

complete the work center.
Enter CANCEL on the Command line, and press

Enter.
The Work Center Directory is displayed. The
event status is unchanged.
Auto Replies
Zeke enables you to respond automatically to outstanding replies (WTORs) from your
Zeke-controlled jobs that have static or predictable responses. Replies also can use Zeke
or OASIS variables to substitute all or part of the reply text. They can be limited by date,
step, and program. Up to 999 replies can be defined for a single job. For example, replies
can be triggered by any portion of the text of the message, message ID, or unique text
string. Replies can even be triggered by suppressed messages. Each reply is called an
element.
Note:
Auto replies are not supported in remote jobs. If a remote job containing an auto reply is
dispatched, it must be replied to manually on the remote system.
159
Related Generation Options

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

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

1
160
Verify the Aur, Aurintv, and Aurmsg generation option settings:
Determine the how automatic replies are set up for your Zeke systems
globally. See Auto Reply Options on page 308.
If there are exceptions to how automatic replies are set up globally, use
ZDISPLAY, ZENABLE, and ZDISABLE operator commands, as applicable.
See Managing Auto Replies on page 163.
4 Events
Enter AUTORPLY on the Command line, and press Enter.
If auto replies do not exist for the event, the Auto Reply Function screen is
displayed. Go to step 5.
If auto replies exist for the event, the Auto Reply Summary screen is
displayed.
The Auto Reply Summary screen provides a list of all auto reply elements that have
been defined for the event.
ASG-Zeke
COMMAND ===>
Auto Reply Summary

SCROLL ===> PAGE Z1113000
Primary Commands: ADD DELALL

Line Commands: B - Browse D - Delete
E - Edit
Event: 000019 Jobname: SPTEXD19 System: ZEQA

Event Name: EKGSTRT1
NUM ----------------------- Message Text ----------------------PROGRAM
001 TEST MSG
001 ENTER GO TO PROCESS
***************************** Bottom of data ******************************
Desired Result
Action
Add an auto reply element Enter ADD on the Command line, and press Enter.
Delete all auto reply
elements
1 Enter DELALL on the Command line, and press Enter.
Browse the auto reply

detail
Enter B to the left of the NUM field, and press Enter.
Edit the auto reply element Enter E to the left of the NUM field, and press Enter.
Delete the specific
auto reply element
Enter D to the left of the NUM field, and press Enter.

Press Enter again to confirm.
161
The Auto-Reply Function screen is displayed:

ASG-Zeke
Command ===>
Auto-Reply Function
EDIT
Update complete
Primary Commands: ADD BACK BROWSE DELALL DELETE EDIT NEXT

Event: 000019
Jobname: SPTEXD19
System: ZEQA
Desc: EKGSTRT1
Desc2:
Automatic Reply Element Number: 001
Msg text: ENTER GO TO PROCESS
Reply: GO
Effective as of: 01/01/2012
Effective until: 06/01/2012
Job step name: STEP1
Program (Exec):
<==
<==
MM/DD/YYYY
MM/DD/YYYY
The Automatic Reply Element Number is the Zeke-assigned number that identifies
the reply element. When there are multiple replies to the same message text, Zeke
issues the elements in sequence starting with the lowest number and flags the
element as used. If the message is issued more times than there are replies, the last
used element is repeated. If a message is defined with only one reply, Zeke issues
that reply as many times as needed.
5

Field
Description
Msg Text
Specify the message to which to reply. This does not need to be the
whole message (just enough to make a unique match). The message
ID usually is a unique identifier.
Reply
Specify the reply that Zeke issues to the message. For example:
To enter a null reply
Leave the Reply field blank.
To enter a static reply
Enter a value (e.g., YES).
To use a variable for a reply Enter a variable (e.g., $CURDATE).

To use a variable with
constant values in a reply
Enter a variable and any appropriate

static text. For example:
YESTERDAY WAS $(PREVDATE)
Effective As Of
162
Specify the date (MM/DD/YYYY) that the reply becomes effective.
4 Events
Field
Description
Effective Until
Specify the date (MM/DD/YYYY) that the reply expires.
JOB STEP NAME
Specify the z/OS job stepname that issues the message text. The auto
reply is valid only if this job step issues the message.
Program (EXEC)
Specify the program name that issues the message text. The auto
reply is valid only if this program issues the message.
Managing Auto Replies

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

You can use the ZDISPLAY operator command to perform a wide variety of functions.
For example, you can display the active automatic reply elements for a given jobname. If
a job event is running, Zeke displays the messages and replies that are active for that job
event.
To display active automatic reply elements
Issue the ZDISPLAY operator command, and include the JOBNAME and REPLY
parameters. For example, to display messages and replies for jobname TESTXYZ,
issue this command:
ZDISPLAY JOB TESTXYZ REPLY
Enabling Auto Replies (ZENABLE)

You can use the ZENABLE operator command to perform these actions.
To reactivate or enable one or more events that were previously disabled using the
ZDISABLE operator command.
To reactivate the automatic reply elements for an event that had automatic replies
disabled.
A disabled event that was scheduled for a prior day will most likely have been dropped by
the current day's first schedule update.
163
To enable an auto reply for an event
Issue the ZENABLE operator command, and include the REPLY and EVENT
parameters. For example, to enable previously disabled auto replies for event 55,
issue this command:
ZENABLE EV 55 REP
Disabling Auto Replies (ZDISABLE)

You can use the ZDISABLE operator command to perform these functions:
To deactivate or disable one or more events that were previously enabled using the
ZENABLE operator command. The ZDISABLE operator command prevents
WHEN conditions for that event from being satisfied.
To deactivate the automatic reply elements for an event that had automatic replies
enabled.
To disable an auto reply for an event that is not running
Issue the ZDISABLE operator command, and include the REPLY and EVENT
parameters. For example, to disable the auto reply for event 77, issue this command:
ZDISABLE REP EV 77
Event Documentation
You can use event documentation to store useful information about an event. These are
the areas where you can store event documentation:
164
Documentation Type
Description
Dataset
Stores names of datasets used by a job event
Note
Stores brief notes up to 10 lines
Scratch
Stores brief notes up to 10 lines
Text
Stores up to approximately 450 records
4 Events
Accessing Event Documentation

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

1
From the Zeke Primary Menu, enter option 7. The Documentation Selection Criteria
Desired Result
Action
Update documentation
for which you know the
event number

2 Specify the event number in the Event field.
3 Press Enter. The Documentation Segments screen is
displayed.
Go to step 4.
Update documentation
for which you do not
know the event number
1 Enter any character next to the appropriate event type under

Event Types and any information you know for any of the
2 Press Enter.
165
The Event Documentation Directory is displayed:

ASG-Zeke
Command ===>
Event Documentation Directory

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

n = 1 through 4 for specific types of documentation
Event -Event Name000001 ZEKE60TST1

000002 ZEKE60TST2
000003 ZEKE60TST3
000004 ZEKE60TST4
000005 ZEKE60TST5
000006 KTEST1
000007 KTEST2
000008 KTEST3
000009 KTEST4
000010 KTEST5
000011 ZEKE60CC
000012 ZEKE60CC
000013
000014
000015
000016
Jobname
TSKKGUT1
TSKKGUT2
TSKKGUT3
TSKKGUT4
TSKKGUT5
SPTEXD11
SPTEXD12
Type
MSG
MSG
MSG
MSG
MSG
JOB
JOB
JOB
JOB
JOB
JOB
JOB
WORK
VCOM
ZCOM
SCOM
1
Scratch
*
2
Text
*
3
Tape
*
4
Note
*
*
An asterisk (*) indicates the types of documentation that exist for the event.
3
Desired Result
Action
Edit scratch pad

documentation for the event
Enter E1 to the left of the Event field, and press Enter.
Edit text documentation for

the event
Edit dataset documentation

for the event
Edit note documentation for

the event
166
Go to Maintaining Scratch Pad or Note Documentation

on page 168.
Go to Maintaining Text Documentation on page 169.
Go to Maintaining Dataset Documentation on page 170.

on page 168.
4 Events
Desired Result
Action
Delete the specified

documentation for the event
Enter Dn to the left of the Event field, and press Enter

(where n indicates the documentation type). These are the
valid values:
1
Scratch Pad
Text
Dataset Name List
Note Pad
The asterisk (*) indicating that documentation for the
event exists is deleted, and the message:
DOCUMENT RECORD DELETED is displayed.
The Documentation Segments screen is displayed:

ASG-Zeke
Option ===>
EDIT

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

1 * SCRATCH
2 * TEXT
3
TAPE
4 * NOTE
Scratch pad
Text information
Dataset name information
An asterisk (*) indicates the types of documentation that exist for the event.
4
to work with:
Desired Result
Action
Access scratch pad

documentation
Enter 1, and press Enter.
Access text documentation

on page 168.
Go to Maintaining Text Documentation on page 169.
167
Desired Result
Action
Access dataset or tape

documentation
Access note documentation
Go to Maintaining Dataset Documentation on page 170.

on page 168.

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

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

ASG-Zeke
Command ==>
CANCEL
DELETE
EDIT
EDIT
Line 1 SCRATCH TEXT FOR 30-BYTE NAME JOB

2
3
4
5
6
7
8
9
10
Event: 000031 Jobname: A2345678 Event Name: TESTNAME
System: A
Desc : 30-CHAR NAME NOM
Desc2:
Early:
Sched: 00:00 Late:
Freq:
Times: 0001
Vmem :
0* Tapes: 000
Average run time:
:00 Jcl: ZEKE
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.

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

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

ASG-Zeke
Command ===>
Event:
******
==MSG>
==MSG>
000001
******
Text Documentation
EDIT
Columns 000 000
Scroll ===> PAGE
000031 Jobname: A2345678 Event Name: TESTNAME

System: A
*************************** Top of Data *****************************
-Warning- The UNDO command is not available until you change
tHIS JOB USES TEH 30-CHAR NAME. REVIEW ALL 30 CHAR
*************************** Bottom of Data **************************
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.
Optional. Press F8 to page forward to access an additional screen. Repeat, as

necessary.
Maintaining Dataset Documentation

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

1
Access the Data Set Name List screen, as instructed in Accessing Event
ASG-Zeke
Command ===>
Data Set Name List
Scroll ===> PAGE
Primary commands:
BROWSE CANCEL DELETE EDIT
Line commands: D Delete line
I Insert line
Event: 000031
EDIT
Jobname: A2345678 System: A
R Repeat
Event Name: TESTNAME
I/O T/D Ver --------------Dataset Name-----------------I

T 001 JNM.TAPE.STORE
***************************** Bottom of data ******************************
170
4 Events

Field
Description
I/O
Specify the dataset type. These are the valid values:
T/D
Ver
Default. Input dataset.
Output dataset
Specify the dataset media type. These are the valid values:
T
Default. Tape.
Disk
Specify the dataset version number. The valid values are 001 for the
current dataset, 002 for the next most recent dataset, etc. The default
value is 001.
This field is a required field for input datasets; otherwise, you can leave
this field blank.
Dataset Name
Specify the dataset name.
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.
171

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
Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 333
Desc: TEST JOB KMC
Type: JOB Desc2:
Event Name: ZEKEKMCASG
System: ZEQA
Cal: A
Target: *LOCAL
Verload: 0
Latestart: 13:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Control: Y Tapes: 0
Job: MBCBR14
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
172
Class:
Pri: 0
CMS:
Ftype:
4 Events
Enter ACC on the Command line, and press Enter. The Event Master Record
Accounting screen is displayed:
ASG-Zeke
Command ===>
Event Master Record Accounting
BROWSE
Primary Commands: BROWSE EDIT

Evt: 000333
Type: JOB
Avgdur: 00:12:15
Alert Tolerance: 50
Job: MBCBR14
Ename: ZEKEKMCASG
System: ZEQA
Enable Duration Alerts:

Job ran 20 Times
Fail if short or long:
Normal Range: 00:05:10 - 00:19:20 Clear Duration Stats Y
Dispatched
6 Times
Last Update: 01/14/2012 15:33 by BOB
Start: 01/14/2012 17:37:00
End: 01/14/2012 17:37:30
Job ID: JOB00006
Version:
1
Sched Date: 01/14/2012
Status: F/FAIL
Dispatch Date 01/14/2012 at 17:37:00
Dur: 00:00:30
Cputime: 00:00:01
Tapes:
0
Comp.code C0000
Vmem:
0
Status: F/FAIL
Dispatch Date 01/07/2012 at 11:31:00

Dur: 00:21:55
Cputime: 00:00:01
Tapes:
0
Comp.code C0000
Vmem:
0
Status: Fail Long
Dispatch Date 01/02/2012 at 12:25:00

Dur: 00:14:02
Cputime: 00:00:01
Tapes:
0
Comp.code C0000
Vmem:
0
Status: Success
Note:
You also can access this screen from the OCCURS screen in the EMR.
The screen displays this event activity information:
Average duration of the job.
Whether the DurAlert generation option has been overridden for the event.
Number of job runs included in the jobs current duration statistics.
Alert tolerance (used to calculate the acceptable range of duration times for
the event).
Whether the DurFail generation option has been overridden for the event.
Acceptable range of duration times for the event.

If duration alerts and/or duration failure are enabled for the event, executions
that run shorter or longer than this range will generate an alert and/or be
marked as failed.
Number of times the event has been dispatched.
Last date/time the EMR was updated (and the user who updated it).
Start date/time of the last execution that ran to completion. (If the job has
never dispatched, this field does not appear.)
173
Status of the last execution that ran to completion:
SUCCESS indicates that the event completed successfully (or the event
completed successfully after failing once).
FAIL indicates that the event ended abnormally.
F/SUCC indicates that the event was forced to a successful completion

(or the event was forced to a successful completion after failing once).
F/FAIL indicates that the event was forced to an abnormal completion.
FAIL LONG indicates that the event completed, but was marked as failed
because it ran longer than its acceptable range of duration times.
End date and end time of the last execution that ran to completion. (If the job
has never dispatched, this field does not appear.)
Details about the last three dispatches.
Note:
Zeke evaluates and expresses most time values in hours and minutes only; however,
because they affect whether (and when) any dependent events are triggered, Zeke
evaluates and expresses dispatch and end times in hours, minutes, and seconds.
This is especially important for certain extended dependencies. For example, lets
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 events
average duration and displays this value in the Avgdur field. You can configure Zeke to
alert you if a job runs much longer than or shorter than its average duration. You also can
configure Zeke to mark these jobs as failed after they are completed. To use either of
these features, you must tell Zeke how much variation is acceptable from the average
duration.
174
4 Events
Average Duration
Zeke calculates a jobs average duration by adding the last 10 execution times, and
dividing by 10. If the job has not been dispatched 10 times yet, the sum is divided by the
number of times dispatched. (If a job abends, Zeke does not include it in the average
duration calculation.)
In addition to calculating the Avgdur value, Zeke uses the last 10 runs of a job to
calculate the standard deviation, which is a measure of the spread of a series of run
durations around the average duration. If a jobs durations are tightly clustered around the
average duration, the standard deviation is small; if a jobs durations vary widely, the
standard deviation is large. If you want to enable duration alerts and/or failures, you must
tell Zeke the amount of deviation that should trigger an alert or failure. This is specified
using the Alert Tolerance field.
Alert Tolerance
Alert Tolerance a value that ranges from 0 through 100 that Zeke uses to calculate the
acceptable range of durations for a job:
An Alert Tolerance value of 0 indicates that there is no tolerance for deviation from
the average duration. Zeke considers any job that runs longer or shorter than the
average duration to have run too long or too short. Because this setting is likely to
generate many alerts/failures, ASG does not recommended it.
An Alert Tolerance value of 100 enables a job deviate from the Avgdur value up to
three times the standard deviation. This setting is likely to generate very few alerts.
An Alert Tolerance value of 33 enables a job to deviate from the Avgdur value
approximately equal to the standard deviation.
The default Alert Tolerance value is 50.
When you specify an Alert Tolerance value, Zeke uses the Avgdur, the standard
deviation, and the Alert Tolerance to calculate the acceptable range of durations for the
job (which are reflected in the Normal Range field). You can experiment with different
values in the Alert Tolerance field to see how the Normal Range is affected. You also can
modify the Normal Range values directly.
In general, the smaller the Alert Tolerance value, the more likely it is that the job will
generate a duration alert. ASG recommends that you set this number high enough to
avoid frequent alertsset 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 orderAlert Tolerance, then Normal Range (high), then Normal Range
(low), then Avgdur. For example, if you change all of these fields, Zeke accepts only the
change made to Alert Tolerance and then automatically calculates the Normal Range
175
values. If you change only the Normal Range low value, Zeke calculates the Normal
Range high value and the Alert Tolerance. If you change only the Normal Range high
value, Zeke calculates the Normal Range low value and the Alert Tolerance.
Note:
If you update the Avgdur field, Zeke automatically resets the Job ran xx Times value to
1, and resets the standard deviation to 25 percent of the average duration.
Duration Alerts and Failures

You can enable or disable duration alerts and/or failures on a global level for all events
(see Global Duration Alert/Failure Options on page 177). You also can override these
global settings for specific events (see Enabling or Disabling Job Duration Alerts and
Failures on page 178).
Note:
Enabling duration failures does not cause jobs to be cancelled. When a job ends, if its
duration fell outside the Normal Range, Zeke marks the job as failed, and issues message
Z8T02I. If a job abended or failed due to a condition code record, Zeke does not mark the
job as failed (due to its duration). Zeke marks a job as failed only due to its duration if it
otherwise would have been marked successful. Zeke marks these jobs as failed to prevent
them from triggering successor jobs.
Because Zeke needs sufficient history data to determine a jobs normal duration range,
you must specify the minimum number of times a job must run before it is eligible to
trigger alerts or be failed for running outside its normal range. This is done through the
DurCount generation option (see page 177).
If a job has not run enough times to satisfy the Durcount generation option, you can
increase the Job ran xxx Times value to start generating duration alerts/failures sooner.
Keep in mind that the average duration and normal range calculated from only a few runs
might not be truly representative of the jobs normal duration, and so the alerts/failures
generated might not be appropriate.
When a job runs too short or too long, Zeke provides these indications:
176
If duration alerts are enabled, Zeke issues message Z0319W to alert that the event is
running long, ran long and completed, or ran short and completed.
In Schedule View, Zeke highlights the event status if the job is running longer than
its Normal Range.
On the Schedule View WHY screen, the reason code Event ran long/short
indicates that the event has completed, but its duration was longer than or shorter
than the acceptable range of duration times (i.e., Normal Range). The reason code
Event is running long indicates that the event is active, and is running
longer than the acceptable range of duration times (i.e., Normal Range).
4 Events
If duration failures are enabled for the event, Zeke issues message Z8T02I to alert
that the event failed because it ran outside of its acceptable range of durations.
If duration failures are enabled for the event, Zeke assigns the Fail Job Ran
Long status when the event is completed. This indicates that the event failed
because it ran longer than its acceptable range of duration times (i.e., Normal
Range).
If duration failures are enabled for the event, Zeke assigns the Fail Job Ran
Short status when the event is completed. This indicates that the event failed
because it ran shorter than its acceptable range of duration times (i.e., Normal
Range).
If duration failures are enabled for the event, the Status field on the Event Master
Record Accounting screen indicates FAIL LONG for jobs that were marked as
failed because the duration was too long, and FAIL SHORT for jobs marked as
failed because the duration was too short.
If enabled, alerts are also generated in OpsCentral. (OpsCentral alerts are only
generated on z/OS systems that have the Zeke server enabled and active.)
Note:
If duration alerts are enabled, each Zeke system in a sysplex issues the alert.
Global Duration Alert/Failure Options

These Zeke generation options control (at a system wide level) whether Zeke issues alerts
when jobs run long or short, whether Zeke marks jobs that run long or short as failed, and
the minimum number of times a job must run before it is eligible to trigger alerts or fail
for running outside its Normal Range:
Option
Description
DurAlert
Indicates whether Zeke issues a console message (Z0319W) and OpsCentral

alerts if a job runs longer or shorter than the acceptable range of duration
times.
Note:
You can override this option for a specific event using the Enable Duration
Alerts field in the EMR.
DurCount
Specifies the minimum number of times a job must run before Zeke performs
either of these actions:
Uses the events duration history to generate duration alerts.
Fails a job that runs longer or shorter than the acceptable range of
duration times (the jobs fails only if the DurFail generation option is set
to Y, or if the Fail field in the EMR is enabled).
177
Option
Description
The default value is 10. Be sure not to specify a value that is too small, so
that Zeke has sufficient history data to determine the jobs normal duration
range.
DurFail
Indicates whether Zeke fails jobs that run longer or shorter than the
acceptable range of duration times. Zeke marks these jobs as failed to
prevent them from triggering successor jobs.
Note:
This option does not cause a job to be cancelled. When a job ends, if its
duration fell outside the Normal Range, Zeke marks the job as failed and
issues message Z8T02I. If a job abended or failed due to a condition code
record, Zeke does not fail the job (due to its duration). Zeke fails a job due
to its duration only if it otherwise would have been marked successful.
Note:
You can override this option for a specific event using the Fail if short or
long field in the EMR.
See Accessing the Zeke Generation Options on page 281 for details on how to set these
options.
Enabling or Disabling Job Duration Alerts and Failures

You can enable or disable job duration alerts or failures for a specific event.
Note:
You also can enable or disable duration alerts and/or failures globally for all events using
the generation options described in, Global Duration Alert/Failure Options on
page 177. You use the procedure is this section to override the generation options for
selected events.
178
4 Events
To enable or disable job duration alerts or failures

1
Access the Event Master Record Accounting screen, as described in Viewing Event
Accounting Information on page 172:
ASG-Zeke
Command ===>
Event Master Record Accounting
BROWSE
Primary Commands: BROWSE EDIT

Evt: 000333
Type: JOB
Avgdur: 00:12:15
Alert Tolerance: 50
Job: MBCBR14
Ename: ZEKEKMCASG
System: ZEQA
Enable Duration Alerts:

Job ran 20 Times
Fail if short or long:
Normal Range: 00:05:10 - 00:19:20 Clear Duration Stats Y
Dispatched
6 Times
Last Update: 01/14/2012 15:33 by BOB
Start: 01/14/2012 17:37:00
End: 01/14/2012 17:37:30
Job ID: JOB00006
Version:
1
Sched Date: 01/14/2012
Status: F/FAIL
Dispatch Date 01/14/2012 at 17:37:00

Dur: 00:00:30
Cputime: 00:00:01
Tapes:
0
Comp.code C0000
Vmem:
0
Status: F/FAIL
Dispatch Date 01/07/2012 at 11:31:00

Dur: 00:21:55
Cputime: 00:00:01
Tapes:
0
Comp.code C0000
Vmem:
0
Status: Fail Long
Dispatch Date 01/02/2012 at 12:25:00

Dur: 00:14:02
Cputime: 00:00:01
Tapes:
0
Comp.code C0000
Vmem:
0
Status: Success
If the DurAlert generation option is set to Y, and you want to turn alerts off for an
event, enter N in the Enable Duration Alerts field.
Or
If the DurAlert generation option is set to N, and you want to turn alerts on for an
event, enter Y in the Enable Duration Alerts field.
3
If the DurFail generation option is set to Y, and you want to turn the failure option
off for an event, enter N in the Fail if short or long field.
Or
If the DurFail generation option is set to N, and you want to turn the failure option
on for an event, enter Y in the Fail if short or long field.
4
Optional. You can alter the Alert Tolerance, Normal Range, and/or Avgdur values.
See Calculations Done by Zeke on page 174 for details about how Zeke calculates
these values, and how they interact with each other.
179
Note:
If the job has not run enough times to satisfy the DurCount generation option, and
you want to start generating duration alerts/failures sooner, you can increase the
Job ran xxx Times value to match the DurCount value. Keep in mind that Avgdur
and Normal Range values that have been calculated from only a few runs might not
be truly representative of the jobs normal duration, and so the generated
alerts/failures might not be appropriate.
5
Note:
See Duration Alerts and Failures on page 176 for more information on these options.
Considerations for Remote or Downloaded Jobs

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

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

Creating the Schedule Manually
Creating the Schedule Automatically
183
184
186
Downloading the Schedule to Zeke Agent
186
Forecasting and Simulating the Schedule

Forecasting the Schedule
Simulating the Schedule
187
187
188
Creating and Adding an Event to the Schedule
191
Using Schedule View

Schedule View Commands
Displaying Scheduled Events
Updating a Scheduled Event
Displaying or Updating an Event Status
Managing WHEN Conditions
Managing Event Resources
Accessing an Expanded SQR (Using ZOOM)
Customizing Schedule View
Accessing Other Zeke Online Functions
Managing JCL
191
191
200
203
206
213
215
216
218
224
226
181
Topic
Page
Zeke Dispatching
Early Warning Alerts
237
238
/ZCOM Option
Modifying PF Keys
239
240
PathFinder
241
Manually Adding Events to the Schedule

Using the ZADD Operator Command
Using the ADD Function
Adding Events By Path
247
247
249
252
Logical Day (48-hour Clock)

Zeke supports a 48-hour clock, which enables you to schedule according to a logical day.
If you have events that run past midnight, you still can consider those events to be part of
the previous days 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
8:00 A.M.
3:00 P.M.
08:00
15:00
3:00 P.M.
11:00 P.M.
15:00
23:00
11:00 P.M.
8:00 A.M.
23:00
32:00
In the example, using a logical day, shift 1 starts at 08:00, shift 2 at 15:00, and shift 3 at
23:00. You will notice that the end time for shift 3 is 32:00 as compared to 8:00 A.M. on
the normal 12-hour clock. This indicates that the entire eight-hour period of shift 3 is
considered to be part of the same logical workday as shifts 1 and 2.
When the SCHEDULE function runs, it selects every event within 48 hours to be part of
the days schedule. For example, if the schedule runs on Monday at 08:00, events are
selected if their OCCURS clauses match MONDAY and the schedule time is between
00:00 and 47:59.
182
5 Creating and Monitoring the Schedule
Note:
Zeke never dispatches an event with a schedule time of 48:00 because 47:59 is the cutoff
time for dispatching. Use a schedule time of 48:00 for events that you want to place in the
schedule, but do not want to dispatch except by operator command.
Zeke processes an event that is defined as OCCURS(MONDAY) at 27:00 at the same time
as an event that is defined as OCCURS(TUESDAY) at 3:00 A.M. The difference is that
the first event is included in Mondays schedule run, and is considered Mondays event,
while the second event is included in Tuesdays run:
Event
Weekday
Time
Schedule Run Date
Monday
27:00
Monday (actually runs on Tuesday)
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 days
schedule.
Note:
Zeke dispatches events that have no other outstanding dependencies immediately

after completing the schedule load.
Analyzes each event defined in the Zeke database and determines whether the event
is scheduled to occur during the upcoming schedule period.
Note:
Zeke immediately marks events that have no dispatch time (and are not scheduled
for a future date) as time-satisfied.
183
Analyzes each scheduled event and determines whether the event needs to be
downloaded to a remote Zeke Agent system for processing.
Note:
When a schedule is created that contains job events that are specified to be
downloaded to a remote Zeke Agent, Zeke compares the subset of the schedule to
be downloaded with any existing schedules on the Zeke Agent target before
downloading the events.
Zeke provides the ZEKE02MX user exit, which enables you to change various fields in
the SQRs during the schedule build. See the ASG-Zeke Scheduling for z/OS Installation
Guide for more information.
Creating the Schedule Manually

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

1
Run a job using the SCHEDULE control statement to create the schedule at least
once a day:
//ZEKESCHD JOB
//SCHED EXEC ZEKEUTL,PARM=SUBSYS=ZDEV
//SYSIN DD*
SCHEDULE TODAY ACTIVATE DATASPACE
/*
Note:
See the ASG-Zeke Scheduling for z/OS Reference Guide for the additional
parameters you can use with the SCHEDULE function.
2
Ensure that the schedule load is complete before you execute any other batch
schedule runs.
The schedule load is complete when this message appears on the console:
Z5G03I SCHEDULE LOAD COMPLETE
184
Caution! Do not execute multiple SCHEDULE TODAY ACTIVATE functions

simultaneously in the same batch job, or while any system is in WARM
mode (ZKILL WARM). Unpredictable results could occur during a
schedule load in these cases.
Note:
In a Zekeplex (where multiple systems share a database), each Zeke system runs its
schedule table load simultaneously with the schedule creation process by the
SCHEDULE function. Each Zeke systems schedule is updated (through
communication records) as the SQRs are updated in the Zeke database.
After the SCHEDULE function is complete, one Zeke system satisfies weak, EOG,
extended, and variable WHEN conditions, and then the schedule load becomes
complete on all systems. Zeke does not perform a separate schedule load process
(and data space creation) for each system that shares the database.
Simultaneous schedule loador Simuloadoccurs 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).
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.
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.
Optional. You can specify the use of a data space by the SCHEDULE function when
processing SQRs. If you use the DATASPACE option, a temporary data space is
created when the SCHEDULE function starts, and again before any schedule reports
are generated.
Note:
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information.
185
Creating the Schedule Automatically

ASG recommends that you set Zeke up to create the schedule automatically.
Note:
When necessary, you can use the SCHEDULE function to create the schedule manually
(see Creating the Schedule Manually on page 184).
To set up a job that creates the schedule automatically

1
Define a job event as described in Defining a Job Event on page 69.

On the EMR, specify the start time plus 24 hours. For example, if you want the
schedule to be created every day at 8:00 A.M., enter a start time of 32:00.
Specify the appropriate JCL source to include the JCL, as described in Creating the
Schedule Manually on page 184.
Add the OCCURS clause DAILY, so that the job that creates the schedule will run
each day. See Defining an OCCURS Clause on page 121.
This step only has to be performed the first time. Use the ZADD operator command
to add the job event with yesterdays Julian date. For example, if the event number
is 100 and todays date is December 30, 2012, issue this command:
ZADD EV 100 DATE 2012363 RDATE 2012363
The schedule job is placed in the queue with yesterdays date specified as the
schedule date and run date. When the start time is reached, the schedule load runs,
and then loads itself into the queue for the next day.
Downloading the Schedule to Zeke Agent

When it creates the schedule, Zeke checks whether any events in the schedule are
specified to be downloaded to a remote Zeke Agent. Zeke checks the Netregid in the SQR
(which indicates the events target) to determine whether to download the event.
Zeke first sends a message to the specified Zeke Agent to determine whether to download
the set of events that have been identified for downloading. Zeke generates and uses a
unique schedule number to track and synchronize each schedule downloaded to Zeke
Agent. If a newly generated schedule number differs from the number of the schedule
that currently is downloaded and processing on Zeke Agent, then Zeke downloads the
new schedule to Zeke Agent. If the new schedule number matches the number of the
current Zeke Agent schedule, then Zeke does not download the schedule.
186
While the SQRs are being downloaded, each events download status is reported back to
Zeke.
If Zeke is unable to download an SQR to its Zeke Agent target, the event is tracked and
updated like any other event until it is ready to dispatch. Then, instead of dispatching the
event, Zeke places the event on download hold. Later, when Zeke resumes
communication with Zeke Agent, Zeke downloads the event and releases it from hold.
See "Downloading a Job Event to Zeke Agent" on page 83 and Defining Schedule
Download Agents on page 327 for more information on how events are downloaded
from Zeke to Zeke Agent.
Forecasting and Simulating the Schedule

Zeke provides several ways to predict how the schedule will flow without having to
actually run the schedule or dispatch events. You can find missing prerequisite
conditions, set up a logical schedule flow, and even plan for unusual system downtime or
hardware maintenance. Zeke provides these methods for planning or forecasting your
schedule (depending on your specific needs):
Method
Description
OCCURS hit resolution Enables you to display a calendar showing the days the event will be
scheduled. See Defining an OCCURS Clause on page 121 for more
information.
Schedule forecast
Creates a schedule for a future date, which enables you to forecast the
schedule and make any necessary changes.
Schedule simulation
Enables you to specify the date, time, system, and resources for an
event in the simulation JCL, and then run a schedule simulation.
Forecasting the Schedule

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

1
Run a job using the SCHEDULE control statement of the ZEKE utility program:
Include the DATE parameter followed by the future date (in MM/DD/YYYY
format) that you want to forecast.
Do not include the ACTIVATE parameter.

187
For example:
//ZEKESCHD JOB
//SCHED EXEC ZEKEUTL,PARM=SUBSYS=ZDEV
//SYSIN DD*
SCHEDULE DATE 08/23/2012 DATASPACE
/*
Submit the JCL.
For more information on using the ZEKE utility program to forecast the schedule, see the
ASG-Zeke Scheduling for z/OS Reference Guide.
Simulating the Schedule

You can perform a simulation creating and running a simulation job (separately from the
Zeke program) that specifies the date, time, system, and resources for an event. The Zeke
database is copied to another dataset, and then the job flow is simulated against that
dataset. (The simulation database must be contiguous.)
Caution! Do not run a simulation against your production database; this will destroy the
database. Run a simulation only against a database that has been copied for that
purpose. Also, ensure that no other Zeke system is running against the same
database as a simulation.
You can generate these types of simulation reports (depending on which keyword you
specify):
188
Keyword
Description
Console
Generate a report of the messages produced during simulation.
Exception
Generate a report of the exceptions that occurred during simulation.
Schedule
Generate the schedule reports (if a schedule run was requested).
Jobflow
Generate a chart of initiator usage.
To run a schedule simulation

1
Execute the SSS4001 program using the SIMULATE control statement (of the
ZEKE batch utility program) in the SYSIN.
Note:
To simulate schedules accurately, Zeke uses the same programs that process actual
schedules. The program used to invoke simulation, SSS4001, also is used to start
Zeke. When requesting a simulation, you must specify the SIM option in the ZEKE
parameter that specifies the ZEKExx PARMLIB options member; otherwise, Zeke
attempts to process an actual schedule.
2
Specify the date, time, and conditions for the simulated schedule using the
appropriate parameters.
Note:
The attributes STARTDATE, STOPDATE, STARTTIME, and STOPTIME are

specified according to a 24-hour clock; however, Zeke dispatches events scheduled
on a 48-hour clock at the correct time.
3
Ensure that a ZKSMLOG DD statement with the DCB parameters (i.e.,

LRECL=256, BLKSIZE=5124, and RECFM=VB) is included in the JCL. This is
the simulation log that Zeke uses to generate the reports after completing the
simulation. To simulate your current schedule, set the SCHEDRUN and
SCHEDCLR parameters to OFF; otherwise, Zeke builds a new schedule, by default.
Execute the SIMULATE COPY function to copy the Zeke database before starting
the simulation. For example:
COPY
SIMULATE
FROMDD=INCAT TODD=OUTCAT
STARTDATE 01/01/2012 STARTTIME 23:00
STOPDATE 01/02/2012 STOPTIME 22:59
DATABASEDD OUTCAT
SATISFY ALL
INITIATORS 10
TAPEDRIVES 5
SYSTEM MVSSPA
REPORT ALL
189
If you want to run the simulation in a data space, use DATASPACE as the value for
both the TODD and DATABASEDD parameters. For example:
COPY
SIMULATE
FROMDD=INCAT TODD=DATASPACE
STARTDATE 01/01/2012 STARTTIME 23:00
STOPDATE 01/02/2012 STOPTIME 22:59
DATABASEDD DATASPACE
SATISFY ALL
INITIATORS 10
TAPEDRIVES 5
SYSTEM MVSSPA
REPORT ALL
See the ASG-Zeke Scheduling for z/OS Reference Guide for information about
running a simulation in a data space.
5
Optional. You can use the REPORT parameter with subparameters to run specific
simulation reports.
To print simulation reports from a previous run without re-running the simulation,
ensure that you save the ZKSMLOG dataset from the previous run. Specify only
REPORT parameters in the SYSIN control statements, and point the ZKSMLOG
DD to the saved log.
Submit the JCL.
For more information on using the ZEKE batch utility to simulate the schedule (including
a complete list of simulation parameters), see the ASG-Zeke Scheduling for z/OS
Reference Guide.
190
Creating and Adding an Event to the Schedule

You also can use the ZEKE batch utility to define a new event, and add it to the schedule
at the same time.
To add a new event to the schedule

1
Define the event using the EVENT function of the ZEKE batch utility. See the
ASG-Zeke Scheduling for z/OS Reference Guide for more information (including
valid parameters).
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
$$
Submit the JCL.
Using Schedule View

Schedule View displays all scheduled events (SQRs) in the current schedule. From
Schedule View, you can monitor, and temporarily update, the events in the schedule
using simple line commands. You also can issue Zeke operator commands from the
Command line in Schedule View (just like a primary command).
Note:
Any changes that you make to an SQR are temporary and only are effective for the
current schedule run of the event; no changes are made to the EMR.
Schedule View Commands

This section describes the Schedule View commands.
191
Primary Commands
You can issued these primary commands from the Command line in Schedule View:
Command
Action
ADD
Add events to the schedule through the Add wizard. See Using the ADD
Function on page 249 for more information.
AUTO
Enable or disable the automatic monitoring function. These are the valid
parameters:
ON
Default. Monitor the current schedule and automatically refresh the

screen with any schedule changes according to a specified time
interval.
OFF
Disable the automatic monitoring function. (You also can press any
key to disable this function.)
Note:
The AUTO command cannot function properly if you are operating in
split-screen mode.
BROWSE
View the events in the current schedule. See Displaying Scheduled Events on
page 200 for more information.
DOC
Display the Documentation Segments screen.
EDIT
Update an existing event in the current schedule. See Updating a Scheduled

Event on page 203 for more information.
INT
Display the two values that control automatic monitoring mode, where the first
value, rate, is the number of seconds between automatic refreshes, and the
second value, wait. indicates how often Zeke checks for a request to exit
AUTO mode.
To change the timing of screen refreshes, you can enter this command:
INT rate wait
where rate is a range from the wait value to 3660 seconds, and wait is a
value ranging from 1 through 255. The default values of both optional
parameters is 5. Also, the rate value must be a multiple of the wait value;
however, Zeke calculates and adjusts this automatically.
For example, to refresh the screen every 10 seconds, and check for an exit
AUTO mode request every 5 seconds, enter this command:
INT 10 5
EMR
192
Display the Event Master Selection Criteria screen.
Command
Action
SELECT
Refresh the screen with any schedule changes. When you include an event
number, then only the specified event is refreshed.
Note:
When the schedule is refreshed, the cursor remains on the same line number;
however, this might not be the same SQR (if the schedule changed during the
refresh).
See Refreshing the Screen on page 218 for more information.
SORT
Rearrange the sequence of the fields on the screen based on the SORT
parameters. This action is effective only for the current session.
Note:
Enter SORT HELP on the command line to display a complete list of SORT
parameters and their abbreviations.
For more information and to change the display order permanently, see Sorting
Schedule View Information on page 219.
WORK
Display the Work Center Selection Criteria screen.
These ISPF primary commands are valid on the Command line in Schedule View:
Command
Action
X ALL
Exclude all displayed lines.
F STRING NEXT
Find the next occurrence of a specified string of text.
F STRING FIRST
Find the first occurrence of a specified string of text.
F STRING LAST
Find the last occurrence of a specified string of text.
F STRING ALL
Find all occurrences of a specified string of text.

Note:
The FIND ALL command does not display the total number of
strings found.
RESET
Re-display a group of lines that were previously suppressed using the

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

You can enter any valid line command for an event, and then enter the equal sign
(=) to flag multiple additional events. Each time you press PF3/END, the same
line command is issued for the next flagged event.
ADDOK
Add a NEED OPEROK requirement to the selected events 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 events WHEN conditions from being
satisfied.
DSN
Valid for job events only. Display the Step/DD Level Information screen for the
selected event.
Note:
This function requires Zebb to be active on this Zeke system.
Press F3 or Enter to return to Schedule View.
194
Command
Action
EMR
Display the EMR for the selected event. From this display, you also can make
changes to its EMR.
You can use the REB line command to see the changes to the EMR reflected in
Schedule View.
EN
Enable the selected disabled event, and re-add the event to the schedule.
FDEL
Release the resources for the selected event, and then delete the SQR.
FDONE
Force the status of the selected event to DONE (regardless of the status of the
resources).
FFAIL
Force the status of the selected event to Failed.
FREB
Release the selected events resources, and then re-add the event to the schedule.
FREF
Release the selected events resources, refresh the SQR, and then re-add the
event to the schedule.
FSUCC
Force the status of the selected event to Success.
Hold
Place an operator hold on the selected event.

You can use the REL line command to release the hold.
JCLR
Valid for job events only. Retrieve the actual JCL (from the JCL source) for the
selected event, so that you can view or update it. The JCL must reside on the
same system where you issue the command.
You can issue the ZOOM line command for the same event to display the
Schedule View Record Expand Function screen where you can view, update, or
delete the JCL. See Accessing an Expanded SQR (Using ZOOM) on page 216
for more information.
Note:
This command is not supported for SQRs that have JESQ as the JCL source.
JPREP
Valid for job events only. Invoke JCLPREP for JCL scanning.
See Invoking ASG-JCLPREP on page 231 for more information.
Note:
195
Command
Action
LDSN
Valid for job events only. Display the List DSN Detail Information screen.
Note:
NOTE
Display any available note text for the selected event.
OK
Enable Zeke to dispatch the selected event.

If the OperOk generation option is set to Y, then Zeke requires an operator to
issue this command to approve event dispatching.
PATH
Display the Pathfinder screen for the selected events 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

PRED
Display the Pathfinder screen to display the events on which the selected event
or job is dependent.
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 events resources, update resource detail, or release a

resource from control by an event or system.
See Managing Event Resources on page 215 for more information.
196
Command
Action
RSTRT
Valid for job events only. Display the Job Restart Management screen for the
selected event.
Note:
RUN
Satisfy all conditions for the selected event, and dispatch the event.
Note:
Zeke ignores any NOTDURING WHEN conditions for the event (until you
rebuild the SQR from the EMR).
SCAN
Valid for job events only. Scan and validate the selected events JCL that is to
be submitted by Zeke.
See Validating JCL on page 231 for more information.
Note:
SUCC
Display the Pathfinder screen for events that are dependent on the selected event
or job.
SYSx
View the JES2 job output information for the selected event, where x is one
of these codes:
L
Display all job log information.
Display any generated messages.
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 IBMs spool browse facility.
You are running JES release 4.x or later.
The job is in the JES spool.
TOK
Satisfy the time requirements for the selected event.
197
Command
Action
WHEN
Display and update the WHEN conditions for the selected event during this
schedule run.
See Managing WHEN Conditions on page 213 for more information.
WHY
Display the reasons why the selected event is awaiting execution, and update the
WHEN conditions to change the status, if necessary.
See Displaying or Updating an Event Status on page 206 for more
information.
WOK
Satisfy all WHEN conditions for the selected event.

See Managing WHEN Conditions on page 213 for more information.
WORK
Valid for work center events only. Display the Work Center Selection Criteria
menu.
ZEBB
Valid for job events only. Display the Job Functions Menu.
Note:
ZOom
Display the Schedule View Record Expand Function screen for the selected
event.
This ZOOM screen is similar to the EMR screen, except that changes on the
Schedule View Record Expand Function screen are temporary (i.e., only for the
current schedule run).
See Accessing an Expanded SQR (Using ZOOM) on page 216 for more
information.
. . . .
Create your own CLIST or REXX command that can be executed from
Schedule View.
See Custom Line Commands on page 199 for more information.
198
Custom Line Commands

You can create custom CLIST and REXX commands and execute them from Schedule
View). Schedule View line commands can be from 3 to 5 characters long.
To execute a line command

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

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

1
From the Zeke Primary Menu, enter option 2. The Schedule Information Selection
ASG-Zeke
Command ===> 1
1
2
3
4
Schedule Information Selection Criteria
Schedule View
ZCOM
ADD Function
ADD by path
Event ===>
Schedule Display and Modification Facility

List Scheduling System Commands
Select Event Records "TO ADD" to Schedule
Select Event Records by path
Permanently save criteria ===> N
Event Types
Job:
Job Name:
Msg:
Event Name:
Pcom:
Application:
Work:
Group ID:
Vcom:
User ID:
Zcom:
System:
Scom:
Disp Class:
REXX:
Sched Date:
Run Date:
Target:
Permanent:
Milestone:
---- Event Status ---Actv:

Y
Done: Y
Pend:
Y
ABOK: Y
Sched:
Y
Fail: Y
Hold: Y
FBOK: Y
Late: Y
FSucc: Y
/ OperOk: N
Needs - TimeOk: N
%Actv:
\ WhenOk: N
To display all events in the current schedule, enter 1 on the Command line, and
press Enter. Schedule View displays all SQRs in the current schedule.
Or
To display a selection of events, enter selection criteria in any of these fields, and
press Enter:
200
Field
Description
Event Types
Enter any character next to the event types that you want to display.
Field
Description
Selection Field
Masks
Enter any information you know about the events that you want to select
(e.g., jobname, user ID, run date, etc.).
You can use wildcard characters in your selection criteria. You can use
an asterisk (*) to represent multiple characters, and/or a question mark
(?) to represent a single character.
For example:
This entry in the Job Name field selects all events with a jobname that
begins with ABC:
ABC*
This entry in the Job Name field selects all events that begin with A, and
end with C, with any character in the second position.
A?C
Event Status
For each status, indicate whether that you want to display events with this
status. These are the valid values:
N
Do not select events with this status for display.
Select events with this status for display.
These are the valid event status codes:

Actv
Active events.
Pend
Pending events.
Sched
All scheduled events. To narrow down the selection, you can

specify N, and then specify any of these secondary statuses:
Done
Hold
All events on hold.
Late
All events that are late.
Needs OperOK
All events waiting for an operator OK.
Needs TimeOK
All events waiting for a certain time.
Needs WhenOK
All events waiting for particular WHEN

conditions to be satisfied.
Events with a status of EOJ or AEOJ. To narrow down the

selection, you can specify N, and then specify any of these
secondary statuses:
201
Field
Description
ABOK
All successful events that failed once. This

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

displayed in Schedule View like this:
Forced
FBOK
All events that failed once, and then were

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

displayed in Schedule View like this:
Success Forced
Schedule View displays only the SQRs that match the selection criteria:
ASG-Zeke
Command ===>
Event ===>
Schedule View
System=SYSD
BROWSE
Scroll ===> PAGE
Selected=0000004
2012.022
15:45
Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ?
Line Commands: Del Delete Wh When
? to list other Line Commands
Line Event Sched
Job
Evnt Event
Event Status
Cmd
No.
Date
Name
Type Name
Reason Code
==========================================================================
000001 2012053
MSG ZEKEEVTST1
Queued Need Oper OK
000002 2012053
MSG ZEKEEVTST2
Scheduled Time OK
000003 2012053
MSG ZEKEEVTST3
Scheduled Time OK
000004 2012053
MSG ZEKEEVTST4
Scheduled Time OK
000005 2012053
MSG ZEKEEVTST5
Scheduled Time OK
000006 2012053 TSKKGUT1 JOB KTEST1
Scheduled Time OK
Success
Active
90%
Success
Success
000011 2012053 SPTEXD11 JOB ZEKEEVCC
Scheduled Time OK
000012 2012053 SPTEXD12 JOB ZEKEEVCC
Scheduled Time OK
000013 2012053
WORK
Scheduled Time OK
From the main Schedule View screen, you can scroll left and right, and up and
down, to display all of the SQR fields (depending on how you set your display
characteristics). Use the normal ISPF scroll commands LEFT and RIGHT to view
additional fields.
202
Schedule View displays a variety of information about each scheduled event

(including the events 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 events scheduling and dispatching requirements
from the main Schedule View screen.
If you need to review an entire SQR, and make necessary changes, see Accessing an
Expanded SQR (Using ZOOM) on page 216.
To update a scheduled event through Schedule View

1
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.
Desired Result
Action
Display a list of all valid line

commands
Enter ? in any Line Cmd field, and press Enter.
Change the events dispatch

priority
Type over the value in the Dp field, and press Enter.
Change the time the event is

scheduled to run
Type over the value in the Start Time field, and press Enter.
A value of 00:00 indicates that Zeke dispatches the event
according to the WHEN conditions.
203
Desired Result
Action
You can update any of these fields to alter other schedule
time information:
Late start
Early time
Must time
After time (Notafter)
Average duration
Late end
Change the Zeke system or

pool where the job can run
Type over the value in the System field, and press Enter.
Change the number of times

Zeke dispatches an event
1 Type over the value in the Cnt field to indicate the

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

for the job
Specify the name of the class in the Dsptch Class field, and
press Enter.
Change the number of

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

Specify the amount of storage in the Virt Mem field, and
storage required by the event press Enter.
204
Desired Result
Action
Change the way Zeke

submits and executes JCL
Specify the code indicating the type of job processing to use

in the Target field, and press Enter. These are the valid
values:
*LOCAL Execute the JCL for the job on the dispatching
system.
*RL
(Remote Limited processing) Dispatch and

submit the JCL on one system, and execute the
JCL on another system.
This option does not support condition code
processing.
Change the required

scheduling environment
*RF
(Remote Full processing) Dispatch and submit

the JCL on one system, and execute the JCL on
another system.
*R
(Remote processing) Zeke determines whether

to use RL or RF processing based on the jobs
minimum required support.
other
OASIS/DMS Netregid of another Zeke system

or Zeke Agent where Zeke will dispatch or
download the SQR.
Type over the environment name in the Scheduling

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

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

entered
1 Enter any valid line command that already has been

executed for an event, followed by =, in the Line Cmd
Field to flag any additional events for the same action.
2 Press Enter.
3 Continue to press Enter to issue the command for each
subsequent, flagged event.
Repeat the last change for

subsequent lines
1 Enter ALT in the Line Cmd field for the event that you
want to update.
2 Enter = in the Line Cmd field to flag any subsequent
lines where that you want to apply the same changes.
3 Press Enter.
4 Continue to press Enter to apply the change to each
subsequent, flagged event (until you execute a different
line command).
Note:
If you want Zeke to download an event that has been updated to Zeke Agent, then
you must rebuild the SQR first.
Displaying or Updating an Event Status

Schedule View displays the status of each event in the schedule, the reason an event is
awaiting execution, and any WHEN conditions that have not been satisfied for an event
version.
If necessary, you can display more detailed event status information, and update an event
status by satisfying its dispatching requirements and dependencies manually.
206
Event Statuses
This table describes the event status codes that Zeke displays in Schedule View:
Event Status Code
Description
Active
The event is currently running. The percentage of the events

average duration is displayed to the right of the status.
Zeke highlights the Active status if the event has run beyond its
average duration, as displayed on the Event Master Record
Accounting screen (see Viewing Event Accounting Information
on page 172).
Dispatching
Zeke currently is submitting the job event to JES.
Fail
The event ended abnormally.
Fail Forced
The event was forced to an abnormal completion.
Fail Job Ran Long
The event completed, but was marked as failed because it ran

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

shorter than its acceptable range of duration times (i.e., its Normal
Range).
Queued
The event is in the dispatch queue, but is not yet running.
Scheduled
The event is scheduled, but has not been dispatched yet.
Success
The event has completed successfully.
Success Failed Once
The event ended abnormally, was refreshed, and then finished

successfully.
Success Forced
The event was forced to a successful completion.
Success Forced Failed Once
The event was forced to a successful completion after failing once.
207
Event Reason Codes

This table describes the codes that Zeke displays in Schedule View to indicate the reason
that an event is waiting to be dispatched:
Reason Code
Description
Awaiting Retry
Zeke attempted to dispatch the event, but the event failed with a
recoverable error. Zeke will attempt to dispatch the event again.
Class Cap
The job event is on hold because the job class maximum capacity
has been reached. Zeke will submit the job event to JES when the
number of jobs of that class falls below the limit.
Comm Record Wait
The event currently is under multisystem processing. The event is

available for dispatching after the associated communication record
is processed.
Delayed Dispatch Wait
Zeke has delayed event dispatching due to multisystem processing

requirements.
Disabled
The event is disabled, and cannot be dispatched.

Note:
An active event that has been disabled using the ZDISABLE
operator command continues to run to completion, but Zeke
ignores it for the purposes of triggering (and no longer tracks it). In
this case, the event appears in Schedule View with this status (even
after it is completed):
ACTIVE DISABLED
208
Download Hold
The event is being downloaded to a Zeke Agent.
DSN Hold
There are multiple SQRs in the schedule with the same event
number and the same DSN trigger specified. Because the DsnTrig
generation option is set to NT, Zeke did not trigger any of the events,
and the events are on hold.
Event ran long/short
The event completed, but its duration was longer than or shorter than
its acceptable range of duration times (i.e., its Normal Range).
Event is running long
The event is active, and is running longer than its acceptable range
of duration times (i.e., its Normal Range).
Failed Once
The event failed, was refreshed, was rerun, and finished

successfully.
Reason Code
Description
Forced
The event was forced to completion without actually being

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

error.
JESQ Held Job Wait
The event is on hold in the dispatch queue until a job is found in the
JES queue with a matching jobname.
Late
For an event that has not dispatched, either its Late Start time has
passed, or based on its average duration, the event is projected to run
past its Late End time. For a dispatched event, the event did not
complete by its Late End time.
Manual Schedule Wait
The event is one of a group of events that were manually scheduled

by a single ZADD command. The event is waiting for the other
events in the group to be added, and for any weak and variable
conditions to be checked.
Multiple Systems
This status occurs only in a Zekeplex (where the XCFONLY=YES

start-up option is specified in the ZEKExx PARMLIB options
member). Because events specified system ID is a pool, the event
can be in multiple dispatch queues.
You can issue the WHY command to view the wait statuses across
all systems.
Need Initiator
The event is waiting for an available initiator.
Need Logical Resources
The event is waiting for resources.

You can issue the ZRESOURCE operator command to display the
resources.
Need Oper Ok
The event requires an operator OK before it can be dispatched.

You can issue the ZOK operator command to approve dispatching.
209
Reason Code
Description
Need Tape Drives
The required number of tape drives are not available.
Network Hold
The event is on hold due to a networking error.

Zeke releases a network hold when the remote scheduler or agent
re-registers with Zeke.
Network Time Out
OASIS/DMS timed out while waiting for a response.
New DQT Entry
The event has been newly added to the dispatch queue.
Not After/Must End
The Not After time or the Must End time has been reached.
Notduring Wait
The event is waiting for the completion of a program or job that is

specified in the events WHEN condition.
OASIS REXX Hold
The REXX event (submitted through OASIS/ECF) abended, and the

event is on hold.
Operator Hold
The event is on operator hold because a ZHOLD operator command

was issued.
Pending
The event has been dispatched, and is ready to execute.
Posid=No/Rem Hold
The Posid generation option is set to N, and the Control field on the
EMR is set to Y. Because these settings prevent Zeke from tracking
a remote job event, the event was placed on hold. For Zeke to track
a remote job event, Posid must be set to Y; otherwise, Control must
be set to N, so that Zeke does not attempt to track the remote job
event.
Ready
The event is ready to be dispatched.
Refresh Hold
A ZREFRESH operator command was issued for this event. This

event is refreshed, and is on operator hold.
Security Hold
The job is not authorized to run on the platform where it was

submitted. The event is on hold.
SCHENV Wait
The job is waiting on the required scheduling environment to

become active.
SJCL Hold
Zeke encountered an error reading the JCL while attempting to

dispatch the event. The event is on hold.
System Hold
The Zeke dispatching system is on hold.

You can issue the ZRELEASE operator command (with the
SYSTEM parameter) to release the hold.
210
Reason Code
Description
Time OK
The event has met the schedule time requirements.
VSE Pool Hold
Zeke has attempted to dispatch a pool event on a VSE system when

the DispSel generation option is set to N. The event is on hold.
Wait Sched Load
There is a new SQR entry being added to the schedule by the current
schedule load. The SQR is available for dispatching when the
schedule load is complete.
Weak Resolution Wait
The event has been updated by a communications record, but its

weak and variable conditions have not been checked yet.
When OK
All prerequisites have been satisfied.
To display or update event status information

1
Access Schedule View, and locate the desired event (as described in Displaying
Scheduled Events on page 200).
Enter WHY in the Line Cmd field to the left of the selected event version, and press
Enter. The Schedule ViewWHY screen is displayed:
ASG-Zeke
Option ===>
Schedule View
Event = 000116
Event Name = MYBR14
Jobname = ZEKBR14
When Vr = 00000
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Event Status <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
Needs Time OK
Event is LATE
****** ************************** BOTTOM OF DATA ***************************
For example, for an event with the status Queued, and the reason code Multiple
Systems, issuing the WHY command displays the wait reasons for all systems:
ASG-Zeke
Option ===>
Schedule View
Event = 000005
Event Name = EVENT5
Jobname = ZEKWTOR5
When Vr = N/A
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Event Status <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
ASGSYSD
Need Oper OK
ASGSYSB
System Hold
Event was scheduled for system POOLBD or pool POOLBD
Needs Operator OK
Needs Resource(s)
****** ************************** BOTTOM OF DATA ***************************
211
If the information in the Event Status section includes a system name (e.g.,
ASGSYSD), this indicates that the SQR is waiting in the dispatch queue on that
system. If the status information is not preceded by a system name, this indicates
the base SQR on any system.
Note:
Zeke uses this screen format only for pooled SQRs in a Zekeplex (where the
start-up option PLEXCOMM=XCFONLY has been specified in the ZEKExx options
member for all Zekes). In this case, Zeke always displays the system name (even for
nonpooled events).
3
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
individual WHEN condition
In the Tabular When Conditions section, enter any

character to the left of the condition that you want to
satisfy or complete, and press Enter.
These symbols are displayed to describe the status of the
condition:
Satisfy or complete all WHEN

conditions
Zeke satisfied the condition.
An operator command was used to manually

satisfy the condition.
The condition is satisfied because the event is not

in the schedule.
In the Event Status section, enter any character to the left

of the statement Needs WHEN OK, and press Enter.
If the job is waiting for resources, the Schedule View
Resource screen is displayed. See Managing Event
Resources on page 215.
212
Press F3 to return to the main Schedule View screen.
Managing WHEN Conditions

You can satisfy WHEN conditions manually, or update them, through Schedule View.
The changes you make are effective only for the current schedule run.
Note:
To change a WHEN condition permanently, you must update the condition in the EMR.
See WHEN Condition Keywords on page 133 for the valid keywords.
To manage WHEN conditions through Schedule View

1
Enter WH in the Line Cmd field to the left of the selected event version, and press
Enter. The Schedule ViewWhen Conditions screen is displayed:
ASG-Zeke
Option ===>
Schedule View
Event = 000116
Event Name = MYBR14
Jobname = ZEKBR14
When Vr = 00000
CAPS: ON
>>>>>>>>>>>>>>>>>>>>>>>>>>
When Conditions
<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>> English When Conditions <<<<<<<<<<<<<<<<<<<<<<<<<
(EOE EVEX VER 2 OR EOJ JOBEO VER 3 OR EOE EVFF VER 2)
>>>>>>>>>>>>>>>>>>>>>>>>> Tabular When Conditions <<<<<<<<<<<<<<<<<<<<<<<<<
EOE 'EVEX' VER 2
EOJ 'JOBEO' VER 3
EOE 'EVFF' VER 2
******************************* BOTTOM OF DATA ****************************
Desired Result
Action
Update existing WHEN

conditions
1 In the English When Conditions section, tab to the

blank field after the existing statement.
2 Enter AND or OR, and the specify another WHEN
condition (which is appended to the existing
statement). Do not add a closing parenthesis to the
existing statement.
213
Desired Result
Action
The maximum length of a WHEN conditions is 17 lines,
or approximately 1360 characters, in total. Zeke removes
the blank update field from this section when the
maximum is reached.
Note:
When updating an existing condition in Schedule View,
you can add only approximately 120 characters (because
of buffer requirements). If you need to specify a dataset
dependency that uses a dataset name longer than 120
characters, you must use a Zeke operator command to
update the WHEN condition.
Satisfy an individual WHEN

condition
Tab to the blank space in front of the condition in the

Tabular When Conditions section, and enter any
character.
These symbols indicate describe the status of the
prerequisite:
Satisfy all WHEN conditions
214
Press Enter.
Zeke satisfied the condition.
An operator command was used to manually

satisfy the condition.
The condition is satisfied because the event is not

in the schedule.
Enter WOK in the Line Cmd field for the selected event
on the Schedule View screen.
Note:
If you enter WH for a selected work center event, this screen is displayed:
ASG-Zeke
Option ===>
Schedule View
Event = 000117
Event Name = CLEANERS
Jobname =
When Vr = 00000
CAPS: ON
>>>>>>>>>>>>>>>>>>>>>>>>>
When Conditions
<<<<<<<<<<<<<<<<<<<<<<<<<<
>>>>>>>>>>>>>>>>>>>>>>>>> English Set Conditions <<<<<<<<<<<<<<<<<<<<<<<<<
(?XVAR TEST1 EQ 'THIS IS A TEST')
>>>>>>>>>>>>>>>>>>>>>>>>> Tabular Set Conditions <<<<<<<<<<<<<<<<<<<<<<<<<
?VAR TEST1 EQ 'THIS IS A TEST'
******************************** BOTTOM OF DATA ***************************
You can follow the same procedures for updating and satisfying WHEN conditions
when that you want to update or satisfy SET statements.
Managing Event Resources

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

1
Enter RESO in the Line Cmd field to the left of the selected event, and press Enter.
The Schedule ViewResource screen is displayed:
ASG-Zeke
OPTION ===>
Event = 000028
Schedule View
Event Name = ZEKEEVTST6
Line Commands: Who - Show holder(s)
Jobname = TSKKGUT1
Rel - Release the resource
Count Mode Sta Event Ver

Date
Scp Resource Name
============<============================================================>
1 SHR
000028 00000 2012053 GBL INIT1
******************************** BOTTOM OF DATA ***************************
215
Note:
If there are no resources defined for the event, this message is displayed:
**** NO RESOURCE DEFINED ****
3
Desired Result
Action
Release the resource
To the left of the resource, enter REL, and press Enter.
Display the event currently using

the resource
To the left of the resource, enter WHO, and press Enter.
Note:
If there are no resources currently being held for the event, this message is
displayed:
**** RESOURCE NOT HELD ****
4
Accessing an Expanded SQR (Using ZOOM)

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

1
Access Schedule View, and locate the event that you want to display (as described
in Displaying Scheduled Events on page 200).
Enter ZOOM in the Line Cmd field to the left of the selected event, and press Enter.
The Schedule View Record Expand Function screen is displayed:
ASG-Zeke
Command ===>
Evt: 000028
Schedule View Record Expand Function
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
Sched date: 2012053

Run date: 2012053
Version: 00000
STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK
Type: JOB
EventName: ZEKEEVTST6
App:
System: ZEQA
Class:
Target: *LOCAL
Early:
Sched: 00:00
Dprty: 50
Cntrl: Y
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
JCL Line Commands: B - Browse
D - Delete
Grp:
Mustend:
Notafter:
Freqcalc: S
Virt Mem:
E - Edit
Usrid:
Trig: A
R - Retrieve
JCL--> Zeke JCL
Note:
If JCL exists for an event, you can browse, delete, edit, or retrieve it from this
screen. The screen provides line commands, and indicates the JCL source.
3
To update a scheduled event

1
Enter EDIT on the Command line, and press Enter to enable Edit mode.
In Edit mode, you can edit any of the highlighted fields. You can scroll left or right
to access additional fields.
Or
From the Schedule View screen, enter ZOOM in the Line Cmd field beside the
desired event and press Enter.
217

ASG-Zeke
Command ===>
Evt: 000028
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
Sched date: 2012053

Run date: 2012053
Version: 00000
Type: JOB
App:
System: ZEQA
Class:
Target: *LOCAL
Early:
Dprty: 50
Cntrl: Y
Sched: 00:00
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
D - Delete
Grp:
Usrid:
Mustend:
Freqcalc: S
Virt Mem:
E - Edit
Notafter:
Trig: A
R - Retrieve
JCL--> Zeke JCL
Note:
See Accessing an Expanded SQR (Using ZOOM) on page 216 for more
information on updating an SQR in ZOOM mode.
3
Update the fields, as necessary, and press Enter.
To display or update the events JCL, in the blank field to the left of the JCL>
field, enter one of the available JCL line commands. Press Enter.
Caution! Changes made to JCL using this method are applied to the EMR. For
one-time JCL overrides, see Overriding JCL on page 226.
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 users ISPF profile. Each user can set up Schedule View according to
their preferences.
Refreshing the Screen

Schedule View monitors the current schedule and automatically refreshes the screen (at
specified intervals) with any schedule changes.
218
You can enable or disable the automatic monitoring function, and change the screen
refresh rate (when this feature is enabled).
To change the automatic refresh options

1
Access Schedule View (as described in Displaying Scheduled Events on

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

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

1
From the Zeke Primary Menu, enter option C.3. The Schedule View Sort Setup
ASG-Zeke
Command ===>
Schedule View Sort Setup
Row 1 to 16 of 33
Scroll ===> PAGE
Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET

Line Commands: nnn - Move to/after nnn; 0 - Don't use; A/D - direction
nnn
---
Order A/D
--------10
A
20
D
30
A
40
Field Description
-------------------------------------------------------------Status/Reason Code
Schedule Date
Event Number
----- Sort uses fields above; fields below are not used ----Application Identification
Average Duration
CNT (number of times)
Dispatching Classes
Download Status
DP (Dispatch Priority)
Early Dispatch Time
Event Name
Event Type
Freq (dispatch interval)
Frequency Calc
Group Identification
This line serves as a separator on this screen:

----- Sort uses fields above; fields below are not used -----
The fields listed above the line are used for sorting in the user-specified sort order.
Unused fields (below the line) are listed alphabetically, for convenience.
2
In the nnn field, perform these steps:

a
To remove a field as a sort field, specify the line command 0 next to the field,
and press Enter. This moves the field down to the not used section of the table.
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 fields placement in the sort order.
Order values begin at 10, and increment by 10. This enables you to position
multiple fields in between existing fields, if necessary.
Each time a field is included in or removed from the sort sequence, or fields are
reordered, the Order values are recalculated for the entire list.
220
In the previous example, the scheduled events are designated to be sorted first by
Status/Reason Code, then by Schedule Date, and then by Event Number. The user
has specified to use Cnt as the last sort option.
3
Enter A or D in the A/D field to specify an ascending or descending order for the
sort, and press Enter. Ascending numerical and alphabetical order is the default
sequence.
In the example, Status/Reason Code, Event Number, and Cnt will sort in ascending
order, and Schedule Date will sort in descending order.
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.
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.
Optional. Enter SORT HELP on the Command line, and press Enter to display a
list of SORT parameters and their correct syntax.
Enter END on the Command line to save the changes and return to the previous
screen.
221
Selecting Fields to Display

You can select the fields that you want to display in Schedule View, and reorder the
placement of those fields.
To format the Schedule View screen layout

1
From the Zeke Primary Menu, enter option C.2. The Schedule View Display Setup
ASG-Zeke
Command ===>
Schedule View Display Setup
Row 17 of 33
Scroll ===> PAGE

Line Commands: nnn - Move to/after nnn; 0 - Don't show
nnn
---
Order
----170
180
190
200
210
Field Description
*Date Format: YYYYDDD
-----------------------------------------------------------------Version Number
Frequency Calc
Trigger Type
Long Job Name
Download Status
----- Fields above are displayed; fields below are not ----CNT (number of times)
Early Dispatch Time
Event Name
Event Type
Late Dispatch Time
Must End Time
Run Date *
Status Time
This line serves as a separator on this screen:

----- Fields above are displayed; fields below are not -----
Fields listed above the line are displayed in the user-specified sequence. Unused
fields (below the line) are listed alphabetically, for convenience.
2
222
In the nnn field, perform these steps:

a
To remove a field from the display, specify the line command 0 next to the
field, and press Enter. This moves the field below the line to the not used
section.
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 fields placement on the screen.
To reorder fields, specify a new value next to the desired fields, and press
Enter.
Order values begin at 10, and increment by 10. This enables you to position
multiple fields in between existing fields, if necessary.
Each time a field is included in or removed from the display sequence, or fields are
reordered, the Order values are recalculated for the entire list.
3
Enter END at the Command line to save the changes and return to the previous
screen.
In this example, the Event Number appears in Field 1, the Schedule Date in Field 2,
the Sched Time in Field 3, and the Status/Reason Code in Field 4. The remaining
fields are marked for removal because their nnn value has been set to 0. When
you press Enter, those fields are moved below the separator line to indicate that they
are not displayed:
ASG-Zeke
Command ===>
Schedule View Display Setup
Row 1 of 33
Scroll ===> PAGE

Line Commands: nnn - Move to/after nnn; 0 - Don't show
nnn
---
0
0
0
0
0
0
0
0
0
0
0
0
Order
----10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
Field Description
*Date Format: YYYYDDD
-----------------------------------------------------------------Event Number
Schedule Date *
Schedule Time
Status/Reason Code
Job Name
Event Type
Event Name
Late Dispatch Time
System Identification
Run Date *
CNT (number of times)
Status Time
Early Dispatch Time
Must End Time
Note:
On the Schedule View screen, the DOC, JCL, AUTO REPLY, RESOURCE,
CODE, and WHEN fields always appear as the last six fields, and cannot be moved.
223
Changing the Date Display Format

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

1
From the Zeke Primary Menu, enter option C.4. The Date Selection screen is
displayed. The selected format is marked by an asterisk (*) in the Current Format
column:
ASG-Zeke
OPTION ===>
OPT
1
2
3
4
Current
Format
*
Date Selection
Format
YYYYDDD
YYDDD
MM/DD/YYYY
MM/DD/YY
Description
Use
Use
Use
Use
7 digit Julian date (default)

5 digit Julian date
10 character Gregorian date
8 character Gregorian date
In the OPTION field, specify the corresponding option number (OPT) to select the
date format that you want to use in Schedule View, and press Enter.
Accessing Other Zeke Online Functions

You can quickly access other functions of the Zeke online facility from Schedule View.
The Zeke Primary Menu options are still valid; however, Schedule View offers an
alternate way to access these other areas of the online facility.
To access other Zeke online functions from Schedule View

1
224
From the Zeke Primary Menu, enter option 2.1. The Schedule View screen is
displayed.
Desired Result
Action
Access EMRs
Enter EMR on the Command line, and press Enter. The Event
Master Selection Criteria screen is displayed.
Or
Enter EMR in the Line Cmd field for an event, and press Enter.
The Event Master Definition screen is displayed in Browse
mode.
See Event Master Record (EMRs) on page 52 for more
information.
Access online
documentation
Enter DOC on the Command line, and press Enter. The

Documentation Selection Criteria screen is displayed.
Or
Enter NOTE in the Line Cmd field for an event, and press
Enter to display Note Text information only for the selected
event.
See Event Documentation on page 164 for more
information.
Access work centers
Enter WORK on the Command line, or in any Line Cmd field,

and press Enter. The Work Center Selection Criteria screen is
displayed.
See Work Centers on page 149 for more information.
Access PathFinder
Enter one of these line commands in the Line Cmd field:

PATH
Displays all predecessors and successors for the

event.
PRED
Displays only predecessors.
SUCC
Displays only successors.
225
Desired Result
Action
Access Zebb
Enter one of these line commands in the Line Cmd field to

access the appropriate Zebb function:
ZEBB
Display the Job Functions Menu.
DSN
Display the Step/DD Level Information screen.
LDSN
Display the List DSN Detail Information screen.
RSTRT
Display the Job Restart Management screen.
Note:
Display SQR information
on one screen
Enter ZOOM in the Line Cmd field for the selected event, and
press Enter.
See Accessing an Expanded SQR (Using ZOOM) on
page 216 for more information.
Edit or override JCL for a

job event
Enter ZOOM in the Line Cmd field for the selected event, and
press Enter.
See Overriding JCL on page 226 for more information.
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 events schedule entry for
subsequent runs. If you override the JCL for a recurring event, all subsequent runs for that
schedule day will use the override JCL (unless the override copy is manually deleted).
When the event is completed successfully, the JCL override copy is purged with the event
at the next schedule load.
Note:
If JESQ is the JCL source for the SQR, you cannot override the JCL from Zeke.
226
To modify the JCL for an event

1
Access Schedule View, and locate the event for to which you want to access the JCL
(as described in Displaying Scheduled Events on page 200).
Enter JCLR in the Line Cmd field next to the job, and press Enter.
This message is displayed:
Request queued
Enter ZOOM in the Line Cmd field, and press Enter. The Schedule View Record
Expand Function screen is displayed:
ASG-Zeke
Command ===>
Evt: 000028
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
Sched date: 2012053

Run date: 2012053
Version: 00000
Type: JOB
App:
System: ZEQA
Class:
Target: *LOCAL
Early:
Dprty: 50
Cntrl: Y
Sched: 00:00
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
D - Delete
JCL--> Override present in SQR

JCL--> Zeke JCL
Grp:
Usrid:
Mustend:
Freqcalc: S
Virt Mem:
E - Edit
Notafter:
Trig: A
R - Retrieve
Delete after next use (Y/N) N
Review the first JCL field. In this example, the field indicates the JCL has not been
retrieved yet:
Override present in SQR
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.
In the Delete after next use (Y/N) field, specify whether to delete the updated JCL
after the next use. If you set this field to Y, the override JCL is deleted after the next
run of the job. If you set this field to N, the JCL is kept and re-used for every job run
until the override JCL is manually deleted (using the D line command in Schedule
View), or this option is changed to Y. The default setting for this field is controlled
by the DefDelOJ generation option.
227
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>
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
000009 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
000011 //SYSIN
DD *
000012 SET WAIT 1
000013 //*
****** ************************** Bottom of Data **************************
Make any necessary changes, and press F3 to save the changes and return to the
Schedule View Record Expand Function screen.
Note:
A few editing commands have the same name in ISPF as in Zeke (e.g., CANCEL,
COPY, and EDIT). When these commands are issued from Zeke, they are
processed as Zeke commands (rather than as ISPF commands). To use the ISPF
command when there is a Zeke command by the same name, you must issue it as
part of the ISPF EDIT command BUILTIN (e.g., BUILTIN CANCEL). Otherwise,
it is assumed that you are issuing a Zeke command (and not an ISPF command).
See your ISPF documentation for details about the BUILTIN command.
9
Press F3 again to return to the Schedule View screen.
10
Optional. You can check your JCL for syntax errors without affecting the actual
SQR. See Validating JCL on page 231.
Zeke PDS JCL Override

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

1
Enter ZOOM in the Line Cmd field to the left of the job, and press Enter.
ASG-Zeke
Command ===>
Event ===>
Schedule View
System=SYSD
BROWSE
Scroll ===> PAGE
Selected=0000034
2012.084
12:51
Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ?
Line Commands: Del Delete Wh When
? to list other Line Commands
Line Event Sched
Job
Evnt Event
Event Status
Cmd
No.
Date
Name
Type Name
Reason Code
==========================================================================
000001 2012067 DOWN0001 JOB DOWNLOAD0001 Queued Download Hold
zoom 000021 2012069 ZEK806
JOB ABEND806
Fail S806
000025 2012065 ZEKXDCA JOB JOBTEMPLATE Queued Need Oper OK
000076 2012057 ZEKJCL
JOB ZEKEJCLTEST Success
000079 2012065 ZEKJCL2 JOB ZEKEJCLTEST Fail Forced
001014 2012068 KATHYG01 JOB KATHYG01
Fail JCL Error
001098 2012067 TRACK04 JOB TRACK0000004 Active
6900%
001694 2012067
SCOM EOJTRACK75
Success
********************************** BOTTOM OF DATA *************************
229

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

ASG-Zeke
Command ===>
Evt: 000021
Schedule View Record Expand Func Override successful

Platform: MVS
Job: ZEK806
Sched date: 20122012069

Run date: 2012069
Version: 00000
Type: JOB
EventName: ABEND806
System: SYSD
Class: A
Early:
Dprty: 50
Cntrl: Y
Sched: 00:00
Times:
Tapes:
App: A2345678
Target: *LOCAL
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
D - Delete
Mustend:
Freqcalc: S
Virt Mem:
E - Edit
Notafter:
Trig: A
R - Retrieve
JCL--> PDS: ZEKEJCL Member: ABEND806
After the datasets are allocated, ZOVERPDS copies the member (indicated in the
SQR) to a dataset pointed to by the OVERRIDE DD in the Zeke started task. A
ZALTER command is issued against the SQR to change the SQR to point to the
OVERRIDE DD.
4
230
Exit, and then re-access, the zoom screen to see the change in the SQR.
Optional. Enter E to the left of the JCL-->PDS: OVERRIDE Member field to

edit the override JCL.
ASG-Zeke
Command ===>
Evt: 000021
Schedule View Record Expand Function BROWSE

Platform: MVS
Job: ZEK806
Sched date: 2012069

Run date: 2012069
Type: JOB
EventName: ABEND806
System: SYSD
Class: A
Early:
Dprty: 50
Cntrl: Y
Sched: 00:00
Times:
Tapes:
App: A2345678
Target: *LOCAL
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
Version: 00000
D - Delete
Mustend:
Freqcalc: S
Virt Mem:
E - Edit
Notafter:
Trig: A
R - Retrieve
e JCL--> PDS: OVERRIDE Member: ABEND806
Validating JCL
After you create or edit JCL, you can check it for syntactical errors using one of these
facilities:
ASG-JCLPREP (through use of the JPREP line command)
ASG-JOB/SCAN (through use of the JSCAN line command)
ZSCAN operator command
Note:
Other JCL scanning products can be invoked from the Schedule View display by using
the Zeke line command JSCAN. You must write a TSO CLIST or REXX EXEC to
perform the validation before using the JSCAN line command. See the section on using
other JCL scanning products in the ASG-Zeke Scheduling for z/OS Installation Guide. If
your product provides an ISPF EDIT macro to scan JCL, then you can use it while editing
event JCL from the ZOOM display.
Invoking ASG-JCLPREP
ASG-JCLPREP (herein called JCLPREP) validates the JCL syntax for a job and issues a
report about its accuracy. From Schedule View, you can invoke JCLPREP in either of
two ways:
Through the ZOOM feature
By entering the JPREP line command
JCLPREP can only be used for jobs with existing JCL.

231
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
Enter ZOOM in the Line Cmd field to the left of the selected job event, and press
Enter. The Schedule View Record Expand Function screen is displayed:
ASG-Zeke
Command ===>
Evt: 000028
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
Sched date: 2012053

Run date: 2012053
Version: 00000
Type: JOB
App:
System: ZEQA
Class:
Target: *LOCAL
Early:
Sched: 00:00
Dprty: 50
Cntrl: Y
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00

JCL--> Zeke JCL
232
D - Delete
Grp:
Mustend:
Notafter:
Freqcalc: S
Virt Mem:
E - Edit
Usrid:
Trig: A
R - Retrieve
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>
==MSG>
000100 //ZEKTST30 JOB (10038),'J SMITH',
000200 //
MSGCLASS=Y,CLASS=A,
000300 //
REGION=4M
000610 //STEPLIB DD
000620 //*
DD
000630 //
DD
000640 //*
DD
000650 //*
DD
DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB
000660 //*
DD
DISP=SHR,DSN=ZEKE.PDBER.LINKLIB
000670 //
DD
000680 //
DD
000690 //*
DD
000691 //
DD
000800 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
000900 //SYSIN
DD *
Enter FPREP on the Command line, and press Enter to invoke the JCLPREP EDIT
macro. JCLPREP is invoked to check the JCL syntax.
After JCLPREP completes the check, the JCLPREP output is displayed.
When you finish reviewing the JCLPREP output, press F3 to exit the output screen.
To invoke JCLPREP using the JPREP line command

1
From the Schedule View screen, enter JPREP in the Line Cmd field 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.
When you finish reviewing the JCLPREP output, press F3 to exit the output screen.
Invoking JOB/SCAN
From Schedule View, you can invoke the JCL management tool, ASG-JOB/SCAN, in
either of two ways: through the ZOOM feature, or by entering the JSCAN line command.
Both methods for accessing ASG-JOB/SCAN (herein called JOB/SCAN) are described
in this section.
JOB/SCAN can only be used for jobs that have existing JCL.
233
See the ASG-Zeke Scheduling for z/OS Installation Guide for information on configuring
JOB/SCAN for JCL management, and for important setup procedures that must be
performed before you can invoke JOB/SCAN from Schedule View. Also refer to your
JOB/SCAN documentation series for more information.
To invoke JOB/SCAN using the ZOOM feature of Schedule View

Note:
For SQRs with JESQ as the JCL source, the JCL cannot be viewed or edited.
1
Enter ZOOM in the Line Cmd field next to the job and press Enter. The Schedule
View Record Expand Function screen is displayed:
ASG-Zeke
Command ===>
Evt: 000028
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
Sched date: 2012053

Run date: 2012053
Version: 00000
Type: JOB
App:
System: ZEQA
Class:
Target: *LOCAL
Early:
Sched: 00:00
Dprty: 50
Cntrl: Y
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00

JCL--> Zeke JCL
234
D - Delete
Grp:
Mustend:
Notafter:
Freqcalc: S
Virt Mem:
E - Edit
Usrid:
Trig: A
R - Retrieve
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>
==MSG>
000100 //ZEKTST30 JOB (10038),'J SMITH',
000200 //
MSGCLASS=Y,CLASS=A,
000300 //
REGION=4M
000610 //STEPLIB DD
000620 //*
DD
000630 //
DD
000640 //*
DD
000650 //*
DD
DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB
000660 //*
DD
DISP=SHR,DSN=ZEKE.PDBER.LINKLIB
000670 //
DD
000680 //
DD
000690 //*
DD
000691 //
DD
000800 //SYSABEND DD SYSOUT=*
000900 //SYSIN
DD *
Enter JEM on the command line, and press Enter to invoke the JOB/SCAN EDIT
macro. JOB/SCAN is invoked to check the JCL syntax.
After JOB/SCAN completes the check, the JOB/SCAN output is displayed.
When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.
To invoke JOB/SCAN using the JSCAN line command

1
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.
When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.
Note:
See the JOB/SCAN documentation series for more instructions.
235
Using ZSCAN
You can check your JCL for syntax errors through the OS facility. This function is the
same as issuing the Zeke operator command ZSCAN and follows the same guidelines as
the JCL feature TYPRUN=SCAN. Your job card must have a MSGCLASS= value that
will hold the output on the spool. Otherwise, you cannot view the system messages.
Note:
To validate JCL on another system, you must specify the system name. Use the ZSCAN
operator command to do so. See the ASG-Zeke Scheduling for z/OS Reference Guide for
details).
Note:
This feature is not supported for SQRs which have JESQ as the JCL source.
To check your JCL for syntax errors using ZSCAN

1
Enter SCAN in the Line Cmd field, and press Enter.
If you have a package designed to browse the JES spool (e.g., SDSF or BETA92),
use it to view the messages. Otherwise, enter SYSM in the Line Cmd field and press
Enter. The Schedule View Record Expand Function screen is displayed.
All SYSLOG and JESLOG messages can be displayed to aid in problem resolution
and speed the restart process. Use the SYSL and SYSJ line commands,
respectively.
Note:
The SYSM, SYSL, and SYSJ commands are valid only if these conditions are met:
236
You are running an OS release that supports IBMs spool browse facility
You are running JES release 4.x or above
The job is in the JES spool.
Zeke Dispatching
Zeke determines the order in which events are dispatched by evaluating these event
attributes or conditions in sequence:
1
Dispatch priority from the events SQR.
Whether or not the event is near its must start time (Muststart). Zeke considers, as
applicable, an events not after time (Notafter), must end time (Mustend), average
duration (Avgdur), and the value of the Mspintrl generation option (see page 300).
Zeke uses one of these two formulas to calculate an events near dispatch time and
evaluate whether to elevate its dispatch priority:
Mustend Avgdur Mspintrl = near_dispatch_time
For example, lets suppose that the Mustend time for event ABC is set to 17:00.
The events average duration is 30 minutes. The value of the Mspintrl generation
option is 1 hour (the default value). Based on this formula, Zeke assigns event ABC
a higher dispatch priority at 15:30.
Or
Notafter Mspintrl = near_dispatch_time

For example, lets suppose that the Notafter time for event DEF is set to 11:00.
The value of the Mspintrl generation option is 1 hour (the default value). Based on
this formula, Zeke assigns event DEF a higher dispatch priority beginning at 10:00.
3
Whether the event is past its late start time (Latestart) and the Prilate generation
option is set to Y (which gives priority to late events despite their schedule time).
Run date.
Schedule time from the SQR.
Event number.
Version number.
Note:
An events late end time (Lateend) does not affect its dispatching sequence.
See Defining a Job Event on page 69 for information on schedule times and other event
attributes that affect event dispatching.
237
See Dispatching Events and Messages on page 300 for details on the generation
options that control dispatching.
Early Warning Alerts

If enabled, Zekes early warning processor analyzes the historical run times for a
scheduled events 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, Zekes early warning processor estimates the start and end time of every
SQR that has one or more of these time constraint values specified:
Latestart
Lateend
Notafter
Mustend
If the SQRs projected start or end time exceeds one of its time constraints, Zeke issues
an early warning alert to OpsCentral.
To enable early warning alerts, the OpsCentral server must be configured (i.e., the GUI
Serv generation option must be set to Y) and the ZEKE_SERVER_ALERT_EARLYWARN
environment variable must be set to YES on at least one of the Zeke systems in your
Zekeplex.
Zeke projects an SQRs start and end times by examining the triggers from its WHEN
condition and recursively projecting the start and end times of its predecessors. The early
warning processor considers only triggers that can be matched to an SQR in the schedule.
These types of triggers are ignored:
DSN, VAR, and NOTDURINGs.
All abend triggers (i.e., AEOJ, AEOS, AEOP, AEOE).
EOS, EOP, and BOP triggers that do not specify a jobname.
Remote dependencies (i.e., triggers with the AT keyword).
EOJ, BOJ, or EOE triggers with a job or event name that does not match an SQR.
Other than these exceptions, Zekes early warning processor assumes that all of an SQRs
triggers must be satisfied before the event can be dispatched (i.e., Zeke assumes that all
WHEN conditions use the AND operator instead of the OR operator).
238
Zeke ignores any SQR requirements other than time and WHEN prerequisites (e.g.,
logical resources, tape drives, and initiators), and also any manual intervention
requirements (i.e., operator OKs and work centers).
Because Zeke does not track the duration lengths of nonjob events, when projecting
start/end times, Zekes early warning processor assumes that all nonjob SQRs have a
duration of one minute.
Caution! If you use early warning alerts and you restore an earlier Zeke database backup
file, ASG recommends that you restore the database with the NOSCHED
option. Otherwise, if an earlier schedule is restored, your network could become
flooded with early warning alerts.
/ZCOM Option
You can issue Zeke operator commands either from the console or through the /ZCOM
option. See the ASG-Zeke Scheduling for z/OS Reference Guide for a complete list of
commands, parameters, and values that are valid for Zeke operator commands.
Note:
You also can update the values of Zeke variables through the /ZCOM option.
To issue Zeke operator commands through /ZCOM

1
From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions
ASG-Zeke
Option ===>
Schedule Control Function
BROWSE
Please enter a valid Zeke operator command

Opt Description
Opt Description
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
ZD
ZD JOB
ZD MSG
ZD SCOM
ZD ZCOM
ZD WAIT
ZD DONE
ZD LATE
ZD HOLD
ZD AV
ZID
ZMAP
Cmd: Add - ZADD Function
239
The Schedule Control Function screen lists some of the most common operator
commands you can issue for displaying and updating scheduled event information
(depending on your security and class definition).
2
Enter the command (or the option number for the command) on the Option line and
press Enter. The ZCOM Output screen is displayed.
For example, to display all of the events in the current schedule, enter 1 or ZD on
the Option line, and press Enter.
Note:
You also can set your own customized commands for options 13 through 24.
Modifying PF Keys
Using the SETPF command, you can temporarily modify the PF keys assigned to ZCOM
commands. Modified PF keys remain set until you exit the ZCOM function.
For example, this command modifies the command assigned and executed when you
press PF1:
SETPF PF1 'ZD JOB = *PR'
You also can assign a command to a PF key and include a prompt so that you can modify
the command parameters before the command is executed. Use these special characters in
the command assignment:
Character
Meaning
>
Indicates to display the command on the Command line without executing it.
This enables the operator to modify the command. Specify this character in the
first position (before the command).
Indicates where in the command to position the cursor so that the operator can
insert parameter values.
For example, lets suppose you issue this command to modify the command assigned and
executed when you press PF1:
SETPF PF1 >ZADD APP @
DATE 999999
When you press PF1, this command is displayed on the Command line:
ZADD APP @
DATE 999999
The cursor is positioned after APP to enable to specify the application name.
240
When you press Enter, the corresponding Zeke Command Output Display screen is
displayed detailing the selected criteria:
ASG-Zeke
Command ===>
Zeke Command Output Display
BROWSE
Row 1 to 17 of 30
Scroll ==> PAGE
Please enter a valid Zeke operator command or option number.

Press PF3/PF15 key to return to the schedule control function panel.
-------------------------------------------------------------------------Z0922I DATE
RDATE
VER TYPE JOB/EVT NAME DP SCHED FREQ CNT
STATUS
000006 2012053 2012053 000 JOB TSKKGUT1
50 00:00
1 T
000008 2012053 2012053 000 JOB TSKKGUT3
50 00:00
1 T
000011 2012053 2012053 000 JOB SPTEXD11
50 00:00
1 T
000018 2012053 2012053 000 JOB SPTEXD18
50 00:00
1 T
000019 2012053 2012053 000 JOB SPTEXD19
50 00:00
1 T
000020 2012053 2012053 000 JOB SPTEXD20
50 00:00
1 T
000021 2012053 2012053 000 JOB SPTEXD21
50 00:00
1 T
000022 2012053 2012053 000 JOB SPTEXD22
50 00:00
1 T
000023 2012053 2012053 000 JOB SPTEXD23
50 00:00
1 T
000024 2012053 2012053 000 JOB SPTEXD24
50 00:00
1 T
000025 2012053 2012053 000 JOB SPTEXD25
50 00:00
1 T
000026 2012053 2012053 000 JOB SPTEXD26
50 00:00
1 T
000028 2012053 2012053 000 JOB TSKKGUT1
50 00:00
1 T
000029 2012053 2012053 000 JOB SPTEXD29
50 00:00
1 T
000030 2012053 2012053 000 JOB SPTEXD30
50 00:00
1 T
Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00028 SYSTEM ZEQA
As usual, press F3 to return to the previous screen.
PathFinder
PathFinder displays all predecessor and successor relationships for an event. This enables
you to evaluate what needs to occur before an event can run, and what will happen after
the event has run. You can access PathFinder through Schedule View, or by issuing a
Zeke operator command.
See Using Schedule View on page 191 for information on activating PathFinder
through Schedule View.
This procedure explains how to activate PathFinder using a variety of Zeke operator
commands.
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on Zeke
operator commands.
Note:
You also can issue any of the operator commands described in this procedure directly
from the console.
241
To activate PathFinder using Zeke operator commands

1
From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions
Desired Result
Action
Display predecessors for

an event at all levels
Issue one of these commands from the Option line:

ZD PRE LEV * JOB jobname
ZD PRE LEV * EV event-number
Zeke considers the specified event to be at level 0 and

displays at the bottom of the flow. You might have to scroll
down to see the Level 0 job.
Then, scroll up to see the order of the predecessors. They are
displayed from the bottom to the top, beginning with the first
job (Level 1). Displayed above each Level 1 job are all the
jobs that trigger it (Level 2 through the end).
If a condition has already been displayed, this message
appears directly underneath the job that triggered it:
CONDITION ALREADY DISPLAYED BELOW
Display successors for an

event at all levels

ZD SU LEV * JOB jobname
ZD SU LEV * EV event number
The specified job is the zero (0) level job and is displayed at
the top of the screen. All jobs that are triggered by this job are
displayed below the Level 0 job beginning with the first job
(Level 1). Displayed under each Level 1 job are all the jobs
that it triggers (Level 2 through the end).
If a condition has already been displayed, this message
appears directly underneath the job that triggered it:
CONDITION ALREADY DISPLAYED ABOVE
Display all predecessors
and successors for an event
ZD PRE SU LEV * JOB jobname
ZD PRE SU LEV * EV event number
Scroll down until you find the first job (Level 0) and page up
for the predecessors and down for the successors.
242
Desired Result
Action
Display nonZeke jobs in

path
The generation option Trigjob must be set to A so that any job

can trigger another event's WHEN conditions, regardless of
how the job is dispatched. this message is displayed whenever
a nonZeke job is found:
** NOT IN THE SCHEDULE OR NOT A ZEKE EVENT **
Note:
The predecessors cannot be displayed because those events
do not have WHEN conditions.
Display different levels in
the hierarchy
Enter LEV followed by a space and the number of levels you

want to display with one of the commands listed above and
press Enter. For example,
ZD SU EV 100 LEV 3
Display up to 3 levels of jobs that are dependent upon event

100.
Note:
Enter an (*) asterisk to display all levels.
If Zeke detects a loop in any of the WHEN conditions, it will continue to list all
predecessors and successors and display this message:
*** INFINITE WHEN-CONDITION LOOP DETECTED!! ***
243
Display Successor Example

This diagram and screen display show all events that are dependent on an event named
MYTEST (i.e., its successors):
MYTEST
(Level 0)
ALHJOB2
(Level 1)
DONETST
(Level 2)
ZTSRPT9T
(Level 2)
ZTSERAXT
(Level 3)
ZTSBKUP
(Level 4)
ZTSDONE
(Level 4)
If you issue this command:

ZD SU LEV * JOB MYTEST
then, a screen similar to this one is displayed:

ASG-Zeke
Command ===>
BROWSE
Row 1 to 5 of 5
Scroll ==> PAGE

----------------------------------------------------------------------------ZD SU LEV * JOB MYTEST
Z09ADI SUCCESSORS FOR THE REQUESTED EVENT:
LVL JOB/EVT NAME TYPE EVENT
DATE
VERS WHEN TRIGGER NAME T-VER STATUS AVDUR
0 MYTEST
JOB 000008 2012053 0000
T
00:00
---------------------------------------------------------------------------->>1 ALHJOB2
JOB 000002 2012045 0000 EOJ MYTEST
T
00:00
2 DONETST
JOB 000053 2012045 0000 WEOG ALHJOB2
00:00
2 ZTSRPT9T
JOB 000067 2012045 0000 WEOG ALHJOB2
00:23
3 ZTSERAXT
JOB 000003 2012045 0000 WEOJ ZTSRPT9T
00:03
4 ZTSBKUP
JOB 000708 2012045 0000 WEOJ ZTSERAXT
00:20
4 ZTSDONE
JOB 000930 2012045 0000 WEOJ ZTSERAXT
00:10
******************************* Bottom of data *******************************
244
Display Predecessor Example

This diagram and screen display show all events on which the event MYTEST is
dependent (i.e., its predecessors):
ZTSVLDTT
(Level 5)
ZSJOBAT
(Level 5)
ZTSJOBBT
(Level 4)
ZTSVLDTT
(Level 3)
ZTSVLDTT
(Level 4)
ZTSJOBDT
(Level 3)
ZTSJOBKT
(Level 2)
ZEKTST04
(Level 1)
MYTEST
(Level 0)

ZD PRE LEV * EVENT 54

AZ09ACI PREDECESSORS FOR THE
3*ZTSVLDTT
JOB 001005
5*ZTSVLDT3
JOB 001009
5*ZSJOBAT
JOB 001010
4 ZTSJOBBT
JOB 001007
REQUESTED EVENT:
DATE
2012038 0000
*
00:00
2012038 0000
*
00:00
2012038 0000
*
00:00
2012038 0000 EOJ ZTSVLDT3
T
00:00
EOJ ZSJOBAT
4*ZTSVLDT2
JOB 001008 2012038 0000
*
00:00
3 ZTSJOBDT
JOB 001006 2012038 0000 EOJ ZTSJOBBT
T
00:00
EOJ ZTSVLDT2
2 ZTSJOBKT
JOB 001004 2012038 0000 EOJ ZTSVLDTT
T
00:00
EOJ ZTSJOBDT
>>1 ZEKTST04
JOB 001003 2012038 0000 EOJ ZTSJOBKT
T SCHD 00:00
-----------------------------------------------------------------------------0 MYTEST
JOB 001002 2012038 0000 EOJ ZEKTST04
T
00:00
******************************* Bottom of data ********************************
245
Display Predecessor and Successor Example

This is an example that shows all of the other events that event ZEKEEVTST3 is
dependent on (i.e., its predecessors), and all of the events that are dependent on event
ZEKEEVTST3 (i.e., its successors.
ZD PRE SU LEV * EV 3

ASG-Zeke
Command ===>
BROWSE
Row 1 to 17 of 131
Scroll ==> PAGE

predecessors
successors
246
----------------------------------------------------------------------------ZD PRE SU LEV * EV 3

Z09AEI PREDECESSORS AND SUCCESSORS FOR THE REQUESTED EVENT:
DATE
>>1*ZEKEEVTST1
MSG 000001 2012053 0000
*
2 KATHYG
*** NOT IN THE SCHEDULE OR NOT A ZEKE JOB ***
2*ZEKEEVTST1
MSG 000001 2012053 0000
*
2*ZEKEEVTST1
MSG 000034 2012053 0000
*
>>1 ZEKEEVTST2
MSG 000002 2012053 0000 EOJ KATHYG
T
EOE ZEKEEVTST1
>>1*ZEKEEVTST1
MSG 000034 2012053 0000
*
----------------------------------------------------------------------------0 ZEKEEVTST3
MSG 000003 2012053 0000 EOE ZEKEEVTST2
T
EOE ZEKEEVTST1
---------------------------------------------------------------------------->>1 ZEKEEVTST4
T
2 ZEKEEVTST5
T
3 SPTEXD11
JOB 000011 2012053 0000 EOE ZEKEEVTST5
T
00:00
2 SPTEXD29
JOB 000029 2012053 0000 EOE ZEKEEVTST5
T
00:00
Manually Adding Events to the Schedule

Normally, the SCHEDULE function (a ZEKE batch utility program) automatically
schedules all of the required events. If you occasionally need to add an individual event
or a group of events to the schedule. Zeke offers these methods for creating an SQR
manually:
ZADD operator command
ADD online function
ADD by path online function
Note:
If you manually add a job to the schedule that has Zeke Agent as its target, then Zeke
downloads (if the agent is configured in Zeke as a download agent) or dispatches the new
job event immediately after Zeke creates the SQR.
Using the ZADD Operator Command

This section explains how to add an event to the schedule using the ZADD operator
command. You must know the event number, event name, or jobname of the event that
you want to add.
To add an event to the schedule using ZADD

1
From the Zeke Primary Menu, enter 2.2 and press Enter. The Schedule Control
Function screen is displayed:
ASG-Zeke
Option ===>
Schedule Control Function
BROWSE
Please enter a valid Zeke operator command

Opt Description
Opt Description
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
ZD
ZD JOB
ZD MSG
ZD SCOM
ZD ZCOM
ZD WAIT
ZD DONE
ZD LATE
ZD HOLD
ZD AV
ZID
ZMAP
Cmd: Add - ZADD Function
247
Desired Result
Action
To add an event by event number
Issue this command:

ZADD EV event-num
To add multiple events using a range of

event numbers
Issue this command:
To add one version of an event by event

number
Issue this command:
To add a job event by jobname
Issue this command:
ZADD EV (event-num, event-num, ...)
ZADD EV event-num VER version-num
ZADD JOB name
To add any event by event name
Issue this command:

ZADD ENAME name
Note:
See the ASG-Zeke Scheduling for z/OS Reference Guide for a complete list of
parameters and values that are valid with the ZADD operator command.
For example, to add event 00018 to the schedule, enter ZADD EV 18 on the
Command line, and press Enter. A corresponding message screen is displayed:
ASG-Zeke
Command ===>
BROWSE
Row 1 to 7 of 7
Scroll ==> PAGE

-------------------------------------------------------------------------ZADD EV 18
Z0952E EVENT 000018 SCHEDULE RECORD ALREADY EXISTS WITH SAME DATE/VERSN
Z0929I ZEKE COMMAND PROCESSED
Z0922I DATE
RDATE
VER TYPE JOB/EVT NAME DP SCHED FREQ CNT
STATUS
000018 2012053 2012053 000 JOB SPTEXD18
50 00:00
1 T
000018 2012055 2012055 000 JOB SPTEXD18
50 00:00
1 T
Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00002 SYSTEM ZEQA
****************************** Bottom of data *****************************
248
Using the ADD Function

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

1
From the Zeke Primary Menu, enter option 2.3. The ADD Event Record Selection
ASG-Zeke
Command ===>
Options:
ADD Event Record Selection Criteria
Auto:
Hold:
Rerun:
Run:
N
N
N
N
(Y/N)
(Y/N)
(Y/N)
(Y/N)
Schedule Date: 2012055
Enable: N
Rebuild: N
Refresh: N
(YYYYDDD)
(Y/N)
(Y/N)
(Y/N)
Run Date: 2012055
2012.055
15:26
(YYYYDDD)
Event ===>
Enter a selection mask in any field(s) to be compared for selection.
Event Types
Job:
Msg:
Pcom:
Work:
Vcom:
Zcom:
Scom:
REXX:

Job Name:
Event Name:
Application:
Group ID:
User ID:
Drl ID:
System:
Permanent:
Specify these additional parameters for adding the event. The valid values for each
field are N (the default) and Y. Specify Y for each action that you want Zeke to
perform during the ZADD process:
Field
Description
Auto
Indicates to add 1 to the number of dispatch times (if the scheduled event is
active). The REFRESH and ENABLE parameters are assumed.
Note:
This parameter is not valid for work center events.
Enable
Indicates to change the event status from Disabled to Enabled.
249
Field
Description
Hold
Indicates to place an operator hold on the event after Zeke adds, refreshes,
or enables the event.
You must release the event from hold before Zeke can dispatch it.
Note:
This parameter is not valid for work centers.
Rebuild
Indicates to re-create the SQR (if an SQR exists already). When rebuilding
an SQR, Zeke performs these actions:
Deletes the SQR.
Re-adds the SQR to the schedule.
Resets all WHEN conditions.
Reflects any EMR changes.
Updates the event status to Active.
Resets any changes made previously using the ZALTER operator
command.
Rerun
Indicates to add the RERUN designation to the SQR. The RERUN

designation appears in the ZDISPLAY operator command output, and is
passed to the ZEKE14D user exit.
If the Zeke generation option TrigRm is set to N, the event does not trigger
the WHEN conditions of other events. You must use the NORERUN
parameter with the ZALTER operator command to remove the RERUN
designation.
Refresh
Indicates to refresh an SQR (i.e., if the status is EOJ, AEOJ, or Pending) by

resetting the event as if it had never run.
Note:
This parameter does not place an operator hold on the event as the
ZREFRESH operator command does.
Run
Indicates to add the event to the schedule ready to run.

Note:
This parameter has the same effect as the ZALTER RUN operator
command.
250
If you are adding only one event, you can specify the event number in the Event field.
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.
Specify any character (except a space) in one or more of the Event Type fields
to display events of the selected type(s).
In the Selection Field Mask fields, specify any additional information about the
events that you want to display (e.g., jobname, user ID, run date, etc.). You can
use wildcards and placeholders (see Specifying Generic Selection Criteria
on page 57).
Press Enter. The Schedule View Event Add List screen is displayed:
ASG-Zeke
Command ===>
Schedule View Event Add List

Scroll ===> PAGE
Selected=0000046
Line Commands: S - Select to add the event to the Schedule

Versn Event
Event
Sched
Evnt System
Applic
User
Job
No.
Number Name
Info
Type ID
ID
ID
Name
==========================================================================
000001 ZEKEEVTST1
2012053 MSG ZEQA
000002 ZEKEEVTST2
2012053 MSG ZEQA
000003 ZEKEEVTST3
2012053 MSG ZEQA
000004 ZEKEEVTST4
2012053 MSG ZEQA
000005 ZEKEEVTST5
2012053 MSG ZEQA
000006 KTEST1
2012053 JOB ZEQA
KTEST
TSKKGUT1
000007 KTEST2
2012053 JOB ZEQA
KTEST
TSKKGUT2
000008 KTEST3
2012053 JOB ZEQA
KTEST
TSKKGUT3
000009 KTEST4
2012053 JOB ZEQA
KTEST
TSKKGUT4
000010 KTEST5
2012053 JOB ZEQA
KTEST
TSKKGUT5
000011 ZEKEEVCC
2012053 JOB ZEQA
SPTEXD11
000012 ZEKEEVCC
2012053 JOB ZEQA
SPTEXD12
000013
2012053 WORK ZEQA
000014
2012053 VCOM ZEQA
000015*
today
ZCOM ZEQA
000016
2012053 SCOM ZEQA
Enter S to the left of each event that you want to add to the schedule. To add a
particular version of an event to the schedule, specify the version number in the
Versn No. field. You can add multiple events at the same time.
Note:
An asterisk (*) next to an event number indicates that more than one event is
scheduled with the same event number and different schedule dates.
7
Press Enter to select all of the events that you marked on this page.
251
Optional. Press F8 to display the next page of events, and repeat step 6 and step 7.
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 events path). A path includes the root event and its
predecessor and successor events.
Note:
To use this function, the DSPIndex generation option must be set to Y.

You cannot use this function to schedule events with the OCCURS clause (REQUEST).
To add an event to the schedule based on an event path

1
From the Zeke Primary Menu, enter option 2.4. The ADD Event Record by Path
Selection Criteria screen is displayed:
ASG-Zeke
Command ===>
ADD Event Record By Path Selection Criteria
Criteria:
Event
Version
Occurs Date
Level
Type
==>
==>
==> 2012022
==> 1
==> B
(omit for default)

(YYYYDDD)
(P=pred, S=succ, B=both)
ZADD options:
Run Date
Auto:
Rebuild:
Run:
252
==>
N
N
N
(Y/N)
(Y/N)
(Y/N)
(YYYYDDD)
Enable: N
Refresh: N
(Y/N)
(Y/N)
Hold: N
Rerun: N
(Y/N)
(Y/N)
Complete these fields to specify the root event:

Field
Description
Event
Required. Specify the event number for the root event (i.e., the event for
which to display the path information).
Version
Specify the version of the root event.
Field
Description
Occurs Date
Specify the OCCURS HIT date (in Julian format). Only events that
would be scheduled on this date are included in the path. The default
value is the current system date.
Level
Specify the number of path levels to display. The valid values range from
1 through 999, or you can specify an asterisk (*) to display all levels).
The default value is 1.
Type
Specify the type of path to display. These are the valid values:
B
Default. Both predecessors and successors.
Predecessors only.
Successors only.
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.
Specify these additional parameters for adding the event. The valid values for each
field are N (the default) and Y. Specify Y for each action that you want Zeke to
perform during the ZADD process:
Field
Description
Auto
Indicates to add 1 to the number of dispatch times (if the scheduled event
is active). The REFRESH and ENABLE parameters are assumed.
Note:
This parameter is not valid for work center events.
Enable
Indicates to change the event status from Disabled to Enabled.
Hold
Indicates to place an operator hold on the event after Zeke adds,

refreshes, or enables the event.
You must release the event from hold before Zeke can dispatch it.
Note:
This parameter is not valid for work centers.
253
Field
Description
Rebuild
Indicates to re-create the SQR (if an SQR exists already). When

rebuilding an SQR, Zeke performs these actions:
Deletes the SQR.
Re-adds the SQR to the schedule.
Resets all WHEN conditions.
Reflects any EMR changes.
Updates the event status to Active.
Resets any changes made previously using the ZALTER operator
command.
Refresh
Indicates to refresh an SQR (i.e., if the status is EOJ, AEOJ, or Pending)

by resetting the event as if it had never run.
Note:
This parameter does not place an operator hold on the event as the
ZREFRESH operator command does.
Rerun
Indicates to add the RERUN designation to the SQR. The RERUN

designation appears in the ZDISPLAY operator command output, and is
passed to the ZEKE14D user exit.
If the Zeke generation option TrigRm is set to N, the event does not
trigger the WHEN conditions of other events. You must use the
NORERUN parameter with the ZALTER operator command to remove
the RERUN designation.
Run
Indicates to add the event to the schedule ready to run.

Note:
This parameter has the same effect as the ZALTER RUN operator
command.
Press Enter.
Note:
If the criteria entered results in multiple hit dates, a pop-up window appears and
enables you to select the appropriate date.
254
The Schedule View Event Add List screen is displayed:

ASG-Zeke
Command ===>
Schedule View Event Add List
Line Commands: S - Select to add the event to the Schedule

Level Event
Job
Evnt
Event
Sched
Versn System
Appl
Grp
Name
Name
Type
Number Date
Number ID
ID
ID
=================================================================================
3
EVENT00V
JOB00V
JOB
000024 2012094 00000 SYSTEM1 PATHAPP PTH
3
EVENT00W
JOB00W
JOB
2
EVENT00U
JOB00U
JOB
3
EVENT00BA
JOB00BA
JOB
3
EVENT00BH
JOB00BH
JOB
3
EVENT00BJ
JOB00BJ
JOB
3
EVENT00BQ
JOB00BQ
JOB
2
EVENT00BL
JOB00BL
JOB
*1
EVENT00BF
JOB00BF
JOB
3
EVENT00BI
JOB00BI
JOB
3
EVENT00BJ
JOB00BJ
JOB
2
EVENT00BH
JOB00BH
JOB
3
EVENT00BJ
JOB00BJ
JOB
3
EVENT00BK
JOB00BK
JOB
2
EVENT00BI
JOB00BI
JOB
1
EVENT00BG
JOB00BG
JOB
0
EVENT00BE
JOB00BE
JOB
000033
2012094
00000 SYSTEM1
PATHAPP
PTH
*1
2
3
3
3
2
3
3
*1
2
3
3
2
3
3
EVENT00BC
EVENT00BA
EVENT00Y
EVENT00Z
EVENT00BL
EVENT00BB
EVENT00Z
EVENT00BA
EVENT00BD
EVENT00BB
EVENT00Z
EVENT00BA
EVENT00BC
EVENT00BA
EVENT00BB
JOB00BC
JOB00BA
JOB00Y
JOB00Z
JOB00BL
JOB00BB
JOB00Z
JOB00BA
JOB00BD
JOB00BB
JOB00Z
JOB00BA
JOB00BC
JOB00BA
JOB00BB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
JOB
000031
000029
000027
000028
000040
000030
000028
000029
000032
000030
000028
000029
000031
000029
000030
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
2012094
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
00000
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PATHAPP
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
PTH
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
SYSTEM1
Enter S to the left of each event that you want to add to the schedule. To add a
particular version of an event, specify the version number in the Versn Number field.
Note:
An asterisk (*) next to the Level number indicates where the events at the next level
begin.
7
Press Enter to select all of flagged events on the current page.
Optional. Press F8 to display the next page of events, repeat step 6 and step 7.
Press Enter to add all of the selected events to the current schedule.
255
256
Resources
Chapter 6:
6
Before dispatching an event, Zeke ensures that all resources are available. These are the
resource types:
Type
Description
Physical
Includes tape drives, systems, pools, and initiators.
Logical
Anything that you want to define to represent the use of a physical resource (e.g.,
an entire CPU, a specific CPU channel, a file, or a dataset).
Logical resources are used for events that, if executed simultaneously, could cause
contention among your system resources.
Note:
Work center events do not use resources.

Topic
Page
Physical Resources
Initiator Processing
Defining Pools
258
258
268
Logical Resources
Defining a Logical Resource
Defining Resources for an Event
Deleting Resources for an Event
271
272
274
277
257
Physical Resources
These are the key types of physical resources that Zeke can use:
Type
Description
Initiators
An initiator is a physical resource that is required by every MVS event. To

optimize the use of system resources, you can configure Zeke to submit
events to a system only when an initiator of the correct class is available.
Note:
Zeke does not support initiator selection for JES3.
Systems and pools
The actual system where an event is processed is a physical resource.

Systems can be combined into pools that share the same database (which
enables Zeke to select the appropriate system for each event).
Tape drives
Tape drives are a physical resource used for job events.

To ensure sufficient tape drives are available before an event executes, you
can specify the number of required tape drives on the jobs EMR. See
Defining a Job Event on page 69. Or, Zeke can automatically calculate
the number of tape drives needed for each job. You use the Zeke generation
option Calctap to activate this feature. See Tape Options on page 308.
Before you determine whether that you want to activate initiator processing, you need to
understand how initiator selection occurs. Defining initiators to Zeke does not mean that
Zeke controls them; instead, it lets Zeke know which initiators are eligible for selection.
No matter how an initiator is selected (i.e., by Zeke or by JES), these are some of the
many factors that determine the actual initiator:
258
Whether there is a class on the job card
Whether there is a list of classes on the EMR
Initiator availability at the time of dispatch
Whether IBMs Workload Manager (WLM) is in use
6 Resources
Settings of the Zeke generation options DispSel, DefDspCl, and UserCls.
Initiator Selection Using DispSel

The most important generation option that affects how initiators are selected is DispSel.
When DispSel is No
If the DispSel generation option is set to N, Zeke submits jobs directly to JES when all
other dispatching criteria have been met (without regard for initiator availability). Jobs
waiting in the JES input queue will have a Pending status while they wait for JES to select
the initiator.
If DispSel is set to N, Zeke checks the EMR for a class list. An event can have up to six
classes. Zeke continues processing based on these criteria:
If no class list is supplied, Zeke checks the value of the generation option
DefDspCl:
If DefDspCl does not have a value, Zeke submits the job to JES and the job
card is unchanged. If a class is not specified on the job card, JES uses the
JES-defined default class.
If DefDspCl has a value, Zeke updates the job card with the default class
value and submits the job to JES.
If there is a class list, Zeke updates the job card with the first EMR class and
submits the job to JES.
If you set the DispSel generation option to N, these are some additional considerations:
NOTDURING dependencies are not supported.

Note:
If you have specified PLEXNOTD=YES in your ZEKExx PARMLIB options

member to enable enhanced NOTDURING JOB processing, then a DispSel value
of N is ignored for NOTDURING dependency support.
Tape drive prerequisites specified in the EMR are ignored.
An auto reply defined for one initiator is valid for all initiators.
The ZMAP command does not show initiator names.
The ZDISPLAY AVAILABLE command is not valid.
The INITIATOR parameter of the ZHOLD, ZRELEASE, ZALTER, and

ZDISPLAY operator commands is not valid.
259
This flowchart illustrates the process that occurs before an event is dispatched to an
initiator, where DispSel is set to N.
Figure 1 Zeke Initiator Selection Process (DispSel is No)
DispSel=N
Y
Was a class
specified in
the EMR?
Was a value
specified for
DefDspCl?
Make no changes
to the job card
Put the DefDspCl

value on the job card
Put the first class

specified on the
job card
Submit the job

to JES
When DispSel is Yes

If the DispSel generation option is set to Y, Zeke checks the jobs EMR for a class list. (A
job event can have up to six classes.)
If one or more classes is specified, Zeke selects a free initiator that has been defined to
Zeke and can process one of the specified classes. If no classes are specified on the EMR,
Zeke selects any free initiator defined in the Zeke database.
Then, Zeke adds or changes the class parameter on the job card to reflect the selected
class based on these criteria:
260
If no class list is supplied, Zeke updates the job card with the highest priority class
defined to the initiator and submits the job.
6 Resources
If there is a class list, Zeke checks the value of the generation option UserCls:
If UserCls is set to Y, Zeke updates the job card with the EMR class that caused
the initiator to be selected and submits the job.
If UserCls is set to N, Zeke updates the job card with the highest priority class
defined to the initiator and submits the job.
This flowchart illustrates the process that occurs before an event is dispatched to an
initiator when DispSel is set to Y:
Figure 2 Zeke Initiator Selection Process (DispSel is Yes)
DispSel=Y
Was a
class
specified
in the
EMR?
Waits until a Zeke-defined initiator that

processes the specified class is available.
Initiator class preference is determined
by the order in which the resources
are defined in the EMR.
Waits until a
Zeke-defined
initiator is available
UserCls=Y?
The highest priority class

processed by the selected initiator
is inserted on the job card;
the job can run in any available initiator
that can run that particular class.
The class in the EMR

that causes the initiator
to be selected is inserted
on the job card.
Submit the job

to JES
261
Defining Job Class Exceptions

If you want to configure Zeke to select initiators generally (Zeke generation option
DispSel is set to Y), you also can define up to 36 job classes to be treated as exceptions
(as if DispSel were set to N). See Specifying Job Class Capacity Limits on page 265 for
details.
Setting Dispatching Options

The first step in setting up Zeke initiator processing is to set the generation options that
control dispatching. See Dispatching Options on page 297 for more information.
Defining Initiators to Zeke

After the dispatching options have been set, the next step is to define all the initiators for
each operating system running Zeke. ASG recommends that you define every initiator
and specify the times the initiator is available. If an initiator normally is not used by Zeke,
specify a time range of 00:00 to 00:00 hours. This setting gives the operator the ability to
alter (by operator command) the initiator information and enable the system to use the
initiator on demand.
ASG also recommends that when you define the initiators to JES, you make the first class
of each initiator unique. This setting ensures that jobs will run in the Zeke-selected
initiators, because when Zeke selects the initiator, it inserts the highest priority class for
that initiator in the job card, depending on the UserCls generation option. (See the
flowchart on page 261.)
To define initiators
1
From the Zeke Primary Menu, enter 4.3 and press Enter. The System
Initiator/Partition Directory is displayed:
ASG-Zeke
Command ===>
System ===>
System Initiator/Partition Directory
System type ===>
("MVS", "VSE" or "VSE/ESA")
Primary Commands: ADD BROWSE COPY DELETE EDIT

Line Commands: B - Browse C - Copy D - Delete
System
JES/POWER ID
System Type
Row 1 to 7 of 7
Scroll ===> PAGE
E - Edit
Description
_ ********
MVS
_ *GLOBAL
MVS
GLOBAL JOB CLASS CAP
_ LZ56
MVS
_ PLEX55
MVS
_ QA27
MVS
_ SM27
MVS
_ 55QA
MVS
******************************* Bottom of data ****************************
262
6 Resources
Desired Result
Action
Add a new system and

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
PARMLIB options member.
3 Enter MVS in the System Type field to indicate the
operating system.
Edit initiator information

for an existing system
Enter E to the left of the system that you want to update.
Press Enter. The System Initiator Specification screen is displayed:

ASG-Zeke
Command ===>
System Initiator Specification
EDIT
Scroll ==> PAGE
Zeke System: ********

JES System ID:
System type: MVS

Description:
Primary command: ADD BROWSE CANCEL CAPACITY COPY DELETE EDIT

Line commands: B - Browse initiator detail
E - Edit initiator detail
D - DELETE A LINE
R - REPEAT A LINE
I - INSERT A LINE
_
_
_
_
_
_
_
_
_
_
_
_
Initid
A
T004
T03
T2
1
2
B
C
D
E
F
G
MTWTFSS
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
Desired Result
Action
Add an initiator
In the Initid field, enter the ID to be assigned to the initiator. Use

the same name as when it was defined to JES. Press Enter.
To add availability detail for the initiator, enter E to the left of
the initiator.
263
Desired Result
Action
Edit existing initiator

information
Enter E to the left of the initiator that you want to update.
Copy an initiator record
Enter R to the left of the initiator that you want to copy.
Delete a single initiator
Enter D to the left of the initiator that you want to delete, and
press Enter. The initiator is deleted for this system.
Go to step .
Delete system name and

all initiator
specifications
1 Enter DELETE on the Command line, and press Enter.

2 Re-enter DELETE on the Command line, and press Enter
to confirm.
Go to step .
Press Enter. The System Initiator Detail screen is displayed:

ASG-Zeke
COMMAND ===>
System Initiator Detail
System Id : EDMVS
Initiator Id:
EDIT
A1
Primary commands: BROWSE CANCEL EDIT

Start
Monday
Tuesday
Wednesday
Thursday
Friday
Saturday
Sunday
time
time
time
time
time
time
time
End
Start
End
Start
End
Start
End
ranges:
ranges:
ranges:
ranges:
ranges:
ranges:
ranges:
To restrict the time of day the initiator is available to Zeke, enter the hours of
availability in the Start and End fields for each day. Press Enter.
For example, if the initiator is available 24 hours a day on Monday through
Saturday, but on Sunday it is available only from 7:00 A.M. to 6:00 P.M., in the
first Start field next to Sunday time ranges, enter 07:00. In the first End field,
enter 18:00.
A time range of 00:00 to 00:00 makes the initiator unavailable all day. However,
an operator can still make use of the initiator on-demand by using Zeke operator
commands.
If you do not enter a range for a day, Zeke assumes the initiator is available 24
hours that day.
264
6 Resources
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 IBMs 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 jobs execution class is for a WLM-managed
initiator, then WLM cannot start an initiator until the job has been submitted to JES.
Consequently, Zeke does not submit the job because there are no initiators, and WLM
does not start more initiators because there is no pending work in the JES queues.
Creating job class exceptions enables Zeke-controlled jobs to be submitted to JES
without having to wait for an available initiator (even if initiators are managed by WLM).
Job class exceptions also are useful if you simply want to limit the number of jobs that
Zeke can submit for a particular class of initiators. When you set a job class limit, Zeke
submits the job to JES according to the capacity limit and does not consider whether an
initiator is available. Because JES (along with WLM, if used) assumes control over job
scheduling after the job reaches the JES input queue, setting job capacity limits helps you
manage the order of job execution by controlling when a job is placed into the JES queue.
Controlling the number of Zeke-submitted jobs that are in the JES queue at the same time
(instead of allowing Zeke to send an unlimited number) will increase the potential for the
jobs to be executed in closer accordance with your Zeke-defined dispatching priorities.
265
To specify job class capacities for all defined resources for a system
1
From the Zeke Primary Menu, enter 4.3 and press Enter. The System
Initiator/Partition Directory is displayed:
ASG-Zeke
Command ===>
System ===>
System Initiator/Partition Directory
System type ===>
("MVS", "VSE" or "VSE/ESA")

System
JES/POWER ID
System Type
Row 1 to 7 of 7
Scroll ===> PAGE
E - Edit
Description
_ ********
MVS
_ *GLOBAL
MVS
GLOBAL JOB CLASS CAP
_ LZ56
MVS
_ PLEX55
MVS
_ QA27
MVS
_ SM27
MVS
_ 55QA
MVS
******************************* Bottom of data ****************************
You can specify job class limits for the resources defined for all of these:
A particular, named local system.
All local systems that are not defined explicitly (********).
Resources shared by all systems (*GLOBAL).
Note:
If you define an identically named job class for the *GLOBAL system (as well as the
local system), Zeke uses the capacity specified in the local system definition.
266
6 Resources
Enter E to the left of the system for which you want to define job class capacity
limits. The System Initiator Specification screen is displayed:
ASG-Zeke
Command ===>
System Initiator Specification
EDIT
Scroll ==> PAGE

JES System ID:
System type: MVS

Description:
Primary command: ADD BROWSE CANCEL CAPACITY COPY EDIT DELETE (All initiators)
Line commands: B - Browse initiator detail
E - Edit initiator detail
D - DELETE A LINE
R - REPEAT A LINE
I - INSERT A LINE
Initid
A
T004
T03
T2
1
2
B
C
D
E
F
G
_
_
_
_
_
_
_
_
_
_
_
_
MTWTFSS
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
At the Command line, enter CAP. The Job Class Capacity screen is displayed:
ASG-Zeke
Command ===>
Job Class Capacity

JES System ID:
EDIT
System type: MVS

Description:
Primary commands: BROWSE CANCEL EDIT

Class
----A
G
Max
--NO
99
Class
----B
H
Max
--9
999
Class
----C
I
Max
--99
NO
Class
----D
J
Max
--999
9
Class
----E
K
Max
--NO
99
Class
----F
L
Max
--9
999
Enter up to 36 job classes on the six available lines:

Field
Description
Class
Job class ID. The valid values range from A through Z, and 0 through 9.
Max
Maximum number of jobs that Zeke can submit for this initiator class. Zeke
will submit jobs to JES according to this capacity limit without considering
whether an initiator is available. The valid values are NO (i.e., unlimited),
or range from 0 through 999.
267
Press Enter to update the data.
At the Command line on any screen, issue the command ZRELOAD INIT to reload
the updated information. See the ASG-Zeke Scheduling for z/OS Reference Guide for
additional information on using the ZRELOAD operator command.
WLM Scheduling Environments

You can define Zeke as a resource in a WLM scheduling environment. This resource is
used to indicate whether Zeke is active (on) or inactive (off) on a system to ensure
Zeke-submitted jobs run only on MVS systems where Zeke is running:
After Zeke loads the schedule tables, the resource is set to ON.
When you terminate Zeke COLD or TRACK (or if the Zeke address space
terminates abnormally), the resource is set to OFF.
When you terminate Zeke WARM, the resource remains ON.
See the ASG-Zeke Scheduling for z/OS Installation Guide for instructions on how to
define Zeke as a WLM resource.
Defining Pools
Every job is owned by a system sharing the Zeke database or by a pool. A pool is a
user-defined group of systems identified to Zeke. If you have a group of systems that you
want to treat as a unit, you can group them in a pool. For example, if you have multiple
systems used only for testing, you can define them as a pool; then, when you assign an
event to that pool, it will run on one of your test systems.
On the EMR, the System field specifies the owning system or pool to which the job
belongs. The system name corresponds to the NAME parameter of the OASISxx
PARMLIB options member (i.e., if you are not using a pool ID). If you do not specify an
owning system, then the default of system A is used.
268
6 Resources
To define and maintain a system pool

1
From the Zeke Primary Menu, enter 4.5 and press Enter. The System Pool
Directory is displayed:
ASG-Zeke
Command ===>
System Pool Directory
Row 1 to 1 of 1
Scroll ===> PAGE
Pool id ===> POOL1

Line Commands: B - Browse C -Copy D - Delete
E - Edit
Pool ID
Description
**************************************************************************
POOL1
TEST POOL
MAIN
PROD1 POOL
***************************** Bottom of data ******************************
Desired Result
Action
Add a new pool

2 Enter the name of the new system in the Pool ID field.
Note:
Do not use any Zeke operands, parameters, or keywords (or
abbreviations of these) to name your systems or pools. For example,
do not name a system or pool AB (which is short for the parameter
ABEND).
Edit an existing
pool
Enter E to the left of the pool that you want to update, and press
Enter.
Delete a pool
1 Enter D to the left of the pool that you want to delete, and press
Enter.
2 Enter DELETE on the Command line, and press Enter to
confirm.
Go to step 6 on page 270.
269
Press Enter. The System Pool Specification screen is displayed:

ASG-Zeke
Command ===>
Pool ID:
System Pool Specification
EDIT
Scroll ==> PAGE
POOL1
Desc: TEST POOL
Primary command: ADD BROWSE CANCEL COPY DELETE EDIT

Line commands: D - Delete a line
I - Insert a line
R - Repeat a line
SYSTEM
TSO45
Desired Result
Action
Add a system to a
new pool
In the System field, enter a name for the new system name.
You can enter up to 15 systems on one screen. To add more than 15
systems, press F8 to view additional blank entry lines.
Note:
Do not use any Zeke operands, parameters, or keywords (or
abbreviations of these) to name your systems or pools. For example,
do not name a system or pool AB (which is short for the parameter
ABEND).
Add a system to an
existing pool
1 Enter I in the unlabeled selection field next to a system name,

press Enter. A blank line is added.
2 Enter the new system name on the blank line.
270
Edit an existing
system
Complete the changes to the system that you want to update.
Delete a system
from a pool
Enter D to the left of the system name, and press Enter.
Press Enter to update the pool record.
Re-cycle Zeke for the changes to take effect.
6 Resources
Logical Resources
Logical resources are user-defined and represent the use of a physical resource. The
difference between a logical resource and a physical resource is that the logical resource
does not really have to exist.
You can use logical resources for events that, if executed simultaneously, could cause
contention among your system resources. You can think of logical resources as a more
versatile and sophisticated NOTDURING dependency.
A logical resource can be anything that you want to define to represent the use of a
physical resource (e.g., an entire CPU, a specific CPU channel, a file, or a dataset).
For example, lets suppose that a file is used by six different jobs. Jobs 1 through 5 use
this file in Read mode, while job 6 backs up the file. This situation causes dataset
contention when job 6 is running with any of the other five jobs. To avoid dataset
contention, you can use logical resources to ensure that job 6 runs alone. You define a
resource to represent the file and give job 6 exclusive access to the resource.
To define a logical resource, you must specify this information:
A quantitative figure to let Zeke know how much of a resource is available at any
one time.
The systems where the resource is active.
For each job that uses this resource, you then can specify the resource name and the
amount used of the required resource on the EMR.
Prior to dispatch, Zeke ensures the required resource is available in the quantity specified.
For example, lets suppose that a resource is defined with a value of 1. Job A needs 1 of
this resource before it can run. If Job B is running and using this resource, the resource is
not available, and Job A will have to wait for Job B to free the resource.
Note:
If DispSel is set to N, Zeke resolves only the resources defined as GLOBAL (i.e., any
system can share the resource).
271
Defining a Logical Resource

This section describes how to define resources to the Zeke database. The resource
definition specifies where each resource exists and how many are available.
To define a logical resource

1
From the Zeke Primary Menu, enter 4.6 and press Enter. The Resource
Specification screen is displayed:
ASG-Zeke
Command ===>
Resource Specification
Row 1 to 1 of 1
Scroll ===> PAGE
Resource name ===>

System ===>
Line Commands: C - Copy D - Delete
Primary Commands: ADD COPY DELETE
Resource name
Maximum Active?
Shared
EDR2
MEDA
00001
YES
EDR2
TSO45
00001
YES
EDR3
(GLOBAL)
00001
YES
INIT1
(GLOBAL)
00005
YES
TAPE
(GLOBAL)
09901
YES
TAPEDRIVE
HLPDESK
00001
YES
***************************** Bottom of data ******************************
System
Perform the steps outlined in the Action column (depending on the desired result):
Desired Result
Action
Define a resource to the

Zeke database

2 Enter the resource name in the Resource Name field, and
press Enter.
Caution! Do not use spaces in the resource name.

Edit an existing resource
To update Maximum Shared or Active, type over the existing

information, and press Enter.
Copy an existing resource

to create a new one
1 Enter COPY on the Command line.

2 Enter the resource name to copy in the Resource Name
field, and press Enter. The Resource Detail screen is
displayed.
3 Enter the new name in the Resource Name field, and press
Enter.
272
6 Resources
Desired Result
Action
Delete a resource from the

Zeke database
1 Enter DELETE on the Command line.

2 Enter the resource name to delete in the Resource Name
field, and press Enter. The Resource Detail screen is
displayed.
Caution! Before deleting a resource, ensure that no Zeke

events reference the resource to be deleted. An
event that attempts to acquire a deleted resource
is not dispatched.
The Resource Detail screen is displayed:

ASG-Zeke
Command ===>
Resource Detail
Resource name:
Scroll ===> PAGE

INIT1
Primary commands: ADD CANCEL COPY DELETE EDIT

System: (GLOBAL)
Max share count: 00005
Active?: YES
In the System field, enter the name of the system that owns the resource. You can
specify a resource multiple times with different system names. The default value is
GLOBAL (i.e., any system can share the resource). If the jobs system name is
assigned to a pool, keep the default value to ensure proper dispatching.
4
In the Max Share Count field, enter the number identifying the resource amount.
This value can be any number that quantifies the resources availability.
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.
When you have finished adding or updating information on the Resource Detail
screen, press Enter to save the changes.
273
Defining Resources for an Event

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

1
Access the EMR for the event, or the Event Master Directory, as described in,
From the Event Master Directory, enter E4 to the left of the event number for the
event to which you want to assign a resource.
Or
From the EMR, enter RESOURCE on the Command line.

3
Press Enter. The Resource Control screen is displayed:

ASG-Zeke
Command ===>
Resource Control
EDIT
Scroll ===> PAGE
Primary Commands: BROWSE DELETE EDIT

Job: TSKKGUT2 Evt Name: KTEST2
System: ZEQA
Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S)

--------------Resource Name----------------- Cnt --CodesMd H E A
==========================================================================
INIT1
001 SR N R N
274
If the job has no resources defined, simply enter the name of the resource in the
Resource Name field.
If the job already has one or more resources defined, 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.
Enter the name of the new resource in the Resource Name field of the new line.
6 Resources
In the Cnt field, specify a number to represent how much of this resource is used
when this job runs.
Note:
If mode is EX or ES, this value must be 001.

7
In the Md field, specify the resource mode required by the job. These are the valid
codes:
Code
Meaning
EX
Allow only one event to access to resource in Write mode

For example, lets 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, lets 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:
Define Jobs A and B with a mode of ES and a count of 1.
Define the other jobs with a mode of SR and a count of 1.
Note:
Exclusive-share events cannot run with other exclusive-share events, but they
can run with multiple share events.
275
Code
Meaning
SR
Allow multiple events to access this event

For example, three jobs execute nightly at around the same time (which causes
performance problems).
You could avoid contention (in this example) by taking these steps:
Set up 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.
In the H field, specify whether resources should be held. These are the valid codes:
Code
Meaning
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.
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.
276
In the E field, specify whether resources should be released at AEOJ. These are the
valid codes:
Code
Meaning
Keep resource at AEOJ if the job abends. The resource mode must be EX or ES,
and can be obtained by a restart/rerun.
Default. Do not hold the resource; release the resource if the job abends.
6 Resources
10
In the A field, specify whether to use the resource for a restart. These are the valid
codes:
Code
Meaning
Use resource for a restart. The event tries again to obtain the resource from an
abended event that has specified its Reskeep value set to Y.
Note:
The resource mode must be EX or ES and can be obtained by a rerun/restart.
11
Do not use resource for a restart.
The event assumes the resource only from itself (if the event abends).
Deleting Resources for an Event

You can delete one or more resources for an event.
To delete one or more resources for an event

1
Access the EMR or the Event Master Directory, as described in, Accessing the
Event Definition on page 58.
From the Event Record Directory screen, enter E4 to the left of the Event Number
field for the event for which you want to delete a resource, and press Enter.
Or
From the EMR, type RESOURCE on the Command line, and press Enter.
The Resource Control screen is displayed:
ASG-Zeke
Command ===>
Resource Control
EDIT
Scroll ===> PAGE
Primary Commands: BROWSE DELETE EDIT

Job: TSKKGUT2 Evt Name: KTEST2
System: ZEQA
Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S)

--------------Resource Name----------------- Cnt --CodesMd H E A
==========================================================================
INIT1
001 SR N R N
EDTR2
002 SR N R N
277
To delete one or more specific resources, enter d in the line command field to the left
of the resource names that you want to delete, and press Enter.
Or
To delete the entire resource record for the job, enter DEL on the Command line,
and press Enter. Press Enter again to confirm.
All resources for the event are deleted.
278
Customizing and Maintaining Zeke
Chapter 7:
7
Zeke provides you with a great amount of flexibility and control over Zeke operations
including event scheduling and dispatching, as well as maintenance and database access.
Topic
Page
Zeke Generation Options

GENOPTs
Accessing the Zeke Generation Options
Adding a GENOPT
Editing a GENOPT
Viewing Pending GENOPT Updates
Deleting a GENOPT
Reloading GENOPTS
Audit Options
Dispatching Options
Exit Options
General Options
JCL Options
Message Options
Scheduling Options
Security Options
Trace Options
User Interface Options
Variables Options
280
280
281
287
290
291
293
295
296
297
309
309
312
319
320
324
325
325
326
Defining Schedule Download Agents
327
Obtaining Operating Passwords
329
Creating the Zeke Databases (Primary and Vault)
Backing Up the Zeke Database
Restoring the Zeke Database
Moving the Vault Database
Recovery Using Electronic Vaulting
330
331
333
334
337
338
279
Topic
Page
Continuous Job Tracking

Terminating Zeke using ZKILL TRACK
SMF Recording Mode
Applying Maintenance
SMF Playback
340
341
341
344
344
Zeke Generation Options

Generation options enable you to configure the operating criteria for your environment.
No two data centers are exactly the same, and, typically, no two systems are identical
within an environment. Zeke enables you to configure separate systems with different
generation options for each one.
During Zeke installation, the generation options are set to default values that are suitable
for most data centers. ASG recommends that you review the options immediately after
you install Zeke and make any modifications. With gained experience using Zeke, you
might choose later to change these settings options to better address your needs.
Because they affect your entire site, ASG recommends that the personnel responsible for
system programming, scheduling, data security, and site standards all review and agree
on your generation option settings.
There are over 250 generation options. This chapter discusses in greater detail the options
that are most commonly used and modified. See the ASG-Zeke Scheduling for z/OS
Reference Guide for an alphabetical listing and explanations of all options.
GENOPTs
A collection of generation options is referred to as a GENOPT table or GENOPT. You
can use GENOPTs to group together specific generation option settings that control a
particular system or that you want to be used across multiple systems. You can create
new GENOPTs, or Zeke provides default GENOPTs that you can customize or copy.
These are the types of GENOPTs:
280
Type
Name
Description
Special
*ACTIVE
Contains all options loaded in memory and currently active (i.e.,

both global and local options) for the local Zeke system. This
GENOPT is generated automatically and is for reference only;
you cannot modify or delete it.
7 Customizing and Maintaining Zeke
Type
Name
Description
Global
*GLOBAL
Contains options that require the same setting across all Zeke
systems in the Zekeplex (i.e., that share the same database).
The global GENOPT *GLOBAL is created during Zeke
installation and can be customized. You cannot rename, copy or
delete it.
When you start Zeke or reload the GENOPTs on request (see
Reloading GENOPTS on page 295), Zeke loads this
GENOPT along with the local GENOPT for the system being
initialized.
Local
********
Contains options that control a local Zeke system.
or
You can define a different local GENOPT for each Zeke system
in the Zekeplex. The GENOPT name must match the name of
user-defined
the system ID for Zeke to associate them.
The default local GENOPT (********) contains the default
option settings for local Zeke systems and can be customized
and copied. You cannot rename or delete it.
When you start Zeke or reload the GENOPTs on request (see
Reloading GENOPTS on page 295), Zeke loads the local
GENOPT for the system being initialized along with the
*GLOBAL GENOPT. If no local GENOPT is found that
matches the system ID, Zeke loads the default GENOPT
(********).
Note:
If you customize the default local GENOPT (********), the
updated settings are used when you add a new GENOPT
(which then can be customized).
Accessing the Zeke Generation Options

This procedure explains how to access the GENOPTs Directory (which contains a listing
of all default and user-defined GENOPT tables in the Zeke database) using the ISPF
online facility. From this directory, you can add, browse, copy, edit, or delete GENOPTs.
To access the GENOPTs Directory
Enter =4.1 on any Command line, and press Enter.
281
The GENOPTs Directory screen displays a listing of all GENOPTs in the Zeke
database:
ASG-Zeke
Command ===>
GENOPTs Directory
Row 1 to 4 of 4
Scroll ===> CSR
Zeke System:
Primary Commands: ADD BROWSE CONFIRM COPY DELETE EDIT PENDING
Line Commands: B - Browse C - Copy D - Delete E - Edit
System
* Description
Last updated by
- -------- - -------------------------------- ---------------------------*ACTIVE
In-memory values (ZEKE60A )
*ZEKEUP* 01/10/2012 13:21:28
*GLOBAL
Zekeplex global options
ZEKEUSER 12/05/2011 19:14:48
ZEKE60A * Zeke 6.0 component on SYSA
ZEK60JOB 11/29/2011 15:53:54
********
Default local system options
*DBCNVT* 11/10/2011 13:05:28
******************************* Bottom of data *******************************
The listing displays this information for each GENOPT:
GENOPT name (which, for local GENOPTs, matches the system ID).
Optional, user-defined descriptions for each local GENOPT, and the default
local and global GENOPTs. (The description for the *ACTIVE GENOPT is
static and references the name of the currently active GENOPT.)
In addition to being displayed online, this description is also displayed when
you request a GENOPT details for a batch report or ZDISPLAY output. (See
the ASG-Zeke Scheduling for z/OS Reference Guide for more information.)
Date and time that the local or global GENOPT was last updated, and the user
ID or batch jobname that made the update; or, the date and time that the
*ACTIVE GENOPT was last reloaded, and the user ID or batch jobname that
reloaded it.This information also helps indicate whether a GENOPT was last
reloaded automatically as result of a Zeke startup, or as a result of a database
CREATE or RESTORE.
An asterisk (*) in the second column indicates whether this local GENOPT is
the one that is currently active.
From this screen, you can add, browse, copy, edit, and delete GENOPTs using the
primary and line commands, as well as set controls for monitoring any changes that
are made to a GENOPT.
282
Viewing GENOPT Details

A detailed view of each GENOPT displays the current setting of each generation option
field. The fields are listed alphabetically by default. The CATEGORY primary command
enables you to sort and view the display by functional categories.
If you sort the display by category, these are the predefined categories under which the
generation option fields are organized:
Category
Description
Audit
Audit options.
Dispatching
Options that affect event dispatching.
Exits
Options that affect Zeke and operating system exits.
General
All options that do not fall under another category.
JCL
Options related to JCL sources and processing.
Messages
Options that control the issuing of messages.
Scheduling
Options that affect event scheduling.
Security
Options that control security.
Traces
Data space trace options.
User interfaces
Options that affect the ISPF and online facilities.
Variables
Options related to Zeke variables.
To access a detailed GENOPT view

1
Follow the procedure in Accessing the Zeke Generation Options on page 281.
Enter B in the selection field to the left of the GENOPT you want to browse.
Or
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.)
Enter BROWSE on the Command line, and press Enter.
283
The Generation Options screen displays (in browse mode) the options and settings
for the selected GENOPT. This is an example of the default (alphabetical) detail
view:
ASG-Zeke
Command ===>
Generation Options
Description:
Option
--------Aur:
AurIntv:
AurMsg:
BimAppl:
BimPasw:
BimUid:
CalcMem:
CalcTap:
ChgVal:
CmdCons:
CondrDv:
CondrLb:
CondrVer:
DispDly:
DispSel:
Value
---------Y
1
Y
OMIT
Y
Y
Y
Y
SYS000
OMIT
001
30
Y
DSPBatch: N
BROWSE
Row 1 to 17 of 141
Scroll ===> CSR
(active)
Description
--------------------------------------------------------(Y,N)
Yes to enable automatic responses
(1-99)
Number of seconds to check auto responses
(Y,N)
Yes to inform operator auto. response issues
(xxxxxxxx) Bimedit application name
(xxxxxx)
Bimedit access password
(xxxx)
Bimedit access userid
(Y,N)
Yes to calculate virtual memory
(Y,N)
Yes to calculate tape drive usage
(Y,N)
Yes to display Variable update message
(Y,N)
Yes to route command response to console
(xxxxxx)
Condor camlib device name
(xxxx)
Condor camlib qualifier
(xxx)
Condor version id
(nnnnn)
Seconds to delay dispatching pooled events
(Y,N)
Yes for Zeke to select initiators
(Yes is ignored for JES3)
(Y,N)
Yes to use a dataspace for ZEKE batch program
If this is the currently active GENOPT, (active) is displayed to the right of the
Description.
3
Optional. You can change the way the options are sorted. Enter this command on the
Command line to toggle between a category view and the default (alphabetical)
view:
CATegory [ON|OFF]
For example, enter CAT ON.
284
This is an example of the detail view by category for the same GENOPT:
ASG-Zeke
Command ===>
Generation Options
Zeke System: JCRZEKEA
Description:
BROWSE
Row 1 to 17 of 152
Scroll ===> CSR
Option
Value
--------- ---------====================
====================
Aur: Y
AurIntv: 1
CalcMem: Y
CalcTap: Y
DispDly: 30
DispSel: Y
Description
--------------------------------------------------------Audit ===================================================
Dispatching =============================================
(Y,N)
(1-99)
(Y,N)
(Y,N)
(nnnnn)
(Y,N)
Idcams: N
(Y,N)
Yes to replace occurences of IDCAMS
IgnCat2: N
(Y,N)
Yes to ignore NOT-CAT2 messages
PauseEoj: N
(Y,N)
Yes to pause partition at FAIL
ScomMax: 1
(nn)
Maximum subtasks for SCOMs
ScomWt: 5
(nn)
Maximum minutes before SCOM timeout
TapeIO: 100
(nnn)
Number of tape I/Os before Zeke calculates
==================== Exits ===================================================
DynSmf: Y
(Y,N)
Yes to dynamically install SMF exit
In a detailed view by category, the categories are listed alphabetically and the
applicable fields are listed alphabetically under each category. All category
headings are displayed, even if there are no fields in that category associated with
the selected GENOPT.
Note:
Based on the definition of the GENOPT (i.e., local or global, some options might
not be applicable.
4
Scroll through the pages on the Generation Options screen and review the options.
Or
To quickly find a particular field or category, you can use these primary commands:
Command
Description
FIND
Finds and moves the cursor to the beginning of the specified text string
in field names, values, descriptions, and category headings. This is the
command format:
FIND string
For example, this command finds and places the cursor at the
generation option field named Jcl1:
FIND JCL
285
Command
Description
LOCATE
Locates the first line that begins with the specified text string and
scrolls to the associated field. This is the command format:
LOCATE string
When fields are displayed alphabetically, this command scrolls to the

first field that contains the string. When the fields are sorted by
category, this command scrolls to the first category name that contains
the string.
For example, this command scrolls to the JclBrows option field if the
fields are listed alphabetically:
LOCATE JCL
The same command scrolls to the JCL category if the fields are sorted
by category.
Note:
You cannot use the LOCATE command to scroll to subsequent lines
that begin with the string; the command locates only the first line.
Finds and highlights the next occurrence of the text string specified on
the last FIND string command. This is the command format:
RFIND
RFIND
For example, this is the result when you issue the command FIND DISP:
ASG-Zeke
Command ===>
Generation Options
Zeke System: KACZ600A
Description: Adding a GENOPT Proc Test
Option
--------Aur:
AurIntv:
AurMsg:
BimAppl:
BimPasw:
BimUid:
CalcMem:
CalcTap:
ChgVal:
286
Value
---------Y
1
Y
OMIT
Y
N
Y
EDIT
Found 'DISP'
Scroll ===> CSR
Description
--------------------------------------------------------(Y,N)
(1-99)
(Y,N)
(xxxxxx)
(xxxx)
(Y,N)
(Y,N)
(Y,N)
This is the result when you issue the command FIND DISP when the screen is in
category mode (i.e., CAT ON):
ASG-Zeke
Command ===>
Generation Options
Option
Value
--------- ---------====================
Aur: Y
EDIT
Row 2 to 18 of 152
Scroll ===> CSR
Description
--------------------------------------------------------Dispatching =============================================
(Y,N)
This is the result when you issue the command LOCATE DISP:
ASG-Zeke
Command ===>
Generation Options
EDIT
Row 14 to 30 of 141
Scroll ===> CSR
Option
Value
Description
--------- ---------- --------------------------------------------------------DispDly: 30
(nnnnn)
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.
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
Enter B or E in the selection field to the left of the default local GENOPT
(********). The Generation Options screen displays its options and settings. Skip
to step 3 on page 288.
Or
287
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.
In the Description field, type a description for the GENOPT (up to 32

characters long).
Enter ADD on the Command line, and press Enter.

A new GENOPT is created based on the settings in the default local GENOPT
(********).
ASG-Zeke
Command ===>
Generation Options
Zeke System:
Description:
Option
--------Aur:
AurIntv:
AurMsg:
BimAppl:
BimPasw:
BimUid:
CalcMem:
CalcTap:
ChgVal:
CmdCons:
CondrDv:
CondrLb:
CondrVer:
DispDly:
DispSel:
Value
---------Y
1
Y
OMIT
Y
Y
Y
Y
SYS000
OMIT
001
30
Y
DSPBatch: N
ADD
Initial values loaded

Scroll ===> CSR
Description
--------------------------------------------------------(Y,N)
(1-99)
(Y,N)
(xxxxxx)
(xxxx)
(Y,N)
(Y,N)
(Y,N)
(Y,N)
Yes to route command response to console
(xxxxxx)
(xxxx)
(xxx)
Condor version id
(nnnnn)
(Y,N)
(Y,N)
If you did not already do this from the directory (in step 2 on page 287), enter the
GENOPT name (which must match the system ID for the associated Zeke system)
in the Zeke System field.
Optional. Enter a description (up to 32 characters long) of the GENOPT in the

Description field.
Make any necessary changes to the option settings.
Note:
By default, the options are listed alphabetically. You also can list the options by
category. To change the way the options are sorted, see step 3 on page 284, or to
quickly locate an option or category, see step on page 285.
288
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
Enter C in the selection field to the left of the GENOPT that you want to copy. Skip
to step 3.
Or
In the System field, type the name of the GENOPT that you want to copy. (The
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.
Optional. In the Description field, type a description for the GENOPT (up to 32
characters long) or replace the existing value.
Make any necessary changes to the option settings.
Note:
By default, the options are listed alphabetically. To change the way the options are
sorted, see step 3 on page 284, or to quickly locate an option or category, see step
on page 285.
289
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
Enter E in the selection field to the left of the GENOPT that you want to edit. Skip
to step 3.
Or
In the System field, type the name of the GENOPT that you want to edit. (The
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
Note:
By default, the options are listed alphabetically. To change the way the options are
sorted, see step 3 on page 284, or to quickly locate an option or category, see step
on page 285.
290
Make any necessary changes to the option settings. You also can update the System
name and/or Description by typing over the existing values.
Enter SAVE on the Command line to save the updated GENOPT and remain on the
screen in edit mode, or enter END to save the GENOPT and return to the GENOPTs
Directory.
Note:
You can enter CANCEL to cancel the changes the GENOPT, if necessary.
Press Enter. The GENOPT is updated in the Zeke database.
If you updated the currently active GENOPT, a pop-up panel displays the options
that were changed, the new values, and the action required to activate each updated
option:
ASG-Zeke
Generation Options
EDIT
+---------------- ASG-Zeke Generation Options ----------------+
|
Pending GENOPT Changes
Row 1 to 6 of 6 |
| Command ===> ______________________________________________ |
|
|
| You have made changes to the active GENOPT, ********.
|
|
|
| No options require Zeke to be recycled COLD.
|
|
4 options require Zeke to be recycled TRACK.
|
|
2 options can be activated with ZRELOAD GENOPT.
|
|
_ Issue the ZRELOAD command
|
|
|
| Option
Action
New value
|
| ---------- ------- -------------------------------------- |
| Aur
TRACK
N
|
| BatSec
ZRELOAD N
|
| PbTrack
TRACK
Y
|
| Posid
TRACK
Y
|
+-------------------------------------------------------------+
Condrdv: SYS000
(xxxxxx)
Condrlb: OMIT
(xxxx)
Condrver: 001
(xxx)
Condor version id
Datasub: Y
(Y or N)
Yes for Zeke to substitute DOS JCL
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
291
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)
DSPBatch: N
(Y,N)
The Pending GENOPT Changes pop-up displays these details:
292
Name of the currently active GENOPT.
Number of updated settings that require Zeke to be re-cycled COLD.
Number of updated settings that require Zeke to be re-cycled TRACK.
Number of updated settings that you can activate by issuing a ZRELOAD

GENOPT command.
Name and new value of each updated option, and the required action to
activate the new setting.
Optional. To issue the ZRELOAD GENOPT command at this point, enter any
nonblank character in the Issue the ZRELOAD command field or enter the
ZRELOAD GENOPT command on the Command line. This command requires the
Deleting a GENOPT
You can delete any GENOPT except the special ones (i.e., ********, *GLOBAL, and
*ACTIVE).
To delete a GENOPT
1
Follow the procedure in Viewing GENOPT Details on page 283. The Generation
Options screen displays the options and settings for the selected GENOPT. Skip to
step 3b.
Or
Follow the procedure Accessing the Zeke Generation Options on page 281.
2
Enter D in the selection field to the left of the GENOPT that you want to delete.
Or
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.
Enter DELETE on the Command line, and press Enter.
If a confirmation pop-up displays the name of the GENOPT to be deleted, follow the
instructions to confirm the delete request. (See Setting the Delete Confirmation
Option on page 294 for instructions on how to implement this feature.)
Otherwise:
a
Re-enter DELETE on the Command line, and press Enter to confirm the
delete request and return to the GENOPTs Directory.
Or
Enter CANCEL or EXIT to cancel the delete request.
Note:
If the currently active GENOPT is deleted, the GENOPT is marked with an X (instead
of an *) in the GENOPTs directory and no further changes can be made to the deleted
GENOPT. When a ZRELOAD GENOPT command is issued or Zeke is re-cycled, the
Zeke activates the default local GENOPT (********) in place of the deleted one.
293
Setting the Delete Confirmation Option

For added control, you can set an option that specifies whether to display a confirmation
pop-up when a user attempts to delete a GENOPT.
To implement or cancel delete confirmations

1
Follow the procedure Accessing the Zeke Generation Options on page 281.
From the GENOPTs Directory or from any Generations Options detail view, type
CONFIRM on the Command line, and press Enter.
The CONFIRM primary command toggles between enabling and disabling the pop-ups.
The command enables confirmation pop-ups (if they currently are disabled). Or, if
confirmation pop-ups are enabled already, the CONFIRM command disables them.
When confirmations are enabled, this pop-up displays when you request to delete a
GENOPT:
ASG-Zeke
GENOPTs Directory
Row 15 to 20 of 20
+_________________________ ASG-Zeke __________________________+ ll ===> CSR
|
Confirm Delete
|
| Command ===>
|
|
|
| Delete pending for GENOPT table:
|
| TCOM600Z
|
|
|
|
Set delete confirmation off for GENOPT tables.
|
|
|
| Press ENTER to confirm delete.
|
| Press CANCEL or EXIT to cancel delete.
|
|
|
+_____________________________________________________________+
VJCRVTAM
*DBCNVT* 01/17/2012 14:38:04
********
*DBCNVT* 01/17/2012 14:38:04
******************************* Bottom of data ********************************
See Deleting a GENOPT on page 293 for details on deleting a GENOPT.
294
Reloading GENOPTS
Zeke activates some generation options immediately when you save them, but most
options must be reloaded for each system that is affected by the changes.
Zeke reloads the generation options automatically during each startup. Or, you can reload
the generation options at any time by issuing this command:
ZRELOAD GENOPT [FORCE]
Note:
See the chapter on operator commands in the ASG-Zeke Scheduling for z/OS Reference
Guide for more information on the ZRELOAD command.
For most generation options, the changes take effect immediately; however, some options
do require a Zeke re-cycle (i.e., at least a ZKILL TRACK re-cycle and, in some cases, a
ZKILL COLD re-cycle. A ZKILL WARM re-cycle does not reload the generation
options). The required action for each option is noted in the field-level online help and in
the chapter on generation options in the ASG-Zeke Scheduling for z/OS Reference Guide.
After updating the currently active GENOPT, you have the option to reload the options.
When you save the GENOPT changes, this information is provided:
Name of the GENOPT.
Number of updated settings that require Zeke to be re-cycled COLD.
Number of updated settings that require Zeke to be re-cycled TRACK.
Number of updated settings that you can activate by issuing a ZRELOAD GENOPT
command.
Name and new value of each updated option, and the required action to activate the
new setting.
As an option, you can reload the generation options at this point. This action requires the
You also can review any changes that have been made to the currently active GENOPT,
but have not been activated yet, without actually reloading the changes. See Viewing
Pending GENOPT Updates on page 291 for details.
295
Audit Options
The AUDIT utility (in OASIS) tracks Zeke database activity and logs the information in
an audit log file. You decide what types of activity that you want to audit. These are some
of the actions you can track in an audit log:
Issued Zeke operator commands
Changes to any of these elements:
Events status (e.g. scheduled, active, or EOJ)
Zeke variables
Event definitions
Internal security classes
Calendars
External security classes
Zeke generation options
Your company name or address
Internal security operator records
Passwords
Partition definitions
Pool records
Resource definitions
SQRs
When an audited element is updated, the change is recorded automatically in the audit
log. You can use audit records to generate reports to review the logged updates.
Note:
You must set the XAUDxx option ZEKEADT with the number of Zeke audit logs and
allocate the audit log datasets before any activity is be logged.
Audit options are global generation options that enable the auditing (i.e., by the OASIS
AUDIT utility) of different types of Zeke system activities and record updates (e.g.,
changes to EMRs, SQRs, variables, calendars, generation options, etc.). You enable the
audit option for each type of information that you want to track. Audited activities are
logged in a record in the audit log file.
See the ASG-OASIS for z/OS Reference Guide for more information on setting up and
using the AUDIT utility and on audit reporting.
296
To access the audit options

1
Follow the procedure in Editing a GENOPT on page 290 to access the *GLOBAL
GENOPT, then locate the audit options.
In ISPF, you can use the LOCATE AUD command to locate the first audit option,
or issue CATEGORY ON to sort the display by categories and scroll to the Audit
section.
Review the audit options and their default values.
Update each audit option according to your requirements:

Specify Y to enable auditing for the corresponding function.
Or
Specify N to disable auditing for the corresponding function.

4
You can reload the audit options by re-cycling Zeke using the ZKILL COLD or
ZKILL TRACK operator command. See Reloading GENOPTS on page 295 for
details.
Dispatching Options
Dispatching options are local and global generation options that control Zeke
dispatching.
To access the dispatching options

1
Follow the procedure in Editing a GENOPT on page 290 to access the local or
*GLOBAL GENOPT, then locate the dispatching options.
In ISPF, you can use the LOCATE DISP command to locate the first dispatching
option, or issue CATEGORY ON to sort the display by categories and scroll to the
Dispatching section.
Review the dispatching options and their default values.
Update each dispatching option according to your requirements:

For many options, you enable or disable the option by specifying Y to enable the
corresponding function or N to disable it.
For other options, you might be required to specify a numeric or character value
(e.g., a time, interval, class, disposition, or code), or you can keep the default value.
297
You can reload most dispatching options using the ZRELOAD GENOPT operator
command. See Reloading GENOPTS on page 295 for details.
Note:
These dispatching options require you to re-cycle Zeke using ZKILL TRACK:
Aur
DsclTrig
Flush (VSE only)
Idcams
Scommax (VSE only)
TapeIO
WkTrgdn
WkTrgds
Updating the PausEoj dispatching option requires you to re-cycle Zeke using
ZKILL COLD.
The following sections discuss some of the most important options used to control Zeke
dispatching and also indicate the additional related generation options that might be
required to support a particular dispatching environment or configuration.
These generation options determine how Zeke uses initiators in your system:
Option
Description
ChkSEnv
Indicates whether Zeke performs scheduling environment checking. These are

the valid values:
Y
Default. Zeke checks each event to be scheduled for the value of the
SCHENV field, which indicates the name of the requested scheduling
environment.
For job events targeted for the current system and for all other event
types, Zeke dispatches the event when the scheduling environment is
active.
For job events targeted for a pool, Zeke dispatches the event if the
scheduling environment is active on any system in the pool.
For job events targeted for a remote system, Zeke does not check for
the scheduling environment.
298
Option
Description
See Using Scheduling Environments on page 105 for more information.
Note:
For a job event, this value can be inserted (optionally) in the JCL before the job
is submitted to JES. See JOB Card Override on page 315 for more
information.
N
Zeke does not check the event to see if a particular scheduling

environment is requested.
DefJPrty
Specifies a default job operating system priority (from 0 through 15) to use if a
priority is not entered in the Pri field in the EMR. The default value is 1. If the
priority should be left unchanged, then enter NO.
DefDspCl
Specifies the default dispatch class that is assumed if the class is not entered on
the EMR.
DispDly
Specifies the number of seconds to wait between dispatches of pooled events.

The default value is 30. This field is required if the DispSel generation option
is set to N, but is ignored if the Posid generation option is set to Y.
DispSel
Indicates whether Zeke selects the initiators.

Note:
DispSel is ignored if you are using JES3.
N
Zeke does not select initiators and submits jobs to JES regardless of
initiator availability.
Default. Zeke selects initiators and submits jobs to JES based on initiator
availability.
Generally, if you want to set DispSel to Y, you also can define specific
job classes to be treated as if DispSel is set to N (e.g., if you use
Workload Manager to manager initiators, but you want Zeke to be able to
submit certain job classes to JES without having to wait for initiator
availability).
UserCls
Optional. Indicates whether to use the EMR class for job submission. These are
the valid values:
N
Do not use the EMR class; select initiators using the Zeke class selection
process.
299
Option
Description
Y
Default. Use the class specified in the EMR to submit jobs to the initiator.
Zeke does not change the class at dispatch time. If this option is set to Y
and no classes are defined on the EMR, then Zeke selects initiators using
the regular class selection process.
Dispatching Events and Messages

These generation options are related to dispatching events and issuing related messages:
Option
Description
Note:
In this table, the term priority refers to the Zeke dispatching priority, not the operating system
job priority.
DefDPrty
Specifies a default dispatch priority (from 0 through 99) to use if a dispatch

priority is not entered on the EMR. The default value is 50. This value displays
in the Dprty field on the EMR.
Dispdly
Specifies the number of seconds to wait between dispatches of pooled events.

The default value is 30. This field is required if the DispSel generation option
is set to N, but is ignored if the Posid generation option is set to Y.
Msgwait
Specifies the time interval (in HH:MM format) that Zeke waits between issuing
messages for events waiting in the dispatch queue. The default value is 01:00
(i.e., one hour). This option affects these messages:
Z0601I
Z0602I
Z0611I
Z0615I
Z0617I
Z0618I
Z0628I
Z0631I
Z0634I
Mspintrl
Specifies the time (near dispatch) interval (in HH:MM format) when an event
is given a higher dispatch priority. A job is given a higher dispatch priority if its
must start or not after times are within the interval. The default value is
01:00 (i.e., one hour).
Operok
Indicates whether Zeke is to wait for an operator OK before dispatching any

event. You can override this option for an individual event on the EMR
(OPEROK). These are the valid values:
N
300
Default. Dispatch events without an operator OK
Option
Description
Y
Prilate
Wait for an operator OK; a message is issued when an event is placed in

the dispatch queue
Specifies whether to dispatch late events with a higher dispatch priority. These
are the valid values:
N
Default. Dispatch events in the schedule time sequence (regardless of late

time).
Dispatch late events before other events (regardless of the schedule time).
These are the default dispatching messages that are issued by Zeke:
Z0308I EVENT nnnnnn yyyyddd VER vvvvv RESCHEDULED FOR ...
Z05C18I Event nnnnnn yyyyddd ver vvvvv issued ...
Z05C18I ZEKESET Job jjjjjjjj issued ...
Z0603I nnnnnn yyyyddd ver vvvvv Dispatched Type=...
Z0604I Event nnnnnn yyyyddd ver vvvvv Dispatched Job=...
Z0620I Event nnnnnn yyyyddd ver vvvvv VCOM Dispatch Requested
Z0683I Event nnnnnn yyyyddd ver vvvvv Dispatched Exec=...
where:
nnnnnn is the event number.
yyyyddd is the schedule date.
vvvvv is the version number.
jjjjjjjj is the jobname.
Retaining Events
These generation options are related to retaining events:
Option
Description
CommCtl
Indicates whether to retain work centers in the schedule until they are completed
(EOJ) or disabled. These are the valid values:
N
Discard work centers the next day, regardless of status.
Default. Retain work centers until completed or disabled.
301
Option
Description
If this option is set to N and the Retain field in the EMR is set to Y, then this
option overrides the Retain value the EMR for work centers only.
If this option is set to N and the Retain field in the EMR is set to Y, but the
LoadComm generation option is set to Y, then the work center is retained.
DropSel
Indicates whether to drop completed events from the current schedule when
selection parameters are included with the SCHEDULE ACTIVATE command
for a new schedule run. These are the valid values:
N
The SCHEDULE function drops from the current schedule all completed
events regardless of whether they match the selection parameters
included with the new SCHEDULE ACTIVATE command. This option
prevents completed events from accumulating with the creation of each
new schedule.
Caution! Because incomplete events are discarded during each

schedule run if they have Retain set to N in the EMR, if you
run multiple SCHEDULE commands per day with selection
parameters, this option could cause some incomplete events
to be dropped unintentionally.
Y
Default. The SCHEDULE function drops from the schedule only the
completed events that match the selection parameters included with the
SCHEDULE ACTIVATE command.
Caution! This option enables completed events to remain in the

schedule indefinitely (which could impact performance).
Review the SCHEDULE job output routinely for message
Z08D8I (which indicates completed events retained in the
database).
Retain
RetDays
302
Indicates whether to retain incomplete (i.e. non dispatched) events. This option
determines the default value for the Retain field on the EMR. These are the valid
values:
N
Discard non dispatched events during the next schedule run.
Default. Retain events for the next schedule run.
Specifies the number of days to retain pending or failed (AEOJ) job events. The
default value is 002. If you specify 000, then events are dropped at the next
days schedule load.
Option
Description
RetDone
Indicates whether to retain completed events in the schedule.

Note:
If using EOG, you must retain completed events.
Retpend
Discard completed events after EOJ.
Default. Retain completed events.
Indicates whether to retain an SQR until the event is completed. These are the
valid values:
Y
Default. Retain SQRs until they are completed (i.e., EOJ or disabled).
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).
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.).
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.).
Triggers when a MOD dataset is closed. Triggers when a NEW dataset

is closed. This value can be used alone or in combination with another
code (e.g., NM, OM, NOM, etc.).
303
Option
Description
A
Triggers when a dataset with any of the above dispositions is closed by

an abending program. This code can be added to any combination of
the codes above.
For example, setting DsclTrig to NOMA would trigger on the close of
any of the dispositions.
Note:
If A is not specified, then any of the other disposition codes above do
not trigger if the dataset is closed by an abending program.
(blank)
Iefu83
Does not allow dataset close triggering.
Indicates whether to dynamically install the SMF IEFU83 exits to trigger events
when a newly created dataset is open and closed.
Note:
Because the Iefu83 option controls whether the Zeke IEFU83 SMF exit
ZEKE48G is loaded, changes to this option require a ZKILL COLD restart.
RemTrig
Install the SMF IEFU83 exits to use the DSN dependency
Default. Do not install the SMF IEFU83 exits
Specifies how to handle a remote trigger received for scheduled jobs with multiple
schedule dates if the remote trigger does not contain a schedule or run date.
If the remote trigger has a schedule and run date, this option is ignored and the
TrigDt option is applied to the dates to process the trigger.
If the remote trigger was satisfied by a Zeke-controlled job, then the SQRs
schedule and run dates are sent with the trigger.
If the remote trigger was satisfied by a non Zeke job on a Zeke system, then the
systems current date is sent as the schedule date and run date with the trigger.
304
ND
Trigger the newest date only.
NT
If multiple dates exist, then do not trigger any date. If only one date
exists, trigger that date.
OD
Trigger the oldest date only.
TA
Trigger all dates.
Option
Description
TrigDt
Specifies whether a Zeke-controlled job can trigger another events WHEN conditions if the schedule or run dates are different. These are the valid values:
A
Default. Any event can trigger an events WHEN conditions

(regardless of the date).
The run dates must be the same before an event can trigger another
events WHEN conditions. The run date is the date the event was
actually added to the schedule, either by the ZADD command or the
batch schedule function. The run date also could have been added with
a ZADD command using a different date with the RDATE parameter.
The schedule dates must be the same before an event can trigger
another jobs WHEN conditions. The schedule date is the date that an
event would have run if it were not a 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 events 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.
Only jobs dispatched by this Zeke (or by a Zeke sharing the same
database) can satisfy triggers on this Zeke. Remote Zeke jobs and non
Zeke jobs are ignored.
Only jobs dispatched by this Zeke (or by a Zeke sharing the same
database) and non Zeke jobs can satisfy triggers on this Zeke. Remote
Zeke jobs are ignored.
Note:
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
schedulers trigger), a nonZeke job as well as Zeke-controlled job will satisfy the
trigger, regardless of the setting of either Zekes TrigJob option. Both the local
and remote Zeke systems ignore the Trigjob option when satisfying
cross-schedule triggers.
305
Option
Description
TrigRrn
Specifies whether a job can trigger another events WHEN conditions if the job
has a rerun designation. These are the valid values:
WkTrgdn
A rerun event cannot trigger another events WHEN conditions.
Default. Any event can trigger an events WHEN conditions,

regardless of the rerun designation.
Specifies whether completed events can satisfy the WEOJ/WEOE (weak) WHEN
conditions of other events in the schedule. These are the valid values:
N
Default. Do not allow completed events to trigger weak WHEN

conditions.
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
Allow disabled events to trigger weak WHEN conditions.

Note:
Disabling an event will result in the weak triggering of the dependent
event. If the disabled event is enabled later, the weak trigger will no
longer be satisfied. If multiple events satisfy the weak WHEN
condition, all must be disabled for triggering to occur.
Caution! In a Zekeplex (in which multiple Zeke systems share a database), each
system must be set to the same WkTrgds value to prevent excessive
database I/O.
Note:
If you update DsclTrig, WkTrgdn, or WkTrgdn, you must re-cycle Zeke using the ZKILL
TRACK or ZKILL COLD command.
If you update IEFU83, you must re-cycle Zeke using the ZKILL COLD command.
306
Pending Events and Messages

These generation options are related to pending events and messages:
Option
Description
PendInv
Specifies the number of minutes in the pending event interval that Zeke will hold
a pending events initiator. At the end of this interval, Zeke will place the initiator
in the table of available initiators and dispatch other events to it.
PendMsg
Specifies the number of minutes in the pending message interval (between messages that notify you of a pending event). Enter 0 if you do not want a message
to be issued.
Checking the Dispatch Queue

The EojWake generation option specifies when Zeke will check the dispatch queue.
Code
Meaning
Default. Zeke checks the dispatch queue at EOJ of each job.
Zeke checks the dispatch queue every 60 seconds. (This value could delay dispatch
of an event for up to one minute.)
Updating this option requires you to re-cycle Zeke using ZKILL COLD or TRACK.
Dispatching Events after Zeke Startup

The OprHold generation option specifies whether events are dispatched (or held) after
Zeke startup.
Verify that this option is set to N (the default) to make Zeke ready to dispatch events
after startup.
If this value is set to Y, then Zeke cannot dispatch events. ASG recommends that you do
not place Zeke on hold with the OprHold option set to Y.
If Zeke is placed on hold, you can issue the ZREL SYSTEM command to release Zeke.
This option requires you to re-cycle Zeke using ZKILL COLD or TRACK.
Caution! If you issue the ZRELOAD GENOPT command to reload the generation
options while OprHold is set to Y, then Zeke is placed on hold.
307
Auto Reply Options

Zeke enables you to automatically respond to outstanding replies (WTORs) from your
Zeke-controlled jobs which have static or predictable responses. These generation options
affect automatic replies:
Option
Description
Aur
Indicates whether to enable automatic responses to messages and replies. The

automatic reply facility is designed for job events that require message replies.
Aurintv
Specifies the interval (in seconds) to check for automatic replies. The valid values
range from 01 through 99. The default value is 1.
Note:
If you have numerous jobs with auto replies, use a lower value to improve
throughput. If you have only a few jobs with auto replies, use a higher value to
decrease system overhead.
Aurmsg
Indicates whether the operator is notified of issued auto replies.
Tape Options
The Calctap option automatically tracks the number of tape drives used by a job. If
Calctap is set to Y, then the calculated value is displayed on the EMR with an asterisk (*)
to indicate that it is an Zeke-calculated value. (A value without an asterisk indicates that it
is a user-assigned value.)
If the Tapes field on the EMR is specified, the specified number of tape drives must be
available before Zeke will dispatch the job.
Zeke keeps a running count of all tape mounts for a job, not just the tape drives. For
example, if a job mounts two tapes in the same step or one tape per step in a two-step job,
the calculated tape value is 2. Zeke does not recognize that the tape mounts are probably
done on one drive. (If you need a better way to handle this situation, use logical
resources. See Chapter 6, Resources, on page 257.)
Note:
If DispSel is set to N, then Calctap is ignored if it is set to Y.

To deactivate automatic calculation of tape drive usage, specify N to deactivate tracking
and recording the number of tape drives used by a job.
308
Exit Options
Exit options are local and global generation options that control exits.
To access the exit options

1
*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.
Review the exits options and their default values.
Update each exits option according to your requirements:

(e.g., a name) or you can keep the default value.
Options related to security exits can be reloaded using the ZRELOAD GENOPT
operator command. See Reloading GENOPTS on page 295 for details. Most other
exits options require you to re-cycle Zeke using ZKILL TRACK or COLD.
General Options
General options are local and global generation options that control a variety of functions.
To access the general options

1
*GLOBAL GENOPT, then locate the general options.
In ISPF, you can use the LOCATE GEN command to locate the first general
General section.
Review the general options and their default values.
Update each general option according to your requirements:

309
4
Some general options can be reloaded using the ZRELOAD GENOPT operator
command. Others might require you to re-cycle Zeke using ZKILL TRACK or
COLD. See Reloading GENOPTS on page 295 for details.
The following sections discuss some important general options and also indicate the
additional related generation options that might be required to support a particular Zeke
environment or configuration.
Network Registration ID
The Netregid generation option specifies the unique DMS logical Netregid (network
registration ID) used to identify the local Zeke system.
Remote events dispatched by other Zeke systems to be monitored by this Zeke system
specify this Netregid in the remote events Target field.
If you update this option, re-cycle Zeke using the ZKILL TRACK or COLD command.
Inter-product Communications
Zeke can communicate with other ASG products (e.g., Zebb) via API interfaces. You can
control whether EMR messages are enabled or suppressed.
You can set to ZPRDcom option to indicate whether to activate inter-product
communication (i.e., communication with other ASG products via APIs.). If you do so,
for example, any added or deleted events in Zeke are reflected in Zebb. A COPY or
COPYALL performed in Zeke also are reflected in Zebb.
Note:
If ZPRDcom is set to Y, the Zebb load library must be in the Zeke started task procedure.
The library must also be in the JCL for any Zeke batch utilities and online users (e.g.,
CICS, TSO, etc.) that can add or delete events.
If you update the ZPRDcom option, you must re-cycle Zeke using ZKILL TRACK or
COLD.
Inter-product EMR Messages

You can set the ZPRDsemr option to indicate whether to suppress inter-product EMR
messages. If you activate this option, messages regarding EMR changes are not sent to
other products (e.g., Zebb) and only SQR messages are set. Otherwise (if this option is set
to N), both EMR and SQR messages are sent.
310
Note:
For this option to effective, the ZPRDcom generation option also must be set to Y.
Building EDB Indexes

If you commonly add events to the schedule using the ZADD command (especially when
based on event or jobname), EDB indexes help to improve Zeke performance. Zeke
provides these options for building EDB indexes:
Option
Description
DSPIndex
Indicates whether to build a data space for a full EDB index for each event in the
Zeke database. These are the valid values:
Y
Default. Build a full EDB index for each event in a data space. The maximum size is 2 GB. ASG recommends this setting for large databases for
these reasons:
Improves ZADD command processing
Improves online browsing and retrieval of jobs
Enables the PATH, PREDECESSOR, and SUCCESSOR functions
from the EMR
Note:
The data space is named IX and is owned by the OASIS address space
(which enables it to be maintained across a ZKILL WARM).
N
EDBindex
Do not build a full EDB index.
Indicates whether to build a reduced version of the EDB index in core. These are
the valid values:
Y
Default. Build a reduced version of the EDB index in core. This process
requires approximately 20 bytes of above-the-line CSA storage for each
event in the Zeke database. This setting can improve speed and efficiency
of ZADD command processing.
Note:
This setting is required to track externally submitted jobs (i.e., jobs whose
JCL is contained in the JES job queue).
Do not build a reduced version of the EDB index in core.
311
Note:
Setting both the DSPIndex and EDBindex options to Y can help to maximize the
efficiency of ZADD processing.
If you update either of these options, you must re-cycle Zeke using ZKILL TRACK or
COLD.
Database Options
The MultSys option indicates whether the database is shared by more than one machine
(real or virtual). The database cannot be shared with previous versions of Zeke.
If more than one system is sharing the same Zeke database, these generation options must
be set to the same values for each Zeke system sharing the database:
Posid
Posidend
TrigDt
Trigjob
Wktrgdn
If you update either of these options, you must re-cycle Zeke using ZKILL TRACK or
COLD.
JCL Options
JCL options are local and global generation options that control JCL sources and
processing.
To access the JCL options

1
*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.
Review the JCL options and their default values.
Update each JCL option according to your requirements:

312
4
Some JCL options can be reloaded using the ZRELOAD GENOPT operator
command. Others might require you to re-cycle Zeke using ZKILL TRACK or
COLD. See Reloading GENOPTS on page 295 for details.
The following sections discuss some important JCL options and also indicate the
additional related generation options that might be required to support a particular Zeke
environment or configuration.
JCL Source Options

You can store JCL for events in the Zeke database; however, this is not necessary if you
have a JCL library facility. Zeke can retrieve JCL from a variety of JCL library facilities
(e.g., Bim-Edit, CMS, CA Librarian, CA Panvalet, and PDS). Before you can retrieve
JCL for an event, you must first define your installed JCL libraries to Zeke.
You use the JCL generation options to identify to Zeke the JCL libraries to be used. Each
library type requires some steps to be performed by the systems programmer. See the
section on JCL library support in your ASG-Zeke Scheduling for z/OS Installation Guide
for information on link-editing the third-party libraries or installing PDS or CMS support.
Depending on the JCL libraries you use, update these options:
Library
Generation Options
Librarian
Librarian support enables Zeke to retrieve JCL from the Librarian database and
submit the JCL for processing by the operating system.
If you do not know your Librarian number or codes, contact your Librarian
vendor.
Update these fields when you install Zeke, and again if you update Bim-Edit
(you also must link-edit the Librarian library interface and provide file
information for the Librarian library):
FairMod
Used only for Librarian 3.1 or later. Librarian modification

number.
FairOpn
Used only for Librarian 3.1 or later. Librarian options code.
FairRec
Used only for Librarian 3.1 or later. Librarian record code.
LibrBlk
Librarian library block size. Zeke uses this number to determine

the amount of storage required for Librarian subroutines. The
default value is 12800.
313
Library
Generation Options
LibrDtf
Bim-Edit
Condor
Panvalet
DD name of the Librarian library Zeke uses to retrieve JCL. The

default value is OMITTED. (The name LIBRJCL is reserved
and cannot be used.)
Update these fields when you install Zeke, and again if you update Bim-Edit
(you also must link-edit the Bim-Edit library interface):
BimAppl
Optional. Bim-Edit application name (up to eight characters long)

to be associated with Zeke.
BimPasw
Unique BIM password (up to six characters long).
BimUid
User ID Zeke passes to Bim-Edit to receive JCL. The default value

is OMIT.
Update these fields when you install Zeke, and again if you update Condor (you
also must link-edit the Zeke/Condor support program):
CondrVer
Your Condor version number. The default value is 1.
CondrLb
Library that Zeke will pass to Condor to receive JCL. The default
value is OMIT.
If Panvalet support is installed, Zeke can search for JCL in up to 99 Panvalet

libraries.
Update these fields when you install Zeke, and again if you update Panvalet
(you also must link-edit the Panvalet support program):
PanDisk
Code indicating the DASD type of the disk where the Panvalet
library resides. This field cannot contain blanks. These are the
valid values:
FBA
3340
3350
3375
3380 (default)
3390
3331 (3330-11 disk devices)
314
PanDtf
DD name of the first (or only) Panvalet library to be searched. If a

value is not entered, Zeke searches for DD names of PANDDxx.
The default value is OMITTED.
PanMem
Amount of memory Zeke requires to obtain the Panvalet work

area. The default value is 0240.
Library
Generation Options
PDS
Pdsdd
DD name in the Zeke started task procedure of the partitioned

dataset to retrieve JCL.
VM/CMS JCL
Userid
Name of the CMS JCL machine.
In the DefJcl option, specify the default JCL source type. The default JCL source type is
used if none is specified on the EMR. These are the valid values:
Code
Meaning
BIM
Bim-Edit
CMS
CMS file
CONDOR
Condor
LIBR
CA Librarian
PAN
CA Panvalet
PDS
Partitioned dataset member
ZEKE
Zeke JCL
Z14C
Source not supported by Zeke (JCL is supplied by the ZEKE14C user exit)
In the JCL1 generation option, specify one of the JCL sources listed above. You can enter
additional JCL sources in the remaining fields JCL2 through JCL5. These options
determine the JCL fields that are displayed on the Event Master Definition screen.
JOB Card Override

These generation options enable information on the JOB card for Zeke-dispatched jobs to
be overridden using information from the events EMR.
315
Note:
Zeke processes all options, except RepJName, after any ZEKE14B/N and ZEKE14E/N
user exits are invoked. Zeke processes the RepJName option before any user exits have
been invoked.
Option
Description
RepJGrp
Indicates whether the GROUP= keyword on the JOB card should be inserted (or
replaced) by the Secgroup value from the events EMR. These are the valid values:
RepJName
RepJSEnv
(Never). Default. Do not modify the JOB card.
(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.
(Conditional) If the JOB card already has a GROUP= value, do not modify
it; if the JOB card does not have a GROUP= keyword, add it with the
Secgroup value from the EMR. If a Secgroup value is not specified in the
EMR, the JOB card is not modified.
Indicates whether the jobname on the JOB card should be replaced by the jobname
from the events EMR. These are the valid values:
N
Default. Do not modify the JOB card.
Replace the jobname on the JOB card. (Only the first JOB card in the JCL
is modified.) If the jobname from the EMR is longer than the jobname on
the JOB card, Zeke makes room for the longer name by splitting the card at
a comma that separates operands.
Indicates whether to allow Zeke to insert (or replace) the SCHENV keyword on
the job card before the job event is submitted to JES. (Zeke retrieves the SCHENV
value from the SQR.)
Note:
Depending on how you set this value, the SCHENV value could differ in a job
events 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.
316
Option
Description
RepJUser
Default. (Never) Zeke does not insert/replace the SCHENV keyword on the
job card.
(Always) Zeke always inserts/replaces the SCHENV keyword on the job

card.
(Conditional) Zeke inserts the SCHENV keyword on the job card only if no
keyword exists. Zeke does not replace an existing keyword.
Indicates whether the USER= keyword on the JOB card should be inserted (or
replaced) by the user ID from the events EMR. These are the valid values:
N
Default. (Never) Do not modify the JOB card.
(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.
(Conditional) If the JOB card already has a USER= value, do not modify it;
if the JOB card does not have a USER= keyword, add it with the user ID
value from the EMR. If a user ID is not specified in the EMR, the JOB card
is not modified.
Note:
RACF surrogate processing must be set up before the RepJGrp and RepJUser options can
be used. See the ASG-Zeke Scheduling for z/OS Installation Guide for details.
Job Networking Options

These generation options are related to job networking:
Option
Description
Posid
Indicates whether to assign a unique POSID (positive event ID) to each

Zeke-controlled job event. The job is tracked by its jobname and assigned POSID
until the job is done.
Note:
All Zeke systems that share the same database must have the same Posid value.
N
Do not assign a unique ID and track jobs by jobname only.
317
Option
Description
Y
Default. Assign a unique POSID (positive event ID) to each Zeke job event.
The job is tracked by its jobname and the assigned POSID until the job is
done.
If this option is set to Y, Zeke inserts an IEFBR14 step with the POSID
information either after the job card or as the last step in each Zeke-controlled
job event. For example:
//* THE ZEKECTL STEP IS INSERTED BY ZEKE.
//ZEKECTL EXEC
PGM=IEFBR14,COND=ONLY,PARM=(A913EC42,199915C,00000012
//A9BD957F,MEDADVLP,LDVLP,DVLPZEKE)
The placement of the POSID information is determined by the Posidend

generation option.
Note:
For multiple event versions, the version number is passed to the submitting
system as part of the POSID information. If the submitting system also
supports multiple event versions, the version number enables the dispatch
system to correctly identify the associated SQR.
Note:
Zeke does not support multiple jobs per event. When this option is set to Y,
only the first job of an event is considered a Zeke job. All other jobs in the
same event are considered nonZeke jobs; therefore, each job should be
defined in a separate event.
Note:
A POSID cannot be used with the JCL sources CMS or JCLMAN. If using either of
these services, set this option to N or set the Control field in the EMR to N for
those jobs to be submitted from these sources.
Also, to override the Posid option for a specific event, use the Control field on the
EMR. When Control is set to N, Zeke does not recognize the event as
Zeke-controlled, and marks the job as EOJ at dispatch.
If you update this option, you must re-cycle Zeke.
Posidend
Indicates whether Posid information is placed at the beginning or end of

Zeke-controlled jobs.
Note:
All Zeke systems that share the same database must have the same Posidend value.
Y
318
POSID is placed at the end of the job (as the last step).
Option
Description
N
Default. POSID is placed at the start of the job (as the first step).
For most jobs, the POSID is acceptable in either location; however, there are cases
where one location could be preferable over the other. For example, if a job has the
INCLUDE statement immediately following the job card and the included member
has any JCL statements that must precede the first step (e.g, JOBLIB), then the job
will fail if Posidend is set to N. If a job has in-stream data (i.e., SYSIN DD *)
containing an imbedded job, then the job will fail if Posidend is set to Y.
If a remote job is dispatched to another Zeke system via DMS, then the Posidend
generation option on the execution system governs POSID placement. If a remote
job is dispatched to another system through NJE, then the dispatching Zekes
Posidend generation option governs POSID placement.
Zekectl
Indicates whether Zeke inserts //*ZEKECTL comment statements into the JCL when
submitting a job. This option is required to enable Zekes ThruPut Manager interface
(see Appendix B, Interface to ThruPut Manager, on page 431 for details). If you
do not use ThruPut Manager, these comment statements still can be useful because
they enable Zeke event information to be referenced in JES job logs.
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.
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
*GLOBAL GENOPT, then locate the message options.
In ISPF, you can use the LOCATE MES command to locate the first message
Messages section.
319
Review the message options and their default values.
Update each message option according to your requirements.

Generally, you enable or disable the option by specifying Y to enable the
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.
Most message options can be reloaded using the ZRELOAD GENOPT operator
Scheduling Options
Scheduling options are global generation options that you can use to control Zeke event
scheduling.
To access the scheduling options

1
GENOPT, then locate the scheduling options.
In ISPF, you can use the LOCATE SCH command to locate the first scheduling
Scheduling section.
Review the scheduling options and their default values.
Update each scheduling option according to your requirements.

Generally, you enable or disable the option by specifying Y to enable the
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.
320
Scheduling options can be reloaded using the ZRELOAD GENOPT operator

These tables discuss some of the most important options used to control Zeke dispatching
and also describe the additional related generation options that might be required to
support a particular scheduling environment or configuration:
Option
Description
DropSel
Indicates whether that you want the SCHEDULE function to drop all past, completed events when selection parameters are included with the SCEHDULE ACTIVATE command. Otherwise, only past, completed events that match the
selection parameters are dropped.
If the SCHEDULE function is run without any selection parameters, then the
DropSel option has no effect.
N
Default. The SCHEDULE function will drop from the schedule all past,
completed events regardless of whether they match the selection
parameters included with the SCHEDULE ACTIVATE command.
The SCHEDULE function will drop from the schedule only past,
completed events that match the selection parameters included with the
SCHEDULE ACTIVATE command.
Caution! Specifying this option enables past, completed events to

remain in the schedule indefinitely (which could impact
performance).
MultAp
MultGr
Specifies how to handle a ZADD by application ID when multiple events have

the same application ID. These are the valid values:
A
Add all the matching events.
Default. Add the first matching event and end the search; this is the most
efficient.
Do not add any events; list all matching events on the console.
Specifies how to handle a ZADD by group ID when multiple events have the
same group ID. These are the valid values:
A
efficient.
321
Option
Description
MultHit
Indicates whether an event is to be scheduled multiple times when there is a nonworking day. This option determines the default value for the Multhit field on
the EMR. These are the valid values:
MultJn
MultEn
MultUs
Allow only one SQR.
Default. Allow multiple SQRs. For example, if Monday is a holiday, then

Zeke schedules the jobs to run twice on Tuesday, if they are supposed to
run on Monday and Tuesday.
Specifies how to handle a ZADD by jobname when multiple events have the
same name. These are the valid values:
A
efficient.
Specifies how to handle a ZADD by event name when multiple events have the
same name. These are the valid values:
A
efficient
Do not add any events; list all matching events on the console
Specifies how to handle a ZADD by user ID when multiple events have the
same user ID. These are the valid values:
A
add all the matching events.
efficient.
Note:
The options MultAp, MultGr, MultJn, MultEn, and MultUs work together to determine which
jobs are added with the ZADD command. If multiple criteria are used on the same ZADD
command, then the option with the most restricted value is applied. For example, if a ZADD by
jobname and application ID is requested and MultJn is set to A (all) and MultAp is set to N
(i.e., none), then no events are added since the most restricted is none.
322
Option
Description
LoadComm
Indicates whether to load work centers to the schedule queue table (SQT)
storage.
ASG recommends that you activate this option if you use work centers that are
loaded into the schedule queue at schedule load time. This setting improves
response time when accessing the events through the work center function.
Additionally, work centers can be displayed in Schedule View and by using the
ZDISPLAY operator command.
N
Do not load work centers to the schedule queue table.
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 events late end time and the completion process has not
started on the event (i.e., if it is not in a Pending or Success status). If this
option is set to N, the late end time does not cause a work center event to
enter a late status.
To load work centers to the current schedule queue, enter ZRELOAD SCHD on
the Command line, and press Enter.
Nonwkday
Specifies whether to schedule an event if the OCCURS clause is true for a nonworking day. This option sets the default value used on the EMR (Nwday field).
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.
Schedule the event before the nonworking day
Do not schedule the event
Schedule the event on the nonworking day
323
Option
Description
Refevent
Specifies whether REFEVENT references from one EMR to another EMR by

event number are allowed.
A REFEVENT reference defined in an EMR schedules the event according to
the calendar (including nonworking days) and OCCURS clause of another
event. (You can specify the event that you want to reference either by event
number or event name.)
Caution! Event numbers are unique; however, because Zeke assigns the event
numbers automatically and can reassign available, previously used
numbers to new events, ASG recommends you reference other
events by event name to avoid unintended references.
A
Default. Allow. REFEVENT references from one event to another by

event number are valid.
Fail. A REFEVENT reference from one event to another by event

number is not allowed. The event is not scheduled.
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
GENOPT, then locate the security options.
In ISPF, you can use the LOCATE SEC command to locate the first security
Security section.
Review the security options and their default values.
Update each security option according to your requirements:

For some options, you enable or disable the option by specifying Y to enable the
(e.g., an ID) or you can keep the default value.
324
Security options can be reloaded using the ZRELOAD GENOPT operator

Before setting the security options, be sure to review Chapter 9, Security, on page 369.
Trace Options
Trace options are local generation options that enable trace messages to be generated for
many different types of system activities. You select each type of information to log by
enabling the corresponding trace option. Trace messages are logged to a data space that
can be dumped to a dataset and used in troubleshooting. See the ASG-OASIS for z/OS
Reference Guide for more information on data space logging.
To access the trace options

1
Follow the procedure in Editing a GENOPT on page 290 to access the desired
local GENOPT, then locate the Traces options.
In ISPF, you can use the LOCATE TRA command to locate the first Traces
Traces section.
Review the Traces options and their default values.
Update each Traces option according to your requirements:

Specify Y to enable trace messages to be logged to a data space for the
corresponding function.
Or
Specify N to disable trace messages for the corresponding function.

4
Traces options can be reloaded using the ZRELOAD GENOPT operator command.
See Reloading GENOPTS on page 295 for details.
User Interface Options

User interface options are mostly global generation options that affect the ISPF and
online facilities.
To access the user interface options

1
*GLOBAL GENOPT, then locate the user interface options.
325
In ISPF, you can use the LOCATE USER command to locate the first user
interface option, or issue CATEGORY ON to sort the display by categories and
scroll to the User Interface section.
2
Review the user interface options and their default values.
Update each user interface option according to your requirements:

You can reload user interface options using the ZRELOAD GENOPT operator
Variables Options
Variables options are global generation options that activate variable substitution.
To access the variables options

1
GENOPT, then locate the variables options.
In ISPF, you can use the LOCATE VAR command to locate the first variables
Variables section.
Review the variables options and their default values.
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.
You can reload variables options using the ZRELOAD GENOPT operator
Before setting the variables options, see Chapter 8, Variables, on page 345.
326
Defining Schedule Download Agents

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

1
From the Zeke Primary Menu, enter 4 and press Enter. The Options Selection
Menu is displayed.
From the Options Selection Menu, enter 9 and press Enter. The Schedule
Download Agents List screen is displayed:
ASG-Zeke
Command ===>
Schedule Download Agents List
Row 1 of 3
Scroll ===> PAGE
NETREGID ===>
Primary Commands: ADD DELETE EDIT END
Line Commands: D - Delete E - Edit
NETREGID Description
******************************************************************************
UNIXAGNT ZEKE AGENT UNIX
******************************* Bottom of data *******************************
Desired Result
Action
Add a new agent

2 Enter the Netregid on the NETREGID line.
3 Press Enter. The Schedule Download Agent Specification
Go to step 4.
Update an existing agent

for which you know the
Netregid
1 Enter EDIT on the command line.

2 Enter the Netregid on the NETREGID line.
Go to step 5.
Update an existing agent

Enter E next to the appropriate Netregid and press Enter. The
for which you do not know Schedule Download Agent Specification screen is displayed.
the Netregid
Go to step 5.
327
Desired Result
Action
Delete an agent for which

you know the Netregid
1 Enter DELETE on the Command line.

2 Specify the Netregid on the NETREGID line.
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.
1 Enter D next to the appropriate Netregid and press Enter.
The Schedule Download Agent Specification screen is
displayed.
Delete an agent for which

you do not know the
Netregid
2 Re-enter DELETE on the Command line to confirm and

press Enter. The Netregid that you selected is deleted and
the Schedule Download Agents List screen is displayed.
The Schedule Download Agent Specification screen is displayed:

ASG-Zeke
Command ===>
Schedule Download Agent Specification
Primary commands: CANCEL END

NETREGID: NTAGENT
Description:
In the Description field, enter the description of the agent and press Enter.
Note:
You cannot change the information in the NETREGID field.

5
Press F3 to save the information and to return to the Schedule Download Agents List
screen:
ASG-Zeke
Command ===>
Schedule Download Agents List
Agent added
Scroll ===> PAGE
NETREGID ===>
Primary Commands: ADD DELETE EDIT END
Line Commands: D - Delete E - Edit
NETREGID Description
*******************************************************************************
NTAGENT
ZEKE AGENT NT
UNIXAGNT ZEKE AGENT UNIX
******************************* Bottom of data ********************************
328
Obtaining Operating Passwords

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

1
Verify that you have a signed License Agreement.
Obtain this information:
Company name, address, telephone, and fax number
Contact name
Operating system
Product release number
Real CPU model and serial number
Virtual/Guest machine model and serial number
Note:
The CPU model is the type of machine (e.g., 4341, 4381, etc.). The CPU serial
number is the 6-character serial number of the machine. For guest VM systems, the
serial number is the 6-character serial number of the virtual machine located in the
VM directory.
3
Contact ASG Customer Support.
After you receive your new password, log on to the Zeke online facility.
329
From the Zeke Primary Menu, enter 4.2 on the Option line. The Operating
Password Information screen is displayed:
ASG-Zeke
Command ===>
Operating Password Information
Primary Commands:
BROWSE
BROWSE
EDIT
Zeke Operating Passwords

Pass 1:
Pass 5:
Pass 9:
Pass 13:
Pass 17:
9OF9K3R4
Pass 2: XKVUHXKS
Pass 6:
Pass 10:
Pass 14:
Pass 18:
Pass 3:
Pass 7:
Pass 11:
Pass 15:
Pass 19:
Pass 4:
Pass 8:
Pass 12:
Pass 16:
Pass 20:
The Zeke operating passwords shown on this display screen are

those that allow Zeke to operate on a particular CPU serial
number. These passwords are obtained from Allen Systems Group, Inc.
for each CPU on which Zeke is to operate. These passwords
change only when the CPU on which Zeke is operating changes.
Enter EDIT on the Command line, and press Enter.
Specify the new password in the next consecutive Pass field and press Enter.
Note:
The operating password must be in the Zeke database at all times.
Database maintenance includes these tasks:
Allocating and cataloging datasets.
Backing up the database.

Note:
ASG recommends you use the BACKUP command of the ZEKE utility program to
back up your database at least daily.
330
Moving or enlarging a database.
Recovering from a hardware failure.
Recovering the contents of a destroyed database.
Running Zeke using electronic vaulting.
For an existing database, you can generate a database status report that provides details
about the database (e.g., its size and event capacity, as well as the dates it was created,
last backed up, and last restored). See the ASG-Zeke Scheduling for z/OS Reference Guide
for details.
Creating the Zeke Databases (Primary and Vault)

Note:
You must perform this procedure before using Zeke for the first time.
You create the Zeke databases using the CREATE function of the ZEKE utility program.
The dataset name used to create the Zeke database has the DD name ZEKENEW, and the
dataset name to maintain and access the Zeke database has the DD name ZEKECAT. The
different names prevent the accidental destruction of the database by the CREATE
function.
Note:
Because it is independent of the operating system, the ZEKE utility program requires that
OASIS is active. You can activate OASIS without Zeke being active. This is a normal
condition during the process of installing Zeke.
To create the Zeke databases

1
Start the OASIS started task, using this syntax:

START procname,S=subsys,OASIS='(aa,bb)'
where:
procname is the name of the OASIS start-up procedure.
subsys is the OASIS subsystem name.
(aa,bb) is the OASISxx options member name suffix and console option.
Note:
If the start-up procedure provides appropriate default values for the S and OASIS
symbolic parameters, you can omit those parameters from the START command.
2
To create the primary database only, run the CREATE function using a jobstream
similar to this sample. See the ASG-Zeke Scheduling for z/OS Reference Guide for
detailed information on the CREATE function and parameters.
331
This job allocates and catalogs the dataset:
//ZFRMT
//ZALLOC
//ZNEW
//
//*
//ZUTL
//ZEKENEW
//ZEKECAT
//SYSIN
CREATE
/*
332
PGM=IEFBR14
DSN=ZEKE.DATABASE,DISP=(NEW,CATLG),
UNIT=SYSDA,VOL=SER=PERMVL,SPACE=(CYL,(10),,CONTIG)
EXEC
DD
DD
DD
ZEKEUTL,PARM=SUBSYS=ZDEV
DSN=ZEKE.DATABASE,DISP=OLD
DSN=ZEKE.DATABASE,DISP=OLD
*
For electronic vaulting, run the CREATE function using a jobstream similar to this
sample. See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed
information on the CREATE function and parameters. This job creates both the
primary Zeke database and the Zeke vault database for electronic vaulting:
//ZALLOC
//ZNEW
//
//ZVAULT
//
//ZUTLP
//ZEKENEW
//ZEKECAT
//SYSIN
CREATE
/*
//ZUTLV
//ZEKENEW
//ZEKECAT
//SYSIN
CREATE
/*
JOB
EXEC
DD
EXEC
DD
DD
EXEC
DD
DD
DD *
EXEC
DD
DD
DD *
PGM=IEFBR14
DSN=ZEKE.PRIMARY.DATABASE,DISP=(NEW,CATLG),
UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG)
DSN=ZEKE.VAULT.DATABASE,DISP=(NEW,CATLG),
UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG)
DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
DSN=ZEKE.VAULT.DATABASE,DISP=SHR
DSN=ZEKE.VAULT.DATABASE,DISP=SHR
Start Zeke with the ZEKECAT DD pointing to the primary database and the
ZEKEVLT DD pointing to the vault dataset.
Note:
Regardless of the value for the ESIActv generation option, an external security call
always is made to the SAF Security Interface using the resource class of Z$CATAL with
a resource name of CREATE## and ALTER authority. If this class information is not
defined in your security product, then the SAF action and return code are determined by
your security product. If you do not have a security product using SAF, then Zekes
internal security (which allows the request by default) is used.
If you have a ZEKE15B user exit in place, then the exit can override any external security
return code (depending on how you have coded ZEKE15B).
Backing Up the Zeke Database

You back up the Zeke database to a tape or disk file using the BACKUP function of the
ZEKE utility program.
The BACKUP command copies the contents of the Zeke database in case it must be
restored later. Use the BACKUP command to back up your database at least once daily.
ASG recommends backing up the database prior to each scheduling run.
The database is copied in these two formats:
Logical (default). The database copy follows the pointers to the different types of
database records and groups all the elements of an event together. Two logical
backups can be merged into one database.
Physical. The database copied to tape is an exact copy of the database on disk.
The Zeke database is enqueued for the duration of the physical backup. ASG
recommends you schedule the backup during the time period with the least CPU activity.
Caution! The Zeke database is not an ordinary sequential file. Most third-party
backup/copy utilities do not back up the Zeke database successfully. Be sure to
use only the ZEKE utility programs BACKUP and RESTORE functions for
this purpose.
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on the
BACKUP function and parameters.
To back up the Zeke database
Run a job to back up the Zeke database. See the ASG-Zeke Scheduling for z/OS
Reference Guide for detailed information on the BACKUP function and parameters.
333
The Zeke database BACKUP DD name is ZEKEBK. In the ZEKEUTL jobstream,

enter the Zeke backup file dataset name. Because this is a sequential file, it does not
matter how you allocate it. When the Zeke backup process writes to the file, it will
alter the LRECL and block size of the file as needed.
This is sample JCL to back up the Zeke database to disk:
//ZEKEBKUP JOB ,MSGLEVEL=(1,1),CLASS=A

//ZBK
EXEC ZEKEUTL,PARM=SUBSYS=ZDEV
//ZEKEBK
DD
DSN=ZEKE.BACKUP,DISP=(NEW,KEEP),
//
VOL=(RETAIN,SER=ZEKETP),UNIT=TAPE,LABEL=(1,SL)
//SYSIN
DD
*
BACKUP DISK DATASPACE
/*
Note:
Regardless of the value for the EsiActv generation option, an external security call
always is made to the SAF Security Interface using the resource class of Z$CATAL with
a resource name of BACKUP## and ALTER authority. If this class information is not
defined in your security product, then the SAF action and return code are determined by
your security product. If you do not have a security product using SAF, Zekes internal
security (which allows the request by default) is used.
You can use the parameter DATASPACE with the BACKUP function to improve backup
processing performance.
Restoring the Zeke Database

You restore the Zeke database from a backup using the BACKUP, CREATE, and
RESTORE functions of the ZEKE utility program. The backup copy must have been
produced by the BACKUP function of the ZEKE utility program.
You can use this procedure to recover the contents of a destroyed database and to move
and/or enlarge the database.
Caution! Do not use the RESTORE function to restore an active database.
These are the methods you can use to restore the database from a backup:
334
Logical (default). This method reorganizes the database, which enables you to
restore the database to a larger dataset or merge two databases.
Physical. This method restores the physical portion of the backup to the disk space,
which results in an exact copy of the backed up database.
Before you perform this procedure, be sure to allocate contiguous space in cylinders for
the new Zeke database dataset (i.e., no secondary extents). Allocate more space if you are
enlarging the database. See the ASG-Zeke Scheduling for z/OS Installation Guide for
more information on determining the Zeke database size.
Note:
If a Zeke database containing SQRs that were downloaded to Zeke Agent is restored from
a backup, either the RESTORE NOSCHED option must be used or the SQRs must be
removed from the Zeke Agent that is maintaining copies of them.
To restore the Zeke database

1
Run a job to back up the Zeke database or use a previous backup. See the ASG-Zeke
Scheduling for z/OS Reference Guide for detailed information on the RESTORE
function and parameters.
This sample JCL illustrates backing up the database:
//ZEKEBKUP
//ZBK
//ZEKEBK
//
//
//
//SYSIN
BACKUP
/*
JOB
EXEC
DD
DD
DSN=ZEKE.BACKUP,
DISP=(NEW,KEEP),
VOL=(,RETAIN,SER=ZEKETP),
UNIT=TAPE,LABEL=(1,SL)
*
Terminate Zeke by issuing the ZKILL COLD command. Do not use the ZKILL
WARM or ZKILL TRACK command.
Terminate any other active Zeke systems that share the database.
Caution! Do not use the OASIS STOP command.
Terminate any other OASIS-supported Z products that share the OASIS

subsystem.
Be sure that all products have been terminated, and terminate OASIS using the
XKILL command.
Allocate a new Zeke database and rename the old database (as a precautionary
measure).
Restart OASIS. OASIS becomes active without activating Zeke.
335
Run a ZEKE batch utility job using the CREATE control statement to allocate a new
Zeke database. ZEKENEW and ZEKECAT must both point to the new database.
This is a sample of the database CREATE jobstream:
//ZEKECRET
//ZUTL
//ZEKENEW
//
//
//
//SYSIN
CREATE
/*
JOB
EXEC
DD
DD
DSN=new database name,
DISP=(NEW,CATLG),UNIT=SYSDA,
VOL=SER=ZEKEVL,
SPACE=(CYL,(10),,CONTIG)
*
Note:
The message DATABASE INITIALIZATION COMPLETE is displayed when

the job is complete.
9
Perform a logical restore. This sample JCL restores an existing database:
//ZEKEREST
JOB
//ZRS
EXEC
//ZEKECAT
DD
DISP=SHR,DSN=new enlarged database name
//ZEKENEW
DD
DISP=SHR,DSN=new enlarged database name
//ZEKERS
DD
DSN=last Zeke backup name,DISP=OLD,
//
VOL=SER=ZEKETP,UNIT=TAPE,LABEL=(1,SL)
//SYSIN
DD
*
RESTORE LOGICAL MESSAGE NEWCATLG
/*
Note:
The RESTORE function builds the Zeke database specified in the ZEKENEW DD
statement.
336
10
Edit the started task procedure and change the ZEKECAT DD statement to point to
the new database (if applicable).
11
If Zeke vaulting is being used, preallocate the vault database to be contiguous and
have the same attributes (e.g., size, cylinder boundary, device type) as the new
database. Copy (i.e., DITTO) the Zeke database to the Zeke vault dataset.
12
ASG recommends that you re-cycle OASIS at this point.
13
Start Zeke.
Moving the Vault Database

At times, it might be necessary to relocate the vault database to a new DASD volume.
Zeke does not initialize if the vault database is pointing to a different primary database.
This safeguard prevents Zeke from being initialized with the wrong dataset, which could
cause the vault to become out of synchronization with the primary database (especially if
other systems are running).
If it becomes necessary to relocate the vault database to a new DASD volume, you must
force Zeke to use this new vault volume. To do so, use one of these procedures.
To move the vault database (recommended)

1
Create the new vault database as instructed in Creating the Zeke Databases
(Primary and Vault) on page 331.
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.
Terminate all active Zekes sharing this primary database/vault database pair (using
the ZILL COLD or ZKILL TRACK command).
Restart your Zeke with the ZEKEVLT DD pointing to the new vault DSN.
The first Zeke that starts also initializes the new vault dataset from the primary database
and writes the new dataset name and volume information to the primary database.
To move the vault database (emergency procedure)

1
Create the new vault database as instructed in Creating the Zeke Databases
(Primary and Vault) on page 331.
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.
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.
Restore electronic vault support at the next available opportunity:

a
Terminate all active Zekes sharing the database (using the ZKILL COLD
command).
337
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. Zekes secondary DASD unit
replicates the primary Zeke database. When a record is written to the primary Zeke
database, the electronic vaulting option writes a duplicate record to the secondary
database.
The primary and secondary (vault) databases must have the same allocation size. For
example, if a database allocates 250 contiguous cylinders for the primary Zeke database,
then the Zeke vault database must have 250 contiguous cylinders as well. The vault
database should be located on a different DASD unit on a string of DASD with a different
controller for disaster recovery considerations. Only use electronic vaulting if ample
additional DASD is available.
If there is a hardware failure that makes the Zeke database unavailable, you can recover
full services with this procedure.
If you must recover more quickly than you can copy the Zeke database, use the partial
recovery procedure; however, you will have to bring Zeke back down at the first
opportunity to complete the recovery.
Note:
ASG strongly recommends that you perform the full recovery procedure the first time,
rather than the partial recovery.
To fully recover electronic vaulting

1
Terminate Zeke. If you want to terminate the Zeke system and place it in SMF
recording mode, issue the ZKILL TRACK command. (See Continuous Job
Tracking on page 340 for details). Otherwise, issue the ZKILL COLD command. If
this fails, cancel Zeke.
Use the OASIS batch utility program to issue the STOP ZEKE command.
Note:
If you see message X00224E, this does not indicate a problem; it simply means that
Zeke code has already been pulled for the subsystem.
3
338
Allocate a dataset of the same size and on the same device type (but not on the same
volume) as the damaged database. The dataset must be in a contiguous extent.
Copy (i.e., IEBGENER or FDR) the undamaged vault database to the new dataset on
the same DASD device type.
Change the started task JCL so that ZEKECAT points to the newly copied database
and ZEKEVLT remains pointing to the undamaged vault database.
Start Zeke.
Resume processing.
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.)
Terminate Zeke by issuing the ZKILL COLD command. If this fails, cancel Zeke.
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.
Change the started task JCL so that ZEKECAT points to the renamed vault database
and comment out the ZEKEVLT DD.
Start Zeke. Zeke issues message Z0129R during startup, which is normal.
Again, ensure that there are no other Zeke systems currently active on the old
database and enter NO in response to message Z0129R. Initialization will continue
with the old vault database as the new primary database.
If there are other active Zeke systems, enter YES in response to message Z0129R.
Initialization is terminated with message Z0130E. You must first bring down other
active Zekes and restart Zeke (step 1).
Resume processing.
Zeke is now running without electronic vaulting recovery services. Schedule hourly
backups of the Zeke database until you can restore electronic vaulting.
339
10
After you have performed the partial recovery procedure, restore electronic vault
support at the next available opportunity:
a
Allocate a dataset of the same size and on the same device type (but not on the
same volume) as the existing database. The dataset must be in a contiguous
extent.
Format the new dataset as a database using the batch utility CREATE function.
Terminate all Zekes sharing the database by issuing the ZKILL COLD
command. (To determine whether there are Zeke systems sharing the database,
use the ZD COM operator command.) If this fails, cancel Zeke.
Change the started task JCL by adding the ZEKEVLT DD to point to the newly
created database.
Start Zeke. The first Zeke system that is started initializes the vault dataset
from the primary database.
Resume processing.
Continuous Job Tracking

Zeke can track relevant system and event activities during periods when both the Zeke
and OASIS subsystem have been terminated. This capability is useful when you need to
apply Zeke or OASIS maintenance, or recover database services by switching to a vault
database. With continuous job tracking, disruption to Zeke job dispatching is minimized.
When you terminate Zeke (and even OASIS), the system activities are recorded. When
you restart Zeke, the recorded activities are played back, and the schedule is updated
accordingly. Activity that can be tracked includes:
Starting of jobs, job steps, and programs
Ending of jobs, job steps, and programs
Datasets that are closed
During playback, Zeke will satisfy triggers and update the status for job activity that
occurred while Zeke was down.
Note:
Logged system activity is not maintained across an IPL.
340
Terminating Zeke using ZKILL TRACK

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

This section provides considerations for using SMF recording mode.
Limitations
These Zeke and OASIS services are suspended while Zeke is in tracking mode (i.e., has
been shut down using ZKILL TRACK):
Auto replies for jobs that are active when Zeke enters tracking mode (even after
Zeke is restarted)
Resource management for jobs that are active when Zeke enters tracking mode
(even after Zeke is restarted)
JCL error tracking

341
NOTDURING (WHEN condition) processing
Zeke condition code processing for any job active while Zeke is in recording mode.
Condition code processing cannot resume for an affected job run even for steps that
occur after Zeke is restarted.
Zeke activities requiring DMS services, for example:
Remote triggers from jobs running on Zeke, but dispatched by a remote system,
are not sent back to the dispatcher until Zeke is restarted.
Remote dependencies sent to Zeke are not satisfied.
Schedule updates from a Zeke Agent that has downloaded the Zeke schedule
are not communicated; however, send, store, and forward processing by Zeke
Agent will send the updates when Zeke is restarted.
These services are not available if OASIS also is terminated:
Zeke and OASIS batch utilities
Report Writer
Database Considerations
If multiple Zeke systems share a database, consider these points:
A Zeke in record mode does not make schedule updates. The other Zekes are
notified of schedule changes made as playback occurs.
Only A/EOS, A/B/EOP, and DSN triggers needed by the schedule are recorded. If
another Zeke adds any triggers of these types to the schedule, they are not tracked.
When terminated with ZKILL TRACK, Zeke retains enough information from its
internal tables to determine which SMF records will trigger an event. Zeke
conserves CSA use by recording only SMF records that are pertinent. If an event is
added by another Zeke, the event is not seen by the recording system until Zeke is
restarted.
No changes to the generation options by another system are reflected in the

recording system until Zeke is restarted.
CSA Considerations
Caution! Because Zeke SMF recording logs system activity in ECSA, ASG recommends
restarting Zeke as soon as possible to minimize the storage allocated.
SMF recording periodically queries the amount of unallocated ECSA remaining. Starting
when only 2 MB of ECSA remains, and every 100 K thereafter, Zeke issues this warning:
Z48R4W Zeke SMF Recording: 2.0 MB ECSA remaining
Z48R5W Zeke SMF recording will halt with 1.0 MB ECSA remaining
342
This warning gives you the opportunity to restart Zeke before any recorded activity is
discarded. If any triggers are discarded due to the ECSA limit, a start-up message
indicates the number of triggers affected.
When 1 MB remains, Zeke stops recording activity and issues this message:
Z48R6E Zeke SMF recording ECSA limit reached - triggers will be
discarded
If the system is in record mode for a brief period of time, little ECSA is useda little
over 1 K for each record logged. However, terminating Zeke with the TRACK option just
before leaving for vacation could cause a problem. In cases where ECSA usage becomes
a system constraint, a utility is provided to stop SMF recording and free all recorded
records.
//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
/*
//
If the REPORT parameter is specified, a report of all the discarded triggers is printed to
SYSPRINT:
Zeke SMF Triggers Discarded
NAME
ZEKE
ZEKEAG53
JCLPREP
SPTJX1A
QATST01
QAUTIL
STEPUSI
QATST01
QATST02
QAUTIL
STEPUSI
QATST02
JOBNAME
ZEKEAG53
ZEKEAG53
SPTJX1A
SPTJX1A
QATST01
QATST01
QATST01
QATST01
QATST02
QATST02
QATST02
QATST02
PROCSTEP
TRIGGER
EOS
EOJ
EOS
EOJ
BOJ
BOP
EOS
EOJ
BOJ
BOP
EOS
EOJ
TIME
SCHED DATE EVENT
16:53:42
16:53:42
16:53:43
16:54:08
16:54:00 2012/006 000001
16:54:01
16:54:11
16:54:11
16:54:01 2012/006 000002
16:54:01
16:54:11
16:54:11
VER
00000
00000
343
Applying Maintenance
When you issue ZKILL TRACK, all Zeke modules are unloaded so that maintenance can
be applied, except:
ZEKE48B
ZEKE48C
ZEKE48D
ZEKE48F
ZEKE48G
After maintenance is applied, terminate Zeke again using ZKILL COLD, then restart
Zeke to reload these modules.
If OASIS is terminated also, all OASIS modules are unloaded so that maintenance can be
applied.
SMF Playback
When Zeke restarts, it initiates playback. Activity within an individual job is played back
in the order it occurred. The order between different jobs is not preserved. Playback time
is compressed as much as possible so that Zeke can resume its normal dispatching. Job
accounting information, however, reflects the actual start time, end time, and duration of
the job run. After playback is complete, various messages are issued to indicate the
amount of activity and storage used during recording.
Z0140I GENOPT record A
successfully loaded
Z03B03I SYSGEN record ******** successfully loaded
Z0401I Zeke Variable Monitor initialized
Z0701I Zeke System startup successful 6.0 Z600A000
Z5G06I Schedule load task enabled
Z5G01I Initial schedule load started
Z0501I Zeke Schedule Monitor enabled
Z0510I Zeke ... Time is now 16:26:48
X00353I Program ZEKE48H installed as an IEFUJV
exit
Z5F02I Zeke Multi-System communications enabled
Z5H01I Zeke Remote Dependency task enabled
Z0901I Zeke Command Processor enabled
Z5I01I Zeke Agent Schedule Download Task Enabled
Z5G03I Schedule load complete
Z0502I Zeke Event dispatching enabled
Z45P1I Playback of SMF records has begun
Z45P6I
23 System triggers logged
Z45P7I
29 Kbytes ECSA used
Z45P8I
0 Kbytes used for filter tables
Z45P9I
13 Kbytes saved by filter tables
Z45PAI
11 triggers discarded by filter tables
Z45PBI
0 triggers discarded due to ECSA limit
Z45P5I Playback of SMF records is complete
344
Chapter 8:
Variables
8
Variables are user-defined keywords that represent values, and enable Zeke to carry out a
wide variety of specialized operations automatically. With variables, you can automate
many important tasks (e.g., JCL modifications, job triggering, and console response
handling).
Topic
Page
Zeke Variables
Naming Zeke Variables
Setting Zeke Variable Values
Maintaining Variable Documentation
346
346
346
351
OASIS Variables
Naming OASIS Variables
Setting OASIS Variable Values
Temporary OASIS Variables
355
357
357
358
System-dependent Variables
359
Uses for Zeke Variables

Using Variables to Trigger Events
Using Variables to Control Jobstream Flow
Using Variables to Restart a Job
Substituting Variable Values in JCL
IF Clauses On SET Statements
Variable Substitution in SCOM Events
359
360
361
362
363
366
366
345
Zeke Variables
A Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned
numeric or character value. Zeke supports these types of variables:
Zeke variables
OASIS variables (see the ASG-OASIS for z/OS Reference Guide)
System-dependent variables
Naming Zeke Variables

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

You do not need to define a Zeke variable before you specify it in JCL or in a work center
SET statement.
Variables remain in the Zeke database, where they are accessible to all systems that share
the database, until they are explicitly deleted.
A character value for a Zeke variable can be up to 64 bytes long; a numeric value can be
from -2,147,483,647 to +2,147,483,647.
346
8 Variables
You can establish or change Zeke variable values using any of these methods:
ZEKESET SET statement. For example:
//S1
EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV
//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.

User programs (using a supplied API).
Work center events (see Work Centers on page 149).
Zeke online facilities. The ISPF online facility is illustrated in this procedure.
Note:
You cannot use this procedure for OASIS variables (which are contained in the OASIS
database). To access the OASIS variable maintenance functions, you can issue the OVAR
primary command from any Command line in the Zeke ISPF online facility. See OASIS
Variables on page 355 for more information.
347
To define and maintain a Zeke variable

1
From the Zeke Primary Menu, enter 8 and press Enter. The Variable Selection
ASG-Zeke
Command ===>
Variable Selection Criteria
Variable Name ===>

Primary commands: ADD
Enter
Clear
* -is
? -is
BROWSE
DOCUMENT
EDIT
Selection Mask in any field to be compared for selection.

any field that is not to be used for selection.
a prefix/suffix indicator.
a wild/place holder character.
*
Variable:
Type:
System:
Appl:
GroupID:
UserID:
Date Range:
Time Range:
COPY DELETE
C - character, N - numeric
(MM/DD/YYYY) or (DD/MM/YYYY)
(HH:MM:SS)
Desired Result
Action
Define a new variable

2 Enter the variable name in the Variable Name field.
3 Press Enter.
Go to step 3.
Update a variable for which

you know the name

2 Enter the variable name in the Variable Name field.
3 Press Enter.
Go to step 3.
Update a variable for which

you do not know the name
1 Type any information you know about the variable in

any of the Selection Field Masks fields.
2 Press Enter.
348
8 Variables
The Variable Name Directory screen is displayed:

ASG-Zeke
Command ===>
Variable Name Directory
Row 1 to 6 of 6
Scroll ===> PAGE
Variable name ===>

Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT
Line Commands: B - Browse C -Copy D - Delete E - Edit
Variable Name
Appl
Grp UserID
$ED
$KATHYG
$KATHYG1
$KATHYG2
$KATHYG3
$STPNAME
***************************** Bottom of data
O - dOcument
Date
Time
System
01/30/2012 12:13:35 ZEQA
02/08/2012 14:53:44 ZEQA
02/07/2012 16:54:40 ZEQA
02/07/2012 16:54:48 ZEQA
02/07/2012 16:55:57 ZEQA
01/20/2012 15:16:32 ZEQA
******************************
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.
349
The Variable Name Record Functions screen is displayed:

ASG-Zeke
Command ===>
Variable Name Record Functions
EDIT
Variable Name: $PAYCHECK

BROWSE
CANCEL
COPY
DELETE
Appl: PAYROLL
GroupID: CHK
Desc: STARTING CHECK NUMBER
Desc2:
DOCUMENT
EDIT
UserID: KAC
Curr Value: 1001

Force upper: Y
Value set by: U (J=Job P=Program U=User)
Name: ALICE
Date/Time: 01/30/2012
14:39:55
System: SYSD
Part/Init: TSO
Prev Value: 1001
Value set by: U (J=Job P=Program U=User)
Name: ALICE
Date/Time: 01/30/2012
14:39:51
System: SYSD
Part/Init: TSO
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.
If you want to set the initial value of the variable, enter the value in the Curr Value
field.
In the Force Upper field, specify whether the Current Value includes alpha
characters. These are the valid codes:
Code
Meaning
Forces the Current Value string to uppercase.
Keeps the case of the Current Value exactly as entered. Specify this code if
you need to allow mixed-case values for variable substitution.
Note:
If the Current Value field is a numeric-only value, the Force Upper option is
ignored.
7
350
Complete these fields (which are used to organize variables for selection, display,
and reporting):
Field
Description
Appl
Identifies the application with which the variable is associated. Report Writer,
work centers, and Zeke operator commands use this field to sort and select
variables.
8 Variables
Field
Description
GroupID
This user-assigned code identifies the group with which the variable is
associated. This field can be used as a subset of the application ID.
Userid
User ID (up to eight characters long) associated with the variable against,
which determines which users can access the variable and can be used in a
selection mask. The user ID is case-sensitive; be sure to enter the value correct
case (i.e., upper, lower, or mixed).
Maintaining Variable Documentation

Zeke enables you to maintain and store Zeke variable-related documentation for the
variables that you are authorized to access.
Note:
This procedure cannot be used for OASIS variables. To access the OASIS variable
maintenance functions, you can issue the OVAR primary command from any Command
line in the Zeke ISPF online facility. See OASIS Variables on page 355 for more
information.
To access and maintain variable documentation

1
From the Zeke Primary Menu, enter option 8 and press Enter.
Access the Variable Name Directory screen, as described in, To define and
maintain a Zeke variable on page 348:
ASG-Zeke
Command ===>
Variable Name Directory
Row 1 to 6 of 6
Scroll ===> PAGE
Variable name ===>

Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT
Line Commands: B - Browse C -Copy D - Delete E - Edit
Variable Name
Appl
Grp UserID
$ED
$KATHYG
$KATHYG1
$KATHYG2
$KATHYG3
$STPNAME
***************************** Bottom of data
O - dOcument
Date
Time
System
01/30/2012 12:13:35 ZEQA
02/08/2012 14:53:44 ZEQA
02/07/2012 16:54:40 ZEQA
02/07/2012 16:54:48 ZEQA
02/07/2012 16:55:57 ZEQA
01/20/2012 15:16:32 ZEQA
******************************
351
Enter the line command O to the left of the Variable Name field and press Enter.
The Document Segments screen is displayed:
ASG-Zeke
Option ===>
EDIT

Variable: $KATHYG1
System: ZEQA
User:
Group:
Appl:

1
2
3
SCRATCH
TEXT
NOTE
Scratch pad
Text information
This screen enables you to access the different types of documentation for Zeke
variables.
Note:
If an asterisk (*) is displayed to the left of the documentation type, then

documentation already exists for the variable.
4
352
you want to access:
Desired Result
Action
Access scratch pad

documentation
Enter 1 and press Enter. Go to Maintaining Scratch

Pad or Note Documentation on page 353.
Access text documentation
Enter 2 and press Enter. Go to Maintaining Text

Access note documentation
Enter 3 and press Enter. Go to Maintaining Scratch

Pad or Note Documentation on page 353.
8 Variables

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.

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

Variable Documentation on page 351:
ASG-Zeke
Command ==>
CANCEL
DELETE
ED
EDIT
Line 1 PASS THIS TO 3RD SHIFT

2
3
4
5
6
7
8
9
10
Variable name: $TAPUG1
System: ZEQA
Userid:
Groupid:
Appl:
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.
To add or update scratch pad or note information, enter text information in the Line
area. You can enter up to 60 characters per line, and up to 10 lines of text.
When you have finished adding or updating information on the Scratch Pad or Note
screen, press Enter to update the data.
353

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

1
Access the Text Documentation screen as instructed in Maintaining Variable

Documentation on page 351:
ASG-Zeke
Command ===>
Text Documentation
EDIT
Columns 000 000
Scroll ===> PAGE
Variable: $KATHYG1
System: ZEQA
User:
Grup:
****** *************************** Top of Data *****************************
==MSG>
000001 IF YOU NEED TO UPDATE THIS VARIABLE MORE THAN 3 TIMES PER SHIFT, (NOT
000002 PER DAY), NOTIFY THE SHIFT SUPERVISOR. THE BASE VALUE WILL NEED TO BE
000003 RECONFIGURED BASED ON NUMBER OF OCCUPIED SEATS AND AVAILABLE LINES.
****** *************************** Bottom of Data **************************
354
Use standard ISPF editing commands to enter text in the line area, or to the right of
the column placeholder field, if there is existing text. You can enter up to 80
characters per line, and up to several hundred lines of text. Page forward to access an
additional screen.
When you have finished adding or updating information on the Text screen, press
Enter to update the data.
8 Variables
OASIS Variables
OASIS variable values can be substituted in the same areas as Zeke variables (e.g., JCL,
ZEKESET, SCOM, etc.), but they differ from Zeke variables in this aspects:
OASIS variables reside in an OASIS database on DASD, and, therefore, are

retained across system outages and IPLs. All OASIS-supported Z products that
use the same subsystem can access the OASIS database, so you can use OASIS
variables to communicate information between your Z products.
OASIS variable values can range from zero through 255 characters long. They can
contain any displayable character in the EBCDIC character set (e.g., leading blanks,
imbedded blanks, and trailing blanks).
Each OASIS variable substitution function call includes the variable name enclosed
in a substitution prefix and substitution suffix. This prefix and suffix are
user-definable. The default prefix is $( and the default suffix is ).
For example:
$(OASVAR1)
OASIS has its own online system where you can define, edit, and view OASIS
variables and their values.
You can base the value substituted in an OASIS variable on one or more of these
qualifiers:
Schedule date
Run date
Application ID
Group ID
User ID
Event number
Version number
Jobname
System name
Netregid
This enables multiple values to be valid for a single variable (an unqualified
variable can have only one value associated with it).
355
Various types of formatting for substitution are allowed. One type of formatting
enables you to substitute the entire variable value (or just a portion of it). For
example, you could specify that only the last two characters of the value are
substituted, or only the second word of the value. You also can pad the substituted
value with extra characters.
These are the substitution functions can be performed on OASIS variables:
Substitution
Function
Description
DATE
Converts a date to a specified format and return the result.
EXEC
Calls an EXEC and returns its value.
ITEM
Returns the value of a qualifier.
LEFT
Returns the left-most positions of the string.
RIGHT
Returns the right-most positions of the string.
SUBSTR
Returns a substring of the string.
SUBWORD
Returns one or more specified words from the string.
UPPER
Returns the string in upper case.
VALUE
Return the value of a variable whose name is obtained from the value
of another variable or a nested function call.
You can perform various operations on OASIS variables using the SSS0UTV utility
program. You can use SSS0UTV to create new variable value records, replace or
delete existing value records, and list variable definition records and value records.
The TVSET function enables you to create and set the value of a temporary OASIS
variable (which remains available until your program terminates), or to override an
existing OASIS variable value temporarily (i.e., for the current job run). See
Temporary OASIS Variables on page 358 for more information.
See the ASG-OASIS for z/OS Reference Guide for detailed information before you use
OASIS variables for the first time.
356
8 Variables
Naming OASIS Variables

OASIS variable names can be up to 64 characters long. The first character can be any of
these symbols:
Dollar sign ($)
Underscore (_)
Pound sign (#)
At sign (@)
Any capital letter (from A through Z)
The remaining characters can be any of the above characters or numerics from
0 through 9. Imbedded blanks are not allowed in variable names.
Setting OASIS Variable Values

OASIS variable values are set using any of these methods:
SSS0UTV utility program
OASIVAR Application Programming Interface (API) (see the ASG-OASIS for z/OS
Reference Guide for detail)
OASIS online (as shown in the following procedure)
To maintain OASIS variables
Issue the OVAR primary command from any Command line in the Zeke ISPF online
facility. The OASIS Variable Maintenance screen is displayed:
OASIS Variable Maintenance
OPTION ===>
02/20/12
Primary Commands: ADD ADDDEF BROWSE BRWDEF DELDEF DELETE EDIT EDITDEF
LIST
Variable: ________________________________________________________________
Variable qualifiers:
Job name: ________
Schedule date: _______
Run date: _______
Netregid: ________
Application name: ________
Group name: ___
Userid: ________
Event number: _________
Version number: _____
System: ________
*** Press PF1/PF13 or type "?" in field to see mininum product levels
357
From this screen, you can add, edit, delete, or browse variable definition records
and value records.
Temporary OASIS Variables

The TVSET function (which is unique to OASIS variables) enables you to perform these
tasks:
Create and set the value of a temporary OASIS variable (which remains available
until your program terminates).
Override an existing OASIS variable value temporarily.
For Zeke-dispatched jobs, you can use TVSET if you want to override an existing
variable value without changing the variable itself.
Syntax
//*TVSET {variable name} {new value}
Note:
Do not use an equal sign (=) between the variable name and value.
For example, to change the value of the OASIS variable ABC to NEW_VALUE
without modifying the variable value record, add this line to the JCL:
//*TVSET ABC NEW_VALUE
The new value overrides the previous value anywhere the variable appears, and affects
only the current run of the job. The TVSET command does not appear in the resulting
output JCL.
When used in JCL, the //*TVSET statement appears in the output stream when it runs, so
the statement is checked for syntax errors. If an error is found, message Z0683E is issued
to the JESMSGLG and SYSLOG of the Zeke started task for each //*TVSET line found
with an error. The error message contains the input line number in error and the event and
version numbers associated with the EMR. Message Z0685E is displayed on the console
for the event.
When the JCL is retrieved, the //*TVSET statement is included. The TVSET syntax is not
checked for errors when it is retrieved; the TVSET syntax is checked (and if applicable,
the above error messages are issued) when the retrieved JCL is run.
358
8 Variables
System-dependent Variables
System-dependent variables enable you to run the same job control statement and use the
same variables on different systems while keeping the variables separate.
To define a system-dependent variable, you use three dollar signs ($$$) as the first three
characters of the variable name (e.g., $$$NAME). Zeke replaces the third dollar sign with
the one-character ID of the dispatching CPU. These are examples of system-dependent
variables:
Job Control Variable Name
CPUID
Actual Name Used
$$$PRFLGG
$$APRFLG
$$$OPER1
$$COPER1
$$$VAR01
$$BVAR01
$$$TEST
$$ATEST
Note:
System-dependent variables cannot be used with Zeke operator commands (e.g., ZSET)
because operator commands are processed only by the CPU on which they are entered.
To use a system-dependent variable with an operator command, replace the third dollar
sign with the CPUID (e.g., $$AFLAG instead of $$$FLAG).
System-dependent variables can be used in ZEKESET statements and by programs that
call the ZEKEVAR API.
Uses for Zeke Variables

Zeke and OASIS variables are powerful job management tools. These are some of the
uses of Zeke variables:
Trigger jobs (Zeke variables only)
Prevent jobs from being dispatched
Control jobstream flows by selecting the steps to be processed at execution time
Simplify jobstream recovery and restart
Provide automatic restart at the cancelled step
Substitute values in z/OS and JES JCL statements at submission time
Pass information from one job, job step, or program to another
Document cancellation reason

359
Establish relationships between jobs
Using Variables to Trigger Events

A dependency is a condition that must exist before an event can be dispatched.
Dependencies include a job that must process, a dataset that must close, or a variable that
must be set to a specific value. See WHEN Conditions on page 124 for more
information.
Using a variable value as a dependency enables you to trigger or prevent a job from
occurring through job streams and programs. Additionally, this feature enables you to
trigger jobs through external actions (e.g., the receipt of data for an application). In this
case, an event can be established with a variable dependency that can be satisfied by the
ZSET operator command.
For example, jobstream PRUPDT is a job with a dependency condition. The dependency
states that variable $PRDATA1 should have a value of YES. This is the WHEN condition
to establish this job:
WHEN (VAR $PRDATA1 EQ YES)
Also, this jobstream is not processed until the PREDIT job is processed with no errors.
When the results of PREDIT are satisfactory, and the PRUPDT job can be processed, the
operator simply informs Zeke by entering this command:
ZSET VAR $PRDATA1 EQ YES
This command satisfies the job dependency for PRUPDT, and if the early/schedule time
has been reached, Zeke moves the event to the dispatch queue. Zeke dispatches when all
resource requirements are available.
Additionally, the variable $PRDATA1 needs to be reset to NO when PRUPDT is
complete. You can accomplish this using a ZEKESET program SET statement after the
last step in the jobstream.
The variable $PRDATA1 could be set to YES in any of these ways:
Using a ZEKESET program SET statement.
Using the ZEKEVAR API. This facility enables programs to make decisions that
can affect the dispatching of subsequent events.
Using the Zeke online facility for work centers.
Note:
OASIS variables cannot be used to trigger jobs.
360
8 Variables
Using Variables to Control Jobstream Flow

You can use variables to control the flow of MVS job streams.
As a simple example, this jobstream consists of four steps to be processed daily, and an
additional job step to be processed only when the second step creates a special file of
exception records:
//ARUPDT
JOB
,AR.DEPT,MSGLEVEL=(1,1),CLASS=X
//INIT
//SYSPRINT DD
SYSOUT=A
//SYSIN
DD
*
SET VAR $$$ARFLG EQ NO
<== Begin with variable=NO
/*
//ARSTP1
EXEC PGM=PROG1
<== Step 1
//INFILE
DD
DSN=AR.MASTER.TAPE,DISP=OLD,UNIT=TAPE,
//
VOL=SER=ARTAPE,LABEL=(1,SL)
//SYSPRINT DD
SYSOUT=A
//*
//ARSTP2
EXEC PGM=PROG2
<== Step 2
//OUTFILE
DD
DSN=AR,MASTER.TAPE,DISP=(NEW,KEEP),UNIT=TAPE,
//
VOL=SER=ARTAPE,LABEL=(1,SL)
//EXCPFILE DD
DSN=AR.EXCPS,DISP=(NEW,CATLG),UNIT=SYSDA,
//
SPACE=(132,(2000,500))
//SYSPRINT DD
SYSOUT=A
//ARSTP3
EXEC PGM=PROG3
<== Step 3
//RPTS
DD
DSN=&&AR.REPORTS,UNIT=SYSDA,DISP=(NEW,PASS),
//
SPACE=(132,(2000,500))
//SYSPRINT DD
SYSOUT=A
//*
//ARSTP4
//TAPEIN
//RPTSIN
EXEC
DD
DD
PGM=PROG4
<== Step 4
DSN=SOME.DATASET,DISP=OLD,UNIT=TAPE
DSN=&&AR.REPORTS,DISP=(OLD,DELETE),UNIT=SYSDA
//SYSPRINT
//*
//CHKEXCP
//SYSPRINT
//SYSIN
SET CODE 20
/*
//ARSTP5
//EXCPFILE
//SYSPRINT
//
DD
SYSOUT=A
DD
SYSOUT=A
DD
*
IF $$$ARFLG NE YES
<== Bypass Step 5 if variable=NO
EXEC
DD
DD
PGM=PROG5,=(0,NE,CHKEXCP) <== Step 5

DSN=AR.EXCPS,DISP=(OLD,DELETE)
SYSOUT=A
361
In this jobstream, these actions occur:
An system-dependent variable named $$$ARFLG is set to NO early in the

jobstream, so that step 5 normally is skipped.
The ZEKEVAR API updates the value of $$$ARFLG if Step 2 (program PROG2)
creates the special exceptions file that needs to be processed.
If the variable is still set to NO, the CHKEXCP step terminates with a condition
code of 20. Otherwise, the condition code is zero.
The MVS JCL parameter on the EXEC statement for Step 5 tests the condition code
of the previous step. If the condition code is 20, Step 5 is bypassed.
Using Variables to Restart a Job

Variables can be used to restart a job at a cancelled step. A variable can save the name of
the last job step processed in a jobstream. If any step abends, the job can be restarted at
that step.
This facility works best when used with a COND=ONLY step. The step which specifies
COND=ONLY is executed if any previous step in the jobstream abends. If no abend
occurs, the operating system bypasses the step. If an abend occurs, the COND=ONLY
step sets up the information for the restart.
For example, in this jobstream, the variable $CL01P043STEP saves the restart step name:
//CL01P043
JOB
,MSGLEVEL=(1,1),RESTART=$CL01P043STEP
... JCL FOR STEP 1
/*
... JCL FOR STEP 2
/*
... JCL FOR STEP 3
Last normal step
//EOF
Normal end of job
//SYSPRINT
DD
//SYSIN
DD *
SET VAR $CL01P043STEP EQ *
For next job run
/*
//ABEND
EXEC PGM=ZEKESET,COND=ONLY
EXEC ONLY IF ABEND OCCURRED
//SYSPRINT
DD
//SYSIN
DD *
Only if job abends
SET VAR $CL01P043STEP EQ LASTSTEP
Set VAR to prior step
*
At this point, you can set a variable
*
to a value that dispatches a recovery job
/*
//
END OF JOB
The JOB statement contains an MVS restart parameter. This starts job processing at the
named step. Because the parameter is a Zeke variable, Zeke supplies the value through
the internal reader when the job is submitted.
362
8 Variables
If the job completes normally, ZEKESET sets the variable to asterisk (*); the operating
system starts the jobstream at the first job step the next time it runs.
The last job step specifies COND=ONLY on its execute statement. If the job completes
normally, the operating system bypasses this step. If an abend occurs, this statement sets
the variable to the name of the step which abended.
When this job is restarted by the ZREFRESH operator command, the first step executed
is the one that previously failed (the value of $CL01P043STEP). No external action is
necessary.
To restart at a step other than the one that abends, issue the ZSET command to set
$CL01P043STEP to the desired restart step name. For example, the above jobstream
abends in step CLSTP3, but the jobstream needs to be restarted at step CLSTP2. Enter
this command to begin processing at CLSTP2 the next time it runs:
ZSET VAR $CL01P043STEP EQ CLSTP2
The operating system does not execute the COND=ONLY step (even if the job did not
run properly) in any of these conditions:
A JCL error occurs (i.e., a dataset is missing)
The operator cancels the job (i.e., system S222 abend)
A complete system failure (i.e., power failure)
If these conditions have an impact on system reliability, use this alternate restart
technique. Execute the ZEKESET program between each of the normal job steps in a
jobstream. The restart variable can be set to the name of the step that is about to be
executed (the step after the ZEKESET step). This ensures that the variable always is set
to the step to be restarted (even on full system failures).
Substituting Variable Values in JCL

Zeke and OASIS variables can be used in both JCL and non JCL statements submitted to
the system by Zeke.
If the SubData generation option is set to Y, Zeke scans all statements as the jobstream is
submitted through JES. If a variable is found, it is replaced with its current value.
363
Variable substitution is performed while Zeke is writing JCL statements to the JES
internal reader. The variables must contain the proper values at job dispatch time.
Because of the timing, it is not valid to set values in these ways:
In one job step and expect the new value to be substituted into a subsequent
statement in the same job. The substitution for that statement was already done
before the job started with the value of the variable at that time.
For statements in procedures that are called from the dispatched job. Zeke does not
see the actual statements in the procedure, only the EXEC statement.
To use the variable values on statements in a procedure, code the Zeke or OASIS variable
as the value of a parameter on the EXEC statement. Zeke substitutes the value into the
EXEC statement and the procedure can substitute this value into the statements in the
procedure (e.g., EXEC PROC=TEST1, PARM1=$VAR).
During variable substitution, trailing spaces are truncated from character values to a
maximum of one trailing space, and leading zeros are truncated from numeric values,
leaving one zero if the numeric value is zero.
Note:
When variable substitution occurs on JCL statements with line numbers in columns 72
through 80, the line numbers might be shifted to the left if the value substituted in for the
variable is shorter than the variable name itself.
You can use the Jclcol71 generation option to limit variable substitution to columns 1
through 71. See the ASG-Zeke Scheduling for z/OS Reference Guide for details.
These are examples of variable statements and the actual values. Assume that the
variables have these values:
$X = PR01P001
$Y = 0074
364
Sample
Statement
Resolved
Statement
//$X.$Y
//PR01P00174
To concatenate two variables, enter a period (.)

between them. Zeke discards the period and joins
the values of the variables. You also can use
variable concatenation to create a variable longer
than 64 characters. For example, if $A is 64
characters and $B is 16 characters, then $A.$B =
an 80-character value.
//$X $Y
//PR01P001 74
This example leaves a space between the

variables.
Explanation
8 Variables
Sample
Statement
Resolved
Statement
//$X..$Y
//PR01P001.74
//$X JOB,
PAYROLL.EDIT
//PR01P001 JOB, If the variable value is longer than the name, the
PAYROLL.EDIT
data following the variable shifts to the right. If the
value is shorter than the name, the data following
the variable shifts to the left.
Y EQ $Y
Y EQ 74
The leading zeros are dropped.
$X.ABC
PR01P001ABC
ABC is appended to the value of $X

(concatenation).
$X,
PR01P001,
A comma after the variable name is retained with

the value.
word$Y
word74
A word adjacent to the variable name remains

adjacent to the value.
Explanation
If you want the variable and the value to be
separated by a period after concatenation, enter
two periods between the variable and the value.
You can use these control statements (beginning in column 1) to activate or deactivate
variable substitution:
Statement
Purpose
ZEKE-CTL NOSUB
Deactivate substitution.
ZEKE-CTL SUB
Reactivate substitution.
During the jobstream submission, Zeke discards the control statement and either activates
or deactivates the variable substitution facility accordingly.
If the variable substitution facility is deactivated, it remains deactivated until the end of
the jobstream, or until a new ZEKE-CTL statement reactivates it.
For example, if you use the default substitution prefix and suffix specification
VDELIMS=($(:)) then substitution could be performed on some JCL statements
(i.e., generation dataset relative numbers) inadvertently. If you do not want to redefine
your substitution prefix and suffix, you can deactivate substitution by including these
control statements around the lines on which you do not want substitution performed. For
example:
ZEKE-CTL NOSUB
//
DD DISP-SHR,DSN=A.B.C$(nnn)
ZEKE-CTL SUB
365
As an alternative, you could code the affected lines using a nested quoted literal, for
example:
//
DD DISP=SHR,DSN=A.B.C$($(+0))
When the SubData generation option is set to Y, variable substitution always is in effect
for each new jobstream being submitted (unless the control statements are input to the
program ZEKESET).
The variable substitution control statements cannot be combined with the Zeke PDS
library control statements. Both control statements use the verb ZEKE-CTL, but the
operands of the two statements cannot be specified on a single statement. If both
statements are desired in a single jobstream, code two separate statements.
If you are executing ZEKESET in a PROC and the JCL calling the PROC is passing a
SET VAR $... statement in the SYSIN DATA, the calling JCL should contain the
ZEKE-CTL NOSUB statement after the EXEC statement to prevent variable substitution
on the variables name in the SET VAR $... statements.
Note:
The difference between using OPTION NOSUB and ZEKE-CTL NOSUB to turn off
variable substitution is that OPTION NOSUB turns it off at statement execution time,
while ZEKE-CTL NOSUB turns it off at variable substitution time (just prior to when the
event is dispatched). See the ASG-Zeke Scheduling for z/OS Reference Guide for more
information on OPTION NOSUB.
IF Clauses On SET Statements

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

An SCOM event can contain a maximum of 60 characters of commands or responses per
line. When using variable substitution in an SCOM, the length of each line must be no
longer than 60 bytes (including the values).
366
8 Variables
For example, if you submit this SEND command from an SCOM:

SE THIS IS A TEST TEST TEST TEST TEST TEST.,USER=($ABCVAR)
and this is the value of the variable $ABCVAR:

ABCABCABCABCABC
The length of the command as it appears above is exactly 60 bytes. After variable
substitution is performed for $ABCVAR, the length of the line will exceed 60 characters.
In this case, the line must be modified to be 60 characters or less (including the value).
367
368
Chapter 9:
Security
9
Zeke provides an internal security function as well as the OASIS External Security
Interface (ESI). Zekes versatility enables you to control access to Zeke objects and
functions from another vendors 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.
Topic
Page
Preparing for Implementation
370
Zeke Security Processing

Security Calls
Security Tracing
372
372
376
Internal Security
Internal Security Terms
Online Access
Operator Record
Class Record
Batch Access
Operator Commands
Implementing Internal Security
377
377
378
379
379
380
380
380
External Security
Security Classes and Resource Names
Implementing External Security
392
393
398
369
Preparing for Implementation

Securing information for any computer system can be a complex task, requiring
knowledge of the security package, the information to be protected, and the application
that stores the information. With this in mind, ASG recommends that your Zeke security
team be made of people who are familiar with Zeke, system programming functions, and,
if applicable, your security product.
In general, you must answer these questions before deciding on a security approach:
What exactly needs to be secured?
Access to information (e.g., objects like the Zeke database and specific records).
Access to Zeke (e.g., functions like primary menu options and Zeke operator
commands).
Access to a combination of information and the Zeke functions.
Do that you want to use Zeke internal security, an external security package, or a
combination?
How will you determine who is granted access and to what authority level?
Before you can decide what needs to be secured, you must understand these different
security approaches used by Zeke:
Object security controls access to the information contained in a data structure (e.g.,
a record or file). This includes controlling access to individual EMRs, SQRs, and
variables.
Securing by object protects the information regardless of how access is attempted
(i.e., by command, batch utility, or online facility). For example, securing EMRs as
objects protects them regardless of whether access is attempted from the Event
Master Record online function, the EVENT batch command, or the LIST EVENTS
function of Report Writer.
These are the specific objects that can be protected:
Objects
Internal
Security
Zeke database
370
External
Security
EMRs
SQRs
Variables
9 Security
Objects
Internal
Security
External
Security
Calendars
Generation options (GENOPT)
Initiator definitions (GENSYS)
Company name and address
Pool definitions
Internal security (class and operator) records
Operating passwords
Logical resource records
ESI definition records
Function security controls access to commands, programs, and online screens.

These functions provide access to information and also control Zeke processing.
For example, securing access to Zeke commands by function controls access to
records like variables (ZSET VAR), EMRs (ZADD EV), and SQRs (ZALTER EV)
and also controls access to Zeke processes that do not use records (e.g., ZHOLD
SYS and ZKILL).
These are the specific functions that can be protected:
Internal
Security
External
Security
Primary Menu options
Batch equivalents of Primary Menu options
Functions
SCHEDULE function
ZEKESET commands
Individual SCOM command lines
Zeke operator commands

Online event ADD (by event type)
371
Zeke Security Processing

Although Zeke has its own internal security facility, you can control access to Zeke
objects and functions from any SAF-compliant security product through ESI.
Additionally, you can use a combination of both security methods (which is why it is
important that you understand both internal and external security before deciding on an
approach).
External security offers increased benefits over internal security by enabling more
comprehensive security at a more detailed level and providing more flexibility in
establishing access criteria.
This section gives a general overview of Zeke security processing (whether you are using
internal or external security, your own security exit, or a combination). See the sections,
Internal Security on page 377 and External Security on page 392 for detailed
discussions on each method.
Security Calls
When a user attempts to access a Zeke object or function, Zeke calls the security
processing routine ZEKE15A to determine whether to allow the request.
Authority Levels
Zeke governs security calls using this hierarchy of authority levels (from lowest to
highest):
Authority Level
Description
READ
Allows the user to browse, display, and list records.
UPDATE
Allows the user to modify existing records, along with all of the authority
of READ access.
ALTER
Allows the user to add and delete records, along with all of the authority
of UPDATE access.
CONTROL
Allows the user to perform the requested command (only applies to

individual SCOM command lines).
Each security call specifies the minimum authority level required for the request. For
example, if a user has been granted UPDATE access to a record and the user is requesting
READ access only, then Zeke allows the request (because READ access is assumed to be
granted for a user with UPDATE access).
372
9 Security
Note:
Internal security considers only READ access and WRITE access (i.e., a combination of
UPDATE and ALTER); therefore, if a user is granted WRITE access, internal security
allows the user to add and delete records, as well as update existing records.
Multiple Calls
Sometimes a single user request results in more than one security call.
For example, if a user issues the operator command ZALTER EV 1 WHENOK, then
Zeke makes these two security calls:
A call to determine whether the user is authorized to issue ZALTER operator

commands.
A call to determine whether the user is authorized to update the SQR for event 1.
In this example, the user must be authorized for both requests or the request is denied.
Additionally, if a single user request requires access to multiple records, even more
security calls could be generated.
For example, if a user issues the command ZDISPLAY JOB, Zeke makes these calls:
A call to determine whether the user is authorized for the ZDISPLAY command.
A call for every SQR to determine which ones the user is authorized to display (i.e.,
READ access).
In this example, if the user is authorized for the ZDISPLAY command, then Zeke
displays only the records for which the user has READ access. If the user is not allowed
to issue ZDISPLAY operator command, then Zeke denies the entire request.
373
Origination Sources
A security call can originate from any of these sources:
Source
Description
Batch
A request from a batch program or job (i.e., ZEKE or ZEKESET utility

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

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

Logging on
Accessing one of the Primary Menu options
Accessing a specific record or group of records
Issuing a command (e.g., ZDISPLAY)
Invoking a special command (e.g., a database status)
Adding or updating commands in an SCOM event
Logging off
374
ZEKECMD
A request from the ZEKECMD API (e.g., issuing a command). This request can
originate from a batch program, a TSO or CMS users 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 users address space, or a
multiuser address space (CICS).
9 Security
Processing Logic
This flowchart represents the general flow of Zeke security processing and how Zeke
determines which security functions are invoked:
Access request
Is it a hard-coded
ESI call?
A
N
Does genopt
ESIActv=Y?
N N
Does ESI say to

revert to internal?
Does ESI apply

to this call?
Does internal
security apply?
Call ESI
Internal security
verification
Call user security

exit (if applicable)
Allow/Deny
request
Every request is assumed to be allowed until it is denied by one of the three security
processes (i.e., ESI, internal security, or a user exit).
External Calls
Security calls to ESI have been hard-coded for these Zeke global database functions
CREATE, RESTORE, BACKUP, and STATUSto provide the most security when the
integrity of the database is in question and security criteria might not be accessible.
375
If you have an external security product on your system, you might be required to set up
and define authorized users for the Z$CATAL external class before you can run the
CREATE or RESTORE functions. To do so, grant at least one user ALTER-level
authority to these resource (entity) names:
BACKUP##
CREATE##
RESTORE#
BLOCK###
STATUS##
If you do not define the class and authorized users, your request could be denied
(depending how your security product handles calls with undefined classes). If the return
code generated and passed to SAF from your security product is 0 or 4, then Zeke allows
the request without the class and resource names. If the return code is not 0 or 4, then
Zeke denies the request. Also, if a user security exit exists, the request could be denied.
See Security Classes and Resource Names on page 393 for important details about the
Z$CATAL class.
External security for other calls are activated by the generation option ESIActv. If
ESIActv is set to N, there are no calls to external security (except for Z$CATAL) and,
instead, they are passed to internal security. Even when using external security, there
could be situations when the administrator wants to revert to internal security. This is
especially useful for backup in situations when the security product is disabled.
The user security exit ZEKE15B (if present) is called after all other security verification
has occurred. This exit can only deny requests that (up to this point) are allowed or
change the user ID to be used for the internal security logon. The exit cannot allow
requests that have already been denied.
Security Tracing
You can trace the Zeke security processing flow using the operator command
ZD SECURITY. The trace displays the security parameter list contents at various key
points during processing. This is the same parameter list that is passed to any existing
user security exits (e.g., ZEKE15B).
Use the security trace to help determine this information:
376
Whether a security exit is being called and what effect it has on the security
decision.
Which element of the security process is making the allow/deny decision.
Whether internal and external security processing are being performed for a specific
call.
9 Security
The values of various fields passed to and from the user security exit.
Internal Security
This section explains how Zeke internal security processing works. Internal security is
enabled by default, unless external security is enabled. This is controlled by the Zeke
generation option ESIActv:
If ESIActv is set to N (i.e., do not enable external security), then internal security is
called (by default).
If ESIActv is set to Y, then the process option for each defined external security
class determines whether internal security is called for that class. If external
security has not been set up, then the default process option (N4) for each class will
call internal security. See Implementing External Security on page 398 for more
information.
Internal Security Terms

Zeke internal security uses these record types (stored in the Zeke database) to control
access:
Operator records control access to records (i.e., objects) in the database (e.g.,
EMRs, calendars, work centers, documentation, variables, etc.).
Class records control access to Zeke maintenance functions accessed from the Zeke
Primary Menu options (e.g., EMRs, calendars, work centers, documentation,
variables, etc.) and Zeke operator commands.
These are the terms that identify the ID types related to internal security:
Term
Description
Class ID
Name of a class record. The operator record Zeke uses for internal security also
points to a class record in the Zeke database. The class record extends the
security of the operator record by specifying which types of access are available
to the major Zeke functions and which Zeke operator commands the operator is
authorized to use. Multiple operator records can specify the same class record.
Note:
Keep in mind that class has a different meaning in internal security than in
external security and the two concepts are unrelated.
377
Term
Description
MVS User ID
User ID that identifies a user, job, or address space in the MVS environment
(and also might be referred to as a TSO or ROSCOE user ID, a SAF user, or a
RACF user ID). Zeke uses the MVS user ID to determine which security records
in the Zeke database to use for internal security.
Operator ID
Name of the operator record in the Zeke database that Zeke uses for the MVS
user ID associated with the current operation.
Zeke attempts to find an operator record with a name that matches the MVS user
ID. If it does not find a match, Zeke searches for a default operator record to use
for internal security as determined by Zeke generation option settings. As a
result, the operator ID is either the same as the MVS user ID or the same as the
default operator ID.
The operator record in use contains the name of a class record in the Zeke
database to use for determining access to Zeke functions. It also contains a list
of one or more user ID masks to use for determining access to particular events
and variables.
User ID
Event and variable records in the Zeke database contain a user ID field that is
used for internal security. Zeke does not map the user IDs in the event and
variable records to the actual MVS user ID; instead, Zeke matches the user IDs
against the user ID masks in the operator record.
In summary, the MVS user ID determines which operator record to use to control a users
access. The operator record defines the users access to Zeke functions (by authorizing
access to events and variables based on the user ID on those records and by specifying an
authorization class).
Online Access
The ReqOpid generation option controls access to the Zeke online system. You can use
this option to restrict users from accessing the online system:
If ReqOpid is set to Y, only users that have an MVS user ID that matches the name
of an existing operator ID (i.e., the name of the operator record) can access the Zeke
online system. Otherwise, a user is assigned a default operator ID and cannot use
the Zeke online system.
Caution! Before setting ReqOpid to Y, be sure that at least one user has an MVS
user ID that matches an operator ID that is authorized to access the Zeke
online system. Also, ensure that the assigned operator ID specifies a class
ID that grants WRITE access to security records.
378
If ReqOpid is set to N, Zeke allows any user to access the Zeke online system.
9 Security
Caution! Because you must create and maintain operator and class records using
screens in the Zeke online system, be sure that at least one user always
has WRITE access to security records.
Operator Record
The operator record controls which EMRs, SQRs, and variable records a user can access
and to what authority level. Complete these steps to enable this type of security:
The event or variable record definition must contain a user ID. Multiple event and
variable records can specify the same user ID.
The user ID (or a mask that will select that user ID) must be defined in the operator
record so that it can be compared when a user attempts to access the event or
variable record.
For each user ID or mask in the operator record, you can specify the authority level
(i.e., NONE, READ, or WRITE) for each record type.
Zeke tests the list of user IDs (or masks) in the operator record from the top,
downward, and uses the first match. If no match is found, Zeke denies access to the
event or variable record.
Class Record
The operator record that Zeke associates with a user specifies which class record to use to
determine access to Zeke main functions (through Zeke Primary Menu options) and also
controls which Zeke operator commands the user is authorized to issue.
For operator commands, several levels of access could be required (depending on the
function of the command). A user must be authorized to issue a command, but also could
require access to database records and the ZCOM online function. The users
authorization depends on whether the command requires access to database records and
whether the command verb implies WRITE access.
For example, to be fully authorized to issue the operator command ZADD EV 1, the
user must have these levels of authorization:
Function Access
Authority Level
ZADD command
YES
ZCOM menu option
WRITE
Event 1
WRITE
379
Batch Access
Zeke associates a batch job (issued through the ZEKE or ZEKESET utility programs)
with the MVS user ID of the submitter, and uses the MVS user ID to select the operator
and class records to use for securing access. For batch jobs, Zeke also must determine
what action to take when access to a command or function is denied (which is controlled
by the SecFail generation option):
If SecFail is set to C, the job is cancelled.
If SecFail is set to I, the request is denied and processing continues.
Note:
You do not control security for the SCHEDULE function through internal security. You
must secure the SCHEDULE function either using external security or ZEKE15B user
security exits.
Operator Commands
Zeke uses the MVS user ID to determine the security records to use for authorization of
commands (e.g., issued through Zeke online systems, batch jobs, system consoles, or
SDSF) as for any other function.
Some system consoles are not associated with an MVS user ID; these consoles do not
require a logon. When a user issues a Zeke operator command from this type of system
console, Zeke uses the operator record named OPERATOR for internal security. Be sure
that you define the OPERATOR operator record and its associated class record to provide
an appropriate level of authority to users that might already have access to such consoles.
Implementing Internal Security

Before implementing internal security, review and change (if necessary) the relevant
generation options (see Setting the Internal Security Generation Options on page 381).
When you enable internal security, all functions initially are allowed by default.
If you decide to structure your internal security with restrictive access, you must define
class IDs and operator IDs using this general procedure:
380
Define class IDs to group individuals who need similar access to the online
functions and commands. See Defining Class Records on page 386.
Define an operator ID for each user to be granted access to Zeke. See Defining
Operator Records on page 389.
Define which online functions and operator commands can be accessed by an

operator ID by assigning a class ID.
9 Security
Updating the ZEKExx Options Member (SECWARN)

The ZEKExx PARMLIB options member provides the startup option SECWARN,
which assists you in converting from Zeke 5.6 or earlier. These are the valid values:
Option
Description
SECWARN=YES
Enables internal security tracing. When both of these conditions exist, Zeke
allows actions that normally would be disallowed by internal security in the
earlier Zeke release:
The source of the action is other than the Zeke online system (e.g., a
batch command, the system console, a Zeke API, etc.)
The associated MVS user ID does not match an operator record in the
Zeke database.
When internal security allows an action based on this option, Zeke issues
warning messages that enable you to make necessary changes to your
internal security setting during the conversion process.
For example:
Z151NW SECWARN=YES ZEKE INTERNAL SECURITY RC CHANGED FROM
DENY TO ALLOW
Z151OW SRC=BATCH,TYP=Z,USER=OP0005
,OPERATOR=NEWOPR
Note:
During startup of the Zeke started task, messages are issued to remind you
that this security option is activated.
After all security records have been reviewed (and updated, if necessary)
according to the internal security rules in Zeke 6.0 and later, you can change
this setting to SECWARN=NO to disable internal security tracing for future
startups.
SECWARN=NO
Default. Disables internal security tracing; Zeke operates according to

normal internal security rules.
Setting the Internal Security Generation Options

This section explains how to access and update these generation options that control Zeke
internal security processing:
Option
Description
Batch function security requirements:

SecFail
Indicates the action for Zeke to take if batch security verification fails.
381
Option
Description
Online facility security requirements:

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

If Reqopid is set to Y, Zeke requires a matching operator ID to grant a user
access to the Zeke online system.
If Reqopid is set to N, Zeke grants an unknown user access to the Zeke online
system based on the default operator ID.
Caution! Do not change ReqOpid to Y unless at least one operator ID is

defined to Zeke with at least WRITE authority for the security
function. Otherwise, all users are denied access to the Zeke online
system.
SecExitw=xxxx Number of bytes of storage allocated to call the Zeke security exit routine
(ZEKE15B).
To set the internal security options

1
From the Zeke Primary Menu, enter option 6. The Security Control Functions
ASG-Zeke
Option ===>
1
2
3
X
382
Operators
Classes
ExtSec
Return
List Operator Information by Operator ID

List Class Information by Class ID
External Security Interface (ESI) Customization
Return to main Zeke menu
9 Security
Enter 1 on the Option line, and press Enter. The Directory of Operator IDs screen
is displayed:
ASG-Zeke
Directory of Operator IDs
Command ===> ADD
Operator ID: SECADMIN
Line Commands: E - Edit B - Browse C - Copy
Operator ID
Class
Date
Added
DVNEKG
A
08/30/2007
DVNEKG1
B
09/06/2007
OPERATOR
A
09/19/2006
SPTLRS1
B
06/18/2012
******************************* Bottom of
Row 1 to 4 of 4
Scroll ===> PAGE
D - Delete
Date Last
Updated
04/17/2008
05/29/2012
08/30/2007
06/18/2012
data ********************************
Enter ADD on the Command line.
Specify the new default operator ID in the Operator ID field.
Press Enter. The Operator Detail screen is displayed:

ASG-Zeke
Command ===>
Operator Detail
ADD
Scroll ===> PAGE
CAPS ===> ON

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
In the Class ID field, enter a valid class ID (see Defining Operator Records on
page 389), or keep the default class A, and press Enter. By default, this class record
enables access to all Zeke functions and operator commands (unless the specified
class has been modified).
383
From the Zeke Primary Menu, enter option 4.1. The GENOPTs Directory screen
displays a listing of all GENOPTs in the Zeke database:
ASG-Zeke
Command ===>
GENOPTs Directory
Row 1 to 4 of 4
Scroll ===> CSR
Zeke System:
System
* Description
Last updated by
- -------- - -------------------------------- ---------------------------*ACTIVE
*ZEKEUP* 01/10/2012 13:21:28
*GLOBAL
ZEKEUSER 12/05/2011 19:14:48
ZEK60JOB 11/29/2011 15:53:54
********
*DBCNVT* 11/10/2011 13:05:28
******************************* Bottom of data *******************************
Enter E to the left of the GENOPT with the system name *GLOBAL (which
contains the security options), and press Enter.
The Generation Options EDIT screen is displayed with the options in alphabetical
order:
ASG-Zeke
Command ===>
Generation Options
Zeke System: *GLOBAL
Description: Zekeplex global options
Option
--------Abhold:
AddInact:
AuditCls:
AuditCmd:
AuditCnd:
AuditEcd:
AuditEmr:
AuditEvt:
AuditGop:
AuditNam:
AuditOpr:
AuditPas:
AuditPin:
AuditPoo:
AuditRes:
AuditSqr:
AuditVar:
Row 1 to 17 of 143
Scroll ===> CSR
Description
--------------------------------------------------------(Y,N)
Yes to hold recurring events if abended
(Y,N)
Yes to allow ZADD of inactive event
(Y,N)
Yes to log Security Class changes
(Y,N)
Yes to log Zeke operator commands
(Y,N)
Yes to log Calendar changes
(Y,N)
Yes to log ESI Class changes
(Y,N)
Yes to log EMR changes
(Y,N)
Yes to log event flow
(Y,N)
Yes to log Generation Option (GENOPT) changes
(Y,N)
Yes to log Name/Address changes
(Y,N)
Yes to log Zeke Operator changes
(Y,N)
Yes to log Zeke Operating Password changes
(Y,N)
Yes to log Partition/Initiator changes
(Y,N)
Yes to log Pool changes
(Y,N)
Yes to log Resource changes
(Y,N)
Yes to log SQR changes
(Y,N)
Yes to log Variable changes
To quickly find the options in the security category, you can use these primary
commands (see Viewing GENOPT Details on page 283 for more information):
a
384
Value
---------N
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
EDIT
Enter CAT ON on the Command line, and press Enter to switch to category
view.
9 Security
Enter LOC SEC on the Command line, and press Enter to scroll to the
security options.
Or
To quickly find a particular field, you also can use the primary commands FIND (a
string) or LOCATE (a line containing a string). For example, either of these
commands would scroll to the DefOpid field:
LOC DEFO
FIND OPID
Or, you can simply use the F8 (down) and F7 (up) keys to scroll, as necessary.
This is an example of the detail view by category for the same GENOPT:
ASG-Zeke
Command ===>
Generation Options
EDIT
Row 116 to 132 of 154

Scroll ===> CSR
Option
Value
--------- ---------====================
BatOprid: BATCH
BatSec: N
DefOpid: OPERATOR
ESIActv: N
Description
--------------------------------------------------------Security ================================================
(xxxxxxxx) Default security batch operator id (VSE)
(Y,N)
Yes for Zeke to perform batch security (VSE)
(xxxxxxxx) Default operator id (MVS), online only (VSE)
(Y,N)
Yes to activate External Security Interface
(SAF)
ReqOpid: N
(Y,N)
Yes to require authorized operator id for
logon
SecFail: C
(C,I)
C(ancel) or I(gnore) if batch security fails
SecHide1: N
(Y,N)
Yes to hide records when access is denied
SecHide2: N
(Y,N)
Yes to hide sub-records when access is denied
SecSel: Y
(Y,N)
Yes to security check using select criteria
SecUInit: N
(Y,N)
Yes to init event UserID and SecGroup fields
SecULock: N
(Y,N,E)
Lock event UserID and SecGroup fields
Y(es), (N)o, E(SI-controlled)
==================== Traces ==================================================
==================== User Interface ==========================================
10
To require that a user is defined in the Zeke database as an Zeke operator ID before
access to the Zeke online system can be granted, locate or scroll to the ReqOpid field.
Enter Y in the ReqOpid field and press Enter (see ReqOpid on page 382 for more
information).
Or
To allow access for users who are not defined to Zeke, take these actions:
385
11
Locate or scroll to the DefOpid field, specify a valid operator ID (see Defining
Operator Records on page 389), and press Enter. Because the default value
OPERATOR specifies the operator ID that Zeke uses associates with any user
that accesses a system console without a logon requirement, ASG recommends
that you define a separate operator ID to use as the DefOpid value
Verify that the ReqOpid field is set to N.
Specify whether that you want to cancel a batch job when an unauthorized request is
encountered:
a
Locate or scroll to the SecFail field.
To specify that the job be cancelled, enter C.

Or
To specify that the unauthorized request be ignored and for processing to

continue with the next input statement, enter I.
c
Press Enter.
12
If you plan to use a ZEKE15B user security exit, locate or scroll to the SecExitw
field. Specify the number of bytes of storage allocated to call the security exit routine
(ZEKE15B), and press Enter.
13
To activate the updated options, enter ZRELOAD GENOPT on the Command line,
and press Enter.
Defining Class Records

A class ID is used to grant or deny access to specific online functions and operator
commands for a group of operator IDs.
The default class ID is A (which allows WRITE access to all online functions and
operator commands); however, ASG recommends that this level be reserved for the Zeke
security administrator.
386
9 Security
To create or maintain class records

1
From the Zeke Primary Menu, enter option 6.2. The Directory of Command
Classes screen is displayed:
ASG-Zeke
Command ===>
Directory of Command Classes
Row 1 to 2 of 2
Scroll ===> PAGE
Class ID==>
Class
Event
Zcom Cal
Opt
Work Sec
Doc
Var
E - Edit
Res
A
W
W
W
W
W
W
W
W
W
B
W
N
W
W
W
W
W
W
W
***************************** Bottom of data ******************************
Desired Result
Action
Add a new class ID

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.
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.
387
The Class Detail screen is displayed:

ASG-Zeke
Command ===>
Class Detail
EDIT
Class Id: A
Allowed functions
Event
- W
Zcom
- W
Calendar - W
Options - W
Restart - W
Schedule
ZADD
ZALTER
ZDELETE
ZDISABLE
ZDISPLAY
ZENABLE
ZHOLD
388
BROWSE
CANCEL
Work CenterSecurity
Document
Variable
-
W
W
W
W
COPY
DELETE
EDIT
(R=Read only
W=Write allowed)
(A=Auto entry in write mode)
(N=Not allowed)
control (OPERATOR) commands allowed (Y=Yes, N=No)

- Y
ZID
- Y
ZSET
- Y
ZKILL
- Y
ZSTATUS - Y
ZMAP
- Y
ZSCAN
- Y
ZOK
- Y
ZRESOURCE DISPLAY - Y
ZREFRESH - Y
ZRESOURCE ALTER
- Y
ZRELEASE - Y
ZRESOURCE RELEASE - Y
ZRELOAD - Y
ZPLEX
-
Y
Y
Y
Y
Y
Y
Y
To the right of each function (the main Zeke online functions are shown on this
screen), specify the level of access allowed for this class ID. These are the valid
authority level codes:
Code
Meaning
(WRITE allowed) Zeke allows an operator assigned to this class to browse

and maintain records in this online function.
(READ only) Zeke allows an operator assigned to this class to browse records
in this online function. Not valid for the work center function.
(Not allowed) Zeke denies access to this online function by an operator

assigned to this class.
(Auto entry in WRITE mode) Zeke displays the first screen in this online
function when the operator logs on. You can assign this code to only one
online function.
To the right of each operator command, specify whether access is allowed for this
class ID. These are the valid codes:
Code
Meaning
Allow an operator assigned to this class to execute this command.
9 Security
Code
Meaning
Default. Do not allow an operator assigned to this class to execute this

command.
Note:
You can further limit access to the online functions as granted by the class ID. To
do so, you can specify user IDs on the operator record (see Defining Operator
Records on page 389 for more information).
5
Defining Operator Records

Operator records control access to the various types of database records (e.g., SQRs,
EMRs, work centers, documentation, and variables).
You assign an operator ID to each authorized user and assign each operator ID to a class
that specifies the functions and commands that are allowed for users with that operator
ID. You can restrict access further by the user ID (which controls user access to specific
event and variable records).
To create or maintain operator records

1
From the Zeke Primary Menu, enter option 6.1. The Directory of Operator IDs
ASG-Zeke
Command ===>
Directory of Operator IDs
Row 1 to 1 of 1
Scroll ===> PAGE
Operator ID:
Line Commands: E - Edit B - Browse C - Copy
Operator ID
D - Delete
Class
Date
Date Last
Added
Updated
OPERATOR
A
01/16/2012
01/30/2012
L003J
A
01/24/2012
02/04/2012
****************************** Bottom of data *****************************
389
Desired Result
Action
Add a new operator ID

2 Specify the new operator ID in the Operator ID field.
3 Press Enter.
Go to step 3.
1 Enter E to the left of the operator ID to update.
Update an existing operator ID
2 Press Enter.
Go to step 3.
1 Enter C to the left of the operator ID to copy and
press Enter.
Copy an operator ID
2 Specify the new operator ID in the Operator ID field

and press Enter.
1 Enter D to the left of the operator ID to delete and
press Enter.
Delete an existing operator ID
2 Enter DELETE on the Command line to confirm and

press Enter.
The Operator Detail screen is displayed:

ASG-Zeke
Command ===>
Operator Detail
ADD
Scroll ===> PAGE
CAPS ===> ON

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
********
390
Zcom
Event
Work
Documentation
W
Variable
W
In the Class ID field, specify the ID of the class to which you want to assign this
operator.
9 Security
Note:
The default class ID is A (which allows WRITE access to all online functions and
operator commands). ASG recommends that this level be reserved for the Zeke
security administrator. See Defining Class Records on page 386 for information
on defining class IDs.
4
In the User ID field, enter a user ID to either limit or grant access to Zeke database
records. You can enter a specific or a generic user ID or mask (e.g. you could specify
PAY***** to control access to all events with a user ID beginning with PAY). You
can enter ******** to grant access to all events.
Zeke supports mixed-case user IDs. You can use the ISPF command CAPS to
toggle between mixed and upper case modes. The current mode is displayed in the
upper right portion of the screen.
The authorized user IDs are checked in columnar sequence. For example, you could
allow access to user ID BILL0501, but deny access to any other user ID beginning
with BILL. To do so, you would enter user ID BILL0501 early in the list
(allowing access), and then enter user ID BILL**** later in the list (denying
access).
Zeke also enables you to specify blank user IDs (i.e., composed of all spaces) in
operator records, and allows user ID masks containing leading spaces, embedded
spaces, trailing spaces, or all spaces.
Note:
When you create variables with a blank user ID, you must specify the blank user ID
to have WRITE access to variables and work centers.
5
Below each online function, indicate the level of authority access. These are the valid
codes:
Code
Meaning
(WRITE allowed) Zeke allows users assigned to this operator ID to browse and
maintain records using this online function.
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.
(Not allowed) Zeke denies users assigned to this operator ID access to this
online function.
391
External Security
Zeke external security offers added benefits over internal security by enabling more
comprehensive security at a more detailed level and providing more flexibility in
establishing access criteria.
Zeke uses ESI to pass security information to the SAF security interface. This enables
you to use a third-party security product (e.g., RACF or CA-ACF2) to control access to
resources for specific Zeke functions. You must have installed and be familiar with your
external security package before using this option. Also, be familiar with Zeke internal
security because you can use a combination of internal and external security for your
system. See Zeke Security Processing on page 372 for an overview.
External security is primarily object-oriented. Its main focus is securing the data
structures that contain the Zeke information, as opposed to securing the processes or
functions used to access those structures. A few external security classes are
function-oriented because, in certain situations, securing a process could be more
appropriate than securing the structure. This provides you the flexibility to set up the
most effective security system for your environment.
For example, access to SQRs can be controlled by function (where access to the ZCOM
online screen and the Zeke operator commands is restricted) or by object (where access to
the SQRs themselves is restricted). Access to both functions and objects is controlled by a
security class. Because privileges and restrictions provided by classes could overlap, it
typically is not necessary to activate all classes to achieve the desired security level.
Note:
The term class has different meanings in internal and external security; the types of
classes used for internal and external security are unrelated.
As another example, Zeke variables can be accessed using any of these methods:
The Variable option in the online system
A Zeke command (ZSET VAR)
The ZEKESET program (SET VAR)
Completion of a work center
These are some of the different ways you could secure access to variables:
392
Using the Z$VAR class secures access to variable records that is attempted by
requests made through the online system, a Zeke command, the ZEKESET
program, or by completion of a work center.
Using the Z$ONLINE class controls who can access the ZCOM, variable, and work
center menu options in the online system.
9 Security
Using the Z$SET class controls who can issue the special commands available in
the ZEKESET utility program.
Using the Z$CMD class controls who can issue certain commands.
Security Classes and Resource Names

In external security, classes are used to identify each resource type. The internal class
name is used for all references to that resource type in ESI (e.g., documentation,
messages, and commands) and cannot be changed. For example, the internal class name
for EMRs is Z$EMR.
Each class has a resource name format that contains the information that is used to make
the security decisions. The resource name can be broken down into elements. When the
resource name is built for the SAF call, the value of the element is inserted into the
resource name.
The eligible elements for each class are listed on the X1FOFSEL page of the ESI
Customization screen. These are the types of resource name elements:
Element Type Description
Fields
Most elements that can be a part of the resource name are fields in the records
being secured. For example, for the class that secures the EMR (Z$EMR),
the eligible elements would include EVENTNAME, APP, and GROUP.
Structures
Some elements are structures that are associated with the Zeke database (e.g.,
catalog ID and the system where Zeke are running).
Constants
These elements get their values from a set of constants applicable to that
element (e.g., the source of the request). If a command is entered from the
console, the source is CONSOLE. Likewise, if a command is entered
through the ZCOM function, the source is ONLINE.
User-defined
User-defined constants and delimiter characters are also eligible elements.
393
These are the most commonly used elements:

Element
Description
Catalog ID
Unique, catalog identifier (up to eight characters long) determined when the
Zeke database is created. The catalog ID appears after the word CATID in
the last line of output from a ZID command. Once created, the catalog ID
cannot be changed, even if the database is restored from a backup dataset.
Command
Command verb issued. For example, Z$CMD class (e.g., ZID, ZDISPLAY,
ZALTER, etc.) or Z$SET class (e.g., SET, CDATE, etc.).
When a command verb element is used in the resource name for a security
class, only the command name is included in the security call made by the
Zeke command processor, not the command text.
Command code
394
Type of command issued from an SCOM event. These are the valid codes:
C
System command
System response (VSE only)
Zeke command
VM command
VSE/POWER command
Command text
Full text of an entered command.
Function
Name of the online function to which access is being requested.
Record type
Subordinate record type to which access is requested (e.g., JCL or DOC are
sub-records for an EMR).
Source
Source of the request that caused the security call to be made (e.g., if a
command is entered from the console, then the value of the source field is
CONSOLE.)
Subsystem name
OASIS subsystem under which this Zeke system is running. Multiple

subsystems enable the user to run more than Zeke system on the same
operating system. This value is displayed in ZID command output.
9 Security
These are the Zeke security classes, along with their resource names and authority levels
(see Authority Levels on page 372 for an explanation of the different authority levels
by class):
Zeke Security Classes
Class
Description
Authority Levels
Z$ACCESS
Controls these types of requests or behaviors:
GENERICS
(READ access required)

Use of generic selection criteria (e.g., for application ID,
group ID, system ID, or user ID).
Resource name: SCHEDULE.GENERICS
ACTIVATE
(ALTER access required)

EMRFIELD
Use of the CLEAR keyword with the SCHEDULE function. (UPDATE access required)
Resource name: SCHEDULE.CLEAR
Whether selected EMR fields are locked and unable to be
modified (i.e., the SecULock generation option is set to E).
Resource name:
EMRFIELD.fieldname.subsysname.userid.applid.
grpid.eventname.eventtype
Z$CATAL
Secures access to the database as a whole.
READ
Resource names:
(enables STATUS and

BACKUP functions)
CREATE
BACKUP
RESTORE
STATUS
BLOCK
CLEARCPU
Z$CLASS
Secures access to Zeke internal security class records.
ALTER
(enables CREATE, RESTORE,
and BLOCK functions)
READ/UPDATE/ALTER
Resource name: Zeke-catalog-ID

Z$CMD
Secures access to Zeke operator commands.
READ
Resource name: command-verb

Z$CND
Secures access to calendar records.
READ/UPDATE/ALTER
Resource name: calendar-ID

Z$DOWNLD
Secures access to the schedule download agents list.
READ/UPDATE/ALTER

Z$ECDR
Secures access to the external class definition records (ECDRs). READ/UPDATE/ALTER

395
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

Z$NAME
Secures access to the customer name records.
READ/UPDATE/ALTER

Z$ONLINE
Secures access to the Zeke online functions. Typically, this

option is not necessary if all of the desired records have been
secured.
READ
Note:
Options to which you do not have access are not displayed on
the Zeke Primary Menu.
UPDATE
(enables READ mode for that

section of the online)
(enables WRITE mode)
Resource name: menu-option-name

Z$OPER
Secures access to operator records used in internal security.
READ/UPDATE/ALTER

Z$PASS
Secures access to the operating passwords.
READ/UPDATE/ALTER

Z$PINT
Secures access to the partition/initiator records.
READ/UPDATE/ALTER

Z$POOL
Secures access to the pool definition records.
READ/UPDATE/ALTER

Z$RESRC
Secures access to the resource definition records.

396
READ/UPDATE/ALTER
9 Security
Class
Description
Authority Levels
Z$SCHED
Secures access to the SCHEDULE function.
READ
(if ACTIVATE is not specified)

Note:
Object-oriented security is not applied because a security call
would be required for each attempt to access a record.
ALTER
(if ACTIVATE is specified)
Because the SCHEDULE function involves reading all EMRs,

calendars, and variables in the Zeke database, then creating
SQRs, the resulting number of security calls have a substantial
impact on performance.
Resource name: user-ID
Note:
Parameters provided by the user are used to build the resource
name for one SAF call.
Z$SET
Secures access to the ZEKESET functions.
READ
Resource name: command-verb

Z$SIM
Not used. (Zeke simulation)
n/a

Z$SQR
Secures access to the SQRs.
READ/UPDATE/ALTER

Z$VAR
Secures access to variables.
READ/UPDATE/ALTER

Z$XCOM
Secures access to individual commands within an SCOM event. CONTROL

Resource name: command-code
397
Implementing External Security

ASG recommends fully implementing external security for a single internal class before
implementing ESI for other classes. This enables you to complete the implementation
process (including testing) for a smaller segment of your Zeke system before performing
a large-scale implementation.
ASG also recommends that you activate all classes initially (except for the Z$ONLINE
class). After some use and testing, you might want to deactivate or combine some classes
into the same external class name, or you might want to activate the Z$ONLINE class.
Modifying ESI Classes

All of the ESI classes provide the flexibility of changing the external class name, the
process option, and the resource name format (except for the Z$CATAL class). The
default external class name for all classes is the same as the internal class name, and the
default process option for all classes is N4 (except for the Z$CATAL class).
The Z$CATAL class is unique in that the external class name, the process option, and the
resource name format cannot be changed. Because this class incorporates functions such
as a database RESTORE and CREATE, the SAF call is fixed to ensure that the database
as a resource is secure under all conditions.
Before making any changes to the external security screens in the Zeke online system,
review the ESI chapter of the ASG-OASIS for z/OS Reference Guide (particularly the
section about setting up ESI).
398
9 Security
To modify ESI class definition records

1
From the Zeke Primary Menu, enter option 6.3. The ESI Customization screen
displays the X1SELECT page:
ESI Customization
BROWSE
SCROLL ===> PAGE X1SELECT
COMMAND ===>
Primary Commands: DOWN UP EDIT BROWSE END RETURN

Line Commands: F - Resource name format
C - Copy to discrete ECDR
D - Delete discrete ECDR
System
"Copy to"
System
********
********
********
********
********
********
********
********
********
********
********
********
********
********
Internal
Class
External
Class
Process
Option
Z$ACCESS
Z$CATAL
Z$CLASS
Z$CMD
Z$CND
Z$DOWNLD
Z$ECDR
Z$EMR
Z$GOPT
Z$NAME
Z$ONLINE
Z$OPER
Z$PASS
Z$PINT
Z$ACCESS
Z$CATAL
Z$CLASS
Z$CMD
Z$CND
Z$DOWNLD
Z$ECDR
Z$EMR
Z$GOPT
Z$NAME
Z$ONLINE
Z$OPER
Z$PASS
Z$PINT
N4
Y4
N4
N4
N4
N4
N4
N4
N4
N4
N4
N4
N4
N4
Each line represents an ESI class definition record that is uniquely defined by the
system ID and the internal class name.
2
Perform these actions (depending on the desired result):

Desired Result
Action
Change the external class

name
1 Enter EDIT on the Command line, and press Enter.

2 In the External Class field for the class to change, specify
the new external class name (which must also be defined
in your external security product) that is used for SAF
calls.
3 Press Enter.
Go to step 6.
399
Desired Result
Action
Copy a class record with

1 Enter C to the left of the record to copy.
all of its attributes to
2 Specify the new system ID in the Copy to System field.
another system (that shares
the same Zeke database)
3 Press Enter.
4 Perform any additional actions in this table (depending on
the desired result) to customize the new class record.
Go to step 6.
Delete a class record with
all of its attributes
Enter D to the left of the record to delete, and press Enter.

Go to step 6.
Note:
You cannot delete class records for the default system (********).
Change the process option
for a security class
Note:
If you change the external class name or resource name
format, keep the process option set to N4 until you have
tested the implementation.
2 Specify the process option in the Process Option field for
the class to change. These are the valid process options:
400
N0
Do not call SAF. Grant all access requests.
N4
Do not call SAF. Use internal security to

determine whether to grant the access request. If
internal security has not been implemented, grant
access.
N8
Do not call SAF. Deny all access requests.
Y0
Call SAF. If the SAF return code is 4, grant the

access request.
Y4
Call SAF. If the SAF return code is 4, use internal

security to determine whether to grant the access
request. If internal security has not been
implemented, grant access.
Y8
Call SAF. If the SAF return code is 4, deny the

access request.
9 Security
Desired Result
Action
3 Press Enter.
Go to step 6.
Change the resource name

format for a security class
Enter F to the left of the class name to change, and press

Enter.
Go to step 3.
The ESI Customization screen displays the X1FRMAT1 page with the current list
of elements for the specified resource name format. This example shows the default
resource name format for the Z$EMR class:
********.Z$EMR/Z$EMR
COMMAND ===>
ESI Customization
Primary Commands: DOWN UP EDIT BROWSE RESET

Line Commands: A - Insert element after
D - Delete element
BROWSE
SCROLL ===> PAGE X1FRMAT1
END RETURN CANCEL
B - Insert element before
--+---1----+----2----+----3----+----4----+----5----+----6----+----7---+--8
aaaaaaaa.bbbbbbbb
Start
a
001
.
001
b
001
**END**
Length
008
001
008
Field Description
3 elements
User ID
Delimiter character
Record type
Perform the steps in the Action column (depending on the desired result)
Desired Result
Action
Add an element

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.
Add the new element before the selected element.
3 Press Enter.
Go to step 4.
401
Desired Result
Action
Change a portion of an
element to be included in
the resource name format

2 Specify the beginning position in the Start field.
3 Specify the element length in the Length field.
For example, if the element value is ABCDEDFG (i.e.,
has a start position of 1 and length of 8), and that you
want to select CDE as the new value, enter 3 in the
Start field and 3 in the Length field.
Go to step 6.
Restore the resource name

format to the default
If you have saved changes to the format and want to cancel

them, Enter RESET on the Command line, and press Enter.
Exit screen without saving

changes made to the
format
If you have made changes to the format that you do not want
to keep and have not saved them, Enter CANCEL on the
Command line, and press Enter.
Delete an existing element 1 Enter EDIT on the Command line, and press Enter.
2 Enter D to the left of the element that you want to delete.
3 Press Enter.
Go to step 6.
The ESI Customization screen displays the X1FOFSEL page with a list of eligible
elements for this class. This example shows the eligible fields for the Z$EMR class:
********.Z$EMR/Z$EMR
COMMAND ===>
ESI Customization
EDIT
SCROLL ===> PAGE X1FOFSEL
Primary Commands: DOWN UP END RETURN

Line Commands: C - Copy field
Length
001
1-8
008
008
003
012
008
008
004
008
008
008
007
002
008
004
402
Field Description
Delimiter character
Literal value ===> __________
User ID
Application ID
Group ID
Event name
Job name
System name
Event type
Record type
Target
Platform
Source
Disaster recovery level
Zeke internal catalog ID
Subsystem name
(quoted)
9 Security
To add the element to the resource name format, enter C to the left of the desired
element and press Enter.
After all the desired elements are included in the resource name format, press F3.
For each class that you updated, issue the OASIS operator command RELOAD to
replace the in-storage ESI class definition record. Include the corresponding internal
class name for the record to be replaced. For example, this command reloads the
Zeke operator commands:
XRELOAD ECDR Z$CMD
Activating ESI
To activate ESI
1
From the Zeke Primary Menu, enter option 4.1. The GENOPTs Directory screen
displays a listing of all GENOPTs in the Zeke database:
ASG-Zeke
Command ===>
GENOPTs Directory
Row 1 to 4 of 4
Scroll ===> CSR
Zeke System:
System
* Description
Last updated by
- -------- - -------------------------------- ---------------------------*ACTIVE
*ZEKEUP* 01/10/2012 13:21:28
*GLOBAL
ZEKEUSER 12/05/2011 19:14:48
ZEK60JOB 11/29/2011 15:53:54
********
*DBCNVT* 11/10/2011 13:05:28
******************************* Bottom of data *******************************
Enter E to the left of the GENOPT with the system name *GLOBAL (which
contains the security options) and press Enter.
403
The Generation Options EDIT screen displays the options in alphabetical order:
ASG-Zeke
Command ===>
Generation Options
Option
--------Abhold:
AddInact:
AuditCls:
AuditCmd:
AuditCnd:
AuditEcd:
AuditEmr:
AuditEvt:
AuditGop:
AuditNam:
AuditOpr:
AuditPas:
AuditPin:
AuditPoo:
AuditRes:
AuditSqr:
AuditVar:
Value
---------N
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
EDIT
Row 1 to 17 of 143
Scroll ===> CSR
Description
--------------------------------------------------------(Y,N)
Yes to hold recurring events if abended
(Y,N)
Yes to allow ZADD of inactive event
(Y,N)
Yes to log Security Class changes
(Y,N)
Yes to log Zeke operator commands
(Y,N)
Yes to log Calendar changes
(Y,N)
Yes to log ESI Class changes
(Y,N)
Yes to log EMR changes
(Y,N)
Yes to log event flow
(Y,N)
Yes to log Generation Option (GENOPT) changes
(Y,N)
Yes to log Name/Address changes
(Y,N)
Yes to log Zeke Operator changes
(Y,N)
Yes to log Zeke Operating Password changes
(Y,N)
Yes to log Partition/Initiator changes
(Y,N)
Yes to log Pool changes
(Y,N)
Yes to log Resource changes
(Y,N)
Yes to log SQR changes
(Y,N)
Yes to log Variable changes
To quickly find the options in the security category, you can use these primary
commands (see Viewing GENOPT Details on page 283 for more information):
a
Enter CAT ON on the Command line, and press Enter to switch to category
view.
Enter LOC SEC on the Command line, and press Enter to scroll to the
security options.
Or
To quickly find a particular field, you also can use the primary commands FIND (a
string) or LOCATE (a line containing a string). For example, either of these
commands would scroll to the DefOpid field:
LOC DEFO
FIND OPID
Or, you can simply use the F8 (down) and F7 (up) keys to scroll, as necessary.
404
9 Security
This is an example of the detail view by category for the *GLOBAL GENOPT:
ASG-Zeke
Command ===>
Generation Options
EDIT
Row 116 to 132 of 154

Scroll ===> CSR
Option
Value
--------- ---------====================
BatOprid: BATCH
BatSec: N
DefOpid: OPERATOR
ESIActv: N
Description
--------------------------------------------------------Security ================================================
(xxxxxxxx) Default security batch operator id (VSE)
(Y,N)
Yes for Zeke to perform batch security (VSE)
(xxxxxxxx) Default operator id (MVS), online only (VSE)
(Y,N)
Yes to activate External Security Interface
(SAF)
ReqOpid: N
(Y,N)
Yes to require authorized operator id for
logon
SecFail: C
(C,I)
C(ancel) or I(gnore) if batch security fails
SecHide1: N
(Y,N)
Yes to hide records when access is denied
SecHide2: N
(Y,N)
Yes to hide sub-records when access is denied
SecSel: Y
(Y,N)
Yes to security check using select criteria
SecUInit: N
(Y,N)
Yes to init event UserID and SecGroup fields
SecULock: N
(Y,N,E)
Lock event UserID and SecGroup fields
Y(es), (N)o, E(SI-controlled)
==================== Traces ==================================================
==================== User Interface ==========================================
For the ESIActv generation option, set the value to Y to activate ESI.
For the DefOpid generation option, specify the default Zeke operator ID to be
assigned when an undefined operator logs on (see DefOpid on page 382 for more
information).
Although DefOpid applies solely to internal security, it must be set when activating
ESI even if you plan to use only external security. This is because the ESI process
option provides for the possibility to revert to internal security under certain
circumstances. In such a case, the default operator ID is required. This operator ID
must be supplied to Zeke during log-on. If you plan to use ESI exclusively, it is not
important what level of authority is assigned the default operator ID. If you intend to
use internal security with external security, set it to the default level of authority.
Security verification for batch functions is enabled by default. Determine how to

proceed when an unauthorized request from a batch job is encountered:
To cancel the batch job, verify that the SecFail option is set to C.
To ignore the unauthorized request and continue processing with the next
input statement to that batch program, verify that SecFail is set to I.
405
Determine whether to enable primary records (e.g., events) to be displayed for users
that have been denied access:
To display primary records, verify that the SecHide1 option is set to N.
To hide primary records, verify that SecHide1 is set to Y. Any Zeke online
screen that displays a directory of records will only display those records for
which the user has at least READ access.
Determine whether to enable subordinate records (e.g., WHEN conditions) to be

displayed for users that have been denied access:
To display subordinate records, verify that the SecHide2 option is set to N.
To hide subordinate records, verify that SecHide2 is set to Y. Any Zeke

online screen that displays a directory of records will only display those
subordinate records for which the user has at least READ access.
For example, when as asterisk (*) is displayed in the DOC column on the
Event Master Directory screen, this indicates a subordinate record exists for
the EMR.
To activate the updated options, enter ZRELOAD GENOPT on the Command line,
and press Enter.
10
If you have not defined the external class name, see Modifying ESI Classes on
page 398.
You now are ready to test the implementation. For information on testing ESI with
ESITRACE, see the ASG-OASIS for z/OS Reference Guide.
406
Zeke Web Services
Chapter 10:
10
Zekes Web Services enable you to access to work center functions from a Web browser
instead of requiring you to establish access to Zeke through an online facility (e.g., TSO
or ISPF) or an OpsCentral client. This chapter discusses these topics:
Topic
Page
Web Services Overview
407
Accessing Zeke Web Services

Setting Zeke Web Services as Your Home Page
408
409
Managing Work Centers from the Web

Accessing Scheduled Work Centers
Creating and Maintaining Custom Views
Completing a Work Center
Enabling or Disabling a Work Center
Refreshing a Work Center
409
409
412
418
423
424
Web Services Overview

Web Services takes advantage of the Zeke server to enable remote access to Zeke from a
Web browser using Hypertext Transport Protocol (HTTP).
The Zeke server is a subtask that runs in the Zeke address space and includes an
embedded HTTP/HTTPS server to provide Web Services. The Zeke server accepts
requests and responds with dynamic XML data and static documents (i.e., CSS, GIF,
ICO, JS, XSL). A Web browser, or an application such as ASGs Business Service
Platform (BSP) Enterprise Workload Automation solution, processes the XML data to
create dashboard-type objects to provide an overview of the systems you are monitoring.
Access to Zeke through a Web browser can be secured (i.e,. through SAF) or unsecured
(i.e., controlled based only on the default operator ID).
See the ASG-Zeke Scheduling for z/OS Installation Guide for details on configuring the
Zeke server to enable Web Services.
407
Accessing Zeke Web Services

Before you begin, be sure the system and setup requirements have been met and that the
Zeke server has been enabled and configured for HTTP/HTTPS. See the ASG-Zeke
Scheduling for z/OS Installation Guide for details.
To access Zeke Web Services

1
Point your Web browser to this URL:

http://your.mainframehost:nnnn/zeke/
where:
your.mainframehost is the host name or IP address for Zeke Web services.
nnnn is the port number for Zeke services.
Note:
These values are defined as environment variables in the ZENVIRN environment

file. See the ASG-Zeke Scheduling for z/OS Installation Guide for details.
2
If an authentication process is in force for allowing access to Zeke, a prompt appears

and requests your mainframe user ID and password. Enter your mainframe user ID
and password.
The Zeke Web Services home page appears and lists the available Zeke functions:
From this page, you can access either the list of scheduled work centers or the page
for maintaining custom views of the work center list.
See Managing Work Centers from the Web on page 409 for detailed procedures.
408
10 Zeke Web Services
Setting Zeke Web Services as Your Home Page

You can set the Zeke Web Services home page as your default home page.
To set Zeke Web Services as your home page
In the server root path, create an index.html document with these contents:
<!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.
Managing Work Centers from the Web

Zeke Web Services enable you to view and manage Zeke work center events from a Web
browser.
A work center is a special type of event that is not dispatched by Zeke and requires
operator intervention. Typically, work centers are prerequisites for other events. For a
complete discussion on work center events (including how they are defined and the types
of functions they can perform), see Work Centers on page 149.
Accessing Scheduled Work Centers

This section explains how to access schedules work centers through Zeke Web Services.
To access the work centers list

1
Start the Web interface as described in Accessing Zeke Web Services on page 408.
From the Zeke Web Services home page, click Work Center List.
409
The system default view appears:
By default, the list shows all work centers in the current schedule. You can sort any
column (in ascending or descending alphanumeric order) by clicking on the column
heading.
You can use these additional options to control which information is displayed (and
how it appears):
Filters enable you to narrow down the number of work centers in the list only
to those that meet specific criteria (e.g., a specific completion status).
You can display or hide particular columns and change how they are sorted by
default.
See Creating and Maintaining Custom Views on page 412 for instructions on
creating and customizing different views.
410
These are the default column headings:

Heading
Description
Status
Status of the work center activity. These are the valid statuses:
(gray) Not done
(green) Pending
(yellow) Disabled
(blue) Completed
Note:
You also can move your cursor over a status icon for a verbal status.
Event
Event number. You can click the event number to access the work
center details and documentation.
Appl
Application ID.
Group
Group ID.
Event Name
Event name.
System
System ID.
Version
Event version number.
Sched Time
Schedule time.
Sched Date
Schedule date.
From the Work Center List, you can access and edit the attributes of the current
view (see Updating a View on page 416), delete it (see Deleting a View on
page 418), or create a new view using any existing view as a template (see
Creating a New View on page 412).
To switch to a different view
Select an existing view from the Views: drop down list, and click Select.
411
Note:
Views are listed according to their name and whether they are defined for use by the
current user only or by all users. View names are displayed like this:
viewname:viewdescription
For example:
WC:Not Done Only
After you select a different view, you can view the work center list under this view,
edit the view (see Updating a View on page 416), use it as a template for creating
a new view (see Creating a New View on page 412), or delete it (see Deleting a
View on page 418).
Creating and Maintaining Custom Views

A view controls the types of information that are shown for the work centers in the list.
You can create a custom view and indicate which column headings you want to appear in
that view (and in what sequence you want them to appear). You can create and save
multiple views for later use, and easily switch between different views. A view can be
defined and saved for use only under a particular user ID or it can be shared by multiple
users.
A filter controls which work centers are selected for display. You can create custom
filters based on an application, group, system, or user ID, or a status. You also can
bookmark filters for later use.
See Accessing Scheduled Work Centers on page 409 for an example of the default
system view (which is unfiltered and shows all work centers in the current schedule).
Creating a New View

Typically, you create and manage views through the View Maintenance function. You
also can create a new view (from an existing view) directly from the Work Center List.
To create a new view
412
From the Zeke Web Services home page, click View Maintenance.
The All Views list appears:
The All Views list displays this information:

Column
Description
Type
Type of view, where wc indicates the view is a work center view.
Name
User-defined name of the view.
Description
Description of the contents of the view.
Level
Access level for the view. These are the valid levels:
Personal
The view is available to the current user only.

Note:
Personal views are saved under the name of the
user.
Shared
The view is available to all users.
System
This is the predefined, default view.
Click on the default system view to use it as a template for creating the new view:
Type
Name
Description
Level
wc
default
default view
system
Note:
The default system view is used as a template in this example. All existing views
can be copied to create new personal or shared views.
413
Note:
You also could click on any other existing view to use it as a template instead of the
default view.
The Zeke View Maintenance customization screen appears:
From this screen, you can edit the default system view to create a new view.
Or
You can switch to another view. Select one from the Views: drop down list, and
click Select.
414
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.
Select the Visible check box to enable the column to appear in the view.
Repeat steps a and b for each additional column you want to add to the view.
In the Select Filters section, complete these fields:

Field
Description
Status
Display only the work centers with the specified status. Select one of
these statuses from the drop-down list:
Event
All
Default. All work centers.
Not Done
Work centers waiting to be completed.
Pending
Work centers that are currently being processing and are

pending completion.
Done
Work centers that have been completed.
Disabled
Work centers that have been disabled.
Display only the work centers with the specified event number.
You can specify wildcard characters in any of the filtering criteria below:
Specify * to match one or more characters.
Specify ? to match any single character value.
Appl
Display only the work centers with the specified application ID.
Group
Display only the work centers with the specified group ID.
Event Name
Display only the work centers with the specified event name.
System
Display only the work centers with the specified system ID.
Version
Display only the work centers with the specified version number.
User
Display only the work centers with the specified user ID.
Select the Enabled check box to enable the specified filters.

415
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.
Select the Shared check box if you want to make this view available to all users.
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
Click on the highlighted Name of the view you want to update.

The Zeke View Maintenance customization screen appears. From this screen, you
can update the selected view.
Or
You can switch to another view. Select a view from the Views: drop down list, and
click Select.
3
416
In the Select View Columns section, update the information you want to display in
this view. You can select a maximum of 13 columns (which will appear in the view
in the sequence indicated by the column numbers).
a
For Column # 01, select a heading from the drop-down list to indicate the
information you want to appear in the first column.
Select the Visible check box to enable the column to appear in the view.
Repeat steps a and b for each additional column you want to add to the view.
In the Select Filters section, update these fields:

Field
Description
Status
Display only the work centers with the specified status. Select one of
these statuses from the drop-down list:
Event
All
Default. All work centers.
Not Done
Work centers waiting to be completed.
Pending
Work centers that are currently being processing and are

pending completion.
Done
Work centers that have been completed.
Disabled
Work centers that have been disabled.
Display only the work centers with the specified event number.
You can specify wildcard characters in any of the filtering criteria below:
Specify * to match one or more characters.
Specify ? to match any single character value.
Appl
Display only the work centers with the specified application ID.
Group
Display only the work centers with the specified group ID.
Event Name
Display only the work centers with the specified event name.
System
Display only the work centers with the specified system ID.
Version
Display only the work centers with the specified version number.
User
Display only the work centers with the specified user ID.
Select the Enabled check box to enable the specified filters.
In the Update View section, update the View Name or Description, as desired.
Note:
If you update the view name or description, a new view is created with these
attributes and the existing view is retained with its previous name (and can be
deleted later, if desired).
7
Update the Shared setting indicating whether you want to make the view available
to other users.
417
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
From the Zeke Web Services home page, click View Maintenance.
The All Views list appears.
Click on the highlighted Name of the view you want to delete.

The Zeke View Maintenance customization screen appears.
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 centers required conditions or
actions have been met.
Setting a variable value.

Note:
Some variables are read-only and cannot be changed.
To complete a work center
418
Optional. Select a view from the Views drop-down list to narrow down the list of
work centers (e.g., only the work centers that are not completed yet).
Locate the work center that you want to complete, and right-click the work center for
a context-menu:
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.
If you have already performed the required work center activity, skip to step 7 on
page 420.
Or
If you need to review the work center information or documentation, or the work
center activity requires you to update a variable, click the event number.
419
The Work Center View appears:
Note:
At any time, you can click Cancel to cancel any changes and return the work center
to its previous state (i.e., Pending or Not Done), and return to the Work Center list.
7
Click Complete to complete the work center. The work center status changes to
Complete.
Viewing Documentation
You can view work center text, scratch, or note documentation from a Web browser;
however, you cannot edit the documentation.
To view work center documentation
420
Locate the work center for which you want to view documentation.
Click on the Name of the work center event.

Or
Right-click for a context-menu and select View Work Center.

The Work Center View screen appears.
5
Click on the appropriate tab for the type of documentation you want to view. These
figures illustrate the documentation tab for each documentation type:
Figure 3 Sample Scratch Pad Doc
Figure 4 Sample Text Doc
Figure 5 Sample Note Doc
421
From this screen, you can view the documentation or you can complete,
enable/disable, or refresh the work center.
Or
Click Cancel to return to the Work Center List.
Setting a Variable
Successfully completing a work center could include requiring the operator to set a
variable value.
To set a variable
422
Select the Variables tab:
Click Complete. This enables the New Value field.
In the New Value field, enter the new variable value.
Click Submit.
The work center Status is changed to Complete.
Enabling or Disabling a Work Center

You can disable a work center that is in any status other than Complete. Disabling a work
center event leaves it in the schedule, but Zeke proceeds with event dispatching as if that
event were not in the schedule. Disabling an event can affect dependencies, but does not
affect the EMR or prevent the event from being included in a future schedule.
You can enable a work center that has been disabled (which treats the event normally
again).
Disabling a Work Center

You can disable a work center that has not been completed yet, so that Zeke proceeds
with event dispatching as if the event were not in the schedule.
To disable a work center

1
work centers.
Locate the work center that you want to disable and right-click for a context-menu.
Click Disable Work Center.
The work centers 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
work centers.
423
Locate the disabled work center that you want to enable and right-click for a
context-menu.
Click Enable Work Center.
The work center is enabled and its status is changed to Not Done.
Refreshing a Work Center

Refreshing a work center resets its status to Not Done. You can refresh a work center that
is Pending, Disabled, or Complete. All prerequisite conditions must be satisfied again.
To refresh a work center

1
Locate the work center you want to refresh.

a
Click on the Name of the work center event.

The Work Center View screen appears.
Click Refresh.
Or
Right-click for a context-menu and select Refresh Work Center.
The work center is refreshed and its status is changed to Not Done.
424
Appendix A:
Appendix A
Zeke Agentless
The Zeke Agentless program (ZEKE6NOA) enables you to run Zeke jobs on other
platforms without the need to install OASIS/DMS or a Zeke Agent on the target machine.
It utilizes scp (for secure remote file copy) and ssh (for remote login and command
execution) to send a job defined in Zeke to another system.
Unlike when sending jobs to an actual Zeke Agent, Zeke uses JES and an initiator to
dispatch the job to the target machine rather than dispatching it directly to the target
machine.
Note:
The scheduled event download feature (available with Zeke Agent) is not available with
the Agentless program.
Any target platform that has ssh on it is supported. For example, Linux and Unix have ssh
as part of the operating system; ssh is available as an add-on for many other operating
systems. All standard ssh implementations are supported.
If you have current Zeke Agents that you want to replace with the Agentless program,
you must update your Zeke jobs to call the Agentless program and pass the correct
information.
When executed, the Agentless program sends the job script to the remote box and issues
the commands necessary to execute it. The program then waits until the script finishes
and returns a status; this status is passed back to Zeke.
Note:
The job status passed to Zeke is dependent on the return code that is returned by the ssh
command to the calling program. If the status is greater than 4095, the return status is
reflected as 4095, and you must check the logs for the exact error.
425
System Requirements
These are the system requirements for using the Zeke Agentless program:
USS must be configured on the z/OS system.
At least one user account must be configured to use the HFS file system.
ssh must be configured on the z/OS system and on all target machines that will
receive work through the Agentless program. The ssh protocol must be version 2.
Because Zeke does not know a users 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.
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
426
Configure ssh on the z/OS system and all target machines that will receive work
through the Agentless program. (Refer to your operating system documentation for
the z/OS and target platforms for details.)
Appendix A - Zeke Agentless
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.
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
Export the public key. For example, on an AIX machine, enter this command:
$ ssh-keygen -f $HOME/.ssh/id_dsa.pub -e > public.export
Use FTP to transfer the file public.export to the target machine in ASCII
format.
Log on to the target machine as the user under which the jobs will run.
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 users 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 users password.
For example, on an AIX machine, enter this command:
ssh -l user1 mysystem "uname -a"
427
where mysystem is the hostname.

Sample output:
The authenticity of host 'mysystem (10.107.15.45)' can't be established.
RSA key fingerprint is 5f:ae:92:87:01:71:ee:ae:77:56:5f:75:3c:ca:2c:e1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'mysystem,10.107.15.45' (RSA) to the list of
known hosts.
User1@mysystem's password:
11
Rerun the command. If the configuration is correct, you are not prompted to answer
any questions. For example:
ssh -l user1 mysystem "uname -a"
12
Repeat this procedure for all users and all target machines.
13
Place your job scripts in the HFS file system. Output from the jobs must either be
directed to the HFS file system or must not be trapped. See JCL Requirements on
page 428 for details.
JCL Requirements
Note:
Due to IBM restrictions, the Zeke Agentless program (ZEKE6NOA) can be run only
from the USS environment.
Your Zeke JCL must satisfy these requirements:
Your scripts must be specified by a DD statement for STDIN and must reside in the
HFS.
If you want the output from the jobs, you must define DD statements for STDOUT
and STDERR and they must reside in the HFS.
The jobs must run under a user ID that has been set up in ssh.
The Zeke and OASIS LINKLIBs must either be STEPLIBd in the JCL or be
defined in the users USS login procedure.
The scripts must include parameters for the Zeke subsystem name, destination, and
username:
428
The Zeke subsystem name is the name of the Zeke subsystem that submitted
the job (which is used to verify that Zeke is running).
Appendix A - Zeke Agentless
The destination is the IP address or hostname of the target machine where the
job is to be sent.
The user name is the user ID that the job will run under on the target machine.
Figure 6 is a sample script:

Figure 6 Sample Script
//ASGSSH
//
//STEP1
//
//STDIN
//
//
//STDOUT
//
//
//STDERR
//
//
//
JOB (10039),CLASS=A,MSGCLASS=X,NOTIFY=ASGU1,
USER=ASGU1
EXEC PGM=BPXBATCH,
PARM='sh /var/zeke6noa ZEKA mysystem.mycompany.com user1'
DD PATH='/u/asgu1/script.sh',
PATHOPTS=(ORDONLY),
PATHMODE=SIRWXU
DD PATH='/u/asgu1/script.stdout',
PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
PATHMODE=SIRWXU
DD PATH='/u/asgu1/script.stderr',
PATHOPTS=(OWRONLY,OCREAT,OTRUNC),
PATHMODE=SIRWXU
where:
ASGU1 is the ID of the mainframe user running the job. This user must have authority to
issue ssh commands to the target machine.
mysystem.mycompany.com is the target machine.
/var/zeke6noa is the path to the Zeke Agentless program.
ZEKA is the Zeke subsystem name.
user1 is the user ID on the target machine.
/u/asgu1/script.sh is the script to be run on the target machine.
/u/asgu1/script.stdout is the output of the command.
/u/asgu1/script.stderr is the error output of the command.
429
ZEKE6NOA Command
This section explains how to use the ZEKE6NOA command.
Syntax
zeke6noa [-dlwV] zekesubsystem destination username [home]
Parameters
These are the valid parameters for the ZEKE6NOA command:
430
Parameter
Description
zekesubsystem
The subsystem name for the Zeke executing the command.
destination
The machine where the script is to be sent.
username
The user ID under which the script is to be run.
home
Optional. The home directory for the user on the Windows box (if
applicable). Include this parameter only if ssh does not know home
directory already.
-d
Optional. This flag indicates to print debugging information.
-l
This flag indicates that you do not want output returned.
-w
This flag indicates a Windows job (if applicable). This causes .bat files
to be created and prevents ??? from being appended to the command (as
is done normally for UNIX). Some ssh on Windows (e.g., OpenSSH)
require this flag.
-V
This flag indicates to print the version number.
Appendix B:
Appendix B
Interface to ThruPut Manager
If you use ThruPut Manager (by MVS Solutions) to automate your batch workflow, Zeke
event scheduling information can be made available to ThruPut Manager at the time that
Zeke submits the job.
For any JCL that is submitted from the Zeke started task, relevant job scheduling data can
be specified in JCL comment statements.
Even if you do not use ThruPut Manager, inserting relevant Zeke event scheduling data in
your JCL can be useful because it enables the JES job log to reference this information.
See Job Networking Options on page 317 for more information using the ZekeCtl
generation option to enable this capability.
Note:
Any JCL from CMS, JESQ, or submitted by a user exit (which are not submitted by the
Zeke started task) is not supported by this interface.
See your ThruPut Manager documentation for more information.
Enabling the ThruPut Manager Interface

To enable Zekes interface with ThruPut Manager
1
Verify that your ThruPut Manager installation is at the appropriate PTF level to
enable the Zeke interface.
Note:
Be sure to keep your ThruPut product updated (i.e., to recognize new name/value
pairs as they become available).
431
ZEKECTL Statements
When submitting a job event to JES, Zeke inserts comment statements (containing
name/value pairs) into the JCL according to these rules:
Name/value pairs cannot extend past column 71.
Name/value pairs are listed alphabetically.
Comment statements are inserted after the job statements, except in these cases:
If the PosidEnd generation option is set to Y, then the comment statements

are inserted at the end of the job.
If the Posid generation option is set to Y, then the comment statements are
inserted in front of the Zeke POSID step.
Name/value pairs can contain character, numeric or logic (i.e., true/false) data.
If the data is logic, then only the name is present (i.e., to indicate a true
condition). No name indicates a false condition.
All character values are enclosed in single quotes.
Zeke does not supply a name/value pair if its value blank or zero.
Note:
All possible name/value pairs might not be present for all jobs.
These are examples of the comment statements that Zeke inserts into the JCL:
//*ZEKECTL CAL='A',CATID='C4E6ACDA',DISPID='C8B149BE',DISPSYS='SYSA'
//*ZEKECTL DUR=0:01,EVT=1,EVTSYS='SYSA',SDATE=2011/322,SUBSYS='SSSI'
If a ZEKECTL comment statement is present in the JCL, the logic descriptor $ZEKE is
set to true to indicate that the job is a Zeke job.
Note:
If the JCL is resubmitted manually outside Zeke, then ThruPut Manager will falsely
identify the job as a Zeke job. If the job must be resubmitted outside Zeke, you must
remove the //*ZEKECTL statements.
432
Appendix B - Interface to ThruPut Manager
Zeke Names
This table describes the valid Zeke names in the name/value pairs to be used by ThruPut
Manager to create $ZEKE descriptors:
Name
Format
Description
Note:
An asterisk (*) indicates that the name/value pair always is present in the JCL.
character
Events application ID from the SQR.
* CAL
character
Events 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
Events job classes from the SQR.
CPU
numeric time
mmmmmm:ss
Events average CPU time (in minutes and seconds from

the EMR. If only seconds, the value will include a leading
0 (zero). For example:
APPL
0:12
* DISPID
character
A unique value that identifies the dispatch of the event (i.e.,

different dispatches of the same SQR will have different
DISPID values).
* DISPSYS
character
Zeke system that dispatched the event.
DPRTY
numeric
Events dispatch priority value from the SQR.
DRL
numeric
Events disaster recovery level value from the EMR.
DUR
numeric time
mmmmmm:ss
Events average duration from the SQR. If only seconds,

the value will have a leading 0 (zero). For example:
0:03
* EVT
EVTNAME
* EVTSYS
GRP
numeric
Event number from the SQR.
character
Event name from the SQR.
character
Events system ID from the SQR.
character
Events group ID from the SQR.
433
Name
Format
Description
JCLOVRD
logic
Present (i.e., true) if the events JCL was overridden in the

SQR; otherwise, not present (i.e., false).
LATESTART
numeric time
hh:mm
Events late start time from the SQR. The possible values
are from 00:00 through 48:00.
MANUAL
logic
Present (i.e., true) if the event was added to the schedule

manually; otherwise, not present (i.e., false).
MILESTONE
logic
Present (i.e., true) if the event is a milestone; otherwise, not

present (i.e., false).
MUSTSTART
numeric
date/time
yyyy/ddd.
hh:mm
The time by which the job must start running in order not to
be late. This value is based on the late start time in the
SQR. If there is no late start time specified, then it is based
on the must end time minus the average duration in the
SQR. If there is no late start or must end time, then
MUSTSTART is not present.
If MUSTSTART is present, ThruPut Manager will
calculate the values of these two descriptors when it
evaluates the job:
$ZEKE_MUSTSTART_WITHIN
Number of minutes until the jobs

must start time. This value is
calculated by ThruPut Manager
when it evaluates the job
(i.e., by subtracting the current
time from the MUSTSTART
time).
This value is set to zero if the
result of the calculation is
negative.
If MUSTSTART is not present,
this value defaults to 9999
if $ZEKE is true,
or 0000 if $ZEKE is false.
434
Appendix B - Interface to ThruPut Manager
Name
Format
Description
$ZEKE_MUSTSTART_LATE_BY
Number of minutes after the jobs

must start time. This value is
calculated by ThruPut Manager
when it evaluates the job (i.e., by
subtracting the MUSTSTART
time from the current time.
This value is set to zero if the
result of the calculation is
negative.
If MUSTSTART is not present,
this value defaults to 0000.
These calculated descriptors can be used in ThruPut Manager JAL to give

priority to a job based on its must start time. For example:
Evaluate Zeke_Job
$Zeke_MustStart_Late_By
$Zeke_Muststart_Within
If (Zeke_Job)
If (Very_Late)
Set Priority( 15 )
OrIf (Slightly_Late)
Set Priority( 14 )
OrIf (Soon)
Set Priority( 12 )
OrIf (Pretty_Soon)
Set Priority( 10 )
OrIf (Next_Shift)
Set Priority( 8 )
Otherwise
Set Priority( 6 )
EndIf
EndIf
($Zeke(Yes))
0,Not_Late,1,Slightly_Late,30,Very_Late
0,Soon,60,Pretty_Soon,240,Next_Shift,480,Long_Time
PDSDD
character
DD name of the PDS file that contains the events JCL from
the SQR. The DD name is not present if the events JCL
source is not PDS.
PDSMEM
character
Name of the member in the PDS file specified by PDSDD

that contains the events JCL from the SQR. It is not present
if the events JCL source is not PDS.
RESTART
logic
Present (i.e., true) if the event was restarted; otherwise, not

present (i.e., false).
SCHED
numeric time
hh:mm
Events schedule time from the schedule record. The

possible value are from 00:00 through 48:00.
* SDATE
numeric date
yyyy/ddd
Events schedule date from the schedule SQR.
435
Name
Format
Description
* SUBSYS
character
Zeke subsystem that dispatched the event. (This is the same

value that is displayed in the SUBSYS field when the ZID
operator command is issued.)
USERID
character
Events user ID from the SQR.
VER
numeric
Eevents 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 descriptors value is zero (for a numeric
descriptor), blank (for a character descriptor), or false (for a logic descriptor), unless
noted otherwise in Zeke Names on page 433.
If a name/value pair is not known to ThruPut Manager or contains a syntax error, then
ThruPut Manager issues a warning message and the associated descriptor does not
become available in ThruPut Manager; however, the job continues to execute normally.
$ZEKE_JECL_OK
ThruPut Manager uses the logic descriptor $ZEKE_JECL_OK to indicate successful
parsing. A value of true for this descriptor indicates a successful parse.
If a problem occurs, ThruPut Manager will set $ZEKE_JECL_OK to false. In this case,
for example, the user could fail the job in JAL or simply ignore all $ZEKE descriptors.
436
Index
Symbols
* (asterisk) used with
generic names for dependencies 128,
130
job types 59
special calendars 44
A
adding events by path 5557, 252
alerts
OpsCentral 238
ALTER, Schedule View command 194
Audit Log Facility
logging
in the Audit Log database 296
jobs status changes 296
Zeke operator commands 296
tracking Zeke database activity 296
updating audit actions 296
audit options 296
auto replies
disabling 164
displaying 163
enabling 163
managing Zack Fastpath/Autoreply
tables from Zeke 36
responding to outstanding replies 159
setting generation options 159160
using the AUTORPLY function 161
Automation option, managing Zack
Fastpath/Autoreply tables from
Zeke 36
B
backing up the database 333
using a dataspace 334
C
calculating tape drive usage 308
calendars
accessing online 40
adding a calendar 41
deleting a calendar 41
description of 8
special calendars 43
standard calendars 42
user accounting calendars 44
overview of user accounting

periods 46
CAPS mode 391
class records
defining 386
CLIST commands 198
colors, changing ISPF screen 36
commands
CLIST 198
command events 89
in SCOM events 366
ISPF 3233, 53, 85, 170, 228, 354
JCL 217218
operator 13, 69, 73, 76, 8790, 9394,
97, 154, 160, 163, 191, 239241,
296, 359, 370
auto reply 160
security 377
POWER 89
REXX 198
Schedule View 13, 191, 225
securing 371
system 89
VM 89
ZADD, for Schedule View 247
Zeke start-up 30
ZEKE6NOA 430
ZKILL 31
communication, inter-product
controlling 310
completing work centers 155157
condition codes 11, 143146
controlling jobstream flow using
variables 361
conventions page xi
CREATE batch utility
setting up Z$CATAL class 376
creating
Zeke database 331
cross-platform dependencies 10, 129
D
database
backup using a dataspace 334
creating
Zeke database 331
Zeke started task 336
29
job information contained in 3

moving the vault database 337
recovery, Zeke started task 339
retrieving JCL 84
shared 312
dataset triggering 134
hold code 208
dataspace
database backups using a 334
running simulation against a 190
date format, Schedule View 224
defining
permanent events 99
recurring events 99
deleting
GENOPTS 293294
dependencies
cross-platform scheduling 10, 129
dataset triggering 134
defining 139
description of 10
EOG (end of group) 135, 137
extended dependencies 124, 138
generic event names 130
grouping multiple phrases 131
maintaining
from the EMR (all
versions) 140
multiple 130, 133
multiple job versions 124
Not Active 128
see also logical resources
processing of 124
referencing started tasks 131
satisfied 124
using variables 131
viewing
from the EMR (all
versions) 140
WEAK conditions 126
dispatch queue, checking 307
dispatching
description of 9
generation options 297
list of prerequisites 10
messages and jobs 300
see also dependencies
displaying fields in Schedule View 222
documentation
calendars
note pad 48
scratch pad 48
text 49
events 164
jobs
30
datasets 170
note pad 168
scratch pad 168
summary of types 7
text 169
variables
note pad 353
scratch pad 353
text 354
downloading, setting up a job for 6, 8384
E
early warning alerts, OpsCentral 238
ECDRs, modifying 399
electronic vaulting
considerations for using 338
database allocation 338
description of 17
full recovery procedure 338
partial recovery procedure 339
ESI, see security, external security
event
activating an event 56
adding events to the schedule
manually 247
command events 89
copying an event 67
from a template 65
creating from a template 65
deactivating an event 54
job events 69
routing to another system or
platform for execution 79
master record
accessing 5859
permanent 5, 98106
recurring 5, 97106
resources, accessing 215
routing a job event to another system
or platform 79
status codes, in Schedule View 203
templates
creating events from a
template 65
defining a template 63
work centers 149
event record directory screen 59
exit
exporting database records 20
extended dependencies, see under
dependencies
external security
see security
Index
F
Fastpath, managing Zack Fastpath/Autoreply
tables from Zeke 36
forecasting the schedule 15
G
general
generation options
accessing 281
audit 296
AUR 308
AURINTV 308
AURMSG 308
Calctap 308
COMMCTL 301
DEFDPRTY 300
Defopid 386, 405
DISPDLY 300
DISPSEL 308
DSPIndex 5455
Eojwake 307
global
dispatching 297
exit 309
general 309
JCL 312
scheduling 320
security 324
user interface 325
variables 326
IEFU83 304
Loadcomm 323
local
dispatching 297
exit 309
general 309
JCL 312
messages 319
traces 325
MSGWAIT 300
MSPINTRL 300
MULTAP 321
MULTEN 322
MULTGR 321
Multsys 312
MULTUS 322
Netregid 79, 83
Nonwkday 323
OPEROK 300
Posid 79, 83
POSIDEND 318
PRILATE 301
reloading 295
REMTRIG 304
RepJGrp 316
RepJName 316
RepJUser 317
Reqopid 385
RETAIN 302
RETDAYS 302
RETDONE 303
RETPEND 303
Secexitw 386
Secfail 405
Sechide1 406
Sechide2 406
security options 381
Subdata 326
TRIGDT 305
TRIGJOB 305
TRIGRRN 306
WKTRGDN 306
GENOPTs 280326
accessing 281
adding 287
deleting 293294
editing 290
reloading 295
viewing pending updates 291
global options
dispatching 297
exit 309
general 309
JCL 312
scheduling 320
security 324
user interface 325
variables 326
group
overriding on JOB card 316
H
help, accessing Zeke ISPF online 32
holding an event 250, 253
I
IF clauses within SET statements 366
importing database records 20
initializing the database 331
initiators
adding
a system 263
specifications 263
copying an initiator record 264
defining initiators 262
31
deleting
a single initiator 264
all initiators for a system 264
determining processing 298
editing an existing initiator 263
system availability 264
installation, setting up Z$CATAL class
before running CREATE 376
interfaces, Zebb restart management 197
internal security
see security
inter-product communication,
controlling 310
ISPF menu screens
event record directory 59
ISPF online facility
changing colors on screens 36
commands 3233, 53, 85, 170, 228,
354
common fields 33
features 32
logging on 33
screen format 33
Zeke primary menu 36
see also under online
J
JCL
displaying actual execution JCL 197
JCLR, Schedule View line
command 195
line commands 217218
override 228, 316
performing one-time overrides for job
events 226
retrieving JCL from the Zeke
database 84
substituting variable values 363
syntax checking 236
with JCLPREP 231233
with JOB/SCAN 233235
using variables
to control jobstream flow 361
to restart a job 362
to trigger jobs 360
validation
using ZSCAN 236
with JCLPREP 231
with JOB/SCAN 233
Zeke job control statements 19
JCLPREP, invoking from Schedule
View 231233
job
32
adding jobs to the schedule 251, 255

checking the dispatch queue 307
creating and adding to the schedule at
the same time 191
defining 51
dispatching
messages and jobs 300
EMR
accessing 58
definition of 4
event 69
setting up for downloading 6,
8384
log, displaying 197
MSG jobs 86
name, overriding on JOB card 316
PCOM jobs 89
predecessors, viewing
in Schedule View 196
on the EMR 5455
refreshing jobs 196
scheduled job, changing via Schedule
View 194
SCOM jobs 8990
successors, viewing
on the EMR 54
on the master 56
templates
defining 63
VCOM jobs 89
versions, dependencies for 124
ZCOM jobs 89
JOB/SCAN, invoking from Schedule
View 233235
JPREP line command 233
JSCAN line command 22, 235
L
late events, early warning alerts in
OpsCentral 238
line commands
see commands
loading the work center to SQT 323
local options
dispatching 297
exit 309
general 309
JCL 312
messages 319
trace 325
Logical Day
scheduling examples 9, 74, 182
logical resources
Index
copying a resource 272

defining a resource to Zeke 272
defining resources for an event 274
deleting a resource 273
deleting resources for an event 277
description of 257
editing an existing resource 272
maintaining 271
defining 121
grouping multiple phrases 108
list of keywords 107
multiple phrases 107
processing 107
sample clauses 115
scheduling for holidays and
weekends 118
using parentheses in 108
logon
ISPF online 33
M
menus
OASIS Primary Menu 35
Zeke Primary Menu 36
messages
dispatching 300
display system 197
MSG job 86
multiple
Zeke versions 2
MVS User ID 378
N
NETREGID 133
Network Hold status 210
NOTDURING processing
reason code 210
using logical resources 271
WHEN conditions 127, 134, 197
O
OASIS
started task 29
starting the 331
starting
multiple tasks 29
without Zeke 27
subsystem requirements 2
terminating 30
variables
accessing 32
in SET clauses 150
naming 357
overriding variable values
temporarily 358
overview 355
setting with XVAR and
?XVAR 150
temporary variables 358
OASIS Primary Menu 35
OCCURS clauses
online
see also ISPF online facility
operator commands 13, 69, 73, 76, 8790,
9394, 97, 154, 160, 163, 191, 239
241, 296, 359, 370
auto reply 160
securing 377
ZKILL 27
operator hold on an event 250, 253
operator IDs
mixed case 391
operator records
defining 389
OpsCentral
early warning alerts 238
OVAR 32
overriding JCL 195, 228, 316
overriding the group on the JOB card 316
overriding the job name on the JOB
card 316
overriding the user ID on the JOB card 317
P
partitions
determining partition processing 298
PATH
master primary command 54
Schedule View line command 196
PathFinder
adding events by path 5557, 252
displaying
different levels in the
hierarchy 243
non-Zeke jobs in a path 243
PCOM job 89
PDS override, Zeke started task option 229
permanent events 5, 98106
defining 99
physical resources
defining initiators to Zeke 262
defining pools 268
pools
adding
a pool 269
a system ID 270
33
definition of 15
deleting
a single pool 270
all pools for a system 269
editing
an existing pool 269
an existing system 270
POSIDEND 318
POWER commands 89
predecessors, viewing
on the EMR 5455
prerequisites, see dependencies
primary commands
see commands
primary database
versus secondary database 338
see also under database
primary menu, Zeke 36
R
RACF surrogate processing 317
random scheduling dates, creating calendar
for 43
reason codes in Schedule View 203
recovery, see disaster recovery level,
electronic vaulting
recurring events 5, 97106
defining 99
refreshing jobs 196
refreshing Schedule View 218
reloading GENOPTs 295
remote dependencies 10, 129
RepJGrp generation option 316
RepJName generation option 316
RepJUser generation option 317
rerunning a scheduled job 250, 254
resources
checking before dispatch 11
see also logical resources, physical
resources
restarting
jobs using variables 362
Zeke 27
restoring the database 334
RESTORE batch utility
setting up Z$CATAL class 376
restricting
number of jobs selected 251
system availability
initiators 264
retrieving
JCL for updating 195
JCL from the Zeke database 84
34
return codes
see also condition codes
REXX commands 198
RSTRT, interface to Zebb 197
RUN, Schedule View line command 197
S
schedule
adding a newly created job to the
schedule 191
adding events by path 252
event scheduling 247
forecasting 15
job scheduling 251, 255
number 186
record, rerunning 250, 254
SCHEDADD parameter 191
scheduled job
definition of 5
displaying 191
recreating 250, 254
status, changing 249, 253
simulation 15, 187
schedule download
displaying agents 6, 83
setting up a job for downloading 6,
8384
schedule queue record, definition of 5
Schedule View
accessing
event master record
information 225
online documentation 225
other online information 224
PathFinder 225
resources for an event 215
work center information 225
adding events to the schedule 247,
251, 255
ALTER line command 194
changing
amount of storage for an
event 204
class or class list for an
event 204
dispatch priority 203
number of tape drives 204
number of times an event is
dispatched 204
schedule time 203
scheduled job status 249, 253
sort sequence 220
system or pools 204
Index
way JCL is submitted and

executed 205
commands 191
date format 224
description of 13
display fields 222
displaying
schedule queue record
information 13
scheduled jobs 191
invoking JCLPREP 231233
invoking JOB/SCAN 233235
line commands 13, 191, 194, 203, 225
SYSJ, SYSL, and SYSM 197,
236
maintaining JCL 226
placing an operator hold on an
event 250, 253
primary commands 192
recreating the scheduled job 250, 254
refreshing the screen 218
repeating the last command
entered 206
rerunning a scheduled job 250, 254
restricting the number of jobs
selected 251
setting display characteristics 218
sort sequence, changing 221
validating JCL 236
ZCOM option, entering operator
commands 240
ZOOM line command 13, 232, 234
scheduling
SCOM jobs 8990
variable substitution within SCOM
jobs 366
SECEXITW - specifies work area size 386
SECHIDE1, displaying primary records 406
SECHIDE2, displaying subordinate
records 406
secondary database
versus primary database 338
see also under database
security
authority levels 372
building a Zeke security team 370
calls to ZEKE15A 372
sources of 374
commands 371
exit
SECEXITW option 386
SECFAIL - what to do if
security fails 405
ZEKE15B 376, 386

external security
activating ESI 403
advantages over internal
security 372
cancelling unauthorized batch
job(s) 405
changing the external class
name 399
changing the process option,
internal class 400
copying an ECDR 400
deleting an ECDR 400
displaying primary records 406
displaying subordinate
records 406
elements 393
hard-coded calls 375
main focus 392
modifying ECDRs 399
replacing the ESI class
definition record, internal
class 403
resource name format 393,
401403
security class 392
group, overriding on JOB card 316
implementing 370
internal security
defining logon ID to Zeke
database 385
IDs used 377
not restricting logon access 385
record types used 377
using Zeke security 17
operator commands 377
processing 372
logic 375
securing by function 371
securing by object 370
tracing processing 376
SET clause 150
IF clause within 366
simulation
running against a dataspace 190
schedule 15, 187
SMFPRMxx 131
sorting Schedule View 220
SQR, definition of 5
started task
OASIS 29
starting 331
Zeke 2728, 30
35
database creation 336

database recovery 339
including the Zebb load
library 310
PDS override option 229
terminating 31
starting multiple tasks
OASIS started task 29
Zeke batch utility 29
Zeke started task 28, 30
start-up commands 30
status, event status in Schedule View 203
STOP command 31
successors, viewing
on the EMR 54
on the master 56
surrogate processing 317
SYS1.PARMLIB
SMFPRMxx 131
SYSJ, SYSL, and SYSM line
commands 197, 236
system
commands 89
operating criteria, changing 16, 280
system-dependent variables 359
T
tape drives, calculating usage 308
tasks, Zeke started tasks 30
templates
creating an event from a template 65
defining 63
temporary OASIS variables 358
terminating
OASIS 30
the Zeke started task 31
Zeke 31
using STOP 31
using ZKILL 31
ThruPut Manager interface to Zeke 431436
traces
triggering events, hold code 208
tutorial, accessing Zeke ISPF online 32
TVSET function (temporary variable
set) 358
U
user ID
mixed case 391
overriding on JOB card 317
user interface
36

V
validating JCL 226, 231
VAR and ?VAR keywords 150
variables
as an event prerequisite 131, 359
controlling jobstream flow using
variables 361
deleting a variable 349
in dependencies 360
OASIS, see under OASIS variables
overriding variable values
temporarily 358
restarting a job using variables 362
setting values 158
setting with VAR and ?VAR 150
substitution
activating variable
substitution 326
activating/deactivating 365
in JCL 363
within SCOM jobs 366
summary of features 11
system-dependent variables 359
temporary OASIS variables 358
triggering jobs using variables 360
vault database, moving 337
vaulting, see electronic vaulting
VCOM job 89
VM commands 89
W
WEAK conditions 126
Web Services
for work centers 407424
WHEN conditions
see dependencies
work centers 149
adding or updating a variable
value 158
completing 155157
confirming variable values 159
disabling an event 157
displaying variables for an event 157
enabling a disabled event 157
loading the work center to SQT 323
managing through the Web 407424
refreshing an event 157
SET clause 150
setting up work centers 151
Index
X
XEOJ/XEOE keywords 124, 138
XVAR and ?XVAR keywords 150
Z
Zack, managing Fastpath/Autoreply tables
from Zeke 36
ZADD command 247
ZCOM job 89
ZCOM option 247
entering operator commands 240
Zebb
load library in the Zeke started
task 310
restart management interface 197
Zeke
multiple versions of Zeke 2
restarting 27
starting multiple tasks 30
start-up commands 30
terminating 31
using STOP 31
using ZKILL 31
Zeke "Agentless" 425430
Zeke JCL
override 228
Zeke started task 28
database creation 336
database recovery 339
including the Zebb load library 310
PDS override option 229
terminating 31
ZEKE15A 372
ZEKE6NOA command, Zeke Agentless
program 430
ZEKE6NOA, Zeke Agentless program 426
ZEKECAT 331
ZEKENEW 331
ZEKEOL command 38
ZEKEXUTL (import/export utility) 20
ZKILL
ZKILL COLD command 31
ZKILL TRACK command 31
ZKILL WARM command 31
ZOOM, Schedule View line command
using to invoke JCLPREP 232
using to invoke JOB/SCAN 234
37
38
ASG Worldwide Headquarters Naples Florida USA | asg.com
CD Contents

Zeke 6.0 Users Guide PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Zeke 6.0 Users Guide PDF

Transféré par

Droits d'auteur :

Formats disponibles

ASG-Zeke Scheduling for z/OS

Configuration and Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ASG-Zeke Scheduling for z/OS Users Guide

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

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

Specifying Generic Selection Criteria. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Condition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

ASG-Zeke Scheduling for z/OS Users Guide

Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169

Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 181

Zeke Dispatching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237

Customizing and Maintaining Zeke. . . . . . . . . . . . . . . . . . . . . . . . . . . 279

Defining Schedule Download Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 327

Continuous Job Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

ASG-Zeke Scheduling for z/OS Users Guide

System-dependent Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

External Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 392

Chapter 10: Zeke Web Services. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 407

Appendix A: Zeke Agentless . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 425

System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 426

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

ASG-Zeke Scheduling for z/OS Users Guide

About this Publication

Chapter 6, Resources, explains the differences between physical and logical

Chapter 7, Customizing and Maintaining Zeke, explains how to create and

Chapter 8, Variables, describes the different types of variables and provides

Chapter 9, Security, provides conceptual and procedural information for both

ASG-Zeke Scheduling for z/OS Users Guide

E-mail User Forum

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

ASG-Zeke Scheduling for z/OS Enhancement Summary (AZM1000-nn) describes

ASG-Zeke Scheduling for z/OS Users Guide (AZM0200-nn) explains the

ASG-Zeke Scheduling for z/OS Installation Guide (AZM0300-nn) defines Zeke

ASG-Zeke Scheduling for z/OS Reference Guide (AZM0400-nn) provides a

ASG-OASIS for z/OS Enhancement Summary (AZO0100-nn) describes new

ASG-OASIS for z/OS Installation Guide (AZO0300-nn) provides information on

ASG-OASIS for z/OS Reference Guide (AZO0400-nn) provides information on

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

Used in a procedure to indicate commands within menus.

Indicates that case-sensitive usage is required for a directory, path,

Verify the settings in the asg.conf file.

For system element names, this varies according to the product

Allocate a JSOPTEM member in the JLRCL library.

Create a text file named SECLIST.txt in the

Edit the databaseID.ACC file in the /database directory.

ASG-Zeke Scheduling for z/OS Users Guide

Information that you provide according to your particular situation.

Denotes a cursor-selectable field or line.

Vertical separator bar ( | )

Indicates options available with the default value underlined

Worldwide Customer Support

Intelligent Support Portal (ISP)

Production down, critical situation

Major component of product disabled

Problem with the product, but customer has

How-to questions and enhancement requests

Product Support Policy

ASG-Zeke Scheduling for z/OS Users Guide

ASG Documentation/Product Enhancements

Schedule Monitoring and Intervention

Configuration and Maintenance

Zeke Interfaces to other ASG Products