Zeke

You might also like

Download as doc, pdf, or txt
Download as doc, pdf, or txt
You are on page 1of 25

Zeke

Zeke is a scheduling system that automates the production control process by Scheduling and
dispatching events.

To create the daily schedule of events, Zeke schedule functions uses the information from the Event
Master Records (EMR).

The schedule function typically runs at the start of the each workday, removes the previous day
completed events and adds current day schedule events. Zeke adds an event to the schedule if the
scheduling criteria are met or if an operator enters a request to add an event.

Note: An operator can easily adjust the schedule through Schedule View or by issuing an operator
command from the console.

E.g.: ZADD EV **** (****= Event number)

Event Master Record (EMR):

To define an event to Zeke database we need to create EMR. This is where event type is established with
scheduling and dispatching criteria.

Schedule Queue Records (SQR):

It controls the Zeke schedule and dispatching functions. The SQR’s are created by Zeke Schedule function
to run the Schedule function once a day.
Jobs can be scheduled in Zeke in 24 hrs. 48 hrs and 72 hrs format. Incase if we follow 48 hrs format and if
the schedule starts @ 07:00 AM, the day ends at 07:00 AM of the next day, but the Zeke day ends after
next 24 hrs. The next 24 hrs is considered as the Logical day in Zeke.

Suppose a job is scheduled to run on 3200 hrs, and the schedule loads on Thursday. It means job actually
runs @ 0800 hrs on Friday.

EVENT:

Jobs that are scheduled to run through Zeke are called as Events. Each Event in Zeke has a unique
number called as EVENT NUMBER (Evt).

Event Dispatching Process:

Zeke monitors system activities to detect any circumstances or action that will trigger an Event. When a
Job’s schedule time is reached and its prerequisites known as WHEN conditions have satisfied, job is
placed in dispatch queue.

EVENT TYPES:

System and Work Events

Job OS/390 or VSE Job stream


ZCOM Zeke Operator Command
VCOM VM/370 or VM/SP CP Command
MSG Console Operator Message
SCOM System commands include Z/OS, OS/390, DOS, JES,CICS,VTAM Commands
WORK They are required only when manual intervention is required before a job can run
PCOM Power Command Event

ZCOM Option:

From the system console of ZCOM option, you can enter most of the Zeke operator commands.

Zeke Commands:

ZADD To add an event to today’s schedule


ZDELETE TO delete an event from today’s schedule
ZDISABLE To disable an event
ZENABLE To enable an event
ZHOLD To hold an event
ZRELEASE To release an event
ZADD To add an event to today’s Schedule
Ex: ZADD ev 777

ZDELETE To delete an event from today’s Schedule


Ex: ZDELETE ev 777

ZDISABLE To disable an event


Ex: ZDISABLE ev 777

ZENABLE To enable an event


Ex: ZENABLE ev 777

ZHOLD To HOLD an event


Ex: ZHOLD ev 777

ZRELEASE To RELEASE an event


Ex: ZRELESASE ev 777

ZOK To give OK an event


Ex: ZOK ev 777

ZSET To set a Zeke Variables


Ex: ZSET VAR $CL01P043STEP EQ CLSTP2

ZALTER

Extended WHEN conditions can also be manually satisfied using the ZALTER
WHENOK operator command.

Ex: ZALTER JOB 1 WHENOK (EOJ JOBB AT SYSB)

Work Events:

WorkCentre Events are the tasks that require manual intervention. For example, events that require any
of the following:

 User input, such as dates


 User Approval
 Completion of manual tasks, such as data entry.

CALENDAR TYPES:
 Standard

 Special

 User Accounting

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.

Standard Calendars

Standard calendars define the normal workdays and holidays and indicate the first month of the fiscal
year for your company. Most events are associated with a standard calendar. 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.

Special Calendars

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

Calendar Attributes

 Calendar names are up to 8 characters in length.

 A specific year or a generic year (****) is specified with each calendar.

 Calendars have a start date and an expiration date.

Variable Condition:

Satisfied when the specified Zeke variable is the specified value. This is the most flexible means of
triggering because there are no date or time boundaries.

PRIMARY COMMANDS IN ZEKE:


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

Display Display event information.

DOCument Define or maintain event documentation.

JCL Display JCL stored in the Zeke database.

OCCWhn Maintain the OCCURS clause and WHEN condition for the event. To maintain the WHEN
condition for a particular version of the event, enter the version number in the
appropriate field. If you do not enter a version number, it defaults to first version.

REACt Reactivate an EMR that was previously deactivated.

RESOurce Maintain logical resource control information for job events.

Update Edit event information.


Command Description
ACCTG Displays the Accounting information of the Events

OCCHIT Displays the Occurrence of the Events

LINE COMMANDS SUMMARY:


ADDOK Set "need operator OK"

ALTer Apply same changes to tagged

DEL Delete

DIS Disable

DSN ASG-Zebb Step/DD Level Info

