Beruflich Dokumente
Kultur Dokumente
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
16
16
16
17
Batch Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ZEKE Batch Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
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
32
32
33
33
36
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
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
149
150
151
155
Chapter 5:
191
191
200
203
206
213
215
216
218
224
226
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
280
280
281
287
290
291
293
295
296
297
309
309
312
319
320
324
325
325
326
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
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
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
409
409
412
418
423
424
Contents
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.
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 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
To subscribe 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 Messages and Codes Guide (AZM1200-nn) lists the Zeke
messages, describes their meanings, causes, and resolutions, and provides return
code explanations.
Preface
ASG-OASIS Messages and Codes Guide (AZO1200-nn) lists and explains OASIS
messages. It also provides return code explanations.
Note:
Publication Conventions
ASG uses these conventions in technical publications:
Convention
Usage
Arrow ( )
Bold
xi
Convention
Usage
lowercase italic
monospace
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
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
Within 30 minutes
Within 2 hours
Within 4 hours
Within 4 hours
Severity
xiii
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
12
13
13
14
14
14
15
16
16
16
17
Batch Utilities
ZEKE Batch Utility
Report Writer
Auditing
ZEKESET Utility
ZEKEXUTL Import/Export Utility
17
17
18
18
19
20
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).
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.
See the ASG-Zeke Scheduling for z/OS Installation Guide for more information.
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:
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
SCOM
PCOM
REXX
1 Introducing Zeke
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.
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:
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)
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
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:
A job
A job step
A program
An event
A group of events
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
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.
Variables
Zeke automates variable calculation and substitution. You can use variables to perform or
enable a variety of specialized operations automatically:
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.
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.
Display event statuses, predecessor and successor events, and remote prerequisites
13
Place a hold (on an event, an initiator, or the Zeke system), or release a hold
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:
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
Generation Options
Generation options enable you to configure the operating criteria for your environment.
No two data centers are exactly the same, and, typically, no two systems are identical
within an environment. Zeke enables you to configure separate systems with different
generation options for each one.
A collection of generation options is referred to as a GENOPT table or GENOPT. You
can use GENOPTs to group together specific generation option settings that control a
particular system or that you want to be used across multiple systems. You can create
new GENOPTs, or Zeke provides default GENOPTs that you can customize or copy.
See Zeke Generation Options on page 280 for more information.
See the ASG-Zeke Scheduling for Z/OS Reference Guide for details on using the ZEKE
batch utility for maintaining GENOPTs.
Database Maintenance
Database maintenance includes these tasks:
ASG recommends you use the BACKUP command of the ZEKE utility program to
back up your database at least daily.
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.
Scheduling tasks:
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 and delete local GENOPTs (and update specific field values).
Copy documentation or JCL from an outside source into the Zeke database.
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using
the ZEKE batch utility.
Report Writer
The Report Writer facility enables you to create and customize your own reports based on
information extracted from the Zeke database, as well as generate standard reports. These
are the types of reports you can produce:
Variable listings
Calendar listings
Operator ID listings
Resource listings
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using
Report Writer.
Auditing
Zeke tracks database activity and logs the information. You define the actions be logged
through the Zeke generation options.
You can generate audit reports using the AUDIT utility.
These are the types of actions that you can have audited and logged:
18
Operator commands that are issued from the console and the online facility
1 Introducing Zeke
Event status
Variable value
EMR
SQR
Calendar record
Pool record
Generation option
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
The ZEKESET batch utility enables extensive date manipulation and calculation using
Zeke variables, which provides the ability to create any desired format based on dates.
When used together with variable substitution, this utility can automatically create
program date cards.
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using
the ZEKE batch utility.
19
Import event, variable, and calendar XML records into the Zeke database.
Filtering control statements enable you to select which records to import or export.
Change control statements enable you to change fields within the records being imported
or exported.
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on using
the ZEKE batch utility.
Z Products
These are the OASIS-supported, enterprise workload management, or Z products.
20
1 Introducing Zeke
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.
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.
23
24
Chapter 2:
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
27
28
Terminating OASIS
30
Terminating Zeke
31
32
32
33
33
36
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
where:
Code
Meaning
aa
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
LC
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.
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.
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
//*
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
//
//*
//*
ZEKE
//OASISALT
//OASISALT
//PARMLIB
//SYSPRINT
//SYSMDUMP
//STEPLIB
//
29
This example shows the changes to use a single Zeke started task procedure to access
multiple Zeke database and OASIS subsystems:
//ZEKE
PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS300,
//
DB='ZEKE.DATABASE.NAME;'
//ZEKE
EXEC PGM=SSS4001,REGION=&R,
//
TIME=1440,PARM=OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END
//SYSPRINT DD
SYSOUT=*
//SYSMDUMP DD
DISP=SHR,DSN=* Your Dump Dataset Name *
//ZEKERDR DD
SYSOUT=(A,INTRDR)
//ZEKECAT DD
DISP=SHR,DSN=&DB
//PARMLIB DD
DSN=library-containing-OASIS00-member,DISP=SHR
//STEPLIB DD
DISP=SHR,DSN=* Your Zeke Load Library Name *
//
DD
DISP=SHR,DSN=* Your OASIS Load Library Name *
//*
Use these Zeke startup commands to start the Zeke primary production system using an
alternate database:
S ZEKE
Starts PROD system
S ZEKE,S=ZDOC,DB='ZEKE.TEST.DATABASE',OASIS=(01,L) Starts ALT database
Terminating OASIS
Do not terminate OASIS if any other OASIS-supported Z products are running in the
same OASIS subsystem. You must terminate all products in the subsystem before you
terminate OASIS.
This is a sample jobstream to terminate OASIS (where xxxx is the subsystem):
//ZOASIS
JOB
//SOASIS
EXEC
//SYSPRINT DD
//STEPLIB DD
//SYSIN
DD
TERMINATE
/*
30
,MSGLEVEL=(1,1),CLASS=A
PROC=OASIS,REGION=1024K,S=xxxx
SYSOUT=A
DSN=OASIS.LINKLIB,DISP=SHR
*
<== If required
Terminating Zeke
If multiple OASIS-supported Z products are active in the address space, you can use the
MVS system command STOP to terminate all active products along with the started task.
When you terminate the last (or only) active product in the address space, the started task
is terminated automatically.
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:
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
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.
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 help
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).
ADD
Scroll ===> PAGE
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
RA =Range
O = Ok
- Range Low High
8
16
Action
F
O
All remaining online procedures in this publication start from the Zeke Primary Menu.
33
Utilities
Compilers
Options
Status
Help
TSO-Access
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
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
34
EXIT
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
EXIT
Automated Operations
Rerun/Restart Management
Scheduling for z/OS
Tape Management
OASIS Variables and Audit
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
Z600A000
Copyright (C) 2012 Allen Systems Group, Inc. All rights reserved.
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.
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
Z600A000
Copyright (C) 2012 Allen Systems Group, Inc. All rights reserved.
36
From the Zeke Primary Menu, enter option C.1 and press Enter. The User Color
Select Screen is displayed:
ASG-Zeke
Command ==>
Primary Commands:
INIT SAVE
Description
Color
Hilite
Screen Title
Field and Column Heading
Normal Text
Accented Text
Normal Output Data
Accented Output Text
Normal Input Data
Accented Input Data
Input Field in Error
Warning Field
Exception Field
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
________
Consider the types of data you want to change. This table provides is a description
of each type:
Data Type
Description
Screen Title
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
Accented Text
Data Type
Description
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.
Issue the command ZEKEOL (or its alias ZOL) from any full screen terminal.
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
40
Standard Calendars
42
Special Calendars
43
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
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
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.
From the Zeke Primary Menu, enter option 3. Press Enter. The Calendar Selection
Criteria screen is displayed:
ASG-Zeke
Command ===>
Calendar ID==>
Year==>
BROWSE
COPY
Type==>
DELETE
EDIT
DOCUMENT
Calendar ID =>
Calendar Type =>
Date Range =>
40
STD- Standard
-
3 Calendars
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
Standard calendar
SPC
Special calendar
USR
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
Holidays
Workdays
Holidays
None
Work Days:
Mon
YES
Tue
YES
MM/DD/YYYY
BROWSE
Wed
YES
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:
42
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.
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
January
February
March
April
May
June
July
August
September
October
November
December
1
.
.
.
.
.
.
.
.
.
.
.
*
2
.
.
.
.
.
.
.
.
.
.
.
*
3
.
.
.
.
.
.
.
.
.
.
.
*
4
.
.
.
.
.
.
.
.
.
.
.
*
5
.
.
.
.
.
.
.
.
.
.
.
*
6
.
.
.
.
.
.
.
.
.
.
.
*
7
.
.
.
.
.
.
.
.
.
.
.
*
8
.
.
.
.
.
.
.
.
.
.
.
*
9
.
.
.
.
.
.
.
.
.
.
.
*
BROWSE
DOCUMENT EDIT
Type==> SPC
1
0
.
.
.
.
.
.
.
.
.
.
.
*
1
4
.
.
.
.
.
.
.
.
.
.
.
.
2
5
.
.
.
.
.
.
.
.
.
.
.
.
1
1
.
.
.
.
.
.
.
.
.
.
.
*
1
2
.
.
.
.
.
.
.
.
.
.
.
*
1
3
.
.
.
.
.
.
.
.
.
.
.
*
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
. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
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.
44
3 Calendars
For example, this OCCURs clause selects the last Monday in period 2:
MONDAY.L AND PERIOD.2
Work Days:
Mon
YES
Tue
YES
MM/DD/YYYY
Wed
YES
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:
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:
01: 28
04: 28
07:
10:
13:
16:
19:
22:
BROWSE
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
Period
03: 35
06: 35
09:
12:
15:
18:
21:
24:
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
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
Type: STD
Sdate:
Edate:
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
47
Desired Result
Action
Access text
documentation
Access note
documentation
CANCEL
DELETE
EDIT
EDIT
48
When adding or updating scratch pad or note information, enter text information in
the lined area. You can enter up to 60 characters per line, and up to ten lines of text.
3 Calendars
Text Documentation
EDIT
Columns 000 000
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.
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
52
53
53
57
58
59
61
63
65
67
69
86
89
93
97
102
105
OCCURS Clauses
OCCURS Clause Format
Sample OCCURS Clauses
Scheduling Events on Holidays and Weekends
Defining an OCCURS Clause
107
107
115
118
121
WHEN Conditions
Job and Program WHEN Conditions
WHEN Conditions for Multiple Event Versions
Extended Dependencies
WEAK Conditions
NOTDURING Conditions
124
124
124
124
126
127
51
Topic
Cross-platform Dependencies
Specifying Generic Names
Specifying Multiple WHEN Conditions
Specifying Started Tasks
Using Zeke Variables as WHEN Conditions
WHEN Condition Keywords
Defining a WHEN Condition
Viewing WHEN Conditions for All Event Versions
Page
129
130
130
131
131
133
139
140
Condition Codes
Defining Condition Codes for an Event
143
144
Work Centers
Using Variables in Work Centers
Defining a Work Center
Completing Work Centers
149
150
151
155
Auto Replies
Defining Auto Replies
Managing Auto Replies
159
160
163
Event Documentation
Accessing Event Documentation
Maintaining Scratch Pad or Note Documentation
Maintaining Text Documentation
Maintaining Dataset Documentation
164
165
168
169
170
172
172
174
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
WORK
VCOM
VM CP command event
ZCOM
SCOM
PCOM
REXX
Action
ACCT
ADD
AUTorply
BROwse
CCode
COPY
53
Command
Action
COPYAll
DEACt
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
DOCument
EDit
JCL
OCCurs
PATH
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
54
4 Events
Command
Action
PATHADD
Invoke the Schedule View Add-by-Path wizard, which enables you to list
predecessors and successors for an event and then schedule events from the
list. Zeke auto-fills the event, depth level, OCCURS date, version, and path
type.
Note:
The DSPIndex generation option must be set to Y to enable the PATHADD
command (see Building EDB Indexes on page 311).
LEVel
Specifies the level of depth to display for the path. The valid
values range from 1 through 999, or you can enter an asterisk
(*) to display all levels. The default value is *.
OCCDate
Specifies the Julian date for Zeke to use to resolve the OCCURS
clause. The default value is the current date.
VERsion
Specifies the 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
55
Command
Action
PREDADD
Invoke the Schedule View Add-by-Path wizard, which enables you to list
predecessors for an event and then schedule events from the list. Zeke
auto-fills the event, depth level, OCCURS date, version, and path type.
Note:
The DSPIndex generation option must be set to Y to use the PREDADD
command (see Building EDB Indexes on page 311).
LEVel
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
RESOurce
RESTart
Request the restart facility (e.g., Zebb) for the job event.
SUcc
56
LEVEL
Specifies the level of depth to display for the path. The valid
values range from 1 through 999, or you can enter an asterisk
(*) to display all levels. The default value is *.
OCCDATE
Specifies the Julian date for Zeke to use to resolve the OCCURS
clause. The default value is the current date.
4 Events
Command
Action
VERSION
Invoke the Schedule View Add-by-Path wizard, which enables you to list
successors for an event and then schedule events from the list. Zeke auto-fills
the event, depth level, OCCURS date, version, and path type.
Note:
The DSPIndex generation option must be set to Y to use the SUCCADD
command (see Building EDB Indexes on page 311).
LEVEL
Specifies the level of depth to display for the path. The valid
values range from 1 through 999, or you can enter an asterisk
(*) to display all levels. The default value is *.
OCCDATE
Specifies the Julian date for Zeke to use to resolve the OCCURS
clause. The default value is the current date.
VERSION
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.
From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria
screen is displayed:
ASG-Zeke
Command ===>
Event ===>
Primary Commands:
Event Types
Job:
Msg:
Pcom:
Work:
Vcom:
Zcom:
Scom:
REXX:
Template:
Permanent:
Milestone:
58
4 Events
Optional. To a list of existing templates for a specific event type, perform these steps:
a
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).
From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria
screen is displayed.
59
Enter ADD on the Command line, and press Enter. The Add Event Record Function
screen is displayed:
ASG-Zeke
Option ===>
Use Template: Y
1
Job
2
Msg
3
Pcom
4
Work
5
Vcom
6
Zcom
7
Scom
8
REXX
Add
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
In the Option field, specify the option number for the type of event that you want to
define.
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 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.
4 Events
From the Zeke Primary Menu, enter option 1. The Event Master Selection Criteria
screen is displayed.
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Update event documentation, 1 Enter any character in the appropriate Event Types
JCL, auto reply, resource,
field.
condition codes, or
2 Enter any additional information about the event in the
dependency information
Selection Field Masks fields.
3 Press Enter. The Event Master Directory displays
events that match the selection criteria.
Continue to step 3 on page 62.
61
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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.
1 Enter D to the left of the event that you want to update, and press
Enter. The Event Master Definition screen for the selected event
is displayed in Delete mode.
2 Press Enter again to confirm.
This procedure is complete.
Update event
documentation
Enter E1 to the left of the event that you want to update, and press
Enter.
Continue to Accessing Event Documentation on page 165.
Update online event Enter E2 to the left of the event that you want to update, and press
JCL
Enter.
Continue to Overriding JCL on page 226.
Update event auto
reply segments
Enter E3 to the left of the event that you want to update, and press
Enter.
Continue to Defining Auto Replies on page 160.
Update event
logical resources
Enter E4 to the left of the event that you want to update, and press
Enter.
Continue to Defining Resources for an Event on page 274.
Update event
condition codes
Enter E5 to the left of the event that you want to update, and press
Enter.
Continue to Condition Codes on page 143.
62
4 Events
Desired Result
Action
Update the
OCCURS clause
for an event
Enter E6 to the left of the event that you want to update, and press
Enter.
Enter E7 to the left of the event that you want to update, and press
Enter.
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 ===>
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:
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:
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
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
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
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===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
JESQ (Y, D=dynamic):
Class:
Pri: 0
CMS:
Ftype:
All of the information in the template definition is copied to the new event (except
that Zeke resets the Template field in the new event to N).
66
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.
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.
Access the Event Master Definition screen (see Accessing the Event Definition on
page 58) for the event that you want to copy:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
JESQ (Y, D=dynamic):
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
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
Press F2.
Note:
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
Access the Event Master Definition screen for job events, as described in Accessing
the Event Definition on page 58.
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
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
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
NX
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
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.
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
In the Sched field, specify the normal schedule time for the 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
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.
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).
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).
76
Access the Event Master Definition screen for a job event, as described in
Accessing the Event Definition on page 58.
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.
77
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.
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.
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.
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
Access the Event Master Definition screen for a job event, as described in
Accessing the Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
If the remote system is secured, the Usrid field must specify a valid user ID on the
remote system.
4
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
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
*RF or
*RMTFUL
*RL or
*RMTLIM
81
Field
Description
Note:
The values *REMOTE, *RMTFUL, and *RMTLIM can be used only when
Zeke routes the job to a remote system on the same platform as the
dispatching system. If you want to route a job from a z/OS system to a
system on VSE, AIX, or AS/400, you must specify netregid as the target.
If you want to route a job to the same platform (e.g., from one VSE system
to another), you can specify either netregid or *REMOTE as the target.
Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent a user from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of events
being scheduled unintentionally during the next schedule build cycle. This
change requires you to press the Tab key after typing eight characters in the
Target field to move to the Verload field. If you attempt to type beyond the
end of the Target field, your keyboard locks, and you must press Reset and
then the Tab key to continue.
Platform
Indicate the operating system on which the event is executed. The default
values is the value of the DefPltfm generation option. These are the valid
values:
AIX (see Note below)
DCOSX (Pyramid)
HPUX (see Note below)
MVS (i.e., z/OS)
OS2
OS400
SUN (see Note below)
TANDEM
UNIX (e.g., AIX, AT&T, HPUX, NCR, SCO, SunOS, Sun Solaris, etc.)
USYS
VMS
VSE
WINDOWS (i.e., all supported versions)
Note:
Although the AIX, HPUX, and SUN platform codes are supported, ASG
recommends that you use the UNIX platform code.
Zeke does not download jobs (to a remote system) that have a platform of
MVS or VSE.
82
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
4 Events
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
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===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
83
Note:
If the remote system is secured, the Usrid field must specify a valid user ID on the
remote system.
3
Description
Target
Platform
Specify the operating system where the remote Zeke Agent resides. The
default value is the value of the DefPltfm generation option. Enter UNIX.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
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===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 60
Desc: TEST JOB ASG
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
Enter JCL on the Command line, and press Enter. The JCL screen is displayed. (If
no JCL exists, the screen is displayed in Add mode):
ASG-Zeke
JCL
EDIT Event 00060
Command ===>
Scroll ===> PAGE
****** **************************** Top of Data ****************************
==MSG> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF).
==MSG>
Data has valid standard numbers.
==MSG> -Warning- The UNDO command is not available until you change
==MSG>
your edit profile using the command RECOVERY ON.
000100 //MVSDEM10 JOB (10038),'G HILED',
000200 //
MSGCLASS=Y,CLASS=A,
000300 //
REGION=4M
000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000610 //STEPLIB DD
DISP=SHR,DSN=OASIS.LINKLIB.MVS1
000620 //*
DD
DISP=SHR,DSN=OASIS.LINKLIB.DVLP
000630 //
DD
DISP=SHR,DSN=OASIS.LINKLIB
000640 //*
DD
DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB
000650 //*
DD
DISP=SHR,DSN=ZEKE.PDJKL.LINKLIB
000660 //*
DD
DISP=SHR,DSN=ZEKE.PDMNO.LINKLIB
000670 //
DD
DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000680 //
DD
DISP=SHR,DSN=ZEKE.LINKLIB
000690 //*
DD
DISP=SHR,DSN=ZEBB.TEST.LINKLIB
000691 //
DD
DISP=SHR,DSN=ZEBB.LINKLIB
000700 //SYSPRINT DD SYSOUT=*
000800 //SYSMDUMP DD DISP=SHR,DSN=ZEKE.DUMP
000900 //SYSIN
DD *
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
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.
Access the Event Master Definition screen for message events, as instructed in
Accessing the Event Definition on page 58.
ASG-Zeke
Command ===>
BROWSE
Event===>
Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT
OCCURS PATH PRED REACT RESOURCE SUCC WHEN
Template: N
Permanent: N
Milestone: N
Evt: 482
Desc: OFFSITE CASH RUN TAPE
Type: MSG Desc2: MONTHLY
Event Name: ZECASTPOFF
App:
Grp:
Usrid:
DRL:
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart:
Early:
Sched: 00:00 Mustend:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
Control: Y
SchEnv: ASGSCHEDUENVIRON
Route: (3)
Oper
Oper
Oper
Oper
Oper
Oper
86
4 Events
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
Event Name
Specify the name of the message event. The event name is displayed on
Zeke online screens and reports, and can be used as selection criteria. The
event name also can be specified in end-of-event (EOE and AEOE) and
end-of-group (EOG and AEOG) WHEN conditions.
Usrid
Specify the user ID (up to eight characters long) for the user authorized to
access the message event.
Because Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (upper, lower, or mixed).
Note:
This user ID is for Zeke internal security only.
System
Specify the system or pool that owns the message event (which can be
associated with only one system).
Note:
This is the system where the event is dispatched, and not necessarily the
system where the EMR was defined.
Verload
Specify the number of versions of this event that Zeke loads during
schedule build. The valid values range from 0 through 32767. The default
value is 0.
For example, if Verload is set to 3, Zeke adds EMRs to the schedule for
three versions of the event during schedule build (i.e., versions 1, 2, and 3).
If Verload is set to 0, then only one version of the event (version zero) can
be in the schedule at a time.
If Verload is set to 1, then Zeke loads only one version during the schedule
build, but you can use the ZADD operator command to add multiple
versions (up to 32,767) to the schedule after the schedule load.
Note:
ASG recommends that you run no more than 1,000 versions of a single
event.
87
Field
Description
See Creating Multiple Versions of an Event on page 76 for details on
multiple event versions.
Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of
events being scheduled unintentionally during the next schedule build.
Sched
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.
88
Route
Oper Msg
Specify the message text (up to six lines long) to issue to the system
console.
Complete these fields (as applicable), which enable you to group events for selection
for scheduling or reporting:
Field
Description
App
Specify the code (up to eight characters long) to identify the application ID
associated with the message event.
Grp
Specify the code (up to three characters long) to identify the group ID
associated with the message event. This field is a subset of the application ID.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
4 Events
Description
PCOM
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
ZCOM
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
Access the Event Master Definition screen for SCOM events, as instructed in
Accessing the Event Definition on page 58:
ASG-Zeke
Command ===>
BROWSE
Event===>
Primary Commands: ADD BACK BROWSE COPY COPYALL DEACT DELETE DOC EDIT NEXT
OCCURS PATH PRED REACT RESOURCE SUCC TOPPAGE WHEN
Template: N
Permanent: N
Milestone: N
Evt: 458
Desc: RESUB MJP JOBS
Type: SCOM Desc2:
Event Name: LJDSCOM
App:
Grp:
Usrid:
DRL:
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 08:30
Early:
Sched: 00:00 Mustend:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
Control: Y
SchEnv: ASGSCHEDUENVIRON
__
__
__
__
__
__
__
90
Code =>
Code: C
Code: C
Code: Z
Code: Z
Code: Z
Code: Z
Code: Z
V=VM Cmd
P=VSE/POWER Cmd
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
Event Name
Specify the name of the command event. The event name is displayed on
Zeke online screens and reports, and can be used as selection criteria. The
event name also can be specified in end-of-event (EOE and AEOE) and
end-of-group (EOG and AEOG) WHEN conditions.
4 Events
Field
Description
Usrid
Specify the user ID (up to eight characters long) for the user authorized to
access the command event.
Since Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (upper, lower, or mixed).
Note:
This user ID is for Zeke internal security only.
System
Specify the system or pool that owns the command event (which can be
associated with only one system).
Note:
This is the system where the event is dispatched, and not necessarily the
system where the EMR was defined.
Verload
Specify the number of versions of this event that Zeke loads during
schedule build. The valid values range from 0 through 32767. The default
value is 0.
For example, if Verload is set to 3, Zeke adds EMRs to the schedule for
three versions of the event during schedule build (i.e., versions 1, 2, and 3).
If Verload is set to 0, then only one version of the event (version zero) can
be in the schedule at a time.
If Verload is set to 1, then Zeke loads only one version during the schedule
build, but you can use the ZADD operator command to add multiple
versions (up to 32,767) to the schedule after the schedule load.
Note:
ASG recommends that you run no more than 1,000 versions of a single
event.
See Creating Multiple Versions of an Event on page 76 for details on
multiple event versions.
Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of
events being scheduled unintentionally during the next schedule build.
91
Field
Description
Sched
Specify the normal schedule time for the event. The default value is 00:00
(i.e., the event is dispatched according to WHEN conditions instead of by
time).
See Specifying a Schedule Time on page 73 for a detailed explanation of
schedule time.
Code
Line 001
through line
005
System command
VSE/POWER command
System response
VM command
Zeke command
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
Complete these fields (as applicable), which enable you to group events for selection
for scheduling or reporting:
Field
Description
App
Specify the code (up to eight characters long) to identify the application ID
associated with the command event.
Grp
Specify the code (up to three characters long) to identify the group ID associated
with the command event. This field is a subset of the application ID.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
93
Access the Event Master Definition screen for REXX events, as instructed in
Accessing the Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT
OCCURS PATH PRED REACT RESOURCE SUCC WHEN
Template: N
Permanent: N
Milestone: N
Evt: 458
Desc: RESUB MJP JOBS
Type: REXX Desc2:
Event Name: LJDREXX
App:
Grp:
Usrid:
DRL:
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart:
Early:
Sched: 00:00 Mustend:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
Control: Y
SchEnv: ASGSCHEDUENVIRON
REXX exec: REXX1
Class: A
Pri: 1
Argument:
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
Event Name
Specify the name of the REXX event. The event name is displayed on Zeke
online screens and reports, and can be used as selection criteria. The event
name also can be specified in end-of-event (EOE and AEOE) and
end-of-group (EOG and AEOG) WHEN conditions.
Usrid
Specify the user ID (up to eight characters long) for the user authorized to
access the REXX event.
Since Zeke supports mixed-case user IDs, be sure to specify the desired
user ID in the correct case (upper, lower, or mixed).
Note:
This user ID is for Zeke internal security only.
94
4 Events
Field
Description
System
Specify the system or pool that owns the REXX event (which can be
associated with only one system).
Note:
This is the system where the event is dispatched, and not necessarily the
system where the EMR was defined.
Verload
Specify the number of versions of this event that Zeke loads during
schedule build. The valid values range from 0 through 32767. The default
value is 0.
For example, if Verload is set to 3, Zeke adds EMRs to the schedule for
three versions of the event during schedule build (i.e., versions 1, 2, and 3).
If Verload is set to 0, then only one version of the event (version zero) can
be in the schedule at a time.
If Verload is set to 1, Zeke loads only one version during the schedule
build, but you can use the ZADD operator command to add multiple
versions (up to 32,767) to the schedule after the schedule load.
Note:
ASG recommends that you run no more than 1,000 versions of a single
event.
See Creating Multiple Versions of an Event on page 76 for details on
multiple event versions.
Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data intended
for the Target field so that it overflows into the Verload field. Stray
characters in the Verload field could result in an excessive number of
events being scheduled unintentionally during the next schedule build.
Sched
Specify the normal schedule time for the event. The default value is 00:00
(i.e., the event is dispatched according to WHEN conditions instead of by
time).
See Specifying a Schedule Time on page 73 for a detailed explanation of
schedule time.
95
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
NX
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
Complete these fields (as applicable), which enable you to group events for selection
for scheduling or reporting:
Field
Description
App
Specify the code (up to eight characters long) to identify the application ID
associated with the REXX event.
Grp
Specify the code (up to three characters long) to identify the group ID
associated with the REXX event. This field is a subset of the application ID.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
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.
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.
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:
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).
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.
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.
Access the Event Master Definition screen, as instructed in Accessing the Event
Definition on page 58.
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 3
Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
99
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 by its start time, regardless of the time the
event actually runs. If the event becomes delayed for any reason,
Zeke dispatches any missed runs immediately.
Indicate how the recurring event satisfies WHEN conditions (i.e., serves as a
trigger) for other events.
Note:
This field is valid for recurring events only; permanent events trigger other
events on all occurrences.
These are the valid values:
A
Default. The recurring event triggers other events each time it runs.
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
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.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
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)
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)
(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.
Access the Event Master Definition screen for a job event, as described in
Accessing the Event Definition on page 58.
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
Designate the event as a milestone, which Zeke flags in Schedule View and
OpsCentral.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
Note:
You also can flag an event as a milestone using the EVENT function of the ZEKE utility
program. See the ASG-Zeke Scheduling for z/OS Reference Guide for details.
104
4 Events
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 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.
105
Access the Event Master Definition screen as instructed in Accessing the Event
Definition on page 58.
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 163
Desc: SPECIAL RJE JOB FOR ABC
Type: JOB Desc2:
Event Name: ZK60RJEABC
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 3
Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: CGCJOBA
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Class:
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
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
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
Perform the procedure, Defining a WHEN Condition on page 139, to specify any
prerequisites that must occur before Zeke dispatches the event.
4 Events
OCCURS Clauses
The OCCURS clause specifies the day or days Zeke schedules an event. The
SCHEDULE function of the ZEKE utility program scans the Zeke database, and select
each event to process on the specified schedule date based on its OCCURS clauses.
Zeke schedules an event when the 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.
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)
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.
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.
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)))
108
4 Events
OCCURS Keywords
You can use these symbols in an OCCURS clause that includes keywords:
Symbol
Description
(period)
OCCURS (MONDAY.L)
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)
Description
DAILY
WORKDAYS
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
WTUESDAY
WWEDNESDAY
WTHURSDAY
WFRIDAY
WSATURDAY
WSUNDAY
JANUARY
110
FEBRUARY
MARCH
APRIL
MAY
JUNE
JULY
AUGUST
SEPTEMBER
OCTOBER
NOVEMBER
DECEMBER
EOM
EOM-xx
4 Events
Keyword
Description
WEOM
WEOM-xx
DAY
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 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)
111
Keyword
Description
DATE xx
mm/dd/yyyy
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 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
EVERY xxx
WDAYS FROM
mm/dd/yyyy
Schedules every xxx days beginning on the specified date. Zeke does not
schedule the event before the specified date.
Note:
You also can use the date format dd/mm/yyyy if your OASISxx options
member specifies the start-up option DATE=DDMM.
Schedules every xxx workdays before and after the specified date (when
scheduling events for the future).
Note:
You also can use the date format dd/mm/yyyy if your OASISxx options
member specifies the start-up option DATE=DDMM.
REQUEST
Zeke does not add the event to the schedule automatically. You must issue
the ZADD operator command to schedule the event.
REFEVENT
eventname/
number
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)
113
Keyword
Description
NOT
OR
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 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
4 Events
Keyword
Description
CALENDAR
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
Schedules only if the value for $SUE123 is OKAY, and it is the second
period of the calendar.
Occurs every workday except the seventh workday of each month or period.
OCCURS (SUNDAY AND WEEK.1)
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 every workday except the workday before the last day of the month.
OCCURS (EOM + 5 WDAY)
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 of the week, except for Friday, unless Friday is the last
workday of the month.
OCCURS (MONDAY.L AND PERIOD.1)
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 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)
117
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. 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 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.
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).
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 every Sunday in August, even if Sunday is defined as a weekend
day:
OCCURS ((SUNDAY AND AUGUST) ON WEEKENDS)
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
Access the Event Master Definition screen for the desired event, as instructed in
Accessing the Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 6
Desc: TEST JOB
Type: JOB Desc2:
Event Name: ZEKE60TST6
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 3
Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: TSKKGUT1
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
Enter OCCURS on the Command line, and press Enter. The Event Record Occurs
Clause screen is displayed:
ASG-Zeke
Command ===>
Primary Commands :
EDIT
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
WORKDAYS
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 ===>
EDIT
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
122
4 Events
Zeke uses these codes to indicate the status of each day in the current month:
Code
Meaning
Weekend day
Holiday
Review the results of the OCCURS clause for at least the next 12 months to verify
that the event is hitting the schedule as expected.
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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:
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).
Extended Dependencies
The keywords XEOJ (extended end-of-job) and XEOE (extended end-of-event) provide
the ability to trigger job events across multiple schedules. Extended WHEN conditions
can be satisfied by events that have run in the past, but no longer are in the schedule. If a
124
4 Events
job is dependent on another event that might have run as part of an earlier schedule, Zeke
uses the XEOJ keyword to locate the triggering event in the Zeke database, and determine
whether it has run since the last time the dependent job ran.
See WHEN Condition Keywords on page 133 for details on including the XEOJ and
XEOE keywords in a WHEN condition.
If a job has multiple extended WHEN conditions, all conditions must be satisfied at the
same time for the extended triggering to occur.
At schedule load, Zeke searches the EMRs (using the index, if present) and examines the
first matching jobname. If the last run of the event completed successfully since the last
time the job with the extended dependency ran, the dependency is satisfied and marked
by an asterisk (*) (just like an EOJ or EOE). Otherwise, Zeke considers the dependency
as if it were a regular EOJ or EOE, and waits for the triggering job to complete
successfully before satisfying the dependency. Zeke examines extended dependencies
each time an event becomes TIMEOK (i.e., time-satisfied) and WHENOK (i.e.,
dependencies are satisfied).
In extended dependency triggering, Zeke retains the start date and time, the end date and
time, and the event status in the EMR for the last execution of each event (see Event
Activity Accounting on page 172 for details). If the SQR has been requeued, or if Zeke
is not tracking the execution, Zeke retains the information in the SQR for the last
execution instead. If multiple SQRs for an event are executing at the same time,
triggering occurs based on the execution with the latest end date and time.
Note:
Zeke processes extended WHEN conditions in the same manner as if the generation
option TrigJob is set to C, and TrigDt is set to A. This indicates that Zeke (or another
Zeke that shares the database) must have dispatched the triggering event, but the start
date does not have to be the same as the schedule date of the job being triggered.
If the last execution of an event did not complete successfully, the event cannot trigger an
extended dependency. For example, a JCL error is an unsuccessful completion; an EOJ
FORCED status indicates a successful completion. If the execution is unsuccessful, Zeke
still retains the information for that execution in the EMR, but no triggering takes place.
Extended WHEN conditions also can be manually satisfied using the ZALTER
WHENOK operator command.
XEOE Example
Event 2 has an extended dependency (XEOE) on Event 1. When it loads Event 2 into the
schedule, Zeke checks to see whether Event 1 ran since the last time Event 2 ran. If Event
1 last ran successfully a week ago, and Event 2 last ran successfully two weeks ago, then
the XEOE dependency is satisfied, and Zeke dispatches Event 2 (assuming that any
125
additional dependencies also are satisfied). However, if Event 1 ran two weeks ago, and
Event 2 ran only two days ago, the XEOE is not satisfied, and Zeke treats the dependency
as an EOE instead.
XEOJ Example
The job event named Job B has an extended dependency (XEOJ) on Job A. When Zeke
loads Job B into the schedule, Zeke checks to see whether Job A ran since the last time
Job B ran. If Job A just ended today at 10:30:25 A.M., and Job B is ready to run at
10:30:40 A.M. today (during the same minute), then the XEOJ dependency is satisfied,
and Zeke dispatches Job B (assuming that any additional dependencies also are satisfied).
However, if Job A did not end until 10:30:56 A.M. (also during the same minute), then
the XEOJ is not satisfied, and Zeke treats the dependency as an EOJ instead.
WEAK Conditions
You can use WEAK conditions in a dependency to create WHEN conditions that refer to
other events that might not be in the schedule. WEAK conditions enable you to specify
that Zeke must respect the condition if the event is in the schedule; otherwise, Zeke
ignores the condition.
For example, 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.
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.
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)
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.
129
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on the
ZALTER operator command.
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)
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.
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.
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
GT
Greater Than
LE
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')
at sign (@)
asterisk (*)
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
AEOE
(Abnormal end of event) Specify an event of any type (including work centers).
For example:
WHEN (AEOE JOB1)
AEOP
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)
BOP
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
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)
EOJ
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
You can use WEOG to trigger an event by the completion of an event group
(which could include work centers). This dependency is satisfied when all events
in the schedule that match the specified group name are in EOE or Disabled status,
and at least of the matching events must be in EOE status.
A WEOG condition can be satisfied even if there are no matching events in the
schedule.
See WEAK Conditions on page 126 for more information.
WEOE
(Weak end of event) Specify the event name; do not specify the event number. For
example:
WHEN (WEOE WC_ABC)
You can use WEOE to trigger an event by the completion of another event
(including work centers).
A WEOE condition can be satisfied even if there are no matching events in the
schedule.
See WEAK Conditions on page 126 for more information.
137
Keyword
Description
WEOJ
A WEOJ condition can be satisfied even if there are no matching jobs in the
schedule.
See WEAK Conditions on page 126 for more information.
XEOE
(Extended end of event) Specify the event name; do not specify the event number.
An XEOE is satisfied when an event (including work centers) in the schedule that
matches the specified event name has reached an EOE or Disabled status since the
last time this event ran. For example, if this dependency is defined for JOBC, then
XEOE is satisfied if job ABC has run to EOE or Disabled status since the last time
JOBC ran:
WHEN (XEOE ABC)
Note:
Zeke does not support the use of the VER keyword with the XEOE keyword.
XEOJ
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
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 6
Desc: TEST JOB
Type: JOB Desc2:
Event Name: ZEKE60TST6
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: TSKKGUT1
Class:
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
Bim:
Mbr:
JESQ (Y, D=dynamic):
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 ===>
EDIT
Scroll ===> PAGE
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.
Access the Event Master Definition screen for the event, as instructed in Accessing
the Event Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 32
Desc: TEST JOB
Type: JOB Desc2:
Event Name: TESTADDNM
App:
Grp:
Usrid:
DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 4
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 00:30 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: NOMTEST
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
140
Class:
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
4 Events
B - Browse
D - Delete
Type: JOB
Job: NOMTEST
Evt Name: TESTADDNM
Calid: A
Info:
Platform: MVS
Version Clause (partial)
More
==========================================================================
00000 (EOJ TESTJOB0)
00002 (EOJ TESTJOB0 OR VAR $TESTVAR EQ YES)
00003 (EOJ TESTJOB2)
00004 (EOJ TESTJOB0 AND EOJ TESTJOB2 VER 2)
******************************Bottom of data******************************
All the WHEN conditions that have been defined for the event are listed, with their
corresponding version numbers.
If a dependency is longer than the width of the screen (indicated by a '>' symbol in
the More column), you must access the Event Master Record Function screen to
view the remainder of the statement. To do so, use the Browse line command as
described in the next step.
3
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
141
Desired Result
Action
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:
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
Access the Event Master Definition screen for the event, as instructed in Accessing
the Event Definition on page 58.
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
Jobname: SPTEXD11
Operators:
Actions:
System: ZEQA
EQ NE LE LT GE GT
F = Fail, C = Cancel,
RA =Range
O = Ok
Stepname
Procstep
Operator
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
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
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
LE
LT
GT
GE
NE
RA
Low
High
Action
Indicates the action to take when the condition code meets the specified
criteria. These are the valid codes:
145
Field
Description
F
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.
EDIT
Scroll ===> PAGE
Jobname: SPTEXD11
Operators:
Actions:
Stepname
EOJ CC
STEP3
********
146
System: ZEQA
EQ NE LE LT GE GT
F = Fail, C = Cancel,
Procstep
********
********
Operator
EQ
GT
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
Jobname: SPTEXD11
Operators:
Actions:
System: ZEQA
EQ NE LE LT GE GT
F = Fail, C = Cancel,
Stepname
Procstep
EOJ CC
STEP3
STEP5
********
********
Operator
GT
EQ
LE
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
Jobname: SPTEXD11
Operators:
Actions:
Stepname
EOJ CC
STEP3
STEP5
********
System: ZEQA
EQ NE LE LT GE GT
F = Fail, C = Cancel,
Procstep
********
********
********
Operator
EQ
LE
GT
RA =Range
O = Ok
- Range Low High
4
8
0
Action
O
O
F
147
EDIT
Scroll ===> PAGE
Jobname: SPTEXD11
Operators:
Actions:
Stepname
EQ NE LE LT GE GT
F = Fail, C = Cancel,
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
Jobname: SPTEXD11
Operators:
Actions:
148
System: ZEQA
EQ NE LE LT GE GT
F = Fail, C = Cancel,
Stepname
Procstep
Operator
EOJ CC
MYSTEP
********
********
EQ
GT
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 approval
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.
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
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')
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
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.
Access the Event Master Definition screen, as instructed in Accessing the Event
Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT
OCCURS PATH PRED REACT RESOURCE SUCC WHEN
Template: N
Permanent: N
Milestone: N
Evt: 246
Desc: OBTAIN AUTH FOR JOB CASH0200
Type: WORK Desc2:
Event Name: CASH0199
App:
Grp:
Usrid: EAN
DRL:
System: ZEQA
Cal: A
Retain: N Nwday: B Multhit: N Exp:
Target: *LOCAL
Verload: 0
Latestart:
Early:
Sched: 00:00 Mustend:
Notafter:
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq:
Freqcalc: S Trig: A
SchEnv: ASGSCHEDUENVIRON
WorkCtr
WorkCtr
WorkCtr
WorkCtr
WorkCtr
WorkCtr
Line
Line
Line
Line
Line
Line
1:
2:
3:
4:
5:
6:
151
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
Event Name
Specify the name of the work center event. The event name is
displayed on Zeke online screens and reports, and can be used as
selection criteria. The event name also can be specified in
end-of-event (EOE), abnormal-end-of-event (AEOE) and
end-of-group (EOG and AEOG) WHEN conditions.
Usrid
Specify the user ID (up to eight characters long) for the user
authorized to access the work center event.
Since Zeke supports mixed-case user IDs, be sure to specify the
desired user ID in the correct case (upper, lower, or mixed).
Note:
This user ID is for Zeke internal security only.
System
Specify the system or pool that owns the work center event (which can
be associated with only one system).
Note:
This is the system where the event is dispatched, and not necessarily
the system where the EMR was defined.
152
4 Events
Field
Description
Verload
Specify the number of versions of this event that Zeke loads during the
schedule build. The valid values range from 0 to 32767. The default
value is 0.
For example, if Verload is set to 3, Zeke adds EMRs to the schedule
for three versions of the event during schedule build (i.e., versions 1,
2, and 3).
If Verload is set to 0, then only one version of the event (version zero)
can be in the schedule at a time.
If Verload is set to 1, Zeke loads only one version during the schedule
build, but you can use the ZADD operator command to add multiple
versions (up to 32,767) to the schedule after the schedule load.
Note:
ASG recommends that you run no more than 1,000 versions of a
single event.
See Creating Multiple Versions of an Event on page 76 for details
on multiple event versions.
Note:
The SKIP(OFF) attribute is applied to the end of the Target field (the
previous field on the EMR), to prevent you from overtyping data
intended for the Target field so that it overflows into the Verload
field. Stray characters in the Verload field could result in an
excessive number of events being scheduled unintentionally during
the next schedule build.
WorkCtr Line
153
Complete these fields (as applicable), which enable you to group events for selection
for scheduling or reporting:
Field
Description
App
Grp
Specify the code (up to three characters long) to identify the group ID
associated with the work center event. This field is a subset of the
application ID.
Press Enter to save the changes. The screen is redisplayed in Update mode. If you
are adding the event, Zeke assigns a unique event number.
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 ===>
EDIT
Scroll ===> PAGE
A SET clause is used instead of a WHEN condition for work center events.
6
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
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).
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
Not Done
All
Done
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
App
Group
System
Specify the system or pool that owns the work center (which can be
associated with only one system).
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
******************************
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
156
4 Events
Desired Result
Action
Primary Commands:
Event: 000229
Appl: PAY
COMPLETE
DISABLE
DOCUMENT
ENABLE
REFRESH
System: A
Set ver: 00000
Note:
You can press Enter to display additional SET statements when there are multiple
variables.
This procedure is complete.
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
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 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 ===>
Row 1 to 2 of 2
Scroll ===> PAGE
CANCEL
Event: 000229
Ver: 00000 Sdate: 01/30/2012
Rdate: 01/30/2012
Today :01/30/2012
Time :15:59:27 (39:59:27) Set Ver: 00000
-------------------------------------------------------------------------Variable: $PAYCHECK
?Value: '1051'
****************************** Bottom of data*******************************
11
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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
Description
Aur
AurIntv
AurMsg
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.
160
Determine the how automatic replies are set up for your Zeke systems
globally. See Auto Reply Options on page 308.
If there are exceptions to how automatic replies are set up globally, use
ZDISPLAY, ZENABLE, and ZDISABLE operator commands, as applicable.
See Managing Auto Replies on page 163.
Access the Event Master Definition screen, as instructed in Accessing the Event
Definition on page 58.
4 Events
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 ===>
E - Edit
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Add an auto reply element Enter ADD on the Command line, and press Enter.
Delete all auto reply
elements
Edit the auto reply element Enter E to the left of the NUM field, and press Enter.
Delete the specific
auto reply element
161
Auto-Reply Function
EDIT
Update complete
Jobname: SPTEXD19
System: ZEQA
Desc: EKGSTRT1
Desc2:
Automatic Reply Element Number: 001
Msg text: ENTER GO TO PROCESS
Reply: GO
Effective as of: 01/01/2012
Effective until: 06/01/2012
Job step name: STEP1
Program (Exec):
<==
<==
MM/DD/YYYY
MM/DD/YYYY
The Automatic Reply Element Number is the Zeke-assigned number that identifies
the reply element. When there are multiple replies to the same message text, Zeke
issues the elements in sequence starting with the lowest number and flags the
element as used. If the message is issued more times than there are replies, the last
used element is repeated. If a message is defined with only one reply, Zeke issues
that reply as many times as needed.
5
Description
Msg Text
Specify the message to which to reply. This does not need to be the
whole message (just enough to make a unique match). The message
ID usually is a unique identifier.
Reply
Specify the reply that Zeke issues to the message. For example:
To enter a null reply
Effective As Of
162
4 Events
Field
Description
Effective Until
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.
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
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
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
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.
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
Note
Scratch
Text
4 Events
From the Zeke Primary Menu, enter option 7. The Documentation Selection Criteria
screen is displayed.
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Update documentation
for which you know the
event number
Update documentation
for which you do not
know the event number
165
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
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
166
4 Events
Desired Result
Action
Scratch Pad
Text
Note Pad
The asterisk (*) indicating that documentation for the
event exists is deleted, and the message:
DOCUMENT RECORD DELETED is displayed.
Documentation Segments
EDIT
System: A
Appl:
Scratch pad
Text information
Dataset name information
Note pad information
An asterisk (*) indicates the types of documentation that exist for the event.
4
Enter one of these codes on the Command line to select the type of documentation
to work with:
Desired Result
Action
167
Desired Result
Action
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
CANCEL
DELETE
EDIT
EDIT
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.
169
Text Documentation
EDIT
Columns 000 000
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.
Access the Data Set Name List screen, as instructed in Accessing Event
Documentation on page 165.
ASG-Zeke
Command ===>
Primary commands:
BROWSE CANCEL DELETE EDIT
Line commands: D Delete line
I Insert line
Event: 000031
EDIT
R Repeat
Event Name: TESTNAME
170
4 Events
Description
I/O
T/D
Ver
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
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Delete a line
171
Access the Event Master Definition screen, as instructed in Accessing the Event
Definition on page 58:
ASG-Zeke
Command ===>
EDIT
Event===>
Primary Commands: ACCT ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC
EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN
Template: N
Permanent: N
Milestone: N
Platform: MVS
Evt: 333
Desc: TEST JOB KMC
Type: JOB Desc2:
Event Name: ZEKEKMCASG
App: B2345678 Grp: G23 Usrid: EANTEST DRL: 2
System: ZEQA
Cal: A
Retain: Y Nwday: A Multhit: Y Exp:
Target: *LOCAL
Verload: 0
Latestart: 13:00
Early: 11:00 Sched: 10:00 Mustend: 14:00 Notafter: 12:00
Lateend: 00:00
Dprty: 50
Operok: N
Times: 1
Freq: 01:01 Freqcalc: S Trig: A
Control: Y Tapes: 0
Avgdur: 00:00:00 SecGroup:
SchEnv: ASGSCHEDUENVIRON
Job: MBCBR14
JCL--> PDS:
Member:
Zeke JCL (Y=Yes): Y
172
Class:
Pri: 0
CMS:
Ftype:
JESQ (Y, D=dynamic):
4 Events
Enter ACC on the Command line, and press Enter. The Event Master Record
Accounting screen is displayed:
ASG-Zeke
Command ===>
BROWSE
Type: JOB
Avgdur: 00:12:15
Alert Tolerance: 50
Job: MBCBR14
Ename: ZEKEKMCASG
System: ZEQA
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
Tapes:
0
Comp.code C0000
Vmem:
0
Status: Fail Long
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:
Whether the DurAlert generation option has been overridden for the event.
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.
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
SUCCESS indicates that the event completed successfully (or the event
completed successfully after failing once).
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.)
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.
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.
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.
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.
Description
DurAlert
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.
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
Access the Event Master Record Accounting screen, as described in Viewing Event
Accounting Information on page 172:
ASG-Zeke
Command ===>
BROWSE
Type: JOB
Avgdur: 00:12:15
Alert Tolerance: 50
Job: MBCBR14
Ename: ZEKEKMCASG
System: ZEQA
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
Tapes:
0
Comp.code C0000
Vmem:
0
Status: F/FAIL
Tapes:
0
Comp.code C0000
Vmem:
0
Status: Fail Long
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.
180
Chapter 5:
The main purpose of Zeke is to ensure that your jobs are dispatched in the most efficient
and timely order possible. To accomplish this, Zeke enables you to create a schedule of
events using the SCHEDULE function.
Along with creating a daily schedule of actual events, Zeke also provides ways to forecast
a schedule for a future date and to simulate the run of a schedule complete with initiators,
tape drives, and any defined logical resources.
You can monitor the progress of your scheduled events, as well as intervene, through the
ISPF online facility, Schedule View.
This chapter discusses these topics:
Topic
Page
182
183
184
186
186
187
187
188
191
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
247
247
249
252
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
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
Monday
27:00
Tuesday
03:00
Tuesday
Deletes completed jobs and retains uncompleted events from the previous days
schedule.
Note:
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.
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
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:
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
When necessary, you can use the SCHEDULE function to create the schedule manually
(see Creating the Schedule Manually on page 184).
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.
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.
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.
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.
For example:
//ZEKESCHD JOB
//SCHED EXEC ZEKEUTL,PARM=SUBSYS=ZDEV
//SYSIN DD*
SCHEDULE DATE 08/23/2012 DATASPACE
/*
For more information on using the ZEKE utility program to forecast the schedule, see the
ASG-Zeke Scheduling for z/OS Reference Guide.
188
Keyword
Description
Console
Exception
Schedule
Jobflow
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:
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.
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
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
$$
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.
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
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
EDIT
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
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
These ISPF primary commands are valid on the Command line in Schedule View:
Command
Action
X ALL
F STRING NEXT
F STRING FIRST
F STRING LAST
F STRING ALL
RESET
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
ADDOK
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
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
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
Hold
JCLR
Valid for job events only. Retrieve the actual JCL (from the JCL source) for the
selected event, so that you can view or update it. The JCL must reside on the
same system where you issue the command.
You can issue the ZOOM line command for the same event to display the
Schedule View Record Expand Function screen where you can view, update, or
delete the JCL. See Accessing an Expanded SQR (Using ZOOM) on page 216
for more information.
Note:
This command is not supported for SQRs that have JESQ as the JCL source.
JPREP
Valid for job events only. Invoke JCLPREP for JCL scanning.
See Invoking ASG-JCLPREP on page 231 for more information.
Note:
This command is not supported for SQRs that have JESQ as the JCL source.
195
Command
Action
LDSN
Valid for job events only. Display the List DSN Detail Information screen.
Note:
This function requires Zebb to be active on this Zeke system.
Press F3 or Enter to return to Schedule View.
NOTE
OK
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
Display the Pathfinder screen to display the events on which the selected event
or job is dependent.
See PathFinder on page 241 for more information.
REB
Rebuild the SQR for the selected event, and re-assign its current status.
Note:
Rebuilding an event has the same effect as deleting the event from the
schedule, and re-adding it.
REBH
Rebuild the SQR for the selected event, and place the event on hold.
REF
Refresh the SQR for the selected event by resetting the event as if it had not yet
run. Zeke places a refreshed event on operator hold automatically.
You must issue the REL line command to release the event to enable Zeke to
dispatch the event.
REL
RESO
196
Command
Action
RSTRT
Valid for job events only. Display the Job Restart Management screen for the
selected event.
Note:
This function requires Zebb to be active on this Zeke system.
Press F3 or Enter to return to Schedule View.
RUN
Satisfy all conditions for the selected event, and dispatch the event.
Note:
Zeke ignores any NOTDURING WHEN conditions for the event (until you
rebuild the SQR from the EMR).
SCAN
Valid for job events only. Scan and validate the selected events JCL that is to
be submitted by Zeke.
See Validating JCL on page 231 for more information.
Note:
This command is not supported for SQRs that have JESQ as the JCL source.
SUCC
Display the Pathfinder screen for events that are dependent on the selected event
or job.
See PathFinder on page 241 for more information.
SYSx
View the JES2 job output information for the selected event, where x is one
of these codes:
L
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
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
WORK
Valid for work center events only. Display the Work Center Selection Criteria
menu.
ZEBB
Valid for job events only. Display the Job Functions Menu.
Note:
This function requires Zebb to be active on this Zeke system.
Press F3 or Enter to return to Schedule View.
ZOom
Display the Schedule View Record Expand Function screen for the selected
event.
This ZOOM screen is similar to the EMR screen, except that changes on the
Schedule View Record Expand Function screen are temporary (i.e., only for the
current schedule run).
See Accessing an Expanded SQR (Using ZOOM) on page 216 for more
information.
. . . .
Create your own CLIST or REXX command that can be executed from
Schedule View.
See Custom Line Commands on page 199 for more information.
198
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
From the Zeke Primary Menu, enter option 2. The Schedule Information Selection
Criteria screen is displayed:
ASG-Zeke
Command ===> 1
1
2
3
4
Schedule View
ZCOM
ADD Function
ADD by path
Event ===>
Event Types
Selection Field Masks
Job:
Job Name:
Msg:
Event Name:
Pcom:
Application:
Work:
Group ID:
Vcom:
User ID:
Zcom:
System:
Scom:
Disp Class:
REXX:
Sched Date:
Run Date:
Target:
Permanent:
Milestone:
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
Active events.
Pend
Pending events.
Sched
Done
Hold
Late
Needs OperOK
Needs TimeOK
Needs WhenOK
201
Field
Description
ABOK
Fail
FBOK
FSucc
Schedule View displays only the SQRs that match the selection criteria:
ASG-Zeke
Command ===>
Event ===>
Schedule View
System=SYSD
BROWSE
Scroll ===> PAGE
Selected=0000004
2012.022
15:45
Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ?
Line Commands: Del Delete Wh When
? to list other Line Commands
Line Event Sched
Job
Evnt Event
Event Status
Cmd
No.
Date
Name
Type Name
Reason Code
==========================================================================
000001 2012053
MSG ZEKEEVTST1
Queued Need Oper OK
000002 2012053
MSG ZEKEEVTST2
Scheduled Time OK
000003 2012053
MSG ZEKEEVTST3
Scheduled Time OK
000004 2012053
MSG ZEKEEVTST4
Scheduled Time OK
000005 2012053
MSG ZEKEEVTST5
Scheduled Time OK
000006 2012053 TSKKGUT1 JOB KTEST1
Scheduled Time OK
000007 2012053 TSKKGUT2 JOB KTEST2
Success
000008 2012053 TSKKGUT3 JOB KTEST3
Active
90%
000009 2012053 TSKKGUT4 JOB KTEST4
Success
000010 2012053 TSKKGUT5 JOB KTEST5
Success
000011 2012053 SPTEXD11 JOB ZEKEEVCC
Scheduled Time OK
000012 2012053 SPTEXD12 JOB ZEKEEVCC
Scheduled Time OK
000013 2012053
WORK
Scheduled Time OK
From the main Schedule View screen, you can scroll left and right, and up and
down, to display all of the SQR fields (depending on how you set your display
characteristics). Use the normal ISPF scroll commands LEFT and RIGHT to view
additional fields.
202
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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.
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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
Type over the value in the System field, and press Enter.
Specify the name of the class in the Dsptch Class field, and
press Enter.
Specify the number of tape drives in the No. Tap field, and
press Enter. The valid values range from 0 through 255.
204
Desired Result
Action
*RF
*R
other
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
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.
206
Event Statuses
This table describes the event status codes that Zeke displays in Schedule View:
Event Status Code
Description
Active
Dispatching
Fail
Fail Forced
Queued
Scheduled
Success
Success Forced
207
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.
Disabled
208
Download Hold
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.
The event completed, but its duration was longer than or shorter than
its acceptable range of duration times (i.e., its Normal Range).
The event is active, and is running longer than its acceptable range
of duration times (i.e., its Normal Range).
Failed Once
Reason Code
Description
Forced
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
Internal Hold
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.
Multiple Systems
Need Initiator
Need Oper Ok
209
Reason Code
Description
Network Hold
The Not After time or the Must End time has been reached.
Notduring Wait
Operator Hold
Pending
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
Refresh Hold
Security Hold
SCHENV Wait
SJCL Hold
System Hold
210
Reason Code
Description
Time OK
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.
When OK
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
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Satisfy or complete an
individual WHEN condition
212
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.
Access Schedule View, and locate the desired event (as described in Displaying
Scheduled Events on page 200).
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 ****************************
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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.
214
Press Enter.
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.
Access Schedule View, and locate the desired event (as described in Displaying
Scheduled Events on page 200).
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
Jobname = TSKKGUT1
Rel - Release the resource
215
Note:
If there are no resources defined for the event, this message is displayed:
**** NO RESOURCE DEFINED ****
3
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Note:
If there are no resources currently being held for the event, this message is
displayed:
**** RESOURCE NOT HELD ****
4
See the ASG-Zeke Scheduling for z/OS Installation Guide for information about
activating Panvalet and Librarian support in Zeke.
216
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
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
Sched: 00:00
Dprty: 50
Cntrl: Y
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
D - Delete
Grp:
Mustend:
Notafter:
Freqcalc: S
Virt Mem:
E - Edit
Usrid:
Trig: A
R - Retrieve
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
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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
BROWSE
Platform: MVS
JES2 Job Id:
Job: TSKKGUT1
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
Note:
See Accessing an Expanded SQR (Using ZOOM) on page 216 for more
information on updating an SQR in ZOOM mode.
3
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.
You can enable or disable the automatic monitoring function, and change the screen
refresh rate (when this feature is enabled).
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.
219
From the Zeke Primary Menu, enter option C.3. The Schedule View Sort Setup
screen is displayed:
ASG-Zeke
Command ===>
Row 1 to 16 of 33
Scroll ===> PAGE
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
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
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.
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
From the Zeke Primary Menu, enter option C.2. The Schedule View Display Setup
screen is displayed:
ASG-Zeke
Command ===>
Row 17 of 33
Scroll ===> PAGE
Order
----170
180
190
200
210
Field Description
*Date Format: YYYYDDD
-----------------------------------------------------------------Version Number
Frequency Calc
Trigger Type
Long Job Name
Download Status
----- Fields above are displayed; fields below are not ----CNT (number of times)
DP (Dispatch Priority)
Early Dispatch Time
Event Name
Event Type
Freq (dispatch interval)
Late Dispatch Time
Must End Time
Run Date *
Status Time
Fields listed above the line are displayed in the user-specified sequence. Unused
fields (below the line) are listed alphabetically, for convenience.
2
222
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 ===>
Row 1 of 33
Scroll ===> PAGE
0
0
0
0
0
0
0
0
0
0
0
0
Order
----10
20
30
40
50
60
70
80
90
100
110
120
130
140
150
160
Field Description
*Date Format: YYYYDDD
-----------------------------------------------------------------Event Number
Schedule Date *
Schedule Time
Status/Reason Code
Job Name
Event Type
Event Name
DP (Dispatch Priority)
Late Dispatch Time
System Identification
Run Date *
Freq (dispatch interval)
CNT (number of times)
Status Time
Early Dispatch Time
Must End Time
Note:
On the Schedule View screen, the DOC, JCL, AUTO REPLY, RESOURCE,
CODE, and WHEN fields always appear as the last six fields, and cannot be moved.
223
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
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.
224
From the Zeke Primary Menu, enter option 2.1. The Schedule View screen is
displayed.
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
Access EMRs
Enter EMR on the Command line, and press Enter. The Event
Master Selection Criteria screen is displayed.
Or
Enter EMR in the Line Cmd field for an event, and press Enter.
The Event Master Definition screen is displayed in Browse
mode.
See Event Master Record (EMRs) on page 52 for more
information.
Access online
documentation
Access PathFinder
PRED
SUCC
225
Desired Result
Action
Access Zebb
DSN
LDSN
RSTRT
Note:
This function requires Zebb to be active on this Zeke system.
Display SQR information
on one screen
Enter ZOOM in the Line Cmd field for the selected event, and
press Enter.
See Accessing an Expanded SQR (Using ZOOM) on
page 216 for more information.
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
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
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
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> -Warning- The UNDO command is not available until you change
==MSG>
your edit profile using the command RECOVERY ON.
000001 //ZEKTST29 JOB (26010,200),'JOHN DOE X9999',CLASS=A,MSGCLASS=A,
000002 //
USER=PDDOE,PASSWORD=WHILEOUT
000003 //*
000004 //ZEKE EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000005 //STEPLIB DD DISP=SHR,DSN=ZEKE.PDDOE.LINKLIB
000006 //
DD DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000007 //
DD DISP=SHR,DSN=OASIS.LINKLIB
000008 //SYSPRINT DD SYSOUT=*
000009 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
000011 //SYSIN
DD *
000012 SET WAIT 1
000013 //*
****** ************************** Bottom of Data **************************
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
10
Optional. You can check your JCL for syntax errors without affecting the actual
SQR. See Validating JCL on page 231.
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.
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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
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
Job: ZEK806
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
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.
Job: ZEK806
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
Validating JCL
After you create or edit JCL, you can check it for syntactical errors using one of these
facilities:
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:
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.
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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: 00:00
Dprty: 50
Cntrl: Y
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
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> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF).
==MSG>
Data has valid standard numbers.
==MSG> -Warning- The UNDO command is not available until you change
==MSG>
your edit profile using the command RECOVERY ON.
000100 //ZEKTST30 JOB (10038),'J SMITH',
000200 //
MSGCLASS=Y,CLASS=A,
000300 //
REGION=4M
000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000610 //STEPLIB DD
DISP=SHR,DSN=OASIS.LINKLIB.MVS1
000620 //*
DD
DISP=SHR,DSN=OASIS.LINKLIB.DVLP
000630 //
DD
DISP=SHR,DSN=OASIS.LINKLIB
000640 //*
DD
DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB
000650 //*
DD
DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB
000660 //*
DD
DISP=SHR,DSN=ZEKE.PDBER.LINKLIB
000670 //
DD
DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000680 //
DD
DISP=SHR,DSN=ZEKE.LINKLIB
000690 //*
DD
DISP=SHR,DSN=ZEBB.TEST.LINKLIB
000691 //
DD
DISP=SHR,DSN=ZEBB.LINKLIB
000700 //SYSPRINT DD SYSOUT=*
000800 //SYSMDUMP DD DISP=SHR,DSN=* Your Dump Dataset Name *
000900 //SYSIN
DD *
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.
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.
For SQRs with JESQ as the JCL source, the JCL cannot be viewed or edited.
1
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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: 00:00
Dprty: 50
Cntrl: Y
Times:
Tapes:
LateStrt:
LateEnd: 00:00
Freq:
AvgDur: 00:00
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> -CAUTION- Profile changed to NUMBER ON STD (from NUMBER OFF).
==MSG>
Data has valid standard numbers.
==MSG> -Warning- The UNDO command is not available until you change
==MSG>
your edit profile using the command RECOVERY ON.
000100 //ZEKTST30 JOB (10038),'J SMITH',
000200 //
MSGCLASS=Y,CLASS=A,
000300 //
REGION=4M
000400 //STEP01 EXEC PGM=ZEKESET,PARM='SUBSYS=GWS5'
000610 //STEPLIB DD
DISP=SHR,DSN=OASIS.LINKLIB.MVS1
000620 //*
DD
DISP=SHR,DSN=OASIS.LINKLIB.DVLP
000630 //
DD
DISP=SHR,DSN=OASIS.LINKLIB
000640 //*
DD
DISP=SHR,DSN=ZEKE.OASIS.M1.LINKLIB
000650 //*
DD
DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB
000660 //*
DD
DISP=SHR,DSN=ZEKE.PDBER.LINKLIB
000670 //
DD
DISP=SHR,DSN=ZEKE.LINKLIB.DVLP
000680 //
DD
DISP=SHR,DSN=ZEKE.LINKLIB
000690 //*
DD
DISP=SHR,DSN=ZEBB.TEST.LINKLIB
000691 //
DD
DISP=SHR,DSN=ZEBB.LINKLIB
000700 //SYSPRINT DD SYSOUT=*
000800 //SYSABEND DD SYSOUT=*
000900 //SYSIN
DD *
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.
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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:
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.
Access Schedule View, and locate the event that you want to update (as described in
Displaying Scheduled Events on page 200).
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
Zeke Dispatching
Zeke determines the order in which events are dispatched by evaluating these event
attributes or conditions in sequence:
1
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
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.
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.
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:
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.
From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions
screen is displayed:
ASG-Zeke
Option ===>
BROWSE
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
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 ===>
BROWSE
Row 1 to 17 of 30
Scroll ==> PAGE
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
From the Zeke Primary Menu, enter option 2.2. The Schedule Control Functions
screen is displayed.
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
The specified job is the zero (0) level job and is displayed at
the top of the screen. All jobs that are triggered by this job are
displayed below the Level 0 job beginning with the first job
(Level 1). Displayed under each Level 1 job are all the jobs
that it triggers (Level 2 through the end).
If a condition has already been displayed, this message
appears directly underneath the job that triggered it:
CONDITION ALREADY DISPLAYED ABOVE
Display all predecessors
Issue one of these commands from the Option line:
and successors for an event
ZD PRE SU LEV * JOB jobname
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
Note:
The predecessors cannot be displayed because those events
do not have WHEN conditions.
Display different levels in
the hierarchy
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
MYTEST
(Level 0)
ALHJOB2
(Level 1)
DONETST
(Level 2)
ZTSRPT9T
(Level 2)
ZTSERAXT
(Level 3)
ZTSBKUP
(Level 4)
ZTSDONE
(Level 4)
BROWSE
Row 1 to 5 of 5
Scroll ==> PAGE
244
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)
REQUESTED EVENT:
DATE
VERS WHEN TRIGGER NAME T-VER STATUS AVDUR
2012038 0000
*
00:00
2012038 0000
*
00:00
2012038 0000
*
00:00
2012038 0000 EOJ ZTSVLDT3
T
00:00
EOJ ZSJOBAT
4*ZTSVLDT2
JOB 001008 2012038 0000
*
00:00
3 ZTSJOBDT
JOB 001006 2012038 0000 EOJ ZTSJOBBT
T
00:00
EOJ ZTSVLDT2
2 ZTSJOBKT
JOB 001004 2012038 0000 EOJ ZTSVLDTT
T
00:00
EOJ ZTSJOBDT
>>1 ZEKTST04
JOB 001003 2012038 0000 EOJ ZTSJOBKT
T SCHD 00:00
-----------------------------------------------------------------------------0 MYTEST
JOB 001002 2012038 0000 EOJ ZEKTST04
T
00:00
******************************* Bottom of data ********************************
245
BROWSE
Row 1 to 17 of 131
Scroll ==> PAGE
predecessors
successors
246
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.
From the Zeke Primary Menu, enter 2.2 and press Enter. The Schedule Control
Function screen is displayed:
ASG-Zeke
Option ===>
BROWSE
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
247
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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
248
From the Zeke Primary Menu, enter option 2.3. The ADD Event Record Selection
Criteria screen is displayed:
ASG-Zeke
Command ===>
Options:
Auto:
Hold:
Rerun:
Run:
N
N
N
N
(Y/N)
(Y/N)
(Y/N)
(Y/N)
Enable: N
Rebuild: N
Refresh: N
(YYYYDDD)
(Y/N)
(Y/N)
(Y/N)
2012.055
15:26
(YYYYDDD)
Event ===>
Enter a selection mask in any field(s) to be compared for selection.
* - is a prefix/suffix indicator.
? - is a wild/place holder character.
Event Types
Job:
Msg:
Pcom:
Work:
Vcom:
Zcom:
Scom:
REXX:
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
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
Refresh
Run
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 ===>
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.
From the Zeke Primary Menu, enter option 2.4. The ADD Event Record by Path
Selection Criteria screen is displayed:
ASG-Zeke
Command ===>
Criteria:
Event
Version
Occurs Date
Level
Type
==>
==>
==> 2012022
==> 1
==> B
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)
Description
Event
Required. Specify the event number for the root event (i.e., the event for
which to display the path information).
Version
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
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
Hold
253
Field
Description
Rebuild
Refresh
Rerun
Run
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
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
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
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:
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
Tape drives
Initiator Processing
Before you determine whether that you want to activate initiator processing, you need to
understand how initiator selection occurs. Defining initiators to Zeke does not mean that
Zeke controls them; instead, it lets Zeke know which initiators are eligible for selection.
No matter how an initiator is selected (i.e., by Zeke or by JES), these are some of the
many factors that determine the actual initiator:
258
6 Resources
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:
An auto reply defined for one initiator is valid for all initiators.
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
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 is available
UserCls=Y?
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 ===>
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
Perform the steps in the Action column (depending on the desired result).
Desired Result
Action
EDIT
Scroll ==> PAGE
_
_
_
_
_
_
_
_
_
_
_
_
Initid
A
T004
T03
T2
1
2
B
C
D
E
F
G
MTWTFSS
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
NNNNNNN
Perform the steps in the Action column (depending on the desired result).
Desired Result
Action
Add an initiator
263
Desired Result
Action
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 .
System Id : EDMVS
Initiator Id:
EDIT
A1
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.)
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 ===>
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:
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 ===>
EDIT
Scroll ==> PAGE
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 ===>
EDIT
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
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
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.
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.
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
From the Zeke Primary Menu, enter 4.5 and press Enter. The System Pool
Directory is displayed:
ASG-Zeke
Command ===>
Row 1 to 1 of 1
Scroll ===> PAGE
E - Edit
Pool ID
Description
**************************************************************************
POOL1
TEST POOL
MAIN
PROD1 POOL
***************************** Bottom of data ******************************
Perform the steps in the Action column (depending on the desired result).
Desired Result
Action
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
EDIT
Scroll ==> PAGE
POOL1
R - Repeat a line
SYSTEM
TSO45
Perform the steps in the Action column (depending on the desired result).
Desired Result
Action
Add a system to a
new pool
In the System field, enter a name for the new system name.
You can enter up to 15 systems on one screen. To add more than 15
systems, press F8 to view additional blank entry lines.
Note:
Do not use any Zeke operands, parameters, or keywords (or
abbreviations of these) to name your systems or pools. For example,
do not name a system or pool AB (which is short for the parameter
ABEND).
Add a system to an
existing pool
270
Edit an existing
system
Delete a system
from a pool
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.
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
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
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
272
6 Resources
Desired Result
Action
Resource Detail
Resource name:
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
Access the EMR for the event, or the Event Master Directory, as described in,
Accessing the Event Definition on page 58.
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
Resource Control
EDIT
Scroll ===> PAGE
System: ZEQA
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:
In the Md field, specify the resource mode required by the job. These are the valid
codes:
Code
Meaning
EX
ES
275
Code
Meaning
SR
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.
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
The event assumes the resource only from itself (if the event abends).
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
System: ZEQA
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
Chapter 7:
7
Zeke provides you with a great amount of flexibility and control over Zeke operations
including event scheduling and dispatching, as well as maintenance and database access.
This chapter discusses these topics:
Topic
Page
280
280
281
287
290
291
293
295
296
297
309
309
312
319
320
324
325
325
326
327
329
Database Maintenance
Creating the Zeke Databases (Primary and Vault)
Backing Up the Zeke Database
Restoring the Zeke Database
Moving the Vault Database
Recovery Using Electronic Vaulting
330
331
333
334
337
338
279
Topic
Page
340
341
341
344
344
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
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
********
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).
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 *******************************
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
Description
Audit
Audit options.
Dispatching
Exits
General
JCL
Messages
Scheduling
Security
Traces
User interfaces
Variables
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.)
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]
284
This is an example of the detail view by category for the same GENOPT:
ASG-Zeke
Command ===>
Generation Options
Description:
BROWSE
Row 1 to 17 of 152
Scroll ===> CSR
Option
Value
--------- ---------====================
====================
Aur: Y
AurIntv: 1
CalcMem: Y
CalcTap: Y
DispDly: 30
DispSel: Y
Description
--------------------------------------------------------Audit ===================================================
Dispatching =============================================
(Y,N)
Yes to enable automatic responses
(1-99)
Number of seconds to check auto responses
(Y,N)
Yes to calculate virtual memory
(Y,N)
Yes to calculate tape drive usage
(nnnnn)
Seconds to delay dispatching pooled events
(Y,N)
Yes for Zeke to select initiators
(Yes is ignored for JES3)
Idcams: N
(Y,N)
Yes to replace occurences of IDCAMS
IgnCat2: N
(Y,N)
Yes to ignore NOT-CAT2 messages
PauseEoj: N
(Y,N)
Yes to pause partition at FAIL
ScomMax: 1
(nn)
Maximum subtasks for SCOMs
ScomWt: 5
(nn)
Maximum minutes before SCOM timeout
TapeIO: 100
(nnn)
Number of tape I/Os before Zeke calculates
==================== Exits ===================================================
DynSmf: Y
(Y,N)
Yes to dynamically install SMF exit
In a detailed view by category, the categories are listed alphabetically and the
applicable fields are listed alphabetically under each category. All category
headings are displayed, even if there are no fields in that category associated with
the selected GENOPT.
Note:
Based on the definition of the GENOPT (i.e., local or global, some options might
not be applicable.
4
Scroll through the pages on the Generation Options screen and review the options.
Or
To quickly find a particular field or category, you can use these primary commands:
Command
Description
FIND
Finds and moves the cursor to the beginning of the specified text string
in field names, values, descriptions, and category headings. This is the
command format:
FIND string
For example, this command finds and places the cursor at the
generation option field named Jcl1:
FIND JCL
285
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
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
Option
--------Aur:
AurIntv:
AurMsg:
BimAppl:
BimPasw:
BimUid:
CalcMem:
CalcTap:
ChgVal:
286
Value
---------Y
1
Y
OMIT
Y
N
Y
EDIT
Found 'DISP'
Scroll ===> CSR
Description
--------------------------------------------------------(Y,N)
Yes to enable automatic responses
(1-99)
Number of seconds to check auto responses
(Y,N)
Yes to inform operator auto. response issues
(xxxxxxxx) Bimedit application name
(xxxxxx)
Bimedit access password
(xxxx)
Bimedit access userid
(Y,N)
Yes to calculate virtual memory
(Y,N)
Yes to calculate tape drive usage
(Y,N)
Yes to display Variable update message
This is the result when you issue the command FIND DISP when the screen is in
category mode (i.e., CAT ON):
ASG-Zeke
Command ===>
Generation Options
Option
Value
--------- ---------====================
Aur: Y
EDIT
Row 2 to 18 of 152
Scroll ===> CSR
Description
--------------------------------------------------------Dispatching =============================================
(Y,N)
Yes to enable automatic responses
This is the result when you issue the command LOCATE DISP:
ASG-Zeke
Command ===>
Generation Options
EDIT
Row 14 to 30 of 141
Scroll ===> CSR
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.
Follow the procedure in Accessing the Zeke Generation Options on page 281.
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.
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
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 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.
Scroll through the pages on the Generation Options screen and review the options.
Make any necessary changes to the option settings.
Note:
By default, the options are listed alphabetically. You also can list the options by
category. To change the way the options are sorted, see step 3 on page 284, or to
quickly locate an option or category, see step on page 285.
288
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.
Follow the procedure in Accessing the Zeke Generation Options on page 281.
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
GENOPT name matches the system ID for the associated Zeke system.)
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.
Scroll through the pages on the Generation Options screen and review the options.
Make any necessary changes to the option settings.
Note:
By default, the options are listed alphabetically. To change the way the options are
sorted, see step 3 on page 284, or to quickly locate an option or category, see step
on page 285.
289
On the Command line, type SAVE to save the new GENOPT and remain on the
screen in edit mode, or type END to save the GENOPT and return to the GENOPTs
Directory.
Note:
You can type CANCEL to cancel adding the new GENOPT, if necessary.
Press Enter. The new GENOPT is added to the Zeke database.
Editing a GENOPT
You can edit all existing GENOPTs except *ACTIVE (which is generated automatically
by Zeke).
To edit a GENOPT
1
Follow the procedure in Accessing the Zeke Generation Options on page 281.
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
GENOPT name matches the system ID for the associated Zeke system.)
The Generation Options screen displays (in edit mode) the options and settings for
the selected GENOPT.
3
Scroll through the pages on the Generation Options screen and review the options.
Note:
By default, the options are listed alphabetically. To change the way the options are
sorted, see step 3 on page 284, or to quickly locate an option or category, see step
on page 285.
290
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)
Condor camlib device name
Condrlb: OMIT
(xxxx)
Condor camlib qualifier
Condrver: 001
(xxx)
Condor version id
Datasub: Y
(Y or N)
Yes for Zeke to substitute DOS JCL
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.
Follow the procedure in Accessing the Zeke Generation Options on page 281.
291
292
Name and new value of each updated option, and the required action to
activate the new setting.
Optional. To issue the ZRELOAD GENOPT command at this point, enter any
nonblank character in the Issue the ZRELOAD command field or enter the
ZRELOAD GENOPT command on the Command line. This command requires the
appropriate user authorization.
Deleting a GENOPT
You can delete any GENOPT except the special ones (i.e., ********, *GLOBAL, and
*ACTIVE).
To delete a GENOPT
1
Follow the procedure in Viewing GENOPT Details on page 283. The Generation
Options screen displays the options and settings for the selected GENOPT. Skip to
step 3b.
Or
Follow the procedure Accessing the Zeke Generation Options on page 281.
2
Enter D in the selection field to the left of the GENOPT that you want to delete.
Or
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.
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
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
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 ********************************
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:
Number of updated settings that you can activate by issuing a ZRELOAD GENOPT
command.
Name and new value of each updated option, and the required action to activate the
new setting.
As an option, you can reload the generation options at this point. This action requires the
appropriate user authorization.
You also can review any changes that have been made to the currently active GENOPT,
but have not been activated yet, without actually reloading the changes. See Viewing
Pending GENOPT Updates on page 291 for details.
295
Audit Options
The AUDIT utility (in OASIS) tracks Zeke database activity and logs the information in
an audit log file. You decide what types of activity that you want to audit. These are some
of the actions you can track in an audit log:
Zeke variables
Event definitions
Calendars
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
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.
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.
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.
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.
Initiator Processing
These generation options determine how Zeke uses initiators in your system:
Option
Description
ChkSEnv
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
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
DispSel
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.
Description
Note:
In this table, the term priority refers to the Zeke dispatching priority, not the operating system
job priority.
DefDPrty
Dispdly
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
300
Option
Description
Y
Prilate
Specifies whether to dispatch late events with a higher dispatch priority. These
are the valid values:
N
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
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.
Default. The SCHEDULE function drops from the schedule only the
completed events that match the selection parameters included with the
SCHEDULE ACTIVATE command.
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
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
Retpend
Indicates whether to retain an SQR until the event is completed. These are the
valid values:
Y
Default. Retain SQRs until they are completed (i.e., EOJ or disabled).
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
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.).
303
Option
Description
A
(blank)
Iefu83
Indicates whether to dynamically install the SMF IEFU83 exits to trigger events
when a newly created dataset is open and closed.
Note:
Because the Iefu83 option controls whether the Zeke IEFU83 SMF exit
ZEKE48G is loaded, changes to this option require a ZKILL COLD restart.
RemTrig
Specifies how to handle a remote trigger received for scheduled jobs with multiple
schedule dates if the remote trigger does not contain a schedule or run date.
If the remote trigger has a schedule and run date, 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.
These are the valid values:
304
ND
NT
If multiple dates exist, then do not trigger any date. If only one date
exists, trigger that date.
OD
TA
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
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
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
Specifies whether completed events can satisfy the WEOJ/WEOE (weak) WHEN
conditions of other events in the schedule. These are the valid values:
N
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
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
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.
Meaning
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.
307
Description
Aur
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
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:
308
Exit Options
Exit options are local and global generation options that control exits.
Follow the procedure in Editing a GENOPT on page 290 to access the local or
*GLOBAL GENOPT, then locate the exits options.
In ISPF, you can use the LOCATE EX command to locate the first exits option, or
issue CATEGORY ON to sort the display by categories and scroll to the Exits
section.
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.
Follow the procedure in Editing a GENOPT on page 290 to access the local or
*GLOBAL GENOPT, then locate the general options.
In ISPF, you can use the LOCATE GEN command to locate the first general
option, or issue CATEGORY ON to sort the display by categories and scroll to the
General section.
For other options, you might be required to specify a numeric or character value
(e.g., a name) or you can keep the default value.
4
Some general options can be reloaded using the ZRELOAD GENOPT operator
command. Others might require you to re-cycle Zeke using ZKILL TRACK or
COLD. See Reloading GENOPTS on page 295 for details.
The following sections discuss some important general options and also indicate the
additional related generation options that might be required to support a particular Zeke
environment or configuration.
Network Registration ID
The Netregid generation option specifies the unique DMS logical Netregid (network
registration ID) used to identify the local Zeke system.
Remote events dispatched by other Zeke systems to be monitored by this Zeke system
specify this Netregid in the remote 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.
310
Note:
For this option to effective, the ZPRDcom generation option also must be set to Y.
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
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).
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.
Follow the procedure in Editing a GENOPT on page 290 to access the local or
*GLOBAL GENOPT, then locate the JCL options.
In ISPF, you can use the LOCATE JCL command to locate the first JCL option,
or issue CATEGORY ON to sort the display by categories and scroll to the JCL
section.
312
For other options, you might be required to specify a numeric or character value
(e.g., a name) or you can keep the default value.
4
Some JCL options can be reloaded using the ZRELOAD GENOPT operator
command. Others might require you to re-cycle Zeke using ZKILL TRACK or
COLD. See Reloading GENOPTS on page 295 for details.
The following sections discuss some important JCL options and also indicate the
additional related generation options that might be required to support a particular Zeke
environment or configuration.
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
FairOpn
FairRec
LibrBlk
313
Library
Generation Options
LibrDtf
Bim-Edit
Condor
Panvalet
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
BimPasw
BimUid
Update these fields when you install Zeke, and again if you update Condor (you
also must link-edit the Zeke/Condor support program):
CondrVer
CondrLb
Library that Zeke will pass to Condor to receive JCL. The default
value is OMIT.
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
PanMem
Library
Generation Options
PDS
Pdsdd
VM/CMS JCL
Userid
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
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.
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
(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
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.
These are the valid values:
316
Option
Description
RepJUser
Default. (Never) Zeke does not insert/replace 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
(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.
Description
Posid
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)
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.
These are the valid values:
Y
Default. Zeke inserts //*ZEKECTL comment statements into the JCL when
submitting a job.
If the Posid generation option is set to Y, then the comment statements are
inserted in front of the ZEKECTL POSID job step.
The value of the Posidend generation option determines whether the
comment statements are inserted at the beginning or end of the JCL.
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.
Follow the procedure in Editing a GENOPT on page 290 to access the local or
*GLOBAL GENOPT, then locate the message options.
In ISPF, you can use the LOCATE MES command to locate the first message
option, or issue CATEGORY ON to sort the display by categories and scroll to the
Messages section.
319
Most message options can be reloaded using the ZRELOAD GENOPT operator
command. See Reloading GENOPTS on page 295 for details.
Scheduling Options
Scheduling options are global generation options that you can use to control Zeke event
scheduling.
Follow the procedure in Editing a GENOPT on page 290 to access the *GLOBAL
GENOPT, then locate the scheduling options.
In ISPF, you can use the LOCATE SCH command to locate the first scheduling
option, or issue CATEGORY ON to sort the display by categories and scroll to the
Scheduling section.
320
These tables discuss some of the most important options used to control Zeke dispatching
and also describe the additional related generation options that might be required to
support a particular scheduling environment or configuration:
Option
Description
DropSel
Indicates whether that you want the SCHEDULE function to drop all past, completed events when selection parameters are included with the SCEHDULE ACTIVATE command. Otherwise, only past, completed events that match the
selection parameters are dropped.
If the SCHEDULE function is run without any selection parameters, then the
DropSel option has no effect.
These are the valid values:
N
Default. The SCHEDULE function will drop from the schedule all past,
completed events regardless of whether they match the selection
parameters included with the SCHEDULE ACTIVATE command.
The SCHEDULE function will drop from the schedule only past,
completed events that match the selection parameters included with the
SCHEDULE ACTIVATE command.
MultGr
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
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.
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
Specifies how to handle a ZADD by jobname when multiple events have the
same name. These are the valid values:
A
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 event name when multiple events have the
same name. These are the valid values:
A
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 user ID when multiple events have the
same user ID. These are the valid values:
A
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.
Note:
The options MultAp, MultGr, MultJn, MultEn, and MultUs work together to determine which
jobs are added with the ZADD command. If multiple criteria are used on the same ZADD
command, then the option with the most restricted value is applied. For example, if a ZADD by
jobname and application ID is requested and MultJn is set to A (all) and MultAp is set to N
(i.e., none), then no events are added since the most restricted is none.
322
Option
Description
LoadComm
Indicates whether to load work centers to the schedule queue table (SQT)
storage.
ASG recommends that you activate this option if you use work centers that are
loaded into the schedule queue at schedule load time. This setting improves
response time when accessing the events through the work center function.
Additionally, work centers can be displayed in Schedule View and by using the
ZDISPLAY operator command.
These are the valid values:
N
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).
These are the valid values:
A
Default. Schedule the event after the nonworking day. For example, if
Monday is a holiday, all events scheduled for Monday are scheduled for
Tuesday.
323
Option
Description
Refevent
Caution! Event numbers are unique; however, because Zeke assigns the event
numbers automatically and can reassign available, previously used
numbers to new events, ASG recommends you reference other
events by event name to avoid unintended references.
These are the valid values:
A
Security Options
Security options are global generation options that manage security.
Follow the procedure in Editing a GENOPT on page 290 to access the *GLOBAL
GENOPT, then locate the security options.
In ISPF, you can use the LOCATE SEC command to locate the first security
option, or issue CATEGORY ON to sort the display by categories and scroll to the
Security section.
324
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.
Follow the procedure in Editing a GENOPT on page 290 to access the desired
local GENOPT, then locate the Traces options.
In ISPF, you can use the LOCATE TRA command to locate the first Traces
option, or issue CATEGORY ON to sort the display by categories and scroll to the
Traces section.
Traces options can be reloaded using the ZRELOAD GENOPT operator command.
See Reloading GENOPTS on page 295 for details.
Follow the procedure in Editing a GENOPT on page 290 to access the local or
*GLOBAL GENOPT, then locate the user interface options.
325
In ISPF, you can use the LOCATE USER command to locate the first user
interface option, or issue CATEGORY ON to sort the display by categories and
scroll to the User Interface section.
2
You can reload user interface options using the ZRELOAD GENOPT operator
command. See Reloading GENOPTS on page 295 for details.
Variables Options
Variables options are global generation options that activate variable substitution.
Follow the procedure in Editing a GENOPT on page 290 to access the *GLOBAL
GENOPT, then locate the variables options.
In ISPF, you can use the LOCATE VAR command to locate the first variables
option, or issue CATEGORY ON to sort the display by categories and scroll to the
Variables section.
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
command. See Reloading GENOPTS on page 295 for details.
Before setting the variables options, see Chapter 8, Variables, on page 345.
326
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 ===>
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 *******************************
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
327
Desired Result
Action
Description:
In the Description field, enter the description of the agent and press Enter.
Note:
Press F3 to save the information and to return to the Schedule Download Agents List
screen:
ASG-Zeke
Command ===>
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
Contact name
Operating system
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
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 ===>
Primary Commands:
BROWSE
BROWSE
EDIT
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:
Specify the new password in the next consecutive Pass field and press Enter.
Note:
Database Maintenance
Database maintenance includes these tasks:
ASG recommends you use the BACKUP command of the ZEKE utility program to
back up your database at least daily.
330
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.
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.
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
//ZFRMT
//ZALLOC
//ZNEW
//
//*
//ZUTL
//ZEKENEW
//ZEKECAT
//SYSIN
CREATE
/*
332
,MSGLEVEL=(1,1),CLASS=A
PGM=IEFBR14
DSN=ZEKE.DATABASE,DISP=(NEW,CATLG),
UNIT=SYSDA,VOL=SER=PERMVL,SPACE=(CYL,(10),,CONTIG)
EXEC
DD
DD
DD
ZEKEUTL,PARM=SUBSYS=ZDEV
DSN=ZEKE.DATABASE,DISP=OLD
DSN=ZEKE.DATABASE,DISP=OLD
*
For electronic vaulting, run the CREATE function using a jobstream similar to this
sample. See the ASG-Zeke Scheduling for z/OS Reference Guide for detailed
information on the CREATE function and parameters. This job creates both the
primary Zeke database and the Zeke vault database for electronic vaulting:
//ZALLOC
//ZNEW
//
//ZVAULT
//
//ZUTLP
//ZEKENEW
//ZEKECAT
//SYSIN
CREATE
/*
//ZUTLV
//ZEKENEW
//ZEKECAT
//SYSIN
CREATE
/*
JOB
EXEC
DD
EXEC
DD
DD
EXEC
DD
DD
DD *
EXEC
DD
DD
DD *
PGM=IEFBR14
DSN=ZEKE.PRIMARY.DATABASE,DISP=(NEW,CATLG),
UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG)
DSN=ZEKE.VAULT.DATABASE,DISP=(NEW,CATLG),
UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG)
ZEKEUTL,PARM=SUBSYS=ZDEV
DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR
ZEKEUTL,PARM=SUBSYS=ZDEV
DSN=ZEKE.VAULT.DATABASE,DISP=SHR
DSN=ZEKE.VAULT.DATABASE,DISP=SHR
Start Zeke with the ZEKECAT DD pointing to the primary database and the
ZEKEVLT DD pointing to the vault dataset.
Note:
Regardless of the value for the ESIActv generation option, an external security call
always is made to the SAF Security Interface using the resource class of Z$CATAL with
a resource name of CREATE## and ALTER authority. If this class information is not
defined in your security product, then the SAF action and return code are determined by
your security product. If you do not have a security product using SAF, then 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).
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.
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
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.
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.
Run a job to back up the Zeke database or use a previous backup. See the ASG-Zeke
Scheduling for z/OS Reference Guide for detailed information on the RESTORE
function and parameters.
This sample JCL illustrates backing up the database:
//ZEKEBKUP
//ZBK
//ZEKEBK
//
//
//
//SYSIN
BACKUP
/*
JOB
EXEC
DD
DD
,MSGLEVEL=(1,1),CLASS=A
ZEKEUTL,PARM=SUBSYS=ZDEV
DSN=ZEKE.BACKUP,
DISP=(NEW,KEEP),
VOL=(,RETAIN,SER=ZEKETP),
UNIT=TAPE,LABEL=(1,SL)
*
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.
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).
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
,MSGLEVEL=(1,1),CLASS=A
ZEKEUTL,PARM=SUBSYS=ZDEV
DSN=new database name,
DISP=(NEW,CATLG),UNIT=SYSDA,
VOL=SER=ZEKEVL,
SPACE=(CYL,(10),,CONTIG)
*
Note:
//ZEKEREST
JOB
,MSGLEVEL=(1,1),CLASS=A
//ZRS
EXEC
ZEKEUTL,PARM=SUBSYS=ZDEV
//ZEKECAT
DD
DISP=SHR,DSN=new enlarged database name
//ZEKENEW
DD
DISP=SHR,DSN=new enlarged database name
//ZEKERS
DD
DSN=last Zeke backup name,DISP=OLD,
//
VOL=SER=ZEKETP,UNIT=TAPE,LABEL=(1,SL)
//SYSIN
DD
*
RESTORE LOGICAL MESSAGE NEWCATLG
/*
Note:
The RESTORE function builds the Zeke database specified in the ZEKENEW DD
statement.
336
10
Edit the started task procedure and change the ZEKECAT DD statement to point to
the new database (if applicable).
11
If Zeke vaulting is being used, preallocate the vault database to be contiguous and
have the same attributes (e.g., size, cylinder boundary, device type) as the new
database. Copy (i.e., DITTO) the Zeke database to the Zeke vault dataset.
12
13
Start Zeke.
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.
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.
Terminate all active Zekes sharing the database (using the ZKILL COLD
command).
337
The first Zeke starts also initializes the new vault dataset from the primary database.
ASG strongly recommends that you perform the full recovery procedure the first time,
rather than the partial recovery.
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.
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
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.
During playback, Zeke will satisfy triggers and update the status for job activity that
occurred while Zeke was down.
Note:
340
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.
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)
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.
Remote triggers from jobs running on Zeke, but dispatched by a remote system,
are not sent back to the dispatcher until Zeke is restarted.
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.
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.
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.
If the REPORT parameter is specified, a report of all the discarded triggers is printed to
SYSPRINT:
Zeke SMF Triggers Discarded
NAME
ZEKE
ZEKEAG53
JCLPREP
SPTJX1A
QATST01
QAUTIL
STEPUSI
QATST01
QATST02
QAUTIL
STEPUSI
QATST02
JOBNAME
ZEKEAG53
ZEKEAG53
SPTJX1A
SPTJX1A
QATST01
QATST01
QATST01
QATST01
QATST02
QATST02
QATST02
QATST02
PROCSTEP
TRIGGER
EOS
EOJ
EOS
EOJ
BOJ
BOP
EOS
EOJ
BOJ
BOP
EOS
EOJ
TIME
SCHED DATE EVENT
16:53:42
16:53:42
16:53:43
16:54:08
16:54:00 2012/006 000001
16:54:01
16:54:11
16:54:11
16:54:01 2012/006 000002
16:54:01
16:54:11
16:54:11
VER
00000
00000
343
Applying Maintenance
When you issue ZKILL TRACK, all Zeke modules are unloaded so that maintenance can
be applied, except:
ZEKE48B
ZEKE48C
ZEKE48D
ZEKE48F
ZEKE48G
After maintenance is applied, terminate Zeke again using ZKILL COLD, then restart
Zeke to reload these modules.
If OASIS is terminated also, all OASIS modules are unloaded so that maintenance can be
applied.
SMF Playback
When Zeke restarts, it initiates playback. Activity within an individual job is played back
in the order it occurred. The order between different jobs is not preserved. Playback time
is compressed as much as possible so that Zeke can resume its normal dispatching. Job
accounting information, however, reflects the actual start time, end time, and duration of
the job run. After playback is complete, various messages are issued to indicate the
amount of activity and storage used during recording.
Z0140I GENOPT record A
successfully loaded
Z03B03I SYSGEN record ******** successfully loaded
Z0401I Zeke Variable Monitor initialized
Z0701I Zeke System startup successful 6.0 Z600A000
Z5G06I Schedule load task enabled
Z5G01I Initial schedule load started
Z0501I Zeke Schedule Monitor enabled
Z0510I Zeke ... Time is now 16:26:48
X00353I Program ZEKE48H installed as an IEFUJV
exit
Z5F02I Zeke Multi-System communications enabled
Z5H01I Zeke Remote Dependency task enabled
Z0901I Zeke Command Processor enabled
Z5I01I Zeke Agent Schedule Download Task Enabled
Z5G03I Schedule load complete
Z0502I Zeke Event dispatching enabled
Z45P1I Playback of SMF records has begun
Z45P6I
23 System triggers logged
Z45P7I
29 Kbytes ECSA used
Z45P8I
0 Kbytes used for filter tables
Z45P9I
13 Kbytes saved by filter tables
Z45PAI
11 triggers discarded by filter tables
Z45PBI
0 triggers discarded due to ECSA limit
Z45P5I Playback of SMF records is complete
344
Chapter 8:
Variables
8
Variables are user-defined keywords that represent values, and enable Zeke to carry out a
wide variety of specialized operations automatically. With variables, you can automate
many important tasks (e.g., JCL modifications, job triggering, and console response
handling).
This chapter discusses these topics:
Topic
Page
Zeke Variables
Naming Zeke Variables
Setting Zeke Variable Values
Maintaining Variable Documentation
346
346
346
351
OASIS Variables
Naming OASIS Variables
Setting OASIS Variable Values
Temporary OASIS Variables
355
357
357
358
System-dependent Variables
359
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
System-dependent variables
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.
346
8 Variables
You can establish or change Zeke variable values using any of these methods:
//S1
EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV
//SYSPRINT DD SYSOUT=*
//SYSIN
DD
*
SET VAR $ABC EQ 'ERROR'
SET VAR $XYZ EQ $XYZ + 1
/*
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on
defining variables using the SET VARIABLE function.
See the ASG-Zeke Scheduling for z/OS Reference Guide for more information on
using the ZSET operator command.
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
From the Zeke Primary Menu, enter 8 and press Enter. The Variable Selection
Criteria screen is displayed:
ASG-Zeke
Command ===>
BROWSE
DOCUMENT
EDIT
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)
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
348
8 Variables
Row 1 to 6 of 6
Scroll ===> PAGE
O - dOcument
Date
Time
System
01/30/2012 12:13:35 ZEQA
02/08/2012 14:53:44 ZEQA
02/07/2012 16:54:40 ZEQA
02/07/2012 16:54:48 ZEQA
02/07/2012 16:55:57 ZEQA
01/20/2012 15:16:32 ZEQA
******************************
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
349
EDIT
BROWSE
CANCEL
COPY
DELETE
Appl: PAYROLL
GroupID: CHK
Desc: STARTING CHECK NUMBER
Desc2:
DOCUMENT
EDIT
UserID: KAC
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
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).
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.
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 ===>
Row 1 to 6 of 6
Scroll ===> PAGE
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 ===>
Documentation Segments
EDIT
Group:
Appl:
SCRATCH
TEXT
NOTE
Scratch pad
Text information
Note pad information
This screen enables you to access the different types of documentation for Zeke
variables.
Note:
352
Enter one of these codes on the Command line to select the type of documentation
you want to access:
Desired Result
Action
8 Variables
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.
CANCEL
DELETE
ED
EDIT
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
Text Documentation
EDIT
Columns 000 000
Variable: $KATHYG1
System: ZEQA
User:
Grup:
****** *************************** Top of Data *****************************
==MSG> -Warning- The UNDO command is not available until you change
==MSG>
your edit profile using the command RECOVERY ON.
000001 IF YOU NEED TO UPDATE THIS VARIABLE MORE THAN 3 TIMES PER SHIFT, (NOT
000002 PER DAY), NOTIFY THE SHIFT SUPERVISOR. THE BASE VALUE WILL NEED TO BE
000003 RECONFIGURED BASED ON NUMBER OF OCCUPIED SEATS AND AVAILABLE LINES.
****** *************************** Bottom of Data **************************
354
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 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
EXEC
ITEM
LEFT
RIGHT
SUBSTR
SUBWORD
UPPER
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
Underscore (_)
At sign (@)
The remaining characters can be any of the above characters or numerics from
0 through 9. Imbedded blanks are not allowed in variable names.
OASIVAR Application Programming Interface (API) (see the ASG-OASIS for z/OS
Reference Guide for detail)
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.
Create and set the value of a temporary OASIS variable (which remains available
until your program terminates).
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
$$$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.
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 the ZEKEVAR API. This facility enables programs to make decisions that
can affect the dispatching of subsequent events.
Note:
360
8 Variables
//ARUPDT
JOB
,AR.DEPT,MSGLEVEL=(1,1),CLASS=X
//INIT
EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV
//SYSPRINT DD
SYSOUT=A
//SYSIN
DD
*
SET VAR $$$ARFLG EQ NO
<== Begin with variable=NO
/*
//ARSTP1
EXEC PGM=PROG1
<== Step 1
//INFILE
DD
DSN=AR.MASTER.TAPE,DISP=OLD,UNIT=TAPE,
//
VOL=SER=ARTAPE,LABEL=(1,SL)
//SYSPRINT DD
SYSOUT=A
//*
//ARSTP2
EXEC PGM=PROG2
<== Step 2
//OUTFILE
DD
DSN=AR,MASTER.TAPE,DISP=(NEW,KEEP),UNIT=TAPE,
//
VOL=SER=ARTAPE,LABEL=(1,SL)
//EXCPFILE DD
DSN=AR.EXCPS,DISP=(NEW,CATLG),UNIT=SYSDA,
//
SPACE=(132,(2000,500))
//SYSPRINT DD
SYSOUT=A
//ARSTP3
EXEC PGM=PROG3
<== Step 3
//RPTS
DD
DSN=&&AR.REPORTS,UNIT=SYSDA,DISP=(NEW,PASS),
//
SPACE=(132,(2000,500))
//SYSPRINT DD
SYSOUT=A
//*
//ARSTP4
//TAPEIN
//RPTSIN
EXEC
DD
DD
PGM=PROG4
<== Step 4
DSN=SOME.DATASET,DISP=OLD,UNIT=TAPE
DSN=&&AR.REPORTS,DISP=(OLD,DELETE),UNIT=SYSDA
//SYSPRINT
//*
//CHKEXCP
//SYSPRINT
//SYSIN
SET CODE 20
/*
//ARSTP5
//EXCPFILE
//SYSPRINT
//
DD
SYSOUT=A
EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV
DD
SYSOUT=A
DD
*
IF $$$ARFLG NE YES
<== Bypass Step 5 if variable=NO
EXEC
DD
DD
361
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.
//CL01P043
JOB
,MSGLEVEL=(1,1),RESTART=$CL01P043STEP
... JCL FOR STEP 1
/*
... JCL FOR STEP 2
/*
... JCL FOR STEP 3
Last normal step
//EOF
EXEC PGM=ZEKESET,PARM=SUBSYS=ZDEV
Normal end of job
//SYSPRINT
DD
//SYSIN
DD *
SET VAR $CL01P043STEP EQ *
For next job run
/*
//ABEND
EXEC PGM=ZEKESET,COND=ONLY
EXEC ONLY IF ABEND OCCURRED
//SYSPRINT
DD
//SYSIN
DD *
Only if job abends
SET VAR $CL01P043STEP EQ LASTSTEP
Set VAR to prior step
*
At this point, you can set a variable
*
to a value that dispatches a recovery job
/*
//
END OF JOB
The JOB statement contains an MVS restart parameter. This starts job processing at the
named step. Because the parameter is a Zeke variable, Zeke supplies the value through
the internal reader when the job is submitted.
362
8 Variables
If the job completes normally, ZEKESET sets the variable to asterisk (*); the operating
system starts the jobstream at the first job step the next time it runs.
The last job step specifies COND=ONLY on its execute statement. If the job completes
normally, the operating system bypasses this step. If an abend occurs, this statement sets
the variable to the name of the step which abended.
When this job is restarted by the ZREFRESH operator command, the first step executed
is the one that previously failed (the value of $CL01P043STEP). No external action is
necessary.
To restart at a step other than the one that abends, issue the ZSET command to set
$CL01P043STEP to the desired restart step name. For example, the above jobstream
abends in step CLSTP3, but the jobstream needs to be restarted at step CLSTP2. Enter
this command to begin processing at CLSTP2 the next time it runs:
ZSET VAR $CL01P043STEP EQ CLSTP2
The operating system does not execute the COND=ONLY step (even if the job did not
run properly) in any of these conditions:
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).
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
//$X $Y
//PR01P001 74
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
$X.ABC
PR01P001ABC
$X,
PR01P001,
word$Y
word74
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.
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
($).
366
8 Variables
The length of the command as it appears above is exactly 60 bytes. After variable
substitution is performed for $ABCVAR, the length of the line will exceed 60 characters.
In this case, the line must be modified to be 60 characters or less (including the value).
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.
This chapter discusses these topics:
Topic
Page
370
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
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).
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
Pool definitions
Operating passwords
External
Security
Functions
SCHEDULE function
ZEKESET commands
371
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
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
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 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
Console
Online
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 internal
security apply?
Call ESI
Internal security
verification
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.
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.
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
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):
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.
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.
9 Security
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
Description
Indicates the action for Zeke to take if batch security verification fails.
381
Option
Description
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
From the Zeke Primary Menu, enter option 6. The Security Control Functions
screen is displayed:
ASG-Zeke
Option ===>
1
2
3
X
382
Operators
Classes
ExtSec
Return
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
Primary Commands: ADD BROWSE COPY DELETE EDIT
Line Commands: E - Edit B - Browse C - Copy
Operator ID
Class
Date
Added
DVNEKG
A
08/30/2007
DVNEKG1
B
09/06/2007
OPERATOR
A
09/19/2006
SPTLRS1
B
06/18/2012
******************************* Bottom of
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 ********************************
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:
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 *******************************
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
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
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
Specify whether that you want to cancel a batch job when an unauthorized request is
encountered:
a
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.
386
9 Security
From the Zeke Primary Menu, enter option 6.2. The Directory of Command
Classes screen is displayed:
ASG-Zeke
Command ===>
Row 1 to 2 of 2
Scroll ===> PAGE
Class ID==>
Primary Commands: ADD BROWSE COPY DELETE EDIT
Line Commands: B - Browse C - Copy D - Delete
Class
Event
Zcom Cal
Opt
Work Sec
Doc
Var
E - Edit
Res
A
W
W
W
W
W
W
W
W
W
B
W
N
W
W
W
W
W
W
W
***************************** Bottom of data ******************************
Perform the steps in the Action column (depending on the desired result).
Desired Result
Action
Copy a class ID
387
Class Detail
EDIT
Class Id: A
Primary Commands: ADD
Allowed functions
Event
- W
Zcom
- W
Calendar - W
Options - W
Restart - W
Schedule
ZADD
ZALTER
ZDELETE
ZDISABLE
ZDISPLAY
ZENABLE
ZHOLD
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)
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
(READ only) Zeke allows an operator assigned to this class to browse records
in this online function. Not valid for the work center function.
(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
9 Security
Code
Meaning
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
From the Zeke Primary Menu, enter option 6.1. The Directory of Operator IDs
screen is displayed:
ASG-Zeke
Command ===>
Row 1 to 1 of 1
Scroll ===> PAGE
Operator ID:
Primary Commands: ADD BROWSE COPY DELETE EDIT
Line Commands: E - Edit B - Browse C - Copy
Operator ID
D - Delete
Class
Date
Date Last
Added
Updated
OPERATOR
A
01/16/2012
01/30/2012
L003J
A
01/24/2012
02/04/2012
****************************** Bottom of data *****************************
389
Perform the steps in the Action column (depending on the desired result):
Desired Result
Action
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
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:
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.
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
393
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
Zeke command
VM command
VSE/POWER command
Command text
Function
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
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
GENERICS
ACTIVATE
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
READ
Resource names:
CREATE
BACKUP
RESTORE
STATUS
BLOCK
CLEARCPU
Z$CLASS
ALTER
(enables CREATE, RESTORE,
and BLOCK functions)
READ/UPDATE/ALTER
READ
READ/UPDATE/ALTER
READ/UPDATE/ALTER
395
Class
Description
Authority Levels
Z$EMR
READ/UPDATE/ALTER
READ/UPDATE/ALTER
READ/UPDATE/ALTER
READ
Note:
Options to which you do not have access are not displayed on
the Zeke Primary Menu.
UPDATE
READ/UPDATE/ALTER
READ/UPDATE/ALTER
READ/UPDATE/ALTER
READ/UPDATE/ALTER
396
READ/UPDATE/ALTER
9 Security
Class
Description
Authority Levels
Z$SCHED
READ
ALTER
READ
n/a
READ/UPDATE/ALTER
READ/UPDATE/ALTER
397
398
9 Security
From the Zeke Primary Menu, enter option 6.3. The ESI Customization screen
displays the X1SELECT page:
ESI Customization
BROWSE
SCROLL ===> PAGE X1SELECT
COMMAND ===>
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
Action
399
Desired Result
Action
Note:
You cannot delete class records for the default system (********).
Change the process option
for a security class
Note:
If you change the external class name or resource name
format, keep the process option set to N4 until you have
tested the implementation.
1 Enter EDIT on the Command line, and press Enter.
2 Specify the process option in the Process Option field for
the class to change. These are the valid process options:
400
N0
N4
N8
Y0
Y4
Y8
9 Security
Desired Result
Action
3 Press Enter.
Go to step 6.
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
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
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
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
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:
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 *******************************
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
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.
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 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.
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
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
407
408
409
409
409
412
418
423
424
407
where:
your.mainframehost is the host name or IP address for Zeke Web services.
nnnn is the port number for Zeke services.
Note:
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
In the server root path, create an index.html document with these contents:
</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.
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
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
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
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).
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).
412
Start the Web interface as described in Accessing Zeke Web Services on page 408.
From the Zeke Web Services home page, click View Maintenance.
Description
Type
Name
Description
Level
Access level for the view. These are the valid levels:
Personal
Shared
System
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.
Description
Status
Display only the work centers with the specified status. Select one of
these statuses from the drop-down list:
Event
All
Not Done
Pending
Done
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.
Description
View Name
Description
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
Start the Web interface as described in Accessing Zeke Web Services on page 408.
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.
Description
Status
Display only the work centers with the specified status. Select one of
these statuses from the drop-down list:
Event
All
Not Done
Pending
Done
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.
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
Start the Web interface as described in Accessing Zeke Web Services on page 408.
From the Zeke Web Services home page, click View Maintenance.
The All Views list appears.
Click Delete to delete the view and return to the All Views list.
Manually verifying and indicating that the work centers required conditions or
actions have been met.
418
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.
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
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.
420
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.
Locate the work center for which you want to view documentation.
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
421
From this screen, you can view the documentation or you can complete,
enable/disable, or refresh the work center.
Or
Setting a Variable
Successfully completing a work center could include requiring the operator to set a
variable value.
To set a variable
422
Click Submit.
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.
Optional. Select a view from the Views drop-down list to narrow down the list of
work centers.
Locate the work center that you want to disable and right-click for a context-menu.
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.
Optional. Select a view from the Views drop-down list to narrow down the list of
work centers.
423
Locate the disabled work center that you want to enable and right-click for a
context-menu.
The work center is enabled and its status is changed to Not Done.
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.
Click Refresh.
Or
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:
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.
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
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.)
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
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).
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.
//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
destination
username
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
-l
-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
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.
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:
Comment statements are inserted after the job statements, except in these cases:
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.
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
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
* CAL
character
* CATID
character
CLASSES
character
CPU
numeric time
mmmmmm:ss
APPL
0:12
* DISPID
character
* DISPSYS
character
DPRTY
numeric
DRL
numeric
DUR
numeric time
mmmmmm:ss
* EVT
EVTNAME
* EVTSYS
GRP
numeric
character
character
character
433
Name
Format
Description
JCLOVRD
logic
LATESTART
numeric time
hh:mm
Events late start time from the SQR. The possible values
are from 00:00 through 48:00.
MANUAL
logic
MILESTONE
logic
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
434
Name
Format
Description
$ZEKE_MUSTSTART_LATE_BY
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
RESTART
logic
SCHED
numeric time
hh:mm
* SDATE
numeric date
yyyy/ddd
435
Name
Format
Description
* SUBSYS
character
USERID
character
VER
numeric
$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
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
generation options 309
exporting database records 20
extended dependencies, see under
dependencies
external security
see security
Index
F
Fastpath, managing Zack Fastpath/Autoreply
tables from Zeke 36
forecasting the schedule 15
G
general
generation options 309
generation options
accessing 281
audit 296
AUR 308
AURINTV 308
AURMSG 308
Calctap 308
COMMCTL 301
DEFDPRTY 300
Defopid 386, 405
DISPDLY 300
DISPSEL 308
DSPIndex 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
generation options 381
see security
inter-product communication,
controlling 310
ISPF menu screens
event record directory 59
ISPF online facility
changing colors on screens 36
commands 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
generation options 312
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
Index
defining 121
grouping multiple phrases 108
list of keywords 107
multiple phrases 107
processing 107
sample clauses 115
scheduling for holidays and
weekends 118
using parentheses in 108
logon
ISPF online 33
M
menus
OASIS Primary Menu 35
Zeke Primary Menu 36
messages
dispatching 300
display system 197
generation options 319
MSG job 86
multiple
Zeke versions 2
MVS User ID 378
N
NETREGID 133
Network Hold status 210
NOTDURING processing
reason code 210
using logical resources 271
WHEN conditions 127, 134, 197
O
OASIS
started task 29
starting the 331
starting
multiple tasks 29
without Zeke 27
subsystem requirements 2
terminating 30
variables
accessing 32
in SET clauses 150
naming 357
overriding variable values
temporarily 358
overview 355
setting with XVAR and
?XVAR 150
temporary variables 358
OASIS Primary Menu 35
OCCURS clauses
online
see also ISPF online facility
operator commands 13, 69, 73, 76, 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
in Schedule View 196
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
35
36
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
CD Contents