ZEKE Reference Manual

PL/ I

IMS DB2

JCL

SPF

ZEKE

FW B

SAS

Application Delivery Support Last Revised: March 2000

ZEKE Reference Manual

2

Table of Contents

Table of Contents.........................................................................................................................................................2 Preface ..........................................................................................................................................................................4

Who to Contact for Support ......................................................................................................................................4 Related Information...................................................................................................................................................4

ZEKE Event Master Records.....................................................................................................................................5 EMR Control Fields ..................................................................................................................................................5

Online EMR Fields..............................................................................................................................................11 Occurs Clauses...........................................................................................................................................................12

Multiple OCCURS Clause Phrases .........................................................................................................................12 Grouping Multiple OCCURS Clauses Phrases........................................................................................................12

Some Simple OCCURS Clauses..........................................................................................................................13 Scheduling Events on Holidays and Weekends...................................................................................................13 Sample Occurs Clauses .......................................................................................................................................14 ZEKE and Statutory Holidays .............................................................................................................................16

WHEN Conditions.....................................................................................................................................................17 WHEN Conditions for Multiple Event Versions.....................................................................................................17 WEAK Conditions...................................................................................................................................................17

Generic Names ....................................................................................................................................................18 EOG WHEN Condition.......................................................................................................................................18 Multiple WHEN Condition .................................................................................................................................19 Grouping Multiple WHEN Conditions................................................................................................................19 ZEKE Variables in WHEN Conditions ...............................................................................................................19 Extended Dependencies.......................................................................................................................................19 Remote Prerequisites ...........................................................................................................................................20 Sample WHEN Clauses.......................................................................................................................................21

Job Execution and ZEKE .........................................................................................................................................23 JCL and PJSUB .......................................................................................................................................................23 ZEKESET................................................................................................................................................................23

Abend Notification ..............................................................................................................................................23 NOTIFY Parameter .............................................................................................................................................24 Assigning Values to ZEKE Variables .................................................................................................................24 Setting Condition Codes......................................................................................................................................24

Security Access...........................................................................................................................................................25 ACF2 Security .........................................................................................................................................................25 ZEKE Online Security.............................................................................................................................................25

Clustering Jobs and Checkpoints.............................................................................................................................26 Scheduling One Job from Another Job....................................................................................................................26 Scheduling Jobs between PROD and DEV .............................................................................................................27 Scheduling Jobs between PROD and an AS/400 or NT Server ..............................................................................29

Interacting with ZEKE .............................................................................................................................................30 ZEKE OnlineDirect Inquiry ..................................................................................................................................30

Event Master Records..........................................................................................................................................30 Display an Event by Event Number ....................................................................................................................30 When will my Job be Scheduled?........................................................................................................................31


3

Schedule Records ................................................................................................................................................33 Schedule View.....................................................................................................................................................34 Schedule View Primary Commands ....................................................................................................................35 Schedule View Line Commands .........................................................................................................................35 When Would You Use These Commands? .........................................................................................................36 Online Event Status Codes ..................................................................................................................................37

Customized Schedule View Settings .......................................................................................................................38 Columns Displayed..............................................................................................................................................38 Sort Default .........................................................................................................................................................39

ZEKE Variables.......................................................................................................................................................39 Displaying a Specific Variable ............................................................................................................................39 Displaying Several Variable Records..................................................................................................................39

ZEKE Updates in Batch............................................................................................................................................41 Creating ZEKE Event Master Records....................................................................................................................41

Updating ZEKE Event Master Records...............................................................................................................43 #ZE / ZER Edit Macros .......................................................................................................................................43 Deactivate an EMR..............................................................................................................................................43 Reactivate an EMR..............................................................................................................................................44 Delete an EMR ....................................................................................................................................................44

ZEKE Variables.........................................................................................................................................................45 Naming Conventions ...............................................................................................................................................45 Establishing or Changing Variable Values..............................................................................................................45 Approved Uses ........................................................................................................................................................45

Disadvantages......................................................................................................................................................46 Correcting Variable Values .................................................................................................................................46

ZEKE Utilities and Reports......................................................................................................................................47 ADD Jobs to ZEKE Schedule .................................................................................................................................47

ISSUE ZEKE Commands Verifying Jobname ....................................................................................................47 ZEKE Reports .....................................................................................................................................................48 Obtain Cross Reference Listing on Jobs..............................................................................................................49 ZEDISPLY Program............................................................................................................................................50

Production Problem Solving Tips ............................................................................................................................51 ZEKE Monitors Only Production Jobs....................................................................................................................51 ZEKE will Trigger if Same Schedule Date .............................................................................................................51

Why did ZEKE put my job on HOLD?...............................................................................................................51 Why is My Job Not Running? .............................................................................................................................52 What System am I Delaying? ..............................................................................................................................52 Fixing Production Problems with PPF ................................................................................................................52 ZEKE Summary of Events ..................................................................................................................................52 ZEKE Reference Card .........................................................................................................................................52

Generate ZEKE Network Diagrams with BETA 44................................................................................................53


4

Preface

The ZEKE Reference Manual is intended for people who are responsible for establishing and maintaining the scheduling data for Information Services (IS) production networks. You should already have read the ZEKE Overview and completed the ZEKE Tutorial.

Who to Contact for Support ZEKE questions or problems should be directed to the following people:

ADHELP (Application Delivery Support (ADS) Help Desk) Barry Amos (P088)Application Delivery Support Gilles Robert (P095)Application Delivery Support

Related Information More information on the ZEKE scheduling package and our usage of the product is available in the following locations:

ZEKE Overviewthis manual is intended for beginners. ZEKE Tutorial #210this course is intended for beginners. ZEKE Reference manualthis manual is intended for more advanced users. ZEKE Vendor manualsthese manuals are available in BookManagerVendor Products Library

Platinum Shelf and on iDev under ZEKE.

Note: Exercise caution when using these manuals because our usage of ZEKE is different from what is described in these manuals. If in doubt, contact ADHELP.

ZEKE Reference Cards summarize some of the basic commands to use in the online and batch environments. They are available online on Zeke Reference Cards.

ZEKE InformationFrequently Asked Questions, Quick Tips, etc. are located in iDev.


5

ZEKE Event Master Records

EMR Control Fields The following example illustrates the control fields used to create an Event Master Record (EMR) followed by a description of each parameter. These parameters are generated from the ZEKE Install panels, which you will learn more about in the next section.

For example, once installed, ZEKE automatically schedules and submit job CS010 at 5.00 p.m. on every working day as long as CS005 had completed successfully.

Note: Some fields must be specified and other fields default unless you indicate otherwise.

EVENT ADD


6

If you want to verify when ZEKE is going to schedule your job, browse the event after it has been installed via the ZEKE Online panels. Issue the OCCURS command, which takes you to the OCCURS clause, then the OCCHIT (Occurs Hit) to display the monthly calendars that highlight when your job or event is scheduled.

Note: Consider the effect holidays and weekends can have on your OCCURS clause.

You can also use the ZEKE Forecast report (10.ZEKERPT) to verify that your network runs on a particular date.

Some sample OCCURS clause, which you may find useful, are described later in this manual.. If you have an unusual scheduling requirement, contact ZEKE Support (email ADHELP).

WHEN

The WHEN clause tells ZEKE that job CS005 must reach a normal End-of-Job (EOJ) before job CS010 is submitted for execution.

If your job must wait for a group of similar jobs, you might be able to use the End-of-Group (EOG) parameter, which allows you to pattern on the Event Name (for example: EOG *CRPCS.D1). The Event Name is a brief descriptor of the EMR and has much in common with jobs to which it is related; this could be simpler than specifying EOJ for all the applicable jobs. More about the Event Name field at the end of this section.

If you want a job to be dependent on a job that has an irregular schedule, use the Weak-End-of-Job (WEOJ) conditions. For example, if CS010 had a WHEN clause of WHEN (WEOJ CS005), then CS010 would wait for the successful completion of CS005, if CS005 had been scheduled. If CS005 had not been scheduled, then CS010 would not wait for it.