EMR Display EMR for the SQR

EN Enable

FDEL Delete with acquired resources

FDONE Force to DONE status

FFAIL Force to FAILED status

FREB Rebuild with acquired resources

FREF Refresh with acquired resources

FSUCC Force to SUCCESS status

Hold Hold

JCLR Retrieve JCL

JPREP Invoke ASG-JCLPREP to scan JCL

LDSN ASG-Zebb List DSN Detail Info

NOTE Display note text (if any)

OK Set "operator OK"

PATH Pathfinder-Show pred/succ

PRED Pathfinder-Show predecessors

REB Rebuild
REBH Rebuild and HOLD

REF Refresh

REL Release

RESO Display resources required

RSTRT ASG-Zebb Job Restart Management

RUN Satisfy conditions

SCAN Scan the JCL

SUCC Pathfinder-Show successors

SYS_ Browse: L job log J JCL M sysmsg

TOK Set "time OK"

WHen Display "WHEN" conditions

WHY Display "WAIT" conditions

WOK Set "WHEN OK"

WORK Invoke Work Center (Option 5)

ZEBB ASG-Zebb Job Functions Menu

ZOom Display info in one screen

WHEN Conditions:
WHEN conditions specify the conditions that must occur before an event can be dispatched. An Event
with WHEN condition is not dispatched by Zeke until the WHEN conditions are satisfied. A WHEN
condition is also known as DEPENDENCY.

WHEN conditions may be 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

 A Dataset

Relational Operators can be used in WHEN Conditions.

Relational Operators

EQ Equal
NE Not Equal
LE Less than or Equal
GE Greater than or Equal
LT Less than
GT Greater than

Zeke can trigger a job based on any combination of WHEN conditions, such as:

 Normal or abnormal end of an event/job, a group of events/jobs, a JCL job step or a program.

 Beginning of a JCL job or Program.

 Close of an output non-VSAM dataset.

 Current execution of a JCL job or a Program

 Availability of variables or resources

Multiple WHEN Conditions:

An Event can have more than one WHEN conditions (Dependencies).


This example can shows two WHEN conditions joined with the word OR. The keyword OR indicates the
event is satisfied when either one clause id satisfied.

WHEN (EOJ ABC OR EOJ XYZ)

The Keyword AND indicated that the event can be dispatched only when both the WHEN Conditions are
satisfied.

WHEN (EOJ XYZ AND EOJ ABC)

WEAK Conditions:

WEAK Condition 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 (bypass) the condition.

E.g.: WHEN (WEOJ JOB ABC)

Zeke Variables as WHEN Conditions:

To 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 (EOJ JOBY and VAR $LASTMONTH EQ ‘GOOD’)

NOTDURING Condition:

A 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. It
is also known as Negative Dependency for a Job.

WHEN Condition Keywords:


EMR Parameters:
Template

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

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

Permanent

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.

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

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

Platform

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 (see note below)
TANDEM
USYS
UNIX (includes AIX, AT&T, HPUX, NCR, SCO, SunOS, Sun Solaris, etc.)
VMS
VSE
WINDOWS (includes all supported versions)

Event Number (Evt): Unique number for an Event

Description (Decs)

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 and
AEOG) WHEN conditions and operator commands use the event name.

Application (App)

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


Group (Grp)

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

User Id (Usrid)

Identifies the person who is responsible for the event.

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.

Calendar (Cal)

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

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.

Retain (Retain)

Specifies whether to retain incomplete events.

Code Meaning

Y (Default.) Retain work centers until completed or disabled

N Discard work centers the next day, regardless of status

NWDAY Field/Nonwkday

The NWDAY field in the event’s EMR specifies whether to schedule after, before, or on a holiday (or not
at all). However, when you specify a holiday or weekend in the OCCURS clause, it overrides the NWDAY
field in the EMR.

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


Multiple Entries (Multhit)

Specifies whether an event is scheduled multiple times when there is a nonworkday.

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

Target

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.

Verload

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

Early Time (Early)

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.

Scheduled Time (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.

Late Time (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.

Must end Time (Mustend)

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.
Not After (Notafter)

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.

Dispatching Priority (Dprty)

Specifies the default dispatch priority on the EMR.

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.

Need Operator Ok (Operok)

Specifies whether Zeke is to wait for an operator OK before dispatching any event.

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

Frequency (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.

Frequency Calculation (Freqcalc)

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.

Triggers (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.

Control

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

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.

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 for execution. After dispatch, the event status automatically changes to indicate
success and any dependent events are triggered.

Class (Class)

Up to six classes for the event. When the event is ready to run, Zeke selects a partition 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.

Job (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 job name on the job card for proper tracking.

Priority (Pri)

Defjprty field, enter a default job system priority (between 1 and 15) to use if a priority is not entered on
the Pri field in the EMR. The default is 01.
OCCURS Clause

Syntax: OCCURS (keyword AND|OR keyword)

OCCURS Keywords

You might also like