zeke

ASG-Zeke™ for z/OSUser’s Guide

Version 5.4Publication Number: AZM0200-54

Publication Date: March 2007

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 © 2007 Allen Systems Group, Inc. All rights reserved.All names and products contained herein are the trademarks or registered trademarks of their respective holders.

ASG Worldwide Headquarters Naples Florida USA | asg.com | [email protected] Third Avenue South, Naples, Florida 34102 USA Tel: 239.435.2200 Fax: 239.263.3692 Toll Free: 800.932.5536 (USA only)

i

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .ixAbout this Publication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Related Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . x

Publication Conventions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Worldwide Customer Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xiiIntelligent Support Portal (ISP). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

ASG Documentation/Product Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .xiii

Chapter 1: Introducing Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1What is Zeke? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Zeke Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Zeke Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Processing Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6SMP/E Install Tapes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Online Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6Calendars. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7JCL Sources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9User JCL Exit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Dispatching Dependencies (WHEN conditions). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Resource Checking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Condition Code Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Copying JCL and Documentation into the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . 12Import/Export . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Work Center Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Operator Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13Forecasting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Schedule Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14PolyZeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Continuous Tracking. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14Electronic Vaulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

ASG-Zeke for z/OS User’s Guide

ii

Audit Trail Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15Report Writer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

How Zeke Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Schedule Time. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17Logical Day. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18PolyZeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

Zeke Interfaces to Other ASG Products . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21ASG-OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21ASG-Zeke Agents—Cross-Platform Schedule Download . . . . . . . . . . . . . . . . . . . . . . . 22ASG-Zeke Plug-ins for ASG-OpsCentral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22ASG-Zara—Automated Tape Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22ASG-Zebb—Restart/Recovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22ASG-Zena—Cross-Platform Job Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ASG-IMPACT—Problem Tracking Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ASG-Cortex-Pdb Plug to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23ASG-JCLPREP—JCL Validation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24ASG-JOB/SCAN—JCL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24ASG-PRO/JCL—JCL Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24ASG-Workload Analyzer—Job Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25ASG-Workload Planner—Job Planning When Scheduling . . . . . . . . . . . . . . . . . . . . . . 25

Zeke Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Version 5.3.1 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26Version 5.3.0 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33Version 5.2.0 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Version 5.1.0 Enhancements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Chapter 2: Starting Zeke and Using theOnline Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49Starting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Restarting Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Starting OASIS Only . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

Starting Multiple Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Terminating OASIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

Terminating Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

ISPF Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57ISPF Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57General Screen Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58Logging On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

Contents

iii

Chapter 3: Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63Calendar Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Accessing the Calendar Facility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Standard Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

Special Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

User Accounting Calendars . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

Calendar Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Maintaining Scratch Pad or Note Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Chapter 4: Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75Defining Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Event Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77Primary Commands. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78Accessing the Event Master Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Defining an Event Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86Creating an Event From a Template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88Copying an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90Maintaining a Job Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92Routing a Job Event to Another System or Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Downloading Jobs to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102Maintaining a Message Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104Maintaining Command Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107Maintaining a REXX Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Defining a Recurring or Permanent Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114

OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118OCCURS Clause Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118Sample OCCURS Clauses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126Scheduling Events on Holidays and Weekends . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130Defining an OCCURS Clause. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Job and Program WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135WHEN Conditions for Multiple Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135Extended Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136WEAK Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137Started Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Generic Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138Multiple WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139Zeke Variables as WHEN Conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140NOTDURING Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142Cross-platform Dependencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144WHEN Condition Keywords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145


iv

Defining a WHEN Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150Viewing WHEN Conditions for All Event Versions . . . . . . . . . . . . . . . . . . . . . . . . . . 151

Condition Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Variables in Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161Setting Up Work Centers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163Completing Work Centers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

Auto Replies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171Maintaining Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172Displaying, Enabling, or Disabling Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

Maintaining JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Setting JCL Source Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176Retrieving JCL from the Zeke Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179

Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Accessing Event Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181Maintaining Scratch Pad or Note Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184Maintaining Text Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185Maintaining Dataset Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186

Event Activity Accounting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

Chapter 5: Creating and Monitoring the Schedule . . . . . . . . . . . . . . . . . . . . . . . . 191Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Logical Day (48-hour Clock) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192Creating the Zeke Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194Setting Zeke to Schedule Itself . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196Adding Events to the Schedule As They Are Created . . . . . . . . . . . . . . . . . . . . . . . . . 197Schedules Downloaded to Zeke Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197How Zeke Determines Dispatching Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198Forecasting and Simulating the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199

Using Schedule View. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202Schedule View Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211Accessing Other Online Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217Refreshing the Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219Sorting Schedule View Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220Selecting Fields to Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222Changing the Date Display Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224Viewing and Maintaining WHEN Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225Displaying Event Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 227Accessing Resources for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229Using the ZOOM Feature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230

Maintaining JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232Zeke PDS JCL Override . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234

Contents

v

Validating JCL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236Invoking ASG-JCLPREP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237Invoking JOB/SCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239Using ZSCAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241

Creating Your Own Line Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242

ZCOM Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243

PathFinder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244

Manually Adding Events to the Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Using the ZADD Operator Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250Using the ADD Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252Adding Events By Path . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255

Chapter 6: Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 261Resource Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262

Physical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 262How Initiator Processing Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263Activating Initiator Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 267Defining Initiators to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269Defining Pools to Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272

Maintaining Logical Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274Defining a Logical Resource. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275Maintaining Resources for an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 277Deleting Resources for an Event. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281

Chapter 7: Maintaining Zeke . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283Changing Zeke Operating Criteria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284

Accessing Generation Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286Activating Variable Substitution. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Dispatching Messages and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288Recognizing NOT-CAT2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 290Retaining Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291Triggering Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293Scheduling Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 297Pending Messages and Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 300Defining Schedule Download Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 301Setting Auto Replies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303Loading the Work Center to SQT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 304Calculating Tape Drive Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305Checking the Dispatch Queue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Maintaining the Job Restart Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 306Maintaining Networking Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 307Maintaining Inter-product Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 309


vi

Using Shared Databases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311Dispatching Events After Zeke Start-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Building EDB Indexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312Obtaining Operating Passwords . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314Changing ISPF Color Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316

Using the Audit Facility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 318

Database Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Creating the Zeke Databases (Primary and Vault) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 320Backing Up the Zeke Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323Restoring the Zeke Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324Moving the Vault Database. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 326Recovery Using Electronic Vaulting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 328

Continuous Job Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331Terminating Zeke Using ZKILL TRACK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 331SMF Recording Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 332Applying Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335SMF Playback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335

Chapter 8: Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 337Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Naming Zeke Variables. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Setting Zeke Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 338Maintaining Variable Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 343

OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 347Naming OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 348Setting OASIS Variable Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 349Temporary OASIS Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 350

System-Dependent Variables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351

How Variables Are Used . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 351Using Variables to Trigger Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 352Using Variables to Control Jobstream Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 353Using Variables to Restart a Job . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354Substituting Variable Values in JCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 356IF Clauses On SET Statements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359Variable Substitution in SCOM Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 359

Chapter 9: Security. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 361Preparing for Implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 362

Objects and Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363

Security Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364Security Calls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365Processing Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 367

Contents

vii

Tracing Processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 368

Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 369Online Access: Logging On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Function Access: Class Record. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 370Record Access: Operator Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Batch Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 371Setting Up Internal Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 372

Zeke External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 382Security Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 383Resource Names . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 386Implementing External Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 387

Index. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395


viii

ix

Preface

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

About this PublicationThis publication consists of these chapters:

• Chapter 1, “Introducing Zeke,” introduces you to the basic concepts of using Zeke.

• Chapter 2, “Starting Zeke and Using the Online Facility,” explains how to start and log on to Zeke.

• Chapter 3, “Calendars,” describes the various types of calendars and how to use them.

• Chapter 4, “Events,” explains the components of an event master record (EMR) and how to create and modify them.

• Chapter 5, “Creating and Monitoring the Schedule,” provides sample JCL for creating the daily schedule and explains how to monitor the schedule with Schedule View or using the /ZCOM function, and intervene, if necessary.

• Chapter 6, “Resources,” explains the differences between physical and logical resources and how to use both for more efficient job processing.

• Chapter 7, “Maintaining Zeke,” explains how to create and maintain the Zeke database, as well as providing procedures for the most commonly changed generation options.

• Chapter 8, “Variables,” describes the different types of variables and provides examples.

• Chapter 9, “Security,” provides conceptual and procedural information for both internal and external security.


x

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

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

• ASG-Zeke for z/OS User’s Guide (AZM0200-nn) explains the procedures for using Zeke to schedule your enterprise.

• ASG-Zeke for z/OS Installation Guide (AZM0300-nn) defines Zeke system requirements, provides instructions for installing Zeke, and explains the optional features you can activate after installing.

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

• ASG-Zeke Messages and Codes Guide (AZM1200-nn) lists the Zeke messages, describes their meanings, causes, and resolutions, and provides return code explanations.

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

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

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

Preface

xi

Publication ConventionsASG uses these conventions in technical publications:

Convention Usage

Arrow ( ) Used in a procedure to indicate commands within menus.

Also used to denote a one-step procedure.

Bold Indicates that case-sensitive usage is required for a directory, path, file, dataset, member, database, program, command, or parameter name.

Verify the settings in the asg.conf file.

Capitalization For system element names, this varies according to the product interface and its operating environment.

Mainframe file names use uppercase, for example:

Allocate a JSOPTEM member in the JLRCL library.

Windows file names use mixed case, for example:

Create a text file named SECLIST.txt in the C:\Program Files\ASG\config directory.

UNIX file names use mixed case, for example:

Edit the databaseID.ACC file in the /database directory.

Typical product and operating system elements include:

• Directory, path, file, dataset, member, database, program, command, and parameter names.

• Window, field, field group, check box, button, panel (or screen), and option labels.

• Names of keys. A plus sign (+) is inserted for key combinations (e.g., Alt+Tab).

lowercase italic monospace

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

Monospace Characters you must type exactly as they are shown, such as code, JCL, file listings, or command/statement syntax.

Also used for denoting brief examples in a paragraph.

Underline Denotes a cursor-selectable field or line.

Vertical separator bar ( | ) with underline

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


xii

Worldwide Customer SupportASG provides support throughout the world to resolve questions or problems regarding installation, operation, or use of our products. ASG provides all levels of support during normal business hours and emergency support during non-business hours.

You can access support information at http://www.asg.com/support/support.asp.

ASG Third-party Support. ASG provides software products that run in a number of third-party vendor environments. Support for all non-ASG products is the responsibility of the respective vendor. In the event a vendor discontinues support for a hardware and/or software product, ASG cannot be held responsible for problems arising from the use of that unsupported version.

Intelligent Support Portal (ISP)The ASG Intelligent Support Portal (ISP) provides online support at http://isp.asg.com.

Log on to the ISP with this information:

Customer ID = NNNNNNNNNPassword = XXXXXXXXXX

where:

NNNNNNNNN is your customer ID supplied by ASG Product Distribution.XXXXXXXXXX is your unique password supplied by ASG Product Distribution.

If you do not have your logon information, contact your local support center.

The ASG-Intelligent Support Portal User's Guide provides instructions on how to use the ISP and is located on the ASG Support Web page.

Severity MeaningExpected Support Response Time

1 Production down, critical situation Within 30 minutes

2 Major component of product disabled Within 2 hours

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

Within 4 hours

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

http://www.asg.com/support/support.asp

http://isp.asg.com

Preface

xiii

ASG Documentation/Product EnhancementsSubmit all product and documentation suggestions to ASG’s product management team at http://www.asg.com/asp/emailproductsuggestions.asp.

Include your name, company, work phone, e-mail ID, and the name of the ASG product you are using. For documentation suggestions, include the publication number located on the publication’s front cover.

http://www.asg.com/asp/emailproductsuggestions.asp


xiv

1

1Chapter 1:Introducing Zeke

This chapter provides an overview of Zeke and contains these topics:

Topic Page

What is Zeke? 3

Zeke Terminology 3

Zeke Features 6Processing Ability 6SMP/E Install Tapes 6Online Facility 6Calendars 7Events 7JCL Sources 9User JCL Exit 9Dispatching Dependencies (WHEN conditions) 10Resource Checking 10Pools 11Variables 11Condition Code Validation 12Auto Replies 12Copying JCL and Documentation into the Zeke Database 12Import/Export 13Work Center Facility 13Operator Commands 13Forecasting 14Schedule Simulation 14PolyZeke 14Continuous Tracking 14Electronic Vaulting 15Audit Trail Facility 15Report Writer 16

How Zeke Works 17Schedule Time 17Logical Day 18PolyZeke 18


2

Zeke Interfaces to Other ASG Products 21ASG-OASIS 21ASG-Zeke Agents—Cross-Platform Schedule Download 22ASG-Zeke Plug-ins for ASG-OpsCentral 22ASG-Zara—Automated Tape Management 22ASG-Zebb—Restart/Recovery 22ASG-Zena—Cross-Platform Job Dependencies 23ASG-IMPACT—Problem Tracking Support 23ASG-Cortex-Pdb Plug to Zeke 23ASG-JCLPREP—JCL Validation 24ASG-JOB/SCAN—JCL Validation 24ASG-PRO/JCL—JCL Validation 24ASG-Workload Analyzer—Job Analysis 25ASG-Workload Planner—Job Planning When Scheduling 25

Zeke Enhancements 26Version 5.3.1 Enhancements 26Version 5.3.0 Enhancements 33Version 5.2.0 Enhancements 35Version 5.1.0 Enhancements 39

Topic Page

1 Introducing Zeke

3

What is Zeke?Zeke is an automated scheduling product that controls events on one or more computers. An event can be a computer process or action, or an off-line, manual task. More specifically, a Zeke event can be any of the following:

• A jobstream processed by the operating system

• A message issued to the console operator

• A Zeke operator or batch command

• A VM control program (CP) command

• A communication event that issues commands to the operating system and replies to queries generated by those commands

• A manual task, called a work center

For job events, Zeke reads and interprets event definitions, schedules the jobs for processing, initiates and terminates the processing of the jobs and job steps, plus records the output data. For work centers, Zeke schedules the completion of the manual tasks and enables them to interface with tasks performed on the computer.

Zeke TerminologyTo help you understand Zeke concepts, an overview of basic scheduling terminology, as well as Zeke-specific terminology is provided (in alphabetical order).

Auto Reply. Allows you to automatically respond to outstanding replies (WTORs) from your Zeke events that have static or predictable responses, or for job events that need to be maintained.

Calendar. Calendars provide a way for you to customize your processing schedule. You simply set up one or two standard calendars to distinguish among workdays, weekends, and holidays. One standard calendar is all you need for most events. However, you can also create user accounting calendars to tie events to the periods of your accounting year and special calendars for those few events with random scheduling criteria.

Condition Code Validation. Zeke can determine if a job should be cancelled or marked as abended based on condition codes (or return codes). The condition code can be set at the job or step level and is defined for an event through the online facility.

Documentation Segment. This feature allows you to select the type of documentation you want to maintain by entering the appropriate criteria from a list of options to display one of the following types of documentation: scratch, note, dataset, or text.


4

Electronic Vaulting. Electronic vaulting provides the ability to maintain a second copy of the Zeke database that will be at most one I/O behind the primary. By maintaining a second copy on another DASD string, or even another site, an installation can improve recovery time if a hardware error occurs.

Event. An event is a computer process, such as a jobstream, a command, or message. An event can also be an off-line task, called a work center, that once completed will trigger other system-related events.

Event Master Record (EMR). When you define events to the Zeke database, an event master record (EMR) is created that contains certain information, such as the date the event is to be scheduled, prerequisite conditions for dispatch, and resource requirements. Zeke uses these records to create the daily schedule.

Logical Day. A logical day associates events that run in the early morning hours with the previous day’s schedule. This allows events that belong to a given day to be associated with that day, even though their schedule time actually lies outside the 24 hours of the given day.

Logical Resource. Logical resources can be anything you want to define to represent the use of a physical resource such as the entire CPU, a specific CPU channel, a file, or a dataset. Logical resources are used for events, that if executed simultaneously, might cause contention among your systems resources.

OCCURS Clause. An OCCURS clause is a statement that determines when the event should be added to the schedule. It is comprised of keywords, such as DAILY, WORKDAYS, MONDAY, JANUARY, WEEKENDS, and HOLIDAY that indicate when to schedule events.

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. Additionally, PathFinder can help you uncover predecessor loop conditions.

Schedule Queue Record (SQR). When the SCHEDULE function creates the daily schedule, it uses the EMR information to create temporary records for each scheduled event. These records, called schedule queue records (SQRs), can be modified for that particular run, without affecting the permanent EMR.

Schedule View. Schedule View, available only through ISPF, displays all the events currently scheduled. Schedule View presents all relevant schedule information on a single screen. And from this one screen, you can monitor the current schedule, and make changes to any of the fields.

1 Introducing Zeke

5

Additionally, all messages from a job’s JOBMSG and SYSMSG files can be displayed to aid in problem resolution and speed the restart process. Schedule View also allows access to JCL for one-time overrides. This allows authorized users access to a copy of the executable JCL to update parameters and correct abends. The updated copy is then attached to the event’s schedule entry for subsequent runs.

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.

Security. Zeke offers two approaches to security: internal security—Zeke’s own facility for securing access to Zeke records and functions; and external security – which interfaces to any security package that supports SAF (System Authorization Facility). You can also use a combination of internal and external security to provide optimum protection.

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, such as specifying tape drive and initiator quantities, reporting, and message generation, all without affecting the actual schedule.

System Pooling. Multiple CPUs (real and virtual) can share one Zeke database. Every 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 which system to use for each event based on the system or pool defined for the event.

Variable. A Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned value of either numeric or character format. Variables allow Zeke to automatically carry out a variety of specialized operations, such as automating JCL modifications, triggering event scheduling and dispatching, and responding to console data.

Version. This term refers to multiple SQRs with the same schedule date. An event can have up to 32,767 versions. Each version of an event shares the same OCCURS clause, but can have a different WHEN condition defined for it. Most Zeke operator commands can select events by version number for processing, and WHEN conditions can trigger off of version numbers.

WHEN Condition. A WHEN condition is a statement that contains prerequisites that must occur before the event can be dispatched. Similar to OCCURS clauses, WHEN conditions use keywords, such as EOJ, that indicate when to dispatch events.

Work Center. Work centers are useful when manual intervention is required before a job can run. Work centers allow you to communicate directly with the schedule. Users can add, alter, and control events without filling out a form, making a phone call, or writing a note to an operator.


6

Zeke FeaturesThis section provides an overview of some of Zeke’s key features.

Processing AbilityZeke can schedule up to 24 computer systems from each Zeke database. Any combination of VSE, CMS, and z/OS systems can share a database. This multi-system support enables multiple operating systems to communicate about events occurring on one system that might affect the events on another system.

Zeke can schedule system commands (SCOMs) as well as jobs. System commands include Zeke commands and VM (CP) commands. SCOM events can awaken CICS and issue CICS commands.

As part of the communications system, machines sharing a Zeke database register at start-up and check out at termination. Machines that are stopped are forced off of the machine bit mask. When the machine becomes active again, recovery is automatic. A CPU ID (bit mask) is assigned to each machine during the registration and check out process.

The number of active communications records depends on the volume being passed between multiple machines.

SMP/E Install TapesSites can install Zeke using the SMP/E or non-SMP/E procedures, and maintenance is provided in both formats.

Online FacilityThe Zeke online facility is a full-screen, menu-driven system that makes scheduling maintenance easy. The Zeke online facility runs under several environments:

• CICS

• IDMS

• CMS

• TSO

• ROSCOE

• ISPF

1 Introducing Zeke

7

The Zeke online facility contains complete security, allowing only authorized users to access the scheduling database. Additionally, it allows definition of different levels of access for each authorized operator.

CalendarsAn event can be scheduled by any of the following calendars:

You can specify generic years on all calendars. For example, 07/04/**** means July 4th of any year.

Events

Event TemplatesThis feature allows you to set up model events to use when creating new events of the same type (such as job events). When you create an event from a template, all of the template’s information is copied over to the new event—including documentation, JCL, OCCURS clause, and WHEN conditions. A template is basically a normal event, except that it can never be scheduled.

Multiple Schedule Queue Records (Versions)Allows you to have multiple SQRs (versions) with the same schedule date. An event can have up to 32,767 versions. Each version of an event shares the same OCCURS clause, but can have a different WHEN condition defined for it. Most Zeke operator commands can select events by version number for processing, and WHEN conditions can trigger off of version numbers.

You can also create a new event by copying an existing one; however, you have to know the event number. Templates simplify this function. All you need to know is a template name.

There is no limit to the number of templates that can be defined for each event type.

Calendar Type Description

Standard Used for defining workdays, non-workdays, and holidays.

Special Used for specifically identifying the schedule dates for an event.

User Accounting Used for defining a calendar that matches your accounting periods.


8

Recurring, Permanent, and Milestone EventsAn event can be defined to occur multiple times within the same schedule run. These events are referred to as recurring events. You define the frequency or time interval and the specified number of times. A recurring event can trigger another event each time it runs, or it can be set to trigger only on the first or last occurrence.

A permanent event is never removed from the schedule so that it is always available to respond to triggers, even during schedule load processing. The event occurs across every schedule period until you deactivate it.

A milestone event is a significant event in a job flow (in which events have predecessor/successor relationships) that must process on time in order to avoid a significant delay in the completion of the entire flow. Events flagged as milestones are not processed any differently than other events; this flag is simply a way to easily identify events that you consider to be milestones in a job flow. (For example, in OpsCentral you can filter events based on this designation.)

Non-executable EventsAn event can be defined as non-executable. Non-executable events are scheduled like any other event, and are useful as predecessors to other events. A non-executable event is never submitted to JES for JCL execution. After dispatch, the event status automatically changes to indicate success and any dependent events are triggered.

An event that is part of an intricate event flow can be marked as non-executable (in the EMR, from Schedule View, or using an operator command) without having to change the event flow. This eliminates the need for deleting an event and changing all of its successors WHEN clauses.

Routing Job Events to Other PlatformsUsing the EMR fields Platform and Target, Zeke can dispatch job events for processing across systems and on other platforms.

Event DocumentationZeke provides for full documentation of an event through the following facilities:

• Text facility, which retains a sizeable amount of text (up to approximately 450 records)

• Scratch pad and note facilities, which provide an easy method for leaving short notes for the operations personnel about a job

• Dataset facility, which displays the volume serial numbers and datasets required to run a job

1 Introducing Zeke

9

On-Demand, On-Request EventsRequested events can be defined as events in the Zeke database and added by operator command to the schedule. Zeke dispatches these events as if they were normally scheduled, including checking of prerequisites and resource requirements.

JCL SourcesZeke can retrieve JCL from any of the following sources:

• Bim-Edit

• Librarian

• Condor

• Panvalet

• VM/CMS File

• Zeke JCL

• CA-Driver

• JCLMAN

• Vollie

• VSE/POWER SLI

• ICCF

• OWL

User JCL ExitZeke provides a user JCL exit that can add, review, modify, or delete JCL statements at submission time. The user exit can also place a hold on the job event.


10

Dispatching Dependencies (WHEN conditions)Zeke can make dispatching of an event contingent upon any combination of the following circumstances:

• Normal or abnormal end for:

— A job

— A job step

— A program

— An event

— A group of events

• Beginning of a job or program

• Close of an output non-VSAM dataset, if DISP=NEW

• Current execution of a job or program

• Availability of variables or resources

Zeke’s cross-system triggering ability allows Zeke to satisfy WHEN conditions based on a job running on another system (mainframe or non-mainframe).

Extended DependenciesTwo WHEN conditions, XEOJ and XEOE, provide the ability to trigger jobs across multiple schedules. For example, say JOB_A is dependent on JOB_B, which ran a few weeks ago. The XEOJ keyword can be used to locate the JOB_B in the Zeke database and determine whether it has run since the last time JOB_A ran.

Resource CheckingZeke checks resource availability before an event is dispatched. Physical resources, such as number of tape drives and initiator class, are defined as part of the EMR. Logical resources are user-defined in the Zeke database.

Zeke allows you to specify the days and times each initiator is available for processing.

Up to six initiator classes can be defined for each job event. Zeke dispatches a job event to an initiator that processes one of the named classes. If a class is not specified, Zeke selects an appropriate class for the job at dispatch time.

As part of the resource requirement checking, Zeke ensures that there are the correct number of tape drives available before dispatching a job. Zeke also compares resource names across systems to prevent multiple events from using the same resource.

1 Introducing Zeke

11

PoolsZeke can select the system a job will run on, in addition to selecting the initiator within that system. Pools allow the user to establish groups of systems. For example, pool 1 may include systems A, B, and F. An event defined to run on system 1 (rather than system A, B, or F) is dispatched by Zeke on the first available system within the pool. This prevents one system from being idle while another may be overloaded with jobs.

Variables

Zeke VariablesZeke provides powerful tools, variables, which perform the following functions:

• Controlling jobstream flows (bypassing segments)

• Triggering other events

• Preventing other events from occurring

• Documenting cancellation reasons

• Substituting values in OS and JES JCL statements at execution time

Variables establish relationships between events. For example, when a work center is signed off as complete, it sets a variable telling Zeke that certain jobs can be run.

Variable substitution is performed on all jobstream statements submitted by Zeke, including JCL and data statements. When a jobstream is submitted, Zeke scans it for variables and substitutes the current values.

Variable substitution also occurs in WHEN conditions during batch schedule build and during ZADD processing.

For example,

WHEN EOJ PRDAA$(CYCLE)

If the value of the OASIS CYCLE variable is 09; this number is substituted into the dependency, and the jobname becomes PRDAA09.

A feature in the ZEKESET batch program allows extensive date manipulation and calculation using Zeke variables. This provides the ability to create any desired format based on dates. When used with the variable substitution support (Subdata), this facility can automatically create program date cards.


12

OASIS VariablesOASIS variable values can be substituted in the same areas as Zeke variables (JCL, ZEKESET, SCOM, etc.). The value substituted into an OASIS variable can be based upon a qualifier—jobname, schedule date, run date, Netregid, system, application ID, group ID, user ID, event number, or version number. This allows for multiple values for a single variable name.

OASIS variables reside in an OASIS database on DASD, and are therefore retained across system outages and IPLs. The database is accessible to all applications using the same OASIS/HSI subsystem, so you can use OASIS variables to communicate information between your applications.

OASIS has its own online facility for maintaining variables. Refer to your ASG-OASIS for z/OS Reference Guide for more information.

Condition Code ValidationCondition code validation can be specified for each job event. A master record can include an unlimited list of condition codes to be checked during the processing of that job. If the specified condition codes are met, the specified action (cancel, fail, etc.) is taken.

Auto RepliesYou can pre-define replies to common messages from events using the Automatic Reply function. When a message and subsequent console read is issued, Zeke responds to the console read with the pre-defined reply, substituting any variables before the reply is issued.

Copying JCL and Documentation into the Zeke DatabaseJCL and documentation can be copied from an outside source into the Zeke database using the ZEKE batch utility program. This eliminates having to re-key any JCL or documentation that a user wishes to store in the Zeke database.

1 Introducing Zeke

13

Import/ExportZeke’s import/export utility allows you to:

• Export event (EMR) and variable (VAR) database records as XML data.

• Import EMR and VAR XML records into the Zeke database.

• Change key values of EMR and VAR records being imported or exported.

Filtering control statements allow you to select which records to import or export. Change control statements allow you to change fields within the records being imported or exported.

Work Center FacilityZeke provides an online list of scheduled work centers for each person responsible for signing off or completing an off-line event.

The Work Center facility performs the following functions:

• Relates off-line tasks to online tasks

• Allows online review and update of work centers

• Produces online lists or batch reports of work centers by user ID

• Sets new variable values when the work center is completed

• Triggers other events when the work center is completed

To set up a work center, you create a work center and associate it with a user ID. This user ID specifies the person responsible for the event. Enter a ZDISPLAY command to list the work centers by user ID. When the user flags the event as complete, it is removed from the display, new variables are set, and any related events are triggered.

Operator CommandsA full range of operator commands can be entered through any authorized OS console, similar to JES commands, or through the online facility. These commands allow the operator to do such things as:

• Determine if and why an event has not been dispatched

• Change priority

• Display and modify current schedule


14

ForecastingYou can produce a schedule report for any future date without affecting the status of the current schedule.

Schedule SimulationZeke can simulate the schedule function to generate a sample schedule for any future date. Schedule Simulation lists a flow of events as if the events were actually run. You specify the date, time, system ID, and resources in the simulation JCL, then run the simulation job separate from the Zeke program. The Zeke database is copied to another dataset, then the flow of events is simulated against that dataset.

PolyZekeAllows multiple copies (and different releases) of Zeke to run simultaneously on a single operating system. Each Zeke can reference a separate database or they can all share one database. For more information, see “PolyZeke” on page 18.

Continuous TrackingZeke can monitor system activity and update schedule tables after Zeke’s address space is terminated.

Zeke can track certain relevant system and event activity, even during periods when both Zeke and the OASIS subsystem have been terminated, for example, to apply maintenance. When Zeke, and event OASIS, are terminated, the system activities are recorded. When Zeke is restarted, the logged activities are basically “played back,” and the schedule is updated accordingly. Activity that can be tracked includes:

• Starting of jobs, job steps, and programs

• Ending of jobs, job steps, and programs

• Datasets that are closed

• Because these activities are recorded, Zeke will be able to mark jobs that have ended and also satisfy triggers for any jobs that might have completed while Zeke and/or OASIS was shut down.

1 Introducing Zeke

15

Electronic VaultingZeke provides dual DASD I/O writing for sites that have or are planning the implementation of a disaster recovery plan. This provides two options for designing a recovery plan:

• Use a backup of the Zeke database and perform a database restore in the event of a disaster.

• Allocate a secondary DASD unit to replicate the Zeke database. When a record is written to the primary Zeke database, the electronic vaulting option writes a duplicate record to the secondary vault dataset.

Audit Trail FacilityThe Audit Trail facility tracks Zeke database activity and logs the information in the Audit Trail facility. You define the actions logged through the /Options function of the online facility. You can also generate Audit Trail reports through the Report Writer facility.

Actions you can log include operator commands that are issued from the console and the online facility along with any changes to the following:

• Event status (beginning of job, end of job, etc.)

• Variable value

• EMR

• Internal security class record

• Calendar record

• External security class definition record

• Resource definition record

• Generation option

• Your company name or address

• Internal security operator record

• Password

• Partition or initiator definition

• Pool record

• SQR

Refer to your ASG-OASIS for z/OS Reference Guide for more information.


16

Report WriterThe Report Writer facility allows you to customize your own reports for the Zeke database. This is in addition to the standard reports. You can select the following items for each report.

• Fields

• Sequence

• Schedule records

• Selection criteria

• EMRs

1 Introducing Zeke

17

How Zeke WorksZeke maintains a database of events that need to run in a data center. The events are defined to the Zeke database through the online facility or the batch utility program. The database retains the following information about each event in the event master record (EMR):

• Detailed scheduling information (OCCURS clause)

• Prerequisite conditions (schedule time, WHEN conditions)

• Resource requirements (number of tape drives, initiator class)

This information ensures that an event is scheduled properly and is not dispatched until the prerequisites have occurred and the required resources are available.

The EMRs are used by the SCHEDULE function to create a processing schedule for each system. The schedule function, typically run at the start of each workday, removes the previous day's completed events and adds the current day's events.

Events are added to the schedule when either of the following occurs:

• The scheduling criteria is met

• An operator request is entered

Zeke monitors computer activities to detect actions that will trigger an event. When an event's scheduled time is reached (TIME satisfied) and prerequisites have occurred (WHEN satisfied), the event is placed 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 operator approval is given. Operator approval is an optional dispatch requirement that can be placed on an event.

Schedule TimeSchedule time is an optional dispatching prerequisite that must be met before an event can be dispatched. Schedule time fields available on the EMR include Sched, Early, Late, Mustend, and Notafter (see “Specifying a Schedule Time” on page 96). If the time the event is dispatched does not matter, leave these fields blank (00:00). However, if the event must be dispatched by a certain time or cannot be dispatched after a certain time, use the schedule times fields to place restrictions on the time of day an event can execute.


18

Logical DayZeke supports a 48-hour clock, which lets you schedule according to a logical day. If you have events that run past midnight, you can still consider those events to be part of the previous day’s schedule run.

When the SCHEDULE function runs, it selects every event within 48 hours to be part of the day's schedule. For example, if the schedule runs on Monday at 08:00, events are selected if the OCCURS clauses match Monday and the schedule time is between 00:00 and 47:59.

An event with a schedule time of 48:00 is never dispatched 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.

PolyZekePolyZeke enables you to run multiple copies (and different releases) of Zeke on a single CPU. The default subsystem name that identifies the OASIS subsystem is SSSI, but you can use a different subsystem name if desired. You can have multiple copies of OASIS with different subsystem names, executing in common storage (ECSA/CSA) to support multiple copies of Zeke. (Refer to your ASG-Zeke for z/OS Installation Guide for more information.) This facilitates testing a new release on a single CPU or supporting multiple users with separate Zeke databases.

Each Zeke must be running under a separate OASIS subsystem. Each subsystem should use a unique command prefix to allow commands to be targeted to a particular Zeke. We recommend every system run with generation option Posid=YES. See “Maintaining Networking Options” on page 307 for information about setting the Posid generation option. Each Zeke should have a unique system name, even though they share an OS. Each Zeke is associated with its own SMF exits. For example, if there are three Zekes running on a system, there will be at least three of each SMF exit, with each getting control serially.

You assign each OASIS subsystem a command prefix. Commands can be targeted to a specific system using this prefix. Messages will be issued with the prefix, so you can determine which system issued the message. If a unique CMD prefix is not specified for any or all systems running on a system, then any Zeke commands issued on the system with the common Z prefix will be processed by all copies of Zeke on this OS that do not have a unique prefix defined.

Jobs running on the system will be seen by the SMF exits of every system. How each Zeke processes, based on any one job, will be determined by the Trigjob generation option setting for that system.

1 Introducing Zeke

19

Caution! Multiple Zekes on the same system should be configured to reference separate databases. If all Zekes are at the same release level, they can share a database, but ASG strongly recommends against database sharing between multiple Zekes on the same LPAR. In this configuration, Zeke is not guaranteed to function properly with respect to recurring events, refreshing schedule records, and Zebb restart.

Testing a New ReleaseWith 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 allows the same applications to access more than one database. For example, a customer on a production Zeke 5.3 release can allocate a second database (possibly for testing or for production usage) and test the Zeke 5.4 release, without affecting the 5.3 production system. This is shown in Figure 1.

Figure 1 • Using PolyZeke for Testing a New Release

Zeke Production Database

Zebb Production Database

Zeke Test Database

ISPF User

Zeke 5.4

Zebb 3.1

Zeke 5.3

OASIS 270A SSSX

OASIS 260A SSSI

ISPF User


20

Support Multiple Application DatabasesIt is possible to supply end users with a separate Zeke system. This de-centralizes Zeke while isolating end users from viewing or possibly corrupting other production databases. This concept is illustrated in Figure 2.

Figure 2 • Using PolyZeke for Supporting Multiple Databases

Zebb Production Database


#3


#1

ISPF User


#4


#2

Zeke 5.4

Zeke 5.4

Zeke 5.4

Zeke 5.4

Zebb 3.1

OASIS 270A SSSI

OASIS 270A SSSX

OASIS 270A SSSB

OASIS 270A SSSA

1 Introducing Zeke

21

Zeke Interfaces to Other ASG ProductsThe following ASG products complement Zeke:

• ASG-OASIS™ for common functions of Zeke, ASG-Zebb, and ASG-Zara

• ASG-Zeke Agents™ for a mainframe-centric approach to enterprise scheduling

• ASG-Zeke Plug-ins for OpsCentral™ for centralized management of enterprise scheduling workloads

• ASG-Zara™ for automated tape management

• ASG-Zebb™ for automated job restart/rerun

• ASG-Zena™ for distributed workload management and process automation

• ASG-IMPACT® for complete IT service management

• ASG-Cortex-Pdb™ (production database) for documenting application objects and attributes

• ASG-JCLPREP® for JCL management

• ASG-JOB/SCAN® for JCL management

• ASG-PRO/JCL® for JCL management

• ASG-Workload Analyzer™ for job analysis

• ASG-Workload Planner™ for job planning when scheduling

ASG-OASIS

OASIS/DMS—Common FunctionsOASIS provides common functions for Zeke, ASG-Zebb, and ASG-Zara.

OASIS/Distributed Management Server (herein called DMS) allows Zeke to communicate with other Zekes running on different systems or platforms, as well as enabling cross-platform scheduling using ASG-Zeke Agents for Windows, OS/400, and UNIX to name a few.


22

OASIS/ESI—SAF SecurityZeke supports SAF security through the OASIS External Security Interface facility (ESI). ESI provides the ability to use a third-party security product such as RACF or CA-ACF2 to control access to Zeke or other installed OASIS-supported products.

ASG-Zeke Agents—Cross-Platform Schedule DownloadZeke allows you to download a subset of scheduled jobs in the Zeke schedule, cross-platform, to Zeke Agent. Zeke Agent then tracks and dispatches the SQRs in the same manner as Zeke would. 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 can schedule and dispatch specified job events to be sent one at a time to a Zeke Agent system running on another platform. Zeke Agent can receive, track, schedule, execute, and re-route the jobs from Zeke (or another source) to another system, as necessary.

ASG-Zeke Plug-ins for ASG-OpsCentralASG-OpsCentral (herein called OpsCentral) is the cross-platform, graphical enterprise management console for managing Zeke schedules from a client workstation. The ASG-Zeke Plug-ins for ASG-OpsCentral maintain communication between your Zekes and OpsCentral and enable Zeke functions to be available under the OpsCentral client console.

ASG-Zara—Automated Tape ManagementASG-Zara is an online media management system which secures, audits, and monitors valuable IT data in a z/OS environment, while providing real-time access to tape management data.

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

1 Introducing Zeke

23

ASG-Zena—Cross-Platform Job DependenciesZeke communicates via Zeke Agent for Windows with ASG-Zena (herein called Zena), the distributed job scheduling 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.

ASG-IMPACT—Problem Tracking SupportZeke provides problem tracking support through a user exit to interface with ASG-IMPACT Consolidated Service Desk (herein called IMPACT), or by interfacing with third-party problem tracking systems. The problem tracking interfacing user exit is called and a tracking record is produced for each abnormal end-of-event (AEOE), abnormal end-of-job (AEOJ), abnormal end-of-program (AEOP), and abnormal end-of-step (AEOS).

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

Refer to your ASG-Zeke for z/OS Installation Guide for more information.

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

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


24

ASG-JCLPREP—JCL ValidationZeke provides several ways to scan the JCL associated with your jobs events for accuracy.

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.

In addition to JCLPREP, you can also scan JCL using the Schedule View line command ZOOM, the JCL primary command, the Schedule View line command SCAN, or the ZSCAN operator command. Zeke also interfaces with ASG-JOB/SCAN (see below) using the Schedule View line command JSCAN.

The ZSCAN operator command and SCAN line command do not require installation or customization. Refer to your ASG-Zeke for z/OS User’s Guide for information on how to use the commands. Refer to your ASG-Zeke for z/OS Installation Guide for implementation instructions for the other methods.

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

1 Introducing Zeke

25

ASG-Workload Analyzer—Job AnalysisASG-Workload Analyzer is a PC-based analysis tool that tracks and analyzes batch window processing performance, detects problem areas, and presents an analysis of processing in a graphic format that is easy to understand. Workload Analyzer saves data center staff from 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 the system management facility, thereby expediting analysis of processing trends, resolving bottlenecks, and improving operational productivity in a z/OS environment.

ASG-Workload Planner—Job Planning When SchedulingASG-Workload Planner gives data center staff the ability to better understand complex schedules from a variety of mainframe scheduling systems. In addition, it helps staff forecast future scheduling performance. Workload Planner takes complex information contained in a scheduling system database and translates it into interactive graphic flowcharts. Forecast information, also collected from the scheduling system, is used to create a series of graphs that predict the performance of scheduled processing. Workload Planner provides a comprehensive flowchart of all scheduled jobs. By changing timing information, the addition or removal of jobs to and from a schedule is also modeled. This function allows you to simulate “what-if” scenarios to gauge the impact of changes on batch window processing.


26

Zeke EnhancementsFor a summary of the new features, updated functions, and performance improvements included in Zeke version 5.4, refer to your ASG-Zeke Enhancement Summary. This section lists prior enhancements since version 5.1.0.

ASG encourages you to visit the Intelligent Support Portal (ISP): http://www.asg.com/support/support.asp. The ISP allows you to verify whether any product or documentation revisions, new maintenance, or service packs apply to the current product release.

Version 5.3.1 Enhancements

Add Events by PathYou can now add an event to the schedule based on predecessor/successor relationships, that is, a specified event’s path. A path includes the root event and its predecessor and successor events.

Note:This enhancement is available through the Zeke ISPF online facility only.

Event Master Definition Primary CommandsThe following new primary commands, available on the Event Master Definitions screen, invoke the new Schedule View Add-By-Path wizard, which allows you to list predecessors and successors for an event and then schedule events in the list.

For a path, you can control the level of depth to display, as well as specify the OCCURS HIT date and event version to be considered by including the following command keywords.

Command Description

PATHADD List both predecessors and successors for an event and then schedule events in the list.

PREDADD List predecessors for an event and then schedule events in the list.

SUCCADD List successors for an event and then schedule events in the list.

Keyword Description

LEVEL Limit the path to display this level of depth.

http://www.asg.com/support/support.asp

1 Introducing Zeke

27

ADD Event Record by Path FunctionA new option on the Schedule Information Selection Criteria screen allows you to select event records to add to the schedule based on an event path. The ADD by path option launches the new ADD Event Record by Path Selection Criteria screen where you specify criteria for selecting the root event and event scheduling parameters. The Schedule View Event Add List screen lists the events in the path and allows you to select ones for scheduling.

Permanent EventsYou can now define a Zeke event as permanent. A permanent event is a type of recurring event that is never removed from the schedule so that it is always available to respond to triggers, even during schedule load processing. 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 deactivate it using the ZDELETE command.

Number of Events per DatabaseVersion 5.3.1 removes the limit on the maximum number of events in the Zeke database. The previous limit was 131K.

Report WriterRefer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following Report Writer enhancements.

New ParametersThese new parameters can be used with LIST EVENTS/PLAN for FIELDS selection:

OCCDATE Julian date to use when the OCCURS clause is resolved.

VERSION Version of the event for which to view predecessor/successor information.

Parameter Description

LJCLsrc Indicates whether to include on the report the long JCL source (file type, DD or library name, and member name).

PERManent Indicates whether to include on the report the value of the Permanent field for the selected events.

Keyword Description


28

This new parameter is available for use with LIST EVENTS/PLAN for event selection:

WHENDETAIL ParameterThe WHENDETAIL parameter has been enhanced in several ways.

• WHENDETAIL now selects events that contain the specified string, for example:

LIST EVENTS WHENDETAIL PAY1

This would match any WHEN condition with the string PAY1 in any position in the clause, such as:

EOJ PAY1BR14WEOJ WEAKPAY1VAR $ABC EQ DEVPAY1

• For LIST PLAN, you can select events based specifically on satisfied conditions, for example:

LIST PLAN WHENDETAIL *VAR

This would select events that have at least one satisfied variable WHEN condition.

• WHENDETAIL now accepts mixed-case values. This allows you to select events with mixed-case jobnames.

ZEKEXUTL—Import/ExportYou can use the import/export utility ZEKEXUTL to perform the following procedures:

• Export event (EMR) and variable (VAR) database records as XML data.

• Import EMR and VAR XML records into the Zeke database.

• Change key values of EMR and VAR records being imported or exported.

Filtering control statements allow you to select which records to import or export. Change control statements allow you to change fields within the records being imported or exported.

REPORT SubfunctionThe new REPORT subfunction of the IMPORT and EXPORT utilities allows you to print the results of an export or import of database records.


PERManent Specifies whether to select permanent or non-permanent events only.

1 Introducing Zeke

29

SCHEDULERefer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following batch utility enhancements.

Generic Selection CriteriaYou can now use wildcard or placeholder characters in your selection criteria for the following parameters when specified for the SCHEDULE function:

APPLICATIONGROUPIDSYSTEMIDUSERID

For each parameter, you can specify up to 20 values.

New ParametersThe following new parameters can be used with the SCHEDULE function:

You can use wildcard or placeholder characters in your selection criteria for both parameters.

EVENTRefer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following batch utility enhancement.

The following new parameter can be used with the EVENT function:


ENAME Selects events with the specified event name.

JOB Selects job events with the specified job name.


PERManent Indicates whether the event is to remain in the schedule permanently. See “Permanent Events” on page 27.


30

RESTORE MERGERefer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following batch utility enhancement.

Typically, when you restore EMRs and SQRs to the database, you indicate a starting event number. Optionally, you can restore the records by using available event numbers in the existing database.

ASG-OpsCentral SupportVersion 5.3.1 supports ASG-OpsCentral (herein called OpsCentral) Version 2.0, the cross-platform, graphical enterprise management console for managing a Zeke schedule from a client workstation. If you have multiple Zeke systems operating in a ZekePlex or an ASG-Zena (herein called Zena) platform scheduler, OpsCentral can manage the scheduling information for any or all Zekes and Zena simultaneously.

Zeke’s OpsCentral server is the message processor that facilitates communication between Zeke and OpsCentral via ASG-RI Server (herein called RIS). See “Zeke OpsCentral Server Commands” on page 32 for new operator commands related to the OpsCentral server.

Refer to your ASG-Zeke for z/OS Installation Guide for detailed information on ASG-OpsCentral support.

OpsCentral Client AuthenticationIn Version 5.3.1, the OpsCentral Client is authenticated to Zeke using thread security services. A RACF security environment is created for each request (or executing thread) from OpsCentral.

Although OpsCentral Client authentication can be disabled, ASG recommends you enable it unless your environment is highly secured and clients are authenticated by other means.

Average DurationZeke now maintains the average duration time in seconds (instead of minutes). If you use OpsCentral, this enhancement affects the average duration time Zeke provides to OpsCentral for use in Gantt charts.

1 Introducing Zeke

31

Generation OptionsVersion 5.3.1 introduces the following new generation options. Refer to your ASG-Zeke for z/OS Reference Guide and ASG-Zeke for z/OS User’s Guide for detailed information.

Operator CommandsRefer to your ASG-Zeke for z/OS Reference Guide for detailed information on the following operator command enhancements.

Zeke Address Space CommandsZeke provides its own operator modify commands for altering the Zeke environment.

Option Purpose

DefDelOJ Code indicating the default setting for the Delete after next use option in an SQR when JCL is updated.

DSPReprt Code indicating whether the DATASPACE parameter must be specified with the LIST command for Report Writer jobs to use a dataspace to create a batch report.

Zprdsemr Code indicating whether to suppress inter-product EMR messages.

Command Purpose

#APPEND Append LE parameters to the list of LE parameters used when the OpsCentral server subtask is started (attached).

#CLEAR Remove any LE parameters from the internal LE buffer passed to the OpsCentral server at start-up (when attached).

#DISPLAY Display contents of the LE parameter buffer and subtask information for all subtask modules.

#RESET Reset the subtask restart counter back to zero.

#SET Set the LE parameters to be used when OpsCentral is started and the maximum number of automatic restarts.

#START Start a subtask module.


32

Zeke OpsCentral Server CommandsThe OpsCentral server (the message processor that facilitates communication between Zeke and OpsCentral via RIS) executes as a subtask of the Zeke started task. These commands allow you to manage OpsCentral server thread and trace options while the server is executing and without having to restart it.

VariablesFor improved flexibility in variable substitution, variable values can now be specified in mixed case in the online facilities. (Previously, values were forced to upper case.)

As in previous Zeke releases, mixed-case variable values continue to be supported by the batch utilities (ZEKE and ZEKESET), Report Writer, the Audit facility, and in WHEN conditions.

Note:Currently, only the ZSET function does not support mixed-case values.

Refer to your ASG-Zeke for z/OS User’s Guide for detailed information.

External SecurityA new external security class named Z$ACCESS secures use of generic selection criteria (for application ID, group ID, system ID, or user ID) or the CLEAR keyword with the SCHEDULE function. Refer to your ASG-Zeke for z/OS User’s Guide for detailed information on external security.

Command Purpose

$CLOSE Close one or more alerts.

$DISPLAY Display the current sessions, server thread statistics, trace settings, and the alert cache.

$KILL Remove a session ID, terminate a thread, or remove all sessions associated with a user ID.

$OPEN Create an alert message, which is sent to OpsCentral clients and placed in the OpsCentral server alert cache.

$SET Set the number of threads used to process requests or set or reset trace flags.

1 Introducing Zeke

33

ASG-JCLPREPIf you use ASG-JCLPREP (herein called JCLPREP) to validate JCL in Schedule View, you can now use the JPREP line command to populate OASIS event-related items (XQxxxxx). Refer to your ASG-Zeke for z/OS Installation Guide for more information on configuring Zeke’s JCLPREP interface.


Cross-System Coupling Facility (XCF)Refer to your ASG-Zeke for z/OS Installation Guide for a detailed explanation of XCF, configuration steps, and operating scenarios.

Using XCF for Data SharingZeke 5.3 introduced support for IBM’s Cross-System Coupling Facility (XCF) data repository, a hardware component which, combined with software available in z/OS, allows data to be shared between systems more quickly than is possible using DASD. A key benefit to using XCF is that it is restartable after an outage, without requiring any of the Zekes in the SysPlex to be restarted.

Using XCF for COMM Record BroadcastingOptionally, Zeke can use XCF (in place of the Zeke database) to process communication (COMM) records (records that signal changes to schedule information).

Using XCF for NOTDURING Processing Across a SysPlexXCF messaging services expand NOTDURING processing across your ZekePlex, as an option, by allowing Zeke to recognize non-Zeke jobs running on other systems in the SysPlex. Using XCF also reduces the time needed for Zeke to find both Zeke-controlled and non-Zeke jobs running on another system in the ZekePlex.

In addition to enabling NOTDURING processing through XCF, setting PLEXNOTD to YES allows NOTDURING job processing in both JES2 and JES3 (otherwise, only JES2 supports NOTDURING dependencies). All Zekes must share the same JES pool.

ZPLEX Operator CommandThe ZPLEX operator command is used to manage ZekePlex services. The ZPLEX command can be used to:

• Display status information about all operating systems and Zekes in the ZekePlex.

• Display summary information about this Zeke’s XCF processing status.

• Start and stop ZekePlex services.


34

Continuous Job TrackingZeke can track certain relevant event activity, even during periods when both Zeke and the OASIS subsystem have been terminated, for example, to apply maintenance. When Zeke, and even OASIS, are terminated, the system activities are recorded. When Zeke is restarted, the logged activities are basically “played back,” and the schedule is updated accordingly.

Because these activities are recorded, Zeke will be able to mark jobs that have ended and also satisfy triggers for any jobs that might have completed while Zeke and/or OASIS was shut down.

ZKILL TRACK Operator CommandThe TRACK parameter is used with the Zeke operator command ZKILL to terminate the Zeke system and place it in SMF recording mode.

DMS Registration PerformanceZeke 5.3 enhanced the registration process through DMS. Previously, a single-threaded registration process created a backlog and extended the length of time required for Zeke to register with DMS successfully. This process has been improved by being changed to a multi-threaded process, improving overall DMS performance in the following ways:

• Improving registration performance.

• Improving communication performance of DMS.

• Providing downward compatibility between new DMS data structures and currently supported versions of Zeke, Zebb, Zara, and Zeke Agents.

• Enhancing diagnostic capabilities.

Variable Index ProcessingIn prior releases, Zeke variable processing included an in-memory index for locating the database record containing variable information. This eliminated the need for a directory search of the database and the associated I/O. However, the in-memory index was not updated if a variable was added on another Zeke system. Zeke assumed the index to be inconsistent and searched the database when no entry was found in the index. In a large ZekePlex with many variables, this could cause a significant degradation in scheduling events that use variable values.

In Zeke 5.3.0, the following changes were made:

• Varindex generation option, which controlled the creation of the variable index, has been deleted so that the index is no longer optional; the variable index is always built.

1 Introducing Zeke

35

• Updates to the variable index are broadcast to all Zeke systems in a ZekePlex through COMM records. This helps keep the index consistent and avoid the I/O overhead generated when searching the database—if there is no record in the index, then the variable is assumed not to exist.

• Requests for variable substitution in JCL use only the index to determine if the variable exists. This reduces overhead and elapsed time for JCL variable substitution.

Note:A special PTF is available if you do not want the additional storage use. Contact ASG Customer Support for assistance.

Finer Time Resolution for Event Dispatch/End TimesPreviously, job dispatch and ending times were evaluated by Zeke and expressed in hours and minutes only. Because it is essential in determining if and when certain dependent events are to be triggered, event dispatch and end times are now evaluated and expressed in hours, minutes, and seconds (hh:mm:ss). This is especially important for extended dependencies for job events.

Documentation EnhancementsThe ASG-Zeke for z/OS Reference Guide in your Zeke documentation set has been enhanced to list and define all Zeke online fields and generation options alphabetically.

The ASG-Zeke for z/OS User’s Guide and ASG-Zeke for z/OS Reference Guide now include all primary and secondary status codes and reason codes for Schedule View and the ZDISPLAY command ZD WAIT.


Downloading a Schedule to ASG-Zeke AgentBeginning in Version 5.2.0, Zeke can handle your platform jobs by downloading a subset of the schedule records in the Zeke schedule to a ASG-Zeke Agent (herein called Zeke Agent) for dispatch and execution. (As with previous releases, Zeke continues to be able to dispatch jobs individually to Zeke Agent for execution on your distributed systems.)

For more information on downloading jobs to Zeke Agent, refer to “Schedules Downloaded to Zeke Agent” on page 197 of this publication as well as your ASG-Zeke Agent User’s Guide.


36

Note:This feature requires ASG-Zeke Agent Version 2.x. Contact ASG to find out which platforms are currently supported.

ASG-JCLPREP IntegrationASG-JCLPREP (herein called JCLPREP), ASG’s JCL management tool, provides a way to scan for accuracy the JCL associated with a job event. JCLPREP can be invoked using the Schedule View line command JPREP. Or, you can invoke JCLPREP as you are editing the event JCL via the Schedule View ZOOM display, by issuing the JCLPREP edit macro FPREP.

Note:You must configure Zeke for interfacing with JCLPREP before you can use the JPREP line command. Refer to your ASG-Zeke for z/OS Installation Guide for details.

ASG-IMPACT InterfaceZeke 5.2 introduced a new user exit to interface with ASG-IMPACT Consolidated Service Desk (herein called IMPACT). (Zeke continues to interface with commonly-used third-party problem tracking systems.) Refer to your ASG-Zeke for z/OS Installation Guide for information on accessing and tracking IMPACT tickets opened by Zeke.

Zeke Server for ASG-Enterprise Scheduling ConsoleVersion 5.2 introduced support for ASG-Enterprise Scheduling Console (herein called ESC), the cross-platform, GUI-based enterprise management console used for managing a Zeke schedule from a client workstation. ESC runs on a variety of different platforms, including Windows, UNIX, and Linux. Communications are facilitated through the ASG-RI Server (herein called RIS).

ASG-Cortex-Pdb Plug to ZekeASG-Cortex-Pdb for z/OS Version 6.2.0 (herein called Cortex-Pdb) provides a new plug-in interface to Zeke. As described in PTF Z520A058, a new Zeke module named ZEKEXAPI is installed, enabling Zeke to bridge to Cortex-Pdb.

You must also apply the appropriate PTF for Cortex-Pdb (refer to your ASG-Cortex-Pdb Release Notes Version 6.2.0 for details). Refer to your ASG-Cortex-Pdb Plug to ASG-Zeke User’s Guide for information on implementing and using the interface.

1 Introducing Zeke

37

Improved IBM Workload Manager Initiator SupportZeke’s way of working with IBM Workload Manager (herein called WLM) initiators has been enhanced. WLM manages JES2 initiators, by starting and stopping them in response to job workloads. When running with the generation option Dispsel=Y, Zeke is not able to see any available initiators and does not submit WLM jobs.

Normally, to allow the WLM jobs to be submitted, you would need to specify Dispsel=N. However, if your are running a mixture of WLM and non-WLM jobs, this would not be appropriate.

Through a special PTF, you can mark job events as WLM-managed. These jobs will always be submitted by Zeke, even if Dispsel=Y, and regardless of whether a JES2 initiator is available. Essentially, the jobs are managed by WLM instead of Zeke. After their acceptance by JES2, WLM will start an initiator, as needed.

Julian Day Keyword—JDAYThe Julian day can now be specified in the OCCURS clause using the new keyword, JDAY. JDAY uses the same format as the keyword DAY, but its period is for the year. You can also code JDAY by itself to refer to the current Julian day in comparison phrases.

Verload Field ProtectionThe Event Master Record Functions panel (Z1100000) was modified to prevent a user from over-typing data intended for the Target field so that it overflows into the Verload field. The SKIP(OFF) attribute was applied to the end of the Target field. 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 will lock and you will have to press Reset and then the Tab key to continue.

Zeke PDS Override OptionNormally, the JCL override feature for PDS JCL works by attaching the JCL from the PDS as a ZEKEJCL attachment to the schedule queue record (SQR). This JCL can then be modified for the purpose of re-running the job. Optionally, you may choose for Zeke to override the JCL after the next job run.

Zeke’s new PDS override option provides an alternative to the standard JCL override function in Schedule View. The new 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.


38

Schedule View

Sort SetupThe Schedule View Sort Setup screen provides a new way to set up the sort order for fields in Schedule View. Fields listed above the separator line are used for sorting in the user-specified sort order. Unused fields (below the line) are listed alphabetically, for convenience.

Display SetupThe Schedule View Display Setup screen provides a new way to set up the display order for fields in Schedule View. Fields listed above the separator line are displayed in the user-specified sort sequence. Unused fields (below the line) are listed alphabetically, for convenience.

Operator CommandsVersion 5.2.0 added or updated the following parameters.

ZDISPLAY Command


DOWnload Displays the list of schedule download agents and their processing statuses.

DLStatus Displays the download status of events. Only events with a target of a download agent are displayed.

STATus Displays events of a specified status.

ACTive Displays events currently running.

DISpatched Displays events that have been dispatched but have not started running.

FAIl Displays events that ended abnormally.

QUEued Displays events that are in the dispatch queue.

SCHeduled Displays events with time and WHEN conditions that have not been satisfied.

SUCcess Displays events that completed successfully.

1 Introducing Zeke

39

ZALTER Command

Auto Replies to Suppressed MessagesIn addition to being triggered by a specified message, portion of a message, message ID, or other unique text string, a Zeke automatic reply can also be triggered by a message that has been suppressed from the console.


OS CompatibilityZeke supports four-digit initiator names, in compliance with JES2 4.3 and above.

New Started Task ParametersNew startup parameters for Zeke allow you to start Zeke with the dispatcher on hold, start at a disaster recovery site without the vault dataset, or override certain generation options. The parameters are kept in a PARMLIB member. For example:

Event Definition

Increase Event Numbers to Six DigitsZeke event numbers were increased to six digits. This allows you to define and maintain up to 999,999 events on a single Zeke database as long as the database size is sufficient.


SYNch Synchronizes schedule records downloaded to a Zeke Agent with their corresponding records on Zeke.

Startup Parms Description

SYSHOLD=YES Causes Zeke to start with the dispatcher on hold.

VAULT=NO Enables Zeke to start at a disaster recovery site without the vault dataset.

DSPACE=NO Overrides the generation options and starts the started task without an EDB dataspace.


40

Non-Executable EventsAn event can be defined as non-executable. Non-executable events are scheduled like any other event, and are useful as predecessors to other events. A non-executable event is never submitted for execution. After dispatch, the event status automatically changes to indicate success and any dependent events are triggered.

30-Byte JobnamesZeke supports a 30-byte mixed-case jobname in the event definition for a non-mainframe event and for any jobname used in a WHEN condition. This allows for greater flexibility in defining WHEN conditions for events that execute on other platforms.

All Event Master Record Functions screens are enhanced to allow long jobnames. Long jobname can now also be selected as a field for printing on reports.

Improved WHEN Condition ProcessingWHEN condition processing using the Event Master Record Functions screen has been enhanced to allow the following functions:

• All standard ISPF commands, such as FIND, CHANGE, CHANGEALL, SAVE and CANCEL are now available.

• Scrollable WHEN conditions.

• Limit on the length of jobnames used in a WHEN condition has been increased to 30 characters.

New Event Type for REXX EventsA REXX event type allows Zeke to dispatch and track REXX execs. REXX execs are commonly used to customize various Zeke functions, such as messages and commands. REXX events can be defined using the ISPF online facility or batch. REXX events can be reported or simulated like other event types.

Note:To implement the use of REXX events, OASIS/ECF must be installed and set up. Refer to your ASG-OASIS for z/OS Installation Guide for instructions.

Schedule Time of 48:00You can use 48:00 as a schedule time. An event with a schedule time of 48:00 is never dispatched 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.

1 Introducing Zeke

41

Scheduling

Improved Flexibility in Adding or Deleting Events from the ScheduleZeke now allows you to add an entire schedule for a run date other than the current date. All events added to the schedule will have the specified run date.

Scheduled events can be deleted from the schedule by group ID, application ID, or user ID. Scheduled events that meet all of the specified criteria are cleared from the schedule. If only partial criteria or no criteria are met, then the events remain in the schedule.

Schedule Date Included in Message Z0302I System message Z0302I has been changed to include the schedule date. This allows you to uniquely identify an event that is late when you have multiple events with the same event number, but different schedule times.

Note:If you use an automated operator product, and are intercepting the Z0302I message, revise the automated operator to accommodate the schedule date portion of the message.

Schedule View

AUTO CommandThe maximum wait time to break out of update mode is now specified using the INTERVAL command.

When the screen is in automatic monitoring mode, a message at the bottom of the screen indicates that AUTO mode is on and displays the latest INTERVAL command settings.

INTERVAL CommandThe following parameters were added for the INTERVAL command.


ratewait

These two new operands control the automatic monitoring mode. The first number {rate} is the seconds between automatic refreshes. The second number {wait} is how often to check for a request to exit AUTO mode.To change the timing of screen refreshes, enter INT rate wait where rate is a range from wait value to 3660 seconds and wait is a range from 1 to 255. Both parameters are optional and have default values of 5. Additionally rate must be a multiple of wait; however, this is calculated and changed automatically.For example, to refresh the screen every 10 seconds and to check for an exit AUTO mode request every 5 seconds, enter INT 10 5.


42

Viewing Remote JobnamesAs a part of Zeke’s support for 30-byte mixed-case jobnames in the event definition for non-mainframe events, Schedule View now allows you to view longer remote jobnames in addition to eight-byte mainframe jobnames in your display. See “Using Schedule View” on page 202 for information on setting up how jobnames appear in your display.

Operator Commands

Six-Digit Event Numbers in Operator CommandsSix-digit event numbers can be specified in the event selection criteria for any operator command that accepts event number as a parameter.

ZADD Operator CommandThe following parameters were added for the ZADD command.


APPLication Adds one or more events with the specified application ID to the schedule. The Multap generation option (see “Generation Options” on page 45) indicates the action to take when more than one event matches the specified application ID.

CURRplus Updates the scheduled event’s start time by adding the specified amount of time (hhmm) to the event’s start time. If the event does not have a start time specified, then the CURRPLUS value is added to the current time.

GROup Adds one or more events with the specified group ID to the schedule. The Multgr generation option (see “Generation Options” on page 45) indicates the action to take when more than one event matches the specified group ID.

PREView Displays a list of the events that would be added to the schedule if you submitted the ZADD command with the criteria currently specified.

RUN Adds the event to the schedule ready to run using the event master record (EMR) information. The RUN option satisfies the event’s time, WHEN, NOTACTIVE, and operator confirmation conditions.

USERid Adds one or more events with the specified user ID to the schedule. The Multus generation option (see“Generation Options” on page 45) indicates the action to take when more than one event matches the specified user ID.

1 Introducing Zeke

43

ZALTER Operator CommandThe following parameter was added for the ZALTER command.

ZDELETE Operator CommandThe following parameters were added for the ZDELETE command.


CONTROL Indicates whether this event is tracked as a Zeke-controlled event. Zeke-controlled events are tracked throughout the entire execution. You can also define the event as non-executable. This means the record can be scheduled as normal, but the JCL is not dispatched. Instead when the event is dispatched, the event’s status changes to SUCCESS and other events are triggered.

FAILURE Marks the event with an F/F (forced failure) status and triggers all the failure dependencies.


APPLication Deletes one or more events with the specified application ID from the schedule.

The Multap generation option (see “Generation Options” on page 45) indicates the action to take when more than one event matches the specified application ID.

GROup Deletes one or more events with the specified group ID from the schedule.

The Multgr generation option (see “Generation Options” on page 45) indicates the action to take when more than one event matches the specified group ID.

PREView Displays a list of the events that would be deleted from the schedule if the ZDELETE command string were submitted with the current criteria and without the PREVIEW parameter.

USERid Deletes events with the specified user ID from the schedule.

The Multus generation option (see “Generation Options” on page 45) indicates the action to take when more than one event matches the specified user ID.


44

ZDISPLAY Operator CommandThe following parameter was added for the ZDISPLAY command.

ZDISPLAY FormatsThe display formats have changed to reflect revised column names, six-digit event numbers, and terminology changes.

The ZDISPLAY statuses LATE, DSBL, PEND, ACTV, HOLD are unchanged.

ZRELEASE Operator CommandYou can now use the ZRELEASE command to release an event even if the system is on hold.


STATus Selects events of a specified status to display. Valid statuses are:

Status Description

SCHeduled Displays scheduled events with time conditions and dependencies that are not yet satisfied.

QUEued Displays scheduled events in the dispatch queue.

DISpatched Displays scheduled events that are dispatched but not yet running.

ACTive Displays scheduled events that are running.

SUCcess Displays scheduled events that completed successfully.

FAIl Displays scheduled events that failed to complete.

1 Introducing Zeke

45

Generation OptionsThe following generation options were added.

BACKUP CommandThe following keyword was added for the BACKUP batch utility command.

CREATE CommandThe following keyword was added for the CREATE batch utility command.

Option Description

DSPSched Indicates whether the DATASPACE option can be used for schedule loads.

Multap Indicates what to do when a ZADD or ZDELETE is issued based on an application name, but more than one EMR has the specified application name.

Multgr Indicates what to do when a ZADD or ZDELETE is issued based on a group name, but more than one EMR has the specified group name.

Multus Indicates what to do when a ZADD or ZDELETE is issued based on a user ID, but more than one EMR has the user ID specified.

Posidend z/OS only. If Posid=YES, specifies whether POSID information is placed at the end or the beginning in Zeke-dispatched jobs.

Remtrig Indicates how to handle a remote trigger received for scheduled jobs with multiple schedule dates.

Keyword Description

DATASPACE Creates a backup copy of the database from a temporary copy created in a dataspace.

Keyword Description

PLEXID Specifies an eight-character name that uniquely identifies the Zeke database to which multiple systems are connected.


46

EVENT CommandThe following parameters were added for the EVENT batch utility command:

RESTORE CommandThe following keyword was added for the RESTORE batch utility command.

SCHEDULE CommandThe following parameters were added for the SCHEDULE batch utility command.


SCOMSTARTSCOMAPPEND

Indicates the beginning of SCOM data in the SYSIN JCL to be added to an SCOM event master record as part of the EVENT ADD or EVENT UPDATE process.

SCOMSTOP Indicates the end of SCOM data to be added to an SCOM event master record as part of the EVENT ADD or EVENT UPDATE process.

Keyword Description

PLEXID Specifies an eight-character name that uniquely identifies the Zeke database.


DATASPACE Creates a schedule from a temporary copy of the database created in a dataspace. This feature reduces I/O on the database, reducing CPU time by an average of 30%.

APPLication Identifies the application the event is a part of.

GROupid Identifies the group the event is a part of.

USERid Identifies the person who is responsible for the event.

RDATE RDATE used with the ACTIVATE parameter allows you to specify an RDATE value other than the default value of today. All events added to the schedule will have the RDATE specified in the statement.

1 Introducing Zeke

47

Report Writer

LIST EVENTS/PLAN—EMR and Schedule ListingsThe following parameter was added for the LIST EVENTS/PLAN command.

OCCURSDETAILThe OCCURSDETAIL parameter was added for the LIST EVENTS command. This parameter is not valid with the LIST PLAN command.

When using the OCCURSDETAIL parameter, it is important to understand how Zeke considers OCCURS clauses.

In Version 4.5 and earlier, an event with the default OCCURS specification REQUEST was considered to have an OCCURS clause. However, in Version 5.1.0 (and above), an event with the default OCCURS specification REQUEST is considered by Zeke not to have an OCCURS clause.

Beginning with the introduction of the OCCURSDETAIL parameter in Version 5.1.0, you can perform a LIST EVENTS to select events with any OCCURS clause or with specific OCCURS keywords. Based on Zeke’s interpretation of OCCURS clauses, an OCCURS value of REQUEST is never selected.

LJOBnameThe following keyword were added for the FIELDS parameter of the LIST EVENTS/PLAN command.


DATASPACE Lists the information using a temporary copy of the database created in a dataspace when generating the report. This reduces I/O on the database, allowing the batch program to execute much more quickly.

TARGet Selects EMRs that execute on the specified remote system.


OCCURSDETAIL Selects events with OCCURS clauses that contain the specified keywords.


FIELDs Specifies the fields to be printed on the report.

LIST EVENTS FIELD=(ENAME, LJOB)

Keyword Length Description

LJOBname 30 Long jobname


48

49

2Chapter 2:Starting Zeke and Using the

Online Facility

This chapter explains how to start and terminate Zeke and OASIS. It also describes the ISPF interface to Zeke, and explains how to log on to and exit the Zeke online facility.

Topic Page

Starting Zeke 50

Restarting Zeke 51

Starting OASIS Only 52

Starting Multiple Tasks 53

Terminating OASIS 55

Terminating Zeke 56

ISPF Interface 57ISPF Features 57General Screen Information 58Logging On 59


50

Starting ZekeThe SSS4001 program initializes Zeke. If the specified OASIS subsystem is not already initialized, SSS4001 initializes it before starting Zeke.

To start Zeke

Submit a job similar to the following:

//ZEKE PROC R=0M,S=ZK540,// XP=ZEKECOM,OASIS=(aa,bb),// ZK=YES,//stepname EXEC PGM=SSS4ØØ1,REGION=&R,TIME=1440,// PARM=('OASIS=&OASIS’,’ZEKE=&ZK’,’XPROC=&XP’,’SUBSYS=&S’,END)//STEPLIB DD DISP=SHR,DSN=Zeke load library// DD DISP=SHR,DSN=OASIS load library//ZEKERDR DD SYSOUT=(A,INTRDR)//SYSPRINT DD SYSOUT=*//SYSABEND DD SYSOUT=*//xxxxxxxx DD DISP=SHR,DSN=any necessary DD statements

where:

Code Meaning

aa OASISxx options member name suffix.

bb Console option.

Option Description

L List all options values on the console.

C Start an operator dialogue to list the values, override values for this start-up, and/or cancel the start-up.

LC Both L and C. List option values on the console; then start an operator dialogue.

N Not L or C. Do not list option values or start a dialogue.

2 Starting Zeke and Using the Online Facility

51

Restarting ZekeIf a Zeke started task subtask terminates, it is automatically restarted. An information message is issued when this occurs. If a subtask terminates numerous times, it is assumed a serious error exists and the subtask is not restarted. If this occurs, terminate Zeke and correct the problem before trying to restart Zeke.

If multiple OASIS-supported products are active in one address space and Zeke is deactivated by the ZKILL command (WARM or COLD) or the system STOP command, start the same Zeke procedure that was used to initiate the address space that was terminated.

To restart Zeke when OASIS is already running

Issue the START ZEKE command from the operator console or issue a system MODIFY command to the address space.

F procname STPROD ZEKE

When the Zeke address space starts, it will find its schedule tables in CSA and determine whether it should do a warm or cold start.


52

Starting OASIS OnlyYou can start OASIS without starting Zeke. This is a normal procedure when you need to create a Zeke database.

To start OASIS

Issue the START command using the following syntax:

START procname,S=subsys,OASIS='(aa,bb)'

where:

Note:If the start-up procedure provides values for the S and OASIS symbolic parameters, you can omit those parameters from the START command.

The following is a sample of a typical OASIS startup:

S OASISSTC,S=SSSI,OASIS='(00,N)'$HASP100 OASISSTC ON STCINRDR$HASP373 OASISSTC STARTEDIEF403I OASISSTC - STARTED - TIME=14.39.30X00032I EXECPARM OASIS=(00,N),SUBSYS=SSSIX00353I Program SSS2SV2 installed as SVC 245X00000I SET UP COMMAND PREFIX LENGTHX00008I SSSI Host System Interface initialized CPU=1B02095570600000 ID=A Name=AX00025I OASIS/HSI X270A000 z/OS 1.4.0 JES2X00903I OASIS command processor enabled

procname Name of the OASIS start-up procedure.

subsys OASIS subsystem name.

(aa,bb) OASISxx options member name suffix and console option.


53

Starting Multiple TasksThe following examples show the changes to make to the Zeke started task, the ZEKEUTL batch utility, and the OASIS procedures for an alternate subsystem name of ZDOC. Refer to your ASG-OASIS for z/OS Installation Guide for more information on using PolyZeke, and on modifying Zeke and OASIS procedures to run multiple versions of Zeke on a single operating system.

Zeke Started Task

//* ZEKE : ALTERNATE STARTED TASK PROC//ZK53ALT PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS270//ZK53ALT EXEC PGM=SSS4001,REGION=&R, // TIME=1440,PARM=’OASIS=&OASIS,ZEKE=&ZEKE,SUBSYS=&S,XPROC=&XPROC,END’//SYSPRINT DD SYSOUT=* //SYSABEND DD SYSOUT=* //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* //*

Each Zeke must have its own unique ZEKExx and OASISxx members. In each Zeke started task procedure, change the OASIS=(00,L) and ZEKE=(00,L) to OASIS=(xx,L) and ZEKE=(xx,L), where ‘xx’ is the last 2 characters of the OASISxx or ZEKExx options member for that particular Zeke.

ZEKE Batch Utility

//* ZEKE : BATCH UTILITY PROC//ZEKEUTL PROC R=0M,P='SUBSYS=ZDOC'//ZUTL EXEC PGM=ZEKE,PARM='&P',REGION=&R//ZEKECAT DD DISP=SHR,DSN=* Alternate Zeke Database *//STEPLIB DD DISP=SHR,DSN=* Your Zeke Load Library Name *// DD DISP=SHR,DSN=* Your OASIS Load Library Name*//SYSPRINT DD SYSOUT=*//SYSABEND DD SYSOUT=*//SORTWK01 DD DSN=&&SORTWK01,DISP=(NEW,DELETE),// SPACE=(CYL,(2,2)),UNIT=SYSDA//SORTWK02 DD DSN=&&SORTWK02,DISP=(NEW,DELETE),// SPACE=(CYL,(2,2)),UNIT=SYSDA//SORTWK03 DD DSN=&&SORTWK03,DISP=(NEW,DELETE),// SPACE=(CYL,(2,2)),UNIT=SYSDA//*


54

OASIS Started Task

//* ZEKE : OASIS ALTERNATE SUPPORT PROC//OASISALT PROC R=0M,OASIS=(00,L),S=ZDOC//OASISALT EXEC PGM=SSS0UTL,REGION=&R,PARM=’OASIS=&OASIS,SUBSYS=&S,END’//PARMLIB DD DSN=ASG.PARMLIB,DISP=SHR//SYSPRINT DD SYSOUT=*//SYSABEND DD SYSOUT=*//STEPLIB DD DISP=SHR,DSN=* Your Zeke Load Library Name *// DD DISP=SHR,DSN=* Your OASIS Load Library Name*

Zeke Started TaskThis example shows the changes to use a single started task procedure to access multiple Zeke database and OASIS subsystems.

//ZEKE PROC R=0M,OASIS=(00,L),ZEKE=(00,L),S=ZDOC,XPROC=OASIS270// 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=*//SYSABEND DD SYSOUT=*//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*//*

Zeke Start Up CommandsUse the following commands to start the Zeke primary production system using an alternate database:

S ZEKE Starts production systemS ZEKE,S=ZDOC,DB='ZEKE.TEST.DATABASE',OASIS=(01,L) Starts alternate database


55

Terminating OASISDo not terminate OASIS if any other OASIS-supported products are running in that OASIS subsystem. All OASIS-supported products in the same subsystem must be terminated prior to terminating OASIS.

The following is a sample jobstream to terminate OASIS (where xxxx is the subsystem):

//ZOASIS JOB ,MSGLEVEL=(1,1),CLASS=A//SOASIS EXEC PROC=OASIS,REGION=1024K,S=xxxx//SYSPRINT DD SYSOUT=A//STEPLIB DD DSN=OASIS.LINKLIB,DISP=SHR <== If required//SYSIN DD * TERMINATE/*


56

Terminating ZekeTo terminate Zeke with the STOP command

If more than one OASIS-supported product is active in the address space, the system STOP command (P command) terminates all active products as well as the started task. When the last, or only, active product in the address space terminates, the started task automatically terminates.

1 With the STOP command, specify the name of the procedure that starts the task. Issue the following command to terminate a Zeke started task:

STOP ZEKE

2 Zeke asks whether you want to perform a cold or warm termination (see the description of ZKILL below for the difference between cold and warm termination). Enter C for cold or W for warm.

To terminate Zeke using ZKILL

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

Issue one of the following ZKILL commands to terminate Zeke, depending on the desired result.

See “ZKILL Command” on page 273 for more details.

Command Result

ZKILL COLD Terminate all Zeke processing and release all Zeke program and table storage. Other products in the same address space remain active.

ZKILL WARM Terminate only Zeke dispatching; Zeke still performs all job tracking, triggering, and updates. Other products in the same address space remain active.

Note:If Zeke is cancelled during a cold start, before the schedule has been loaded the first time, or while a schedule reload is in progress, the schedule is freed and Zeke terminates fully.

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


57

ISPF Interface

ISPF FeaturesThe Zeke online facility is a dialog that runs under ISPF/PDF. Since it is a dialog, all ISPF functions, such as SPLIT SCREEN and JUMP, are available. You can enter any valid ISPF commands on the Command line or Option line. Additionally, you have control over the PF key settings.

Online HelpThe online facility includes an online Tutorial and Help system. To access the Tutorial, enter T from the Zeke Option Menu. To access Help, press F1from any Zeke application screen.

Primary CommandsPrimary commands, such as ADD, DELETE, BROWSE, and EDIT, are listed on most screens beside the Primary Commands heading. Enter these commands on the Command line or Option line to change the mode for the screen you are using or to switch to another screen.

Screens that use editing also support all standard ISPF editing commands, such as SAVE, EDIT, CANCEL, and END.

Note:A few commands, such as CANCEL, COPY, and EDIT, have the same name in ISPF as in Zeke. When these commands are issued within Zeke, they are processed as Zeke commands, not ISPF commands. To use the ISPF command within 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 details about the BUILTIN command.

Though not listed beside the Primary Commands heading, the OVAR primary command is available from the Command line of any screen in the ISPF online facility. This command accesses the OASIS Variable Maintenance screen where you can add, browse, edit, or delete OASIS variables.


58

Line CommandsLine commands, such as I for Insert, R for Repeat, and D for Delete, are listed on the screens beside the Line Commands heading where applicable. Enter these commands in the SEL field next to the appropriate item. The SEL field is located at the left-hand column of a screen.

Screens that use line commands also support all standard ISPF editing commands, such as C for Copy, CC for Copy Block, and TF for Text Flow.

General Screen InformationThis section describes the standard format of the Zeke ISPF screens, including the fields common to most screens.

ASG-Zeke Condition Code Validation ADD Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000006 Jobname: TSKKGUT1 System: ZEQA Event Name: ZEKE51TST6 Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC STEP01 GT 8 F STEP02 NE 16 O Screen Mode

action allowed on this screen.

Command or Optionprimary command entry lineScreen Namevaries depending on screen purpose

Primary CommandsZeke primary commands; varies by screen function; standard ISPF commands are also available

Line CommandsZeke line commands; varies by screen function; standard ISPF commands are also available


59

Logging OnThis procedure explains how to log on to the Zeke ISPF online system. The online can be used to update the Zeke database and handle many tasks basic to using Zeke effectively. All the remaining ISPF procedures assume you begin at the Zeke Primary Menu.

To access the Zeke ISPF online facility

1 Access the IBM ISPF Primary Option Menu.

2 Enter Z and press Enter.

The ASG Product Selection Menu is displayed.

3 Enter ZE in the OPTION field.

ISPF Primary Option Menu Option ===> ASG More: + 0 Settings Terminal and user parameters User ID . : SPTKAB 1 View Display source data or listings Time. . . : 15:15 2 Edit Create or change source data Terminal. : 3278 3 Utilities Perform utility functions Screen. . : 1 4 Foreground Interactive language processing Language. : ENGLISH 5 Batch Submit job for language processing Appl ID . : ISP 6 Command Enter TSO or Workstation commands TSO logon : $TSUSER 7 Dialog Test Perform dialog testing TSO prefix: SPTKAB 8 LM Facility Library administrator functions System ID : SYSD 9 IBM Products IBM program development products MVS acct. : ACCT 10 SCLM SW Configuration Library Manager Release . : ISPF 5.2 11 Workplace ISPF Object/Action Workplace BS BookShelf IBM's BookShelf Z Zteam Zeke, Zebb, Zara

Enter X to Terminate using log/list defaults

ASG Product Selection Menu OPTION ===> ZE OASIS Subsystem ===> SSSI USERID - SPTKAB ZA ASG-Zack - Automated Operations TIME - 15:22 ZB ASG-Zebb - Rerun/Restart Management ZE ASG-Zeke - Enterprise Scheduling ZR ASG-Zara - Tape Management ZX ASG-OASIS - OASIS Variables and Audit

WP ASG-WP - Workload Planner (BETA 44) WA ASG-WA - Workload Analyzer (BETA 45)

X EXIT - Return to previous menu

Enter END command to return to the previous menu.


60

4 Enter the subsystem you want to access in the OASIS Subsystem field. The default subsystem is SSSI.

5 Press Enter.

The ASG-Zeke Primary Menu is displayed.

6 From this menu, select any of the online functions by entering the option number on the Option line and pressing Enter.

ASG-Zeke ASG-Zeke Primary Menu Z540A000 Option ===>

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

Copyright (C) 2007 Allen Systems Group, Inc. All rights reserved.


61

To log off the Zeke ISPF online system

1 From the ASG-Zeke Primary Menu, enter X on the Option line.

2 Press Enter.

The ISPF Main Menu is displayed.

Note:If you have Zack installed, the Automation (Fastpath Tables Maintenance) option provides a quick way to manage Zack Fastpath and Autoreply tables directly from Zeke. If Zack is active, the option takes you directly to the Zack Fastpath Table Maintenance function. You are presented a directory listing of table names, types (message/reply/dataset), and statistics. You can then add, browse, copy, delete, or edit a specific table. Refer to your Zack documentation for more information on Fastpath tables.

ASG-Zeke ASG-Zeke Primary Menu Z540A000 Option ===>

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

Copyright (C) 2007 Allen Systems Group, Inc. All rights reserved.


62

63

3Chapter 3:Calendars

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

Topic Page

Calendar Types 64

Accessing the Calendar Facility 65

Standard Calendars 67

Special Calendars 69

User Accounting Calendars 70

Calendar Documentation 72Maintaining Scratch Pad or Note Documentation 73Maintaining Text Documentation 74


64

Calendar TypesThere are three types of calendars.

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

Note:If a calendar is set up for a specific year and begins processing on the first day or week of the year, you must also set up a calendar for the previous year for Zeke to reference when determining the previous workday. The same is true for a calendar processing on the last day or week of the year. You must set up a calendar for the next year for Zeke to reference.

Calendar Description

Standard Defines normal workdays and holidays.

Special Defines the exact days an event is to run; a special calendar is used only when an event has truly random run dates.

User accounting Defines normal workdays, holidays, and establish accounting periods.

3 Calendars

65

Accessing the Calendar FacilityTo access the calendar facility

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

2 Press Enter. The Calendar Directory is displayed.

ASG-Zeke Calendar Selection Criteria Command ===> Calendar ID==> Year==> Type==> Primary commands: ADD BROWSE COPY DELETE EDIT DOCUMENT Enter SELECTION MASK in any field to be compared for selection. Clear any field that is not to be used for selection. * - is a prefix/suffix indicator. ? - is a wild/place holder character. * SELECTION FIELD MASKS * Calendar ID => Calendar Type => STD- Standard SPC- Special USR- User Date Range => - (MM/DD/YYYY) or (DD/MM/YYYY)

ASG-Zeke Calendar Directory Row 1 to 3 of 3 Command ===> Scroll ==> PAGE Calendar id==> Year==> Type==> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: E Edit B Browse C Copy D Delete O dOcument Calendar Workdays Start End Last Name Year Type MTWTFSS Date Date Used A **** STD YYYYYNN 01/20/2007 ACCTG1 2007 USR YYYYYNN 01/01/2007 06/30/2007 USER1 2007 SPC N/A 01/01/2007 12/31/2007 ******************************Bottom of data*******************************


66

3 Perform the steps in the Action column, depending on the desired result.

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

Desired Result Action

Add a new calendar Make the following entries:

1 Enter ADD on the Command line.

2 Enter the new calendar ID.

3 Enter the year the calendar covers.

Note:For standard and special calendars, you can enter **** to indicate a generic year. User Accounting calendars require a specific year.

4 Enter the calendar type and press Enter.

Type Description

STD Standard calendar

SPC Special calendar

USR User accounting calendar

Update an existing calendar

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

Delete an existing calendar

Move the cursor to the unlabeled Selection field to the left of the calendar you want to update and enter D. The Calendar Maintenance Functions screen is displayed, showing the calendar. Enter DEL and press Enter to confirm the deletion. This procedure is complete.

3 Calendars

67

Standard CalendarsStandard 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. The default Calendar A that is installed with Zeke is a standard calendar that can be updated to accommodate your normal schedule. You can define as many standard calendars, each with different workdays and holidays, as you need.

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

To maintain a standard calendar

1 Access the Calendar Maintenance Functions screen as instructed in “Accessing the Calendar Facility” on page 65.

Calendar A Workdays Monday through Friday

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

Calendar B Workdays Monday through Saturday

Holidays None

ASG-Zeke Calendar Maintenance Functions EDIT Command ===> Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT Calendar ID==> A Year==> **** Type==> STD ** Work Days ** ********************* Holidays **************** ** MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY Monday: YES Tuesday: YES Wednesday: YES Thursday: YES Friday: YES Saturday: NO Sunday: NO Fiscal start month: 01 Calendar expire date: Date last accessed: 01/20/2007 Calendar start date: Calendar end date :


68

Note:On the screen, it appears that the Work Days and Holidays are related. They are not. In other words, Monday holidays do not have to be entered on the first line, Tuesday on the second, etc.

2 The default workdays are Monday through Friday, and weekends are Saturday and Sunday. There are no default holidays. You update the Work Days portion of the screen if your workdays are different from the default days. Use the New Line key to access each of the workday fields. For each day of the week, enter YES if it is a workday; enter NO if it is not a workday.

3 To update the Holidays portion of the screen, enter the date 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, so a single calendar can span several years.

4 Press Enter to save your changes.

3 Calendars

69

Special CalendarsA special calendar is used for jobs with random scheduling dates, when no other type of calendar and no OCCURS clause can be used to describe the schedule. The job is still associated with a standard calendar as well. The OCCURS clause indicates the special calendar to use. To schedule an event on every selected date on the special calendar:

OCCURS (CALENDAR CAL1 AND DAILY)

You can use one special calendar for several jobs, then use keywords to specify dates in the OCCURS clause. To schedule an event on selected dates that fall on Monday.

OCCURS (CALENDAR CAL1 AND MONDAY)

To maintain a special calendar


2 Enter an asterisk (*) on the days you want the job to be scheduled. The days are listed across the screen and the months are listed down the left-hand column to create a matrix of dates.

To deselect a date where an asterisk has been entered, replace the asterisk with a period (.).

3 Press Enter to save your changes.

ASG-Zeke Calendar Maintenance Functions BROWSE COMMAND ===> Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT ZEKE Calendar ID==> USER1 Year==> 2007 Type==> SPC 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 January . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . February . . . . . . . . . . . . . . . . . . . . . . . . . . . . . March . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . April . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . May . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . June . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . July . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . August . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . September . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . October . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . November . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . December * * * * * * * * * * * * * . . . . . . . . . . . . . . . . . . Calendar Expire Date: Date Last Accessed: Calendar Start Date: 01/01/2007 Calendar End Date: 12/31/2007


70

User Accounting CalendarsYou set up user accounting calendars to match the days in your accounting periods. In this way, you can schedule jobs based on your company accounting schedule.

An event is tied to a user accounting calendar with the Calid field, just as with a standard calendar. When you specify a user accounting calendar, keywords refer to periods instead of months. You must also use the OCCURS clause keyword PERIODS instead of MONTHS for jobs that use a user accounting calendar.

For example, for the last Monday in period 2:

MONDAY.L AND PERIOD.2

To maintain a user accounting calendar


2 On the screen, it appears that the Work Days and Holidays are related. They are not. In other words, Monday holidays do not have to be entered on the first line, Tuesday on the second, etc.The default workdays are Monday through Friday and weekends are Saturday and Sunday. There are no default holidays. You update the Work Days portion of the screen, if your workdays are different from the default days. Use the New Line key to access each of the workday fields. For each day of the week, enter YES if it is a workday; enter NO if it is not a workday.

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

ASG-Zeke Calendar Maintenance Functions BROWSE Command ===> Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT PERIODS Calendar ID==> ACCTG1 Year==> 2007 Type==> USR ** Work Days ** ********************* Holidays **************** ** MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY MM/DD/YYYY Monday: YES Tuesday: YES Wednesday: YES Thursday: YES Friday: YES Saturday: NO Sunday: NO Calendar expire date: Date last accessed: Calendar start date: 01/01/2007 Calendar end date : 06/30/2007

3 Calendars

71

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

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

6 Enter the number of days in each period. Each period can have any number of days from 1 up to and including 90. 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 2 periods of each quarter and 35 to the last period of each quarter, and is useful if your company uses this accounting scheme.

7 If there are extra days between the end of this fiscal year and the start of the next one, enter that number in the Number of Slack Days field. If slack days are needed and are not entered, an error occurs when the SCHEDULE function is run.

ASG-Zeke User Calendar Periods BROWSE COMMAND ===> Primary Commands: BROWSE CANCEL EDIT Calendar start date: 01/01/2007 Calendar end date : 06/30/2007 ZEKE Calendar ID==> ACCTG1 Year==> 2007 Type==> USR Period 01: 28 Period 02: 28 Period 03: 35 Period 04: 28 Period 05: 28 Period 06: 35 Period 07: Period 08: Period 09: Period 10: Period 11: Period 12: Period 13: Period 14: Period 15: Period 16: Period 17: Period 18: Period 19: Period 20: Period 21: Period 22: Period 23: Period 24: Number of slack days between periods: Enter number of days (01-90) in each period and number of slack days (00-40)


72

Calendar DocumentationThe Calendar facility allows you to store and maintain calendar-related documentation. There are three types of calendar documentation that can be stored.

To access calendar documentation

1 From the Zeke Primary Menu, enter 3 and press Enter.Access the Calendar Maintenance Functions screen as instructed in “Accessing the Calendar Facility” on page 65.

2 Enter DOCUMENT on the Command line and press Enter. The Documentation Segments screen is displayed. If an asterisk (*) is displayed to the left of the documentation type, that type of documentation exists for the calendar.

3 Enter one of the following codes on the Command line to select the type of documentation you want to add or update:

Type Description

Scratch

Note

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

Text Stores up to approximately 450 records

ASG-Zeke Documentation Segments Option ===> Primary Command: DELETE Calid: A Year: **** Type: STD Sdate: Edate: Documentation Record Selection Options 1 SCRATCH Scratch pad 2 * TEXT Text information 3 NOTE Note pad information


Access scratch pad documentation

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

3 Calendars

73

Maintaining Scratch Pad or Note DocumentationEven though there are separate documentation areas for scratch pad and note information, the screens are identical. This procedure shows the scratch pad as an example, but the note screen works the same way.

To maintain scratch pad or note documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in “Calendar Documentation” on page 72.

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

3 Press Enter to update the data.

Access text documentation

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

Access note documentation


ASG-Zeke Documentation Scratch Pad EDITCommand ==> Primary Commands: BROWSE CANCEL DELETE EDIT Line 1 USE THIS CALENDAR FOR ALL LEVEL 4 JOBS AND 2 FOR SPECIAL LEVEL 3 JOBS. 3 4 5 6 7 8 9 10 Calendar id : B Calendar year : **** Calendar type : STD Workdays : YYYYNNY Start date : End date :



74

Maintaining Text DocumentationThe text documentation area allows you to define a sizeable amount of information for a calendar (up to approximately 450 records).

To maintain text documentation

1 Access the Text Documentation screen as instructed in “Calendar Documentation” on page 72.

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

3 Use standard ISPF editing commands to edit the text.

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


ASG-Zeke Text Documentation EDIT Command ===> Columns 000 000 Scroll ===> PAGE Calid: A Year: **** Type: STD Sdate: Edate: ****** *************************** Top of Data *****************************==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 SVP OR HIGHER SIGNATURE REQUIRED TO AUTHORIZE CHANGING THIS CALENDAR ****** ************************** Bottom of Data ***************************

75

4Chapter 4:Events

An event is a unit of work, such as a batch process, program, or command, defined to Zeke and scheduled to occur under a given set of circumstances. Information about the event is gathered to create an event master record (EMR). The EMR includes the date and time to dispatch the event, prerequisite conditions for dispatch, and resource requirements.

Topic Page

Defining Events 77Event Types 77Primary Commands 78Accessing the Event Master Record 82Defining an Event Template 86Creating an Event From a Template 88Copying an Event 90Maintaining a Job Event 92Routing a Job Event to Another System or Platform 98Downloading Jobs to Zeke Agent 102Maintaining a Message Event 104Maintaining Command Events 107Maintaining a REXX Event 111Defining a Recurring or Permanent Event 114

OCCURS Clauses 118OCCURS Clause Format 118Sample OCCURS Clauses 126Scheduling Events on Holidays and Weekends 130Defining an OCCURS Clause 132

WHEN Conditions 135Job and Program WHEN Conditions 135WHEN Conditions for Multiple Event Versions 135Extended Dependencies 136WEAK Conditions 137Started Tasks 138Generic Names 138Multiple WHEN Conditions 139Zeke Variables as WHEN Conditions 140NOTDURING Conditions 142Cross-platform Dependencies 144


76

WHEN Condition Keywords 145Defining a WHEN Condition 150Viewing WHEN Conditions for All Event Versions 151

Condition Codes 154

Work Centers 161Variables in Work Centers 161Setting Up Work Centers 163Completing Work Centers 166

Auto Replies 171Maintaining Auto Replies 172Displaying, Enabling, or Disabling Auto Replies 175

Maintaining JCL 176Setting JCL Source Options 176Retrieving JCL from the Zeke Database 179

Event Documentation 181Accessing Event Documentation 181Maintaining Scratch Pad or Note Documentation 184Maintaining Text Documentation 185Maintaining Dataset Documentation 186

Event Activity Accounting 188

Topic Page

4 Events

77

Defining EventsAn event can be defined to the Zeke database through either of the following facilities:

• Event Master Record Functions screens in the Zeke online facility

• EVENT function of the Zeke batch utility program

This chapter describes the procedures, as performed using the online facility. For information on performing the same procedures using the Zeke batch utility, refer to your ASG-Zeke for z/OS Reference Guide.

Event TypesThe Zeke event types include:

This section explains how to define and maintain the different types of events.

Type Description

JOB Jobstream event

MSG Console operator message event

WORK Work center event

VCOM VM CP command event

ZCOM Zeke operator command event

SCOM System command or system response event

PCOM POWER command event

REXX REXX exec


78

Primary CommandsThe following commands are available from most of the Event Master Definitions screens. Uppercase letters indicate each command’s abbreviation.

Command Description

ADD Add an event.

AUTorply Maintain autoreply elements for job events.

BROwse Browse an event.

CCode Maintain condition code information for job events.

COPY Copy event information to a new event number.

The Event Master Definitions screen is displayed and you are prompted for the new event number.

COPYAll Copy all associated event master information.

DEACt Deactivate an event. The event is not scheduled.

DELete Delete an event from the database. The Event Master Definitions screen is displayed and you are prompted to confirm the deletion by entering the DELETE command again.

Note:You can delete an event definition only if there are no existing schedule records based on the definition. Otherwise, the existing schedule records must be deleted first.

DOCument Define or maintain event documentation.

EDIT Edit an event.

JCL Display JCL stored in the Zeke database.

OCCurs Maintain the OCCURS clause for this event.

4 Events

79

PATH View the predecessors and successors of this event.

Note:The DSPIndex generation option must be set to Y in order to use the PATH command.

Optional keywords include:

LEVel Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all.

OCCDate Julian date to use when the OCCURS clause is resolved. Default is the current date.

VERsion Version of the event for which to view predecessor/successor information.

PATH VER 3

Default is 0 if the Verload generation option is set to 0. Otherwise, the default is 1.

PATHADD Invoke the Schedule View Add-By Path wizard. The event, level, OCCURS date, version, and path type are auto-filled. Allows you to list predecessors and successors for an event and then schedule events in the list.

Note:The DSPIndex generation option must be set to Y in order to use the PATHADD command.




PATH VER 3


Command Description


80

PREd View the predecessors of this event.

Note:The DSPIndex generation option must be set to Y in order to use the PRED command.




PATH VER 3


PREDADD Invoke the Schedule View Add-By Path wizard. (The event, level, OCCURS date, version, and path type are auto-filled.) Allows you to list predecessors for an event and then schedule events in the list.

Note:The DSPIndex generation option must be set to Y in order to use the PREDADD command.




PATH VER 3


REACt Reactivate an EMR that was previously deactivated.

RESOurce Maintain logical resource control information for job events.

RESTart Request the restart facility (such as Zebb) for this job event.

Command Description

4 Events

81

SUcc View the successors of this event.

Note:The DSPIndex generation option must be set to Y in order to use the SUCC command.

LEVEL Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all.

OCCDATE Julian date to use when the OCCURS clause is resolved. Default is the current date.


PATH VER 3


SUCCADD Invoke the Schedule View Add-By Path wizard. The event, level, OCCURS date, version, and path type are auto-filled. Allows you to list successors for an event and then schedule events in the list.

Note:The DSPIndex generation option must be set to Y in order to use the SUCCADD command.

LEVEL Limit the path to display this level of depth. Valid values are 1 to 999, or an asterisk (*) to indicate all levels. Default is all.

OCCDATE Julian date to use when the OCCURS clause is resolved. Default is the current date.


PATH VER 3


WHEN Maintain the WHEN conditions for this event. To maintain the dependency for a particular version of the event, enter WHEN followed by the version number (for example, WHEN 2). If you do not enter a version number, it defaults to first version.

Enter WHEN followed by an asterisk (WHEN *) to display the different versions of WHEN conditions associated with the event.

Command Description


82

Accessing the Event Master RecordThe Event Master Record Functions screens are used to define or update any type of event, and to access documentation, JCL, auto replies, resources, condition codes, and WHEN conditions for an event.

To access the Event Master Record Definitions screens

1 From the Zeke Primary Menu, enter 1 and press Enter.

The Event Master Selection Criteria screen is displayed.


ASG-Zeke Event Master Selection CriteriaCommand ===>

Event ===>

Primary Commands: ADD BROWSE DELETE EDIT

Place any character other than Enter a selection mask in any field(s)a space next to Event Types to to be compared for selection.be selected. * - is a prefix/suffix indicator. ? - is a wild/place holder character.

Event Types Selection Field Masks Job: Job Name: Msg: Event Name: Pcom: Application: Work: Group ID: Vcom: User ID: Zcom: Drl ID: Scom: System: REXX: Calendar ID: Occurs: Template: When: Permanent:


Define a new event If you want to add a new event, enter ADD on the Command line and press Enter. Go to step 3.

Update an existing event for which you know the event number

Enter EDIT on the Command line. Enter the event number in the Event field. Press Enter.

The Event Master Definition screen for the selected event is displayed.

Perform the appropriate update procedure for the event type you are updating.

4 Events

83

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

4 In the Use Template field, enter N and press Enter. (For information on using a template, see “Creating an Event From a Template” on page 88.)

The Event Master Definition screen for the selected event type is displayed.

5 Depending on the type of event you are adding, go to the appropriate procedure.

Update an existing event, for which you do not know the event number

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

View a list of existing templates for a specific event type

Enter Y in the Template field and next to the desired event type. Press Enter.

The Event Master Directory is displayed.

Update the documentation, JCL, autoreply, resource, condition codes, or dependency information for an event

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

ASG-Zeke Add Event Record Function Option ===> Use Template: Y Template 1 Job Add a Job Event JCLTEMPLATE 2 Msg Add a Message Event MSGTEMPLATE 3 Pcom Add a Pcom Event PCOMTEMPLATE 4 Work Add a Work Center Event WORKTEMPLATE 5 Vcom Add a Vcom Event VCOMTEMPLATE 6 Zcom Add a Zcom Event ZCOMTEMPLATE 7 Scom Add a Scom Event SCOMTEMPLATE 8 REXX Add a REXX Event REXXTEMPLATE Press PF3/PF15 key to abort the Add request

Event Type Procedure

Job “Maintaining a Job Event” on page 92

Msg “Maintaining a Message Event” on page 104

PCOM, VCOM, ZCOM, SCOM “Maintaining Command Events” on page 107

Work “Setting Up Work Centers” on page 163



84

The Event Master Directory screen is displayed.

An asterisk in one of the columns at the right side of the screen indicates that a record of that type exists for this event. For example, an asterisk in the Cond Codes column indicates that condition code information exists for this event.

6 Perform the steps in the Action column in the following table, depending on the desired result.

REXX “Maintaining a REXX Event” on page 111

ASG-Zeke Event Master Directory Command ===> Scroll ===> PAGE Primary Commands: ADD Line Commands: E/En - Edit B/Bn - Browse D/Dn - Delete n = 1 through 7 for the specific part of Event as listed below. 1 2 3 4 5 6 7 Event Event Jobname Evt DOC JCL Auto Rsrc Cond Occ Whn Number Name Type Repl Codes ========================================================================== 000001 ZEKE51TST1 MSG * * 000002 ZEKE51TST2 MSG * * 000003 ZEKE51TST3 MSG * * 000004 ZEKE51TST4 MSG * * 000005 ZEKE51TST5 MSG * * 000006 ZEKE51TST6 TSKKGUT1 JOB * * * * 000007 ZEKE51TST7 TSKKGUT2 JOB * * * * 000008 ZEKE51TST8 TSKKGUT3 JOB * * * 000009 ZEKE51TST9 TSKKGUT4 JOB * * * 000010 ZEKE51TST10 TSKKGUT5 JOB * * * 000011 ZEKE51CC SPTEXD11 JOB * * * * 000012 ZEKE51CC SPTEXD12 JOB * * * * 000013 WORK * * 000014 VCOM *


Update the EMR Enter E in the unlabeled Selection field to the left of the event you want to update, and press Enter.

The Event Master Definition screen for the selected event is displayed. Perform the appropriate update procedure for the event type you are updating.

Delete the EMR Enter D in the unlabeled Selection field to the left of the event you want to update, and press Enter.

The Event Master Definition screen for the selected event is displayed. Press Enter to confirm the deletion. This procedure is complete.

Event Type Procedure

4 Events

85

Update the documentation for an event

Enter E1 in the unlabeled Selection field to the left of the event you want to update, and press Enter.

Go to “Event Documentation” on page 181.

Update the online JCL for an event


Go to “Maintaining JCL” on page 176.

Update the auto reply segments for an event


Go to “Maintaining Auto Replies” on page 172.

Update the logical resources for an event


Go to “Maintaining Logical Resources” on page 274.

Update the condition codes for an event


Go to “Condition Codes” on page 154.

Update the OCCURS clause for an event


Go to “Defining an OCCURS Clause” on page 132.

Update the WHEN conditions for an event


Go to “Defining a WHEN Condition” on page 150.



86

Defining an Event TemplateEvents that are in the same cycle are often defined with similar event information. Event templates eliminate the repetitive task of defining the same information over and over for multiple event records.

An event template is used as a model when creating new events of a particular event type (such as job events). When you create an event from a template, all of the template’s information is copied over to the new event — including documentation, JCL, OCCURS clause, WHEN conditions, etc. A template is basically a normal event, except that it can never be scheduled.

To create a certain type of event from a template, you must use a template of that type. For example, you cannot use a job event template to create a work center event. Zeke does not limit the number of templates that can be defined for each event type. Each user can define their own set of template names.

To define an event template

1 Access the Event Master Record Functions screen for the type of event you want to define a template for (such as job events) as instructed in the procedure, “Accessing the Event Master Record” on page 82.

2 Enter an event name for the template. The event name is the identifier that will be used for selecting a template to create a new event.

3 Continue to define the event as described earlier. Define all the fields that you want each new event created from this template to share.

ASG-Zeke Event Master Definition EDIT Command ===> Event===> Primary Commands: 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: MVSEvt: 243 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK51RJEABC App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: AControl: Y Tapes: 000 Avgdur: 00:00:00 Job: TSKKGUT1 Class: Pri: JCL--> PDS: Member: CMS: Ftype: Zeke JCL (Y=Yes): Y

4 Events

87

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

5 Press Enter.

The changes are saved and an event number is assigned.

6 Optionally, deactivate the event template using the DEACT command. It is not necessary to deactivate a template, because templates are never scheduled. However, we recommend that you perform this step so that new events created from the template are not scheduled until you activate them.

7 If you want each new event created from this template to share the same OCCURS clause, perform the procedure, “Defining an OCCURS Clause” on page 132.

8 If you want each new event created from this template to share the same WHEN conditions, perform the procedure, “Defining a WHEN Condition” on page 150.


88

Creating an Event From a TemplateTo create a certain type of event from a template, you must use a template of that type. For example, you cannot use a job event template to create a work center. An unlimited number of templates can be defined for each event type. See “Defining an Event Template” on page 86 for more information on event templates.

To create an event from an existing event template

1 Access the Add Event Record Function screen as instructed in “Accessing the Event Master Record” on page 82.

2 In the Use Template field, enter Y to indicate that you want to create the new event from an existing event template. Tab to the Template field for the type of event you want to define and type the event name of the template you want to use. Enter the option for the type of event you want to define.

To view a list of existing templates for a specific event type, go to the Event Master Record Functions—Browse screen (see “Accessing the Event Master Record” on page 82) and enter Y in the Template field and next to the desired event type.

Note:If you have more than one template defined with the same name and the same event type, Zeke will use the template with the lowest event number. For example, if you have a job event template called JOBTEMPLATE that was assigned event number 12, and another job event template called JOBTEMPLATE that was assigned event number 34, Zeke will use the template with the event number 12.

ASG-Zeke Add Event Record Function Option ===> Use Template: Y Template 1 Job Add a Job Event JCLTEMPLATE 2 Msg Add a Message Event MSGTEMPLATE 3 Pcom Add a Pcom Event PCOMTEMPLATE 4 Work Add a Work Center Event WORKTEMPLATE 5 Vcom Add a Vcom Event VCOMTEMPLATE 6 Zcom Add a Zcom Event ZCOMTEMPLATE 7 Scom Add a Scom Event SCOMTEMPLATE 8 REXX Add a REXX Event REXXTEMPLATE Press PF3/PF15 key to abort the Add request

4 Events

89

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

All the information that was defined in the template is copied over to the new event, with the exception that the Template field is changed to N.

3 Update the information as necessary. We recommend that you change the event name from the original template name to a new name. This will make it easier to distinguish between the template and the actual events created from that template.

4 Press Enter. The changes are saved and an event number is assigned.

5 If necessary, activate the event using the REACT command.

6 If necessary, perform the procedure, “Defining an OCCURS Clause” on page 132 to specify when the event should be added to the schedule.

7 If necessary, perform the procedure, “Defining a WHEN Condition” on page 150 to specify any prerequisites that must occur before the event can be dispatched.

ASG-Zeke Event Master Definition EDIT Command ===> Event===> Primary Commands: 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: MVSEvt: 243 Desc: SPECIAL RJE JOB FOR ABC Type: JOB Desc2: Event Name: ZK51RJEABC App: Grp: Usrid: DRL: System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp: Target: *LOCAL Verload: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: AControl: Y Tapes: 000 Avgdur: 00:00:00 Job: TSKKGUT1 Class: Pri: JCL--> PDS: Member: CMS: Ftype: Zeke JCL (Y=Yes): Y


90

Copying an EventIf you want to define an event that is similar to an existing event, and you do not have a template to create the event from, you can copy the existing event. If you will be creating a number of similar events, it is best to use a template.

To copy an event

1 Access the Event Master Definition screen, as instructed in “Accessing the Event Master Record” on page 82, for the event you want to copy.


3 The following message is displayed:

Z041I EVENT xxxxxx HAS BEEN COPIED TO EVENT yyyyyy

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

Caution! The original event that was copied is still displayed. You need to access the newly created event before you make any changes. Otherwise, you will inadvertently change the original event information.

ASG-Zeke Event Master Definition EDIT Command ===> Event===> Primary Commands: ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHENTemplate: N Permanent: N Milestone: N Platform: MVSEvt: 243 Desc: SPECIAL RJE JOB FOR ABCType: JOB Desc2:Event Name: ZK51RJEABC App: Grp: Usrid: DRL:System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp:Target: *LOCAL Verload: 00000Early: Sched: 00:00 Late: Mustend: Notafter:Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: AControl: Y Tapes: 000 Avgdur: 00:00:00 Job: TSKKGUT1 Class: Pri: JCL--> PDS: Member: CMS: Ftype: Zeke JCL (Y=Yes): Y


Copy the EMR, OCCURS, and dependency information

Enter COPY on the Command line.

Copy all the EMR data Enter COPYALL on the Command line.

4 Events

91

4 To access the new event:

a Press F3 to return to the Event Master Record Directory screen.

b Scroll down to the new event.

c Enter the E line command beside the event number. The Event Master Definition screen is redisplayed in Edit mode with the new EMR data.

d Edit the information as needed and press Enter to update the record.

Note:If you copied a template using this procedure, the Template flag was set to N. If you want the newly created event to be a template, set this flag to Y.


92

Maintaining a Job EventA job event, the most commonly-used event type, executes a specified jobstream.

To define or maintain a job event

1 Access the Event Master Definition screen for job events, as instructed in “Accessing the Event Master Record” on page 82.

2 Enter information in the following fields to define a job event.


Field Description

Desc/Desc2 User-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event.

Event Name Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. End-of-Event (EOE), abnormal-end-of-event (AEOE) and End of Group (EOG) WHEN conditions and operator commands use the event name.

Usrid Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs; be sure to enter the desired user ID in the correct case (upper, lower, or mixed).

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

4 Events

93

System System or pool that owns the event. An event is associated only with one system. This is the system the event is dispatched from, not necessarily the system the EMR is defined on.

Verload Number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load using the ZADD command (up to 32,767 versions).

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

Sched Normal schedule time for this event. The default is 00:00, which means this event is dispatched according to WHEN conditions instead of by time.

See "Specifying a Schedule Time" on page 96 for a detailed explanation of schedule time.

Control Code indicating whether this event is executed and tracked as a Zeke-controlled event.

Note:Zeke does not support multiple jobs per event. Each job should be placed in a separate event. Any additional jobs in the same event are considered non-Zeke jobs.

Code Meaning

Y (Default.) Zeke recognizes the event as a Zeke-controlled event. Zeke-controlled events are tracked throughout the entire execution.

N Zeke does not recognize this event as Zeke-controlled and marks the job as DONE upon dispatch.

Field Description


94

NX Zeke recognizes the event as a non-executable Zeke-controlled event. Non-executable events are scheduled like any other event, and are useful as predecessors to other events. A non-executable event is never submitted to JES for JCL execution. After dispatch, the event status automatically changes to indicate success and any dependent events are triggered.

Note:An event you want to remove from an intricate event flow can simply be marked as non-executable as an alternative to changing the event flow, which typically means having to delete the event and then modify the WHEN clauses for all of the deleted event’s successors.

Tapes Number of physical tape drives (0-255) the job requires. The event is dispatched when the specified number of drives is free. If it is time to dispatch and the drives are not free, Zeke informs the operator the event is waiting on drives.

Zeke can calculate this value automatically, or you can manually enter a value. You can also make an entry to override the calculated number, if desired. Default is zero.

If you leave this field at zero and tapes are required, operator intervention might be necessary the first time the job runs under Zeke control.

If the Calctap generation option is set to Yes, then Zeke automatically calculates this number based on the last time this job was run and displays the value with an asterisk to indicate it is Zeke-calculated (see “Calculating Tape Drive Usage” on page 305). If Calctap=Yes and you manually override the Zeke-calculated value, then Zeke will not calculate the tape value again until you reset the tape value to zero. To reset the tape value, enter three blank spaces in the Tape field.

Job Name of the job in the JCL. This name displays on screens and in messages and is used by Zeke to track the event during execution. This field must match the jobname on the job card for proper tracking.

Class Up to 6 classes for the event. When the event is ready to run, Zeke selects an initiator according to the class defined. If no class is specified, the value specified for the Defdspcl generation option is used. If Defdspcl is not defined, Zeke selects any free initiator defined to it. See “Defining Initiators to Zeke” on page 269. This field is valid only if the generation option Dispsel is set to Yes. Yes is the default for Dispsel.

Field Description

4 Events

95

3 Enter information in the following fields to group events for selection for reports or scheduling. Report Writer, Work Center Control, and Zeke operator commands use these fields to sort and select events

4 Press Enter.

The changes are saved and the screen is displayed in update mode. If you are adding the event, an event number is assigned.

5 Perform the procedure “Defining an OCCURS Clause” on page 132 to specify when the event should be added to the schedule.

6 Perform the procedure “Defining a WHEN Condition” on page 150 to specify any prerequisites that must occur before the event can be dispatched.

JCL JCL source library and member information.

Library Field Entries

Bim-Edit BIM—JCL source library

Member—BIM member name

Condor JCL source library and Condor version

Librarian JCL source library and Librarian member name

Panvalet JCL source library and Panvalet member name

PDS PDS member dataset DD name; must be present in the Zeke started task procedure

Member—PDS member name

CMS JCL source library and CMS file name

Ftype—CMS file type of the JCL file

Field Description

App User-assigned code to identify the application the event is a part of.

Grp User-assigned code to identify the group the event is a part of. This field is a subset of the application ID.

Field Description


96

Specifying a Schedule TimeSchedule time is an optional dispatching prerequisite that must be met before an event can be dispatched. The schedule time fields are Sched, Early, Late, Mustend, and Notafter. If the time the event is dispatched does not matter, leave these fields blank (00:00). However, if the event must be dispatched by a certain time or cannot be dispatched after a certain time, use the schedule times fields to place restrictions on the time of day an event can execute.

Note:For an explanation of Zeke’s 48-hour clock (known as DaySpan), which lets you schedule according to a logical day, see “Logical Day (48-hour Clock)” on page 192.

Use the following table to determine which schedule time fields, if any, your events need to use:


Schedule the event at a specific time

In the Sched field, enter the normal schedule time for this event.

If the time is greater than 24:00, Zeke knows the event is to be processed the next day. The default is 00:00, which means this event is scheduled according to WHEN conditions, instead of by time.

Set the earliest time an event can be dispatched

In the Early field, enter the earliest time this event can be dispatched. An event can be dispatched at its early time as long as the WHEN conditions are satisfied. However, the events are dispatched in schedule time sequence.

For example, an event is set up to run at 12:00 P.M., but can run as early as 11:00 A.M. if an initiator is available.

Note: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 and specify the group’s schedule time in the required order. The schedule command displays will be easier to read as a result. If the events are dispatched early, they are still processed in the correct order.

Set the time an event is considered late

In the Late field, enter the time the event is considered late if it has not been dispatched. If the late time is reached and the event is not dispatched, a message is issued to the operator.

For example, if an event is scheduled to run at 12:00 P.M. with a late time of 13:00, the event is considered late if it is not dispatched by 1:00 pm.

If the generation option Prilate is set to Y, late events are dispatched before events that are not late, regardless of the schedule time.

4 Events

97

Creating Multiple Versions of an EventEvents can be defined to have multiple SQRs with the same schedule date. These are referred to as versions of the event. An event can have up to 32,767 versions.

Each version of an event operates independently of all other versions of the same event. For instance, you can add a JCL override for one version without affecting other versions of the same event.

Each version of an event shares the same OCCURS clause, but can have different WHEN conditions defined for it. Zeke operator commands can select events by version number for processing, and WHEN conditions can trigger off of version numbers.

Multiple versions of the same event all have the same jobname; therefore, they cannot execute concurrently due to JES limitations. (Zeke provides a user exit, ZEKE02OX, to allow you to change the jobnames as events are added to the schedule. Refer to your ASG-Zeke for z/OS Installation Guide for more information on ZEKE02OX.)

You use the Verload field on the Event Master Definitions screen to define the number of versions for an event. Then, you can define WHEN conditions based on a specific version number for that event.

Set the time the event must complete processing by

Enter the latest time the event can complete processing in the Mustend field. Prior to dispatch, Zeke adds the current system time and the event’s average duration. If the result is greater than the Mustend time, a message is issued to the console and the event is removed from the dispatch queue.

For example, the Mustend time is 14:00, the system time is 13:00 and the average duration is 2 hours. Since the event would not complete until 15:00, the event is not dispatched.

Set the latest time an event can be dispatched

Enter the latest time an event can be dispatched in the Notafter field. Prior to dispatch, Zeke compares the system time and the Notafter time. If the Notafter time is less than the system time, the event is no longer time satisfied. Zeke issues a message to the console and removes the event from the dispatch queue.



98

Routing a Job Event to Another System or PlatformZeke can route or send the JCL for a job event to another system or platform for execution. When the job has finished executing, the data or information can be sent back to the original Zeke for triggering other events. For example, you can route JCL from one operating system to another, or from a z/OS system to an OS/400.

Zeke remote jobs support condition code processing (except if *Rmtlim is specified, see below) as well as logical resource usage. All trigger types are supported except dataset name and variable name, and all accounting information is updated in the EMR. Auto replies are not supported for remote jobs and NOTDURING conditions that reference remote jobs are not supported.

To route a job to another system or platform, enter Target and Platform information on the EMR screen. Generally, the system programmer sets up the Posid and Netregid generation options.

To route a job event to another system or platform

1 Ensure that the Posid and Netregid generation options for your system are properly set-up with Posid=Y and a valid, non-blank Netregid. See "Maintaining Networking Options" on page 307.

2 Access the Event Master Record Functions—Job Events screen as instructed in the procedure,“Accessing the Event Master Record” on page 82.

3 Enter the information indicated in “Maintaining a Job Event” on page 92.


4 Events

99

Note:If the remote system is using security, the Usrid field must be defined as a valid user ID on the remote system.

4 Enter the routing information in the following fields.

Field Description

Target Enter a value to indicate how to handle routing.

Note:Although the Target field appears in the Event Master Definition screen for all events, it currently applies to job events only. The target field defaults to *LOCAL for all other event types.

Code Meaning

Remote system DMS logical name

Remote Zeke or Zeke Agent Netregid.

This is the only type of remote processing where the dispatching and execution platform can be different.

Zeke dispatches individual jobs to DMS, which routes them to the specified system, where they are submitted and monitored. The level of communication between the dispatching Zeke and the remote job is based on the job’s condition code processing requirements.

If the specified system is a Zeke Agent defined as a download agent, then SQRs are downloaded via DMS, where they are tracked and executed. See “Defining Schedule Download Agents” on page 301.

*R or *REMOTE The job instructions must contain the necessary NJE statements or parameters to route the job. Zeke dispatches and submits the job on the same system. Then NJE routes the job to the remote system for monitoring. The level of communication between the dispatching Zeke and the remote job is based on the job’s condition code processing requirements.


100

*RL or *RMTLIM Similar to *REMOTE. Zeke dispatches and submits the job on the same system. Then NJE routes the job to the remote system. The remote job sends all trigger information back to the dispatching Zeke, but executes independently. The dispatching Zeke monitors the remote job execution, but maintains no control over it. This type of remote job cannot be cancelled due to condition code processing.

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

Note:Values of *REMOTE, *RMTFUL, and *RMTLIM can only be used when the JOB is being routed to another system of the same platform as the dispatching system. If attempting to route from a z/OS system to a VSE, AIX, or OS/400 system, you must use a Netregid for the Target value. If routing to a like platform, for example, one VSE system to another VSE system, either the Netregid or *REMOTE values can be used for 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 will lock and you will have to press Reset and then the Tab key to continue.

Field Description

4 Events

101

5 Press Enter.


6 Press Enter.


Platform Indicate the operating system on which the event is executed. Zeke defaults to the value of the generation option Defpltfm. Valid values are:

AIX

DCOSX Pyramid.

HPUX

MVS Includes z/OS.

OS2

OS400

SUN

TANDEM

USYS

UNIX Includes all UNIX platforms: AIX, AT&T, HPUX, NCR, SCO, SunOS, Sun Solaris, etc.

VMS

VSE

WINDOWS Includes all supported versions.

Note:Although the AIX, HPUX, and SUN platform codes listed above are supported, it is preferred that you use the UNIX platform code. Zeke does not download jobs that have a platform of MVS or VSE.

Field Description


102

7 Perform the procedure, “Defining an OCCURS Clause” on page 132, to specify when the event should be added to the schedule.

8 Perform the procedure, “Defining a WHEN Condition” on page 150, to specify any prerequisites that must occur before the event can be dispatched.

Downloading Jobs to Zeke AgentZeke allows you to download a subset of scheduled jobs in the Zeke schedule cross-platform to Zeke Agent. Zeke Agent then tracks and dispatches the SQRs in the same manner as Zeke would. 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 can also schedule an individual event directly to a Zeke Agent system running on another platform. Zeke Agent can receive, track, schedule, execute, and re-route a scheduled job from Zeke (or another source) to another platform in your enterprise, as necessary.

To download a job event to Zeke Agent

1 Ensure that the Posid and Netregid generation options for your system are properly set-up with Posid=Y and a valid, non-blank Netregid. See "Maintaining Networking Options" on page 307.

2 Access the Event Master Record Functions—Job Events screen as instructed in the procedure,“Accessing the Event Master Record” on page 82.


4 Events

103

3 Enter the information indicated in “Maintaining a Job Event” on page 92.

Note:If the remote system is using security, the Usrid field must be defined as a valid user ID on the remote system.

4 Enter information about the Zeke Agent in the following fields.

5 Press Enter.




Field Description

Target Remote Zeke Agent Netregid.

Be sure the specified system is a Zeke Agent system defined as a download agent. See “Defining Schedule Download Agents” on page 301.

Platform Operating system of the Zeke Agent system on which the event is to be downloaded. Defaults to the value of generation option Defpltfm. Enter UNIX.


104

Maintaining a Message EventA message event can be any message you want to issue to the system console. Many sites have certain consoles set up to receive certain messages. For example, the console for tape mounting only receives messages with route code=3, and the printer console only receives messages with route code=7. All messages and route codes are logged to the SYSLOG hardcopy file, regardless of the console that received them.

For example, if you want the tape mount console operator to send a certain tape offsite after a job is complete, you would set up a message event with a route code=3 and the following message:

Send tape offsite; dependent on good EOJ of the job.

You could also 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.

To define or maintain a message event

1 Access the Event Master Definition screen for message events as instructed in “Accessing the Event Master Record” on page 82.

ASG-Zeke Event Master Definition BROWSE Command ===> Event===> Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT OCCURS PATH PRED REACT RESOURCE SUCC WHEN Template: N Permanent: N Milestone: NEvt: 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: 00004 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: AControl: Y Route: (3) Oper Msg1: END TAPE OFFSITE; DEPENDENT ON GOOD END OF JOB Oper Msg2: Oper Msg3: Oper Msg4: Oper Msg5: Oper Msg6:

4 Events

105

2 Enter the appropriate information in the following fields to define a message event.

Field Description

Template If you are defining a template, enter Y in this field. Otherwise, leave the default N.


Event Name Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. EOE, AEOE, and End of Group (EOG) WHEN conditions, and operator commands use the event name. If you are creating this event from a template, change this name to differ from the template.

Usrid Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs. Be sure to enter the desired user ID in the correct case (upper, lower, or mixed).

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

System System or pool that owns the event. An event is associated with one system only. This is the system the event is dispatched from, not necessarily the system the EMR is defined on.


See “Creating Multiple Versions of an Event” on page 97 for more information.



106

3 Enter information in the following fields to group events for reports or scheduling. The Report Writer, Work Center Control, and Zeke operator commands use these fields to sort and select events.

4 Press Enter.


5 Perform the procedure, “Defining an OCCURS Clause” on page 132 to specify when the event should be added to the schedule.

6 Perform the procedure, “Defining a WHEN Condition” on page 150 to specify any prerequisites that must occur before the event can be dispatched.

Sched Normal schedule time for this event. The default is 00:00, which means this message is issued according to WHEN conditions instead of by time.

Route User-assigned route code that corresponds to the alternate console route code.

Oper Msg Message text to issue to the system operator console. The message event can contain up to 6 lines.

Field Description


Grp User-assigned code to identify the group the event is a part of.

Field Description

4 Events

107

Maintaining Command EventsCommand events issue specified commands to a specified destination. Several types of command events are available with Zeke.

SCOM events can issue any type of console command, and can be used instead of the other command event types (ZCOM, PCOM, and VCOM), which can only issue specific types of commands. This procedure describes how to define an SCOM event. If you choose to use the other types of command events, you define them in a similar manner.

Command Type Description

SCOM Any command that can be issued from a console. You can enter an unlimited number of commands within each SCOM event.

A security call will be made for each individual command line in an SCOM. See “Security Calls” on page 365 for more information.

ZCOM Any valid Zeke operator command or combination of commands.

PCOM Any valid POWER command for VSE systems.

VCOM Any valid VM CP command.


108

To define and maintain a system command event

1 Access the Event Master Definition—SCOM screen as instructed in “Accessing the Event Master Record” on page 82.

2 Enter the appropriate information in the following fields to define an SCOM event.

ASG-Zeke Event Master Definition BROWSE Command ===> Event===> Primary Commands: ADD BACK BROWSE COPY COPYALL DEACT DELETE DOC EDIT NEXT OCCURS PATH PRED REACT RESOURCE SUCC TOPPAGE WHEN Template: N Permanent: N Milestone: NEvt: 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: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: AControl: Y Code => C=Sys Cmd R=Sys Response Z=Zeke Cmd V=VM Cmd P=VSE/POWER Cmd __ Code: C 001 D T __ Code: C 002 $DI __ Code: Z 003 ZINFO __ Code: Z 001 ZADD EV 27 VER 1 REBUILD __ Code: Z 002 ZADD EV 28 VER 1 REBUILD __ Code: Z 003 ZADD EV 28 VER 2 REBUILD __ Code: Z 004 ZADD EV 29 VER 1 REBUILD

Field Description



Event Name Name of the event. This name is displayed on other Zeke screens and printed on reports to help users identify the event. EOE, AEOE and End of Group (EOG) WHEN conditions and operator commands use the event name. If you are creating this event from a template, change this name to differ from the template.

Usrid Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs; be sure to enter the desired user ID in the correct case (upper, lower, or mixed).

Note:This user ID applies to Zeke internal security only.

4 Events

109

System System or pool that owns the event. An event is associated only with one system or pool. This is the system the event is dispatched from, not necessarily the system the EMR is defined on.

Verload Number of versions of this event to be loaded during the schedule build. For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load by using the ZADD command (up to 32,767 versions).



Sched Normal schedule time for this event. The default is 00:00, which means this command is issued according to WHEN conditions instead of by time.

Code Code indicating the type of command:

Code Meaning

C System command

R System response

Z Zeke command

V VM command

P VSE/POWER command

Field Description


110

3 Enter information in the following fields to group events for reports or scheduling. Report Writer, Work Center Control, and Zeke operator commands use these fields to sort and select events.

4 Press Enter.




Line 001 through Line 005

Up to 60 characters of commands or responses per line. Only the first line is required. To access additional command lines, position the cursor on any SCOM line except the first one and press Enter. The screen is redisplayed with new blank lines. Existing SCOM lines following the cursor are not displayed. Enter as many new lines as necessary and press Enter. The new lines are added to the EMR and the existing lines are redisplayed.

When entering multiple Zeke commands on one line, include the command prefix on the first command only. For example, if your command prefix is ASG, you would code multiple commands in an SCOM event like this:

C 001 ASGZAD EV 12 HOLD ZAD EV 89 HOLD

When using variable substitution in an SCOM event, the length of each line must be no greater than 60 bytes, including the variable values. For example, suppose you submit the following SEND command from an SCOM event:

SE ‘THIS IS A TEST TEST TEST TEST TEST.’,USER=($ABCVAR)

Assume the value of the variable $ABCVAR equals ABCABCABCABCABC. The length of the command as it appears above is exactly 60 bytes. However, once variable substitution is performed for $ABCVAR, the length of the line will exceed 60 characters.

Field Description

App A user-assigned code to identify the application the event is a part of.

Grp A user-assigned code to identify the group the event is a part of.

Field Description

4 Events

111

Maintaining a REXX EventA REXX event lets you dispatch and monitor REXX execs.

To define and maintain REXX events

1 Access the Event Master Definition screen for REXX events as instructed in “Accessing the Event Master Record” on page 82.

2 Enter the appropriate information in the following fields to define a REXX event.

ASG-Zeke Event Master Definition EDIT Command ===> Event===> Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT OCCURS PATH PRED REACT RESOURCE SUCC WHEN Template: N Permanent: N Milestone: NEvt: 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: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: AControl: Y REXX exec: REXX1 Class: A Pri: 1 Argument:

Field Description





112

Usrid Eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs. Be sure to enter the desired user ID in the correct case (upper, lower, or mixed).


System System or pool that owns the event. An event is associated only with one system. This is the system the event is dispatched from, not necessarily the system the EMR is defined on.




Sched Normal schedule time for this event. The default is 00:00, which means this command is issued according to WHEN conditions instead of by time.

Field Description

4 Events

113

Control Enter the code indicating whether this event is executed and tracked as a Zeke-controlled event.

Code Meaning

Y (Default.) Zeke recognizes the event as a Zeke-controlled event. Zeke-controlled events are tracked throughout the entire execution. A Zeke-controlled REXX event is completed with either a status of EOE or AEOE. An EOE status is assigned if the exec completes with a return code of 0.

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

NX Zeke recognizes the event as a non-executable Zeke-controlled event.

REXX exec Name of member that contains the REXX. The dataset that contains this member must be defined in the SYSEXEC or SYSPROC DD concatenation of the OASIS ECF address space started task.

Note:The Zeke installation library contains the member REXSAMP, a sample REXX program for maintaining control over the status (EOE or AEOE) of the event.

Class OASIS/ECF exec class the REXX exec is associated with. Valid classes are A through Z and 0 through 9. Refer to your ASG-OASIS for z/OS Reference Guide for more information.

Pri OASIS ECF exec queue priority. Valid priorities are 1 through 9, where 1 is the highest priority. The default is 5. Priority is used only if there is no free ECF task for the specified class when the event is dispatched. If so, the request is queued and this priority is used to determine which exec for the class executes when a task is available.

Argument Argument string to be passed to the REXX exec when it is dispatched. The string’s values can be parsed into local REXX variables in the exec.

Field Description


114


4 Press Enter.

The changes are saved and the screen is displayed in Update mode. If you are adding the event, an event number is assigned.



Defining a Recurring or Permanent EventA recurring event is scheduled to occur more than once per schedule period. For example, a message issued to the operator every hour is a recurring event. The following statements are true for recurring events:

• If a recurring event has a Not After time specified and the calculated start time is greater than the Not After time, the event is not rescheduled and is considered done.

• Recurring events that have reached DONE status at least once and are scheduled to run again will display in the output for both the ZD DONE and ZDISPLAY operator commands.

A permanent event is never removed from the schedule so that it is always available to respond to triggers, even during schedule load processing. It 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 deactivate it using the ZDELETE command.

Field Description


Grp User-assigned code to identify the group the event is a part of.

4 Events

115

Zeke processes permanent events much like recurring events, with the following additional exceptions:

• The OCCURS clause is forced to REQUEST.

• Non-workday options in the calendar are ignored.

• Only one version can be active (Verload=0).

• The event cannot be downloaded to Zeke Agent.

• The event can be triggered by any date. The values of generation options Trigdte, Dsntrig, and Remtrig are treated as “any” (A or TA).

• Any Multhit generation options are ignored.

To define a recurring or permanent event

1 Access the Event Master Definition screen as instructed in “Accessing the Event Master Record” on page 82.

ASG-Zeke Event Master Definition EDIT Command ===> Event===> Primary Commands: ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOC EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHENTemplate: N Permanent: N Milestone: N Platform: MVSEvt: 243 Desc: SPECIAL RJE JOB FOR ABCType: JOB Desc2:Event Name: ZK51RJEABC App: Grp: Usrid: DRL:System: ZEQA Cal: A Retain: Y Nwday: A Multhit: Y Exp:Target: *LOCAL Verload: 00000Early: Sched: 00:00 Late: Mustend: Notafter:Dprty: 50 Operok: N Times: 003 Freq: 00:30 Freqcalc: S Trig: AControl: Y Tapes: 000 Avgdur: 00:00:00 Job: TSKKGUT1 Class: Pri: JCL--> PDS: Member: CMS: Ftype: Zeke JCL (Y=Yes): Y


116

2 Complete the following fields, as applicable:

Field Description

Permanent Code indicating whether the event is to remain in the schedule permanently/indefinitely.

N Default. Event is processed by each schedule run according to the OCCURS clause.

Y Event must be added to the schedule using ZADD. After it has been added, the event remains in the schedule even across schedule runs until it is deleted using the ZDELETE command.

Times Number of times the event is to be dispatched per schedule run. For a recurring event, valid values are 2 through 255. For a permanent event, do not set a Times value; Zeke considers the number of times to be unlimited, and the value is displayed as 000.

Note:If a permanent event is later changed to be non-permanent, Zeke automatically sets the Times value to 1.

Freq Amount of time a recurring event is to wait before dispatching again. To determine the next schedule time, Zeke adds the value in this field to the current system time or the current schedule time, depending on the Freqcalc value.

If you set Freq=00:00, the recurring or permanent event is marked as time-satisfied immediately after each completion. As soon as the WHEN condition (if any) is also satisfied, the event is dispatched.

Note:For a permanent event, when the next schedule time passes 24:00, the run date is set to the current date.

Freqcalc Code indicating how to calculate the next dispatch time for the recurring event.

S Zeke schedules the event by the scheduled start time, regardless of the time the event actually runs. If the event is held up for some reason, any missed runs are dispatched immediately.

C Zeke schedules the event based on the completion time of the previous run. The current time and the Freq time are used to determine the next dispatch time. If Zeke has been down, any missed runs are dispatched according to the FREQ value.

4 Events

117

3 Press Enter.



5 Perform the procedure “Defining a WHEN Condition” on page 150 to specify any prerequisites that must occur before the event can be dispatched.

Trig Applies to recurring events only. Code indicating when the recurring event can satisfy WHEN conditions (i.e., serve as a trigger) for other events.

A (Default) The recurring event can trigger other events each time it runs.

Note:Permanent events (i.e., recurring events which can occur an unlimited number of times) always trigger on all occurrences.

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

L The recurring event can only trigger other events the last time it runs.

For example, for a recurring event, you might use the following values:

Times 24

Freqcalc S (schedule time)

Freq 01:00 (1 hour)

Trig F

Start Time

8:00

This event is scheduled to run at 8:00 and then Zeke adds the schedule time (8:00) to the FREQ (one hour) and schedules the event to recur at 9:00. This continues until the event is dispatched the specified number of TIMES (24). The event can satisfy WHEN conditions only on the 8:00 run. All subsequent trigger calls for this event are ignored (until the event is rebuilt or refreshed). Changing Trig to A would allow the event to satisfy WHEN conditions every hour, on all 24 runs.

Field Description


118

OCCURS ClausesThe OCCURS clause specifies the day or days an event should be scheduled. The ZEKE utility program SCHEDULE function scans the database and selects all events due to process on the schedule date based on the OCCURS clause. See “OCCURS Keywords” on page 120 for a list and description of all OCCURS clause keywords.

An event is scheduled when its OCCURS clause is true. For example, suppose an event is defined 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 clause is false. When an event’s OCCURS clause is false, the event is not scheduled.

OCCURS Clause FormatThe format of the OCCURS clause is:

OCCURS (keyword AND|OR keyword)

Enclose the entire clause (excluding the word OCCURS) within parentheses. Any AND/OR logic and additional keywords are optional. For example, the following event OCCURS on Mondays:

OCCURS (MONDAY)

The following event OCCURS on the last Monday in January:

OCCURS (MONDAY.L AND JANUARY)

For events with multiple versions, all versions of the event share the same OCCURS clause. When appearing on reports and displays, the OCCURS clause appears as version zero.

4 Events

119

Multiple OCCURS Clause PhrasesAn event can have more than just one OCCURS clause phrase, if needed.

For example, the following event is to be selected on every Monday and Thursday. The event is defined with 2 OCCURS clause phrases joined with the word OR.

OCCURS (MONDAY OR THURSDAY)

The keyword OR indicates the event is scheduled when either clause is true.

The keyword AND indicates the event is scheduled only when both of the OCCURS clauses are true. For example, the following event is scheduled for each Monday during January:

OCCURS (MONDAY AND JANUARY)

The following event is scheduled only when the current schedule date is Monday, and also Thursday. Since this situation can never occur, this OCCURS clause is invalid and the event is never scheduled.

OCCURS (MONDAY AND THURSDAY)

Grouping Multiple OCCURS Clause PhrasesIn addition to AND/OR relationships between multiple OCCURS clause phrases, you can group multiple OCCURS clauses, in order to resolve one group of clauses before resolving the next, higher group. Use additional sets of parentheses to group multiple clauses.

For example, suppose an event is scheduled for any Monday during the first month of each quarter. The months are January, April, July, and October. The OCCURS clause is specified as follows:

OCCURS (MONDAY AND (JANUARY OR APRIL OR JULY OR OCTOBER))

The innermost group is resolved 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, the event is only scheduled if it is a Monday in one of the named months.

Use only additional sets of parentheses to separate multiple conditions. For example, (WORKDAYS AND (MONDAY OR TUESDAY)) does not need to be coded (WORKDAYS AND ((MONDAY) OR (TUESDAY))), because MONDAY and TUESDAY are not multiple conditions.


120

OCCURS KeywordsThe following symbols are used in the OCCURS clause with keywords.

The OCCURS clause can contain one or more of the following keywords:

Symbol Description

.

(period)

Specifies an occurrence of a keyword.

OCCURS (MONDAY.L)

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

Schedules for the second Monday of each month or period.

+

(plus)

Adds the specified number of days or workdays. Can be used with the period (.) keyword followed by L or 1 through 24.

OCCURS (MONDAY.L + 3 DAY)

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

Schedules for 3 workdays after the last Monday of each month or peri-od.

-

(minus)

Subtracts the specified number of days or workdays. Can be used with the period (.) keyword followed by L or 1 through 24.

OCCURS (TUESDAY.1 - 5 WDAY)

Schedules for 5 workdays before the first Tuesday of each month or pe-riod.

OCCURS (EOM-2)

Schedules for 2 days before the last day of each month.

Keyword Description

DAILY Schedules for any day the Zeke schedule function runs, regardless of whether the day is a workday, weekend, or holiday.

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

MONDAY Schedules for Mondays.

TUESDAY Schedules for Tuesdays.

WEDNESDAY Schedules for Wednesdays.

THURSDAY Schedules for Thursdays.

4 Events

121

FRIDAY Schedules for Fridays.

SATURDAY Schedules for Saturdays.

SUNDAY Schedules for Sundays.

WMONDAY Schedules for working Mondays.

WTUESDAY Schedules for working Tuesdays.

WWEDNESDAY Schedules for working Wednesdays.

WTHURSDAY Schedules for working Thursdays.

WFRIDAY Schedules for working Fridays.

WSATURDAY Schedules for working Saturdays.

WSUNDAY Schedules for working Sundays.

JANUARY Schedules if January. Use with AND. For example:

OCCURS (FRIDAY.L AND JANUARY)

Schedules the last Friday in January.

FEBRUARY Schedules if February. Use with AND.

MARCH Schedules if March. Use with AND.

APRIL Schedules if April. Use with AND.

MAY Schedules if May. Use with AND.

JUNE Schedules if June. Use with AND.

JULY Schedules if July. Use with AND.

AUGUST Schedules if August. Use with AND.

SEPTEMBER Schedules if September. Use with AND.

OCTOBER Schedules if October. Use with AND.

NOVEMBER Schedules if November. Use with AND.

DECEMBER Schedules if December. Use with AND.

EOM Schedules for last day of the month.

Keyword Description


122

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

WEOM Schedules for last working day of the month.

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

DAY Schedules on the specified day of the month.

DAY yy xx Schedules on the specified day of the month if the relationship is true.

Where:

yy is an operator (LE, LT, GE, GT, NE, EQ) or period (.).

xx is a number in the range 01 through 31, L, or L–

For example:

OCCURS (DAY LE 07)

Schedules on any day less than or equal to the seventh day of each month.

OCCURS (DAY.5)

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

Schedules on the day before the last day of each month.

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

xx is an operator (LE, LT, GE, GT, NE, EQ) or period (.)

yy is a number in the range 01 through 31, L, or L–

For example,

OCCURS (WDAY EQ 04)

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

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

Schedules on the workday before the last workday of each month.

JDAY Schedules on the specified day of the current year. JDAY uses the same format as the keyword DAY, but its period is for the year. JDAY can also be used to refer to the current Julian day in comparison phrases.

OCCURS (JDAY LE 31)

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

Schedules for the last day of the year.

Keyword Description

4 Events

123

DATE xx mm/dd/yyyy

Schedules on the specified date if the relationship is true.

xx=operator (LE, LT, GE, GT, NE, EQ)

mm/dd/yyyy=an actual date

For example,

OCCURS (DATE LE 12/31/2007)

Schedules for any date less than or equal to December 31, 2007.

Note:You can also use the date format dd/mm/yyyy if your OASISxx PARMLIB member specifies DATE=DDMM.

MONTH Schedules if the month is true. Use with AND.

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 may 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 the week in a month or period. Use with AND.

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 a week in the month or period that includes Monday through Sunday. Use with AND.

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 the working day of the week.

OCCURS (WDAYW.2)

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

WFWEEK Schedules during a normal full work week in the month or period that includes all normal workdays in that week. Use with AND.

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.

Keyword Description


124

USEREXIT Calls a user-written program during OCCURS clause processing. All calendar table information is passed to the exit. USEREXIT determines if the event should be scheduled.

OCCURS (USEREXIT TESTOCCUR)

Schedules if the user exit returns a response of true.Refer to your ASG-Zeke for z/OS Installation Guide for more information on user OCCURS clause exits and on using this keyword.

EVERY xxx DAYS BEGINNING mm/dd/yyyy

Schedules every xxx days beginning on the specified date. The event will not schedule prior to the specified date.

Note:You can also use the date format dd/mm/yyyy if your OASIS00 member is set to DATE=DDMM.

EVERY xxx WDAYS FROM mm/dd/yyyy

Schedules every xxx workdays prior to and after the specified date. When scheduling events for the future, the event will schedule prior to as well as after the specified date.

Note:You can also use the date format dd/mm/yyyy if your OASIS00 member is set to DATE=DDMM.

REQUEST Never automatically schedules this event. Use the ZADD command to schedule the event.

REFEVENT Schedules according to the OCCURS clause of the specified event. This keyword can be used with other OCCURS keywords. Takes into account the NWDAY specification of the referenced event.

OCCURS (REFEVENT 26 + 2 WDAY)

Schedules the event 2 workdays after the OCCURS of event 26.

NOT Schedules if the specified keyword condition is not true. This keyword can be used for a single condition or for a compound condition enclosed in parentheses.

OCCURS (NOT WORKDAYS)

Schedules on any day that is not defined to Zeke as a workday.OCCURS (NOT (MON OR TUES))

Schedules on all days except for Mondays and Tuesdays.OCCURS (WORKDAYS AND NOT MONDAY)

Schedules on any working day that is not a Monday.

AND Schedules if both conditions are true.

Keyword Description

4 Events

125

OR Schedules if either of the conditions is true.

BEFORE Schedules on the working day prior to 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:Use the keywords BEFORE, AFTER, and ON to schedule an event when it would normally fall on a holiday or weekend. Place the keywords immediately after another keyword or compound conditions enclosed in parentheses. If BEFORE or ON is not specified, Zeke schedules the event the day after a holiday or weekend unless the NWDAY parameter specifies differently. See “Scheduling Events on Holidays and Weekends” on page 130.

PERIOD Schedules the event according to the specified period. For example,

OCCURS (MONDAY.L AND PERIOD.3)

Schedules for the last Monday in the 3rd period of the calendar.

HOLIDAYS Schedules on holidays.

Note:To code an OCCURS clause with a relational reference to a holiday (such as (HOLIDAYS + 1 DAY)), the EMR’s NWDAY parameter must be set to “O” (O=schedule the event on the non-workday).

WEEKENDS Schedules on weekends.

HOL/WEEK Schedules on holidays and weekends.

CALENDAR Schedules based on the specified Special calendar. Use with AND.

OCCURS (CALENDAR TEST1 AND WEDNESDAY)

Schedules only for the Wednesdays marked in calendar TEST1.

VAR Schedules if the specified Zeke variable is true. Use with AND.

OCCURS (VAR $SUE123 EQ OKAY AND PERIOD.2)

Schedules only if the value for $SUE123 is OKAY and it is the second period of the calendar.

Keyword Description


126

Sample OCCURS ClausesThe following are some example OCCURS clauses and their descriptions.

OCCURS (WORKDAYS AND MONTH.L)Occurs every workday in the last fiscal month.

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

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

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

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

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

OCCURS (WDAY NE 07)Occurs every workday except the seventh workday of each month or period.

OCCURS (SUNDAY AND WEEK.1)Occurs on Sunday in the first week of each month or period.

OCCURS ((FRIDAY.2 OR FRIDAY.4) AND (MONTH.3 OR MONTH.6 OR MONTH.9 OR MONTH.12))

Occurs the second and fourth Friday of the third month of each quarter.

OCCURS (WEDNESDAY AND NOT DAY.1)Occurs every Wednesday unless Wednesday is the first day of the month.

OCCURS (WORKDAYS AND NOT WEOM-1)Occurs every workday except the workday before the last day of the month.

OCCURS (EOM + 5 WDAY)Occurs five workdays after the last day of the month.

OCCURS (WFWEEK.1 AND NOT MONDAY)Occurs the first full work week of the month except for Monday.

OCCURS (NOT FWEEK.1 AND DAILY)Occurs every day of the month (including weekends) except the first full week (Monday through Sunday) of the month.

4 Events

127

OCCURS (MONTH.10 AND WORKDAYS AND NOT FRIDAY)Occurs every workday in October except Friday.

OCCURS ((WORKDAYS AND NOT FRIDAY) OR (FRIDAY AND WEOM))Occurs every workday of the week, except for Friday, unless Friday is the last workday of the month.

OCCURS (MONDAY.L AND PERIOD.1)Occurs the last Monday of the first period.

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

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

OCCURS (WORKDAYS AND NOT (HOLIDAYS - 1 WDAY) AND NOT (HOLIDAYS - 2 WDAY))

Occurs every workday except the 2 workdays preceding a holiday.

OCCURS (((FRIDAY AND EOM) - 7 DAY) OR ((SATURDAY AND EOM) - 8 DAY) OR ((SUNDAY AND EOM) - 9 DAY) OR (FRIDAY.L AND NOT EOM AND NOT EOM-1 AND NOT EOM-2))

Occurs the last Friday of the month unless the last Friday is also one of the last 3 days of the month; in that case, occurs on the next-to-last Friday of the month.

OCCURS (((FRIDAY AND HOLIDAYS) - 1 DAY) OR (FRIDAY AND NOT HOLIDAYS))

Occurs every Friday unless it is a holiday; in that case, occurs on the previous Thursday.

OCCURS (((((FRIDAY AND HOLIDAYS) - 1 DAY) AND HOLIDAYS) - 1 DAY) OR (((FRIDAY AND HOLIDAYS) - 1 DAY) AND NOT HOLIDAYS) OR (FRIDAY AND NOT HOLIDAYS))

Occurs every Friday unless it is a holiday; in that case, occurs on the previous Thursday. If previous Thursday is also a holiday, occurs the previous Wednesday.

OCCURS (((MONDAY AND HOLIDAYS) + 2 DAY) OR ((MONDAY AND NOT HOLIDAYS) + 1 DAY))

Occurs every Wednesday following a Monday that is a holiday, and every Tuesday following a Monday that is not a holiday.

OCCURS (WORKDAYS AND NOT WDAYW.1 AND (NOT HOLIDAYS + 1 DAY))Occurs every workday unless it is the first workday of the week or the day after a holiday.


128

OCCURS (((WDAYW.1 - 2 DAY) AND NOT HOLIDAYS) OR ((MONDAY AND HOLIDAYS) - 1 DAY))

Occurs the second non-holiday day before the first workday of every week, unless the first workday of the week is a holiday; in that case, occurs the day before the first workday of the week.

OCCURS ((WORKDAYS AND NOT FRIDAY.2) OR (FRIDAY.2 + 2 DAY))Occurs every workday of the month except the second Friday; also occurs 2 days after the second Friday of the month.

OCCURS (WORKDAYS AND NOT (HOLIDAYS AND MONDAY) + 1 DAY)Occurs every workday except the day following a Monday holiday.

OCCURS (SEPTEMBER AND DAY EQ 28 OR (OCTOBER AND DAY EQ 26 OR (NOVEMBER AND DAY EQ 23 ON HOLIDAYS OR (DECEMBER AND DAY EQ 28))))

Occurs on September 28, October 26, November 23 (even if it is a holiday), and December 28.

OCCURS ((DECEMBER AND DAY GE 6 AND DAY LE 27) AND WORKDAYS AND NOT FRIDAY)

Occurs on all workdays, except Fridays, from December 6 through December 27 (inclusive).

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

OCCURS (MONDAY ON HOLIDAYS OR (TUESDAY ON HOLIDAYS OR (WEDNESDAY ON HOLIDAYS OR (THURSDAY ON HOLIDAYS OR (FRIDAY ON HOLIDAYS)))))

Occurs every Monday, Tuesday, Wednesday, Thursday, and Friday—even if it is a holiday. OCCURS (NOT SATURDAY ON HOLIDAYS AND NOT SUNDAY ON HOLIDAYS) would produce the same results.

OCCURS (FRIDAY.1 AND PERIOD.4)Occurs the first Friday in the fourth period of the calendar.

OCCURS (CALENDAR TEST2 AND WSATURDAY)Occurs every working Saturday marked in calendar TEST2.

OCCURS ((WDAYW.3 AND WDAYW.L) - 1 DAY)Occurs on the second workday of the week if the third workday is the last workday in the week (for example, occurs on Tuesday if Thursday and Friday are holidays, or on Thursday if Monday and Tuesday are holidays).

4 Events

129

OCCURS (DAY EQ 15 BEFORE HOL/WEEK)Occurs on the fifteenth day of each month or period unless it is a holiday or weekend; in this case, occurs on the prior workday.

OCCURS ((DAY.L BEFORE HOLIDAYS ON WEEKENDS OR ((DAY.1 AND HOLIDAYS) + 1 DAY)) OR (DAY.1 AND NOT HOLIDAYS))

Occurs the last day of each month or period (even if it is a weekend) unless it is a holiday; in this case, occurs on the prior workday. Also occurs the first day of each month or period unless it is a holiday; in this case, occurs the second day of the month or period.

OCCURS (JDAY LE 31)Occurs the first 31 days of the year.

OCCURS (JDAY LE 31 ON HOLIDAYS)Occurs the first 31 days of the year. Holidays will be scheduled for the actual day.

OCCURS (JDAY.60)Occurs the 60th day of the year, either March 1 of non-leap year, or February 29 in a leap year.

OCCURS (JDAY.L)Occurs on the last day of the year.

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

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


130

Scheduling Events on Holidays and WeekendsThe following OCCURS clause keywords are affected by holidays and weekends.

Events scheduled for a particular day of the week, or EVERY xx DAYS, might hit on a nonworking day. However, events defined to OCCUR WORKDAYS, or WDAY EQ xx, or xx working days prior to the last working day of the month (WDAY.L-xx or WEOM-xx) are not affected by holidays or weekends because a workday, by definition, cannot be a holiday or weekend.

When an event is scheduled to occur on a nonworking day, Zeke, by default, schedules the event for the following working day.

For example, an event is defined to occur on Monday, and Monday is a holiday. Even if the schedule function is processed on Monday, the event is not scheduled because Monday is a holiday. Zeke schedules the event for the following Tuesday, dates the scheduled event with Monday's date, and places it in Tuesday's schedule. The scheduled event contains Monday's date, because there might be another scheduled event for Tuesday (suppose the event is defined to occur Monday or Tuesday).

To schedule the event for the prior working day, Friday, code the OCCURS clause as follows:

OCCURS (MONDAY BEFORE HOLIDAYS)

To schedule the event for Mondays, regardless of whether Monday is a holiday, code the OCCURS clause as follows:

OCCURS (MONDAY ON HOLIDAYS)

To schedule an event for every Saturday when Saturday is defined as a weekend, code the OCCURS clause as follows:

OCCURS (SATURDAY ON WEEKENDS)

For another example, an event is defined to occur every 10 days. If the hit date falls on a holiday or on a weekend, Zeke, by default, schedules the event on the next working day. Use the following phrases to schedule an event prior to a holiday or weekend:

• BEFORE HOLIDAYS

• BEFORE WEEKENDS

• BEFORE HOL/WEEK

DATE xx mm/dd/yyyy DAY EQ xx DAY.x EOM

EOM-xx EVERY xx DAYS HOLIDAYS HOL/WEEK

MONDAY-SUNDAY WEEKEND

4 Events

131

Use the same phrases with the word ON instead of BEFORE to schedule the event on the hit date even if it might be a holiday or weekend.

The words ON, BEFORE and AFTER can be used outside of parentheses to apply to all keywords within parentheses. This does not apply if there is an individual holiday or weekend specified. For example,

OCCURS ((MONDAY BEFORE HOLIDAYS) OR TUESDAY)Schedules event every Monday and Tuesday. However, if Monday is a holiday, schedules on the previous workday.

OCCURS ((MONDAY OR TUESDAY) BEFORE HOL)Schedules event Monday or Tuesday. If either is a holiday, schedules event on the previous workday.

When you specify a holiday or weekend in the OCCURS clause, it overrides the NWDAY field in the EMR.

For global OCCURS clause specifications, you can set a Zeke generation option. See “Scheduling Events” on page 297 for information about the Nonwkday generation option.

Note:The keyword DAILY schedules an event on any day the schedule function runs, regardless of whether that day is a workday, weekend, or holiday. The modifiers ON, BEFORE, and AFTER have no effect on the OCCURS clause keyword DAILY.


132

Defining an OCCURS Clause

To define and test an OCCURS clause


2 Enter OCCURS on the Command line and press Enter.

The Event Record Occurs Clause screen is displayed.


ASG-Zeke Event Record Occurs Clause EDIT Command ===> Primary Commands : BROWSE EDIT ACCTG OCCHIT Evt: 000006 Type: JOB Job: TSKKGUT1 Evt Name: ZEKE51TST6 Calid: AVer: 00000 Occurs: (WEEK.2)

4 Events

133

3 In the OCCURS field, enter a valid OCCURS clause. Enclose the clause in parentheses. The most common OCCURS keywords.

4 Press Enter. The event is updated with the new OCCURS clause.

5 Enter OCCHIT on the Command line and press Enter.

The OCCURS Hit Resolution screen is displayed.

The days of the current month are displayed. The highlighted days with an asterisk (*) to the right are the days the event is scheduled to occur.

Keyword Description

REQUEST (Default.) Event is not automatically scheduled. Manually add it to the schedule via Schedule View or the ZCOM option. See “Using Schedule View” on page 202 or “Using the ZADD Operator Command” on page 250.

DAILY Event is scheduled every day, regardless if workday, weekend, or holiday.

WORKDAYS Event is scheduled for workdays only, as defined on the calendar for the event.

EOM Event is scheduled the last day of each month.

ASG-Zeke Occurs Hit Resolution EDIT Command ===> Primary Commands: BROWSE EDIT NMONTH PMONTH NYEAR PYEAR Month: 11 Year: 2007 Event: 000032 Ename: TESTADDNM Calid: A M O N T U E W E D T H U F R I S A T S U N 1 2 3 4 W 5 W 6 * 7 * 8 * 9 * 10 * 11 W 12 W 13 *2 14 15 16 17 18 W 19 W 20 21 22 23 24 25 W 26 W 27 28 29 30 Ver: 00000 Occurs: (WEEK.2) W = Weekend H = Holiday S = Slack day * = Event scheduled on this date*X = Event scheduled x times on this date


134

6 View the results of the OCCURS clause for at least the next 12 months to verify that it is scheduling as desired. Perform the steps in the Action column in the following table, depending on the desired results.


View the schedule for the next month

Enter NMONTH on the Command line and press Enter.

View the schedule for the previous month

Enter PMONTH on the Command line and press Enter.

View the schedule for the next year

Enter NYEAR on the Command line and press Enter.

View the schedule for the previous year

Enter PYEAR on the Command line and press Enter.

View the schedule for a specific month

Enter the number of the month (01=January, 12=December) in the Month field and the year in the Year field. Press Enter.

4 Events

135

WHEN ConditionsWHEN conditions specify the conditions that must occur before an event can be dispatched. An event with WHEN conditions is not dispatched by Zeke until the WHEN conditions are satisfied. A WHEN condition, also known as a dependency, can be any of the following:

• Execution of a specific program, system job, or Zeke event

• Relating a Zeke variable to a certain value

• Any combination of multiple WHEN conditions

• z/OS dataset creation

If an event does not have a dependency defined to it, then the event is dispatched according to the specified schedule time on the EMR. Work centers do not have WHEN conditions. See “Work Centers” on page 161.

Job and Program WHEN ConditionsJob and program WHEN conditions are satisfied when the system initiates or completes the action named in the dependency (such as starting or ending a specific job). As each dependency is satisfied, the WHEN conditions are examined to determine if they are all satisfied. When they are, the event status becomes WHEN OK.

WHEN Conditions for Multiple Event VersionsFor events with multiple versions, separate WHEN conditions can be defined for each version. A dependency is assigned a version number to indicate which version of the event it belongs to.

When an event version is placed in the schedule, Zeke searches for a dependency with the same version number. If one is found, that dependency is used for the event version. If one is not found, the version zero dependency is used as the default (if it exists). If a default dependency has not been defined for the event, the event is automatically changed to WHEN OK.


136

Extended DependenciesThe 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 are no longer in the schedule. If a job is dependent on another event that may have run as part of an earlier schedule, the XEOJ keyword is used 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 145 for details on including the XEOJ and XEOE keywords in a WHEN condition.)

If a job has multiple extended WHEN conditions, all must be satisfied at the same time in order for the extended triggering to occur.

At schedule load, the EMRs are searched (using the index, if present) and the first matching jobname is examined. If the last run of that event has completed successfully since the last time the job with the extended dependency ran, the dependency is satisfied and displayed with an asterisk (just like an EOJ or EOE). Otherwise, the dependency is treated as if it were a regular EOJ or EOE and must wait for the triggering job to complete successfully before it can be satisfied. Extended dependencies are examined each time an event becomes TIMEOK and WHENOK.

For extended dependency triggering, the start date and time, the end date and time, and the status are retained in the EMR for the last execution of each event. (Refer to “Event Activity Accounting” on page 188.) If the schedule record has been requeued or if the execution is not being tracked, information is kept in the EMR for the previous execution instead. If multiple schedule records for an event are executing together, triggering occurs based on the execution with the latest end date and time.

Note:Extended WHEN conditions are processed in the same manner as if the generation options Trigjob=C and Trigdt=A. In other words, the triggering event must have been dispatched by Zeke (or by a Zeke sharing the same database), 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. (A JCL error is an unsuccessful completion; EOJ FORCED is a successful completion.) If the execution is unsuccessful, the information for that execution is still retained in the EMR, but no triggering takes place.

Extended WHEN conditions can also be manually satisfied using the ZALTER WHENOK operator command.

4 Events

137

XEOE ExampleEvent 2 has an extended dependency (XEOE) on Event 1. When Event 2 is loaded into the schedule, Zeke checks to see if 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 would be satisfied and Event 2 would be dispatched (assuming any additional dependencies are also satisfied). But, if Event 1 ran two weeks ago and Event 2 ran only two days ago, the XEOE would not be satisfied and the dependency is treated as an EOE instead.

XEOJ ExampleThe job event named Job B has an extended dependency (XEOJ) on Job A. When Job B is loaded into the schedule, Zeke checks to see if 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 and Job B would be dispatched (assuming any additional dependencies are also satisfied). But, if Job A did not end until 10:30:56 a.m. (also during the same minute), then the XEOJ would not be satisfied and the dependency is treated as an EOJ instead.

WEAK ConditionsWEAK conditions in a dependency allow you to create WHEN conditions referring to events that may or may not be in the schedule. WEAK conditions allow the user to specify that the condition should be respected if the event is in the schedule; otherwise, ignore the condition.

The following is an example dependency for event 100:

WHEN (WEOJ JOBABC)

If JOBABC is in the schedule, event 100 is not dispatched until JOBABC reaches a successful end-of-job (EOJ).

Zeke continuously checks for JOBABC until the event is dispatched. Zeke also verifies whether the condition was met because WEAK was satisfied (event not in the schedule) or because the condition was satisfied (job ran).

If the generation option Removdq=Y, the example above is processed as follows. If JOBABC is not in the schedule, event 100 is moved to the dispatch queue. While the event is in the dispatch queue, Zeke continues to check for JOBABC. If JOBABC is added to the schedule (ZADD operator command), event 100 is removed from the dispatch queue and is not queued again until JOBABC reaches a successful EOJ. If JOBABC is never added, event 100 executes when the resources are available. (If Removdq=N, events are not removed from the dispatch queue once they have been added.)


138

Started TasksThe BOJ, EOJ, BOP, EOP, AEOJ, EOS, and AEOP WHEN conditions can also refer to started tasks and programs within started tasks, provided the proper specifications are made in the SMFPRMxx member of SYS1.PARMLIB. Refer to your ASG-Zeke for z/OS Installation Guide for more information on SMF requirements or ask your system programmer if your installation supports WHEN conditions referencing started tasks.

Generic NamesTo specify generic event names for the EOE, AEOE, XEOE, or EOG conditions, precede the event name with an asterisk and as many characters as you want to match. Generic names are only valid for event names. Generic names cannot be used for jobnames. For example, *ABC matches all jobs with event names beginning with ABC.

To use an asterisk as a wildcard character, replace any character with an asterisk. For example, PAY***UPD selects all events with PAY in the first three positions, any characters in the fourth through sixth positions, and UPD in the seventh through ninth positions. If the event name contains spaces, specify the name in single quotes. For example, (EOE '**********')

An asterisk can indicate a generic name and a wildcard character, so it is important to understand how Zeke interprets an asterisk. The maximum number of characters is 12. If all 12 characters are specified (with an asterisk in the first position), Zeke assumes the first asterisk is a wildcard. For example, *KKKKKKKKKKK selects all events with any character in the first position and K in the second through twelfth positions. If less than 12 characters are specified, Zeke assumes an asterisk in the first position means a generic name. For example, *KKKKKKKKKK (one less K than the previous example) selects all events beginning with 10 K’s.

If you want to indicate a generic name, but need to specify 12 characters, place the asterisk in the last position, as in the example KKKKKKKKKKK*. This selects all events beginning with 11 K’s.

4 Events

139

Multiple WHEN ConditionsAn event can have more than one dependency.

This example shows two WHEN conditions joined with the word OR. The keyword OR indicates the event is satisfied when either clause is satisfied.

WHEN (EOJ ABC OR EOJ XYZ)

The keyword AND indicates the event is satisfied only when both of the WHEN conditions are satisfied.

WHEN (EOJ XYZ AND EOJ ABC)

Grouping Multiple WHEN ConditionsIn addition to AND/OR relationships between multiple WHEN conditions, multiple WHEN conditions can be enclosed in parentheses. This separates the clauses into groups and indicates to resolve one group before resolving the next, higher group.

For example, an event is satisfied when Job A completes and either Program A or Program B completes.

WHEN (EOJ JOBA AND (EOP PGMA OR EOP PGMB))

The inner group is resolved first. The inner group is satisfied if Program A or Program B finished. Because the keyword AND joins the 2 clauses, the event is only satisfied if Job A has also finished.


140

Zeke Variables as WHEN ConditionsTo use a Zeke variable as a dependency, specify a variable and the relational operator to compare to a specified value. Variable substitution in WHEN conditions is performed when the schedule record is created (during the SCHEDULE function or during a ZADD function).

For example, the following event is not dispatched until the variable $VARNAM1 is YES:

WHEN (VAR $VARNAM1 EQ YES)

When the variable is set to YES, the dependency is satisfied. The dependency is also satisfied if the variable is already equal to YES when the schedule is first loaded.

In WHEN conditions, OASIS variables can only be used for substitution in an operand, such as the jobname in a BOJ condition, the jobname in an EOJ condition, or the expression following the “EQ” in a VAR condition. OASIS variable substitution is performed using qualifiers from the schedule record being created.

WHEN EOJ PRDAA$(CYCLE)

Say the value of the OASIS CYCLE variable is 09; this number is substituted into the dependency, and the jobname becomes PRDAA09.

WHEN conditions containing variables are not checked for syntax when they are defined. Syntax checking occurs only after the variable substitution is performed. This is important in the following situation: suppose the operand of an EOJ dependency containing a variable is longer than eight characters before substitution occurs. Normally, this would be invalid due to its length. However, since syntax checking is not performed until after the substitution, it is valid as long as the value is no longer than eight characters after substitution occurs.

The following relational operators are valid.

Relational Operator Description

EQ EQual

NE Not Equal

LE Less than or Equal

GE Greater than or Equal

LT Less Than

GT Greater Than

4 Events

141

Use either numeric or character literals, but only compare numeric values to numeric variables and character values to character variables. Express numeric literals explicitly (no delimiters), and enclose character literals in special character delimiters if the character string contains other than alpha/numeric characters. For example,

WHEN (VAR $TEST1 EQ PROCEED)WHEN (VAR $CTR4 EQ 411 AND VAR $CTR3 EQ 77)WHEN (VAR $SHOWLIT EQ 'IT IS OK TO CONTINUE NOW')

Caution! The following characters cannot be used as delimiters:

— dollar sign ($)

— question mark (?)

— number/pound sign (#)

— at sign (@)

— asterisk (*)

Combinations of Event Actions and Zeke VariablesCombinations of job, program, and event actions and Zeke variables can be specified as WHEN conditions for any event. For example,

WHEN (EOJ JOBNAME1 AND VAR $VARNAME EQ YES)


142

NOTDURING ConditionsA NOTDURING condition specifies that an event cannot be dispatched while the specified programs or jobs are running. The event remains eligible for dispatch until the NOTDURING conditions are satisfied. Then, the event is immediately dispatched.

Zeke ensures that events with conflicting NOTDURING clauses are not dispatched at the same time. For example, if JOB1 is in PENDING status and JOB2 has an NOTDURING for JOB1, Zeke does not dispatch JOB2 even though JOB1 is not actually running. Disabling JOB1 allows JOB2 to dispatch.

Caution! NOTDURING conditions are not supported while the system is in SMF recording mode (initiated by the ZKILL TRACK command).

Activating NOTDURING ProcessingTo enable Zeke to process NOTDURING conditions on a single Zeke system, you must have the generation option Dispsel=Yes (see “Activating Initiator Options” on page 267). Additionally, the Eojwake generation option determines whether events held due to a NOTDURING condition are re-evaluated at each end-of-job or only at each 60-second dispatch interval (see “Checking the Dispatch Queue” on page 306).

To enable Zeke to use XCF to process NOTDURING conditions across a ZekePlex, the setting of Dispsel is not considered. Instead, you specify PLEXNOTD=YES in your Zeke options member. (Refer to your ASG-Zeke for z/OS Installation Guide for details.) This option allows NOTDURING job processing in both JES2 and JES3 (otherwise, only JES2 supports NOTDURING dependencies). In addition to setting PLEXNOTD=YES, be sure that PLEXID= has been defined in the OASISnn parmlib member for the OASIS under which this Zeke is running. Refer to the ASG-OASIS for z/OS Reference Guide for details on setting PLEXID= in the OASISnn parmlib member.

Specifying NOTDURING Conditions in a WHEN ClauseIn a WHEN clause, NOTDURING conditions must be listed last, after all other WHEN conditions.

NOTDURING conditions are related by the AND condition (the NOTDURING must be satisfied before an event can be dispatched).

NOTDURING conditions are not used in determining whether an event is WHEN OK. Therefore, an event can be WHEN OK even though a program or job named in an NOTDURING clause is executing. However, the event is not actually dispatched until the NOTDURING program or job completes.

4 Events

143

Specifying Generic JobnamesTo specify generic NOTDURING program and jobnames, precede the job or program name with an asterisk and enter up to 7 characters. For example, *ABC matches all jobnames beginning with ABC. To use an asterisk as a wildcard character, replace any character with an asterisk. For example, PAY**UPD selects all jobs with PAY in the first three positions, any characters in the fourth and fifth positions, and UPD in the sixth through eighth positions.

Since an asterisk can indicate both a generic name and a wildcard character, Zeke assumes that an asterisk in the first position means a generic name when fewer than eight characters are entered. For example, if you want to select all jobs with C in the seventh position, enter ******C* instead of ******C. Since all eight characters are specified, Zeke assumes the first asterisk is a wildcard character.

Note:An event cannot have a generic NOTDURING with a pattern that matches the jobname. For example, a job with the name JOBBC3PX and WHEN (NOTDURING JOB *BC3P).

ExamplesThe following are examples of the WHEN NOTDURING condition:

WHEN (EOJ JOB1 NOTDURING JOB PRODCICS)Requires EOJ on JOB1, but cannot run while job PRODCICS is running.

WHEN (NOTDURING PGM DFHSIP)No real WHEN conditions, but cannot run while program DFHSIP is executing.

Note:The NOTDURING PGM clause is honored regardless of the initiator the job is running in.

WHEN (NOTDURING JOB *PAY NOTDURING PGM PAY**01A)Cannot run with any job that has a job name 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.

Note:Resource control is a another effective way to ensure that conflicting Zeke events do not run at the same time. See “Maintaining Logical Resources” on page 274 for more information.


144

Cross-platform DependenciesCross-platform scheduling dependencies are prerequisites that are satisfied by a remote scheduler—either a remote Zeke system or another remote scheduler, such as 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 scheduler, 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 complete (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 job name can be up to 30 characters. The AT keyword does not support use of the VER keyword. If a version number is specified, it will be ignored.

Zeke-to-Zeke Cross-schedule DependenciesWhen a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the object of the AT netregid of another scheduler's trigger), a non-Zeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke's Trigjob generation option. Both the local and remote Zeke systems ignore the Trigjob genopt when satisfying cross-schedule triggers.

Zeke honors schedule and run dates when satisfying cross-schedule triggers. If a job that satisfies a cross-schedule trigger is a Zeke controlled job, the SQR's schedule date and run date are sent to the local Zeke with the satisfy notification. If the job that satisfies a cross-schedule trigger is not a Zeke job, the current date on the system where the job ran is sent to the local Zeke as the job's schedule and run dates in the satisfy notification. When the local Zeke system processes the satisfy notification, the local Zeke applies Trigdt to the schedule and run dates from the remote system to decide whether the remote job will satisfy the trigger. If the remote scheduler does not send the dates in the satisfy notification, the local Zeke system bypasses the Trigdt setting and simply looks for a match on the job name.

You can also use AT to specify a dependency using a ZALTER command. For example:

• To add a remote dependency with an 'and' relationship:

ZALTER JOB 1 WHENAND (EOJ JOBC AT SYSB)

• To add a remote dependency with an 'or' relationship.

ZALTER JOB 1 WHENOR (EOJ JOBC AT SYSB)

• To satisfy a remote dependency:

ZALTER JOB 1 WHENOK (EOJ JOBB AT SYSB)

4 Events

145

Refer to your ASG-Zeke for z/OS Reference Guide for more information on the ZALTER operator command.

WHEN Condition KeywordsUse the following keywords with the WHEN parameter:

Keyword Description

AT Eight-character Netregid for the remote scheduler where the cross-platform prerequisite is to occur.

WHEN (EOJ JOBA AND EOJ JOBB AT SYSB)

Note:With the AT keyword, a job name can be up to 30 characters.

The AT keyword does not support use of the VER keyword. If a version number is specified, it will be ignored.

See “Cross-platform Dependencies” on page 144 for more information.

DSN Dataset triggering is based on the creation and close of an OS output dataset. The event is dispatched when a sequential, non-VSAM dataset that matches the DSN dependency is created and closed.

WHEN (DSN DATASET.NAME)

WHEN (DSN DATASET.NAME AND EOJ PAYROLL)

Before using DSN for non-VSAM datasets, ensure that the generation option IEFU83 is set to Y and that Type 15 SMF records are being created on your system, or that Sterling Commerce’s Connect:Direct® product (formerly Network Data Mover, or NDM) is installed and active with the appropriate RUN TASK statement. Refer to the ASG-Zeke for z/OS Installation Guide for more information on using on using Connect:Direct with Zeke.

A generation data group (GDG) dataset name with a generation number of ‘G0000V00' is satisfied when any dataset in its GDG index is created and closed. The following condition is satisfied when any generation in the GDG ‘A.B' is created and closed.

WHEN (DSN A.B.G0000V00)

The IEFBR14 program does not close a dataset, so it will not trigger a DSN dependency.

AEOJ Failed end of job.

WHEN (AEOJ JOB1)

AEOE Failed event. Applies to any type of event, including work centers.

WHEN (AEOE JOB1)


146

AEOP Abnormal end of program.

WHEN (AEOP PAYROLL)

AEOS Abnormal end of step. 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)

NOTDURING Not during. Prevents jobs/programs from running at the same time. Must be the last condition in the clause.

WHEN (NOTDURING JOB JOBNAME)

WHEN (EOJ JOB1 NOTDURING JOB PRODCICS)

WHEN (NOTDURING JOB *PAY NOTAF PGM PAY**01A)

See “NOTDURING Conditions” on page 142 for a detailed discussion of NOTDURING WHEN conditions.

BOJ Beginning of job.

WHEN (BOJ JOB3)

BOP Beginning of program.

WHEN (BOP PGMNME)

EOG Successful end of a group of events. Use EOG to trigger an event by the completion of any number of other events, including work centers. This dependency is satisfied when all events in the schedule that match the specified event name are in SUCCESS or DISABLED status and at least one of the matching events is in SUCCESS status.

WHEN (EOG GRPPAY)

For example, let’s suppose a master file update is performed after all daily transactions are received. If the number of daily transaction jobs varies, EOE cannot be used, because some of the EOE conditions would not be satisfied if their corresponding jobs were not run on a particular day. With EOG, before the event is dispatched, Zeke ensures that all scheduled events matching the specified event name are in SUCCESS or DISABLED status. If no transaction jobs are complete, the master file update does not run.

Keyword Description

4 Events

147

If the generation option Removdq=YES, the EOG dependency can be unsatisfied up to the time of dispatch

If Removdq=NO, the EOG dependency can be unsatisfied up to the time the event is added to the dispatch queue.

For example, let’s suppose an event with an EOG dependency is scheduled at 18:00. At 10:00, two events that match the EOG are in the schedule. At 12:00, these events are completed. This satisfies the EOG, but the dependent event is not scheduled to run until 18:00. At 14:00, an event that matches the EOG dependency is added to the schedule. The EOG is no longer satisfied and the newly-added event must be completed or disabled before the event with the EOG dependency can be dispatched.

Note:If you specify an EOG dependency in which the dependent event matches the generic event name specified in the EOG, the dependent event will never be triggered (because it is dependent on itself as well as other events). For example, if the WHEN condition specifies EOG *ASG123 and the event name for the dependent event is ASG12345, all other predecessor events might be completed, but the successor will never be triggered.

EOE Successful end of event. This dependency is satisfied when an event in the schedule that matches the specified event name is in EOE or DISABLED status. Applies to any type of event, including work centers.

Note:This keyword requires the event name. Do not use the event number.

WHEN (EOE JOB1)

WHEN (EOE 'JOB TWO')

WHEN (EOE PAYROLL)

WHEN (EOE 'JOB PAYROLL')

EOP Successful End Of Program.

WHEN (EOP PROGRAM.JOB)

WHEN (EOP PGMNAME1 OR EOP PGMNAME2)

EOS Successful end of step. The stepname is the name of the job step that calls the cataloged procedure. The procstep is the name of the procedure step. When executing a procedure:

WHEN (EOS STEPNAME.PROCSTEP.JOBNAME)

When not executing a procedure:

WHEN (EOS STEPNAME..JOBNAME)

Keyword Description


148

EOJ Successful end of job.

WHEN (EOJ JOBNAME1)

WHEN (EOJ JOBNAME1 AND EOJ JOBNAME2 AND BOJ JOBNAME3)

WHEN (EOJ JOB$(CYCLE))

VAR Events are dispatched only when the variable is equal to the specified value.

WHEN (VAR $ABC EQ YES)

See “Zeke Variables as WHEN Conditions” on page 140 for a detailed explanation of variables used as WHEN conditions.

VER Events are dispatched only at the end of a specific version of the event. If the VER condition is omitted, it defaults to the same version SQR. For example, if JOBB version 3 is waiting on EOJ of JOBA but no version is specified, it will wait on EOJ of JOBA run under a version 3 SQR.

WHEN (EOE JOB4 VER 88)

WHEN (EOJ JOBC AND EOJ JOBC VER 2)

The VER condition can appear as part of any EOE, EOJ, EOP, EOS, or EOG clause (including their WEAK counterparts); however, it actually applies only to the SQR causing the trigger to be generated—not the job, program, or step.

Use an asterisk after the VER condition to trigger off of any version of the SQR. In the following example, the event triggers off of the next EOE on EVTB.

WHEN (EOE EVTB VER *)

Note:The following conditions do not support use of the VER keyword: DSN, VAR, ?VAR, XEOJ, and XEOE.

WEOG Weak end of group.

Successful End Of a Group of events. Applies to any type of event, including work centers. This dependency is satisfied when all events in the schedule that match the specified event name are in EOE or DISABLED status. In addition, at least one event must be in EOE status.

All events can be disabled for the WEOG condition. WEOG is also satisfied if there are no matching events in the schedule. See “WEAK Conditions” on page 137 for more information.

WHEN (WEOG GRPA)

Keyword Description

4 Events

149

WEOE Weak end of event. Applies to any type of event, including work centers. This keyword requires the event name. Do not use the event number. See “WEAK Conditions” on page 137 for more information.

WHEN (WEOE WC_ABC)

WEOJ Weak end of job. See “WEAK Conditions” on page 137 for more information.

WHEN (WEOJ JOBNAME)

XEOE Extended end of event. Applies to any type of event, including work centers. This keyword requires the event name. Do not use the event number. XEOE does not support use of the VER keyword.

For example, if the following dependency is defined for JOBC, XEOE is satisfied if job ABC has run to DONE or DISABLED status since the last time JOBC ran.

WHEN (XEOE ABC)

XEOJ Extended EOJ for job events only.

Note:XEOJ does not support use of the VER keyword. If a version number is specified, it will be ignored. An event will be triggered by any version of a matching job.

For example, if the following dependency is defined for JOBC, XEOJ is satisfied if JOBA has run since the last time JOBC ran.

WHEN (XEOJ JOBA)

Keyword Description


150

Defining a WHEN Condition

To define and maintain a WHEN condition

1 Access the Event Master Definition screen as instructed in the procedure, “Accessing the Event Master Record” on page 82.

2 Enter WHEN # (where # is the version) on the Command line and press Enter. If you do not enter a version number, it defaults to the first version.

3 Use the standard ISPF commands to edit the bottom part of the Event Master Record Function screen. Enter a valid dependency for this version of the event.


ASG-Zeke Event Master Record Function EDIT Command ===> Scroll ===> PAGE Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN Evt: 000006 Type: JOB Job: TSKKGUT1 Evt Name: ZEKE51TST6 Calid: A Ver: 00000 Info: Platform: MVS ****** ***************************** Top of Data ***************************==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 (EOE ZEKE51TST5 AND EOE ZEKE51TST4 AND EOE ZEKE51TST1 AND EOE ZEKE51TST2000002 AND EOE ZEKE51TST3) ****** **************************** Bottom of Data *************************

4 Events

151

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 145 for a complete list of valid keywords.

4 Press Enter. The event version is updated with the WHEN conditions.

5 To define a dependency for another version of the event, enter ADD # (where # is the version number) on the Command line. Repeat steps 3 and 4.

You can use the same dependency for multiple versions of an event using the COPY command. For example, to copy the dependency from version 7 to version 8, display the Event Master Record Function screen for version 7. Enter COPY 8 on the Command line. The dependency is copied to version 8, and the screen is displayed in Edit mode for version 8. If you do not specify a version number to copy to, Zeke selects one for you.

Viewing WHEN Conditions for All Event VersionsYou can view the WHEN conditions that are defined for each version of an event.

To view WHEN conditions for all event versions

1 Access the Event Master Definition screen for the desired event as instructed in “Accessing the Event Master Record” on page 82.



152

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

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

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 go to the Event Master Record Function screen to view the remainder of the clause. To do so, use the Browse line command as described below.

3 Perform the steps in the Action column in the following table, depending on the desired results.

ASG-Zeke WHEN/SET Clause Directory Command ===> Scroll ===> PAGE Primary Commands: ADD Line Commands: E - Edit B - Browse D - Delete Evt: 000032 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******************************


Add a dependency for a new version number

Enter ADD ver# on the Command line (where ver# is the number of the version you are adding). For example, ADD 5. Press Enter.

The Event Master Record Function screen is displayed in Add mode. See “Defining a WHEN Condition” on page 150 for further instructions.

Browse the WHEN conditions for a particular version of the event

Enter B to the left of the dependency you want to browse. Press Enter.

The Event Master Record Function screen is displayed in Browse mode.

4 Events

153

Delete the WHEN conditions for a particular version of the event

Enter D to the left of the dependency you want to delete.

The Event Master Record Function screen is displayed and you are asked to confirm the deletion. Type DELETE on the Command line and press Enter to confirm, or press F3 to cancel.

Or,

1 Enter E to the left of the dependency you want to edit. The Event Master Record Function screen is displayed in Edit mode.

2 Type DELETE on the Command line and press Enter.

3 Type DELETE on the Command line again and press Enter to confirm, or press F3 to cancel.

Edit the WHEN conditions for a particular version of the event

Enter E to the left of the dependency you want to edit.

The Event Master Record Function screen is displayed in Edit mode.

When finished editing the dependency, press Enter to save your changes.



154

Condition CodesCondition code validation is used to:

• Flag a job as abended based on end-of-job (EOJ) or end-of-step (EOS) condition codes

• Cancel a job based on EOS condition codes

• Define an acceptable range of condition codes based on EOS

• Define EOJ and EOS condition code checking for an event

• Maintain the maximum condition code at EOJ

A condition code is not considered an abend by Zeke unless the operating system considers it an abend (or unless you manually define it as an abend).

The condition code can be defined 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.

Zeke checks any specified step names first. Then, after the job completes, the maximum condition code for the job is checked.

For every step specified, Zeke searches for the first match on STEP NAME, PROC STEP, OPERATOR, and RANGE. If a match is found, Zeke performs the specified action and the search ends. If there is no match, no action is taken.

If an end-of-job condition is specified (i.e., EOJ CC), then that condition is compared at the end of the job to the maximum condition code from any step in that job. A condition code value that is acceptable at the step level can be designated as AEOJ at the job level.

Note:If you have Zebb installed, condition code checking should be performed in Zeke.

To add, update, or delete condition codes

1 Access the Event Master Definition screen as instructed in the procedure “Accessing the Event Master Record” on page 82.

2 From the Event Master Definition, enter CCODE on the Command line and press Enter.

4 Events

155

The Condition Code Validation screen is displayed.

3 Perform the steps outlined in the Action column, depending upon the desired result:

ASG-Zeke Condition Code Validation EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE51CC Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC STEP01 ******** GT 8 F STEP02 ******** NE 16 O ******** ******** GT 0 C


Add a new or edit an existing condition code

Ensure you are in Edit mode. Go to step 4.

Delete a single condition code

Enter D on the left side of the screen next to the condition code you want to delete and press Enter.

Insert a new line after this line

Enter I on the left side of the screen next to the line you want to insert after and press Enter.

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

Repeat this line Enter R on the left side of the screen next to the line you want to repeat and press Enter.


156

4 Enter information in the following fields.

Field Description

Stepname The JCL step name. If the step is in a procedure, enter the step name that executes the procedure. If the stepname is nulls or blanks, enter the procstep name.

You can use an asterisk as a wildcard character to identify a generic step name. For example, ***STEP5 selects step names with STEP5 in positions 4 through 8.

Always list the most specific steps first, and the most generic steps last. For example, list STEP3 before ******** (see “Sample Condition Code Entries” on page 158 for detailed examples).

Procstep 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 procedure stepname. For example, ***PROC5 selects a procedure stepname with PROC5 in positions 4 through 8.

Operator Operator indicating when to perform a specified action.

Code Meaning

EQ When the condition codes are EQual.

LE When the condition code is Less than or Equal to the specified condition code.

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

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

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

NE When the condition codes are Not Equal.

RA When the condition code is in the specified RAnge.

Low The code to compare. If Operator is RA, the lowest code in the range to compare.

High The highest code to compare. Only make an entry in this field if the Operator is RA, to create a range.

4 Events

157

5 Use the EOJ CC line to specify condition codes to compare at the end of the job.

a Make entries in the Operator, Low, and High fields just as you do for step-level checking.

b In the Action field, enter F. This is the only valid action for the job-level. Checking will be done at the job end for the maximum condition code from any step in this job. This checking is done independently of any step-level checking specified.

6 When you have finished updating condition code information, press Enter.

Action The code that identifies the action to take when the condition code meets the specified criteria

Code Meaning

F Flag the job as Failed during end of job processing.

C Cancel the job at this step and flag it as Failed during end of job processing.

O Continue processing.

Field Description


158

Sample Condition Code EntriesThe following sample screens present a few different scenarios that might help you when defining your condition codes.

In this first example, the ******** ******** acts as a generic condition code and applies to all steps except STEP3. If STEP3 receives a condition code 4, job processing continues; but if any other step gets a condition code greater than zero, the job is marked AEOJ and is cancelled.

In the following example, EOJ CC takes priority since it is encountered first in the list. Therefore, the conditions for STEP3 and STEP5 are ignored, and the job is marked AEOJ, even if STEP3 receives a condition code 4 or if STEP5 receives a condition code 8.

ASG-Zeke Condition Code Validation EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE51CC Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC STEP3 ******** EQ 4 O ******** ******** GT 0 C

ASG-Zeke Condition Code Validation EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE51CC Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC GT 0 F STEP3 ******** EQ 4 O STEP5 ******** LE 8 O

4 Events

159

If you want to use the above example but you want the conditions for STEP3 and STEP5 to be checked, define the condition codes as shown in this example.

Here is the same scenario, but with a PROCSTEP defined.

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

ASG-Zeke Condition Code Validation EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE51CC Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC STEP3 ******** EQ 4 O STEP5 ******** LE 8 O ******** ******** GT 0 F

ASG-Zeke Condition Code Validation EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE51CC Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC STEP3 PSTEP3 EQ 4 O STEP5 ******** LE 8 O ******** ******** GT 0 F


160

If the JCL step name is nulls, and the procedure MYPROC contains the step MYSTEP define the condition codes as follows.

ASG-Zeke Condition Code Validation EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat line Event: 000011 Jobname: SPTEXD11 System: ZEQA Event Name: ZEKE51CC Operators: EQ NE LE LT GE GT RA =Range Actions: F = Fail, C = Cancel, O = Ok Stepname Procstep Operator - Range - Action Low High EOJ CC MYSTEP EQ 4 O ******** ******** GT 0 F

4 Events

161

Work CentersWork center events (work centers) are tasks that require manual intervention. For example, events that require any of the following:

• User input, such as dates or check numbers

• User approval

• Completion of a manual task, such as data entry

Work centers allow the user to communicate directly with the schedule. 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 perform many functions, including:

• Scheduling manual tasks that need to be complete by a certain time, Zeke lets you know when an event is late

• Running request jobs exactly when you need them, operator notification or intervention is not necessary

• Approving an event for processing

• Setting Zeke/OASIS variable values

• Triggering other events that are in the schedule

• Acting as a prerequisite for another event, completion of a work center satisfies an EOE dependency.

• Setting a variable through a work center and using that variable with the VAR keyword in a dependency

Note:While work centers can be predecessors for other events, they cannot have their own WHEN clause. Instead, work centers can have SET clauses, as explained in the following sections. Work centers also do not use resources.

Variables in Work CentersWork centers are often used to set variables. You can specify for a work center to set a variable to a specific value and then use that value as the prerequisite for another event.

For example, suppose you are waiting for management approval before running a job. You can set up a work center to be completed when approval is obtained. Let’s say you set up a variable called $APPROV. Completing the work center sets the variable $APPROV to the value GO. The work center event would contain the WHEN condition $APPROV EQ GO. When the work center is completed, $APPROV equals GO and the dependent job is triggered.


162

SET ClausesZeke or OASIS variables can be set to a specified value when a work center is completed. The SET clause defines how a variable value is set when a work center is completed. The format of the SET clause is similar to a WHEN condition that uses the VAR keyword, except that only an EQUAL condition can be specified. For example,

(VAR $TEST01 EQ PROCEED AND VAR $TEST02 EQ WAIT)(XVAR TEST03 EQ 'A VALUE WITHIN DELIMITERS')

Use the following keywords in the SET clause statement:

Keywords

Zeke OASIS Description

VAR XVAR Variable is automatically set to the specified value when the work center is completed. The operator cannot change the value.

(VAR $JOB1 EQ 45)

When the operator completes this work center, the $JOB1 variable is automatically set to 45.

?VAR ?XVAR Variable value can be entered by the operator before completion of the work center; if desired (the operator is not required to change the value). When the operator completes an event with a ?VAR or ?XVAR, Zeke displays a screen for entering the variable value.

Example:

(?XVAR DATE EQ 'MM/DD/YYYY')

In this example, 'MM/DD/YYYY' is the default value and is retained unless the operator enters a new value.

When the operator completes this work center, the next Work Center Control Functions screen is displayed and prompts the operator to enter the current date.

When using OASIS variables in a SET clause, do not enclose the variable name in the substitution prefix/suffix (the $( ), or additional prefix/suffix defined for your system).

OASIS variables qualified by jobname cannot be used in work centers. (Refer to your 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 enter the value for $TEST03 and Zeke automatically sets the OASIS variable TEST02 to YES.

4 Events

163

Setting Up Work CentersWork centers are typically set up by scheduling personnel and completed by data center operators.

To set up work centers


2 Enter information in the following fields to define a work center.

ASG-Zeke Event Master Definition EDIT Command ===> Event===> Primary Commands: ADD BROWSE COPY COPYALL DEACT DELETE DOC EDIT OCCURS PATH PRED REACT RESOURCE SUCC WHEN Template: N Permanent: N Milestone: NEvt: 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: 00000 Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Operok: N Times: 001 Freq: Freqcalc: S Trig: A WorkCtr Line 1: OBTAIN MGMT OK FOR CHECK RUN WorkCtr Line 2: WorkCtr Line 3: WorkCtr Line 4: WorkCtr Line 5: WorkCtr Line 6:

Field Description


Desc/Desc2 A user-assigned description of the event. This description is used on summary screens and printed on reports to help users identify the event.



164

Usrid An eight-character code used to determine which users may access the event. Zeke supports mixed-case user IDs. Be sure to enter the desired user ID in the correct case (upper, lower, or mixed).


System The system or pool that owns the event. An event is associated only with one system. This is the system the event is dispatched from, not necessarily the system the EMR is defined on.

Verload The number of versions of this event to be loaded during the schedule build.

For example, if Verload is set to 3, schedule build adds event records to the schedule for three versions: versions 1, 2, and 3. This field defaults to zero. If Verload is set to zero, only one version of the event (version zero) can be in the schedule at a time. If Verload is set to one, only one version is created by the schedule build, but any number of versions can be added to the schedule after schedule load using the ZADD command (up to 32,767 versions).



WorkCtr Line The description of the work center activity. This information serves as instructions to the work center user. Up to six lines of comments can be entered. If more are needed, use the Documentation facility to add more notes.

Field Description

4 Events

165


4 Press Enter.

The changes are saved and the screen is displayed in Update mode. If you are adding the event, an event number is assigned.

5 To set up a SET clause for this work center, enter WHEN on the Command line and press Enter.

The Event Master Record Function screen is displayed.

6 A SET clause is used instead of a WHEN condition for work center events. Enter the SET clause, enclosed in parentheses, and press Enter.

See "SET Clauses" on page 162 to get an understanding of the function of the SET clause. See “IF Clauses On SET Statements” on page 359 for help defining the prerequisites that must occur before the event can be dispatched (if any).

The changes are saved and the screen is re-displayed in update mode.


Field Description

App A user-assigned code to identify the application the event is a part of.

Grp A user-assigned code to identify the group the event is a part of.

ASG-Zeke Event Master Record Function EDIT Command ===> Scroll ===> PAGE Primary Commands : ADD BROWSE CANCEL COPY DELETE SAVE WHEN Evt: 000013 Type: WORK Job: Evt Name: Calid: A Ver: 00000 Info: ***** ***************************** Top of Data ****************************==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 (?VAR $JOB1KG EQ XXXXXX) ***** **************************** Bottom of Data **************************


166

8 Be sure the operator has access to Zeke. If desired, you can set up the user’s Zeke operator ID so that when they log on to Zeke, the Work Center Selection Criteria screen is automatically displayed. See “Setting Up Operator IDs” on page 379 for more information.

a Enter A to create a class ID with auto-entry access to the Work Center function.

b Associate the user’s operator ID with the class ID and with the user ID of the work center event.

9 The next time the SCHEDULE function runs, the work center event will be scheduled (assuming the OCCURS clause is true).

10 Be sure all operators are aware of their user IDs for their work center events and how to log on to Zeke.

Completing Work CentersBefore an operator attempts to complete a work center, be sure the operator has access to the Zeke Work Center function.

To complete a work center

1 Depending on how your operator ID is set up, the Work Center Selection Criteria screen may automatically display when you log on to Zeke. Go to step 3.

2 If the Work Center Selection Criteria Screen does not automatically display when you log on to Zeke, then from the Zeke Primary Menu, enter 5 and press Enter.

The Work Center Selection Criteria screen allows you to display a directory of work center events.

ASG-Zeke Work Center Selection CriteriaOption ===>

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

.-------- Selection Criteria --------. | | | UserID => KAC | | App => | | Group => | | System => | | | '------------------------------------'

4 Events

167

3 Enter one of the menu options on the Option line, depending on whether you want to see completed work centers only, uncompleted work centers, or both.

4 Optionally, enter selection criteria to view a specific work center or group of work centers. If you leave a field blank or enter an asterisk only, then that field is not used to restrict the group of work centers selected.

An asterisk (*) in any position performs a wildcard search for all positions following it. For example, ABC* in the UserID field selects all work centers assigned to users whose Zeke ID begins with ABC.

A question mark (?) in any position performs a wildcard search for that one position. For example, A?C selects all records beginning with A, ending with C, and with any character in the second position.

The wild cards can be used together. For example, enter R?M* for all user IDs beginning with R, with any letter in the second position, with M in the third position, and with any character in the remaining positions.

5 Press Enter.

The Directory of Work Center Events is displayed.

Field Description

UserID Enter selection criteria to specify the group of user IDs to select. Zeke supports mixed-case user IDs. Be sure to enter the search criteria in the correct case (upper, lower, or mixed).

App Application name for the work center.

Group Group name for the work center.

System System where the event executes.

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


168


7 The Work Center Control Function screen is displayed in browse mode.

Note:Press Enter to display additional SET statements when there are multiple variables.


Browse the event Enter B to the left of the Event field. Use this command before completing the work center if SET=N.

Complete the event Enter C to the left of the Event field. If SET=N, the event status is changed to DONE.

If SET=Y, the Work Center Function screen is displayed and you are asked to verify the variable value or enter a new one. Go to step 8.

Disable the event Enter A to the left of the Event field, if the event is not considered part of the schedule. The status is updated to DISABLED.

Enable the disabled event Enter N to the left of the Event field. The status is updated to ENABLED.

Refresh the event Enter R to the left of the Event field. This changes a complete event to NOT DONE.

Display the Work Center Doc. Segments Screen

Enter O to the left of the Event field. See “Accessing Event Documentation” on page 181.

ASG-Zeke Work Center Control FunctionCommand ===>

Primary Commands: COMPLETE DISABLE DOCUMENT ENABLE REFRESH

Event: 000229 Event Name: PAYCHECK System: AAppl: PAY Group: PAY UserID: KAC Set ver: 00000

Schd: 00:00 Sdate: 01/30/2007 Rdate: 01/30/2007 Today:01/30/2007Late: Times: 001 Freq: * DONE * Time:16:01:51 (40:01:51)Comment Line 1: ENTER THE STARTING CHECK NUMBER AND PRESS ENTER.Comment Line 2:Comment Line 3:Comment Line 4:Comment Line 5:Comment Line 6: Set: (?VAR $PAYCHECK EQ 'NNNN')

4 Events

169

The Work Center Control Function screen is displayed in update mode.

8 To use the current value and complete the work center, press F3.

Or

To change the value and complete the work center, enter a new value in the New Value field. The variable value can be numeric or any alphanumeric combination up to 64 characters in length.

9 In the Force Upper field, specify of the following codes if the Current Value includes alpha characters:

Note:If the Current Value is numeric only, the Force Upper option is ignored.

ASG-Zeke Work Center Control FunctionCommand ===>

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

Event: 000229 Appl: PAY Group: PAY UserID: KACEvent Name: PAYCHECK System: A Set ver: 00000

Schd: 00:00 Sdate: 01/30/2007 Rdate: 01/30/2007 Today: 01/30/2007Late: Times: 001 Freq: NOT DONE Time: 15:59:27 (39:59:27)Comment Line 1: ENTER THE STARTING CHECK NUMBER AND PRESS ENTER.Comment Line 2:Comment Line 3:Comment Line 4:Comment Line 5:Comment Line 6:

Data-Name: $PAYCHECKCurr Value: 1001 New Value: 'NNNN'Force upper: Y

Code Meaning

Y Forces the Current Value string to uppercase.

N Keeps the case of the Current Value exactly as entered. Specify this code if you need to allow mixed-case values for variable substitution.


170

10 Press Enter.

A verify screen is displayed after all the variables are set.

11 Perform the steps in the Action column, depending upon the desired result:

ASG-Zeke Work Center Control Function Row 1 to 2 of 2Command ===> Scroll ===> PAGE

Primary Commands: COMPLETE CANCEL

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


Confirm the values are correct and complete the work center

Enter COMPLETE on the Command line and press Enter.

The Work Center Directory is displayed. The status is updated to DONE.

Do not set the values, or do not complete the work center

Enter CANCEL on the Command line and press Enter.

The Work Center Directory is displayed. The status is unchanged.

4 Events

171

Auto RepliesZeke allows you to respond automatically to outstanding replies (WTORs) from your Zeke-controlled jobs that have static or predictable responses. Replies can also use Zeke or OASIS variables to substitute all or part of the reply text. They can be limited by date, step, and program. Up to 999 replies can be defined for a single job. For example, replies can be triggered by any portion of the text of the message, message ID, or unique text string. Replies can even be triggered by suppressed messages. Each reply is called an element.

Note:Auto replies are not supported in remote jobs. If a remote job containing an auto reply is dispatched, it must be replied to manually on the remote system.

Related Generation OptionsThree generation options affect automatic replies for your systems:

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 “Setting Auto Replies” on page 303, 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, use the ZDISABLE command.

Generation Option Description

Aur Enables or disables automatic responses to messages and replies.

Aurintv Specifies the interval to check for automatic responses.

Aurmsg Indicates if the operator is notified of auto response issues.


172

Maintaining Auto Replies

To maintain automatic replies for a job event

1 Check the Aur, Aurintv, and Aurmsg generation options to determine:

• Global setup of automatic replies for your systems. See “Setting Auto Replies” on page 303.

• If there are exceptions to the global setup of automatic replies, use ZDISPLAY, ZENABLE, and ZDISABLE operator commands where applicable. See “Displaying, Enabling, or Disabling Auto Replies” on page 175.


3 Enter AUTORPLY on the Command line and press Enter.

• If auto replies exist for the event, the Auto Reply Summary screen is displayed. Go to step 4.

• If auto replies do not exist for the event, the Auto Reply Function screen is displayed. Go to step 5.

The Auto Reply Summary screen provides a list of all auto reply elements that have been defined for the event.


ASG-Zeke Auto Reply Summary COMMAND ===> SCROLL ===> PAGE Z1113000 Primary Commands: ADD DELALL Line Commands: B - Browse D - Delete E - Edit Event: 000019 Jobname: SPTEXD19 System: ZEQA Event Name: EKGSTRT1 NUM ----------------------- Message Text ----------------------- PROGRAM 001 TEST MSG 001 ENTER GO TO PROCESS ***************************** Bottom of data ******************************


Add an auto reply element Enter ADD on the Command line and press Enter. Go to step 5.

Delete all auto reply elements Enter DELALL on the Command line and press Enter. To confirm the delete, press Enter again.

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

4 Events

173

The Auto-Reply Function screen is displayed.

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.


Edit the auto reply element Enter E to the left of the NUM field and press Enter. Go to step 5.

Delete the specific auto reply element

Enter D to the left of the NUM field and press Enter. To confirm the delete, press Enter again.

ASG-Zeke Auto-Reply Function EDIT Update completeCommand ===> Primary Commands: ADD BACK BROWSE DELALL DELETE EDIT NEXT Event: 000019 Jobname: SPTEXD19 System: ZEQA Event Name: ZEKE51CC Desc: EKGSTRT1 Desc2: Automatic Reply Element Number: 001 Msg text: ENTER GO TO PROCESS Reply: GO Effective as of: 01/01/2007 <== MM/DD/YYYY Effective until: 06/01/2007 <== MM/DD/YYYY Job step name: STEP1 Program (Exec):

Field Description

Msg Text Message to be replied to. This does not need to be the whole message; just enough to make a unique match. The message ID is usually a unique identifier.



174


Reply Reply you want Zeke to issue to the message.

For example:

To enter a null reply... Leave Reply field blank.

To enter a static reply... Enter YES in the Reply field, for example.

To use a variable for a reply...

Enter $CURDATE in the Reply field, for example.

To use a variable with constant values in a reply...

In the reply field, enter, for example:

YESTERDAY WAS $(PREVDATE)

Effective As Of Date the reply goes into effect, formatted as shown on the screen.

Effective Until Date the reply expires, formatted as shown on the screen.

JOB STEP NAME OS job step name that issues the message text. The auto reply is only valid if this job step issues the message.

Program (EXEC) Program name that issues the message text. The auto reply is only valid if this program issues the message.

Field Description

4 Events

175

Displaying, Enabling, or Disabling Auto RepliesYou can use the ZDISPLAY, ZENABLE, and ZDISABLE operator commands to manually display, enable, or disable automatic replies for a job event.

Displaying Auto Replies (ZDISPLAY)The ZDISPLAY command performs many functions. One of those functions is to display the active automatic reply elements for a given jobname. If a job event is running, Zeke displays the messages and replies that are active for that job event.

To display active automatic reply elements

Issue the ZDISPLAY command with the JOBNAME and REPLY parameters. For example, to display messages and replies for jobname TESTXYZ, use:

ZDISPLAY JOB TESTXYZ REPLY

Enabling Auto Replies (ZENABLE)The ZENABLE command has two functions.

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

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

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

To enable an auto reply for an event

Issue the ZENABLE command with the REPLY and EVENT parameters. For example, to enable previously disabled auto replies for job 55, use:

ZENABLE JOB 55 REP

Disabling Auto Replies (ZDISABLE)The ZDISABLE command has two functions.

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

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


176

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

Issue the ZDISABLE command with the REPLY and EVENT parameters. For example, to disable the auto reply for job 77, use:

ZDISABLE REP JOB 77

Maintaining JCLYou can store JCL for events in the Zeke database. However, it is not necessary if you have a JCL library facility. Zeke can retrieve JCL from a number of JCL library facilities, such as Bim-Edit, CMS, Librarian, Panvalet, and PDS. Before you can retrieve JCL for an event, you must first define your installed JCL libraries to Zeke.

Setting JCL Source OptionsThis section tells how to identify to Zeke the JCL libraries to be used. Each library type requires some steps to be performed by the systems programmer. Refer to the section on JCL library support in your ASG-Zeke for z/OS Installation Guide for information on link editing the third-party libraries or installing PDS or CMS support.

To set the JCL source generation options

1 Enter =4.1 on any Zeke Command line and press Enter.

2 Enter E to the left of system you want to change and press Enter.

Note:'********' is the generic system. If generation options are not set for a system, it defaults to the generic system values.

ASG-Zeke Option System Directory Row 1 to 1 of 1 Command ===> Scroll ===> PAGE System ===> Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete E - Edit System ******** MEDAZ520 ZK51VLT***************************** Bottom of data ******************************

4 Events

177

The Generation Options screen is displayed with the options in alphabetical order.

3 Use the F8 or F7 keys to scroll, as necessary.

4 Depending on the JCL libraries you use, update the following options.

ASG-Zeke Generation Options EDIT Command ===> Scroll ===> PAGE Zeke System: ******** Abhold: N (Y or N) Yes to hold recurring events if abended Aur: Y (Y or N) Yes to enable automatic responses Aurintv: 01 (1 - NN) Number of seconds to check auto responses Aurmsg: Y (Y or N) Yes to inform operator auto. response issue Batoprid: BATCH (xxxxxxxx) Default security batch operator id Batsec: N (Y or N) Yes for Zeke to perform batch security Bimappl: (xxxxxxxx) Bimedit application name Bimpasw: (xxxxxx) Bimedit access password Bimuid: OMIT (xxxx) Bimedit access userid Bypjob: N (Y or N) Yes for Zeke to bypass all Power Job cards Calcmem: Y (Y or N) Yes to calculate virtual memory (VSE) Calctap: Y (Y or N) Yes to calculate tape drive usage Chgval: Y (Y or N) Yes to display Variable update message Cmdcons: Y (Y or N) Yes to route cmd response to console Cmsftype: JCL (xxxxxxxx) Default CMS filetype Commctl: Y (Y or N) Yes to retain Work Events until completed Condrdv: SYS000 (xxxxxx) Condor camlib device name Condrlb: OMIT (xxxx) Condor camlib qualifier Condrver: 001 (xxx) Condor version id

Library Generation Options

Librarian If you do not know your Librarian number or codes, contact your Librarian vendor.

Fairmod Your Librarian modification number. (Librarian 3.1 or higher.)

Fairopn Your Librarian options code. (Librarian 3.1 or higher.)

Fairrec Your Librarian record code. (Librarian 3.1 or higher.)

Librblk Librarian library block size. Zeke uses this number to determine the amount of storage required for Librarian subroutines. The default is 12800.

Librdtf DD name of the Librarian library Zeke uses to retrieve JCL. The default is OMITTED. (The name LIBRJCL is reserved and cannot be used.)


178

Bim-Edit

Bimappl (optional)

Application name of the Bim-Edit to be associated with Zeke.

Bimpasw Unique BIM password.

Bimuid User ID Zeke passes to Bim-Edit in order to receive JCL. The default is OMIT.

Condor

Condrver Your Condor version number. The default is 001.

Condrlb Library that Zeke will pass to Condor to receive JCL. The default value is OMIT.

Panvalet

Pandisk Code indicating the DASD type of the disk where the Panvalet library resides. This field cannot contain blanks.

FBA3340335033753380 (default)33903331 (3330-11 disk devices)

Pandtf DD name of the first Panvalet library to be searched. If a value is not entered, Zeke searches for DD names of PANDDxx. The default is OMITTED.

Panmem Amount of memory Zeke requires to obtain the Panvalet work area. The default is 0240.

PDS

Pdsdd The DD name in the Zeke started task procedure of the partitioned dataset to retrieve JCL.

VM/CMS JCL

Userid The name of the CMS JCL machine.

Library Generation Options

4 Events

179

5 Page to the Defjcl generation option and enter the code specifying the default JCL source type. The default JCL source type is used if none is specified on the EMR.

6 Page to generation option JCL1 and enter one of the JCL sources listed above. You can enter additional JCL sources in the remaining JCL2-JCL5 fields. These options determine which JCL fields display on the Event Master Definition screen.

7 Press Enter to update the options.

8 To activate the updated options, enter ZRELOAD GENOPT on the Command line and press Enter.

Retrieving JCL from the Zeke DatabaseFrom the Event Master Definition screen, you can only retrieve Zeke JCL; however, you can retrieve Zeke JCL and any other valid JCL source from Schedule View. See “Maintaining JCL” on page 232 for further instructions on using Schedule View to retrieve JCL stored within other packages, as well as Zeke JCL.

Note:ZEKEJCL must be defined as a JCL source type on the Generation Options screen. See “Setting JCL Source Options” on page 176 for more information.

To retrieve and maintain JCL that is stored in the Zeke database


Code Meaning

BIM Bim-Edit

CMS CMS file

CONDOR Condor

LIBR Librarian

PAN Panvalet

PDS Partitioned dataset member

ZEKE Zeke JCL

Z14C Source not supported by Zeke (JCL is supplied by the ZEKE14C user exit)


180

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

3 While using this screen, control is passed to the ISPF Text Editor. Use the standard ISPF commands to add, delete, or edit the JCL.

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


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.R220A.LINKLIB.OS3901 000620 //* DD DISP=SHR,DSN=OASIS.R230A.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.R230AM1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDJKL.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDMNO.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.R300A.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.R300A.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *

4 Events

181

Event DocumentationEvent documentation is used to store useful information about the event. There are four areas documentation can be stored.

Accessing Event DocumentationEvent documentation can be maintained through the Event, Schedule View, Documentation, and Work options in the Zeke online facility. All options update the same records. For simplicity, this procedure takes you directly through the Documentation option.

To access event documentation


The Documentation Selection Criteria screen is displayed.

2 Perform the steps in the Action column, depending on the desired result

Documentation Type Description

Scratch Stores brief notes, limited to 10 lines

Note Stores brief notes, limited to 10 lines

Text Stores up to 450 records approximately

Dataset Stores names of datasets used by a job


Update documentation for which you know the event number

Enter EDIT on the Command line. Enter the event number in the Event field. Press Enter.

The Documentation Segments screen is displayed. Go to step 4.

Update documentation for which you do not know the event number

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


182

The Event Documentation Directory is displayed. If an asterisk (*) is displayed in a column, that type of documentation exists for the event.

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

ASG-Zeke Event Documentation Directory Command ===> Scroll ==> PAGE Line Commands: E/E1/E4 - Edit B/Bn - Browse D/D1/D4 - Delete n = 1 through 4 for specific types of documentation 1 2 3 4 Event -Event Name- Jobname Type Scratch Text Tape Note 000001 ZEKE51TST1 MSG * * * * 000002 ZEKE51TST2 MSG 000003 ZEKE51TST3 MSG * * * 000004 ZEKE51TST4 MSG 000005 ZEKE51TST5 MSG 000006 KTEST1 TSKKGUT1 JOB 000007 KTEST2 TSKKGUT2 JOB * 000008 KTEST3 TSKKGUT3 JOB 000009 KTEST4 TSKKGUT4 JOB 000010 KTEST5 TSKKGUT5 JOB * * * * 000011 ZEKE51CC SPTEXD11 JOB 000012 ZEKE51CC SPTEXD12 JOB 000013 WORK * * * * 000014 VCOM 000015 ZCOM 000016 SCOM


Edit scratch pad documentation for the event

Enter E1 to the left of the Event field and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 184.

Edit text documentation for the event

Enter E2 to the left of the Event field and press Enter. Go to “Maintaining Text Documentation” on page 185.

Edit dataset documentation for the event

Enter E3 to the left of the Event field and press Enter. Go to “Maintaining Dataset Documentation” on page 186.

Edit note documentation for the event

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

4 Events

183

The Documentation Segments screen is displayed. If an asterisk (*) is displayed to the left of the documentation type, that type of documentation for the event exists.

4 Enter one of the following codes on the Command line to select the type of documentation to work with:

Delete the specified documentation for the event

Enter Dn to the left of the Event field and press Enter (where n indicates the documentation type):

1 Scratch Pad

2 Text

3 Dataset Name List

4 Note Pad

The asterisk (*) indicating that documentation for the event exists is deleted, and the message:

DOCUMENT RECORD DELETED is displayed.

ASG-Zeke Documentation Segments EDIT Option ===> Primary Command: DELETE Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: A Appl: Documentation Record Selection Options 1 * SCRATCH Scratch pad 2 * TEXT Text information 3 TAPE Dataset name information 4 * NOTE Note pad information


Access scratch pad documentation Enter 1 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 184.

Access text documentation Enter 2 and press Enter. Go to “Maintaining Text Documentation” on page 185.

Access dataset or tape documentation

Enter 3 and press Enter. Go to “Maintaining Dataset Documentation” on page 186.

Access note documentation Enter 4 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 184.



184

Maintaining Scratch Pad or Note DocumentationScratch Pad and Note documentation each allow you to define up to 10 lines of information for an event. These documentation areas are like “sticky notes.” They are used to pass notes from shift to shift, or from one department to another. The operator should always review scratch pad or note pad information before an event runs.

These areas can also be used for “quick reference” information. Besides being displayed online and on Zeke reports, this data can be displayed for events in the current schedule through the Schedule View screen and even directly at the system console by issuing one of the following commands:

ZDISPLAY EVENT 99 NOTE

Or

ZDISPLAY EVENT 99 SCRATCH

Even though there are separate documentation areas for Scratch Pad and Note Information, the screens are identical. This procedure shows the Scratch Pad as an example, but the Note screen works the same way.

To maintain Scratch Pad or Note Documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in “Accessing the Event Master Record” on page 82.

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

ASG-Zeke Documentation Scratch Pad EDIT Command ==> Primary Commands: BROWSE CANCEL DELETE EDIT Line 1 SCRATCH TEXT FOR 30-BYTE NAME JOB 2 3 4 5 6 7 8 9 10 Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: ADesc : 30-CHAR NAME NOM Desc2: Early: Sched: 00:00 Late: Freq: Times: 00001 Vmem : 0* Tapes: 000 Average run time: :00 Jcl: ZEKE

4 Events

185

3 When you finish adding or updating information on the Scratch Pad or Note screen, press Enter to update the data.

Maintaining Text DocumentationThe text documentation allows you to define a sizeable amount of information for an event (up to approximately 450 records).

You can maintain text documentation from the Event, Schedule View, and Documentation options. From the Work Center option, you can only browse text documentation.

To maintain Text documentation

1 Access the Text Documentation screen as instructed in “Accessing Event Documentation” on page 181.

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

3 Use standard ISPF editing commands to edit the text.

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


ASG-Zeke Text Documentation EDIT Command ===> Columns 000 000 Scroll ===> PAGE Event: 000031 Jobname: A2345678 Event Name: TESTNAME System: A ****** *************************** Top of Data *****************************==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 tHIS JOB USES TEH 30-CHAR NAME. REVIEW ALL 30 CHAR ****** *************************** Bottom of Data **************************


186

Maintaining Dataset DocumentationDataset documentation can be accessed via the Events, Schedule View, and Documentation options.

To maintain dataset documentation required by an event

1 Access the Data Set Name List screen as instructed in “Accessing Event Documentation” on page 181.


ASG-Zeke Data Set Name List EDIT Command ===> Scroll ===> PAGE Primary commands: BROWSE CANCEL DELETE EDIT Line commands: D Delete line I Insert line R Repeat Event: 000031 Jobname: A2345678 System: A Event Name: TESTNAME I/O T/D Ver --------------Dataset Name------------------ I T 001 JNM.TAPE.STORE ***************************** Bottom of data ******************************

Field Description

I/O The code that identifies the dataset type.

Code Meaning

I Input dataset (default)

O Output dataset

T/D The code that identifies the dataset media type.

Code Meaning

T Tape (default)

D Disk

Ver The dataset version number. This is a required field for input datasets; otherwise, leave it blank. For example, 001 (default) for the most current dataset; 002 next current dataset, etc.

Dataset Name The dataset name.

4 Events

187




Delete a line Enter D to the left of the I/O field and press Enter.

Insert a new line after this line

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

Repeat this line Enter R to the left of the I/O field and press Enter.


188

Event Activity AccountingZeke provides you with a record of event accounting information so you can view the last date and time an event master record was updated and by whom. Event accounting also includes information concerning the last three dispatches of the event.

To view event accounting information


2 Enter OCCURS on the Command line and press Enter.

The Event Record Occurs Clause screen is displayed.

3 Enter ACCTG on the Command line and press Enter.


ASG-Zeke Event Record Occurs Clause EDIT Command ===> Primary Commands : BROWSE EDIT ACCTG OCCHIT Evt: 000006 Type: JOB Job: TSKKGUT1 Evt Name: ZEKE51TST6 Calid: AVer: 00000 Occurs: (WEEK.2)

4 Events

189

The Event Master Record Accounting screen is displayed.

The screen displays the following event activity information:

• Number of times the event has been dispatched.

• Last date/time the EMR was updated, and by which user.

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

• Status of the last execution that ran to completion:

— SUCCESS means the event completed successfully (or the event completed successfully after failing once).

— FAIL means the event ended abnormally.

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

— F/FAIL means the event was forced to an abnormal completion.

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

• Details about the last three dispatches.

ASG-Zeke Event Master Record Accounting BROWSE Command ===> Primary Commands: BROWSE EDIT OCCHIT Evt: 000005 Type: JOB Job: MBCBR14 Ename: IEFBR14 System: MBCX260A Dispatched 22 Times Last Update: 01/14/2007 15:33 by DEVMBC Start: 01/14/2007 17:37 End: 01/14/2007 17:37:30 Job ID: Version: 0 Sched Date: 01/14/2007 Status: FAIL Dispatch Date 01/14/2007 at 17:37:00 Tapes: 0 Vmem: 0 Dur: __:__:__ Cputime: __:__:__ Comp.code C0000 Dispatch Date 01/07/2007 at 11:31:00 Tapes: 0 Vmem: 0 Dur: __:__:__ Cputime: __:__:__ Comp.code C0000 Dispatch Date 01/02/2007 at 12:25:00 Tapes: 0 Vmem: 0 Dur: __:__:__ Cputime: __:__:__ Comp.code C0000 ------------- Avg: __:__:__


190

Note:Most time values are evaluated by Zeke and expressed in hours and minutes only. However, because they affect if and when any dependent events are triggered, dispatch and end times are evaluated and expressed in hours, minutes, and seconds.

This is especially important for certain extended dependencies. For example, suppose Job B has an extended dependency on Job A. When Job B is loaded into the schedule, Zeke checks to see if 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.

4 If desired, you can directly access the OCCURS Hit Resolution screen, or return to the previous screen.

191

5Chapter 5:Creating and Monitoring the

Schedule

Once jobs are defined to Zeke, it is time to create a schedule. The progress of the scheduled jobs can be monitored, altered, and maintained through the ISPF online Schedule View function.

Topic Page

Scheduling 192Logical Day (48-hour Clock) 192Creating the Zeke Schedule 194Setting Zeke to Schedule Itself 196Adding Events to the Schedule As They Are Created 197Schedules Downloaded to Zeke Agent 197How Zeke Determines Dispatching Sequence 198Forecasting and Simulating the Schedule 199

Using Schedule View 202Schedule View Commands 211Accessing Other Online Information 217Refreshing the Screen 219Sorting Schedule View Information 220Selecting Fields to Display 222Changing the Date Display Format 224Viewing and Maintaining WHEN Conditions 225Displaying Event Status 227Accessing Resources for an Event 229Using the ZOOM Feature 230

Maintaining JCL 232Zeke PDS JCL Override 234

Validating JCL 236Invoking ASG-JCLPREP 237Invoking JOB/SCAN 239Using ZSCAN 241

Creating Your Own Line Commands 242

ZCOM Option 243

PathFinder 244


192

SchedulingThe main purpose of Zeke is to ensure your jobs are dispatched in the most efficient and timely order. To accomplish this, Zeke creates a schedule of jobs using the SCHEDULE function.

Along with creating a daily schedule of actual jobs, 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.

Logical Day (48-hour Clock)Zeke supports a 48-hour clock, which lets you schedule according to a logical day. If you have events that run past midnight, you can still consider those events to be part of the previous day’s schedule run.

The following example is based on a three-shift day. According to the typical 12-hour clock, shift 1 starts at 8:00 AM, shift 2 at 3:00 PM, and shift 3 at 11:00 PM,. Shift 3 ends the next morning at 8:00 AM.

In the example, using a logical day, shift 1 starts at 08:00, shift 2 at 15:00, and shift 3 at 23:00. 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 part of the same logical workday as shifts 1 and 2.

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

Normal Time Logical Day Time

Shift Start End Start End

1 8:00 AM 3:00 PM 08:00 15:00

2 3:00 PM 11:00 PM 15:00 23:00

3 11:00 PM 8:00 AM 23:00 32:00

Topic Page

5 Creating and Monitoring the Schedule

193

When the SCHEDULE function runs, it selects every event within 48 hours to be part of the day's schedule. For example, if the schedule runs on Monday at 08:00, events are selected if the OCCURS clauses match Monday and the schedule time is between 00:00 and 47:59.

Note:An event with a schedule time of 48:00 is never dispatched 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.

An event defined as OCCURS(MONDAY) at 27:00 is processed the same time as an event defined as OCCURS(TUESDAY) at 3:00 A.M. The difference is that the first event is included in Monday's schedule run and is considered Monday's event, while the second event is included in Tuesday's run.

Event Weekday Time Schedule Run Date

A Monday 27:00 Monday (actually runs on Tuesday)

B Tuesday 03:00 Tuesday


194

Creating the Zeke ScheduleSchedule queue records (SQRs) control scheduling and dispatching. The schedule is comprised of all the SQRs created for each Zeke system. The SQRs are created using the SCHEDULE function of the ZEKE batch utility.

Executing the SCHEDULE function:

• Deletes completed jobs and retains uncompleted jobs from the previous day's schedule.

Note:Events with no other outstanding dependencies are dispatched immediately after the schedule load completes.

• Analyzes each job defined to the Zeke database and determines whether the job is scheduled to occur during the upcoming schedule period.

Note:Events with no dispatch time, and not scheduled for a future date, are marked time-satisfied immediately.

• Analyzes each scheduled job and determines whether the job needs to be downloaded to a remote Zeke Agent system for processing.

Note:When a schedule is created containing jobs set up to be downloaded to a Zeke Agent target, Zeke compares the subset of the schedule to be downloaded with any existing schedules on Zeke Agent before downloading those jobs.

Zeke provides a user exit that allows you to change various fields in the SQRs during the schedule build. Refer to your ASG-Zeke for z/OS Installation Guide for more information on the ZEKE02MX user exits.

For instructions on setting Zeke to schedule itself, “Setting Zeke to Schedule Itself” on page 196.


195

To run the SCHEDULE function to create the daily schedule

1 Run the following job at least once a day.

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

Note:Refer to your ASG-Zeke for z/OS Reference Guide for additional parameters you can use with the SCHEDULE function.

2 Ensure that the schedule load is complete before executing any other batch schedule runs.

The schedule load is complete when the following message appears on the console:

Z5G03I SCHEDULE LOAD COMPLETE

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

Note:If multiple Zeke systems share a database, the Zeke systems begin the schedule load process after the batch schedule function completes. Each system issues the “Z5G02I Reloading schedule” message at this time. Once its schedule tables have been updated, each system issues the “Z0398I Schedule tables loaded” message. Once all systems have updated their schedule tables, only one of the systems will resolve the weak, EOG, extended, and variable WHEN conditions, after issuing the “Z0399I Weak satisfy” message. Meanwhile, the other systems in the ZekePlex will load the new schedule. Since only one of the systems performs the condition checking, this reduces I/O and shortens the schedule load process. It allows Zeke to load the schedule and begin dispatching events in the new schedule much more quickly. When that one system completes the WHEN condition checks, the schedule load is complete and all systems issue the “Z5G03I Schedule load complete” message.


196

3 Optionally, you can use the REPORT parameter to produce specific scheduling reports depending on the sub-parameters used in conjunction with REPORT. If you do not specify REPORT, all the scheduling reports are produced. Refer to your ASG-Zeke for z/OS Reference Guide for more information on generating scheduling reports using Report Writer.

4 Optionally, you can use the OVERRIDE parameter to include and exclude various jobs, regardless of their OCCURS clauses. Refer to your ASG-Zeke for z/OS Reference Guide for more information on selecting events using the OVERRIDE parameter.

Setting Zeke to Schedule ItselfCreating the schedule as indicated in the preceding procedure allows you to run the SCHEDULE function manually whenever you need to. However, we recommend setting up Zeke so that the schedule runs automatically.

To set up an event so the schedule executes automatically

1 Set up a job event as instructed in “Maintaining a Job Event” on page 92. On the EMR, enter the start time plus 24 hours. For example, if you want the schedule to be created every day at 8:00 A.M., enter a start time of 32:00.

2 Specify the appropriate JCL source to include the JCL described in “Creating the Zeke Schedule” on page 194.

3 Add the OCCURS clause DAILY, so the job creating the schedule will run each day. See “Defining an OCCURS Clause” on page 132.

Note:The following step only has to be performed the first time.

4 ZADD the event with yesterday’s Julian date. For example, if the event number is 100 and today’s date is December 30, 2007, issue the command:

ZADD EV 100 DA 2007364

The schedule is put in the queue with yesterday’s date. When the start time is reached, the schedule load runs and then loads itself in the queue for the next day.


197

Adding Events to the Schedule As They Are CreatedTo create an event and add it to the schedule queue at the same time

1 Define a job event using the EVENT function of the Zeke batch utility. Refer to your ASG-Zeke for z/OS Reference Guide for details.

2 Insert the SCHEDADD parameter at the end of the event definition as shown in this JCL example.

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

3 Submit the JCL.

Schedules Downloaded to Zeke AgentWhen the schedule is created, Zeke checks to see whether any jobs are specified to be downloaded to a Zeke Agent target. Zeke looks at the Netregid specified in the SQR as a job’s target to determine whether the job is to be downloaded.

Zeke first sends a message to the specified Zeke Agent to determine if the set of jobs should be downloaded. A unique Zeke-generated schedule number is used to track and synchronize a schedule downloaded to Zeke Agent. If the newly-generated schedule number differs from the number of the schedule currently downloaded and processing on Zeke Agent, then the new schedule is downloaded to Zeke Agent. If the new schedule number matches the number of the current Zeke Agent schedule, then the schedule is not downloaded.

As SQRs are being downloaded, the download status is reported to Zeke for each job.

If Zeke is unable to download an SQR to its Zeke Agent target, the job is tracked and updated like any other Zeke job until it is ready to dispatch. Then, instead of dispatching the job, Zeke places the job on download hold. Later, when Zeke is able to communicate with the Zeke Agent target, the job will be downloaded and released from hold.

See "Downloading Jobs to Zeke Agent" on page 102 and “Defining Schedule Download Agents” on page 301 for more information on how jobs are downloaded from Zeke to Zeke Agent.


198

How Zeke Determines Dispatching SequenceZeke determines the order in which events are dispatched by evaluating the following event attributes or conditions in sequence:

1 Dispatch priority from the event’s SQR.

2 Whether the event is near its Must Start time. Zeke considers, as applicable, an event’s Not After time, Must End time, average duration, and the value of the Mspintrl generation option. Zeke uses one of the following two formulas to calculate an event’s near dispatch time and evaluate whether to elevate its dispatch priority:

mustend – avgdur – mspintrl = near_dispatch_time

For example, the Must End time for Job ABC is set to 17:00. The event’s average duration is 30 minutes. The value of the Mspintrl generation option is 1 hour (the default value). Zeke gives Job ABC a higher dispatch priority at 15:30.

Or

notafter – mspintrl = near_dispatch_time

For example, the Not After time for Job DEF is set to 11:00. The value of the Mspintrl generation option is 1 hour (the default value). Zeke gives Job DEF a higher dispatch priority beginning at 10:00.

3 Whether the event is past its Late time and the Prilate generation option is set to Yes, (giving priority to late events despite their schedule time).

4 Run date.

5 Schedule time from the SQR.

6 Event number.

7 Version number.

See “Maintaining a Job Event” on page 92 for information on schedule times and other event attributes that affect dispatch. See “Dispatching Messages and Events” on page 288 for details on the generation options that control dispatching.


199

Forecasting and Simulating the ScheduleZeke provides several ways to predict how the schedule will flow without having to actually run the schedule or dispatch jobs. You can find missing prerequisite conditions, set up a logical schedule flow, and even plan for unusual system downtime or hardware maintenance. You can use any of the following methods to plan or forecast your schedule depending on your specific needs:

Occurs Hit Resolution. Allows you to display a calendar showing the days the event will be scheduled. See “Defining an OCCURS Clause” on page 132.

Schedule Forecast. Creates a schedule for a future date allowing you to forecast the schedule and make any necessary changes.

Forecasting the ScheduleThis procedure does not actually activate the schedule.

To create a schedule for a future date

1 Execute the ZEKE utility program using the SCHEDULE control statement.

2 Enter the DATE parameter followed by the date you want to forecast the schedule for (in MM/DD/YYYY format).

3 Submit the JCL.

Note:Refer to your ASG-Zeke for z/OS Reference Guide for information on running the actual schedule.


200

Simulating the ScheduleSchedule Simulation allows you to specify the date, time, system, and resources for an event in the simulation JCL, then run the simulation job separate from the Zeke program. The Zeke database is copied to another dataset, then the flow of jobs is simulated against that dataset. The simulation database must be contiguous.

STARTDATE, STOPDATE, STARTTIME, and STOPTIME are specified according to a 24-hour clock, but jobs scheduled on a 48-hour clock dispatch at the correct time.

Several simulation reports are available, depending on the report keyword you specify.

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

Caution! Do not run the simulation function against the production database. Run simulation against a simulation-copied database only. No other Zeke system should be running against the same database as simulation. Running the simulation function against the production database will destroy the production database.

Refer to your ASG-Zeke for z/OS Reference Guide for a complete list of simulation parameters.

To use the simulation feature

1 Execute the SSS4001 program using the SIMULATE control statement in the SYSIN.

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

Keyword Description

Console Shows the messages produced during simulation.

Exception Shows the exceptions that occurred during simulation.

Schedule Shows the schedule reports if a schedule run was requested.

Jobflow Shows a chart of initiator usage.


201

3 Ensure a ZKSMLOG DD statement with the DCB parameters (LRECL=256, BLKSIZE=5124, RECFM=VB) is included in the JCL. This is the simulation log and is used to generate the reports after the simulation run is complete. To simulate your current schedule, set the SCHEDRUN and SCHEDCLR parameters to OFF, otherwise a new schedule is built by default.

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

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

Note:To run the simulation against a dataspace, use DATASPACE as the value for both the TODD and DATASPACEDD parameters. Refer to your ASG-Zeke for z/OS Reference Guide for information about simulation from a dataspace.

5 Optionally, you can use the REPORT parameter to run specific simulation reports depending on the subparameters used with REPORT.

To print simulation reports from a previous run without rerunning the simulation, ensure the ZKSMLOG dataset was saved from the previous run. Specify only REPORT parameters in the SYSIN control statements and point the ZKSMLOG DD to the saved log.

6 Submit the JCL.


202

Using Schedule ViewSchedule View displays the current scheduled events. From this display, the schedule can be monitored and temporarily updated using simple line commands, as an alternative to Zeke operator commands. Operator commands can also be issued from the Schedule View Primary Command line.

Note:Changes to SQRs are only temporary for that run of the event. The changes are not made to the EMR.

You can choose the information you want to display and the placement of the fields. You can also change the way information is displayed and sorted. These customization options are accessed from the Schedule View Display Characteristics menu (option C on the Zeke Primary Menu). Changes made to display characteristics are valid for the current user and are saved in the user’s ISPF profile. Each user can set up Schedule View according to their preferences.

To update job information from the Schedule View screen

1 From the Zeke Primary Menu, enter 2 on the Option line and press Enter.

The Schedule Information Selection Criteria screen is displayed.

ASG-Zeke Schedule Information Selection CriteriaCommand ===> 1

1 Schedule View Schedule Display and Modification Facility 2 ZCOM List Scheduling System Commands 3 ADD Function Select Event Records "TO ADD" to Schedule 4 ADD by path Select Event Records by path

Event ===>

Permanently save criteria ===> N

Event Types Selection Field Masks ---- Event Status ---- Job: Job Name: Actv: Y Done: Y Msg: Event Name: Pend: Y ABOK: Y Pcom: Application: Sched: Y Fail: Y Work: Group ID: Hold: Y FBOK: Y Vcom: User ID: Late: Y FSucc: Y Zcom: System: / OperOk: N Scom: Disp Class: Needs - TimeOk: N %Actv: REXX: Sched Date: \ WhenOk: N Run Date: Target: Permanent:


203

2 Type 1 on the Command line. To display all events in the current schedule, press Enter. To display particular events, enter selection criteria in any of the following fields and press Enter.

Field Description

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

Selection Field Masks

Enter any information you know about the events you want to select, such as jobname, user ID, run date, etc. You can use * (asterisk) and ? (question mark) to perform wildcard searches. Enter * in any position to search for all positions following it. For example, ABC* in the JOBNAME field selects all events whose jobname begins with ABC. Enter ? in any position to search for that one position. For example, A?C selects all records beginning with A, ending with C, and with any character in the second position.

Event Status Enter Y or N for each status code to indicate whether you want to display events with that particular status.

Status Description

Actv Y selects all active events.

Pend Y selects all pending events.

Sched Y selects all scheduled events. If N, you can select from the secondary statuses:

Hold Y selects all events on hold.

Late Y selects all events that are late.

Needs OperOK Y selects all events waiting on an operator OK.

Needs TimeOK Y selects all events waiting for a certain time.

Needs WhenOK Y selects all events waiting for certain WHEN conditions.

Done Y selects all events with a status of EOJ or AEOJ. If N, you can select from the secondary statuses:

ABOK Y selects all successful events that failed once. The screen status is “Success Failed Once”.


204

Only the records that match the selection criteria are displayed in Schedule View.

Schedule View can be scrolled left and right, as well as up and down to display all of the SQR fields, depending on how you set up your display characteristics. Use the normal ISPF left and right scroll commands to view additional fields.

Fail Y selects all events that failed. The screen status is “Forced”.

FBOK Y selects all events that failed once and then were forced to EOJ. The screen status is “Success Forced Failed Once”.

FSucc Y selects all events forced to EOJ. The screen status is “Success Forced”.

ASG-Zeke Schedule View BROWSE Command ===> Scroll ===> PAGE

Event ===> System=SYSD Selected=0000004 2007.022 15:45 Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When cond ? to list other Line Commands

Line Event Sched Job Evnt Event Event Status Cmd No. Date Name Type Name Reason Code ========================================================================== 000001 2007053 MSG ZEKE51TST1 Queued Need Oper OK 000002 2007053 MSG ZEKE51TST2 Scheduled Time OK 000003 2007053 MSG ZEKE51TST3 Scheduled Time OK 000004 2007053 MSG ZEKE51TST4 Scheduled Time OK 000005 2007053 MSG ZEKE51TST5 Scheduled Time OK 000006 2007053 TSKKGUT1 JOB KTEST1 Scheduled Time OK 000007 2007053 TSKKGUT2 JOB KTEST2 Success 000008 2007053 TSKKGUT3 JOB KTEST3 Active 90% 000009 2007053 TSKKGUT4 JOB KTEST4 Success 000010 2007053 TSKKGUT5 JOB KTEST5 Success 000011 2007053 SPTEXD11 JOB ZEKE51CC Scheduled Time OK 000012 2007053 SPTEXD12 JOB ZEKE51CC Scheduled Time OK 000013 2007053 WORK Scheduled Time OK

Field Description


205

Schedule View displays a variety of information about the scheduled jobs, including the event status and the reason the event is waiting to execute, if applicable. The following table lists the event status codes and their meanings.

The following table lists the reason codes and their meanings.

Event Status Description

Active The event is currently running. The percentage of average duration remaining is displayed to the right of the status.

Dispatching The event is currently being dispatched to JES.

Fail The event ended abnormally.

Fail Forced The event was forced to an abnormal completion.

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

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

Success The event has completed successfully.

Success Failed Once The event ended abnormally, was refreshed, then finished successfully.

Success Forced The event was forced to a successful completion.

Success Forced Failed Once

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

Reason Code Description

Awaiting Retry The event attempted dispatch but failed with a recoverable error. It will attempt to dispatch again.

Comm Record Wait The event is currently being processed by multi-CPU processing. The event will be available for dispatching after the communication record is processed.

Delayed Dispatch Wait Zeke is delaying the event dispatch due to multi-CPU processing requirements.

Disabled The event is disabled and will not be dispatched.

Download Hold The event is being downloaded to a Zeke agent.


206

DSN Hold There are multiple SQRs in the schedule with the same DSN trigger specified. The Dsntrig generation option is set to NT, so Zeke did not trigger any of the events, and the events are on hold.

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

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

Hold The event is on hold.

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

Late The late time has passed.

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

Multiple Systems This status occurs only in XCFONLY sysplexes. The event’s system ID is a pool, therefore the event can be in multiple dispatch queues. Enter the Why command to view the wait statuses for all systems.

Need Initiator The event is waiting for an available initiator.

Need Logical Resources The event is waiting for resources. Issue the ZRESOURCE command to display the resources.

Need Oper Ok The event requires an operator OK (ZOK command) prior to dispatch.

Need Tape Drives The required number of tape drives are not available.

Network Hold The event is on hold due to a networking error.

A network hold is released when the other scheduler or agent re-registers with Zeke.

Network Time Out DMS timed out while waiting for a response reply.

New DQT Entry The event has just been added to the dispatch queue.

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



207

3 Enter EDIT on the Command line and press Enter.

Notduring Wait The event is waiting for the completion of a program or job that is specified in the event's WHEN clause.

OASIS REXX Hold The Zeke REXX event submitted through OASIS ECF abended and the event is on hold.

Operator Hold The event is on operator hold because a ZHOLD command was issued for the event.

Pending The event has been dispatched and is just about to execute.

Posid=No/Rem Hold The POSID generation option is set to No and the Control field on the EMR is set to Yes. With these settings, Zeke has no way to track a remote job, so the event was placed on hold. For Zeke to track a remote job, POSID must be set to Yes. Otherwise, Control must be set to No so that Zeke will not attempt to track the remote job.

Ready The event is ready to be dispatched.

Refresh Hold A ZREFRESH command was issued for this event; the event is refreshed and on operator hold.

Security Hold The job does not have the authority to run on the platform it was sent to. The event is on hold.

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

System Hold The Zeke dispatching system is on hold. Issue the ZRELEASE command with the system parameter.

Time OK The event has met the schedule time requirements.

VSE Pool Hold Zeke attempted to dispatch a pool event on a VSE system with Dispsel set to N. The event is on hold.

Wait Sched Load There is a new schedule record entry added by the schedule load that is currently processing. The entry will be available for dispatching when the schedule load is complete.

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

When OK All prerequisites have been satisfied.



208


Note:The following are all fields that can be updated from the Schedule View screen. The actual fields displayed on your screen depend on how your display is set up through the Schedule View Display Setup screen.


Display a list of all valid line commands

Enter ? in any Line Cmd field and press Enter.

Change the dispatch priority

Type over the number in the Dp field and press Enter.

Change the time the event is scheduled to run

Type over the number in the Start Time field and press Enter. 00:00 indicates the event is dispatched according to the WHEN conditions.

Update any of the following fields to alter other start time information:

• Late Time

• Early Time

• Must Time

• Notaftr Time

• Avgdur

Change the system or pool the job can run on

Type over the information in the System field and press Enter.

Change the number of times an event is dispatched

Type over the number in the Cnt field and enter the amount of time to wait between dispatches in the Freq field and press Enter. If you do not enter a time in the Freq field, the event is dispatched as soon as the previous run has completed. See “Defining a Recurring or Permanent Event” on page 114.

Change the class or class list for the job

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

Change the number of required tape drives

Enter the number (between 0 and 255) of tape drives in the No. Tap field and press Enter.

Change the amount of storage required by the event

Enter the amount of storage in the Virt Mem field and press Enter.


209

Change the way JCL is submitted and executed

Enter the code to indicate the type of processing to be used in the Target field and press Enter.

Code Meaning

*LOCAL The JCL for the job is executed on the dispatching system.

*RL Remote Limited processing. The JCL is dispatched and submitted on one system and executed on another but does not support condition code processing.

*RF Remote Full processing. The JCL is dispatched and submitted on one system and executed on another.

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

other DMS Netregid of another Zeke system or Zeke Agent where the SQR will be dispatched or downloaded.

Change the target that an event downloads to

Type over the information in the Target field and press Enter. From the Schedule Information Selection Criteria screen, enter REB in the Line Cmd field and press Enter to rebuild the schedule. The rebuilt schedule is downloaded to Zeke Agent.

Note:The Target field may be changed only if the event is not downloaded yet.

Repeat the last command entered

Enter any valid line command for an event and = in the Line Cmd Field for one or more jobs.

Each time you press Enter from the Schedule View screen, the same line command is applied to the next job with an equal sign.



210

Optionally, you can make the same change to any subsequent lines by performing the following steps:

a Enter ALT in the Line Cmd field for the job with the change

b Enter = in the Line Cmd field for any subsequent lines you want to apply the change

c Press Enter.

Note:You can continue applying the change as long as a new line command is not entered.

5 If you make any changes to an SQR that you want Zeke to download to Zeke Agent, then you must rebuild the schedule record before the job can be downloaded to Zeke Agent.


211

Schedule View Commands

Primary CommandsThe following primary commands can be issued from the Command line on the Schedule View screen.

Command Action

ADD Add events to the schedule through the Add wizard.

AUTO Enable or disable the automatic monitoring function depending on the parameter selected.


ON (Default.) Monitors the current schedule and automatically refreshes the screen with any schedule changes based on the specified interval of time.

OFF Disables the automatic monitoring function. Pressing any key will also disable this function.

Note:AUTO will not function properly if you are operating in split-screen mode.

BROWSE View the existing scheduled events.

DOC Display the Documentation Segments screen.

EDIT Update an existing scheduled event.

INT Display the 2 values that control automatic monitoring mode. The first number {rate} is the seconds between automatic refreshes. The second number {wait} is how often to check for a request to exit AUTO mode.

To change the timing of screen refreshes, enter INT rate wait where rate is a range from wait value to 3660 seconds and wait is a range from 1 to 255. Both parameters are optional and have default values of 5. Additionally rate must be a multiple of wait; however, this is calculated and changed automatically.

For example, to refresh the screen every 10 seconds and to check for an exit AUTO mode request every 5 seconds, enter INT 10 5.

EMR Display the Event Master Selection Criteria screen.


212

The following ISPF primary commands are also valid in the Command line on the Schedule View screen:

SELECT Refresh the screen with any schedule changes. When entered with a event number, selects only that event.

Note:When the schedule is refreshed, the cursor remains on the same line number it was on. This may not be the same SQR if the schedule changed during that time.

SORT Re-arrange the sequence of the fields displayed on the screen based on the SORT parameters. This command is only in effect for the current session. For more information and to change the display order permanently, see the Schedule View Sort Setup screen.

Note:Enter SORT HELP on the command line to display a complete list of SORT parameters and their abbreviations.

WORK Display the Work Center Selection Criteria screen.

Command Action

X ALL Exclude all displayed lines.

F ‘STRING’ NEXT Find the next occurrence of a specified string of text.

F ‘STRING’ FIRST Find the first occurrence of a specified string of text.

F ‘STRING’ LAST Find the last occurrence of a specified string of text.

F ‘STRING’ ALL Find all occurrences of a specified string of text.

Note:The FIND ALL command does not display the total number of strings found.

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

Command Action


213

Line CommandsEnter one or more of the following line commands in the Line Cmd field to update a scheduled job.

You can enter line commands for more than one job and they are stacked in the order they appear on the screen. Then each time you press F3 or Enter, the next command is executed.

Command Action

? Display the complete list of line commands online.

= Repeat the last command entered. Enter any valid line command for an event and the equal sign (=) for one or more jobs. Each time you press the PF3/END key, the same line command is applied to the next job with (=).

ADDOK Add a NEED OPEROK to the requirements of the scheduled job without rebuilding it.

ALTer Make any change directly to the scheduled job by typing over the existing information. The same change will be applied to any subsequent lines using the equal sign (=) line command.

DEL Delete the event from the schedule.

DIS Disable the event and remove it from the schedule. To enable the record, use the EN command.

Note:The DIS command prevents WHEN conditions for that record from being satisfied.

DSN Display the Step/DD Level Information screen. Press F3 or Enter to return to Schedule View.

Note:This is valid for job events only. Also, Zebb must be active on this system of Zeke.

EMR Display the EMR screen for the scheduled job. From this display you can make permanent changes to the EMR for that event. Use the REB command to see changes reflected in Schedule View.

EN Enable a disabled event and add it back to the schedule.

FDEL Release the resources for the event before deleting the SQR.


214

FDONE Force the SQR to DONE, regardless of the status of the resources.

FFAIL Force to failed status.

FREB Release the resources for the SQR before the event is re-added to the schedule.

FREF Release the resources and refresh the SQR before the event is re-added to the schedule.

FSUCC Force the SQR to Success status.

Hold Place an operator hold on the scheduled event. To release the hold, use the REL command.

JCLR Retrieve the actual JCL from the JCL source and put it in the SQR so you can view it or update it. The JCL must reside on the same system you are issuing the command from.

Note:You must then issue the ZOOM line command for the same event to display the Schedule View Record Expand Function screen. From that screen, you can view, update or delete the JCL.

JPREP Invoke ASG-JCLPREP to scan JCL. See “Invoking ASG-JCLPREP” on page 237 for more information.

LDSN Display the List DSN Detail Information screen. Press F3 or Enter to return to Schedule View.

Note:This is only valid for job events. Also, Zebb must be active on this system of Zeke.

NOTE Display note text for the event, if applicable.

OK Allow the event to be dispatched. If the generation option OPEROK is set to YES, this command is required by the operator to “OK” the event.

PATH Display the Pathfinder screen for predecessors and successors of the event. Enter a number (1 through 9) after the PATH command to display that number of levels. For example, PATH4 displays four levels of predecessor and successor information. Enter an asterisk (*) to display all levels.

PRED Display the Pathfinder screen for events that the specified event number or jobname is dependent upon. See “PathFinder” on page 244 for more information.

Command Action


215

REB Recreates the SQR with the current status for the event. This produces the same result as deleting a record and re-adding it.

REBH Rebuilds the SQR and places the event on hold.

REF Refresh the SQR by resetting the event as if it had not run. Any refreshed event is placed on operator hold automatically and must be released using the REL command before it is dispatched.

REL Release an operator hold on an event.

RESO Display the resources for the event, alter resource detail, and release a resource from events or a system. See the Schedule View Resource Screen at the end of this section for more information.

RSTRT Display the Job Restart Management screen. Press F3 or Enter to return to Schedule View.

Note:This is valid for job events only. Also, Zebb must be active on this system of Zeke.

RUN Satisfy all conditions and dispatch the scheduled event. Any NOTDURING WHEN conditions are ignored for this event, until a new one is added re-using the EMR.

SCAN Scan and validate JCL that is submitted by Zeke. See “Validating JCL” on page 236 for more information.

SUCC Display the Pathfinder screen for events dependent upon the specified event number or jobname. See “PathFinder” on page 244 for more information.

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

Code Meaning

L Display all job log information.

M Display any messages that were generated.

J Display the actual JCL that was executed.

Command Action


216

The SYSM, SYSL, and SYSJ commands are valid only if the following conditions are met:

• You are running an MVS release that supports IBM’s spool browse facility, and

• You are running JES release 4.x or above, and

• The job is in the JES spool.

TOK Satisfy the time requirements for the scheduled event.

WHEN Display and alter the WHEN conditions for the selected event during this schedule run. See “Viewing and Maintaining WHEN Conditions” on page 225 for more information.

WHY Display the reasons the event is awaiting execution and change the WHEN conditions, if necessary. See “Displaying Event Status” on page 227 for more information.

WOK Satisfy all WHEN conditions for the scheduled event.

WORK Display the Work Center Selection Criteria menu. This command is only valid with work centers.

ZEBB Display the Job Functions Menu. Press F3 or Enter to return to Schedule View.

Note:Only valid for job events. Also, Zebb must be active on this system of Zeke.

ZOom Display the Schedule View Record Expand Function screen. You can update SQR information from one screen. This screen is similar to the EMR screen except that changes on the Schedule View Record Expand Function screen are only temporary for this run of the schedule.

. . . . Create your own CLIST or REXX command that can be executed from Schedule View. An example, ZUSER, is included on the install tape.

Command Action


217

Accessing Other Online InformationYou can access other areas of the Zeke online facility through Schedule View. The menu options are still valid; however, Schedule View offers an alternate way to access these other areas of the online facility. For further information on each of the online facility areas listed below, see the appropriate section in this chapter.

To access other online facility information

1 From the Zeke Primary Menu, enter 2.1 on the Option line and press Enter.

The Schedule View screen is displayed.



Access EMR 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 the event and press Enter. The Event Master Definition screen is displayed in Browse mode. See “Defining Events” on page 77.

Access online documentation

Enter DOC on the Command line and press Enter. The Documentation Selection Criteria screen is displayed.

Or, enter NOTE in the Line Cmd field for the event and press Enter to display Note Text information only for a specific event. See “Event Documentation” on page 181.

Access Work Center information

Enter WORK on the Command line or in any Line Cmd field and press Enter. The Work Center Selection Criteria screen is displayed. See “Work Centers” on page 161.

Access PathFinder Enter one of the following line commands in the Line Cmd field. See “PathFinder” on page 244.

Command Action

PATH Displays all predecessors and successors for the event.

PRED Displays only predecessors.

SUCC Displays only successors.


218

3 Press F3 to return to the Schedule View screen.

Access Zebb Enter one of the following line commands in the Line Cmd field to access the desired Zebb function.

Command Action

ZEBB Display the Job Functions Menu.

DSN Display the Step/DD Level Information screen.

LDSN Display the List DSN Detail Information screen.

RSTRT Display the Job Restart Management screen.

Note:You must have Zebb active on the same system as Zeke before issuing any of these commands from Schedule View.

Display SQR information on one screen

Enter ZOOM in the Line Cmd field for the event and press Enter. See “Using the ZOOM Feature” on page 230.

Edit or override JCL for a job event

Enter ZOOM in the Line Cmd field for the event and press Enter. See “Maintaining JCL” on page 232.



219

Refreshing the ScreenSchedule View monitors the current schedule and automatically refreshes the screen with any schedule changes at specified intervals.

Use the following procedure to enable or disable the automatic monitoring function, and to change the screen refresh rate when this feature is enabled.

To change the automatic refresh options

1 To enable automatic monitoring of the current schedule, enter AUTO ON on the Command line and press Enter. AUTO ON is the default.

2 To disable this function, enter AUTO OFF on the Command line and 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 numbers are displayed. The first number {rate} is the seconds between automatic refreshes. The second number {wait} is how often Zeke checks for a request to exit AUTO mode.

4 To change the timing of screen refreshes, enter INT rate wait where rate is a range from wait value to 3660 seconds and wait is a range from 1 to 255. Both parameters are optional and have default values of 5. Additionally rate must be a multiple of wait; however, this is calculated and changed automatically.

For example, to refresh the screen every 10 seconds and to check for an exit AUTO mode request every 5 seconds, enter INT 10 5.

Another example, to refresh the screen every 12 seconds and to check for an exit AUTO mode request every 4 seconds, enter INT 12 4. If you enter INT 13 4, the 13 is automatically changed to 12.


220

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

To change the default sorting sequence

1 From the Zeke Primary Menu, enter C.3 on the Option line and press Enter.

The Schedule View Sort Setup screen is displayed.

The following line serves as a separator on this screen.

----- Sort uses fields above; fields below are not used -----

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

2 In the nnn field, do the following:

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

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

ASG-Zeke Schedule View Sort Setup Row 1 to 16 of 33 Command ===> Scroll ===> PAGE

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


221

Order values begin at 10 and increment by 10. This allows you to position multiple fields in between existing fields, if necessary.

Each time a field is included in or removed from the sort sequence, or fields are reordered, the Order values are recalculated for the entire list.

In the previous example, the scheduled events are designated to be sorted by Status/Reason Code first, Schedule Date second, and Event Number third. The user has specified that Cnt be used as the fourth 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.

In the example, Status/Reason Code, Event Number, and Cnt will sort in ascending order and Schedule Date will sort in descending order.

4 Type END at the Command line to return to the previous screen.

To change the sorting sequence temporarily


The Schedule View screen is displayed.

2 Enter SORT followed by a space and the abbreviation for the fields you want to sort by and press Enter. Separate each field with a comma and no space.

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


222

Selecting Fields to DisplayYou can select the fields you want to display on the Schedule View screen, and re-order the placement of those fields in Schedule View.

To format the Schedule View screen layout


The Schedule View Display Setup screen is displayed.

The following line serves as a separator on this screen.

----- Fields above are displayed; fields below are not -----

Fields listed above the line are displayed in the user-specified sequence. Unused fields (below the line) are listed by alphabetically, for convenience.

2 In the nnn field, do the following:

a To remove a field from the display, enter the line command 0 next to the field and press Enter. This moves the field below the line to the not used section of the table.

b To include a field in the display, enter any other value next to the field and press Enter. This to moves the field above the line to the used section. The value determines the field’s placement on the screen.

c To re-order fields, enter a new value next to the fields and press Enter.

ASG-Zeke Schedule View Display Setup Row 17 of 33 Command ===> Scroll ===> PAGE Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't show nnn Order Field Description *Date Format: YYYYDDD --- ----- ------------------------------------------------------------------ 170 Version Number 180 Frequency Calc 190 Trigger Type 200 Full Job Name 210 Download Status ----- Fields above are displayed; fields below are not ----- CNT (number of times) DP (Dispatch Priority) Early Dispatch Time Event Name Event Type Freq (dispatch interval) Late Dispatch Time Must End Time Run Date * Status Time


223

Order values begin at 10 and increment by 10. This allows 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 Type END at the Command line to return to the previous screen.

In the following example, the Event Number and Schedule Date appear in Fields 1 and 2. The Sched Time appears in Field 3 and the Status/Reason Code appears in Field 4. None of the other fields display.

Note:On the Schedule View screen, the DOC, JCL, AUTO REPLY, RESOURCE, COND CODE, and WHEN fields always appear as the last six fields. These cannot be changed.

ASG-Zeke Schedule View Display Setup Row 1 of 33 Command ===> Scroll ===> PAGE Primary Commands: CANCEL CLEAR DEFAULT END PREVIEW RESET Line Commands: nnn - Move to/after nnn; 0 - Don't show nnn Order Field Description *Date Format: YYYYDDD --- ----- ------------------------------------------------------------------ 10 Event Number 20 Schedule Date * 30 Schedule Time 40 Status/Reason Code 0 50 Job Name 0 60 Event Type 0 70 Event Name 0 80 DP (Dispatch Priority) 0 90 Late Dispatch Time 0 100 System Identification 0 110 Run Date * 0 120 Freq (dispatch interval) 0 130 CNT (number of times) 0 140 Status Time 0 150 Early Dispatch Time 0 160 Must End Time


224

Changing the Date Display FormatYou can specify the format for selected dates displayed in Schedule View. Entries made on the Date Selection screen affect the fields marked with * (an asterisk) on the Schedule View Display Setup screen.

To change date display format


The Date Selection screen is displayed.

2 In the OPTION field, enter the number of the option marking the format you want displayed on the Schedule View screens. The selected format is marked by * (an asterisk) in the Current Format column.

3 Press Enter.

ASG-Zeke Date Selection OPTION ===>

Current OPT Format Format Description

1 * YYYYDDD Use 7 digit Julian date (default) 2 YYDDD Use 5 digit Julian date 3 MM/DD/YYYY Use 10 character Gregorian date 4 MM/DD/YY Use 8 character Gregorian date


225

Viewing and Maintaining WHEN ConditionsThe following procedure explains how to view and maintain WHEN conditions through Schedule View. See “WHEN Condition Keywords” on page 145 for a list valid keywords.

Changes are only in effect for this run of the schedule. To change the condition permanently, you must use the Event Master Record Function screen.

To view and maintain WHEN conditions through Schedule View

1 From the Schedule View screen, enter WH in the Line Cmd field beside the version you want to view WHEN conditions for and press Enter.

The Schedule View - WHEN Conditions screen is displayed.


ASG-Zeke Schedule View Option ===>

Event = 000116 Event Name = MYBR14 Jobname = MDRBR14 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 ****************************


Alter the existing WHEN conditions

Tab to the blank field after the existing clause under the heading English WHEN Conditions and enter AND or OR and another dependency to the end of the existing one. Do not backspace over any part of the existing clause and do not enter a closing parenthesis.

The maximum size for WHEN conditions is 17 lines, or approximately 1360 characters. Schedule View removes the update field once the maximum is reached.

You can only add approximately 120 characters when altering a dependency through Schedule View, due to necessary buffer information. To post a dataset dependency using a dataset name longer than 120 characters, use the Zeke operator commands.


226

3 Press Enter.

Note:The following screen is displayed if WH is entered beside a work center job on the Schedule View screen. Follow the same procedures for altering and satisfying WHEN conditions to alter or satisfy SET statements.

Satisfy or complete an individual WHEN condition

Tab to the blank space in front of the condition under the Tabular WHEN Conditions heading and enter any character.

The following symbols in the space in front of the condition describe the status of the prerequisite.

Symbol Meaning

* Zeke satisfied the condition.

+ An operator command was used to manually satisfy the condition.

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

Satisfy or complete all WHEN conditions

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


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



227

Displaying Event StatusThis procedure explains how to display and update information about the event status. The reason a version is awaiting execution is displayed under the Event Status heading. If a version has WHEN conditions that have not been satisfied, they are displayed under the Tabular WHEN Conditions heading.

To display and update information about the event status

1 From the Schedule View screen, enter WHY in the Line Cmd field beside the desired version and press Enter.

The Schedule View—WHY screen is displayed.

For events with a status of Queued and a reason code of Multiple Systems, the WHY command displays the wait reasons for all systems. For example:

The Event Status lines that include a system name (JKMSYSD and JKMSYSB) indicate that the SQR is waiting in the dispatch queue on those systems. The lines which are not preceded by a system name apply to the base SQR on any system. This WHY screen format is only generated for pooled SQRs in a SysPlex with PLEXCOMM=XCFONLY on all Zekes. If the SysPlex has PLEXCOMM set to XCFONLY, the system name is always shown, even for non-pooled events.

See page 205 for explanations of the status codes/reason codes.


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


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


228



Satisfy a particular condition under Event Status

Tab to the blank space in front of the condition, type any character and press Enter.

Satisfy or complete an individual WHEN condition

Tab to the blank space in front of the condition under the Tabular WHEN Conditions heading and enter any character.

The following symbols in the space in front of the condition describe the status of the prerequisite:

Symbol Meaning

* Zeke satisfied the condition.

+ An operator command was used to manually satisfy the condition.

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

Satisfy or complete all WHEN conditions

Tab to the blank space in front of the statement Needs WHEN OK under the Event Status heading, enter any character, and press Enter.

If the job is waiting for resources, the Schedule View—Resource screen is displayed. See “Accessing Resources for an Event” on page 229.


229

Accessing Resources for an Event

To view and release the resources assigned to an event

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

The Schedule View—Resource screen is displayed.

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


ASG-Zeke Schedule View OPTION ===> Event = 000028 Event Name = ZEKE51TST6 Jobname = TSKKGUT1 Line Commands: Who - Show holder(s) Rel - Release the resource Count Mode Sta Event Ver Date Scp Resource Name ============<============================================================> 1 SHR 000028 00000 2007053 GBL INIT1 ******************************** BOTTOM OF DATA ***************************


Release the resource Tab to the unlabeled field to the left of the resource and enter REL. Press Enter.

Display the event currently using the resource

Tab to the unlabeled field to the left of the resource and enter WHO. Press Enter. If there are no resources currently being held for the event, the following message is displayed:

**** RESOURCE NOT HELD ****


230

Using the ZOOM FeatureThe ZOOM feature allows you to view or edit all SQR information for the selected event on one screen. This screen is similar to the Event Master Definition screen, except changes to the Schedule View Record Expand Function screen are only temporary for the current run of the schedule.

The ZOOM feature of Schedule View works as is with JCL stored in Zeke and PDS datasets. If you plan to use JCL stored in a Librarian or Panvalet source, modify sample CLIST ZEKELIB (provided on the install tape in ZEKE.CMDPROC) according to the instructions provided in the CLIST. Refer to your ASG-Zeke for z/OS Installation Guide for more information on Librarian and Panvalet.

To view scheduled event information

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

The Schedule View Record Expand Function screen is displayed.

Note:If JCL exists for an event, you can browse, delete, edit, or retrieve it from this screen. The JCL line commands are displayed on the screen, followed by the JCL source.


ASG-Zeke Schedule View Record Expand Function BROWSE Command ===> Platform: MVS Evt: 000028 Job: TSKKGUT1 JES2 Job Id: Sched date: 2007053 Run date: 2007053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKE51TST6 App: Grp: Usrid: System: ZEQA Class: Target: *LOCAL Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem: JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve JCL--> Zeke JCL


231

To edit scheduled job information

1 From the Schedule View screen, enter EDIT on the Command line and press Enter.

The screen is re-displayed in Edit mode. When in Edit mode, you can edit any of the highlighted fields directly from this screen. Scroll left or right to access additional fields. Typically, it is more convenient to edit fields from the Schedule View Record Expand Function screen.

Or

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


2 Update the fields, as necessary, and press Enter.

3 To update or view the event’s JCL, tab to the blank field left of JCL--> and enter one of the available JCL line commands. Press Enter.

Caution! Changes made to JCL via this option are applied to the EMR for this event.


ASG-Zeke Schedule View Record Expand Function BROWSE Command ===> Platform: MVSEvt: 000028 Job: TSKKGUT1 JES2 Job Id: Sched date: 2007053 Run date: 2007053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKE51TST6 App: Grp: Usrid: System: ZEQA Class: Target: *LOCAL Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem: JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve JCL--> Zeke JCL


232

Maintaining JCLFor job events, Schedule View allows access to JCL for one-time overrides. You can retrieve the actual JCL from the JCL source and insert it in the SQR to view or update. This allows authorized users access to a copy of the executable JCL to update parameters and correct abends. The updated copy is then attached to the event’s schedule entry for subsequent runs. If you override the JCL for a recurring event, all subsequent runs for that schedule day will use the override unless the override copy is manually deleted. The JCL override copy is purged with the event at the next schedule load, if the event completes.

To maintain JCL for an event

1 From the Schedule View screen, enter JCLR in the Line Cmd field next to the job and press Enter.

The message following message is displayed:

Request queued

2 Enter ZOOM in the Line Cmd field and press Enter.


3 Tab to first JCL field. In this example, the field indicates the JCL has not been retrieved yet:

Override present in SQR

4 Enter the JCL line command E to edit the JCL and press Enter. Changes to this JCL field are only in effect for this run of the schedule.

ASG-Zeke Schedule View Record Expand Function BROWSE Command ===> Platform: MVSEvt: 000028 Job: TSKKGUT1 JES2 Job Id: Sched date: 2007053 Run date: 2007053 Version: 00000 STATUS TIME: 00:00 STATUS/REASON: Scheduled Time OK Type: JOB EventName: ZEKE51TST6 App: Grp: Usrid: System: ZEQA Class: Target: *LOCAL Early: Sched: 00:00 Late: Mustend: Notafter: Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: A Cntrl: Y Tapes: AvgDur: 00:00 Virt Mem: JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve JCL--> Override present in SQR Delete after next use (Y/N) N JCL--> Zeke JCL


233

5 In the Delete after next use field, specify whether to delete the updated JCL after the next use. If set to Y, the update JCL is deleted after the next run of the job. If set to N, the JCL is kept and re-used for every run until it 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.

6 The additional JCL field contains the name of the specified JCL source for the job. Update this field, if necessary. Changes to that field are permanent and affect the EMR for this event.

The Zeke JCL Override screen is displayed.

7 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, such as CANCEL, COPY, and EDIT. When these commands are issued from Zeke, they are processed as Zeke commands rather than 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.

8 Press F3 again to return to the Schedule View screen.

9 Optionally, you can check your JCL for syntax errors without affecting the actual SQR. See “Validating JCL” on page 236.

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 //EANTST29 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.R510A.LINKLIB.DVLP 000007 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000008 //SYSPRINT DD SYSOUT=* 000009 //SYSABEND DD SYSOUT=* 000010 //SYSUDUMP DD SYSOUT=* 000011 //SYSIN DD * 000012 SET WAIT 1 000013 //* ****** ************************** Bottom of Data **************************


234

Zeke PDS JCL OverrideJCL override for PDS JCL works by attaching the JCL from the PDS as a ZEKEJCL attachment to the schedule queue record (SQR). This JCL can then be modified for the purpose of re-running the job. As an option, you may choose for Zeke to override the JCL after the next job run.

Zeke’s PDS override option provides an alternative to the standard JCL override function in Schedule View. This override option copies the JCL that is pointed to by the DDNAME/member name combination in the SQR to a PDS that is pointed to by the OVERRIDE DD in the Zeke started task. The SQR is updated to point to that DDNAME OVERRIDE. You can then edit the JCL through the ZOOM screen in Schedule View.

The OVERPDS command allocates the datasets pointed to by the DDNAME in the Zeke started task based on the DDNAME found in the current SQR.

For information on how to install and configure the PDS JCL override option, refer to your ASG-Zeke for z/OS Installation Guide.

To perform a Zeke PDS override

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

ASG-Zeke Schedule View BROWSECommand ===> Scroll ===> PAGE

Event ===> System=SYSD Selected=0000034 2007.084 12:51Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When cond ? to list other Line Commands

Line Event Sched Job Evnt Event Event StatusCmd No. Date Name Type Name Reason Code========================================================================== 000001 2007067 DOWN0001 JOB DOWNLOAD0001 Queued Download Holdzoom 000021 2007069 CGC806 JOB ABEND806 Fail S806 000025 2007065 CGCXDCA JOB JOBTEMPLATE Queued Need Oper OK 000076 2007057 CGCJCL JOB ZEKEJCLTEST Success 000079 2007065 CGCJCL2 JOB ZEKEJCLTEST Fail Forced 001014 2007068 KATHYG01 JOB KATHYG01 Fail JCL Error 001098 2007067 TRACK04 JOB TRACK0000004 Active 6900% 001694 2007067 SCOM EOJTRACK75 Success********************************** BOTTOM OF DATA *************************


235


2 On the Command line, enter OVERPDS.

After the datasets are allocated, OVERPDS copies the member (indicated in the SQR) to a dataset pointed to by the OVERRIDE DD in the Zeke started task. A ZALTER command is issued against the SQR to change the SQR to point to the OVERRIDE DD.

3 Exit and then re-enter the zoom screen to see the change in the SQR.

ASG-Zeke Schedule View Record Expand Function BROWSECommand ===> OVERPDS Platform: MVSEvt: 000021 Job: CGC806 JES2 Job Id: JOB09781

Sched date: 2007069 Run date: 2007069 Version: 00000STATUS TIME: 01:06 STATUS/REASON: Fail S806

Type: JOB EventName: ABEND806 App: A2345678 Grp: G23 Usrid: U2345678 System: SYSD Class: A Target: *LOCAL

Early: Sched: 00:00 Late: Mustend: Notafter:

Dprty: 50 Times: 1 Freq: Freqcalc: S Trig: ACntrl: Y Tapes: AvgDur: 00:00 Virt Mem:

JCL Line Commands: B - Browse D - Delete E - Edit R - Retrieve

JCL--> PDS: ZEKEJCL Member: ABEND806

ASG-Zeke Schedule View Record Expand Func Override successfulCommand ===> Platform: MVSEvt: 000021 Job: CGC806 JES2 Job Id: JOB09781






JCL--> PDS: ZEKEJCL Member: ABEND806


236

4 You can the enter E to the left of the JCL—>PDS: OVERRIDE line to edit the override JCL, if needed.

Validating JCLAfter you create or edit JCL you can check it for syntactical errors using one of the following:

• ASG-JCLPREP—using the JPREP line command

• ASG-JOB/SCAN—using the JSCAN line command

• ZSCAN operator command

Note:Other JCL scanning products can be invoked from the Schedule View display by using the Zeke line command JSCAN. You must write a TSO CLIST or REXX exec to perform the validation before using the JSCAN line command. Refer to the section on using other JCL scanning products in your ASG-Zeke for z/OS Installation Guide. If your product provides an ISPF EDIT macro to scan JCL, then you may use it while editing event JCL from the ZOOM display.

ASG-Zeke Schedule View Record Expand Function BROWSECommand ===> Platform: MVSEvt: 000021 Job: CGC806 JES2 Job Id: JOB09781






e JCL--> PDS: OVERRIDE Member: ABEND806


237

Invoking ASG-JCLPREPASG-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:

• Via the ZOOM feature

• By entering the JPREP line command

JCLPREP can only be used for jobs with existing JCL.

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.

Refer to your ASG-Zeke 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.

To invoke JCLPREP using Schedule View ZOOM

1 From the Schedule View screen, type ZOOM in the Line Cmd field beside the desired job and press Enter.




238

2 To access the JCL, enter E in front of the JCL field and press Enter.

The JCL screen is displayed.

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

4 When you finish reviewing the JCLPREP output, press F3 to exit the output screen.

To invoke JCLPREP using the JPREP line command

1 From the Schedule View screen, enter JPREP in the Line Cmd field beside the desired event and press Enter. JCLPREP is invoked to check the JCL syntax.

After JCLPREP completes the check, the JCLPREP output is displayed.

2 When you finish reviewing the JCLPREP output, press F3 to exit the output screen.

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 //EANTST30 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.R220A.LINKLIB.OS3901 000620 //* DD DISP=SHR,DSN=OASIS.R230A.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.R230AM1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.R300A.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.R300A.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *


239

Invoking JOB/SCANFrom Schedule View, you can invoke the JCL management tool, ASG-JOB/SCAN, in either of two ways: via the ZOOM feature, or by entering the JSCAN line command. Both methods for accessing ASG-JOB/SCAN (herein called JOB/SCAN) are described in the following section.

JOB/SCAN can only be used for jobs that have existing JCL.

Refer to your ASG-Zeke for z/OS Installation Guide for information on configuring JOB/SCAN for JCL management, and for important setup procedures that must be performed before you can invoke JOB/SCAN from Schedule View. Also refer to your JOB/SCAN documentation series for more information.

To invoke JOB/SCAN using the ZOOM feature of Schedule View

1 From the Schedule View screen, type ZOOM in the Line Cmd field next to the job and press Enter.


2 To access the JCL, enter E in front of the JCL field and press Enter.



240

The JCL screen is displayed.

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

4 When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.

To invoke JOB/SCAN using the JSCAN line command

1 From the Schedule View screen, 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.

2 When you finish reviewing the JOB/SCAN output, press F3 to exit the output screen.

Note:See the JOB/SCAN documentation series for more instructions.

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 //EANTST30 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.R220A.LINKLIB.OS3901 000620 //* DD DISP=SHR,DSN=OASIS.R230A.LINKLIB.DVLP 000630 // DD DISP=SHR,DSN=OASIS.R230A.LINKLIB 000640 //* DD DISP=SHR,DSN=ZEKE.OASIS.R230AM1.LINKLIB 000650 //* DD DISP=SHR,DSN=ZEKE.PDOAN.LINKLIB 000660 //* DD DISP=SHR,DSN=ZEKE.PDBER.LINKLIB 000670 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB.DVLP 000680 // DD DISP=SHR,DSN=ZEKE.R510A.LINKLIB 000690 //* DD DISP=SHR,DSN=ZEBB.R300A.TEST.LINKLIB 000691 // DD DISP=SHR,DSN=ZEBB.R300A.LINKLIB 000700 //SYSPRINT DD SYSOUT=* 000800 //SYSABEND DD SYSOUT=* 000900 //SYSIN DD *


241

Using ZSCANYou 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 will not be able to view the OS messages.

Note:To validate JCL on another system, you must specify the system name. Use the ZSCAN operator command to do so. Refer to your ASG-Zeke for z/OS Reference Guide for details).

To check your JCL for syntax errors using ZSCAN

1 From the Schedule View screen, enter SCAN in the Line Cmd field and press Enter.

2 If you have a package designed to browse the JES spool, such as SDSF or BETA92, use it to view the messages. Otherwise, enter SYSM in the Line Cmd field and press Enter.


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 the following conditions are met: you are running an OS release that supports IBM’s spool browse facility; you are running JES release 4.x or above; and the job is in the JES spool.


242

Creating Your Own Line CommandsSchedule View allows you to create your own CLIST or REXX commands that can be executed from Schedule View. See the ZUSER example included on the install tape.

To create a line command

1 From the Schedule View screen, enter the 3-character to 5-character name of your CLIST or REXX command in the Line Cmd field beside the desired job and press Enter.

2 The user-defined command is executed. This sample shows the parameters passed in the ZUSER example.

EVENT NUMBER = 00021 VERSION = 00000 SCHEDULE DATE = 2007053 JOB NAME = TSKKGUT1EVENT TYPE = JOB EVENT NAME = KTEST1 STATUS/REASON CODE = SCHEDULED TIME OKDISPATCH PRIORITY = 50 START TIME = 00:00 LATE DISPATCH TIME = SSYSTEM = ZEQA RUN DATE = 2007053 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


243

ZCOM OptionFrom the console or via the ZCOM option, you can enter Zeke operator commands. Refer to your ASG-Zeke for z/OS Reference Guide for a complete list of commands, parameters, and values that are valid for operator commands.

The Schedule Control Function screen lists some of the most common operator commands you are allowed to enter, depending on your security and class definition. These commands are used for altering and displaying scheduled event information. You can also alter the values of Zeke variables through the ZCOM option.

To issue operator commands

1 From the Zeke Primary Menu, enter option 2.2 and press Enter.

The Schedule Control Functions screen is displayed.

2 Enter an option number or enter a command on the Option line and press Enter.

The Zeke Command Output Display screen is displayed.

Note:You can also Tab over to the description section for options 13 through 24 and set up your own command options.

For example, to display all of the events for the current schedule, you can enter 1 on the Option line and press Enter, or enter ZD on the Option line and press Enter.

ASG-Zeke Schedule Control Function BROWSE Option ===> Please enter a valid Zeke operator command Opt Description Opt Description 1 ZD 13 2 ZD JOB 14 3 ZD MSG 15 4 ZD SCOM 16 5 ZD ZCOM 17 6 ZD WAIT 18 7 ZD DONE 19 8 ZD LATE 20 9 ZD HOLD 21 10 ZD AV 22 11 ZID 23 12 ZMAP 24 Cmd: Add - ZADD Function


244

The corresponding Zeke Command Output Display screen is displayed detailing the selected criteria.

3 Press F3 to return to the previous screen.

PathFinderPathFinder shows all predecessor and successor relationships for any given event. This allows you to view what needs to occur before a job can run and what will happen after the job has run. This display can be accessed through Schedule View or by issuing a Zeke operator command.

The following procedure explains how to access PathFinder using several operator commands. Refer to your ASG-Zeke for z/OS Reference Guide if you are unfamiliar with Zeke operator commands. See “Using Schedule View” on page 202 for information on accessing this feature through Schedule View.

Note:Any commands listed in this procedure can also be entered directly from the console.

ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 17 of 30 Command ===> Scroll ==> PAGE Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. -------------------------------------------------------------------------- Z0922I DATE RDATE VERS TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS 000006 2007053 2007053 0000 JOB TSKKGUT1 50 00:00 1 T 000008 2007053 2007053 0000 JOB TSKKGUT3 50 00:00 1 T 000011 2007053 2007053 0000 JOB SPTEXD11 50 00:00 1 T 000018 2007053 2007053 0000 JOB SPTEXD18 50 00:00 1 T 000019 2007053 2007053 0000 JOB SPTEXD19 50 00:00 1 T 000020 2007053 2007053 0000 JOB SPTEXD20 50 00:00 1 T 000021 2007053 2007053 0000 JOB SPTEXD21 50 00:00 1 T 000022 2007053 2007053 0000 JOB SPTEXD22 50 00:00 1 T 000023 2007053 2007053 0000 JOB SPTEXD23 50 00:00 1 T 000024 2007053 2007053 0000 JOB SPTEXD24 50 00:00 1 T 000025 2007053 2007053 0000 JOB SPTEXD25 50 00:00 1 T 000026 2007053 2007053 0000 JOB SPTEXD26 50 00:00 1 T 000028 2007053 2007053 0000 JOB TSKKGUT1 50 00:00 1 T 000029 2007053 2007053 0000 JOB SPTEXD29 50 00:00 1 T 000030 2007053 2007053 0000 JOB SPTEXD30 50 00:00 1 T Z0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00028 SYSTEM ZEQA


245

To access PathFinder using Zeke operator commands




Display predecessors for an event at all levels

Enter:

ZD PRE LEV * JOB jobname

or

ZD PRE LEV * EV event number

on the Option line and press Enter.

The specified job is the zero (0) level job and is displayed at the bottom of the flow. You may have to scroll down to see the Level 0 job.

Then, scroll up to see the order of the predecessors. They will be displayed from the bottom to the top, beginning with the first job (Level 1). Displayed above each Level 1 job are all the jobs that trigger it (Level 2 through the end).

If a condition has already been displayed, the following message appears directly underneath the job that triggered it:

CONDITION ALREADY DISPLAYED BELOW

Display successors for an event at all levels

Enter:

ZD SU LEV * JOB jobname

or

ZD SU LEV * EV event number


The specified job is the zero (0) level job and is displayed at the top of the screen. All jobs that are triggered by this job are displayed below the Level 0 job beginning with the first job (Level 1). Displayed under each Level 1 job are all the jobs that it triggers (Level 2 through the end).

If a condition has already been displayed, the following message appears directly underneath the job that triggered it:

CONDITION ALREADY DISPLAYED ABOVE


246

If Zeke detects a loop in any of the WHEN conditions, it will continue to list all predecessors and successors and display the following message:

*** INFINITE WHEN-CONDITION LOOP DETECTED!! ***

Display all predecessors and successors for an event

Enter:

ZD PRE SU LEV * JOB jobname

or

ZD PRE SU LEV * EV event number


Scroll down until you find the first job (Level 0) and page up for the predecessors and down for the successors.

Display non-Zeke jobs in path

The generation option Trigjob must be set to A so that any job can trigger another event's WHEN conditions, regardless of how the job is dispatched. The following message is displayed whenever a non-Zeke job is found:

** NOT IN THE SCHEDULE OR NOT A ZEKE EVENT **

Note:The predecessors cannot be displayed because those events do not have WHEN conditions.

Display different levels in the hierarchy

Enter LEV followed by a space and the number of levels you want to display with one of the commands listed above and press Enter. For example,

ZD SU EV 100 LEV 3

Display up to 3 levels of jobs that are dependent upon event 100.

Note:Enter an (*) asterisk to display all levels.



247

Display Successor ExampleThe following shows an example of all jobs dependent on MYTEST:

After the following command is entered:

ZD SU LEV * JOB MYTEST

a screen similar to the following is displayed.

ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 5 of 5 Command ===> Scroll ==> PAGE Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. -----------------------------------------------------------------------------ZD SU LEV * JOB MYTEST Z09ADI SUCCESSORS FOR THE REQUESTED EVENT: LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR 0 MYTEST JOB 000008 2007053 0000 T 00:00 ----------------------------------------------------------------------------- >>1 ALHJOB2 JOB 000002 2007045 0000 EOJ MYTEST T 00:00 2 DONETST JOB 000053 2007045 0000 WEOG ALHJOB2 00:00 2 ZTSRPT9T JOB 000067 2007045 0000 WEOG ALHJOB2 00:23 3 ZTSERAXT JOB 000003 2007045 0000 WEOJ ZTSRPT9T 00:03 4 ZTSBKUP JOB 000708 2007045 0000 WEOJ ZTSERAXT 00:20 4 ZTSDONE JOB 000930 2007045 0000 WEOJ ZTSERAXT 00:10 ******************************* Bottom of data *******************************

MYTEST(Level 0)

DONETST(Level 2)

ZTSRPT9T(Level 2)

ZTSERAXT(Level 3)

ZTSBKUP(Level 4)

ZTSDONE(Level 4)

ALHJOB2(Level 1)


248

Display Predecessor ExampleThe following diagram shows an example of all jobs that MYTEST is dependent on:


ZD PRE LEV * EVENT 54


AZ09ACI PREDECESSORS FOR THE REQUESTED EVENT: LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR 3*ZTSVLDTT JOB 001005 2007038 0000 * 00:00 5*ZTSVLDT3 JOB 001009 2007038 0000 * 00:00 5*ZSJOBAT JOB 001010 2007038 0000 * 00:00 4 ZTSJOBBT JOB 001007 2007038 0000 EOJ ZTSVLDT3 T 00:00 EOJ ZSJOBAT 4*ZTSVLDT2 JOB 001008 2007038 0000 * 00:00 3 ZTSJOBDT JOB 001006 2007038 0000 EOJ ZTSJOBBT T 00:00 EOJ ZTSVLDT2 2 ZTSJOBKT JOB 001004 2007038 0000 EOJ ZTSVLDTT T 00:00 EOJ ZTSJOBDT >>1 EANTST04 JOB 001003 2007038 0000 EOJ ZTSJOBKT T SCHD 00:00 ------------------------------------------------------------------------------ 0 MYTEST JOB 001002 2007038 0000 EOJ EANTST04 T 00:00 ******************************* Bottom of data ********************************

EANTST04(Level 1)

ZTSJOBBT(Level 4)

ZTSVLDTT(Level 4)

MYTEST(Level 0)

ZTSVLDTT(Level 5)

ZSJOBAT(Level 5)

ZTSJOBKT(Level 2)

ZTSVLDTT(Level 3)

ZTSJOBDT(Level 3)


249

Display Predecessor and Successor ExampleThe following is an example of all events that ZEKE51TST3 is dependent upon and all events dependent on ZEKE51TST3.


ZD PRE SU LEV * EV 3


ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 17 of 131Command ===> Scroll ==> PAGE Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. -----------------------------------------------------------------------------ZD PRE SU LEV * EV 3 Z09AEI PREDECESSORS AND SUCCESSORS FOR THE REQUESTED EVENT: LVL JOB/EVT NAME TYPE EVENT DATE VERS WHEN TRIGGER NAME T-VER STATUS AVDUR>>1*ZEKE51TST1 MSG 000001 2007053 0000 * 2 KATHYG *** NOT IN THE SCHEDULE OR NOT A ZEKE JOB *** 2*ZEKE51TST1 MSG 000001 2007053 0000 * 2*ZEKE51TST1 MSG 000034 2007053 0000 * >>1 ZEKE51TST2 MSG 000002 2007053 0000 EOJ KATHYG T EOE ZEKE51TST1 >>1*ZEKE51TST1 MSG 000034 2007053 0000 * ----------------------------------------------------------------------------- 0 ZEKE51TST3 MSG 000003 2007053 0000 EOE ZEKE51TST2 T EOE ZEKE51TST1 ----------------------------------------------------------------------------->>1 ZEKE51TST4 MSG 000004 2007053 0000 EOE ZEKE51TST3 T 2 ZEKE51TST5 MSG 000005 2007053 0000 EOE ZEKE51TST4 T 3 SPTEXD11 JOB 000011 2007053 0000 EOE ZEKE51TST5 T 00:00 2 SPTEXD29 JOB 000029 2007053 0000 EOE ZEKE51TST5 T 00:00

predecessors

successors


250

Manually Adding Events to the ScheduleNormally, the SCHEDULE function (a batch utility program) automatically schedules all of the required events. However, sometimes you need to manually add an individual event or a group of events to the schedule. Zeke offers several methods for creating an SQR manually:

• ZADD operator command

• ADD online function

• ADD by path online function

Note:If a job event manually added to the schedule 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 the SQR is created.

Using the ZADD Operator CommandThis procedure requires that you know the event number, the event name, or the jobname of the event you want to add to the schedule.

To manually add an event to the schedule using the ZADD command

1 From the Zeke Primary Menu, enter 2.2 and press Enter.

The Schedule Control Function screen is displayed.

ASG-Zeke Schedule Control Function BROWSE Option ===> Please enter a valid Zeke operator command Opt Description Opt Description 1 ZD 13 2 ZD JOB 14 3 ZD MSG 15 4 ZD SCOM 16 5 ZD ZCOM 17 6 ZD WAIT 18 7 ZD DONE 19 8 ZD LATE 20 9 ZD HOLD 21 10 ZD AV 22 11 ZID 23 12 ZMAP 24 Cmd: Add - ZADD Function


251


Note:Refer to your ASG-Zeke for z/OS Reference Guide for a complete list of commands, parameters, and values that are valid with the ZADD 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.


To add one job by event number

Enter ZADD EV event-num

To add several jobs using a range of event numbers

Enter ZADD EV (event-num, event-num, ...)

To add one version of an event by event number

Enter ZADD EV event-num VER version-num

To add a job event by jobname

Enter ZADD JOB name

To add any job by event name

Enter ZADD ENAME name

ASG-Zeke Zeke Command Output Display BROWSE Row 1 to 7 of 7 Command ===> Scroll ==> PAGE Please enter a valid Zeke operator command or option number. Press PF3/PF15 key to return to the schedule control function panel. --------------------------------------------------------------------------ZADD EV 18Z0952E EVENT 000018 SCHEDULE RECORD ALREADY EXISTS WITH SAME DATE/VERSNZ0929I ZEKE COMMAND PROCESSEDZ0922I DATE RDATE VERS TYPE JOB/EVT NAME DP SCHED FREQ CNT STATUS000018 2007053 2007053 0000 JOB SPTEXD18 50 00:00 1 T000018 2007055 2007055 0000 JOB SPTEXD18 50 00:00 1 TZ0905I NUMBER OF SCHEDULE ENTRIES SELECTED WAS 00002 SYSTEM ZEQA****************************** Bottom of data *****************************


252

Using the ADD FunctionThis procedure describes how to add any type of event to the schedule using the online facility. Behind the scenes, Zeke uses your selections on this screen to build a ZADD operator command.

To manually add an event to the schedule using the ADD function


The ADD Event Record Selection Criteria screen is displayed.

2 Enter Y in any of the following fields if you want to include that parameter with the ZADD command issued from this screen. The default for each field is N.

ASG-Zeke ADD Event Record Selection Criteria Command ===> 2007.055Options: Auto: N (Y/N) Enable: N (Y/N) 15:26 Hold: N (Y/N) Rebuild: N (Y/N) Rerun: N (Y/N) Refresh: N (Y/N) Run: N (Y/N) Schedule Date: 2007055 (YYYYDDD) Run Date: 2007055 (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 Selection Field Masks Job: Job Name: Msg: Event Name: Pcom: Application: Work: Group ID: Vcom: User ID: Zcom: Drl ID: Scom: System: REXX: Permanent:

Field Description

Auto Add one to the value for number of dispatch times, if the scheduled job is active. The REFRESH and ENABLE parameters are assumed. This parameter is not valid for work center events.

Enable Change the scheduled job status from DISABLE to ENABLE.

Hold Place an operator hold on the event after it is added, refreshed, or enabled. The event must then be released from hold before it can be dispatched. This parameter is not valid for work centers.


253

3 If one job is to be added, the event number may be entered in the Event field.

4 Enter information in any of the fields under either or both of the following headings to restrict the number of events selected. The more information you enter here, the fewer events you need to look at to find the event you want to work with. If you do not enter information in any fields, all events defined in your Zeke database are displayed.

Rebuild Recreate the SQR. (If an SQR does not exist, you do not need this parameter.) This produces the same result as deleting a record and re-adding it.

• Resets all WHEN conditions

• Reflects any EMR changes

• Places the event into ACTIVE status

• Resets any ZALTER changes previously made

Rerun Add the RERUN designation to the schedule job record. The RERUN designation appears in the ZDISPLAY output and is passed to the user exit ZEKE14D. If the generation option TRIGRRN=NO, the job will not trigger the WHEN conditions of other jobs. Use the NORERUN parameter of the ZALTER command to remove the RERUN designation.

Refresh Refresh an SQR if the status is EOJ, AEOJ, or Pending. (The ZADD REFRESH does not place an operator hold on the job like the ZREFRESH command.)

Run Add the job to the schedule ready to run. This is the same as a ZALTER RUN operator command.

Field Description

Event Types Enter any character except a space to indicate the types of jobs to be selected.

Selection Field Masks

Enter any information you know about the events you want to select, such as jobname, user ID, run date, etc. You can use * (asterisk) and ? (question mark) to perform wildcard searches. Enter * in any position to search for all positions following it. For example, ABC* in the Job Name field selects all events whose jobname begins with ABC. Enter ? in any position to search for that one position. For example, A?C selects all records beginning with A, ending with C, and with any character in the second position.

Field Description


254

5 Press Enter.

The Schedule View Event Add List screen is displayed.

6 Enter S in the unlabeled Selection field to the left of all the events you want to add to the schedule. To add a particular version of an event to the schedule, enter the version number in the Versn No. field. You can add as many of the events displayed on one screen as you want.

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 the events marked on this page. Press F8 to display the next page of events.

8 Press Enter. All the events marked are added to the current schedule.

ASG-Zeke Schedule View Event Add ListCommand ===> Scroll ===> PAGE Selected=0000046 Line Commands: S - Select to add the event to the Schedule Versn Event Event Sched Evnt System Applic User Job No. Number Name Info Type ID ID ID Name========================================================================== 000001 ZEKE51TST1 2007053 MSG ZEQA 000002 ZEKE51TST2 2007053 MSG ZEQA 000003 ZEKE51TST3 2007053 MSG ZEQA 000004 ZEKE51TST4 2007053 MSG ZEQA 000005 ZEKE51TST5 2007053 MSG ZEQA 000006 KTEST1 2007053 JOB ZEQA KTEST TSKKGUT1 000007 KTEST2 2007053 JOB ZEQA KTEST TSKKGUT2 000008 KTEST3 2007053 JOB ZEQA KTEST TSKKGUT3 000009 KTEST4 2007053 JOB ZEQA KTEST TSKKGUT4 000010 KTEST5 2007053 JOB ZEQA KTEST TSKKGUT5 000011 ZEKE51CC 2007053 JOB ZEQA SPTEXD11 000012 ZEKE51CC 2007053 JOB ZEQA SPTEXD12 000013 2007053 WORK ZEQA 000014 2007053 VCOM ZEQA 000015* today ZCOM ZEQA 000016 2007053 SCOM ZEQA


255

Adding Events By PathYou can add an event to the schedule based on predecessor/successor relationships, that is, a specified event’s path. A path includes the root event and its predecessor and successor events.

Note:To use this function, the DSPIndex generation option must be set to Y.

You cannot use this function to schedule events with an OCCURS clause of (REQUEST).

To manually add an event to the schedule based on an event path


The ADD Event Record by Path Selection Criteria screen is displayed.

2 Complete the following fields to specify the root event to be processed.

ASG-Zeke ADD Event Record By Path Selection Criteria Command ===>

Criteria:

Event ==> Version ==> (omit for default) Occurs Date ==> 2007022 (YYYYDDD) Level ==> 1 Type ==> B (P=pred, S=succ, B=both)

ZADD options:

Run Date ==> (YYYYDDD)

Auto: N (Y/N) Enable: N (Y/N) Hold: N (Y/N) Rebuild: N (Y/N) Refresh: N (Y/N) Rerun: N (Y/N) Run: N (Y/N)

Field Description

Event Required. Event number for the root event, the event for which to display the path information.

Version Version of the root event.

Occurs Date OCCURS HIT date (in Julian format). Only events that would be scheduled on this date are included in the path. Default is the current system date.


256

3 In the Run Date field, specify date on which the event is to run, in Julian format (YYYYDDD). Events are added with the specified run date.

4 Specify which parameters for adding the event. The default for each field is N. Enter Y for each parameter you want to include for the ZADD.

Level Number of path levels to display. Valid values are 1-999, or enter an asterisk (*) for all levels. Default is 1.

Type Type of path to display. Valid values are:

P Predecessors only.

S Successors only.

B Default. Both predecessors and successors.

Field Description

Auto Add 1 to the value for 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 Change the event status from DISABLE to ENABLE.

Hold Place an operator hold on the event after it is added, refreshed, or enabled. The event must be released from hold before it can be dispatched.

Note:This parameter is not valid for work centers.

Rebuild Recreate the SQR if one already exists. This option essentially:

• Deletes the SQR

• Re-adds the SQR

• Resets all WHEN conditions

• Reflects any EMR changes

• Places the event into ACTIVE status

• Resets any ZALTER changes previously made

Field Description


257

5 Press Enter.

Note:If the criteria entered results in multiple dates, a pop-up window appears and allows you to select the appropriate date.

Refresh Refresh an SQR, if the status is EOJ, AEOJ, or Pending, by resetting the event as if it had never run. (The ZADD REFRESH does not place an operator hold on the job like the ZREFRESH command.)

Rerun Add the RERUN designation to the schedule job record. The RERUN designation appears in the ZDISPLAY output and is passed to the user exit ZEKE14D. If the generation option Trigrrn=NO, the job will not trigger the WHEN conditions of other jobs. Use the NORERUN parameter of the ZALTER command to remove the RERUN designation.

Run Add the event to the schedule ready to run. This is the same as a ZALTER RUN operator command.

Field Description


258

The Schedule View Event Add List screen is displayed.

6 Enter S in the unlabeled Selection field to the left of each event to add to the schedule. To add a particular version of an event to the schedule, enter the version number in the Versn Number field.

Note:An asterisk (*) next to the Level number indicates events that begin a new level.

7 Press Enter to select all the events marked on the current page.

8 Press F8 to display the next page of events.

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

Level Event Job Evnt Event Sched Versn System Appl Grp Name Name Type Number Date Number ID ID ID================================================================================= 3 EVENT00V JOB00V JOB 000024 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00W JOB00W JOB 000025 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00U JOB00U JOB 000023 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BA JOB00BA JOB 000029 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BH JOB00BH JOB 000036 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BQ JOB00BQ JOB 000045 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BL JOB00BL JOB 000040 2007094 00000 SYSTEM1 PATHAPP PTH *1 EVENT00BF JOB00BF JOB 000034 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BI JOB00BI JOB 000037 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BH JOB00BH JOB 000036 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BJ JOB00BJ JOB 000038 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BK JOB00BK JOB 000039 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BI JOB00BI JOB 000037 2007094 00000 SYSTEM1 PATHAPP PTH 1 EVENT00BG JOB00BG JOB 000035 2007094 00000 SYSTEM1 PATHAPP PTH 0 EVENT00BE JOB00BE JOB 000033 2007094 00000 SYSTEM1 PATHAPP PTH

*1 EVENT00BC JOB00BC JOB 000031 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BA JOB00BA JOB 000029 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00Y JOB00Y JOB 000027 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00Z JOB00Z JOB 000028 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BL JOB00BL JOB 000040 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BB JOB00BB JOB 000030 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00Z JOB00Z JOB 000028 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BA JOB00BA JOB 000029 2007094 00000 SYSTEM1 PATHAPP PTH *1 EVENT00BD JOB00BD JOB 000032 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BB JOB00BB JOB 000030 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00Z JOB00Z JOB 000028 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BA JOB00BA JOB 000029 2007094 00000 SYSTEM1 PATHAPP PTH 2 EVENT00BC JOB00BC JOB 000031 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BA JOB00BA JOB 000029 2007094 00000 SYSTEM1 PATHAPP PTH 3 EVENT00BB JOB00BB JOB 000030 2007094 00000 SYSTEM1 PATHAPP PTH


259

9 Repeat steps 6 through 8, as necessary.

10 Press Enter.

All selected events are added to the current schedule.


260

261

6Chapter 6:Resources

Zeke provides both physical and logical resource control. Before dispatching an event, it ensures all resources are available.

Topic Page

Resource Types 262

Physical Resources 262How Initiator Processing Works 263Activating Initiator Options 267Defining Initiators to Zeke 269Defining Pools to Zeke 272

Maintaining Logical Resources 274Defining a Logical Resource 275Maintaining Resources for an Event 277Deleting Resources for an Event 281


262

Resource Types

Note:Work center events do not use resources.

Physical ResourcesTape drives are a resource used with job events. To ensure sufficient tape drives are available before an event executes, you can specify the number of required tape drives on the job’s EMR. See “Maintaining a Job Event” on page 92. Or, Zeke can automatically calculate the number of tape drives needed for each job. Use the generation option Calctap to activate this feature (see “Calculating Tape Drive Usage” on page 305).

An initiator is a physical resource required by every OS job. To maximize the use of system resources, you can choose to have Zeke submit jobs to a system only when an initiator of the correct class is available.

Note:Zeke does not support initiator selection for JES3.

Another physical resource is the actual system the job will process on. These systems can be combined into pools that share the same database, allowing Zeke to select the proper system for each job.

Resource Type Includes

Physical Tape drives, systems, pools, and initiators.

Logical Anything you want to define to represent the use of a physical resource such as the entire CPU, a specific CPU channel, a file, or a dataset. Log-ical resources are used for jobs that if executed simultaneously might cause contention among your system resources.

6 Resources

263

How Initiator Processing WorksBefore you determine whether 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.

Regardless of how an initiator is selected (Zeke or JES), the actual initiator is determined by a host of factors, including:

• Whether there is a class on the job card

• Settings of the generation options Dispsel, Defdspcl, and Usercls

• Whether there is a list of classes on the EMR

• Initiator availability at the time of dispatch

As mentioned previously, there are several generation options that relate to initiator processing. The most important is Dispsel.

When Dispsel=YIf Dispsel is set to Y, Zeke checks the EMR for a class list. An event can have up to six classes. If one or more classes is specified, Zeke selects a free initiator that has been defined to Zeke and can process one of the specified classes. If no classes are specified on the EMR, Zeke selects any free initiator defined to Zeke.

Then, Zeke adds or changes the class parameter on the job card to reflect the selected class based on the following criteria:

• If no class list is supplied, Zeke updates the job card with the highest priority class defined to the initiator and submits the job.

• If there is a class list, Zeke checks the value of the generation option Usercls.

— If Usercls is set to Y, Zeke updates the job card with the EMR class that caused the initiator to be selected and submits the job.

— However, if Usercls is set to N, Zeke updates the job card with the highest priority class defined to the initiator and submits the job.


264

The following flowchart illustrates the process that occurs before an event is dispatched to an initiator when Dispsel=Y.

Figure 3 • Zeke Initiator Selection Process—Dispsel=Y

Dispsel=Y

Was a class

specified in the EMR?

Waits until Zeke-defined

initiator is available

Waits until a Zeke-defined initiator that processes the specified class is available.

Initiator class preference is determined by the order in which they appear in the EMR.

Usercls=Y?

The class on the EMR that caused the initiator to be selected is put on

the job card.

The highest priority class processed by the selected initiator is put on the job

card and the job can run in any available initiator that can run that particular class.

Submit the job to JES

YN

YN

6 Resources

265

When Dispsel=NIf the generation option Dispsel is set to N, initiator selection is deactivated and Zeke submits jobs directly to JES when all other dispatching criteria have been met, without regard for initiator availability. One thing to be aware of is that jobs waiting in the JES input queue will have a PENDING status as 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 the following:

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

The following considerations apply if you specify Defdspcl=N:

• Initiator name does not appear in message Z0533I.

• NOTDURING dependency support is not available.

Note:If you have set PLEXNOTD=YES in your Zeke options member to enable enhanced NOTDURING processing, then Dispsel=N is ignored for NOTDURING dependency support.

• Tape drive prerequisites specified in the EMR are ignored.

• An auto-reply defined for one initiator is valid for all.

• The ZMAP command does not show initiator name.

• The ZDISPLAY AVAILABLE command is not valid.

• The INITIATOR parameter of the ZHOLD, ZRELEASE, ZALTER, and ZDISPLAY operator commands is not valid.


266

The following flowchart illustrates the process that occurs before an event is dispatched to an initiator, where Dispsel=N.

Figure 4 • Zeke Initiator Selection Process-Dispsel=N

Put the Defdspcl value on the job card

Dispsel=N

Was a class specified in the EMR?

Put the first class specified on the job card

Make no changes to the job card

Submit the job to JES

YN

YN Was a value specified for Defdspcl?

6 Resources

267

Activating Initiator OptionsFive generation options are related to determining how Zeke can use initiators for your system:

To activate initiator options

1 Enter =4.1 on any Command line and press Enter.

The Option System Directory is displayed.

Note:'********' is the generic system name, so that if a system is not set up with its own generation options, it defaults to the values entered under this ID.

2 Enter E to the left of the System field and press Enter, or enter EDIT on the Command line and the system name in the System field and press Enter.

3 Press F8 to scroll to the Defjprty field.

Option Description

Defjprty Specifies the default job priority on the EMR.

Defdspcl Specifies the default dispatch class on the EMR.

Dispdly Specifies the number of seconds to wait before dispatching jobs to Zeke pools. (The Dispdly value is ignored if POSID is set to Y.)

Dispsel Specifies whether or not Zeke selects initiators.

Usercls Specifies whether to use the EMR class for job submission.



268

4 In the Defjprty field, enter a default job operating system priority (between 0 and 15) to use if a priority is not entered on the EMR PRI field. The default is 01. Enter NO if the priority should be left unchanged.

5 In the Dispsel field, enter the code indicating whether Zeke selects the initiators.

Note:Dispsel is ignored if you are using JES3.

6 In the Defdspcl field, enter the default dispatch class that will be assumed if the class is not entered on the EMR.

7 In the Dispdly field, enter the number of seconds to wait between dispatches of pooled events. The default is 30 seconds. This field is required if Dispsel=N, but is ignored if POSID=Y.

8 Optionally in the Usercls field, enter one of the following codes to determine the job submission class.

9 At the Command line on any screen enter ZRELOAD GENOPT to reload the changed options.

Code Meaning

Y Default. Selects initiators

N Disregard initiators

Code Meaning

N Do not use the EMR class; select initiators using the Zeke class selection process.

Y Default. Use the class specified in the EMR to submit jobs to the initiator. Zeke does not change the class at dispatch time. If this option is set to ‘Y’ and no classes are defined on the EMR, Zeke selects initiators using the regular class selection process.

6 Resources

269

Defining Initiators to ZekeThe next step is to define all the initiators for each operating system running Zeke. ASG recommends that you define every initiator and specify the times the initiator is available. If an initiator is not normally used by Zeke, specify a time range of 00:00 - 00:00 hours. This gives the operator the ability to alter, by operator command, the initiator information and enable the system to use the initiator on demand.

ASG also recommends that when you define the initiators to JES, you make the first class of each initiator unique. This ensures that jobs will run in the Zeke-selected initiators, because when Zeke selects the initiator, it puts the highest priority class for that initiator in the job card, depending on the generation option Usercls. (See the Dispsel=Y flowchart on page 264.)

To define initiators


The System Initiator/Partition Directory is displayed.


ASG-Zeke System Initiator/Partition Directory Row 1 to 1 of 1 Command ===> Scroll ===> PAGE System ===> System type ===> ("MVS", "VSE" or "VSE/ESA") Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete E - Edit System JES/POWER ID System Type Description _ ******** MVS _ TSO45 VSE/ESA _ Z51TST MVS ***************************** Bottom of data ******************************


Add a new system and initiator specifications

Do the following:

• Enter ADD on the Command line

• Enter the name of the new system in the System field; this is the value of the NAME parameter in the OASIS options member

• Enter MVS in the System Type field to indicate the operating system

Edit initiator information for an existing system

Enter E in the unlabeled Selection field to the left of the system you want to update.


270

3 Press Enter.

The System Initiator Specification screen is displayed.


ASG-Zeke System Initiator Specification EDIT Command ===> Scroll ==> PAGE Zeke System: ******** System type: MVS JES System ID: Description: Primary command: ADD BROWSE CANCEL COPY EDIT DELETE (All initiators) Line commands: B - Browse initiator detail E - Edit initiator detail D - DELETE A LINE R - REPEAT A LINE I - INSERT A LINE Initid MTWTFSS _ A NNNNNNN _ T004 NNNNNNN _ T03 NNNNNNN _ T2 NNNNNNN _ 1 NNNNNNN _ 2 NNNNNNN _ B NNNNNNN _ C NNNNNNN _ D NNNNNNN _ E NNNNNNN _ F NNNNNNN _ G NNNNNNN


Add an initiator In the Initid field, enter the ID to be assigned to the initiator. Use the same name as when it was defined to JES. Press Enter and the initiator is added.

To add availability detail for the initiator, enter E in the unlabeled Selection field next to the initiator.

Edit existing initiator information

Enter E in the unlabeled Selection field next to the initiator you want to update.

Copy an initiator record Enter R in the unlabeled Selection field next to the initiator you want to copy.

Delete a single initiator Enter D in the unlabeled Selection field next to the initiator you want to delete and press Enter. The initiator is deleted for this system. Go to step 7.

Delete system name and all initiator specifications

Enter DELETE on the Command line and press Enter. To confirm the delete, enter DELETE on the Command line again and press Enter. Go to step 7.

6 Resources

271

5 Press Enter.

The System Initiator Detail screen is displayed.

6 To restrict the time of day the initiator is available to Zeke, enter the hours of availability in the Start and End fields for each day. If you do not enter a range for a day, the initiator is assumed to be available 24 hours that day.

For example, if the initiator is available 24 hours a day Monday through Saturday, but on Sunday 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 - 00:00 makes the initiator unavailable all day. However, the operator can still make use of the initiator on-demand through Zeke operator commands.

7 Press Enter.

8 At the Command line on any screen enter ZRELOAD INIT to reload the changed information.

ASG-Zeke System Initiator Detail EDIT COMMAND ===> System Id : EDMVS Initiator Id: A1 Primary commands: BROWSE CANCEL EDIT Start End Start End Start End Start End Monday time ranges: Tuesday time ranges: Wednesday time ranges: Thursday time ranges: Friday time ranges: Saturday time ranges: Sunday time ranges:


272

Defining Pools to ZekeEvery job is owned by one of the systems sharing the Zeke database or by one of the pools. A pool is a user-defined group of systems identified to Zeke. If you have a group of systems 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 the job belongs to. The system name corresponds to the NAME parameter of the OASIS00 options member (if not using a pool ID). If no owner is specified, a default of system A is used.

To define and maintain a system pool


The System Pool Directory is displayed.


ASG-Zeke System Pool Directory Row 1 to 1 of 1 Command ===> Scroll ===> PAGE Pool id ===> POOL1 Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit Pool ID Description ************************************************************************** POOL1 TEST POOL MAIN PROD1 POOL***************************** Bottom of data ******************************


Add a new pool Make the following entries:

• Enter ADD on the Command line.

• Enter the name of the new system in the Pool ID field.

Note:Do not use any Zeke operands, parameters, keywords, or abbreviations of these to name your systems or pools. For example, do not name an system or pool AB, which is short for the parameter ABEND.

Edit an existing pool Enter E in the unlabeled Selection field to the left of the pool you want to update.

6 Resources

273

3 Press Enter.

The System Pool Specification screen is displayed.


Delete a pool Enter D in the unlabeled Selection field to the left of the pool you want to delete. Press Enter. Enter DELETE on the Command line and press Enter. The pool is deleted. This procedure is complete.

ASG-Zeke System Pool Specification EDIT Command ===> Scroll ==> PAGE Pool ID: POOL1 Desc: TEST POOL Primary command: ADD BROWSE CANCEL COPY DELETE EDIT Line commands: D - Delete a line I - Insert a line R - Repeat a line SYSTEM TSO45


Add a system to a new pool Enter the new system name in the System field. You can enter up to 15 systems on one screen. If you need to add more than 15 systems, press F8 to view additional blank lines for entry.

Note:Do not use any Zeke operands, parameters, 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 Enter I in the unlabeled Selection field next to a system name. Press Enter. A blank line is added. Enter the new system name on the blank line.

Edit an existing system Enter the changes to the system you want to update.

Delete a system from a pool Enter D in the unlabeled Selection field next to the system name.



274

5 Press Enter.

The pool record is updated.

6 Cycle Zeke in order for your modifications to take effect.

Maintaining Logical ResourcesLogical resources are user-defined and represent the use of a physical resource. The difference between a logical resource and a physical resource is the logical resource does not really have to exist.

Logical resources can be used for events that if executed simultaneously might cause contention among your system resources. Think of logical resources as a more versatile and sophisticated NOTDURING dependency.

A logical resource can be anything you want to define to represent the use of a physical resource such as an entire CPU, a specific CPU channel, a file, or a dataset.

For example, 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 causes dataset contention when job 6 is running with any of the other 5 jobs. To avoid dataset contention, use logical resources to ensure that job 6 runs alone. Define a resource to represent the file and give job 6 exclusive access to the resource.

To set up or define a logical resource, you must enter:

• A quantitative figure to let Zeke know how much of a resource is available at any one time.

• Which systems the resource is active on.

Then, for each job that uses this resource, enter 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, say a resource is defined with a value of 1. JOBA needs 1 of this resource before it can run. If JOBB is running and using this resource, it will not be available and JOBA will have to wait for JOBB to free the resource.

Note:When Dispsel=N, only resources defined as GLOBAL (that is, any system can share the resource) are resolved.

6 Resources

275

Defining a Logical ResourceThis procedure defines resources to the Zeke database. It tells Zeke where each resource exists and how many are available.

To define a logical resource


The Resource Specification screen is displayed.

2 Perform the steps outlined in the Action column, depending on the desired result:

ASG-Zeke Resource Specification Row 1 to 1 of 1 Command ===> Scroll ===> PAGE Resource name ===> System ===> Line Commands: C - Copy D - Delete Primary Commands: ADD COPY DELETE Resource name System 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 ******************************


Define a resource to Zeke Make the following entries:


• Enter the resource name in the Resource Name field and press Enter.

Caution! Do not use spaces within the resource name. For example, the name MY DATASET NAME is invalid. Instead, use MY.DATASET.NAME.

Edit an existing resource To update Maximum Shared or Active, type over the existing information and press Enter.


276

The Resource Detail screen is displayed when the add, copy, or delete command is entered.

3 In the System field, enter the code identifying the system that owns the resource. You can specify a resource more than once with different system names. GLOBAL is the default and means any system can share this resource. If the job’s system name is assigned to a pool, leave this field GLOBAL to ensure proper dispatching.

4 In the Max Share Count field, enter the number identifying the resource amount. This can be any number that quantifies the resource availability.

Copy an existing resource to a new name

Enter COPY on the Command line.

Enter the resource name to copy in the Resource Name field and press Enter. The Resource Detail screen is displayed.

Enter the new name in the Resource Name field and press Enter to complete the procedure and to return to the Resource Specification screen.

Delete a resource Enter DELETE on the Command line.

Enter the resource name to delete in the Resource Name field and press Enter. The Resource Detail screen is displayed.

Press Enter again to delete the resource and return to the Resource Specification screen.

Note:Ensure no events reference a deleted resource. Events that try to acquire a deleted resource will not dispatch.

ASG-Zeke Resource Detail Command ===> Scroll ===> PAGE Resource name: INIT1 Primary commands: ADD CANCEL COPY DELETE EDIT System: (GLOBAL) Max share count: 00005 Active?: YES


6 Resources

277

5 Enter the code indicating whether the resource is active in the Active field.

6 When you have finished adding or updating information on the Resource Detail screen, press Enter to update the data.

Maintaining Resources for an EventOnce you have defined logical resources for your systems, use the Resource Control screen to assign the appropriate resource name and amount used of the required resource for each event.

Prior to dispatch, Zeke ensures the required resource is available in the quantity specified.

Caution! You must complete the procedure “Defining a Logical Resource” on page 275 before beginning this procedure for adding the resource to an event. If a resource is added to an event before defining it, the event will be unable to acquire it and will not dispatch properly.

To add a resource to an event

1 Access the EMR or the Event Master Directory as instructed in the procedure, “Accessing the Event Master Record” on page 82.

2 Perform one of the following:

• From the Event Master Directory, enter E4 to the left of the event number for the event you want to assign a resource to and press Enter.

• From the EMR, enter RESOURCE on the Command line and press Enter.

Code Meaning

YES Indicates the resource is active. Zeke ensures the resource is available before dispatching an event that uses this resource.

NO Indicates the resource is not active. Zeke does not perform any resource control for events that use this resource.


278

The Resource Control screen is displayed.

3 If the job has no resources defined, simply enter the name of the resource in the Resource Name field.

4 If the job already has one or more resources defined:

a Enter i in the line command field to the left of one of the existing resource names and press Enter to insert a line after that resource.

b Enter the name of the new resource in the Resource Name field of the new line.

5 In the Cnt field, enter a number to represent how much of this resource is used when this job runs.

Note:If mode is EX or ES, this field must be 001.

6 In the Md field, enter a code indicating the resource mode required by the job:

ASG-Zeke Resource Control EDIT Command ===> Scroll ===> PAGE Primary Commands: BROWSE DELETE EDIT Evt: 000007 Type: JOB Job: TSKKGUT2 Evt Name: KTEST2 System: ZEQA Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S) --------------Resource Name----------------- Cnt --Codes- Md H E A ========================================================================== INIT1 001 SR N R N


Allow only one job access to this resource in Write mode.

For that one job, enter EX in the Md field.

For example, a file is used by 6 jobs. All of the jobs but 1 use the file in Read mode. The remaining job backs up the file. This causes dataset contention when the job backing up the file is running with the other 5 jobs. To avoid dataset contention, you’ll want to run the job that backs up the file alone.

Set up a logical resource with a maximum share count of 5. Define the resource to each of the 5 jobs that read the dataset with a mode of SR and a count of 1. Define the resource to the job that backs up the dataset with a mode of EX so it won’t execute concurrently with any of the 5 jobs reading the dataset.

6 Resources

279

7 In the H field, enter a code indicating if resources should be held.

Allow only one job access to this resource in Read mode

Enter ES in the Md field.

For example, out of a group of 6 jobs, 2 of the jobs (A and B) cannot run together. However, the remaining jobs can run in any combination with either jobs A or B.

Set up a logical resource with a maximum share of 5. Define Jobs A and B with a mode of ES and a count of 1. Define the other jobs with a mode of SR and a count of 1.

Note:Jobs with exclusive share cannot run with other exclusive share jobs, but they can run with any number of share jobs.

Allow multiple jobs access to this resource

Enter SR in the Md field.

For example, 3 jobs execute nightly at about the same time which causes performance problems.

Set up a logical resource with a maximum share of 100. Set up each job with a resource mode of SR and a count of 50.

Zeke only allows 2 of these jobs to run simultaneously. The third job must wait for one of the jobs to complete so that at least 50 of the resource is available.

Code Meaning

Y Hold resource if available and the correct mode. However, the resource can be “stolen” by another job with a higher dispatch priority. For example, job A requires 4 resources prior to dispatch. Other jobs require only 1. With the H field set to Y, job A holds each resource as it becomes available until it has all 4. The other jobs must wait until job A releases the hold on the resources before they can run.

N (Default.) Do not hold available resource. For example, job A requires 4 resources prior to dispatch. Other jobs require only 1. With the H field set to N, the other jobs continue to obtain 1 of the resources as needed. Job A waits and does not hold any resources until all 4 are available at the same time.



280

8 In the E field, enter a code indicating if resources should be released at AEOJ.

9 In the A field, enter a code indicating whether to use the resource for a restart.

10 When you have finished adding or updating information on the Resource Control screen, press Enter to update the data.

Code Meaning

K Keep resource if the job abends. The resource mode must be EX or ES and can be obtained by a restart/rerun.

R (Default.) Release resource if the job abends.

Code Meaning

Y Use resource for a restart. The job will try to obtain the resource from an abended job, if the job is set to release the resource (RESKEEP=YES). The resource mode must be EX or ES and can be obtained by a restart/rerun.

N Do not use resource for a restart.

S Job can assume the resource from itself only, if it abends.

6 Resources

281

Deleting Resources for an EventUse the Resource Control screen to delete one or more resources for an event.

To delete one or more resources for an event

1 Access the EMR or the Event Master Directory as instructed in the procedure, “Accessing the Event Master Record” on page 82.

2 Do one of the following:

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

b From the EMR, enter RESOURCE on the Command line and press Enter.

The Resource Control screen is displayed.

3 To delete one or more specific resources, enter d in the line command field to the left of the resource names you wish to delete. 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 the deletion.

ASG-Zeke Resource Control EDIT Command ===> Scroll ===> PAGE Primary Commands: BROWSE DELETE EDIT Evt: 000007 Type: JOB Job: TSKKGUT2 Evt Name: KTEST2 System: ZEQA Codes: Md = Mode (EX/ES/SR) H = Hold (Y/N) E = Fail (K/R) A = Assume (Y/N/S) --------------Resource Name----------------- Cnt --Codes- Md H E A ========================================================================== INIT1 001 SR N R N EDTR2 002 SR N R N


282

283

7Chapter 7:Maintaining Zeke

Zeke provides you with a great amount of flexibility and control of event scheduling and Zeke database access and maintenance. Generation options set these specifications.

Topic Page

Changing Zeke Operating Criteria 284

Accessing Generation Options 286Activating Variable Substitution 288Dispatching Messages and Events 288Recognizing NOT-CAT2 Messages 290Retaining Events 291Triggering Events 293Scheduling Events 297Pending Messages and Events 300Defining Schedule Download Agents 301Setting Auto Replies 303Loading the Work Center to SQT 304Calculating Tape Drive Usage 305Checking the Dispatch Queue 306Maintaining the Job Restart Facility 306Maintaining Networking Options 307Maintaining Inter-product Communication 309Using Shared Databases 311Dispatching Events After Zeke Start-up 312Building EDB Indexes 312Obtaining Operating Passwords 314Changing ISPF Color Scheme 316

Using the Audit Facility 318

Database Maintenance 320Creating the Zeke Databases (Primary and Vault) 320Backing Up the Zeke Database 323Restoring the Zeke Database 324Moving the Vault Database 326Recovery Using Electronic Vaulting 328


284

Changing Zeke Operating CriteriaGeneration options are necessary because no two data centers are exactly the same. In fact, for some installations, no two systems are the same. Zeke allows you to set up separate systems with different generation options for each.

When Zeke is installed, these generation options are set to default values that are satisfactory for most data centers. As you gain more experience and start to use more of the features, you may want to update the generation options to better meet your needs.

Because they affect your entire site, your personnel responsible for system programming, scheduling, data security, and site standards all should review and agree on your generation options settings. You should define the options immediately after Zeke is installed. (They can be changed at a later date, if necessary.)

To date, there are over 150 generation options. This chapter discusses in greater detail only the options most commonly used. Refer to your ASG-Zeke for z/OS Reference Guide for an alphabetical listing, along with explanations, of all Zeke generation options.

After any changes are made, you must enter the operator command ZRELOAD GENOPT at the console for each system that will be affected by the changes. For most generation options, the changes take effect immediately. However, some options require you to cycle Zeke, using either ZKILL COLD or ZKILL TRACK. The table below lists the generations options that require you to cycle Zeke when changed, and indicates whether ZKILL TRACK is effective for making the change.

Continuous Job Tracking 331Terminating Zeke Using ZKILL TRACK 331SMF Recording Mode 332Applying Maintenance 335SMF Playback 335

Topic Page

7 Maintaining Zeke

285

Table 1 • Generation Options Requiring a Zeke Cycle

Cycle Required

Generation Option COLD TRACK

Aur

DSPIndex

Dynsmf

EDBindex

GUIServ

Iefu83

MultSys

Netregid

Oprhold

Posid

Wktrgdn

X14coml

ZPRDcom


286

Accessing Generation OptionsTo access the generation options

1 Enter =4.1 on any Command line and press Enter.


This screen displays a list of existing systems.

Note:'********' is the generic system, so that if a system is not set up with its own generation options, it defaults to the values entered under this ID.

2 Depending on the desired result, perform one of the following actions.



Add a system Enter ADD on the Command line and enter the new system in the System field, and press Enter. The Generation Options screen is displayed. Re-enter the new system on the Command line and press Enter.

Browse an existing system Enter B to the left of the System field and press Enter, or enter BROWSE on the Command line and the system in the System field and press Enter.

Edit an existing system Enter E to the left of the System field and press Enter, or enter EDIT on the Command line and the system in the System field and press Enter.

7 Maintaining Zeke

287

The first Generation Options screen is displayed.

3 Scroll to the generation option you want to view or update by pressing F8 (scroll forward), or F7 (scroll backwards).

4 See the procedures listed in this section for a detailed explanation on how to update specific generation options.

Copy an existing system Enter C to the left of the System field and press Enter, or enter COPY on the Command line and the system in the System field and press Enter. The Generation Options screen is displayed. Enter the new system on the Command line and press Enter.

Delete an existing system Enter D to the left of the System field and press Enter, or enter DELETE on the Command line and the system in the System field and press Enter. The Generation Options screen is displayed. Enter DELETE on the Command line to confirm the delete and press Enter.

ASG-Zeke Generation Options EDIT Command ===> Scroll ===> PAGE Zeke System: ******** Abhold: N (Y or N) Yes to hold recurring events if abended Aur: Y (Y or N) Yes to enable automatic responses Aurintv: 01 (1 - NN) Number of seconds to check auto responses Aurmsg: Y (Y or N) Yes to inform operator auto. response issueBatoprid: BATCH (xxxxxxxx) Default security batch operator id Batsec: N (Y or N) Yes for Zeke to perform batch security Bimappl: (xxxxxxxx) Bimedit application name Bimpasw: (xxxxxx) Bimedit access password Bimuid: OMIT (xxxx) Bimedit access userid Bypjob: N (Y or N) Yes for Zeke to bypass all Power Job cards Calcmem: Y (Y or N) Yes to calculate virtual memory (VSE) Calctap: Y (Y or N) Yes to calculate tape drive usage Chgval: Y (Y or N) Yes to display Variable update message Cmdcons: Y (Y or N) Yes to route cmd response to console Cmsftype: JCL (xxxxxxxx) Default CMS filetype Commctl: Y (Y or N) Yes to retain Work Events until completed Condrdv: SYS000 (xxxxxx) Condor camlib device name Condrlb: OMIT (xxxx) Condor camlib qualifier Condrver: 001 (xxx) Condor version id



288

Activating Variable SubstitutionThe Subdata generation option affects variable substitution. Activate this option if you want variable substitution to be performed in your JCL. If this option is not activated, errors will occur in jobs submitted with Zeke and OASIS variable names in the JCL.

To activate variable substitution

1 Access the Option System Directory screen in Edit mode as instructed in “Accessing Generation Options” on page 286

2 Press F8 to scroll to the Subdata field.

3 Enter Y to substitute variables in the JCL before submitting the job to JES and press Enter.

4 To activate the updated option, enter ZRELOAD GENOPT on the Command line and press Enter.

Dispatching Messages and EventsThe following generation options are related to dispatching events and issuing related messages.

Note:In this section the term priority refers to the Zeke dispatching priority, not the operating system job priority.

Defdprty Specifies the default dispatch priority on the EMR.

Dispdly Specifies the number of seconds to wait between dispatches of pooled events. (The Dispdly value is ignored if POSID is set to Y.)

Dispmsg Specifies whether or not to issue event dispatch messages.

Msgwait Specifies amount of time between messages for events waiting in the dispatch queue.

Mspintrl Specifies the time when an event is given a higher dispatch priority.

Operok Specifies whether Zeke is to wait for an operator OK before dispatching any event.

Prilate Specifies whether to dispatch late events with priority.

7 Maintaining Zeke

289

To activate the options for dispatching messages and events

1 Access the Option System Directory screen in Edit mode as instructed in“Accessing Generation Options” on page 286.

2 Press F8 to scroll to the generation option you want to update.

3 In the Defdprty field, enter a default dispatch priority (between 1 and 99) to use if a dispatch priority is not entered on the EMR. The default is 50. This number displays in the Dprty field on the EMR.

4 If Dispel=N, then in the Dispdly field, enter the number of seconds to wait before dispatching pooled events. The default is 30 seconds. (The Dispdly value is ignored if POSID=Y.)

5 In the Dispmsg field, enter the code indicating whether Zeke should issue dispatching messages.

6 In the Msgwait field, enter the amount of time (HH:MM) Zeke waits between issuing messages for events waiting in the dispatch queue. The default is 1 hour. This option affects the following messages:

7 In the Mspintrl field, enter a time interval (HH:MM) for near dispatches. Jobs are given a higher dispatch priority if their Must Start or Not After times are within the specified interval. The default is 1 hour.

Code Meaning

Y (Default.) Issue dispatching messages Z0603I, Z0604I, and Z0605I

N Disregard dispatching messages

Z0601I Z0602I Z0611I

Z0615I Z0617I Z0618I

Z0628I Z0631I Z0634I


290

8 In the Operok field, enter a code indicating whether Zeke is to wait for an operator OK before dispatching any event. This option can be overridden for an individual event on the EMR (OPEROK).

9 In the Prilate field, enter the code indicating whether to dispatch late events with a higher dispatch priority.

10 To activate the updated options, enter ZRELOAD GENOPT on the Command line.

Recognizing NOT-CAT2 MessagesThis option recognizes the following NOT-CAT2 messages and marks the job as failed.

To activate the NOT-CAT2 option

1 Access the Option System Directory screen in Edit mode as instructed in “Accessing Generation Options” on page 286.

2 Press F8 to scroll to the IGNCAT2 field.

3 Enter N for Zeke to recognize NOT-CAT2 messages, and to mark the job as failed.


Code Meaning

Y Wait for an operator OK; a message is issued when an event is placed in the dispatch queue

N (Default.) Dispatch events without an operator OK

Code Meaning

Y Dispatch late events before other events, regardless of the schedule time

N (Default.) Dispatch events in the schedule time sequence, without regard to late time

IEF377I IAT4801 MIM1083 (MIMS product message)

IEF452I IEF287I

IEFC452I IEF378I

7 Maintaining Zeke

291

Retaining EventsThe following generation options are related to retaining events.

To activate any of the options for retaining events



3 In the Commctl field, enter the code indicating whether Zeke should retain work centers in the schedule until they are done (EOJ) or disabled.

If the value for Retain in the EMR is Yes and the value in the Commctl parameter is No, the Commctl parameter overrides the definition on the EMR for work centers. However, if Retain is Yes and Commctl is No, but the Loadcomm option is set to Yes, then the work center is retained.

4 In the Retain field, enter the code indicating whether Zeke should retain non-dispatched events. This option determines the default value for the Retain field on the EMR.

Commctl Specifies whether to retain work centers until completed.

Retain Specifies whether to retain incomplete events.

Retdays Specifies the days to retain pending or AEOJ job events.

Retdone Specifies whether to retain completed events in the schedule.

Retpend Specifies whether to retain SQRs until completion of the event.

Code Meaning

Y (Default.) Retain work centers until completed or disabled.

N Discard work centers the next day, regardless of status.

Code Meaning

Y (Default.) Retain events for the next schedule run.

N Discard non-dispatched events during the next schedule run.


292

5 In the Retdays field, enter the number of days to retain pending or failed events. The default is 002 days.

Note:If you enter 000 days in the Retdays field, the events will be dropped on the next day’s schedule load.

6 In the Retdone field, enter the code indicating whether Zeke should retain completed events in the schedule.

Note:If using EOG, you must retain completed events.

7 In the Retpend field, enter the code indicating whether Zeke should retain SQRs until the event is complete.


Code Meaning

Y (Default.) Retain completed events

N Discard completed events after EOJ

Code Meaning

Y (Default.) Retain events until done (EOJ or disabled)

N Delete schedule records when the event is dispatched

7 Maintaining Zeke

293

Triggering EventsThe following generation options are related to triggering events.

Iefu83 Dynamically installs SMF IEFU83 to trigger events when a newly created dataset is open and closed.

Note:Because the Iefu83 generation option controls whether the Zeke IEFU83 SMF exit ZEKE48G is loaded, changes to the value of this option do not take effect when a ZKILL TRACK restart is performed. Changing this option requires a ZKILL COLD restart.

Remtrig Indicates 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, the SQR's schedule and run dates are sent with the trigger. If the remote trigger was satisfied by a non-Zeke job on a Zeke system, the system's current date is sent as the schedule date and run date with the trigger.

TA Trigger all dates.

NT If multiple dates exist, then do not trigger any date. If only one date exists, trigger that date.

OD Trigger the oldest date only.

ND Trigger the newest date only.

Trigdt Specifies whether a Zeke-controlled job can trigger another event’s WHEN conditions if the schedule or run dates are different.

Note:When the schedule is created and a subset of SQRs is to be downloaded to Zeke Agent, the value of the Trigdt genopt is communicated to Zeke Agent. If this genopt is changed on Zeke and a ZRELOAD GENOPT command is executed, Zeke Agent continue to use the old Trigdt value until a new schedule is downloaded.


294

To activate any of the triggering options



3 In the IEFU83 field, enter the code indicating whether to dynamically install the SMF IEFU83 exits.

4 In the Trigdt field, enter the code indicating whether an Zeke-controlled job can trigger another event’s WHEN conditions if the dates are different.

Trigjob Specifies whether a job can trigger another event’s WHEN conditions if the job is not dispatched by this Zeke (or by another Zeke sharing the same database).

Note:When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the object of the AT netregid of another scheduler's trigger), a non-Zeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke's Trigjob generation option. Both the local and remote Zeke systems ignore the Trigjob genopt when satisfying cross-schedule triggers.

Trigrrn Specifies whether a job can trigger another event’s WHEN conditions if the job has a rerun designation.

Wktrgdn Specifies whether completed events can trigger weak WHEN conditions.

Code Meaning

Y Install the SMF IEFU83 exits to use the DSN dependency

N (Default.) Do not install the SMF IEFU83 exits

Code Meaning

A (Default.) Any event can trigger an event’s WHEN conditions, regardless of the date.

S The schedule dates must be the same before an event can trigger another job’s WHEN conditions. The schedule date is the date that an event would have run if it were not a non-workday (weekend or holiday).

7 Maintaining Zeke

295

Note:If multiple Zeke systems are sharing a database (Multsys is set to Y), each of the Zeke systems must be set to the same Trigdt value. Otherwise, you may experience excessive database I/O.

5 In the Trigjob field, enter the code indicating whether an event can trigger another event’s WHEN conditions.

Note:If multiple Zeke systems are sharing a database (i.e., Multsys is set to Y), each of the Zeke systems must be set to the same Trigjob value.

When a Zeke system satisfies a cross-platform scheduling trigger for a remote system (that is, a Zeke system is the object of the AT netregid of another scheduler's trigger), a non-Zeke job as well as Zeke-controlled job will satisfy the trigger, regardless of the setting of either Zeke's Trigjob generation option. Both the local and remote Zeke systems ignore the Trigjob genopt when satisfying cross-schedule triggers.

R The run dates must be the same before an event can trigger another event’s WHEN conditions. The run date is the date the event was actually added to the schedule, either by the ZADD command or the batch schedule function. The run date also could have been added with a ZADD command using a different date with the RDATE parameter.

Code Meaning

A (Default) Any job can satisfy triggers on this Zeke regardless of how/where the job is dispatched.

C Only jobs dispatched by this Zeke (or by a Zeke sharing the same database) can satisfy triggers on this Zeke. Remote Zeke jobs and non-Zeke jobs are ignored.

S Only jobs dispatched by this Zeke (or by a Zeke sharing the same database) and non-Zeke jobs can satisfy triggers on this Zeke. Remote Zeke jobs are ignored.

Code Meaning


296

6 In the Trigrrn field, enter the code indicating whether an event can trigger another event’s WHEN conditions if the event has a rerun designation.

7 In the Wktrgdn field, enter the code indicating whether previously completed events can trigger weak WHEN conditions.

Note:If multiple Zeke systems are sharing a database (Multsys is set to Y), each of the Zeke systems must be set to the same Wktrgdn value. Otherwise, you may experience excessive database I/O.


Code Meaning

Y (Default.) Any event can trigger an event’s WHEN conditions, regardless of the rerun designation

N A rerun event cannot trigger another event’s WHEN conditions

Code Meaning

Y Allow completed events to trigger weak WHEN conditions

N (Default.) Do not allow previously completed events to trigger weak WHEN conditions

7 Maintaining Zeke

297

Scheduling EventsThe following generation options are related to scheduling events.

Note:The options MultAp, MultGr, MultJn, MultEn, and MultUs work together to determine what jobs are added with the ZADD command. If multiple criteria is used on the same ZADD command, the option with the most restricted value is applied. For example, if a ZADD by jobname and application ID is requested and MultJn=All and MultAp=None, then no events are added since the most restricted is none.

To activate the event scheduling generation options



3 In the Multap field, enter the code indicating how to handle a ZADD by application ID when multiple events exist with the same application.

MultAp Specifies what to do when a ZADD by application ID is issued and multiple events have the same application ID.

MultGr Specifies what to do when a ZADD by group ID is issued and multiple events have the same group ID.

Multhit Specifies whether an event is scheduled multiple times when there is a nonwork-day.

MultJn Specifies what to do when a ZADD by job name is issued and multiple events have the same name.

MultEn Specifies what to do when a ZADD by event name is issued and multiple events have the same name.

MultUs Specifies what to do when a ZADD by user ID is issued and multiple events have the same user ID.

Nonwkday Specifies whether to schedule an event if the OCCURS clause is true for a non-workday.

Code Meaning

F (Default.) Add the first matching event and end the search; this is the most efficient


298

4 In the Multgr field, enter the code indicating how to handle a ZADD by group ID when multiple events exist with the same group.

5 In the Multhit field, enter the code indicating whether an event can be scheduled multiple times when there is a nonworkday. This option determines the default value for the Multhit field on the EMR.

6 In the Multjn field, enter the code indicating how to handle a ZADD by jobname when multiple events exist with the same name.

N Do not add any events; list all matching events on the console

A Add all the matching events

Code Meaning




Code Meaning

Y (Default.) Allow multiple schedule records. For example, if Monday is a holiday, then Zeke schedules the jobs to run 2 times on Tuesday, if they are supposed to run on Monday and Tuesday.

N Allow only 1 schedule record

Code Meaning




Code Meaning

7 Maintaining Zeke

299

7 In the Multen field, enter the code indicating how to handle a ZADD by event name when multiple events exist with the same name.

8 In the Multus field, enter the code indicating how to handle a ZADD by user ID when multiple events exist with the same user ID.

9 In the Nonwkday field, enter the code indicating when to schedule an event if the OCCURS clause is true for a nonworkday. This option is the default used on the EMR (Nwday field).


Code Meaning




Code Meaning



A add all the matching events

Code Meaning

A (Default.) Schedule the event after the nonworkday. For example, if Monday is a holiday, all events scheduled for Monday will be scheduled for Tuesday.

B Schedule the event before the nonworkday

O Schedule the event on the nonworkday

N Do not schedule the event


300

Pending Messages and EventsThe following generation options are related to pending messages and events.

To activate the options for pending messages and events



3 In the Pendinv field, enter the number of minutes Zeke will hold a pending event’s initiator. At the end of this interval, Zeke will place the initiator in the table of available initiators and dispatch other events to it.

4 In the Pendmsg field, enter the number of minutes between messages that notify you of a pending event. Enter ‘0’ if you do not want a message to be issued.


Pendinv Specifies the pending event interval.

Pendmsg Specifies the pending message interval.

7 Maintaining Zeke

301

Defining Schedule Download AgentsZeke allows you to download a subset of SQRs in the Zeke schedule to a Zeke Agent. In order to download SQRs to Zeke Agent, Zeke Agent must first be defined to Zeke.

To define a download agent


The Options Selection Menu is displayed.

2 From the Options Selection Menu, enter 9 and press Enter.

The Schedule Download Agents List screen is displayed.

3 Perform the steps in the Action Column, depending on the desired result.

ASG-Zeke Schedule Download Agents List Row 1 of 3Command ===> Scroll ===> PAGE NETREGID ===> Primary Commands: ADD DELETE EDIT END Line Commands: D - Delete E - Edit NETREGID Description ****************************************************************************** UNIXAGNT ZEKE AGENT UNIX ******************************* Bottom of data *******************************


Add a new agent Make the following entries:


• Enter the Netregid on the NETREGID line.

• Press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 4.

Update an existing agent for which you know the Netregid

Make the following entries:

• Enter EDIT on the command line.


• Press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 5.

Update an existing agent for which you do not know the Netregid

Enter E next to the appropriate Netregid and press Enter. The Schedule Download Agent Specification screen is displayed. Go to step 5.


302

4 In the Description field, enter the description of the agent and press Enter.

Note:You may not change the information in the NETREGID field.

5 Press F3 to save the information and to return to the Schedule Download Agents List screen.

Delete an agent for which you know the Netregid


• Enter DELETE on the Command line.


• Press Enter. The Schedule Download Agent Specification screen is displayed. Enter DELETE on the Command line to confirm the delete. Press Enter. The Netregid that you selected is deleted and the Schedule Download Agents List screen is displayed. This procedure is complete.

Delete an agent for which you do not know the Netregid

Enter D next to the appropriate Netregid and press Enter. The Schedule Download Agent Specification screen is displayed. Enter DELETE on the Command line to confirm the delete. Press Enter. The Netregid that you selected is deleted and the Schedule Download Agents List screen is displayed.

ASG-Zeke Schedule Download Agent Specification Command ===> Primary commands: CANCEL END NETREGID: NTAGENT Description:

ASG-Zeke Schedule Download Agents List Agent added Command ===> Scroll ===> PAGE NETREGID ===> Primary Commands: ADD DELETE EDIT END Line Commands: D - Delete E - Edit NETREGID Description ******************************************************************************* NTAGENT ZEKE AGENT NT UNIXAGNT ZEKE AGENT UNIX ******************************* Bottom of data ********************************


7 Maintaining Zeke

303

Setting Auto RepliesZeke allows you to automatically respond to outstanding replies (WTORs) from your Zeke-controlled jobs which have static or predictable responses. The following generation options affect automatic replies.

To activate automatic replies



3 In the Aur field, enter Y to enable the automatic reply facility. This facility is designed for job events that require message replies.

4 In the Aurintv field, specify the number of seconds to check for automatic replies (from the default of 01 to 99).

Note: If you have numerous jobs with auto replies, use a lower value to improve throughput. If you only have a few jobs with auto replies, use a higher value to decrease system overhead.

5 In the Aurmsg field, enter Y (default) to issue a message to the operator when an automatic reply is supplied.

6 Cycle Zeke if you have updated the Aur field.

7 To activate the updated Aurintv and Aurmsg options, enter ZRELOAD GENOPT on the Command line and press Enter.

Aur Enables or disables automatic responses to messages and replies.

Caution! You must cycle Zeke if you update the Aur generation option.

Aurintv Specifies the interval to check for automatic responses.

Aurmsg Indicates whether the operator is notified of issued auto responses.


304

Loading the Work Center to SQTThe Loadcomm option specifies whether to load work centers to the schedule queue table (storage). We recommend you activate this option if you use work centers that are loaded into the schedule queue at schedule load time. This 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 command.

Note:The Loadcomm option must be set to Y to access or complete work centers from an OpsCentral console.

To activate the LOADCOMM option


2 Press F8 to scroll to the Loadcomm field.

3 In the Loadcomm field, enter the code indicating whether to load work centers to the schedule queue table.


5 To load work centers to the current schedule queue, enter ZRELOAD SCHD on the Command line and press Enter.

Code Meaning

Y (Default.) Load work centers to the schedule queue table. This option loads the work center more efficiently, but requires more above the line CSA storage.

N Do not load work centers to the schedule queue table.

7 Maintaining Zeke

305

Calculating Tape Drive UsageThe Calctap option automatically tracks the number of tape drives used by a job.

If Calctap=Y, the calculated value is displayed on the EMR with an asterisk (*), indicating it is an Zeke-calculated value. A value without an asterisk indicates that it is a user-assigned value.

Zeke keeps a running count of all tape mounts for a job, not just the tape drives. For example, if a job mounts 2 tapes in the same step or 1 tape per step in a 2-step job, the calculated tape value is 2. Zeke does not recognize that the tape mounts are probably done on 1 drive. If you need a better way to handle this situation, use logical resources.

Note:If Dispsel=N, then Calctap=Y is ignored.

To deactivate automatic calculation of tape drive usage


2 Press F8 to scroll to the Calctap field.

3 Enter N to deactivate tracking and recording the number of tape drives used by a job.

Note:If the Tapes field on the EMR is specified, Zeke requires that many tape drives be available before it will dispatch a job.



306

Checking the Dispatch QueueThis option specifies when Zeke will check the dispatch queue.

To specify when to check the dispatch queue


2 Press F8 to scroll to the Eojwake field.

3 Enter the code indicating whether to check the dispatch queue for batch jobs at EOJ.


Maintaining the Job Restart FacilityThis option specifies whether a restart facility (like Zebb) is used.

To specify the restart facility


2 Press F8 to scroll to the Jobrst field.

3 In the Jobrst field, enter the code, in upper case, indicating which type of restart facility (if any) is used.


Code Meaning

Y (Default.) Zeke checks the dispatch queue at EOJ of each job.

N Zeke checks the dispatch queue every 60 seconds. This value may delay dispatch of an event for up to one minute.

Code Meaning

blank (Default.) No restart facility

ZEBB ASG-Zebb

CA-11 Restart facility from Computer Associates

7 Maintaining Zeke

307

Maintaining Networking OptionsThe following generation options are related to networking.

Caution! You must cycle Zeke if you update the Posid or Netregid generation options.

To activate the networking options

1 Access the Option System Directory screen in edit mode. as instructed in “Accessing Generation Options” on page 286.


3 In the Posid field, enter the code indicating whether Zeke will assign a unique ID to each Zeke-controlled job event.

Posid Specifies whether to assign a unique POSID (positive event ID) to each Zeke job event. The job is tracked by its jobname and assigned POSID until the job is done.

Note:All Zeke systems sharing the same Zeke database must have the same value for Posid.

Posidend Specifies whether Posid information is placed at the beginning or end of Zeke-controlled jobs.

Netregid Specifies the Zeke logical Netregid (network registration ID), which is used to identify the current Zeke system.

Code Meaning

Y (Default.) Assign a unique POSID (positive event ID) to each Zeke job event. The job is tracked by its jobname and assigned POSID until the job is done.

If Posid=YES, 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 EXECPGM=IEFBR14,COND=ONLY,PARM=(A913EC42,199915C,00000012//A9BD957F,’MEDADVLP’,LDVLP,’DVLPZEKE‘)

The placement of the POSID information is determined by the Posidend generation option.


308

4 If Posid=Y, in the Posidend field, enter the code indicating where the POSID information is placed in the job.

For most jobs, the POSID is acceptable in either location. But there are cases in which one location might 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 (JOBLIB, for example) the job will fail if Posidend=NO. If a job has in-stream data (SYSIN DD *) containing an imbedded job, the job will fail if Posidend=YES.

Note:For multiple event versions, the version number is passed to the submitting system as part of the POSID information. If the submitting system also supports multiple event versions, the version number enables the dispatch system to correctly identify the associated SQR.

Note:Zeke does not support multiple jobs per event, and when Posid=YES, only the first job of an event is considered a Zeke job. All other jobs in the same event are considered non-Zeke jobs. Therefore, each job should be placed in a separate event.

N Do not assign a unique ID and tracks jobs by job name only.

Note:A POSID cannot be used with JCL sources of CMS or JCLMAN. If using either of these services, set Posid=NO or specify Control=NO for each event when submitting from these sources.

Note:To override the Posid option for a specific event, use the Control field on the EMR screen. (When Control=NO, Zeke does not recognize the event as Zeke-controlled, and marks the job as EOJ at dispatch.)

Code Meaning

Y POSID is placed at the end of the job, as the last step

N (Default.) POSID is placed at the start of the job, as the first step

Code Meaning

7 Maintaining Zeke

309

If a remote job is dispatched to another Zeke system via DMS, the Posidend generation option on the execution system governs POSID placement. If a remote job is dispatched to another system through NJE, the dispatching Zeke’s Posidend generation option governs POSID placement.

5 In the Netregid field, enter the Zeke unique DMS logical registration ID. Remote events dispatched by other Zeke systems to be monitored by this Zeke should specify this Netregid in the remote event’s Target field.

6 Cycle Zeke if you have updated the Posid and/or Netregid generation options.

Maintaining Inter-product CommunicationZeke can communicate with other ASG products (such as Zebb) via API interfaces. You can control whether EMR messages are enabled or suppressed.

To enable communication with other ASG products via APIs


2 Press F8 to scroll to the Zprdcom field.

3 In the Zprdcom field, enter the code indicating whether to activate inter-product communication. Valid values are:

4 Cycle Zeke (ZKILL COLD or ZKILL TRACK) to activate the updated option.

Code Meaning

Y Default. Activate product-to-product communication. Added or deleted events in Zeke will be reflected in Zebb. A COPY or COPYALL performed in Zeke will also be reflected in Zebb.

Note:When ZPRDCOM=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 (CICS, TSO, etc.) who can add or delete events.

N Do not activate product-to-product communications.


310

To suppress inter-product messages


2 Press F8 to scroll to the Zprdsemr field.

3 In the Zprdsemr field, enter the code indicating whether to suppress inter-product EMR messages. Valid values are:

Note:For this option to be effective, the Zprdcom generation option must be set to Y.


Code Meaning

Y Prevent messages regarding EMR changes from being sent to other products, such as Zebb; send SQR messages only.

N Default. Allow both EMR and SQR messages to be sent. Changes to Zprdsemr require a ZRELOAD GENOPT command to become effective.

7 Maintaining Zeke

311

Using Shared DatabasesThe MultSys generation 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.

Caution! You must cycle Zeke COLD if you update the MultSys generation option.

If more than one system is sharing the same Zeke database, the following generation options must be set to the same values for each Zeke system sharing the database:

• Posid

• Posidend

• Trigdt

• Trigjob

• Wktrgdn

To use shared databases


2 Press F8 to scroll to the Multsys field.

3 Enter the code indicating whether the database is shared by more than one machine.

4 Cycle Zeke COLD to activate the updated option.

Code Meaning

Y Default. Database is shared by more than one machine.

N Database is not shared. This reduces unnecessary I/O.


312

Dispatching Events After Zeke Start-upThis procedure is used to specify whether events are dispatched after Zeke start-up. We recommend you do not place Zeke on hold with Oprhold=Y for start-up.

Issuing the command ZRELOAD GENOPT also places Zeke on hold if Oprhold=Y.

To dispatch events after Zeke start-up

1 Access the Option System Directory screen in edit mode as instructed in “Accessing Generation Options” on page 286.

2 Press F8 to scroll to the Oprhold field.

3 Ensure that the code equals N (default) to have the Zeke ready to dispatch events after start-up.

Note:When the value is set to Y, events cannot be dispatched. Issue the command ZREL SYSTEM to release Zeke.


Building EDB IndexesZeke provides the following options for building EDB indexes:

Caution! If you update either of these generation options, you must cycle Zeke.

DSPIndex For ESA-capable dataspaces only; this option is used to specify whether you want Zeke to build a full EDB index for each event (maximum size = 2 gigabytes). Setting this option to Y is recommended for large databases because it:

• Improves ZADD command processing

• Improves online browsing and retrieval of jobs

• Enables the PATH, PREDECESSOR, and SUCCESSOR functions from the EMR

EDBindex Specifies whether you want Zeke to build a reduced version of the EDB index in core. This requires approximately 20 bytes of above-the-line CSA storage for every event in the database. Setting this option to Y results in improved speed and efficiency of ZADD command processing.

7 Maintaining Zeke

313

To set the options for building EDB indexes

1 Access the Option System Directory screen in edit mode as instructed in “Accessing Generation Options” on page 286.

2 Press F8 to scroll to the field you want to update.

3 In the DSPIndex field, enter the code indicating whether to build a full EDB index for each event.

4 In the EDBindex field, enter the code indicating whether to build a reduced version of the EDB index in core.

Note:If both the DSPIndex and EDBindex generation options are set to Y, the DSPIndex option overrides EDBindex.

5 Cycle Zeke (using ZKILL COLD or ZKILL TRACK) if you have changed either of these options.

Code Meaning

Y Build a full EDB index for each event

N (Default.) Do not build a full EDB index

Code Meaning

Y (Default.) Build a reduced version of the EDB index in core

N Do not build a reduced version of the EDB index in core


314

Obtaining Operating PasswordsZeke requires a password for each CPU serial number it operates on. The password is provided by ASG and authorizes Zeke to operate on a specific CPU model and serial number.

A different password is required for a system operating under VM than is required for that same system running native on a CPU. The Zeke database holds up to 20 operating passwords. Zeke operates on a system if any of the 20 passwords in the database is the required password.

Zeke will run up to 45 days without a password. Each time Zeke is started without a new password, a console message is issued indicating the number of days that Zeke has left to operate.

If you replace the CPU, you must contact ASG for a new operating password. You can update the password using either the Zeke batch utility program or the online, as in the following procedure.

To obtain a new operating password

1 Verify that you have a signed License Agreement.

2 Obtain the following information:

• Company name, address, telephone, and FAX number

• Contact name

• Operating system

• Product release number

• Real CPU model and serial number

Virtual/Guest machine model and serial number

Note:The CPU model is the type of machine, such as 4341, 4381, etc. The CPU serial number is the 6-character serial number of the machine. For guest VM systems, the serial number is the 6-character serial number of the virtual machine located in the VM directory.

3 Contact ASG Customer Support.

4 After you receive your new password, log on to the Zeke online facility.

5 From the Zeke Primary Menu, enter 4.2 on the Option line.

7 Maintaining Zeke

315

The Operating Password Information screen is displayed.

6 Enter EDIT on the Command line and press Enter.

7 Enter the new password in the next consecutive Pass field and press Enter.

Note:The operating password must be in the Zeke database at all times.

ASG-Zeke Operating Password Information BROWSE Command ===> Primary Commands: BROWSE EDIT Zeke Operating Passwords Pass 1: 9OF9K3R4 Pass 2: XKVUHXKS Pass 3: Pass 4: Pass 5: Pass 6: Pass 7: Pass 8: Pass 9: Pass 10: Pass 11: Pass 12: Pass 13: Pass 14: Pass 15: Pass 16: Pass 17: Pass 18: Pass 19: Pass 20: The Zeke operating passwords shown on this display screen are those that allow Zeke to operate on a particular CPU serial number. These passwords are obtained from Allen Systems Group, Inc. for each CPU on which Zeke is to operate. These passwords change only when the CPU on which Zeke is operating changes.


316

Changing ISPF Color SchemeZeke allows you to control the colors that display on your ISPF online screens. The color and attributes you choose only affect your logon ID and remain in place until you change them again. The command INIT resets the colors back to the default values.

To change the colors on your Zeke ISPF screens

1 From the Zeke Primary Menu, enter option C.1 and press Enter.

The User Color Select Screen is displayed.

2 Decide the type of data you want to change. The following is a description of each type.

ASG-Zeke User Color Select Screen Command ==> Primary Commands: INIT SAVE Description Color Hilite Screen Title ________ ________ Field and Column Heading ________ ________ Normal Text ________ Accented Text ________ Normal Output Data ________ ________ Accented Output Text ________ ________ Normal Input Data ________ ________ Accented Input Data ________ ________ Input Field in Error ________ ________ Warning Field ________ ________ Exception Field ________ ________ Colors: Red, Blue, Green, Yellow, White, Pink, Turq Hilite Keywords: Reverse, Uscore, Blink, or leave blank

Data Type Description

Screen Title The first line of the screen.

Field and Column Labels that identify the fields. Field names and Heading column headings are treated the same, whether the fields are arranged in a column or placed next to the field name that applies to them.

Normal Text Descriptive or narrative text that usually explains or introduces other information displayed on the screen. For example, in the phrase ‘D - Delete line,’ ‘Delete line,’ which is the explanation, is normal text, while ‘D,’ which is the entry, is accented.

7 Maintaining Zeke

317

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

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

5 Enter SAVE on the Command line and press Enter.

Accented Text Descriptive or narrative text that is highlighted for emphasis, such as the line command letter to enter in the Select field. For example, in the phrase ‘D - Delete line,’ ‘D,’ which is the entry, is accented.

Normal Output Data Displayed information that has previously been entered or has been calculated by the system.

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

Normal Input Data Fields available for entry.

Accented Input Data Fields available for entry; highlighted for emphasis.

Input Field in Error Not used at this time.

Warning Field Not used at this time.

Exception Field Not used at this time.

Data Type Description


318

Using the Audit FacilityThe audit log facility tracks Zeke database activity and logs the information in the Audit Log database. You decide what types of activity you want to audit. Actions you can log include the following:

• Issued Zeke operator commands

• Changes to any of the following:

— Event’s status (scheduled, active, EOJ, etc.)

— Zeke variable record

— Event record

— Internal security class record

— Calendar record

— External security class definition record

— Zeke generation option

— Your company name or address

— Internal security operator record

— Password

— Partition definition

— Pool record

— Resource definition record

— SQR

Whenever the item you select is updated, the update is automatically recorded on an audit log. The records created by Audit can be used for reporting updates to the respective databases. You can generate reports to view the logged information. Refer to your ASG-OASIS for z/OS Reference Guide for more information on Audit reporting.

You must set the OASIS option ZEKEADT for the number of Zeke Audit logs and allocate the datasets for the Audit logs before any activity will be logged. Refer to your ASG-OASIS for z/OS Reference Guide for information on the OASIS00 options.

7 Maintaining Zeke

319

To select the types of activity to log for Audit


The Audit Log Options screen is displayed.


Note:The system must be added before you can set the audit log options for it. See “Accessing Generation Options” on page 286 for information on adding a system.

3 Enter Y in a field to activate auditing of that area. Each field defaults to N.

4 Re-cycle both Zeke and OASIS for the changes to go into effect.

ASG-Zeke Audit Log Options BROWSECommand ===> System: Primary Commands: BROWSE EDIT System: ******** Job Execution Flow: Y Zeke Command: Y Zeke Variable: Y Event Master Record: Y Security Class: Y Calendar: Y External-Security Class Def: Y Genopt: Y Name/Address: Y Security Operator: Y Password: Y Partition/Initiator: Y Pool: Y Resource Definition: Y Schedule Queue Record: Y


Display the audit log for a specific system

Enter BROWSE on the Command line and the system name in the System field and press Enter.

Define or update the audit log for a single system

Enter EDIT on the Command line and the system name in the System field and press Enter. The Audit Log Options screen is re-displayed.


320

Database MaintenanceDatabase maintenance can be performed when you want to:

• Allocate and catalog datasets

• Backup the database

• Move or enlarge a database

• Recover from a hardware failure

• Recover the contents of a destroyed database

• Run Zeke and use electronic vaulting

Note:We recommend you use the BACKUP command in the Zeke utility program to back up your database at least once a day.

Creating the Zeke Databases (Primary and Vault)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 of the utility program.

Since the Zeke batch program is independent of the operating system, it requires that OASIS be active. Special provisions have been made to allow OASIS to be activated without Zeke being active. This is a normal condition during the process of installing Zeke.

Note:This procedure must be performed before using Zeke for the first time.

To initialize and create the Zeke databases

1 Start the OASIS started task, using the following syntax:

START procname,S=subsys,OASIS='(aa,bb)'

where:

procname = Name of the OASIS start-up procedure.

subsys = OASIS subsystem name.

(aa,bb) = OASISxx options member name suffix and console option.

7 Maintaining Zeke

321

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 the following sample. This job allocates and catalogs the dataset.

//ZFRMT JOB ,MSGLEVEL=(1,1),CLASS=A//ZALLOC EXEC PGM=IEFBR14//ZNEW DD DSN=ZEKE.DATABASE,DISP=(NEW,CATLG),// UNIT=SYSDA,VOL=SER=PERMVL,SPACE=(CYL,(10),,CONTIG)//*//ZUTL EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKENEW DD DSN=ZEKE.DATABASE,DISP=OLD//ZEKECAT DD DSN=ZEKE.DATABASE,DISP=OLD//SYSIN DD * CREATE/*

3 For electronic vaulting, run the CREATE function using a jobstream similar to the following sample.


322

This job creates both the primary Zeke database and the Zeke vault database for electronic vaulting.

//ZALLOC EXEC PGM=IEFBR14 //ZNEW DD DSN=ZEKE.PRIMARY.DATABASE,DISP=(NEW,CATLG), // UNIT=xxxx,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG) //ZVAULT DD DSN=ZEKE.VAULT.DATABASE,DISP=(NEW,CATLG), // UNIT=XXXX,VOL=SER=vvvvvv,SPACE=(CYL,(30),,CONTIG) //ZUTLP EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKENEW DD DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR //ZEKECAT DD DSN=ZEKE.PRIMARY.DATABASE,DISP=SHR //SYSIN DD * CREATE/*//ZUTLV EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKENEW DD DSN=ZEKE.VAULT.DATABASE,DISP=SHR //ZEKECAT DD DSN=ZEKE.VAULT.DATABASE,DISP=SHR //SYSIN DD * CREATE/*

4 Start Zeke with the ZEKECAT DD pointing to the primary database and the ZEKEVLT DD pointing to the vault dataset.

7 Maintaining Zeke

323

Backing Up the Zeke DatabaseThis procedure explains how to back up a Zeke database to a tape or disk file. The BACKUP command copies the contents of the Zeke database in case it must be restored.

Use the BACKUP command to back up your database at least once a day. ASG recommends backing up the database prior to each scheduling run.

The database can be copied in two formats.

Note:The Zeke database is not a normal sequential file and most backup/copy utilities do not perform properly when used with the Zeke database. Only use the Zeke BACKUP and RESTORE functions.

The Zeke database BACKUP DD name is ZEKEBK. In the ZEKEUTL jobstream, enter the Zeke backup file dataset name. This is a sequential file; it does not matter how you allocate this file (e.g., 80x80 or 512x512) because when the Zeke backup process writes to the file, it will alter the LRECL and block size of the file as needed.

Use the parameter DATASPACE with the BACKUP batch utility to improve back up processing performance.

To back up the Zeke database

Run a job to back up the Zeke database to tape. The following JCL is a sample job:

//ZEKEBKUP JOB ,MSGLEVEL=(1,1),CLASS=A//ZBK EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKEBK DD DSN=ZEKE.BACKUP,DISP=(NEW,KEEP),// VOL=(RETAIN,SER=ZEKETP),UNIT=TAPE,LABEL=(1,SL)//SYSIN DD * BACKUP DISK DATASPACE/*

Format Description

Physical Copy on tape is an exact copy of the database on disk.

Logical Copy follows the pointers to the different types of database records and groups all the elements of an event together. Multiple logical backups can be merged into one database. Refer to your ASG-Zeke for z/OS Reference Guide for more information on restoring a database backup.


324

Note:The Zeke database is enqueued for the duration of the physical backup. We recommend scheduling the backup during the period that has the least amount of CPU activity.

Restoring the Zeke DatabaseThis procedure describes how to restore a Zeke database from backup. This procedure uses the BACKUP, CREATE, and RESTORE functions. You can use this procedure to recover the contents of a destroyed database and to move and/or enlarge the database. The file must have been produced by the utility program BACKUP function.

Note:If a Zeke database containing SQRs that were downloaded to Zeke Agent is restored from a backup, either the RESTORE NOSCHED option should be used, or the job records should be removed from the Zeke Agent that is maintaining copies of the SQRs.

Caution! Do not use the RESTORE function to restore an active database.

Refer to your ASG-Zeke for z/OS Reference Guide for more information on the BACKUP, CREATE, and RESTORE functions.

Before you perform this procedure, ensure that you allocate contiguous space in cylinders for the new Zeke database dataset (no secondary extents). Allocate more space if you are enlarging the database.

To restore the Zeke database

1 Run a job to backup the Zeke database.

The following JCL is a sample for backing up the database to tape:

//ZEKEBKUP JOB ,MSGLEVEL=(1,1),CLASS=A//ZBK EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKEBK DD DSN=ZEKE.BACKUP,// DISP=(NEW,KEEP),// VOL=(,RETAIN,SER=ZEKETP),// UNIT=TAPE,LABEL=(1,SL)//SYSIN DD * BACKUP/*

2 Terminate Zeke by issuing the ZKILL COLD command. (Do not use the ZKILL WARM or ZKILL TRACK command.)

7 Maintaining Zeke

325

3 Terminate any other active Zeke systems sharing the database.

Caution! Do not use the OASIS STOP command.

4 Terminate any other OASIS-supported products sharing this same subsystem.

5 Terminate OASIS using the XKILL command.

Note:Ensure that all products have been terminated before issuing the OASIS XKILL command.

6 Allocate a new Zeke database and rename the old database as a precautionary measure.

7 Restart OASIS. OASIS becomes active without activating Zeke.

8 Run a Zeke utility job using the CREATE control statement to allocate a new Zeke database. ZEKENEW and ZEKECAT must both point to the new database.

The following is a sample of the database CREATE jobstream:

//ZEKECRET JOB ,MSGLEVEL=(1,1),CLASS=A//ZUTL EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKENEW DD DSN=new database name,// DISP=(NEW,CATLG),UNIT=SYSDA,// VOL=SER=ZEKEVL,// SPACE=(CYL,(10),,CONTIG)//SYSIN DD * CREATE/*

Note:The message CATALOG INITIALIZATION COMPLETE is displayed when the job is complete.

9 Perform a logical restore. The following is sample JCL to restore over an existing database; however, you must change the dataset names to reflect the actual ones in the following DD statements:

• ZEKECAT DD = new enlarged database name

• ZEKENEW DD = new enlarged database name

• ZEKERS DD = backup dataset name


326

//ZEKEREST JOB ,MSGLEVEL=(1,1),CLASS=A//ZRS EXEC ZEKEUTL,PARM=’SUBSYS=ZDEV’//ZEKECAT DD DISP=SHR,DSN=new enlarged database name //ZEKENEW DD DISP=SHR,DSN=new enlarged database name//ZEKERS DD DSN=last Zeke backup name,DISP=OLD,// VOL=SER=ZEKETP,UNIT=TAPE,LABEL=(1,SL)//SYSIN DD * RESTORE LOGICAL MESSAGE NEWCATLG/*

Note:The RESTORE function builds the Zeke database specified in the ZEKENEW DD statement.

10 Edit the started task procedure and change the ZEKECAT DD statement to point to the new database, if applicable.

11 If Zeke vaulting is being used, pre-allocate the vault database to be contiguous and have the same attributes (size, cylinder boundary, device type) as the new database. Copy (IEBGENER) the Zeke database to the Zeke vault dataset.

12 ASG recommends that you cycle OASIS at this point.

13 Start Zeke.

Moving the Vault DatabaseAt times, it may be necessary to relocate the vault database to a new DASD volume. Zeke does not initialize if the vault database is pointing to a different primary database. This prevents accidental initialization with the wrong dataset and getting the vault “out of sync” with the primary database (especially if other systems are running).

If it becomes necessary to relocate the vault database to a new DASD volume, you must force Zeke to use this new vault volume. To do so, use one of the following procedures.

Moving the vault database—recommended procedure

1 Create the new vault database as instructed in “Creating the Zeke Databases (Primary and Vault)” on page 320.

2 Using the ZEKEUTL utility function, disable the old vault by specifying VAULT DISABLE in the SYSIN (ZEKEVLT DD points to the original vault DSN). This clears the vault dataset name and volume information in the primary database.

7 Maintaining Zeke

327

3 Terminate all active Zekes sharing this primary database/vault database pair (ZKILL COLD command).

4 Restart your Zeke with the ZEKEVLT DD pointing to the new vault DSN.

The first Zeke that is started up initializes the new vault dataset from the primary database and writes the new dataset name and volume information to the primary database.

Moving the vault database—emergency procedure

1 Create the new vault database as instructed in “Creating the Zeke Databases (Primary and Vault)” on page 320.

2 Enter the ZDISABLE VAULT operator command on any Zeke system sharing the old vault dataset. Vaulting is then disabled on all systems sharing the old vault.

3 Zeke is now running WITHOUT electronic vaulting recovery services. Schedule hourly backups of the Zeke database until you can restore electronic vaulting.

Caution! Vaulting remains disabled from the time the ZDISABLE VAULT command is issued until the new vault is initialized.

4 Restore electronic vault support at the next available opportunity. To do so:

a Terminate all active Zekes sharing the database (ZKILL COLD command).

b Start Zeke with ZEKEVLT DD pointing to the new vault DSN.

The first Zeke that is started up initializes the new vault dataset from the primary database.


328

Recovery Using Electronic VaultingElectronic vaulting offers an advantage over traditional restore recovery methods because it eliminates the cost of down time for hardware failures. Zeke’s secondary DASD unit replicates the primary Zeke database. When a record is written to the primary Zeke database, the electronic vaulting option writes a duplicate record to the secondary database.

The primary and secondary databases must have the same allocation size. For example, if a database allocates 250 contiguous cylinders for the primary Zeke database, then a second Zeke vault database must be a contiguous 250 cylinders as well. This second database should be located on a different DASD unit on a string of DASD with a different controller for disaster recovery considerations. Only use electronic vaulting if ample additional DASD is available.

If there is a hardware failure that makes the Zeke database unavailable, you can recover full services with the following procedure.

If you must recover more quickly than you can copy the Zeke database, you can by using the partial recovery procedure; however, you will have to bring Zeke back down at the first opportunity to complete the recovery.

Note:We strongly recommend that you perform the full recovery procedure the first time, rather than the partial recovery.

To fully recover electronic vaulting

1 Terminate Zeke. If you want to terminate the Zeke system and place it in SMF recording mode, issue the ZKILL TRACK command. (See “Continuous Job Tracking” on page 331 for details). Otherwise, issue the ZKILL COLD command. If this fails, cancel Zeke.

2 Use the OASIS batch utility to STOP ZEKE.

Note:You may see message X00224E. This does not indicate a problem. It simply means the Zeke code has already been pulled for the subsystem.

3 Allocate a dataset of the same size and on the same device type (but not on the same volume) as the damaged database. The dataset must be in a contiguous extent.

4 Copy (IEBGENER or FDR) the undamaged vault database to the new dataset on the same DASD device type (i.e., 3380 to 3380, 3390 to 3390).

7 Maintaining Zeke

329

5 Change the started task JCL so that ZEKECAT points to the newly copied database and ZEKEVLT remains pointing to the undamaged vault database.

6 Start Zeke.

7 Resume processing.

To partially recover electronic vaulting

1 Terminate Zeke by issuing the ZKILL COLD command. If this fails, cancel Zeke.

2 Use the OASIS batch utility to STOP ZEKE.

Note:You may see message X00224E. This does not indicate a problem. It simply means the Zeke code has already been pulled for the subsystem.

3 Rename the vault dataset.

4 Change the started task JCL so that ZEKECAT points to the renamed vault database and comment out the ZEKEVLT DD.

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

6 Start Zeke. You will receive the console message Z0129R during start-up. This is normal.

7 Again, ensure that there are no other Zeke systems currently active on the old database and enter NO in response to message Z0129R. Initialization will continue with the old vault database as the new primary database.

If there are other active Zeke systems, enter YES in response to message Z0129R. Initialization is terminated with message Z0130E. You must first bring down other active Zekes and restart Zeke (step 5).

8 Resume processing.

9 Zeke is now running without electronic vaulting recovery services. Schedule hourly backups of the Zeke database until you can restore electronic vaulting.


330

10 After you have performed the partial recovery procedure, restore electronic vault support at the next available opportunity:

a Allocate a dataset of the same size and on the same device type (but not on the same volume) as the existing database. The dataset must be in a contiguous extent.

b Format the new dataset as a database using the batch utility CREATE function.

c Terminate all Zekes sharing the database by issuing the ZKILL COLD command. (To determine whether there are Zeke systems sharing the database, use the ZD COM operator command.) If this fails, cancel Zeke.

d Change the started task JCL by adding the ZEKEVLT DD to point to the newly created database.

e Start Zeke. The first Zeke system that is started initializes the vault dataset from the primary database.

f Resume processing.

7 Maintaining Zeke

331

Continuous Job TrackingZeke can track relevant system and event activities during periods when both the Zeke and OASIS subsystem have been terminated. This ability is useful when you need to apply Zeke or OASIS maintenance, or recover database services by switching to a vault database. With continuous job tracking, disruption to Zeke job dispatching is minimized.

When Zeke (and even OASIS) are terminated, the system activities are recorded. When Zeke is restarted, the recorded activities are played back, and the schedule is updated accordingly. Activity that can be tracked includes:

• Starting of jobs, job steps, and programs

• Ending of jobs, job steps, and programs

• Datasets that are closed

During playback, Zeke will satisfy triggers and update the status for job activity that occurred while Zeke was down.

Note:Logged system activity is not maintained across an IPL.

Terminating Zeke Using ZKILL TRACKUse the ZKILL TRACK operator command to terminate the Zeke system and place it in SMF recording mode. Zeke issues an informational message indicating that system activity is being recorded. Termination continues as it would for a traditional ZKILL COLD, except that only the IEFUJV SMF exit is de-installed. See also the section on ZKILL in your ASG-Zeke for z/OS Reference Guide.

Caution! Do not use ZKILL TRACK under the following conditions:

— If Zeke will be restarted on a different database than it is currently using.

— If the database will be restored before Zeke is restarted.

— If a full schedule run will occur before Zeke is restarted.

— If you are upgrading to a different release of Zeke.

Z49F05I Zeke SMF Recording startedZ49F01I ZEKE TERMINATION BEGINNING Z0904I ZEKE COMMAND PROCESSOR TERMINATING X00354I Program ZEKE48H (IEFUJV ) de-installed Z0505I Zeke Schedule Monitor terminating Z5H02I Zeke Remote Dependency task terminating Z5I14I Zeke Agent task terminating Z5G07I Schedule load task terminating Z5F06I Zeke Multi-System communications terminating


332

Note:ZKILL TRACK can be used if you are upgrading to a different PTF level within the same release.

SMF Recording Mode

LimitationsThe following Zeke and OASIS services are not available when Zeke is shut down using ZKILL TRACK:

• Auto-replies

• JCL error tracking

• ‘NOTDURING’ WHEN condition processing

• Zeke condition code processing. Condition code processing is suspended for any job active while Zeke is in recording mode. Condition code processing cannot resume for that job run even for steps that occur after Zeke is restarted.

• Zeke activities requiring DMS services, for example:

— Remote triggers from jobs running on Zeke but dispatched by a remote system are not sent back to the dispatcher until Zeke is restarted.

— Remote dependencies sent to Zeke are not satisfied.

— Schedule updates from a Zeke Agent that has downloaded the Zeke schedule are not communicated. However, send, store, and forward processing by Zeke Agent will send the updates when Zeke is restarted.

The following services are not available if OASIS is also terminated:

• Zeke and OASIS batch utilities

• Report Writer

7 Maintaining Zeke

333

Database Considerations

If multiple Zeke systems share a database:

• A Zeke in record mode does not make schedule updates. The other Zekes will be notified of schedule changes made as playback occurs.

• Only A/EOS, A/B/EOP, and DSN triggers needed by the schedule are recorded. If another Zeke adds any triggers of these types to the schedule, they are not tracked.

• When terminated with ZKILL TRACK, Zeke retains enough information from its internal tables to determine which SMF records will trigger an event. Zeke conserves CSA use by recording only SMF records that are pertinent. If an event is added by another Zeke, the event is not seen by the recording system until Zeke is restarted.

• No changes to the generation options by another system will be reflected in the recording system until Zeke is restarted.

CSA Considerations

Caution! Because Zeke SMF recording logs system activity in ECSA, ASG recommends restarting Zeke as soon as possible to minimize the storage allocated.

SMF recording periodically queries the amount of unallocated ECSA remaining. Starting when only 2 MB of ECSA remains, and every 100 K thereafter, Zeke issues the following warning:

Z48R4W Zeke SMF Recording: 2.0 MB ECSA remainingZ48R5W Zeke SMF recording will halt with 1.0 MB ECSA remaining

This warning gives you the opportunity to restart Zeke before any recorded activity is discarded. If any triggers are discarded due to the ECSA limit, a start-up message indicates the number of triggers affected.

When 1 MB remains, Zeke stops recording activity and issues the following 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 will be used—a little over 1 K for each record logged. However, terminating Zeke with the TRACK option just before leaving for vacation could cause a problem. In cases where ECSA usage becomes a system constraint, a utility is provided to stop SMF recording and free all recorded records.


334

//ZEKECLR JOB (ACCT),,CLASS=A,MSGLEVEL=(1,1)//STEP1 EXEC PGM=ZEKE11M,REGION=2048K,// PARM='SUBSYS=SSSI,REPORT'//STEPLIB DD DISP=SHR,DSN=ZEKE.LINKLIB//SYSPRINT DD SYSOUT=*/*//

If the REPORT parameter is specified, a report of all the discarded triggers is printed to SYSPRINT:

Zeke SMF Triggers Discarded

NAME JOBNAME PROCSTEP TRIGGER TIME SCHED DATE EVENT VERZEKE ZEKEAG53 EOS 16:53:42ZEKEAG53 ZEKEAG53 EOJ 16:53:42JCLPREP SPTJX1A EOS 16:53:43SPTJX1A SPTJX1A EOJ 16:54:08QATST01 QATST01 BOJ 16:54:00 2007/006 000001 00000QAUTIL QATST01 BOP 16:54:01STEPUSI QATST01 EOS 16:54:11QATST01 QATST01 EOJ 16:54:11QATST02 QATST02 BOJ 16:54:01 2007/006 000002 00000QAUTIL QATST02 BOP 16:54:01STEPUSI QATST02 EOS 16:54:11QATST02 QATST02 EOJ 16:54:11

7 Maintaining Zeke

335

Applying MaintenanceWhen 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 in order to reload these modules.

If OASIS is terminated also, all OASIS modules are unloaded so that maintenance may be applied.

SMF PlaybackWhen 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 may 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 loadedZ03B03I SYSGEN record ******** successfully loadedZ0401I Zeke Variable Monitor initializedZ0701I Zeke System startup successful 5.4 Z540A000Z5G06I Schedule load task enabledZ5G01I Initial schedule load startedZ0501I Zeke Schedule Monitor enabledZ0510I Zeke ... Time is now 16:26:48X00353I Program ZEKE48H installed as an IEFUJV exitZ5F02I Zeke Multi-System communications enabledZ5H01I Zeke Remote Dependency task enabledZ0901I Zeke Command Processor enabledZ5I01I Zeke Agent Schedule Download Task EnabledZ5G03I Schedule load completeZ0502I Zeke Event dispatching enabledZ45P1I Playback of SMF records has begunZ45P6I 23 System triggers loggedZ45P7I 29 Kbytes ECSA usedZ45P8I 0 Kbytes used for filter tablesZ45P9I 13 Kbytes saved by filter tablesZ45PAI 11 triggers discarded by filter tablesZ45PBI 0 triggers discarded due to ECSA limitZ45P5I Playback of SMF records is complete


336

337

8Chapter 8:Variables

Variables, user-defined keywords representing values, enable Zeke to automatically carry out a wide variety of specialized operations. With variables you can automate several important tasks, such as JCL modifications, job triggering, and console response handling.

Topic Page

Zeke Variables 338Naming Zeke Variables 338Setting Zeke Variable Values 338Maintaining Variable Documentation 343

OASIS Variables 347Naming OASIS Variables 348Setting OASIS Variable Values 349Temporary OASIS Variables 350

System-Dependent Variables 351

How Variables Are Used 351Using Variables to Trigger Events 352Using Variables to Control Jobstream Flow 353Using Variables to Restart a Job 354Substituting Variable Values in JCL 356IF Clauses On SET Statements 359Variable Substitution in SCOM Events 359


338

Zeke VariablesA Zeke variable is a symbol beginning with a dollar sign ($) that has a user-assigned value of either numeric or character format.

Zeke supports the following types of variables:

• Zeke variables

• OASIS variables

• System-dependent variables

Naming Zeke VariablesIt is a good idea to name variables according to the jobstream, application, or function they are related to, because standard naming conventions help prevent questions about the purpose of a specific variable. For example, a restart variable that relates to JOBA is named $JOBASTEP.

Zeke variable names can be up to 16 characters long, and the first character must be a dollar sign ($). The remaining 15 characters can be alpha or numeric.

Note:Do not use special characters (hex value ‘7F’ or less) in variable names, because Zeke assumes that these characters are the end of the variable name during variable substitution. After the dollar sign, use only the characters 0 through 9 and A through Z.

Setting Zeke Variable ValuesYou do not need to define a variable before using it in JCL or a work center SET statement. They remain in the database, accessible to all systems sharing that database, until explicitly deleted.

A character value for a Zeke variable can be up to 64 bytes long; a numeric value can be from -2,147,483,647 to +2,147,483,647.

8 Variables

339

Zeke variable values can be established or changed using any of the following methods:

• ZEKESET SET statement. For example:

//S1 EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’//SYSPRINT DD SYSOUT=*//SYSIN DD * SET VAR $ABC EQ 'ERROR'SET VAR $XYZ EQ $XYZ + 1 /*

Refer to your ASG-Zeke for z/OS Reference Guide for more information on defining variables using SET VARIABLE.

• ZSET operator command. For example:

ZSET VAR $XYZ EQ 0 Variable $XYZ = 0ZSET VAR $OPERFLG EQ NO Variable $OPERFLG = NO

Refer to your ASG-Zeke for z/OS Reference Guide for more information on using the ZSET operator command.

• Calling the subroutine ZEKEVAR. (Refer to your ASG-Zeke for z/OS Installation Guide for more information.)

• User programs, using a supplied subroutine.

• Work center events. See “Work Centers” on page 161.

• The Zeke online facilities. ISPF is shown in the following procedure.

Note:This procedure cannot be used to define or maintain OASIS variables. To access OASIS variable maintenance, issue the OVAR primary command from any Command line in the Zeke ISPF online facility.

To define and maintain a Zeke variable



340

The Variable Selection Criteria screen is displayed.


ASG-Zeke Variable Selection Criteria Command ===> Variable Name ===> Primary commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Enter Selection Mask in any field to be compared for selection. Clear any field that is not to be used for selection. * -is a prefix/suffix indicator. ? -is a wild/place holder character. * Selection Field Masks * Variable: Type: C - character, N - numeric System: Appl: GroupID: UserID: Date Range: - (MM/DD/YYYY) or (DD/MM/YYYY) Time Range: - (HH:MM:SS)


Define a new variable Enter ADD on the Command line and the variable name in the Variable Name field. Press Enter. Go to step 3.

Update a variable for which you know the name

Enter EDIT on the Command line. Enter the variable name in the Variable Name field. Press Enter. Go to step 3.

Update a variable for which you do not know the name

Enter any information you know for any of the Selection Field Masks fields. Press Enter. The Variable Name Directory screen is displayed.

8 Variables

341

3 Perform the steps in the Action column depending on the desired result.

The Variable Name Record Functions screen is displayed.

ASG-Zeke Variable Name Directory Row 1 to 6 of 6 Command ===> Scroll ===> PAGE Variable name ===> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit O - dOcument Variable Name Appl Grp UserID Date Time System $ED 01/30/2007 12:13:35 ZEQA $KATHYG 02/08/2007 14:53:44 ZEQA $KATHYG1 02/07/2007 16:54:40 ZEQA $KATHYG2 02/07/2007 16:54:48 ZEQA $KATHYG3 02/07/2007 16:55:57 ZEQA $STPNAME 01/20/2007 15:16:32 ZEQA ***************************** Bottom of data ******************************


Update the variable Enter E in the unlabeled Selection field to the left of the variable you want to edit, and press Enter.

View the variable value Enter B in the unlabeled Selection field to the left of the variable you want to view, and press Enter.

Delete the variable Enter D in the unlabeled Selection field to the left of the variable you want to delete, and press Enter. The Variable Name Record Functions screen is displayed. Enter DELETE on the Command line and press Enter to confirm the deletion. This procedure is complete.

ASG-Zeke Variable Name Record Functions EDIT Command ===>

Variable Name: $PAYCHECK

Primary Commands: ADD BROWSE CANCEL COPY DELETE DOCUMENT EDIT

Appl: PAYROLL GroupID: CHK UserID: KAC Desc: STARTING CHECK NUMBER Desc2:

Curr Value: 1001 Force upper: Y Value set by: U (J=Job P=Program U=User) Name: SPTKAB Date/Time: 01/30/2007 14:39:55 System: SYSD Part/Init: TSO

Prev Value: 1001 Value set by: U (J=Job P=Program U=User) Name: SPTKAB Date/Time: 01/30/2007 14:39:51 System: SYSD Part/Init: TSO


342

4 Optionally, enter a description of the variable in the Desc/Desc2 fields. This description appears on summary screens and is printed on reports.

5 If you want to set the initial value of the variable, enter the value in the Curr Value field.

6 In the Force Upper field, specify of the following codes if the Current Value includes alpha characters:

Note:If the Current Value is numeric only, the Force Upper option is ignored.

7 Enter information in the following fields to group variables for report selection.

8 In the Userid field, enter a character string up to eight bytes in length. This field is used to determine which users can update the variable.

9 Press Enter. The variable is updated.

Code Meaning

Y Forces the Current Value string to uppercase.

N Keeps the case of the Current Value exactly as entered. Specify this code if you need to allow mixed-case values for variable substitution.

Field Description

Appl User-assigned code to identify the application the variable is a part of. The Report Writer, Work Center Control, and Zeke operator commands use this field to sort and select variables.

Groupid User-assigned code to identify the group the variable is a part of. This field can be used as a subset of the application ID.

8 Variables

343

Maintaining Variable DocumentationThe Variable Maintenance facility gives you a place to maintain and store Zeke variable-related documentation, provided you have security authorization.

To access and maintain variable documentation


2 Access the Variable Name Directory screen, as described in “To define and maintain a Zeke variable” on page 339.

3 Enter the line command O to the left of the Variable Name field and press Enter.

The Document Segments screen is displayed. This screen allows you to access screens where you can maintain documentation for Zeke variables.

Note:If an asterisk (*) is displayed to the left of the documentation type, documentation already exists for the variable.

ASG-Zeke Variable Name Directory Row 1 to 6 of 6Command ===> Scroll ===> PAGE Variable name ===> Primary Commands: ADD BROWSE COPY DELETE DOCUMENT EDIT Line Commands: B - Browse C -Copy D - Delete E - Edit O - dOcument Variable Name Appl Grp UserID Date Time System $ED 01/30/2007 12:13:35 ZEQA $KATHYG 02/08/2007 14:53:44 ZEQA $KATHYG1 02/07/2007 16:54:40 ZEQA $KATHYG2 02/07/2007 16:54:48 ZEQA $KATHYG3 02/07/2007 16:55:57 ZEQA $STPNAME 01/20/2007 15:16:32 ZEQA ***************************** Bottom of data ******************************

ASG-Zeke Documentation Segments EDITOption ===> Primary Command: DELETE Variable: $KATHYG1 System: ZEQA User: Group: Appl: Documentation Record Selection Options 1 SCRATCH Scratch pad 2 TEXT Text information 3 NOTE Note pad information


344

4 Enter one of the following codes on the Command line to select the type of documentation you want to work with:

Note:OASIS variables are maintained through the OASIS Variable Maintenance screens. See “OASIS Variables” on page 347 for an overview.

Maintaining Scratch Pad or Note DocumentationYou can add, browse, edit, or delete Scratch or Note documentation from the Variable option. The Scratch Pad or Note Information screens allow you to define or browse up to 10 lines of information for a variable.

Note:Even though there are separate documentation areas for Scratch Pad and Note Information, the procedures have been combined because the screen layouts, number of lines of text, and fields displayed are identical.

This screen is like a sticky note. It is used to pass notes from shift to shift, or from one department to another. The operator should always review scratch pad or note pad information before a job runs.

This area can also be used for “quick reference” information.


Access scratch pad documentation


Access text documentation Enter 2 and press Enter. Go to “Maintaining Text Documentation” on page 346.

Access note documentation Enter 3 and press Enter. Go to “Maintaining Scratch Pad or Note Documentation” on page 344.

8 Variables

345

To maintain scratch pad or note documentation

1 Access the Documentation Scratch Pad or Note screen as instructed in “Maintaining Variable Documentation” on page 343.

2 To delete the scratch pad or note information, enter DELETE on the Command line and press Enter. To confirm, re-enter DELETE on the Command line and press Enter.

3 To add or update scratch pad or note information, enter text information in the Line area. You can enter up to 60 characters per line, and up to 10 lines of text.

4 When you have finished adding or updating information on the Scratch Pad or Note screen, press Enter to update the data.

ASG-Zeke Documentation Scratch Pad EDCommand ==> Primary Commands: BROWSE CANCEL DELETE EDIT Line 1 PASS THIS TO 3RD SHIFT 2 3 4 5 6 7 8 9 10 Variable name: $TAPUG1 System: ZEQA Userid: Groupid: Appl:


346

Maintaining Text DocumentationYou can add, browse, edit, or delete text documentation from the Variable option.

This screen allows you to define a sizeable amount of information for a variable (up to approximately 450 records).

To maintain text documentation

1 Access the Text Documentation screen as instructed in “Maintaining Variable Documentation” on page 343.

2 Use standard ISPF editing commands to enter text in the line area, or to the right of the column placeholder field, if there is existing text. You can enter up to 80 characters per line, and up to several hundred lines of text. Page forward to access an additional screen.

3 When you have finished adding or updating information on the Text screen, press Enter to update the data.

ASG-Zeke Text Documentation EDIT Command ===> Columns 000 000 Scroll ===> PAGE Variable: $KATHYG1 System: ZEQA User: Grup: ****** *************************** Top of Data *****************************==MSG> -Warning- The UNDO command is not available until you change ==MSG> your edit profile using the command RECOVERY ON. 000001 IF YOU NEED TO UPDATE THIS VARIABLE MORE THAN 3 TIMES PER SHIFT, (NOT000002 PER DAY), NOTIFY THE SHIFT SUPERVISOR. THE BASE VALUE WILL NEED TO BE000003 RECONFIGURED BASED ON NUMBER OF OCCUPIED SEATS AND AVAILABLE LINES.****** *************************** Bottom of Data **************************

8 Variables

347

OASIS VariablesOASIS variable values can be substituted in the same areas as Zeke variables (JCL, ZEKESET, SCOM, etc.), but they differ from Zeke variables in the following aspects:

• OASIS variables reside in an OASIS database on DASD, and are therefore retained across system outages and IPLs. The database is accessible to all OASIS-supported applications using the same subsystem, so you can use OASIS variables to communicate information between your applications.

• OASIS variable values can be from zero to 255 characters in length. They can contain any displayable character in the EBCDIC character set, including 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 for variables where you can define, edit, and view OASIS variable names and their values.

• The value substituted in an OASIS variable can be based on one or more of the following qualifiers. This allows for multiple values for a single variable name. (An unqualified variable has only one value associated with it.)

• Various types of formatting for substitution are allowed. One type of formatting allows you to substitute the entire variable value or just a portion of it. For example, you can specify to substitute only the last 2 characters of the value, or only the second word of the value. You can also pad the substituted value with extra characters.

The following substitution functions can be performed on OASIS variables:

• Schedule date • Group ID

• Run date • User ID

• Job name • Event number

• Netregid • Version number

• Application ID • System name

Substitution Function Description

DATE Convert a date to a specified format and return the result.


348

• Functions can be performed on OASIS variables using the SSS0UTV utility program. SSS0UTV can be used to create new variable value records, replace or delete existing value records, and list variable definition records and value records.

• The TVSET function allows 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 (that is, for the current run of the job). See “Temporary OASIS Variables” on page 350 for more information.

Refer to your ASG-OASIS for z/OS Reference Guide for detailed information that you need to know before using OASIS variables for the first time.

Naming OASIS VariablesOASIS variable names can be up to 64 characters long. The first character can be any of the following:

• Dollar sign ($)

• Underscore (_)

• Pound sign (#)

• At sign (@)

• Any capital letter (A through Z)

The remaining characters can be any of the above characters or the digits 0 through 9. Imbedded blanks are not allowed in variable names.

EXEC Call an exec and return its return value.

ITEM Return the value of a qualifier.

LEFT Return the left-most positions of the string.

RIGHT Return the right-most positions of the string.

SUBSTR Return a substring of the string.

SUBWORD Return one or more specified words from the string.

UPPER Return the string in upper case.

VALUE Return the value of a variable whose name is obtained from the value of another variable or a nested function call.

Substitution Function Description

8 Variables

349

Setting OASIS Variable ValuesOASIS variable values are set using any of the following methods:

• The SSS0UTV utility program.

• The OASIVAR Application Programming Interface. Refer to your ASG-OASIS for z/OS Reference Guide.

• The OASIS online, as shown in the following procedure.

To maintain OASIS variables

Issue the OVAR primary command from any Command line in the Zeke online facility.

The OASIS Variable Maintenance screen is displayed, where you can add, edit, delete, or browse variable definition records and variable value records.

OASIS Variable Maintenance OPTION ===> 12/20/00Primary 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


350

Temporary OASIS VariablesThe TVSET function, unique to OASIS variables, allows you to:

• Create and set the value of a temporary OASIS variable, which remains available until your program terminates.

• Override an existing OASIS variable value temporarily.

For Zeke-dispatched jobs, you can use TVSET if you want to override an existing variable value without changing the variable itself.

Syntax

//*TVSET {variable name} {new value}

Caution! 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 the following 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 the //*TVSET statement is used in JCL, it appears in the output stream when run, and it 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 to be in 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.

8 Variables

351

System-Dependent VariablesSystem-dependent variables allow 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, use three dollar signs ($$$) as the first three characters of the variable name (for example, $$$NAME). Zeke replaces the third dollar sign with the 1-character ID of the dispatching CPU.

The following are examples of system-dependent variables:

Note:System-dependent variables cannot be used with Zeke operator commands (such as 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. For example, $$AFLAG instead of $$$FLAG.

System-dependent variables can be used in ZEKESET statements and by programs that call the ZEKEVAR subroutine.

How Variables Are UsedZeke and OASIS variables are powerful job management tools. They perform the following functions:

• Trigger jobs (Zeke variables only)

• Prevent jobs from being dispatched

• Control jobstream flows by selecting the steps to be processed at execution time

• Simplify jobstream recovery and restart

• Provide automatic restart at the cancelled step

• Substitute values in OS and JES JCL statements at submission time

• Pass information from one job, job step, or program to another

Job Control Variable Name CPUID Actual Name Used

FL$$$PRFLGG A $$APRFLG

$$$OPER1 C $$COPER1

$$$VAR01 B $$BVAR01

$$$TEST A $$ATEST


352

• Document cancellation reason

• Establish relationships between jobs

Using Variables to Trigger EventsA dependency is a condition that must exist before an event can be dispatched. Dependencies include a job that must process, a dataset that must close, or a variable that must be set to a specific value. See “WHEN Conditions” on page 135 for more information.

Using a variable value as a dependency enables you to trigger or prevent a job from occurring through job streams and programs. Additionally, this feature enables you to trigger jobs through external actions, such as the receipt of data for an application. In this case, an event can be established with a variable dependency that can be satisfied by the ZSET operator command.

For example, jobstream PRUPDT is a job with a dependency condition. The dependency states that variable $PRDATA1 should have a value of YES. The WHEN condition to establish this job is as follows:

WHEN (VAR $PRDATA1 EQ YES)

Also, this jobstream is not processed until the job PREDIT is processed with no errors. A situation determined outside of the computer room. When word is received that the results of job PREDIT are satisfactory, and job PRUPDT can be processed, the operator simply informs Zeke by entering the command:

ZSET VAR $PRDATA1 EQ YES

This command satisfies the job dependency for PRUPDT, and if the Early/Schedule time has been reached, the event is moved to the dispatch queue. The event is dispatched from the dispatch queue when all resource requirements are available.

Additionally, the variable $PRDATA1 needs to be reset to NO when PRUPDT is complete. This is accomplished by a ZEKESET program SET statement after the last step in the jobstream.

The variable $PRDATA1 could be set to YES in several ways:

• Using a ZEKESET program SET statement.

• Using the subroutine ZEKEVAR. This facility enables programs to make decisions that can affect the dispatching of subsequent events.

• Using the Zeke online work center facility.

Note:OASIS variables cannot be used to trigger jobs.

8 Variables

353

Using Variables to Control Jobstream FlowVariables can control the flow of OS job streams.

As a simple example, the following jobstream consists of four steps processed daily, and an additional job step to be processed only when the second step creates a special file of exception records.

//ARUPDT JOB ,AR.DEPT,MSGLEVEL=(1,1),CLASS=X//INIT EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’//SYSPRINT DD SYSOUT=A//SYSIN DD *SET VAR $$$ARFLG EQ NO Begin with variable=NO/*//ARSTP1 EXEC PGM=PROG1 Step 1//INFILE DD DSN=AR.MASTER.TAPE,DISP=OLD,UNIT=TAPE,// VOL=SER=ARTAPE,LABEL=(1,SL)//SYSPRINT DD SYSOUT=A//*//ARSTP2 EXEC PGM=PROG2 Step 2//OUTFILE DD DSN=AR,MASTER.TAPE,DISP=(NEW,KEEP),UNIT=TAPE,// VOL=SER=ARTAPE,LABEL=(1,SL) //EXCPFILE DD DSN=AR.EXCPS,DISP=(NEW,CATLG),UNIT=SYSDA,// SPACE=(132,(2000,500))//SYSPRINT DD SYSOUT=A//ARSTP3 EXEC PGM=PROG3 Step 3//RPTS DD DSN=&&AR.REPORTS,UNIT=SYSDA,DISP=(NEW,PASS),// SPACE=(132,(2000,500)) //SYSPRINT DD SYSOUT=A//*

//ARSTP4 EXEC PGM=PROG4 Step 4//TAPEIN DD DSN=SOME.DATASET,DISP=OLD,UNIT=TAPE //RPTSIN DD DSN=&&AR.REPORTS,DISP=(OLD,DELETE),UNIT=SYSDA

//SYSPRINT DD SYSOUT=A//*//CHKEXCP EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’//SYSPRINT DD SYSOUT=A//SYSIN DD *SET CONDCODE 20 IF $$$ARFLG NE YES Bypass Step 5 if variable=NO/* //ARSTP5 EXEC PGM=PROG5,COND=(0,NE,CHKEXCP) Step 5//EXCPFILE DD DSN=AR.EXCPS,DISP=(OLD,DELETE)//SYSPRINT DD SYSOUT=A //

In this jobstream:

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

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


354

• 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 COND on the EXEC statement for Step 5 tests the condition code of the previous step. If the condition code is 20, Step 5 is bypassed.

Using Variables to Restart a JobVariables can be used to restart a job at a cancelled step. A variable can save the name of the last job step processed in a jobstream, so that if any step abends, the job can be restarted at that step.

This facility works best when used with an MVS COND=ONLY step. The step which specifies COND=ONLY is executed if any previous step in the jobstream abends. If no abend occurs, the OS bypasses the step. If an abend occurs, the COND=ONLY step sets up the information for the restart.

For example, in the following jobstream, the variable $CL01P043STEP saves the restart step name.

//CL01P043 JOB ,MSGLEVEL=(1,1),RESTART=$CL01P043STEP... JCL FOR STEP 1/* ... JCL FOR STEP 2 /* ... JCL FOR STEP 3 Last normal step//EOF EXEC PGM=ZEKESET,PARM=’SUBSYS=ZDEV’ Normal end of job reached here//SYSPRINT DD//SYSIN DD *SET VAR $CL01P043STEP EQ * For next time job is run/*//ABEND EXEC PGM=ZEKESET,COND=ONLY EXEC ONLY IF ABEND OCCURRED//SYSPRINT DD//SYSIN DD * Come here only if job abendsSET 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 OS restart parameter. This starts job processing at the named step. Since the parameter is a Zeke variable, Zeke supplies the value through the internal reader when the job is submitted.

If the job completes normally, ZEKESET sets the variable to * (asterisk). z/OS starts the jobstream at the first job step the next time it is run.

8 Variables

355

The last job step specifies COND=ONLY on its execute statement. If the job completes normally, z/OS 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 which previously failed (the value of $CL01P043STEP). No external action is necessary.

To restart at a step other than the one that abends, enter the ZSET command to set $CL01P043STEP to the desired restart step name. For example, say that the above jobstream abends in step CLSTP3, but the jobstream needs to be restarted at step CLSTP2 for some reason. Enter the following command to begin processing at CLSTP2 the next time it runs:

ZSET VAR $CL01P043STEP EQ CLSTP2

The OS does not execute the COND=ONLY step, even though the job did not run properly, in any of the following conditions:

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

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

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

If these conditions become a major factor in system reliability, use the following 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 about to be executed (the step following the ZEKESET step). This ensures that the variable is always set to the step to be restarted, even on full system failures.


356

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

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 variable values in the following 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 variable value into the EXEC statement and the procedure can substitute this value into the statements in the procedure. For example, EXEC PROC=TEST1, PARM1=$VAR.

During variable substitution, trailing spaces are truncated from character values to a maximum of 1 trailing space, and leading zeros are truncated from numeric values, leaving 1 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 may be shifted to the left if the variable value substituted in for the variable name is shorter than the variable name itself. Contact ASG Customer Support for assistance.

8 Variables

357

The following are examples of variable statements and the actual values. Assume that the variables have these values:

$X = PR01P001$Y = 0074

Sample Statement

Resolved Statement Explanation

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

//$X $Y //PR01P001 74 This example leaves a space between the variables.

//$X..$Y //PR01P001.74 If you want the variable and the value to be separated by a period after concatenation, enter 2 periods between the variable and the value.

//$X JOB,PAYROLL.EDIT

//PR01P001 JOB,PAYROLL.EDIT

If the variable value is longer than the variable name, the data following the variable shifts to the right. If the variable value is shorter than the variable name, the data following the variable shifts to the left.

Y EQ $Y Y EQ 74 The leading zeros are dropped.

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

$X, PR01P001, A comma after the variable name is retained with the value.

word$Y word74 A word adjacent to the variable name remains adjacent to the variable value.


358

Use the following control statements, beginning in column 1, to activate or deactivate variable substitution support.

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.

If Zeke is generated with Subdata=YES, variable substitution is always 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 dispatch of the event. Refer to your ASG-Zeke for z/OS Reference Guide for more information on OPTION NOSUB.

Statement Purpose

ZEKE-CTL NOSUB Deactivate substitution.

ZEKE-CTL SUB Reactivate substitution.

8 Variables

359

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

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

Variable Substitution in SCOM EventsAn SCOM event can contain a maximum of 60 characters of commands or responses per line. When using variable substitution in an SCOM, the length of each line must be no greater than 60 bytes including the variable values. For example, suppose you submit the following SEND command from an SCOM:

SE ‘THIS IS A TEST TEST TEST TEST TEST TEST.’,USER=($ABCVAR)

and the value of the variable $ABCVAR equals ABCABCABCABCABC. The length of the command as it appears above is exactly 60 bytes. However, once 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 variable value.


360

361

9Chapter 9:Security

Zeke security can be defined using its internal security function or through the OASIS External Security Interface (ESI). Zeke‘s versatility allows you to control access to Zeke objects and functions from another vendor’s security product, or your own, provided the product uses the SAF (System Authorization Facility) interface. You may even use a combination of internal and external security packages. It is recommended that you fully understand Zeke internal and external security features before implementing either, or both of them.

Topic Page

Preparing for Implementation 362

Objects and Functions 363

Security Processing 364Security Calls 365Processing Logic 367Tracing Processing 368

Internal Security 369Online Access: Logging On 370Function Access: Class Record 370Record Access: Operator Record 371Batch Access 371Setting Up Internal Security 372

Zeke External Security 382Security Classes 383Resource Names 386Implementing External Security 387


362

Preparing for ImplementationSecuring information for any computer system can be a complex task, requiring knowledge of the security package, the information to be protected, and the application that stores the information. With this in mind, we recommend that your Zeke security team be made of people who are familiar with Zeke, system programming functions, and, if applicable, your security product.

Note:Before attempting to implement any security for Zeke, 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.

In general, you must answer the following questions before deciding on a security approach:

• What exactly needs to be secured?

— Access to information (for example, objects like the Zeke database and specific records)

— Access to Zeke (for example, functions like primary menu options and Zeke operator commands)

— Access to a combination of information and the Zeke functions

• Do you want to use Zeke internal security, an external security package, or a combination of the two?

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

9 Security

363

Objects and FunctionsBefore you can decide what needs to be secured, you must understand the different security approaches that Zeke uses.

The following table lists the specific objects and functions that can be protected with Zeke security (internal and/or external).

Security Approach Description

Object Controlling access to the information contained in a data structure, such as a record or file. This includes controlling access to individual Zeke EMRs, Zeke SQRs, and Zeke variables.

Securing by object protects the information regardless of how access is attempted: by command, by batch utility, or by online program. For example, securing EMRs as objects protects them regardless of whether access is attempted from the EVENT online function, the EVENT batch utility command, or the LIST EVENTS report writer facility.

Function Securing by function means controlling access to commands, programs, and online screens. These functions provide access to the information and also control Zeke processing. For example, securing access to Zeke commands by function controls access to records, such as variables (ZSET VAR), EMRs (ZADD EV), and SQRs (ZALTER EV); and controls access to Zeke processes that do not use records, such as ZHOLD SYS and ZKILL.

Specific functions that can be protected with Zeke internal security are:

• Zeke Primary Menu Options

• Batch Equivalents of Primary Menu Options

• Zeke Operator Commands

Objects Internal Security External Security

Zeke Database

EMRs

Schedule Records

Variables

Calendars

Generation Options (GENOPTS)


364

Security ProcessingZeke has its own internal security facility. However, you can control access to Zeke objects and functions from any SAF-compliant security product through OASIS External Security Interface (ESI). Additionally, you can use a combination of both security methods. This is why it is important that you understand both internal and external security before deciding on an approach.

Zeke external security provides increased benefits over internal security by including the ability to secure at a more detailed level, more comprehensive security, and more flexibility in establishing access criteria.

This section gives a general overview of Zeke security processing, whether you are using internal, external, your own security exit or a combination of all three.

Initiator Definitions (GENSYS)

Company Name and Address

Pool Definitions

Internal Security Records (Class & Operator)

Operating Passwords

Logical Resource Records

ESI Definition Records

Functions

Primary Menu Options

Batch Equivalents of Primary Menu Options

SCHEDULE Function

ZEKESET Commands

Individual SCOM Command Lines

Zeke Operator Commands

Online Event Add (by event type)

Objects Internal Security External Security

9 Security

365

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

Each security call is governed by the following hierarchy of authority levels (from lowest to highest):

Each security call specifies the minimum authority level required for the request. For example, if you have granted a user UPDATE access to a record and the user is only requesting READ access, then Zeke allows the request, since READ access is assumed to be granted for someone with UPDATE access.

Note:Internal security uses only READ and WRITE access. WRITE is 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.

Sometimes a single user request results in more than one security call. For example, if a user issues the command ZALTER EV 1 WHENOK, two security calls are made. One security call to determine if the user is authorized to issue ZALTER operator commands and the second to determine if the user is authorized to update the schedule record for event 1. In this example, the user must be authorized for both, or the request is denied.

Additionally, if a single user request requires access to multiple records, even more security calls may be generated. For example, if a user issues the command ZDISPLAY JOB, several calls are made. One security call to determine if the user is authorized for the ZDISPLAY command, followed by a call for every job-type schedule record to determine which ones the user is authorized to display (READ access). In this example, if the user is authorized for ZDISPLAY, then only the records that the user has READ access to are displayed. However, if the user is not allowed to issue ZDISPLAY operator commands, then the entire request is denied.

Authority Level Description

Read Can browse, display, and list records.

Update Can modify existing records, plus all the authority of READ access.

Alter Can add and delete records, plus all the authority of UPDATE access.

Control Can perform the requested command (only applies to individual SCOM command lines).


366

A security call can originate from any of the following sources:

Source Description

Online A request from the Zeke online system.

• Logging on

• Accessing one of the primary menu options

• Accessing a specific record or group of records

• Issuing a command, such as ZDISPLAY

• Invoking special commands, such as a catalog STATUS

• Adding or updating commands in an SCOM event

• Logging off

Batch A request from a batch program or job (ZEKE utility or ZEKESET).

• Logging on (first Zeke access attempt)

• Accessing function that is the batch equivalent of one of the online functions

• Invoking a batch-only function, such as SCHEDULE or LIST

• Accessing a specific record or group of records

• Using SET ZCOM to issue command, such as ZDISPLAY

• Issuing a command using SET SCOM ... within an execution of ZEKESET

• Invoking a global database function, such as BACKUP or RESTORE

• Logging off Zeke in this initiator

Console A request from the system console.

• Issuing a command, such as ZDISPLAY

• Accessing a specific Zeke record or group of records

ZEKECMD A request from the ZEKECMD subroutine. For example, issuing a command. This could originate from a batch program, a TSO or CMS user’s address space, or a multi-user address space (CICS).

ZEKEVAR A request from the ZEKEVAR subroutine. For example, accessing a variable. This could originate from a batch program, a TSO or CMS user’s address space, or a multi-user address space (CICS).

9 Security

367

Processing LogicThe following flowchart represents the general flow of Zeke security.

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

Security calls to ESI have been hard-coded for the following Zeke global database functions: CREATE, RESTORE, BACKUP, and STATUS. This is done to provide the most security when the integrity of the database is in question and security criteria may not be accessible. So, if you have a security product on your system, you may be required to set up and define authorized users for the Z$CATAL external class before you can run the CREATE or RESTORE. You can do so by granting at least one user ALTER-level

N

Y

Y

Y

N

N

Y

Y

N

N

Access Request

Allow/Deny Request

A

A

Hard-CodedESI Call?

Genopt ESI ACTV = Y?

Does ESI apply to this call?

Does ESI say to revert to internal?

Does internal security apply?

Internal security verification

Call External Security Interface

Call User Security Exit, if exists


368

authority to the following resource (entity) names: BACKUP##, CREATE##, RESTORE#, BLOCK###, STATUS##. If you do not define the class and authorized users, your request may be denied, depending how your external security product handles calls with undefined classes. If the return code generated and passed to SAF from your security product is 0 or 4, Zeke allows the request without the class and resource names. If the return code is not 0 or 4, the request is denied. Also, if a user security exit exists, the request may be denied. See “Security Classes” on page 383 for important details about the Z$CATAL class.

External security for other calls can be activated with the generation option ESI Actv. If ESI Actv 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 may be situations when the administrator wants to revert to internal security. This is especially useful in “backup” security situations when the security product is down.

A user security exit (ZEKE15B) is always called, if present, 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. It cannot allow requests that have already been denied.

Tracing ProcessingYou can trace the Zeke security processing flow using the command ZD SEC. 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 (ZEKE15B).

Use the trace to help determine the following information:

• If a security exit is being called and what effect it has on the security decision

• What element of the security process is making the allow/deny decision

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

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

9 Security

369

Internal SecurityZeke internal security uses two types of records, stored in the Zeke database, to control access: operator records and class records.

There are four different IDs related to internal security:

Note:Keep in mind that class has a different meaning in internal security than in external security and the two concepts are unrelated.

Record Type Description

Operator Control access to records (objects) in the database, such as schedule records, EMRs, work centers, documentation, and variables.

Class Control access to Zeke functions, such as the Zeke Primary Menu Options and Zeke operator commands.

ID Description

Logon ID ID of the user trying to access the online system. Usually a TSO, CMS, CICS, ROSCOE, or IDMS user ID.

Operator ID A user defined to Zeke. Usually a TSO, CMS, CICS, ROSCOE, or IDMS user ID. The operator ID, combined with the user ID, determines which events and variables a user is authorized to view or update. Any number of user IDs can be assigned to an operator ID.

User ID Zeke events and variables have a User ID field. Access to individual event and variable records is determined by the value of this field. An Zeke operator record contains a list of masks to be compared with User ID to control access to the event or variable for a specific operator ID. The User ID does not have to correspond to any logon or operator ID. Any number of events or variables can have the same user ID.

Class ID Defines the online functions that can be accessed and the Zeke operator commands that are allowed for each operator ID. Any number of operator IDs can be assigned to the same class.


370

Online Access: Logging OnYou can either restrict online logon access to specific logon IDs or you can allow anyone to logon with a default level of authority, with more specific criteria for certain defined users. The generation option Reqopid determines whether a specific logon ID is required or whether a default ID is allowed.

If Reqopid=Y, an operator ID matching the user’s logon ID must be defined in the Zeke database, or access is denied. If access is granted, the assigned operator ID is used for all internal security calls required during the session.

If Reqopid=N, first Zeke attempts to find a matching operator ID. If a match is found and access is granted, the assigned operator ID is associated with the user. If a match is not found and access is granted, the operator ID in the generation option Defopid is associated with the user. The associated operator ID is used for all internal security calls required during the session.

Caution! Verify that an operator record is defined for the value specified in the Defopid generation option; otherwise, access is denied for anyone whose logon defaults to this ID.

Function Access: Class RecordAfter logon, the class record controls the access to the Zeke Primary Menu Options. The class record also controls which Zeke operator commands the user is authorized to issue. In the online system all Zeke operator commands are issued under the ZCOM/SCHEDULE VIEW option.

Not only must a user be authorized to issue a command, a user may also need access to the Zeke database records and the ZCOM online function. This depends on whether the command accesses records and whether the command verb implies Write access.

For example, to be fully authorized to issue the command ZADD EV 1, the user must have the following levels:

• Yes for the ZADD command

• Write for the ZCOM menu option

• Write for event 1

9 Security

371

Record Access: Operator RecordThe operator record controls which specific EMRs, schedule records, and variable records a user can access and to what level. When an event or variable record is defined, you can assign a user ID to that record. Any number of records can have the same user ID.

Then, on the operator record, you enter that same user ID, or a mask of that user ID, to be compared when access to the event or variable record is attempted. Next to each user ID mask you can specify the level of authorized access (NONE, READ, or WRITE) for each record type.

On the operator record, the list of user IDs (or masks) is tested from the top down and the first match is used. If no match is found, access is denied.

Batch AccessBatch security processing is activated by the generation option Batsec=Y. Batch security controls access to the Zeke database and functions as attempted by batch jobs. Batsec does not affect external security nor does it affect the user security exit (ZEKE15B).

A batch logon security call is made when the first Zeke batch function in a job is processed. If a ZEKE15B user security exit does not specify an Zeke operator ID to be associated with the job, then Zeke uses the default specified in the generation option Batoprid. If a matching operator record cannot be found, access is denied.

If Zeke is down when the batch job starts, an internal batch logon is performed for each function or record access requested in the job.

Once the operator ID is determined, security processing works the same as it does for online access. If any access requests are denied, the action taken depends on the generation option Secfail. If Secfail=C, the job is cancelled. If Secfail=I, the denied request is ignored and processing continues.

Note:The SCHEDULE function and the ZEKESET commands that do not access variables are not secured through internal security. These functions must be secured by either external security or by a ZEKE15B user security exit.


372

Setting Up Internal SecurityBegin by first checking or changing the default Generation Options that affect internal security. Go to “Setting Internal Security Requirements” on page 372.

If you decide to structure your internal security with restrictive access you will need to maintain class IDs and operator IDs.

• Set up class IDs to group individuals who need similar access to the online functions and commands. Go to “Setting Up Class IDs” on page 376.

• Define an operator ID for each user who is to be granted access to the system. Define which online functions and operator commands can be accessed by assigning a class ID. Go to “Setting Up Operator IDs” on page 379.

Setting Internal Security RequirementsThe following generation options affect internal security processing.

Option Description

Batch Requirements:

Batoprid Default operator ID used for internal security verification of batch functions. The default is BATCH.

Batsec Indicates whether Zeke is to provide internal security for batch pro-cessing.

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

9 Security

373

Online Requirements:

Defopid Default operator ID to be assigned when an undefined operator logs on. The default is OPERATOR. Required if N is entered in the Reqopid field.

When Zeke is first installed, the default operator ID is OPERATOR. This logon ID is also tied to any commands issued from the console. Therefore, any changes made to the security class for OPERATOR are also made for the console. For example, if access to the ZADD com-mand is changed to N, then the ZADD command can no longer be per-formed from the console. To restrict operator commands from being entered at the console, change the OPERATOR security class ID ac-cordingly. However, if you need the console to be available to issue all commands, do not change the OPERATOR security class ID.

Since there is no way to change the ID for the console, we recommend changing the default operator ID to another name to avoid confusion with the OPERATOR operator ID used at the console.

Note:If Reqopid=Y, then it is not necessary to change the default operator ID.

Reqopid Indicates whether an authorized operator ID is required when logging on to Zeke.

Caution! Do not change Reqopid to Y until at least one operator ID is defined to Zeke with at least write authority for the security function. Otherwise, all users will be locked out of the online facility.

User Exit:

SECEXITW={xxxx} The number of bytes of storage allocated to call the Zeke security exit routine (ZEKE15B).

Option Description


374

To set the internal security requirements

1 Determine if you want to require a user’s logon ID to be defined in the Zeke database as an operator ID before logon access to the Zeke online is granted.

If yes, define at least one new operator ID with write access to all security functions to ensure that you are not locked out of the system.

If no, define a new operator ID to be used as the default when an undefined user logs on to Zeke.

• From the Zeke Primary Menu, enter 6.1 and press Enter.

• From the Directory of Operator IDs screen, enter ADD on the Command line.

• Enter the new default operator ID in the Operator ID field and press Enter. The Operator Detail screen is displayed.

• In the Class ID field, use the default class of A and press Enter. This allows access to all Zeke functions and operator commands as long as class A has not been changed.

2 If you want to invoke internal security for batch processing, define an operator ID for the name you will use in the Batoprid generation option. The default for Batoprid is BATCH; however, you can define it to match the ID that the security exit calls, or a newly defined operator ID.

• From the Zeke Primary Menu, enter 6.1 and press Enter.

• From the Directory of Operator IDs screen, enter ADD on the Command line.

• Enter the new default operator ID in the Operator ID field and press Enter. The Operator Detail screen is displayed.

• In the Class ID field, use the default class of A and press Enter. This allows access to all Zeke functions and operator commands as long as class A has not been changed.

3 From the Command line, enter =4.1 and press Enter.

9 Security

375


4 Enter E to the left of the system you want to change and press Enter.

Note:*********' is the generic system; if generation options are not set for a system, it defaults to the generic system values.

5 The first Generation Options screen is displayed with the options in alphabetical order. Use the F8 or F7 keys to scroll.

ASG-Zeke Option System Directory Row 1 to 1 of 1 Command ===> Scroll ===> PAGE System ===> Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete E - Edit System ******** MEDAZ510 ZK51VLT****************************** Bottom of data *****************************

ASG-Zeke Generation Options EDIT Command ===> Scroll ===> PAGE Zeke System: ******** Abhold: N (Y or N) Yes to hold recurring events if abended Aur: Y (Y or N) Yes to enable automatic responses Aurintv: 01 (1 - NN) Number of seconds to check auto responses Aurmsg: Y (Y or N) Yes to inform operator auto. response issue Batoprid: BATCH (xxxxxxxx) Default security batch operator id Batsec: N (Y or N) Yes for Zeke to perform batch security Bimappl: (xxxxxxxx) Bimedit application name Bimpasw: (xxxxxx) Bimedit access password Bimuid: OMIT (xxxx) Bimedit access userid Bypjob: N (Y or N) Yes for Zeke to bypass all Power Job cards Calcmem: Y (Y or N) Yes to calculate virtual memory (VSE) Calctap: Y (Y or N) Yes to calculate tape drive usage Chgval: Y (Y or N) Yes to display Variable update message Cmdcons: Y (Y or N) Yes to route cmd response to console Cmsftype: JCL (xxxxxxxx) Default CMS filetype Commctl: Y (Y or N) Yes to retain Work Events until completed Condrdv: SYS000 (xxxxxx) Condor camlib device name Condrlb: OMIT (xxxx) Condor camlib qualifier Condrver: 001 (xxx) Condor version id


376

6 If you want to require a user’s logon ID be defined in the Zeke database as an Zeke operator ID before logon access to the Zeke online is granted, enter Y in the Reqopid field.

• If you want to allow logon access for users who are not defined to Zeke:

• In the Defopid field, enter the new operator ID you created in step 1 and press Enter. Do not leave Defopid=OPERATOR.

• Verify that Reqopid is set to N.

7 If you want to activate internal security for batch processing:

• In the Batoprid field, enter the new operator ID you created in step 2.

• In the Batsec field, enter Y to activate the batch portion of internal security and press Enter. This has no effect on whether a ZEKE15B exit is called. If you are using the ZEKE15B exit, it is called regardless of how this option is set.

• Determine whether you want to cancel a batch job when an unauthorized request is encountered. If you do, then change the generation option Secfail to C. If you do not, ensure that the option is set to I, to ignore the unauthorized request and continue processing with the next input statement to that batch program.

8 If you will be using a ZEKE15B user security exit, in the Secexitw field, enter the number of bytes of storage allocated to call the security exit routine (ZEKE15B). Press Enter.


Setting Up Class IDsA class ID is a way to grant or deny access to specific functions and operator commands for a group of operator IDs.

When Zeke is installed, the default class ID A is defined. Class A allows write access to all functions and operator commands. We recommend that this level be reserved for the Zeke security administrator.

9 Security

377

To maintain class IDs



ASG-Zeke Directory of Command Classes Row 1 to 2 of 2 Command ===> Scroll ===> PAGE Class ID==> Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: B - Browse C - Copy D - Delete E - Edit Class Event Zcom Cal Opt Work Sec Doc Var Res A W W W W W W W W W B W N W W W W W W W ***************************** Bottom of data ******************************


Add a new class ID Enter ADD on the Command line. Enter the new class ID and press Enter. Go to step 3.

Update an existing class ID Enter E to the left of the desired class ID and press Enter. Go to step 3.

Copy a class ID Make the following entries:

• Enter C to the left of the desired class ID and press Enter.

• Enter the new class ID, and press Enter. The message Record Copied is displayed. This procedure is complete.

Delete an existing class ID Make the following entries:

• Enter D to the left of the desired class ID and press Enter.

• Enter DELETE on the Command line to confirm the delete. This procedure is complete.


378

The Class Detail screen is displayed.

3 Each of the major online functions are listed on the screen. To the right of each function, enter the level of access allowed for this class ID. The class ID grants access which can be limited further by user IDs on the operator record.

4 Enter a code to the right of each operator command. As with the online functions, these commands can be limited further by the user ID on the operator record.

5 Press Enter to update the database.

ASG-Zeke Class Detail EDIT Command ===> Class Id: A Primary Commands: ADD BROWSE CANCEL COPY DELETE EDIT Allowed functions Event - W Work Center- W (R=Read only W=Write allowed) Zcom - W Security - W (A=Auto entry in write mode) Calendar - W Document - W (N=Not allowed) Options - W Variable - W Restart - W Schedule control (OPERATOR) commands allowed (Y=Yes, N=No) ZADD - Y ZID - Y ZSET - Y ZALTER - Y ZKILL - Y ZSTATUS - Y ZDELETE - Y ZMAP - Y ZSCAN - Y ZDISABLE - Y ZOK - Y ZRESOURCE DISPLAY - Y ZDISPLAY - Y ZREFRESH - Y ZRESOURCE ALTER - Y ZENABLE - Y ZRELEASE - Y ZRESOURCE RELEASE - Y ZHOLD - Y ZRELOAD - Y ZPLEX - Y

Level Description

W Write and read access; can perform all operations for the specified online functions.

R Read only; can only view functions. Not valid for the work center function.

N No access; cannot access the specified online function.

A Auto entry in Write mode; the first screen of the function is displayed when the operator logs on to Zeke. Only one function can be assigned this code.

Code Meaning

Y Allow this class to execute this command.

N Do not allow this class to execute this command.

9 Security

379

Setting Up Operator IDsZeke allows you to assign an operator ID to each authorized user. Each operator ID is assigned to a class that specifies which functions and commands are valid for the user. Also, access can be restricted further by the user ID, which identifies the event and variable records the user can access.

Zeke operator records control access to records in the Zeke database, such as schedule records, EMRs, work centers, documentation, and variables. Associated with every operator record is the class ID. Class IDs control access to functions, such as the operator commands.

Zeke is installed with the default operator ID of OPERATOR. We recommend that you do not use OPERATOR as a default logon operator ID. See “Setting Internal Security Requirements” on page 372 for additional information.

To maintain operator IDs



ASG-Zeke Directory of Operator IDs Row 1 to 1 of 1Command ===> Scroll ===> PAGE Operator ID: Primary Commands: ADD BROWSE COPY DELETE EDIT Line Commands: E - Edit B - Browse C - Copy D - Delete Operator ID Class Date Date Last Added Updated OPERATOR A 01/16/2007 01/30/2007 L003J A 01/24/2007 02/04/2007 ****************************** Bottom of data *****************************


Add a new operator ID Make the following entries:


• Enter the new operator ID, such as your TSO logon ID, in the Operator ID field and press Enter. Go to step 3.

Update an existing operator ID Enter E to the left of the desired operator ID and press Enter. Go to step 3.


380

The Operator Detail screen is displayed.

3 Enter the class ID in the Class ID field.

Note:The default class when the database is created is A, which gives access to all Zeke functions and operator commands. You should reserve this class for the security administrator of Zeke. See “Setting Up Class IDs” on page 376 for information on defining class IDs.

4 In the Userid field, enter a user ID to either limit or grant access to an online function. You can enter a specific or a generic user ID. For example, enter PAY***** to control access to all events with a user ID beginning with PAY.

Zeke supports mixed-case security user IDs. Use the ISPF command CAPS to toggle between mixed-case and upper case modes. The current mode is displayed in the upper right-hand portion of the screen.

Copy an operator ID Make the following entries:

• Enter C to the left of the desired operator ID and press Enter.

• Enter the new operator ID, such as your TSO logon ID, in the Operator Id field and press Enter. This procedure is complete.

Delete an existing operator ID Make the following entries:

• Enter D to the left of the desired operator ID and press Enter.

• Enter DELETE on the Command line to confirm the delete. This procedure is complete.

ASG-Zeke Operator Detail EDIT Command ===> Scroll ===> PAGE CAPS ===> ON Primary Commands: ADD BROWSE COPY DELETE EDIT Operator ID: OPERATOR Class ID: A Enter below the Event User IDs or User ID mask, and for each User ID, enter: R - READ MODE W - WRITE MODE OR N - NOT ALLOWED UserID Zcom Event Work Documentation Variable ******** W W W W W


9 Security

381

The authorized user IDs are checked in columnar sequence. Therefore, it is possible to allow access to user ID BILL0501, but prohibit access to any other BILL**** user ID. Enter the BILL0501 user ID first in the list, allowing access. Then list the BILL**** user ID further down the list prohibiting access.

Zeke also supports blank user IDs (user IDs composed of all spaces) for operator records, and allows user ID masks containing leading spaces, embedded spaces, trailing spaces, or all spaces.

Note:When creating variables with a blank user ID, the blank user ID must be set up to have write security access to variables and work centers.

5 Enter a code in the space below each online function indicating the type of security access. If you do not specify an access level, it defaults to R.

6 Press Enter to update the database.

Code Meaning

W Grant Write access to the function.

R (Default.) Grant Read (only) access to the function. Not valid for the “Work” (work center) function.

N Disallow access to the function.


382

Zeke External SecurityZeke external security provides added benefit over internal security by providing the ability to secure at a more detailed level, more comprehensive security, and more flexibility in establishing access criteria.

Zeke uses the External Security Facility (ESI) to pass security information to the SAF security interface. This allows you to use a third-party security product, such as RACF or CA-ACF2, to control access to resources for specific Zeke functions. Therefore, you must have previously installed and be familiar with an external security package before using this option. Also, it is a good idea to be familiar with Zeke internal security because you can use a combination of internal and external security for your installation. See “Security Processing” on page 364 for an overview of Zeke security.

Zeke 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 that are used to access those structures. However, a few of the external security classes are function-oriented because in certain situations, securing a process is more appropriate than securing the structure. This allows you the flexibility to set up the most effective security for your particular situation.

For example, access to schedule records can be controlled by function—limiting access to the ZCOM online screen and the Zeke operator commands, or by object—the schedule records themselves. Each of these items is controlled by a security class. Because the protection provided by many of these classes overlaps, you probably will not need to activate all of the classes to obtain 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 one of the following methods:

• The online system (Variable menu option)

• A Zeke command (ZSET VAR $TEST EQ YES)

• The ZEKESET program (SET VAR $TEST)

• Completion of a work center

9 Security

383

The following describes different ways to secure access to variables:

• Secure access to the variable records by using Z$VAR class. This allows you to secure access to any attempt made through the online system, a Zeke command, the ZEKESET program, or by completion of a work center.

• Secure access to the online menu options by using the Z$ONLINE class. This allows you to restrict who can access the ZCOM, variable, and work center options.

• Secure access to the ZEKESET program by using the Z$SET class. This allows you to restrict who can issue the special commands available in ZEKESET.

• Secure access to the Zeke commands by using the Z$CMD class. This allows you to restrict who can issue certain commands.

Security ClassesIn external security, classes are used to identify each resource type. For example, the internal class name for EMRs is Z$EMR. The internal class name is used for all references to that resource type in ESI documentation, messages, and commands. See “Security Calls” on page 365 for an explanation of the different authority levels for classes. The following is a list of all the security classes provided with Zeke, including a description and the authority classes.

Z$ACCESS Secures use of generic selection criteria (for application ID, group ID, system ID, or user ID) or the CLEAR keyword with the SCHEDULE function.

Resource name=SCHEDULE.GENERICS/SCHEDULE.CLEAR

Levels: If the ACTIVATE parameter is specified, ALTER authority is required. Otherwise, READ authority is required.

Z$CATAL Secures access to the database as a single unit. Resource name=CREATE/BACKUP/RESTORE/STATUS/BLOCK.

Levels: READ enables Status and Backup functions; ALTER enables Create, Restore, and Block functions.

Z$CLASS Secures access to Zeke class records that are used in internal security. Default resource name format=(Zeke catalog-id).

Levels: READ/UPDATE/ALTER

Z$CMD Secures access to Zeke operator commands. Default resource name format=(command verb).

Levels: READ

Z$CND Secures access to calendar records. Default resource name format=(calendar-name).



384

Z$ECDR Secures access to the ESI class definition records. Default resource name format=(Zeke catalog-id).


Z$DOWNLD Secures access to the schedule download agents list. Default resource name format=(Zeke catalog-id).


Z$EMR Secures access to the EMRs. Default resource name format=(userid.record-type).


Z$GOPT Secures access to the generation option records. Default resource name format=(Zeke catalog-id).


Z$NAME Secures access to the customer name records. Default resource name format=(Zeke catalog-id).


Z$ONLINE Secures access to the Zeke online functions. Default resource name format=(online menu option name). Typically, this option is not necessary if all of the desired records have been secured.

Levels: READ enables Read mode for that section of the online; UPDATE enables Write mode. Options to which you do not have access are not displayed on the Zeke Primary Menu.

Z$OPER Secures access to operator records used in internal security. Default resource name format=(Zeke catalog-id).


Z$PASS Secures access to the operating passwords. Default resource name format=(Zeke catalog-id).


Z$PINT Secures access to the partition/initiator records. Default resource name format=(Zeke catalog-id).


Z$POOL Secures access to the pool definition records. Default resource name format=(Zeke catalog-id).


9 Security

385

Z$RESRC Secures access to the resource definition records. Default resource name format=(Zeke catalog-id).


Z$SCHED Secures access to the SCHEDULE function. Default resource name format=(userid). The parameters provided by the user are used to build the resource name for one SAF call. Object-oriented security is not applied to this function because a security call would be required for each attempt to access a record. Since the SCHEDULE function involves reading every EMR in the Zeke database, calendars, and variables, and then creating schedule records, thousands of security calls could result, with a substantial impact on performance.

Levels: If the ACTIVATE parameter is specified, ALTER authority is required. Otherwise, READ authority is required.

Z$SET Secures access to the ZEKESET functions. Default resource name format=(command verb).

Levels: READ

Z$SIM Not valid at this time. In a future release, this class will secure access to the simulation function. Default resource name format=(userid).

Levels: n/a

Z$SQR Secures access to the schedule records. Default resource name format=(userid).


Z$VAR Secures access to variables. Default resource name format=(userid).


Z$XCOM Secures access to individual commands within an SCOM event. Default resource name format=(command code).

Levels: CONTROL


386

Resource NamesEach class has a resource name format that contains the information that is used to make the security decisions. The resource name can be broken down into elements. When the resource name is built for the SAF call, the value of the element is inserted into the resource name.

The eligible elements for each class are listed on the X1FOFSEL—ESI Customization screen. There are several types of elements:

The most common elements are described below:

Fields Most elements that are eligible to 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 list of elements includes EVENTNAME, APP, and GROUP.

Structures Some elements are structures that are associated with the Zeke database, such as the catalog ID and the system you are running under.

Constants These elements get their values from a set of constants applicable to that element. For example, the source of the request. If a command is entered from the console, the source is CONSOLE. Likewise, if a command is entered through the ZCOM function, the source is ONLINE.

User-defined User-defined constants and delimiter characters are also eligible elements.

Catalog ID The 8-byte unique catalog identifier, determined when the catalog 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 catalog is restored from a backup dataset.

Command The command verb issued. For example,

Z$CMD Class—ZID, ZDISPLAY, ZALTER, etc.

Z$SET Class—SET, CDATE, etc.

Command Code The type of command issued from an SCOM event.

C System command

R System response (VSE only)

Z Zeke command

V VM command

P VSE/POWER command

9 Security

387

Implementing External SecurityASG recommends fully implementing external security for a single internal class before implementing ESI for other classes. This allows you to go through the complete implementation process, including testing, for a small area of the system before performing a large-scale implementation.

ASG also recommends that you activate all classes initially, except for the Z$ONLINE class. After some use and testing, you may want to deactivate or combine some classes into the same external class name, or to activate the Z$ONLINE class.

All of the Zeke ESI classes provide the flexibility of changing the external class name, the process option, and the resource name format—except for the Z$CATAL class. The default external class name for all classes is the same as the internal class name, and the default process option for all classes is N4 (except for the Z$CATAL class).

The Z$CATAL class is unique in that the external class name, the process option, and the resource name format cannot be changed. Because this class incorporates functions such as a database RESTORE and CREATE, the SAF call is fixed to ensure that the database as a resource is secure under all conditions.

Before making any changes to the external security screens, please read the ESI chapter of your ASG-OASIS for z/OS Reference Guide, particularly the section about setting up ESI.

To modify ESI class definition records


Command Text The full text of an entered command.

Function The name of the online function to which access is being requested.

Record Type The sub-record type to which access is requested. for example, an EMR has several types of subordinate records like JCL and DOC

Source The source of the request that caused the security call to be made. For example, if a command is entered from the console, the value of the source field is “CONSOLE”.

Subsystem Name The OASIS subsystem that this Zeke system is running under. Multiple subsystems allow the user to run more than one system on the same operating system. Its value is shown on the third line of the response to the ZID command.


388

On the ESI Customization—X1SELECT screen, each line represents an ESI class definition record that is uniquely defined by the system ID and the internal class name.

2 Perform the following actions, depending on the desired result:

ESI Customization BROWSECOMMAND ===> SCROLL ===> PAGE X1SELECT Primary Commands: DOWN UP EDIT BROWSE END RETURN Line Commands: F - Resource name format C - Copy to discrete ECDR D - Delete discrete ECDR "Copy to" Internal External Process System System Class Class Option ******** Z$CATAL Z$CATAL Y4 ******** Z$CLASS Z$CLASS N4 ******** Z$CMD Z$CMD N4 ******** Z$CND Z$CND N4 ******** Z$ECDR Z$ECDR N4 ******** Z$EMR Z$EMR N4 ******** Z$GOPT Z$GOPT N4 ******** Z$NAME Z$NAME N4 ******** Z$ONLINE Z$ONLINE N4 ******** Z$OPER Z$OPER N4 ******** Z$PASS Z$PASS N4 ******** Z$PINT Z$PINT N4 ******** Z$POOL Z$POOL N4 ******** Z$RESRC Z$RESRC N4


Change the external class name Make the following entries:

• Enter EDIT on the Command line and press Enter.

• Enter the new class name in the External Class field of the class to change.

• Press Enter. Go to step 6.

Copy a record with all of its attributes to another system

• Enter C to the left of the record to copy.

• Enter the new system ID in the “Copy to” System field.


Delete a record with all of its attributes

Enter D to the left of the record to delete and press Enter. Go to step 6.

Note:The generic (********) records cannot be deleted.

9 Security

389

Change the process option Note:If changes are made to the external class name or the resource name format, leave the process option set to N4 until you have tested the implementation.



• Enter the process option in the Process Option field.

Process Option

Description

N0 Do not call SAF. Grant all access requests.

N4 Do not call SAF. Use internal security to determine whether to grant the access request.

N8 Do not call SAF. Deny all access requests.

Y0 Call SAF. If the SAF return code is 4, grant the access request.

Y4 Call SAF. If the SAF return code is 4, use internal security to determine whether to grant the access request. If there is no internal security, access is allowed.

Y8 Call SAF. If the SAF return code is 4, deny the access request.

• Press Enter to update the record. Go to step 6.

Change the resource name format

Enter F to the left of the class name that you are changing and press Enter. Go to step 3.



390

The ESI Customization—X1FRMAT1 screen is displayed with the current list of elements for the specified resource name format.

3 Perform the steps in the Action column, depending on the desired result

********.Z$EMR/Z$EMR ESI Customization BROWSE COMMAND ===> SCROLL ===> PAGE X1FRMAT1 Primary Commands: DOWN UP EDIT BROWSE RESET END RETURN CANCEL Line Commands: A - Insert element after B - Insert element before D - Delete element --+---1----+----2----+----3----+----4----+----5----+----6----+----7---+--8aaaaaaaa.bbbbbbbb Start Length Field Description 3 elements a 001 008 User ID . 001 001 Delimiter character b 001 008 Record type **END**


Add an element Make the following entries:


• Enter the code to the left of an element to position the new element.

Code Meaning

A Add the new element after the selected element.

B Add the new element before the selected element.


Change a portion of an element to be included in the resource name format



• Enter the beginning position in the Start field.

• Enter the length in the Length field. For example, if the element value is ABCDEDFG (start position of 1 and length of 8), and you want to select CDE as the new value. Enter 3 in the Start field and 3 in the Length field. Go to step 6.

Restore the resource name format to the default

If you have saved changes to the format and wish to cancel them, enter RESET on the Command line and press Enter.

9 Security

391

The ESI Customization X1FOFSEL screen is displayed with a list of eligible elements (fields) for this class.

4 To add the element to the resource name format, enter C to the left of the desired element and press Enter.

5 After all the desired elements are included in the resource name format, press F3.

6 For each class that you updated, use the OASIS operator command RELOAD to replace the in-storage ESI class definition record. With the RELOAD command, enter the internal class name for which the in-storage ESI class definition record is to be replaced. For example, RELOAD ECDR Z$CMD reloads the Zeke operator commands.

Exit screen without saving changes made to the format

If you have made changes to the format that you do not wish to keep and have not saved them, enter CANCEL on the Command line and press Enter.

Delete an existing element



• Position the cursor to the left of the element you wish to delete.

• Enter D and press Enter. Go to step 6.

********.Z$EMR/Z$EMR ESI Customization EDIT COMMAND ===> SCROLL ===> PAGE X1FOFSEL Primary Commands: DOWN UP END RETURN Line Commands: C - Copy field Length Field Description 001 Delimiter character 1-8 Literal value ===> __________ (quoted) 008 User ID 008 Application ID 003 Group ID 012 Event name 008 Job name 008 System name 004 Event type 008 Record type 008 Target 008 Platform 007 Source 002 Disaster recovery level 008 Zeke internal catalog ID 004 Subsystem name



392

To activate the External Security Interface


2 Enter E to the left of the system you want to change and press Enter.

Note:*********' is the generic system; if generation options are not set for a system, it defaults to the generic system values.

3 The Generation Options screen is displayed with the options in alphabetical order. Use the F8 or F7 keys to scroll.

4 Page to the ESI Actv generation option and enter Y to activate the External Security Interface.


ASG-Zeke Generation Options BROWSE Command ===> Scroll ===> PAGE Zeke System: ******** Defopid: OPERATOR (xxxxxxxx) Default online operator ID Defpltfm: MVS (xxxxxxxx) Default Jobevent EMR Platform value DefSysId ZEQA (xxxxxxxx) Default System Id for Event add Dispdly: 030 (xxxxx) Seconds to delay dispatching pooled events Dispmsg: Y (Y or N) Yes to issue dispatch message Dispsel: N (Y or N) Yes for Zeke to select initiators (MVS) (yes is ignored for JES3) Dsntrig: TA (xx) TA=Trigger All Dates NT=If Multi-Dates exist, Place on HOLD, else Trigger Date OD=Trigger Oldest Date ND=Trigger Newest Date DSPIndex: Y (Y or N) Yes to create an index dataspace DSPSched: Y (Y or N) Yes to use a dataspace for Schedule load Dynsmf: Y (Y or N) Yes to dynamically install SMF exit EDBindex: N (Y or N) Yes to build EDB in-core index Eojwake: Y (Y or N) Yes for Zeke to wake up at EOJ ESI Actv: Y (Y or N) Yes to activate Ext Sec Interface (SAF) Fairmod: 023000 (xxxxxx) Fairmod option code

9 Security

393

5 For the Defopid generation option, enter the default Zeke operator ID to be assigned when an undefined operator logs on. The default is OPERATOR.

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 allows for the possibility to revert to internal security under certain circumstances. In such a case, the default operator ID is required. This operator ID must be supplied to Zeke during log-on. If you plan to use ESI exclusively, it is not important what level of authority is assigned the default operator ID. If you intend to use internal security with external security, set it to the default level of authority.

6 Set the Batoprid generation option to the default operator ID to use for security verification of batch functions. The default is BATCH. Batoprid is the batch equivalent of Defopid (described in step 5). Verify that there is an operator ID record defined for this ID.

7 Determine whether you want to cancel a batch job when an unauthorized request is encountered.

• If you do, ensure that Secfail is set to C.

• If you do not, ensure that Secfail is set to I, to ignore the unauthorized request and continue processing with the next input statement to that batch program.

8 Determine whether you want to display primary records if security access is denied.

• If you do, ensure that Sechide1 is set to N.

• If you do not, ensure that Sechide1 is set to Y. Any Zeke online screen that displays a directory of records will only display those records the user has at least Read access to.

9 Determine whether you want to display subordinate records if security access is denied to a user.

• If you do, ensure that Sechide2 is set to N.

• If you do not, ensure that Sechide2 is set to Y. Any Zeke online screen that displays a directory of records will only display those subordinate records the user has at least Read access to. For example, the * (asterisk) displayed in the DOC column on the Event Master Directory screen indicates a subordinate record of the EMR exists.


11 If you have not defined the external class name, go to the procedure “To modify ESI class definition records” on page 387.

12 You are ready to test the implementation. For information on testing ESI with ESITRACE, refer to your ASG-OASIS for z/OS Reference Guide.


394

395

Index

Symbols* (asterisk) used with

generic names for dependencies 138, 143

job types 84special calendars 69

Aadding events by path 79, 255ALTER, Schedule View command 213Audit Log Facility

defining/updating the audit log 319displaying the audit log 319logging

in the Audit Log database 318job’s status changes 318Zeke operator commands 318

tracking Zeke database activity 318updating audit actions 318

Auto access 378auto replies

disabling 175displaying 175enabling 175managing Zack Fastpath/Autoreply

tables from Zeke 61responding to outstanding replies 39,

171setting generation options 39, 171–

172using the AUTORPLY function 172

Automation option, managing Zack Fastpath/Autoreply tables from Zeke 61

Bbacking up the database 323

using a dataspace 45, 323

Ccalculating tape drive usage 305calendars

accessing online 65adding a calendar 66deleting a calendar 66description of 3special calendars 69

standard calendars 67summary of types 7user accounting calendars 70

overview of user accounting periods 71

CAPS mode 380class IDs 369, 376CLIST commands 242

creating your own 242colors, changing ISPF screen 316commands

CLIST 242command events 107in SCOM events 359ISPF 57–58, 78, 180, 185, 233, 346

creating your own 242JCL 230–231operator 92, 95, 97, 105–108, 111,

114, 165, 171, 175, 202, 243–244, 318, 351, 362auto reply 171securing 370security 369

POWER 107REXX 242Schedule View 202, 211–217securing 363system 107VM 107ZADD, for Schedule View 250, 252Zeke start-up 54ZEKESET 371ZKILL 56

communication, inter-productcontrolling 309

completing work centers 166–168condition codes 3, 154–157controlling jobstream flow using

variables 353conventions page xiCREATE batch utility

setting up Z$CATAL class 367creating

CLIST or REXX commands 242Zeke database 320

cross-platform dependencies 144cycling Zeke 284


396

Ddatabase

backing up the database 323backup using a dataspace 45, 323creating

Zeke database 320Zeke started task 326

job information contained in 17moving the vault database 326recovery, Zeke started task 329retrieving JCL 179shared 311

dataset triggering 145hold code 206

dataspacebuilding a full EDB index 312creating the schedule using a 46database backups using a 45, 323events listing using a 47for schedule loads 45running simulation against a 201start-up parameter 39use in report generation 47

date format, Schedule View 224DaySpan, description of logical days 4defining

permanent events 115recurring events 115

dependenciescross-platform scheduling 144dataset triggering 145defining 150description of 5EOG (end of group) 146, 148extended dependencies 136, 149generic event names 138grouping multiple phrases 139length of 225maintaining

from Schedule View 225from the EMR (all

versions) 151multiple 139, 141multiple job versions 135Not Active 142

see also logical resourcesprocessing of 135referencing started tasks 138satisfied 17, 135using variables 140viewing

from Schedule View 225from the EMR (all

versions) 151WEAK conditions 137

dispatch queue, checking 306dispatching

description of 17jobs after Zeke start-up 312list of prerequisites 10messages and jobs 288see also dependencies

displaying fields in Schedule View 222documentation

calendarsnote pad 73scratch pad 73text 74

events 181jobs

datasets 186note pad 184scratch pad 184summary of types 8text 185

segments, definition 3variables

note pad 344scratch pad 344text 346

downloaded schedules 197downloading, setting up a job for 102–103DSPIndex generation option 312

EECDRs, modifying 387EDB indexes, building 312electronic vaulting

considerations for using 328database allocation 328description of 4features 15full recovery procedure 328partial recovery procedure 329

ESI, see security, external securityevent

activating an event 80adding events to the schedule

manually 250command events 107copying an event 90

from a template 88creating from a template 88deactivating an event 78job events 92

routing to another system or platform for execution 98

permanent 8, 114–117recurring 8, 114–117resources, accessing 229

Index

397

routing a job event to another system or platform 98

status codes, in Schedule View 205status, displaying 227templates

creating events from a template 88

defining a template 86work centers 161

exporting database records 28extended dependencies, see under

dependenciesexternal security

see security

FFastpath, managing Zack Fastpath/Autoreply

tables from Zeke 61forecasting the schedule 5

Ggeneration options

accessing 286activating 284cycling Zeke 284dataspace 45AUR 303AURINTV 303AURMSG 303Batoprid 376, 393Batsec 376Calctap 305COMMCTL 291DEFDPRTY 288Defopid 376, 393DISPDLY 288DISPMSG 288DISPSEL 305DSPIndex 79, 312EDBindex 312Eojwake 306IEFU83 293Igncat2 290JOBRST 306Loadcomm 304MSGWAIT 288MSPINTRL 288MULTAP 297MULTEN 297MULTGR 297Multhit 297Multjn 297Multsys 295, 311

MULTUS 297Netregid 98, 102, 307Nonwkday 297OPEROK 214, 288Oprhold 312Pendinv 300Pendmsg 300Posid 98, 102, 307POSIDEND 45, 307PRILATE 288Reqopid 376RETAIN 291RETDAYS 291RETDONE 291RETPEND 291Secexitw 376Secfail 376, 393Sechide1 393Sechide2 393Subdata 288TRIGDT 293TRIGJOB 294TRIGRRN 294WKTRGDN 294

Hhelp, accessing Zeke ISPF online 57holding an event 252, 256

IIF clauses within SET statements 359importing database records 28initializing the database 320initiators

addinga system 269specifications 269

copying an initiator record 270defining initiators 269deleting

a single initiator 270all initiators for a system 270

editing an existing initiator 269selecting, according to class 266system availability 271

installation, setting up Z$CATAL class before running CREATE 367

interfaces, Zebb restart management 215internal security

see securityinter-product communication,

controlling 309


398

ISPF online facilityaccessing a subsystem 60changing colors on screens 316commands 57–58, 78, 180, 185, 233,

346creating your own 242

common fields 58features 57logging on 59screen format 58Zeke primary menu 60–61see also under online

JJCL

displaying actual execution JCL 215JCLR, Schedule View line

command 214line commands 230–231override 234performing one-time overrides for job

events 232retrieving JCL from the Zeke

database 179specifying JCL source libraries

PDS 176substituting variable values 356syntax checking 241

with JCLPREP 237–238with JOB/SCAN 239–240

using variablesto control jobstream flow 353to restart a job 354to trigger jobs 352

validationusing ZSCAN 241with JCLPREP 237with JOB/SCAN 239

JCLPREP, invoking from Schedule View 237–238

jobactivating pending messages and

jobs 300adding jobs to the schedule 254, 258checking the dispatch queue 306creating and adding to the schedule at

the same time 197defining 75definition 4dispatching

jobs after Zeke start-up 312messages and jobs 288

EMRaccessing 82definition of 4

event 92setting up for

downloading 102–103log, displaying 215MSG jobs 104NOT-CAT2 messages,

recognizing 290PCOM jobs 107pending 300predecessors, viewing

in Schedule View 214on the EMR 79–80

refreshing jobs 215restart facility 306retaining jobs 291scheduled job, changing via Schedule

View 213scheduling jobs 297SCOM jobs 107–108successors, viewing

in Schedule View 214on the EMR 79on the master 81

templatesdefining 86overview 7

types of jobs Zeke processes 3VCOM jobs 107versions, dependencies for 135ZCOM jobs 107

JOB/SCAN, invoking from Schedule View 239–240

JPREP line command 238JSCAN line command 24, 240

Lline commands

see commandslisting events using a 47loading the work center to SQT 304Logical Day 4

scheduling examples 18, 96, 192logical resources

copying a resource 276defining a resource to Zeke 275defining resources for an event 277deleting a resource 276deleting resources for an event 281description of 4, 262editing an existing resource 275maintaining 274

logonIDs, maintaining 369ISPF online 59

Index

399

Mmenus

Zeke Primary Menu 60–61messages

dispatching 288display system 215pending 300

MSG job 104multiple

OASIS support 20system support 6Zekes 18

NNETREGID 145, 307Network Hold status 206networking options, maintaining 307NOT-CAT2 messages, recognizing 290NOTDURING processing

reason code 207using logical resources 274WHEN conditions 142, 146, 215

OOASIS

multiple OASIS support 20started task 54

starting the 320starting

multiple tasks 54without Zeke 52

terminating 55variables

accessing 57in SET clauses 162naming 348overriding variable values

temporarily 350overview 347setting with XVAR and

?XVAR 162temporary variables 350

OCCURS clausesdefining 132description of 4grouping multiple phrases 119list of keywords 118multiple phrases 118processing 118sample clauses 126scheduling for holidays and

weekends 130using parentheses in 119

onlinesee also ISPF online facility

operator commands 92, 95, 97, 105–108, 111, 114, 165, 171, 175, 202, 243–244, 318, 351, 362auto reply 171securing 369–370ZKILL 51

operator hold on an event 252, 256operator IDs

maintaining 369, 379mixed case 380

OpsCentral 22OVAR 57overriding JCL 214, 234

PPATH

master primary command 79Schedule View line command 214

PathFinderadding events by path 79, 255description of 4displaying

different levels in the hierarchy 246

non-Zeke jobs in a path 246PCOM job 107PDS JCL support 176PDS override, Zeke started task option 234pending messages and jobs 300permanent events 8, 114–117

defining 115physical resources

defining initiators to Zeke 269defining pools 272

Poly-Zeke 14, 18pools

addinga pool 272a system ID 273

definition of 5deleting

a single pool 273all pools for a system 273

editingan existing pool 272an existing system 273

POSID 307POSIDEND 45, 307POWER commands 107predecessors, viewing

in Schedule View 214on the EMR 79–80


400

prerequisites, see dependenciesprimary commands

see commandsprimary database

versus secondary database 328see also under database

primary menu, Zeke 60–61

Rrandom scheduling dates, creating calendar

for 69Read access 378, 381reason codes in Schedule View 205recovery, see disaster recovery level,

electronic vaultingrecurring events 8, 114–117

defining 115refreshing jobs 215refreshing Schedule View 219remote dependencies 144rerunning a scheduled job 253, 257resources

checking before dispatch 10see also logical resources, physical

resourcesrestarting

jobs using variables 354Zeke 51

restoring the database 324RESTORE batch utility

setting up Z$CATAL class 367restricting

number of jobs selected 253system availability

initiators 271retaining jobs 291retrieving

JCL for updating 214JCL from the Zeke database 179

return codessee also condition codes

REXX commands 242creating your own 242

RSTRT, interface to Zebb 215RUN, Schedule View line command 215

SSAF security 22schedule

adding a newly created job to the schedule 197

adding events by path 255creation using a dataspace 46

event scheduling 250forecasting 5job scheduling 254, 258, 297number 197record, rerunning 253, 257SCHED ID, see OCCURS clausesSCHEDADD parameter 197SCHEDULE batch utility

function of 17running the schedule

automatically 196scheduled job

definition of 4displaying 202recreating 253, 256status, changing 252, 256

scheduling criteria, see OCCURS clauses

simulation 5, 199schedule download 197

displaying agents 22, 102setting up a job for downloading 102–

103schedule queue record, definition of 4Schedule View

accessingevent master record

information 217online documentation 217other online information 217PathFinder 217resources for an event 229work center information 217

adding events to the schedule 250, 254, 258

ALTER line command 213changing

amount of storage for an event 208

class or class list for an event 208

dispatch priority 208number of tape drives 208number of times an event is

dispatched 208schedule time 208scheduled job status 252, 256sort sequence 220system or pools 208way JCL is submitted and

executed 209commands 211–216

Index

401

creatingCLIST or REXX

commands 242schedule 194

date format 224description of 4display fields 222displaying

event status 227schedule queue record

information 230scheduled jobs 202status of events 227

invoking JCLPREP 237–238invoking JOB/SCAN 239–240line commands 202, 208, 213, 217

SYSJ, SYSL, and SYSM 216, 241

maintaining dependencies 225maintaining JCL 232placing an operator hold on an

event 252, 256primary commands 211recreating the scheduled job 253, 256refreshing the screen 219repeating the last command

entered 209rerunning a scheduled job 253, 257restricting the number of jobs

selected 253setting display characteristics 202sort sequence, changing 221validating JCL 241ZADD command 252ZCOM option, entering operator

commands 243ZOOM line command 230, 237, 239

SCOM jobs 107–108variable substitution within SCOM

jobs 359SECEXITW - specifies work area size 376SECHIDE1, displaying primary records 393SECHIDE2, displaying subordinate

records 393secondary database

versus primary database 328see also under database

securityauthority levels 365building a Zeke security team 362calls to ZEKE15A 365

sources of 366commands 363

exitBATOPRID 376BATSEC=YES 376SECEXITW option 376SECFAIL - what to do if

security fails 376, 393ZEKE15B 368, 376

external securityactivating ESI 392advantages over internal

security 364cancelling unauthorized batch

job(s) 393changing the external class

name 388changing the process option,

internal class 389copying an ECDR 388deleting an ECDR 388description of 5displaying primary records 393displaying subordinate

records 393elements 386hard-coded calls 367main focus 382modifying ECDRs 387protection provided by 363replacing the ESI class

definition record, internal class 391

resource name format 386, 389–391

security class 382–383implementing 362internal security

activating security for batch processing 376

allocating work area size 376cancelling unauthorized batch

jobs 376changing security

requirements 372class IDs, maintaining 369, 376defining logon ID to Zeke

database 376description of 5IDs used 369logon IDs, maintaining 369not restricting logon access 376online logon access 370operator IDs, maintaining 369,

379protection provided by 363


402

record types used 369user IDs, maintaining 369using Zeke security 361

operator commands 369–370processing 364

logic 367securing by function 363securing by object 363tracing processing 368

SET clause 162IF clause within 359

simulationrunning against a dataspace 201schedule 5, 14, 199

SMFPRMxx 138SMP/E install 6sorting Schedule View 220SQR, definition of 4started task

OASIS 54starting 320

Zeke 51, 53–54database creation 326database recovery 329including the Zebb load

library 309PDS override option 37, 234start-up parameters 39terminating 56

starting multiple tasksOASIS started task 54Zeke batch utility 53Zeke started task 53–54

start-upcommands 54parameters, dataspace 39

status, event status in Schedule View 205STOP command 56subsystem 18

accessing ISPF online using 60successors, viewing

in Schedule View 214on the EMR 79on the master 81

SYS1.PARMLIBSMFPRMxx 138

SYSJ, SYSL, and SYSM line commands 216, 241

systemcommands 107maintaining 286networking options 307operating criteria, changing 284system-dependent variables 351

Ttape drives, calculating usage 305tasks, Zeke started tasks 54templates

creating an event from a template 88defining 86overview 7

temporary OASIS variables 350terminating

OASIS 55the Zeke started task 56Zeke 56

using STOP 56using ZKILL 56

triggering events, hold code 206tutorial, accessing Zeke ISPF online 57TVSET function (temporary variable

set) 350

Uuser ID

maintaining 369mixed case 380

Vvalidating JCL 236VAR and ?VAR keywords 162variables

as an event prerequisite 140, 351controlling jobstream flow using

variables 353deleting a variable 341description of Zeke variables 5in dependencies 352naming variables 338OASIS, see under OASIS variablesoverriding variable values

temporarily 350restarting a job using variables 354setting values 169setting with VAR and ?VAR 162substitution

activating variable substitution 288

activating/deactivating 358in JCL 356within SCOM jobs 359

summary of features 11system-dependent variables 351temporary OASIS variables 350triggering jobs using variables 352

vault database, moving 326vaulting, see electronic vaulting

Index

403

VCOM job 107versions, description of 5VM commands 107

Wwait reasons, displaying 227WEAK conditions 137WHEN conditions

see dependencieswork centers 161

adding or updating a variable value 169

completing 166–168confirming variable values 170description of 5disabling an event 168displaying variables for an event 168enabling a disabled event 168loading the work center to SQT 304refreshing an event 168SET clause 162setting up work centers 163

Write access 378, 381

XXEOJ/XEOE keywords 136, 149XVAR and ?XVAR keywords 162

ZZack, managing Fastpath/Autoreply tables

from Zeke 61ZADD command 250, 252ZCOM job 107ZCOM option 250

entering operator commands 243Zebb

load library in the Zeke started task 309

restart management interface 215Zeke

cycling 284OpsCentral setup 22PDS JCL override 234restarting 51starting multiple tasks 54start-up commands 54terminating 56

using STOP 56using ZKILL 56

Zeke started task 53database creation 326database recovery 329including the Zebb load library 309

PDS override option 234terminating 56

ZEKE15A 365ZEKECAT 320ZEKENEW 320ZEKESET commands 371ZEKEXUTL (import/export utility) 28ZKILL

ZKILL COLD command 56ZKILL TRACK command 56ZKILL WARM command 56

ZOOM, Schedule View line commandusing to invoke JCLPREP 237using to invoke JOB/SCAN 239


404

CD Contents

ASG Worldwide Headquarters Naples Florida USA | asg.com

zeke

Documents

asgzeke plugins

terminating zeke

asg products

zeke database

zeke interfaces

restarting zeke

zeke works schedule

enhancements version