WEOG works in a similar fashion to EOG and WEOJ. Your job waits for all scheduled events that match the specified Event Name pattern. If the number of these scheduled events varies from day to day, your job only waits on those that have been scheduled for that day.

Some sample WHEN clauses, which you may find useful, are described later in this manual. If you have an unusual scheduling requirement, contact ZEKE Support (email ADHELP).

SCHED

This is the earliest time that a job is released by ZEKE for processing. An event's schedule time may be in the range 00:00 through 47:59 (11:59 p.m. the next day).

Using ZEKE's 48 hour clock, 06:00 Workdays schedules a job for 06:00 Monday to Friday while 30:00 Workdays schedules for 06:00 Tuesday to Saturday. This one-day shift is accomplished by the 30:00 schedule time: 30:00 - 24:00 = 06:00 the next day. This could be useful if you want to do the following:

Schedule your jobs to run Tuesday to Saturday but be dependent upon jobs scheduled for Monday to Friday evening

Take advantage of the Workdays OCCURS clause to handle the weekend and holiday scheduling Many lead jobs in a network have a realistic start time of 20:00, while its following jobs have a schedule time of 17:00. This allows us to start a whole network earlier by simply changing the lead job's schedule time from 20:00 to 18:00.


7

LATE

This is the time a job is considered late if it has not been dispatched by ZEKE. This parameter should only be used for critical Checkpoint type jobs. When used, the LATE time must accurately reflect the time a job is considered late. If set too soon after the scheduled time, even a small interruption sends a non-deletable message to the operator's console. Setting the time too late may not give adequate warning if your application is delayed. The majority of jobs should not specify a LATE time, which is the default. Consult with your project leader if you feel you require a late time on a job.

Note: If no LATE time is specified, the install panel drops the LATE parameter since a blank LATE time is invalid.

CALID

This field indicates the ID of the calendar ZEKE uses when resolving the events OCCURS clause. When the ZEKE schedule is rebuilt, ZEKE scans all the OCCURS clauses and their corresponding ZEKE calendars and decides if a job should be scheduled for execution at that time.

In our example above, Calendar A (CALID A) has Monday to Friday defined as working days. Holidays are also included. Since the OCCURS clause indicates Workdays, ZEKE knows that CS010 are scheduled every Monday to Friday that is not a holiday. The default CALID parameter used with Retail LPAR is CALID A.

The calendars listed below have the following days defined as working days:

Calendar S: Saturdays

Each calendar can have a different set of working days of the week and/or a different set of holidays to suit its situation.

Changing the CALID for an event can dramatically change when its corresponding job is scheduled. For example, an event defined, as Workdays using CALID A would be scheduled every Monday to Friday. With CALID S it would be scheduled on Saturdays only; however, using a different calendar might make the OCCURS clause simpler in some situations.

Note: The ZEKE calendars are used for job scheduling only and have nothing to do with the Data Management calendars and dataset versioning.

RETAIN

This field indicates what happens to the ZEKE schedule record for a job that is not processed within 24 hours of being scheduled.

If RETAIN = YES and the event has not completed, the job's schedule record is carried over onto the next day's ZEKE schedule.

If RETAIN = NO and the event has not completed, the job's schedule record is automatically dropped by ZEKE from the next day's schedule (24 hours after it was originally added to the schedule). The default is YES.

Completed events are automatically dropped from the ZEKE schedule 24 hours after they were initially scheduled.

EXPIRE


8

Indicates the date (ddmmyyyy) the Event Master Record (EMR) is automatically deleted from the ZEKE catalogue. To remove an expiration date, use 0 as the date value. The default is no expiration date.

TIMES

This field indicates how often an event should be scheduled for submission during the same working day. Most job events default to 1 (for example, once a day). Recurring events (which are dispatched multiple times throughout the day) are first dispatched at the event's normal schedule time. It is next dispatched after its frequency interval has passed. The TIMES field decrements with each submission of the event.

MULTHIT

This field indicates whether or not an event is scheduled multiple times due to a non-working day. For example, an event is scheduled on Mondays and Tuesdays; however, one week Monday is a holiday. MULTHIT determines if the event is to be scheduled to run twice on Tuesday or if the Monday run is skipped. If this is a possibility, you should consider the following options:

YESthe event could be scheduled multiple times on the working day. NOthe event is not scheduled multiple times on the non-working day. Normally we only want a

job scheduled once a day. NO is the default.

NWDAY

This field only applies to events that fall on a non-working day (holiday or weekend). For example, an OCCURS clause of Workdays never falls on a non-working day but day eq 26 could. If this is a possibility, you must select one of the following options:

A (After)the event is scheduled on the next working day. This is the default. B (Before)the event is scheduled on the working day that precedes the non-working day. O (On)the event is scheduled on the non-working day. N (Not)do not schedule the event on a non-working day. Note: This field must be the same for the lead job and all REFEVENTed events.

The NWDAY field allows you to remove before hol/week etc. from the OCCURS clause because NWDAY does the same thing. However, the NWDAY field is not as visible as the OCCURS clause.

FREQ

This field indicates the amount of time (hh:mm - 00:01 to 48:00) that ZEKE waits before again dispatching a recurring event the same day. ZEKE adds this frequency to the current schedule time (Freqcalc option S) or the system time (Freqcalc option C) to determine the next schedule time. The default is 00:00 since most jobs are only run once a day.

FREQCALC

This field only applies to recurring events. There are two options:

S (Schedule)the schedule time for the next submission of this event is based upon adding the event's frequency (FREQ) to the event's original or last schedule time. S is the default. For example, an event is scheduled for 10:00, then every two hours after that, two more times. The


9

second and third time this job is run is 12:00 and 14:00 regardless of the completion time of the first job. If the operating system has been down for a while, this option causes a recurring event to play catch up and run every minute until it is back in step with the current clock time.

C (Clock)the schedule time for the next submission of this event is based upon adding the event's frequency (FREQ) to its last completion time. For example, an event is scheduled for 10:00, then every two hours after that, two more times. If it completes the first time at 10:15, the second event is scheduled for 12:15. When it completes, the third event is scheduled for two hours after that. If the operating system has been down for a while, this option prevents a recurring event from playing catch up; however, the delay and the job's frequency could cause the job to run longer.

SYSTEMID

This field indicates the ID of the operating system to be used when the jobs are scheduled. A indicates the PROD system and B indicates the DEV system.

USERID

This field specifies the two-character system mnemonic of the event and is used by ACF2 to determine who has update access to the event.

APPL

This field indicates the (old) Division of the job network (or the application). These values are not as directly applicable to the business as they once were. However, we suggest that you have a standard for your application because this makes it easier to select all the jobs in the application if you want to generate network diagrams directly from the ZEKE catalogue using BETA 44.

CRPold Corporate Division FINold Finance Division GRPold Group Division INDold Individual Division INVold Investment Division XXXother logical grouping

GROUPID

This field is used to further define the event where f indicates the frequency of the job network (D-daily, W-weekly, M-monthly, Q-quarterly, Y-yearly, R-on request or O-other) and n is a numerical identifier for this job network (for example, D1 = daily network # 1).

Note: R-on Request signifies a job which uses Request in the OCCURS clause (for example, a job which is ZADDed from another job). O-Other indicates a job that is scheduled by the ZEKE scheduler but does not fit any of the other patterns (for example, scheduled only in January and February).

ENAME

This field (CRPCS.D1010 in our example) is used to identify a group of related events. The Event Name (ENAME) is assembled from the Application ID (CRP), the System mnemonic (CS, LF, GXS, etc.), and the Group ID (D1) followed by a unique identifier (xxx) which represents the numeric


10

portion of the jobname. If you use the ZEKE event panels (11.ZEKE) to build your implementation records, the ENAME is automatically generated for you.

Note: Having a standard for your application makes it easier to select all the jobs in the application if you want to generate network diagrams with BETA 44 directly from the ZEKE catalogue.


11

DESC

This optional field is used to provide a description for the event. If it is present, the first 24 bytes of the description appear in the ZEKE network diagrams generated from the ZEKE catalogue with BETA 44.

MUSTEND

Enter the latest time that you want the event to complete processing. Prior to dispatching the job, ZEKE adds the current system time to the events average duration. If the result is greater than the MUSTEND time, a message is written to the system log, and the event is left in the non-dispatched (NDSP) queue:

EVENT 00301 1999172 VER 00000 MUST END TIME REACHED In Schedule View it has a reason WHY of. Event is LATEPast Must End Time.

For example, if the current system time is 13:00, the MUSTEND time is 14:00 and the average duration is two hours, then ZEKE does not dispatch the event because it is not likely to complete until 15:00 (one hour after the MUSTEND time). For most jobs that only run once a day, this field should be left blank.

NOTAFTER

Enter the latest time that you want ZEKE to dispatch a recurring event. If the next scheduled time is going to exceed the NOTAFTER time (regardless of the current value of the Times parameter), ZEKE stops re-scheduling the event and put it in SUCC status. For most jobs that only run once a day, this field should be left blank.

Online EMR Fields

All of the fields listed above can also be changed via the ZEKE Online Event Master Record panels. However, when compared to the batch update above, online changes are immediate and you do not have an audit trail.

Do not change the following fields because they can adversely affect the execution of your job:

PLATFORM MVS is the only acceptable value.

SENDTO *LOCAL is the only acceptable value.

OPEROK N is the only acceptable value.

CONTROL Y is the only acceptable value.

All remaining fields (for example, tapes, etc.) have no affect in our ZEKE environment and can be ignored.


12

Occurs Clauses

Multiple OCCURS Clause Phrases An event can have more than one OCCURS clause phrase. The AND/OR logic and additional keywords are optional. For example, the following event is to be selected on every Monday and Thursday. The event is defined with two 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 clause 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 Clauses Phrases In addition to AND/OR relationships between multiple OCCURS clause phrases, multiple OCCURS clauses can be surrounded by sets of parentheses. This separates the clauses into groups and tells ZEKE to resolve one group before resolving the next higher group.

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 inner most 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.


13

Some Simple OCCURS Clauses

Listed below are a few simple examples that use Calendar ID A. More examples appear later in the manual.

Scheduling Requirement OCCURS Clause

Every day including weekends and holidays (DAILY)

Every workday excluding weekends and holidays (WORKDAYS)

Every Monday that is a working day (WMONDAY)

The first Friday of the month that is a working day (WFRIDAY.1)

On the second working day of each week (WDAYW.2)

On Monday if it is the third week of the month (MONDAY AND WEEK.3)

Scheduling Events on Holidays and Weekends

The following OCCURS clause keywords are affected by holidays and weekends:

DATE xx mm/dd/yyyy DAY EQ xx DAY.x EOM

EOM-xx EVERY xx DAYS HOLIDAYS HOL/WEEK

MONDAY-SUNDAY WEEKEND

Events scheduled for a particular day of the week, or EVERY xx DAYS, might fall on a non-working day. However, events defined to OCCUR Workdays, 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 non-working day, ZEKE, by default, schedules the event for the following working day.

For example, an event is defined to occur on Monday, which 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 Schedule Queue Record with Monday's date, and places it in Tuesday's schedule. The Schedule Queue Record contains Monday's date because there might be another SQR 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:


14

OCCURS (Saturday on Weekends)

For another example, an event is defined to occur every 10 days. If the event date falls on a holiday or on a weekend, ZEKE, by default, schedules it 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 Additionally, 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)

This schedules the event every Monday and Tuesday; however, if Monday is a holiday, it is scheduled on the previous workday.

OCCURS ((Monday or Tuesday) before Holidays)

The schedules the event Monday or Tuesday; however if either is a holiday, it schedules the event on the previous workday. When you specify a holiday or weekend in the OCCURS clause, it overrides the NWDAY field in the EMR.

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.

Sample Occurs Clauses

CALID A considers Monday to Friday to be working days while CALID S considers Saturdays as working days. This list shows how calendars and OCCURS clauses can work together to produce different results.

If you want to verify when ZEKE schedules your job, then browse the event via the ZEKE Online panels. Issue the OCCURS command which takes you to the OCCURS clause, then issue OCCHIT (Occurs Hit) to display the monthly calendars. The highlighted date indicates when your job or event is scheduled.

Scheduling Requirement OCCURS Clause

Every day including weekends and holidays (Daily)

Every workday excluding weekends and holidays (Workdays)

Every Monday that is a working day (Wmonday)

The first Friday of the month that is a working day (Wfriday.1)

On the second working day of each week (Wdayw.2)

On Monday if it is the third week of the month (Monday and Week.3)


15

On Tuesday if it is in the first full week of the month (Tuesday and Fweek.1)

On Tuesday if it is in the second week of the month that includes all normal working days

(Tuesday and Wfweek.2)

On Sundays (Sunday on Weekends

On all working days except for Mondays ((Tuesday or Wednesday or Thursday or Friday) and Workdays)

Regular Month-endscheduled on the 26th or first working day thereafter each month

(Day EQ 26)

Schedule every working day other than the 26ththis is not the opposite of Regular Month-end since Regular Month-end does not always fall on the 26th

(Day NE 26 and Workdays)

Schedule monthly on the 26th but not in January, April, or July

((Day EQ 26) and (not January and not April and not July))

Group Month-endscheduled on the 25th or first working day thereafter each month

(Day EQ 25)

Scheduled on the 31st if a working day. If the month has less than 31 days, the job is not scheduled

(Day EQ 31)

Last working day of the week. If Friday is a holiday, schedule on Thursday

(Friday before Holidays)

Regular Quarter-end (Day EQ 26 and (March or June or September or December))

Last working day of the month (WEOM)

Last Friday of the month (Friday.L)

Four working days after the second Tuesday of the month (Tuesday.2 + 4 Wday)

Two days before the third Friday of the month. If that day falls on a holiday or weekend, the event falls on the next working day

(Friday.3 - 2 Day)

On request (Request)

On a specific date (Date EQ Dd/Mm/Yy)

Last working day of the year (WEOM and December)

Second workday of the month (Wday.2)

First working day of the year (Workday EQ 1 and January)

All non-working days (Not Workdays on Hol/Week)

On the 15th of the month, unless that is a holiday or weekend in which case it runs the first working day before the 15th

(Day EQ 15 before Hol/Week)

On the first and third Mondays of each month (Monday.1 Or Monday.3)

Use the OCCURS clause of event nnnnn. Event nnnnn could in turn REFEVENT another event. ZEKE refers back as far as necessary until it picks up a valid OCCURS clause

(Refevent Nnnnn)


16

Event is to be selected on the date specified and every xxx days thereafter unless it is a weekend or holiday in which case it is scheduled on the next working day

(Every nnn Days beginning dd/mm/yy)

Two days before the last day of the month unless it is a weekend or holiday in which case it is scheduled on the next working day

(EOM-2)

Occurs every working Saturday marked in calendar FX000 OCCURS (Calendar Fx000 and Wsaturday)

Schedule if the value of variable $EXAMPLE is true and it is a working day.

(Var $Example EQ Ready and Workdays)

ZEKE and Statutory Holidays

Creating a ZEKE OCCURS clause based upon the known holidays for the current year is one thing; however, with a complex OCCURS clause it is sometimes difficult to know if the clause is still true once future holidays have been finalized. The following table outlines when each holiday is likely observed and from that you can determine whether or not the clause still works once the next year's holiday schedule has been finalized.

Note: Some holidays (for example, Labour Day) are fixed, while others (prefixed by *) float depending on their proximity to the nearest working day and the consensus of the business community.

Holiday Observed on

New Year's Day The first working day on or after January 1

Good Friday April 02 1999 April 21 2000

* Victoria Day The first Monday on or before May 24

* Canada Day The first working day on or after July 01

Civic Holiday The first Monday in August

Labour Day The first Monday in September

Thanksgiving The second Monday in October

* Christmas Eve The first working day before the Christmas Day holiday

* Christmas Day The first working day on or after December 25

* Boxing Day The first working day after the Christmas Day


17

WHEN Conditions

WHEN conditions are satisfied when the system initiates or completes the action named in the WHEN condition (such as starting or ending a specific job name). As each WHEN condition is satisfied, the WHEN segments are examined to determine if they are true. If so, the event is WHEN SATISFIED.

For example, if job XYZ456 has a WHEN clause of WHEN (EOJ ABC123), then ZEKE does not activate XYZ456 until job ABC123 has completed successfully. The following are some other possible keywords for the WHEN clause:

Condition Action

AEOE Abnormal End of Eventother than a job

FAIL Abnormal End of Job

BOJ Beginning of Job

EOE End of Event (includes weak and extended EOEsother than a job)

EOG End of Group (includes weak EOGs)

EOJ End of Job (includes weak and extended EOJs)

VAR Variable

WEOE Weak End of Eventother than a job

WEOG Weak End of Group

WEOJ Weak End of Job

WHEN Conditions for Multiple Event Versions For events with multiple schedule queue records with the same schedule date (for example, multiple versions), a separate WHEN condition can be defined for each version. Each WHEN condition is assigned a version number to indicate to which version of the event it belongs.

When an event version is placed in the schedule, ZEKE searches for a WHEN condition with the same version number. If one is found, that WHEN clause is used for the event version. If one is not found, the version zero WHEN clause is used as the default (if it exists). If a default WHEN clause has not been defined for the event, then the event is automatically WHENOKd.

Note: This feature first became available in July 1998 but we had no immediate use for it.

WEAK Conditions WEAK conditions in a WHEN condition allow the user to create WHEN conditions referring to jobs 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 a WHEN condition for job ABC123:

EMR ABC123 WHEN (WEOJ LAS100) WEOJ=Weak End of Job


18

If LAS100 is on todays schedule, then job ABC123 is not dispatched until LAS100 reaches a successful End-of-Job.

If LAS100 is on todays schedule, Disabled ZEKE still waits for the job to end before dispatching ABC123. If LAS100 is deleted from todays schedule (instead of being disabled), then the WEAK condition would cause ABC123 to start.

If LAS100 was never on todays schedule, then this condition is ignored and job ABC123 is dispatched.

Generic Names

To 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. For example, *ABC matches all events with Event Name 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 both a generic name and a wildcard character; therefore, you need to understand how ZEKE interprets an asterisk in different situations. The maximum number of characters you can use is 12. If all 12 characters are specified (with an asterisk in the first position), ZEKE assumes that the first asterisk is a wildcard character. For example, *kkkkkkkkkkk selects all events with any character in the first position and a K in the 2nd through 12th positions. If less than 12 characters are specified, ZEKE assumes that an asterisk in the first position means a generic name. For example, *kkkkkkkkkk (which has one less K than the previous example) selects all events beginning with ten Ks. If you want to use an asterisk to indicate a generic name but you need to specify all 12 characters, place the asterisk in the last position, such as in the example kkkkkkkkkkk*. This selects all events beginning with 11 Ks.

Note: Generic names are only valid for Event Names. Generic names cannot be used for job names.

EOG WHEN Condition

The EOG (End Of Group) WHEN condition is a special case. This WHEN condition is satisfied when all events in the schedule that match the specified Event Name are in either SUCC or Disabled status. Note the following:

At least one event must be in SUCC status. All events can be disabled for the WEOG condition. WEOG is also satisfied if there are no matching events in the schedule. Use EOG to trigger an event by the completion of a varying number of other events. For example, a master file update needs to be performed after all daily transactions are received. If the number of daily transaction jobs varies from day to day, the EOJ WHEN condition cannot be used, because some of the EOJ conditions would not be satisfied if their corresponding jobs were not run on a particular day. With EOG, ZEKE makes sure that all the scheduled events that match the specified Event Name are in either SUCC or Disabled status before it releases the master file update job. If no transaction events are complete, the master file update does not run.


19

The EOG WHEN condition can be unsatisfied up to the time of dispatch or up to the time the event is added to the dispatch queue. For example, an event with an EOG condition is scheduled at 18:00. At 10:00, two events that match the EOG condition are in the schedule. At 12:00, these events are completed. This satisfies the EOG condition but the event is not scheduled to run until 18:00. At 14:00, an event that matches the EOG condition is added to the schedule. The EOG condition is no longer satisfied and the new event must be completed or disabled before the event with the EOG condition can be dispatched.

Multiple WHEN Condition

An event can have more than one WHEN condition. The event in the following example is defined with two WHEN conditions joined with the word OR:

WHEN (EOJ ABC123 or EOJ XYZ456)

The keyword OR indicates the event is satisfied when either clause is true. The keyword AND indicates the event is satisfied only when both of the WHEN conditions are true. For example:

WHEN (EOJ XYZ456 and EOJ ABC123)

Grouping Multiple WHEN Conditions

In addition to AND/OR relationships between multiple WHEN conditions, multiple WHEN conditions can be surrounded by a set of parentheses. This separates the clauses into groups and tells ZEKE to resolve one group before resolving the next higher group. For example, an event is satisfied when Job A completes and either Job B or Job C completes:

WHEN (EOJ JOBA and (EOJ JOBB or EOJ JOBC))

The inner group is resolved first. The inner group is true if Job B or Job C finished. Because the keyword AND joins the two clauses, the event is only satisfied if Job A has also finished.

ZEKE Variables in WHEN Conditions

To use a ZEKE variable as a WHEN condition, specify a variable and the relational operator to compare to a specified value.

Variable substitution in WHEN a condition is performed when the Schedule Record is created (for example, 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 WHEN condition is satisfied. The WHEN condition is also satisfied if the variable is already equal to YES when the schedule is first loaded.

Extended Dependencies

The keywords XEOJ (Extended End of Job) and XEOE (Extended End of Event) provide the ability to trigger jobs and events across multiple schedules. For example, suppose 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


20

and determine whether or not it has run since the last time JOB A ran. The jobs schedule date does not have to be the same as the schedule date of the event being triggered.

Extended dependencies can be triggered by events that have run in the past but are no longer in the schedule. When the schedule is rebuilt, the event directory records are searched and the first event matching the job name or Event Name is examined. If the last run of that event has completed successfully since the last time the event with the extended dependency has dispatched, the condition is satisfied and is displayed with an asterisk (the same as EOJ and EOE). Otherwise, the condition is treated as if it were an EOJ or EOE and must wait for a matching event to complete successfully to be satisfied.

For the purpose of extended dependency triggering, the following information is retained in the EMR for the last execution of each event: the start date and time, the end date and time, and the status. However, if the Schedule Record has been re-queued 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.

If the last execution of an event did not complete successfully, the event cannot trigger an extended dependency. (A JCL error is considered an unsuccessful completion; Forced SUCC is considered a successful completion.) If the execution is not triggering, the information for that execution is still retained in the EMR but no triggering occurs.

Extended dependencies can be manually satisfied using the ZALTER WHENOK operator command.

Extended dependencies are examined each time an event becomes TIMEOK and WHENOK. If a WHEN condition has two extended dependencies, both must be satisfied at the same time in order for the trigger to occur.

Note: The XEOE and XEOJ conditions do not support the use of the VER or SP keywords. If a version number is specified, it is ignored; an event is triggered by any version of a matching event.

Remote Prerequisites

This feature is new as of July 1998 and is currently untested. Contact ADHELP before attempting to use it.

Previously, prerequisites for a network job had to be satisfied on the system that dispatched the job. Now with ZEKE 4.5, prerequisites can be satisfied from any system. Additionally, this enhancement allows ZEKE to share prerequisite information with PLATINUM AutoSys, the scheduling system for UNIX and NT.

This new capability does not apply to the AutoSys/Team Agent applicationprerequisites for a network job must still be satisfied on the system that dispatches the job. The implementation is straightforward. Add the keyword NETR to the WHEN condition. This tells ZEKE the ID of the system where the prerequisite is to occur. For example,

WHEN: (EOJ JOBA and EOJ JOBB NETR SYSB)

With the presence of the NETR keyword, ZEKE waits on an EOJ from job JOBB on system SYSB before dispatching the event. When JOBB is complete (EOJ), SYSB notifies the originating ZEKE system that the WHEN condition is satisfied. ZEKE then satisfies the WHEN condition for all events waiting for an EOJ JOBB from SYSB.


21

At this time, only the WHEN conditions EOJ, FAIL, and BOJ can be shared with remote systems.

Note: The NETR keyword does not support use of the VER keyword. If a version number is specified, it is ignored.

You can also use the keyword NETR with the ZALTER command: ZALTER EV 1 WHENAND (EOJ JOBC NETR SYSB) To add a remote WHEN condition with an and

relationship.

ZALTER EV 1 WHENOR (EOJ JOBC NETR SYSB) To add a remote WHEN condition with an or relationship.

ZALTER EV 1 WHENOK (EOJ JOBB NETR SYSB) To WHENOK a remote WHEN condition.

Sample WHEN Clauses

Prerequisite WHEN Condition WHEN Clause

Wait for normal end of a job of JOB1. (EOJ JOB1)

Either JOB1 or JOB2 must go to normal End of a Job. (EOJ JOB1 or EOJ JOB2)

In this case JOB1, JOB2 and JOB3 must all go to normal End of Job. This is because an OR preceded by an AND becomes an AND.

(EOJ JOB1 and EOJ JOB2 or EOJ JOB3)

Wait for normal end of JOB1 if JOB1 has been scheduled. If JOB1 has not been scheduled, do not wait for it.

(WEOJ JOB1)

Abnormal end of JOB1 and abnormal end of JOB2 and end of started task PRODWTR.

(FAIL JOB1 and FAIL JOB2 and EOJ PRODWTR)

Beginning of JOBC. (BOJ JOBC)

Normal End of an Event which has an Event Name of EVENTNAME1.

(EOE EVENTNAME1)

Wait for the end (SUCC or disabled) of a group of events whose Event Names match GRPGRXD16**:fnref refid=group.

This is useful when you have a job dependent upon a series of other jobs that varies from day to day.

(EOG GRPGRXD16**)does a wild card match

(EOG *GRPGRXD16)does a generic match

Wait for normal End of Job of all scheduled events that have an Event Name that matches GRPGRXR2. If no events are scheduled that match this Event Name pattern, then do not wait for them.

This is useful when you have a job dependent upon a series of other jobs that may or may not be scheduled from day to day.

(WEOG *GRPGRXR2)


22

Wait until ZEKE variable $SAMPLE1 has a value of YES.

(VAR $SAMPLE1 EQ YES)

ZEKE variable $SAMPLE matches the character string.

(VAR $SAMPLE EQ 'IT IS OK TO CONTINUE')

Normal End of Job of JOB3 and ZEKE variable $VARNAME has a value of OK.

(EOJ JOB3 and VAR $VARNAME EQ OK)

Exercise caution when adding or deleting events that might match this Event Name and delay your application. There must be at least one matching event in SUCC or DISABLED status for this to work.


23

Job Execution and ZEKE

JCL and PJSUB Our production JCL is stored in PDS libraries by application. Implementing the JCL via FWB makes sure that the JCL is stored in the right locations. When ZEKE has determined that a job has satisfied all its prerequisites the following occurs:

The jobname (for example, LAS100) that is specified in the ZEKE EMR is passed to PJSUB (Production Job Submit facility)

PJSUB looks in LA.JCL for a member that has the same name as the jobname (for example, LAS100).

Note: The jobname within this member must have the same name as the member name.

The JCL member is then passed to MVS where it waits for an initiator in order to begin execution Once the job begins execution a ZEKE utility program called ZEKESET is used to pass information from the JCL (or Job) to ZEKE where it is used to make scheduling decisions.

ZEKESET The ZEKESET program is used to pass information from the JCL to ZEKE that it uses to make scheduling decisions. This information is coded into the JCL via a SYSIN data card. There are three main uses for using ZEKESET:

1. Abend notification (you want to tell ZEKE that a job has failed) 2. Assigning values to ZEKE variables 3. Setting condition codes

Abend Notification

The SET ABEND 99 statement causes the job to abend immediately. It might also notify the console operator and ZEKE that the job has failed (based upon the value of the NOTIFY parm on the Job cardsee the NOTIFY parameter below). ZEKE does not release any jobs that are dependent upon this job's successful completion. Refer to the JCL ModelZEKE Abend.

//CHECKCC EXEC PGM=IEFBR14,COND=(0,LT) //SYSIN DD * SET ABEND 99 /* //SYSPRINT DD SYSOUT=*

The console operator is automatically notified of all system abends so it is not necessary to use COND=ONLY.

Note: If your job is dependent upon a non-ZEKE controlled job, that job must contain a ZEKESET abend step so ZEKE knows if it fails.


24

NOTIFY Parameter

NOTIFY=CONSOLE informs the console operator and ZEKE that your job has failed. This setting is applicable to critical jobs.

NOTIFY=ZEKE informs only ZEKE that your job has failed. This setting is applicable for non-critical jobs.

Assigning Values to ZEKE Variables

The ZEKESET step with the SET command allows you to assign specific values to ZEKE variables. For more information on variables and how they assign these values, refer to the section called ZEKE Variables.

Setting Condition Codes

The following ZEKESET step checks whether or not a specific condition is true and then directs the processing within that job. For example, maybe a report is to be created if data was processed in a previous step that in turn set a variable to OK if true. The following example shows how it looks:

//ZEKESET EXEC PGM=ZEKESET,COND=( ) //SYSPRINT DD SYSOUT=E //SYSIN DD * SET CONDCODE 1 IF VAR $variable NE OK /*

If the variable $VARIABLE is not equal to OK then the condition code of the step would be 1. The report step then checks this condition code to determine whether or not to execute. The following are some more examples:

SET CONDCODE 4 IF TIME GT 050000

A condition code of 4 is returned for this step if the time (hhmmss) has exceeded 5.00am. If it is prior to 5.00am, a condition code of 0 is returned. You can prevent job steps from executing simply by setting a return code. SET CONDCODE 8 IF DAY EQ 1 Set a condition code based on the day of the week (where Monday-Sunday is numerically equivalent to 1-7). SET CONDCODE 8 IF @VARNAME. EQ 'YES' Check the value of a variable (UJSUB for example) to a specific value and set a return code.


25

Security Access

ACF2 Security Make sure that ZEKE and any other applications or users have the access that they need. The ACF2 Rule Models or another applications rules might be helpful for this. If you have any questions, contact Computer Security (email ACCESS).

ZEKE and PJSUB must be able to read your system's JCL library (ACF2 DSN rule). ZEKE and PJSUB must be authorized to submit your system's jobs (ACF2 PJS rule). Your systems userid and support people might require access to your system's ZEKE Variables

(ACF2 ZDN rule). Your system's support people require access to modify your system's ZEKE Job Event Master

Records (ACF2 ZJE rule). Your system userid and support people require access to issue ZEKE commands against your system

(ACF2 ZCM rule).

ZEKE Online Security ZEKE internal security must be updated for those people who require update access via the online ZEKE panels. Such access is generally limited to Technical Analysts and Technical Services. These requests should be sent to ADHELP along with the name of the production userid.

Clustering Jobs and Checkpoints

ZEKE can schedule many jobs at the same time so wherever possible you should schedule jobs with different functions to run at the same time. Enqueue datasets should be used when scheduling more than one update job at a time. If your system clusters jobs, you should use a checkpoint job as illustrated below.

Job four in this case is a dummy job (for example an IEFBR14 step) that runs at the end of Jobs 1, 2, and 3. Likewise Jobs 5, 6, and 7 do not start until Job 4 has completed. This serves two purposes. It creates a simpler WHEN clauses for Jobs 5, 6, and 7 and it provides a job (Job 4) which can be used as a barometer for how the system is progressing.

Job 4 CHKPT Job

Job 7 Job 5 Job 6

Job 2 Job 3 Job 1

Scheduling One Job from Another Job The above examples dealt with controlling job steps for jobs that were already scheduled. But how do you get one job to schedule another job on demand (for example, a database backout). Instead of scheduling them every day and only running them when needed, you can use one of the following 10.ZEKE utilities in SPF.

1. IXA Table //ZADD EXEC ZEZADD,EVENT=1234,JOBNAME=CS999,DATE= In this example, ZEZADD checks an IXA table to verify that job CS999 has a ZEKE event number of 1234. If it does, then CS999 is added to the schedule. IXA makes this more efficient than adding an event by jobname and verifying that the jobname and event number match eliminates any surprises from adding an event by an old event number. Any event that REFEVENTs CS999 is also added at the same time.


26


27

The IXA table is generated from the latest ZE.EVENT.SUMMARY.SIXX which is created after the ZEKE schedule has been rebuilt around 16:30 daily. If the job you want to add is in the latest ZE.EVENT.SUMMARY.SIXX, then you can use this method.

If no date is specified, then it defaults to the current date. This might be a problem if this job is scheduled before or after midnight and if it also interrelates with other jobs that have a different ZEKE schedule date.

Note: ZEKE does not let one event trigger another event if the schedule dates on the two records are different.

DATE can be hard-coded or passed through via a MSSCAN date variable expression. This resolves potential triggering problems encountered when jobs are added to the schedule after midnight.

The event record for these jobs look like any other job event except the OCCURS clause is (Request). The SCHEDule time in most cases should be 00:01 if you want the job to be submitted immediately (since the schedule time would be immediately satisfied).

2. ZEKE Extract

//ZADD EXEC ZEKEADD2, // HLQ=CS, // LIB=, // INCLJ=Y, // LEAD=CS500, // ZCAT='ZE.ZCATALOG.MASTER' //SAS.DATE DD * 930924 /*

This method is much slower and more expensive than the previous one since it scans the ZEKE catalogue; however, it is useful if you want to schedule a new or changed event that is not in the latest ZE.EVENT.SUMMARY.SIXX yet. There is no jobname/event number checking so exercise caution.

This procedure is more useful for user submitted jobs than for production.

3. UJSUB UJSUB is another way to add a production job to the schedule. If the job needs to be added to the evening schedule so it can communicate with regularly scheduled ZEKE jobs, then the UJSUBed job should be typrun=overnite. The ZEKE OCCURS clause should be set to (Request) so it is not automatically scheduled by ZEKE. Refer to the UJSUB manual online.

Scheduling Jobs between PROD and DEV ZEKE is licensed for both the Production and Development machines and each system has its own ZEKE catalogue. If your system runs exclusively on one system, you should define your network to the ZEKE on that system. If most of your system runs on PROD and a couple of jobs run on DEV, the entire network should be scheduled from the PROD machine and the DEV jobs submitted from the PROD machine.

Note: Since ZEKE uses PJSUB to submit jobs, an ss.JCL dataset is needed on the system where the jobs are scheduled in order for ZEKE to submit them for processing.

If a job runs on the opposite system from which it was scheduled, then the system where it originated must be notified of the job's successful completion. The two ZEKE catalogues are not shared and there is no automatic procedure to notify the other ZEKE. If this information is not passed back, your network could stop at that point waiting for a WHEN clause to be satisfied. Following is an example of how this would work. Let's assume the following:

ZEKE must control the network without manual intervention. All CS jobs are scheduled from PROD. CS510 must do its processing on DEV.

PROD SYSTEM DEV SYSTEM

Reader by CS510 Submitted to Internal

CS510 CS510

CS510

CS515

CS505

In the above example above, when CS505 ends on PROD, ZEKE dispatches CS510. Since CS510 has a SYSAFF=SI10 card, and its JCL resides on PROD, then ZEKE on PROD submits it to run on DEV. This leaves a Pending CS510 event on PROD where it was originally scheduled. The last thing CS510 does on DEV is to submit a CS510 job back to PROD via its imbedded JCL (refer to the next example).

The CS510 that runs on PROD notifies ZEKE that the Pending CS510 it has previously dispatched from PROD had now completed on DEV. You must use the same jobname for CS510 on DEV and PROD so that ZEKE matches it with the Pending CS510 event on PROD. Once ZEKE sees that CS510 has completed, it submits CS515.


28


29

//CS510 JOB (D01,07CS) ..... //* --------------------------------------------------------------- //* THIS STEP SUBMITS CS510 FROM DEV TO THE INTERNAL READER ON //* PROD. SINCE THIS IMBEDDED JCL HAS THE SAME JOBNAME AS THE //* PENDING CS510 ALREADY ON PROD, ZEKE RECOGNIZES THE REAL CS510 //* ON DEV AS HAVING COMPLETED SUCCESSFULLY. //* --------------------------------------------------------------- //SUBZEKE EXEC PGM=WCSGENER,COND=(0,LT) //SYSIN DD DUMMY //SYSPRINT DD SYSOUT=* //SYSUT1 DD DATA,DLM=## //CS510 JOB (D01,07CS),'ZEKE NOTIFY',MSGCLASS=E /*JOBPARM T=(,3),L=1,SYSAFF=SI00,Q=O,OUTNAME=CSPROD //* //CHECKCC EXEC PGM=IEFBR14 //ZEKESET EXEC PGM=ZEKESET,COND=(0,EQ,CHECKCC) //SYSPRINT DD SYSOUT=E //SYSIN DD * SET ABEND 99 /* //* ## //SYSUT2 DD SYSOUT=(A,INTRDR) //*

Scheduling Jobs between PROD and an AS/400 or NT Server Scheduling jobs between PROD and an AS/400 (or NT server) is similar to running jobs between PROD and DEV.

For example, you might have a job called ESA001 that is scheduled and runs on PROD. It in turn submits a job with the same jobname that runs on an AS/400 (called TMGIMAG1). At the end of the AS/400 job a file is sent back to PROD via FileWriter.

The file sent back to PROD looks like the following example:

ES.SUPP.FILEWTR.PARMLIB(A001) DSNAME=ES.INVSIGN.TMGIMAG1.Vxxxx Dataset being sent to PROD. FROMNODE=TMGIMAG1 Where the file originated. FROMUSER=* ADMIN=HELP400 Userid of person to receive error messages. ZEKEADD=JOB=ESA011 Jobname of the job that Zeke adds to the schedule. Or ZEKEADD=EV=12345 The event number for the job that Zeke adds to the schedule

This file activates the remaining jobs ESA011, ESA011A and ESA011B that run on PROD. More information on FileWriter can be found in the FileWriter manual online.


30

Interacting with ZEKE

ZEKE OnlineDirect Inquiry From the SPF main menu, type ZEKE on the command line. This takes you to the ZEKE Primary menu, then select the option that matches the component you want to access.

Event Master Records

To view individual Event Master Records select option 1 (Event Record Maintenance) from the ZEKE Primary menu. This takes you to the Event Record Selection Criteria panel. From here you can display specific events by event number or display a collection of jobs based upon a jobname mask.

Zeke ZEKE Primary Menu OPTION ===> 1 1 EVENT Event Record Maintenance 2 SCHEDVIEW/ZCOM Schedule View/Scheduling System Commands 3 CALENDAR Calendar ID Maintenance 4 5 6 7 8 VARIABLE Variable Name Record Maintenance 9 C CONTROL ALTAI Display Characteristics T TUTORIAL Information about using ZEKE X EXIT Exit the ZEKE Application

Display an Event by Event Number

To display an event by its event number, type BROwse on the command line of the Event Record Selection Criteria screen (below) and the event number of your job in the EVENT field and press Enter.

Zeke Event Master Record Functions BROWSE COMMAND ===> EVENT ===> Primary Commands: ADD AUTORPLY BROWSE CCODE COPY COPYALL DEACT DELETE DOCUMENT EDIT JCL OCCURS PATH PRED REACT RESOURCE RESTART SUCC WHEN Template: N Platform: MVS Evt: 1111 Desc: DCD115 - RUN RUNSTATS ON DTS@MISC Type: JOB Desc2: Ename: CRPDCDW1115D App: CRP Grp: W1 Usrid: DC DRL: Sys: B Cal: A Retain: N Nwday: A Multhit: Y Exp: Sendto: *LOCAL Verload: 00000 Early: Sched: 24:30 Late: Mustend: Notafter: Dprty: 99 Operok: N Times: 001 Freq: 00:00 Freqcalc: S Trig: A Tapes: 000 Avgdur: 00:00:24 Control: Y Job: DCD115 Class: Pri: JCL--> PDS: PJSUB Member: DCD115


31

The following screen is the Event Master Record for job DCD115. You might recognize some of these fields (JOBname = DCD115, SCHEDule time = 24:30) from when you earlier created an EMR in batch.

To display the OCCURS clause for this event, either type OCCURS on the command line or press Page Down. In this example, we can see that this jobs OCCURS clause schedules the job to run on every working day as indicated in Calendar A.

Zeke Event Master Record Function BROWSE COMMAND ===> Primary Commands: BROWSE EDIT ACCTG OCCHIT Evt: 01111 Type: JOB Job: DCD115 Ename: CRPDCDW1115D Calid: A Ver: 00000 Platform: MVS Occurs: (WORKDAYS)

To display the WHEN clause for this event, either type WHEN on the command line or press Page Down. In this example, we can see that this job (DCD115) is only dispatched by ZEKE after job DCD115BC has ended successfully.

Zeke Event Master Record Function BROWSE COMMAND ===> Primary Commands: ADD BROWSE COPY DELETE EDIT WHEN Evt: 01111 Type: JOB Job: DCD115 Ename: CRPDCDW1115D Calid: S Ver: 00000 Platform: MVS When:(EOJ DCD115BC)

When will my Job be Scheduled?

If you want to see on what days this OCCURS clause actually schedules the job, use the OCCHIT command from the OCCURS screen.

You first see a calendar of the current month. The days that the job is scheduled are highlighted with an asterisk. H indicates a holiday and W indicates a weekend. If a number appears beside the asterisk, it means that the job has been scheduled that many times on that day. If you only want your job to run once on that day, consider setting the MULTHIT parm to N.

Note: Recurring events (that use FREQ > 0 and TIMES > 1) are really only scheduled once per day but they run multiple times on that day. They appear on the calendar as being scheduled only once.

You can specify a particular month and year or scroll through the calendar by entering NM for next month, PM for the previous month, or NY for next year, or PY for the previous year.


32

Zeke Occurs Hit Resolution BROWSE COMMAND ===> Primary Commands: BROWSE EDIT NMONTH PMONTH NYEAR PYEAR Month: 11 Year: 2000 Event: 01111 Ename: CRPDCDW1115D Calid: A MON TUE WED THU FRI SAT SUN 1 * 2 * 3 * 4 W 5 W 6 * 7 * 8 * 9 * 10 * 11 W 12 W 13 * 14 * 15 * 16 * 17 * 18 W 19 W 20 * 21 * 22 * 23 * 24 * 25 W 26 W 27 * 28 * 29 * 30 * 27 * Ver: 00000 Occurs: (WORKDAYS) W = Weekend H = Holiday S = Slack day * = Event scheduled on this date *X = Event scheduled x times on this date In this example we can see that this job is scheduled Monday to Friday during the month of November 2000 as indicated by the highlighted asterisks (*). From the previous OCCURS screen you can also display some interesting information (below) about when this job was previously scheduled by specifying the ACCTG command. For example, you can see the following: The last EMR update date, time and user The last three dispatch date/time The average duration, CPU time ZEKE tracks the average duration by adding the last 10 execution times and dividing by 10. If the job has not run yet 10 times, it is divided by the number of times it has run. If a job abends, it is still included in the average duration calculation.

Zeke Event Master Record Accounting BROWSE COMMAND ===> Z11 Primary Commands: BROWSE EDIT OCCHIT Evt: 01111 Type: JOB Job: DCCD115 Ename: CRPDCDW1115D DI.D1MX010 Sysid: B Dispatched 1386 Times Last Update: 30/09/1993 16:39 by BATCH Start: 20/11/1998 06:00 End: 20/11/1998 06:00 Job id: JOB07739 Version: 0 Sched Date: 20/11/1998 Status: SUCC Dispatch Date 20/11/1998 at 06:00 Tapes: 0 Vmem: 0 Dur: 00:00:15 Cputime: 00:00:01 Comp.code C0001 Dispatch Date 19/11/1998 at 06:00 Tapes: 0 Vmem: 0 Dur: 00:00:10 Cputime: 00:00:01 Comp.code C0001 Dispatch Date 18/11/1998 at 06:00 Tapes: 0 Vmem: 0 Dur: 00:00:15 Cputime: 00:00:01 Comp.code C0001 ------------- Avg: 00:00:18

From the previous OCCURS screen we can Page Down to the WHEN clause or specify the WHEN command. If there is no WHEN information, this screen is not displayed.


33

Zeke Event Master Record Function BROWSE COMMAND ===> Primary Commands: ADD BROWSE COPY DELETE EDIT WHEN Evt: 01111 Type: JOB Job: DCD115 Ename: CRPDCDW1115D Calid: A Ver: 00000 Platform: MVS When: (EOJ MX196)

In this example we can see that job DCD115 is not submitted for execution by ZEKE until after job MX196 has ended successfully (When: (EOJ MX196)).

Schedule Records

Scheduled Records differ from Event Master Records in that they are not permanent but are a one-time copy of the ZEKE scheduling information needed to run a job on a particular day. There are two ways to access this information and both are available by selecting option 2 (SCHEDULE VIEW/ZCOM) from the ZEKE Primary menu.

Schedule Information Selection Criteria 1 Schedule View Schedule Display and Modification Facility 2 ZCOM List Scheduling System Commands

Option 2 (ZCOM) allows you to issue ZEKE commands for a job or jobs (for example, ZD JOB ABC123 = ZEKE Display for Job ABC123), which is no longer the preferred or recommended method. Option 1 (Schedule View) is much more user-friendly and easier to use.


34

Schedule View

Option 1 (Schedule View) provides a more efficient front-end for working with scheduled records. As illustrated in the example below, you can select jobs based upon a number of factors. In this example we use a selection mask (Job Name is set to LA2*) to select all the jobs that are prefixed with LA2. You can also specify the event statuses you want to see. In this case we do not want to see events that are SUCC (so SUCC: is set to N).

Zeke Schedule Information Selection Criteria COMMAND ===> Z200000A 1 Schedule View Schedule Display and Modification Facility 2 ZCOM List Scheduling System Commands 3 ADD Function Select Event Master Records "to add" to schedule EVENT ===> Permanently save criteria ===> N Event Types Selection Field Masks ---- Event Status ---- Job: Job Name: ACTV: Y SUCC: Y Msg: Event Name: PEND: Y FLOK: Y Pcom: Application: NDSP: Y FAIL: Y Comm: Group Id: HOLD: Y F/OK: Y VCOM: USER ID: LATE: Y F/S: Y Zcom: System Id: / Operok: N Scom: Disp Class: Needs - Timeok: N %ACTV: Sched Date: \ Whenok: N Run Date: Send to: This selection gives us the following information about the LA2xx jobs that are currently scheduled and not SUCC.

Schedule View COMMAND ===> EVENT ===> System=A Selected=0000009 Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When cond ? to list other Line Command Line Event Sched Job Event Event Status Sched Cmd No. Date Name Name Reason Code Time ------------------------------------------------------------------ 00165 95270 LA200 INDLA.D1200 FAIL S806 20:00 00166 95270 LA210 INDLA.D1210 NDSP 20:00 00167 95270 LA220 INDLA.D1220 NDSP 20:00 00168 95270 LA230 INDLA.D1230 TOK NDSP 17:00 00169 95270 LA240 INDLA.D1240 TOK NDSP 17:00 00170 95270 LA250 INDLA.D1250 TOK NDSP 17:00 00171 95270 LA260 INDLA.D1260 TOK NDSP 17:00 00172 95270 LA270 INDLA.D1270 TOK NDSP 17:00 00173 95270 LA280 INDLA.D1280 TOK LATE NDSP 17:00


35

If the columns in the above example do not match your online displays, this is because these examples have been modified from the default setting. Refer to Customized Schedule View Settings at the end of this section for more information.

From this screen we can issue several Primary or Line commands (subject to your access authority).

Schedule View Primary Commands

BROWSE Set those fields that are editable back to browse. EMR Display the Event Record Selection Criteria screen. SORT Temporarily re-arranges the sequence of the fields based on the parameter selections (for

example, sort jobname, sort status, sort sched, sort late, etc.). Enter sort help for a list of sort parameters.

Schedule View Line Commands

? List all the Schedule View commands.

= Repeat the last command entered.

EMR Display the Event Master Record for this scheduled record.

PATH Pathfinder-Show scheduled record predecessor and successor events. PATH # controls the number of levels displayed.

PRED Pathfinder-Show scheduled record predecessor events.

SUCC Pathfinder-Show scheduled record successor events.

WHEN Display scheduled record WHEN conditions.

WHY Display scheduled record WAIT conditions.


36

When Would You Use These Commands?

If the WHEN command is issued against job LA200 ZEKE displays the current status of that jobs WHEN clause (if there is one).

Schedule View

COMMAND ===> EVENT ===> System=A Selected=0000009 Primary Commands: ADD AUTO BROWSE DOC EDIT EMR INT SELECT SORT WORK ? Line Commands: Del Delete Wh When cond ? to list other Line Command Line Event Sched Job Event Event Status Sched Cmd No. Date Name Name Reason Code Time ------------------------------------------------------------------ WHEN 00165 95270 LA200 INDLA.D1200 TOK NDSP 20:00 00166 95270 LA210 INDLA.D1210 NDSP 20:00 00167 95270 LA220 INDLA.D1220 NDSP 20:00 00168 95270 LA230 INDLA.D1230 TOK NDSP 17:00 00169 95270 LA240 INDLA.D1240 TOK NDSP 17:00 00170 95270 LA250 INDLA.D1250 TOK NDSP 17:00 00171 95270 LA260 INDLA.D1260 TOK NDSP 17:00 00172 95270 LA270 INDLA.D1270 TOK NDSP 17:00 00173 95270 LA280 INDLA.D1280 TOK LATE NDSP 17:00

In this particular case we can see that the LA190 dependency has been satisfied (as indicated by the asterisk (*) preceding EOJ LA190) but LA195 has still not completed successfully (because there is no asterisk (*)).

Zeke Schedule View OPTION ===> Event = 12579 Event name = Job name = LA200 When Vr = 00000 >>>>>>>>>>>>>>>>>>>>>>>>> WHEN Conditions >> English WHEN Conditions >>>>>>>>>>>> Event Status


37

In this case we can see that the Time and When dependencies for LA220 have not yet been satisfied.

When the PATH command is issued against a particular event, it shows the events that precede or follow that event. By default, PATH displays this information one level back. PATH2 displays two levels back, PATH9 displays up to nine levels and PATH* displays all levels of information. The example below shows the following:

What LA250 waits on (for example, what jobs precede it) What waits on LA250 (for example, what jobs succeed it) Z09AEI PREDECESSORS AND SUCCESSORS FOR THE REQUESTED EVENT: LVL JOB/EVT NAME TYPE EVENT DATE WHEN TRIGGER NAME STATUS AVDUR 5 LA200 JOB 00165 95270 - 05:23 4 LA210 JOB 00166 95270 EOJ LA200 03:45 3 LA220 JOB 00167 95270 EOJ LA210 04:00 2 LA230 JOB 00168 95270 EOJ LA220 T 02:12 >>1 LA240 JOB 00169 95270 EOJ LA230 T 12:03 ----------------------------------------------------------------- 0 LA250 JOB 00170 95270 EOJ LA240 23:10 ----------------------------------------------------------------- >>1 LA260 JOB 00171 95270 EOJ LA250 T 03:00 2 LA270 JOB 00172 95270 EOJ LA260 T 04:30 3 LA280 JOB 00173 95270 EOJ LA270 T 02:10 The EMR command displays the corresponding Event Master Record for the selected scheduled record. Subsequently issuing the EDIT command allows you to make a permanent change to the EMR (if authorized). If you want this change to the EMR to be reflected in the current day's scheduled record you must rebuild the scheduled record. This is done via the Rebuild line command (if authorized).

Online Event Status Codes

When you check on the status of a job through the Schedule View panels, you see that it has one of the following conditions.

Condition Description

blank The event has not been dispatched and submitted by ZEKE.

TOK The schedule time has been reached but the WHEN condition has not been satisfied.

WOK The WHEN condition has been satisfied but the Schedule time has not been reached.

NDSP The event has not been dispatched and submitted by ZEKE.

ACTV The conditions for the event have been satisfied and it has been submitted to run; however this does not necessarily mean the job is currently running.

PEND The event has been dispatched by ZEKE but has not completed or has had an error during conversion.

HOLD The event has been manually held so it is not submitted.

LATE The event has a LATE time specified and that time has been reached before the job was


38

dispatched.

SUCC The event has completed successfully.

FAIL The event has failed to complete successfully.

FLOK The event has abended, been resubmitted, and completed successfully.

F/OK The event has abended and been forced to End of Job.

F/S The event was not dispatched but has been forced to End of Job.

DSBL The event has been disabled and is dropped from the schedule.

Dispatch JCL Error PJSUB had a problem submitting the job. Verify that the jobname on the Job card and ZEKE EMR matches the member name of the job. A non-deletable message should be written to the console and relayed to the applications support team.

Customized Schedule View Settings

Columns Displayed

The default setting is to display all information (columns) available, which means you have to scroll left and right a lot. If you want to reduce this to the most meaningful information, return to the ZEKE Primary menu and select option CCONTROL and then option 2. Specify a 0 for the fields you do not want to display and a sequence number for the remaining fields. The examples in this section use the following selections.

Zeke Schedule View Display Setup COMMAND ===> Title line: Field 1 : Event Number Field 2 : Schedule Date * Field 6 : Job Name Field 0 : Event Type Field 0 : Event Name Field 9 : Status/Reason Code Field 0 : DP (Dispatch Priority) Field 4 : Schedule Time Field 5 : Late Dispatch Time Field 0 : System Identification Field 3 : Run Date * Field 12 : Freq (dispatch interval) Field 14 : CNT (number of times) Field 10 : Status Time Field 0 : Early dispatch Time Field 0 : Must end Time Field 0 : Not after Time Field 0 : User Identification Field 0 : Application Identifn Field 0 : Group Identification Field 0 : Dispatching Classes Field 0 : No. of Tapes required Field 0 : Virtual memory required Field 0 : Average Duration Field 25 : Job Number Field 0 : Sendto designation Field 0 : Version Number Field 13 : Frequency Calc Field 0 : Trigger Type * DATE FORMAT YYYYDDD Enter the desired title line display sequence by specifying the numbering order.


39

Sort Default

If you want to have a default sort performed on your Schedule View display, select option 3 from the CONTROL option. Select one or two of the following fields for your default sort sequence. The examples in this section use the following choicesJO (jobname) and STA (event status.reason c

Documents

ZEKE Reference Manual