Conceptual Overview

This chapter includes the following topics:

Introduction

This conceptual overview is intended for production control personnel who are familiar with ZEKE terminology. Experience with Control-M is recommended, but not required.

The conversion tool supports ZEKE on the z/OS and distributed (such as UNIX and WINDOWS) operating system platforms. In addition, OASIS SERVER/CLIENT distributed jobs are also supported. Users running ZEKE on a DOS/VSE operating system platform can also use this conversion tool to convert to Control-M on a z/OS platform, provided the ZEKE JCL libraries are moved to a z/OS platform and converted to z/OS format.

The ZEKE to Control-M conversion tool is provided by BMC to assist in the creation of the primary product elements for Control-M. It is designed to expedite the conversion process by automatically translating the most commonly built ZEKE scheduling elements into functionally equivalent processes in Control-M. For more information on the ZEKE conversion tool, see Control-M ZEKE Conversion Tool.

The primary scheduling units in ZEKE are system and work center events (COMM and WORK).

An event is a ZEKE action that takes place under a set of circumstances. A ZEKE batch utility or online system adds Event Master Records (EMRs) to the ZEKE Catalog.

Under ZEKE, defining a production application is a process that requires the use of numerous definition screens. Through the Event Master Record Functions Menu (/EVENT Option), the user selects from commands that add events and perform maintenance for existing events. The user must then navigate through many separate screens to ADD an EMR, UPDATE an EMR, BROWSE EMRs, DOCUMENT events, and so on.

Under Control-M and Control-O, all comparable definitions are handled via the Job Scheduling Definition screen (Screen 2), the IOA Conditions/Resources facility (screen 4), the IOA Calendar facility (Screen 8), the Control-O Rule Definition facility (screen OR), and Control-M/Enterprise Manager (Control-M/EM).

Each component of the ZEKE event definition is discussed on the following pages in relation to the management of corresponding components under Control-M.

Event and Job Definition

In ZEKE, event definition is performed using the Event Master Record Function Menu. Information relevant to a specific event, such as job name, user ID, or group name, is specified in this and associated screens. Each event definition is stored as a separate entity in the ZEKE catalog.

A ZEKE event may contain multiple jobs and, conversely, the same job may be contained in different events.

In Control-M, the basic scheduling unit is the job scheduling definition. Job scheduling definitions are defined using the Job Scheduling Definition screen, and are stored in partitioned data sets called table libraries. Application job grouping is performed by defining all related jobs in one table. The table naming standard is established by the GROUPBY conversion parameter, described in "GROUPBY" in Conversion Parameters and by EOG (End of Group) processing described in Job Dependencies. When the user’s data contains WHEN clauses specifying the EOG or WEOG keywords then SMART scheduling tables are created to contain all jobs whose event names match any of the (W)EOG grouping criteria. The SMART table names are determined by the (generic) event name specified in the (W)EOG clause by default unless otherwise changed by the user following JOB0A.

The ZEKE job name is used for the Control-M MEMNAME parameter. For ZEKE events that do not have job names, see 1. EVENT NUMBR for how the Control-M MEMNAME is formed.

The same job name may appear more than once in one Control-M table or several tables if the job is defined multiple times in the ZEKE catalog.

Job Dependencies

In ZEKE, job and event dependency is controlled by means of the WHEN clause. Prerequisite conditions can be specified by various criteria including

  • end of job, job step or event

  • abnormal end of job, job step or event

  • weak end of job or event

  • beginning of job or event

  • close of an output data set

  • (weak) end of group (event name/ mask)

  • cross platform (remote) dependencies

In Control-M, job execution sequence is controlled by means of prerequisite conditions. A prerequisite condition is a descriptive name given to a certain situation, event, or condition. The prerequisite condition is the basic mechanism used by Control-M to control job execution flow. In Control-M prerequisite condition terminology, an IN condition is specified for a job when the job must wait for the occurrence of an event. A condition may be added to the IOA Conditions file when an event such as job completion occurs. Conditions can be added or deleted after successful or unsuccessful job completion, based on user specification, through the OUT or ON PGMST clauses in the job scheduling definition. For more information about prerequisite condition concepts, see the Control-M for z/OS User Guide.

The conversion tool automatically converts ZEKE job dependencies into IN or OUT prerequisite condition definitions to establish the same schedule tree structure. In some cases, such as the beginning of a job or the close of a data set or for non-existent jobs in the Zeke database, the Control-O Rule Definition facility is necessary to post conditions for JOBARRIVAL, DSNEVENT, ON STEP and JOBEND events. For more information and details, see Table 11 in Component Conversion Summary.

For Zeke (W)EOG events job dependencies are established as follows: For every (W)EOG event specified in Zeke WHEN clauses, the event name (or generic/masked event name) is used to create a Control-M SMART table – see JOB1: Create the EOG Table List File for details. Any job/event whose event name matches, using any applicable mask requirements, one of these table names is placed into that SMART table. The SMART table-entity is created with two OUT conditions:

These conditions will be added to the IOA Conditions file only when all the jobs in the table have successfully ended. Any job with an (W)EOG dependency will be created with one of the above as an IN condition establishing the triggering relationship to the desired group.

Cross platform dependencies on remote systems are specified in Zeke WHEN clauses as ‘(A)EOJ triggering-jobname AT remote-system-id’. When the conversion tool encounters such a dependency in a job, it obtains from the REMOTEID file (see JOB2: Create Libraries, Including the Control-O Rules Library for details) the corresponding condition name prefix for the specified remote-system-id in order to create an IN condition for the job establishing the proper job flow. It is the user’s responsibility to create a corresponding OUT condition in the triggering job definition on the remote system.

For more information and details, see Table 6 in Component Conversion Summary.

Scheduling

In ZEKE, scheduling information, such as every day, or once a month, is specified using the OCCURS clause. The OCCURS clause consists of a keyword vocabulary of reserved words, which is used together with a calendar mechanism to determine when to select an event for execution. The ZEKE OCCURS clause keywords are converted to Control-M Basic Scheduling parameters.

Calendars

Every ZEKE event is associated with a ZEKE calendar. When the ZEKE schedule function runs, it uses the calendar of the event to determine the workdays, holidays, and the meaning of the OCCURS clause.

Three types of ZEKE calendars exist:

  • Standard, which defines workdays and holidays

  • User Accounting, which defines workdays and holidays within accounting periods

  • Special, which defines the exact days an event is to run

All of these ZEKE calendars are converted from the ZEKE LIST CALID * report to Control-M standard calendars using the ZEKE calendar name. All Zeke calendars referred to in the Zeke LIST EVENTS report must be defined in the CALID report.

The conversion tool creates additional calendars when necessary, using the following naming conventions:

Table 1 Calendar Naming Conventions on Conversion

Name

Description

$WEEKnnn

A weekend calendar for each ZEKE Standard and User Accounting Calendar

$HLWKnnn

A calendar containing holidays and weekends for each ZEKE Standard and User Accounting calendar

$HOLInnn

A calendar containing holidays for each ZEKE Standard and User Accounting calendar

@HOLInnn

A calendar containing "not holiday" days for each ZEKE Standard and User Accounting Calendar

@WEEKnnn

A calendar containing "not weekends" days for each ZEKE Standard and User Accounting Calendar

RFxnnnnn

A calendar name created for each REFEVENT OCCURS clause specified in the ZEKE LIST EVENTS reports when CAL is specified for the REFEVT conversion option. For more information, see Conversion Parameters.

CALnnnnn

Calendars created when combinations of any of the above calendars are required.

User Accounting Calendars are not converted to Control-M periodic calendars.

User Documentation

The ZEKE LIST EVENTS LISTDOC report lists all event documentation and produces a report containing all the information that would be contained in reports produced using the ZEKE commands LISTNOTE, LISTDSN, LISTTEXT, LISTPAD, and so on.

The conversion tool copies ZEKE user documentation (from the LIST EVENTS LISTDOC report) into the corresponding Control-M Job scheduling definition as (multiple) lines of the DESC parameter (up to a maximum of 57 lines). Comments contained as text in ZEKE COMM and WORK events are copied into the Control-M documentation library. In such cases, the member names have the format: xxnnnnnn where xx is CO and nnnnnn is the ZEKE event number (with zero padding if necessary). For more information, see 32. COMM and WORK.

Control-O Rule Definition Facility

In ZEKE, events such as the close of an output data set, the beginning of a job, the end of a job step, or a job step’s condition code, can be used to indicate job dependency or to terminate (cancel) the execution of a job. This is done using the ZEKE DSN, BOJ, and (A)EOS WHEN clause keywords and the Condition Code Validation feature.

The corresponding facility is the Control-O Rule Definition facility, which manages external events. Control-O performs predefined actions in response to the occurrence of events in the system. The ZEKE DSN, BOJ, and (A)EOS OCCURS keywords are equivalent to the DSNEVENT, JOBARRIVAL, and ON STEP events in Control-O, which add prerequisite conditions to the IOA Conditions file. ZEKE Condition Code Validation C (Cancel) actions are equivalent to ON STEP DO STOPJOB events in Control-O. In addition, JOBEND events in Control-O can be created for jobs which are externally submitted (See the conversion option JOBMANL in Conversion Parameters for further information). Zeke EOJ events, which do not exist in the Zeke database, are treated as external events by creating ON JOBEND rules in Control-O.

For details on the exact conversion process, see the subsections for DSN, BOJ, EOS, and AEOS in 22. WHEN, and 24. COND CODE. For more information about the Control-O Rule Definition facility, see the Control-O User Guide.

Resource Control

ZEKE Resource Control serializes the use of critical resources by event. In Control-M, this type of resource management is implemented by defining either Control Resources or Quantitative Resources in the job scheduling definition, depending on the attributes of the ZEKE resource. For more information, see 21. RESOURCE.

Production Control

The following paragraphs discuss aspects of ZEKE production control in relation to their management under Control-M.

SAC is supported only on the mainframe platform, and not on distributed platforms. Therefore, the discussion below of the SAC parameter applies only to jobs defined on the mainframe platform. For each distributed job, the conversion process issues a message (BLT895I), indicating that the required SAC functionality is not supported. If you are a new Control-M customer and this message appears many times, consider setting the Control-M New Day time to midnight and rerunning the conversion, to eliminate all occurrences of the message.

The 48-hour Clock and New Day Processing

Control-M production jobs are scheduled using New Day processing, performed once each day at a predefined time, according to your local site requirements. Control-M, using New Day processing, presumes that workdays do not always begin at the start of a calendar day. Instead, Control-M enables you to define a logical workday that begins at a specified time. Other scheduling products, such as ZEKE, begin every workday at the first moment of a new calendar day. The Control-M ZEKE conversion tool is designed to convert ZEKE scheduling data so it can be used in Control-M scheduling.

In addition to standard midnight-to-midnight 24-hour scheduling, ZEKE also supports a 48-hour clock that begins at midnight and continues for two full calendar days, so that shifts that run past midnight can still be considered to be part of the work of the previous day. An event can be scheduled for any 48-hour period within this range. For example, an event scheduled for 28:00 on Monday is actually processed as if it was an event defined as OCCURS (TUESDAY) at 4:00 AM.

Control-M enables you to define logical workdays that begin at a time best suited to the scheduling requirements of your organization, without being subject to the limits that might be imposed by strict adherence to calendar days.

All events that depend on a 48-hour clock, that is, whose scheduled or late times, for example exceed 24:00, are first converted to a 24-hour clock framework by subtracting 24 hours from the time in question. Depending on the Control-M New Day time, a Control-M DAYS offset of +001 may be specified. This allows the event to be ordered according to its scheduling criteria (as specified in the ZEKE definition) on the proper Control-M working day. This simplifies situations which must be considered for the following examples, since all times are now in the 0-24 hour range.

Figure 1 New Day Processing Example 1

The above example assumes that your logical business date changes at 8:00 A.M. You want to take a job scheduled in ZEKE to begin at 2800 hours (4:00 A.M. on March 15th), and convert it to be run as a Control-M job. The conversion tool converts this ZEKE job to a Control-M job that begins at 4:00 A.M. on the March 14th logical business day.

Because 4:00 A.M. precedes the Control-M New Day time, a DAYS offset of +001 is NOT added to job's FROM TIME definition.

Figure 2 New Day Processing Example 2

A ZEKE event is scheduled at 0400 hours on the March 14th 48-hour clock, but this point is before the Control-M March 14th logical business day begins. The conversion tool sets the Control-M SAC parameter to P (previous). This ensures that the Control-M job is scheduled at 4:00 A.M. on the March 13th logical business day.

Figure 3 New Day Processing Example 3

A ZEKE event is scheduled at 4000 hours on the March 14th 48-hour clock, but this point is after the Control-M March 14th logical business day ends. The conversion sets the Control-M FROM TIME days offset to +001. This adjusts the Control-M schedule time forward by 24 hours, and ensures that the Control-M job is scheduled at 4:00 P.M. on the March 15th logical business day.

For more information about the Control-M SAC parameter, see the Control-M User Guide and the Control-M Parameter Guide.

All other ZEKE time criteria (EARLY TIME, LATE TIME, MUST END, NOT AFTER) are handled similarly.

JCL Considerations

ZEKE provides facilities to control job stream flow, obtain job related data at run time, test and save this data, assist in abend recovery, interact with user programs and with event scheduling and triggering, and execute MVS and JES commands using ZEKE JCL variables and the ZEKESET program.

The ZEKESET program is converted to CTMZSET, a program that invokes the IOACND, IOAAPI, and IOATEST IOA utilities and the CTMRELRS and CTMAPI Control-M utilities, which perform many of the parallel functions available in ZEKESET. For more information, see CTMZSET: Invoke IOATEST, IOAAPI, IOACND, CTMRELRS, and CTMAPI Services.

ZEKE Variables

ZEKE variables may be used to define job scheduling criteria and prerequisite conditions, and to control job flow in JCL run streams, as described in 25. $ VARIABLES. Because of these varied uses for ZEKE variables, the conversion tool treats them differently, depending on the context in which they are found.

When ZEKE variables are used to define job scheduling criteria and prerequisite conditions, the conversion tool converts them to Control-M IN conditions and SET VAR parameters to perform Control-M job triggering functions. When ZEKE variables are used to control job flow and to change or add variable values, the conversion tool converts them to Control-M AutoEdit variables to perform similar functions.

Since ZEKE variables can be used to communicate between jobs, the Conversion tool converts them to IOA Global Variables, which likewise enables inter-job communication for Control-M controlled jobs. For this facility to be operative, Control-O must be active on the applicable system.

The formats into which the conversion program converts the ZEKE variables varies depending on their origin as described in the following table.

Table 2 ZEKE variable formats

Origin

Converted Format

JCL runstream

AutoEdit %%SET %%\M\NO_APPL\NO_GROUP\NO_MEM\varName = varValue

Control-M job scheduling definitions

SET VAR statements

IN/OUT Conditions

Creation and initialization of ZEKE variables from the ZEKE variable report

Control statements of the CTMAPI utility using SET GLOBAL commands

ZEKE variables may be converted in stages, meaning that the conversion may form intermediary AutoEdit variables with the format %%n (n=0, 1, 2, …) before forming the final AutoEdit variable expression. For example, the ZEKE expression in a ZEKESET JCL step

Copy 
SET VAR $A EQ $B + $C IF $X EQ 'SPLIT VAL'

is converted as follows:

Copy 
 %%SET %%0 = %%\M\NO_APPL\NO_GROUP\NO_MEM\A
 %%SET %%1 = %%\M\NO_APPL\NO_GROUP\NO_MEM\B
 %%SET %%2 = %%\M\NO_APPL\NO_GROUP\NO_MEM\C
 %%SET %%3 = %%\M\NO_APPL\NO_GROUP\NO_MEM\X
 %%SET %%4 = SPLIT%%BLANK1%%.VAL
 %%IF  %%3 = %%4
    %%SET  %%0 = %%1 %%PLUS %%2
    %%SET  %%\M\NO_APPL\NO_GROUP\NO_MEM\A = %%0
 %%ENDIF

Note that the variables are converted as being non-related to any particular application (NO_APPL), group (NO_GROUP), or member (NO_MEM).

The conversion provides only limited support for Zeke Oasis Variables. For details, see 51. Oasis Variables.

Command and Message Events

ZEKE uses ZCOM, SCOM, and MSG events to schedule ZEKE commands, system commands, and messages issued to the system operator.

The conversion tool converts ZCOM and SCOM events by creating in-stream JCL in the corresponding job definitions to perform the functionally equivalent Control-M task. To perform these functions, the following utilities are used:

MSG events are converted to Control-M SHOUT parameters in dummy job scheduling definitions. For more information, see 33. MSG.

When SCOM or ZCOM events in the Zeke Commands file generate more than 50 lines of JCL, the conversion creates a JCL member in the CTM DAJCL library, instead of creating the JCL In-stream in the job definition.

The DAJCL library must be specified in the DALIB concatenation of the CTM monitor and on-line procedures.

Recurring events and cyclic jobs

ZEKE recurring events are events scheduled to occur more than once in each schedule period, and are defined using the following parameters:

  • TIMES – specifies the number of times a day the event is to be dispatched

  • FREQUENCY – establishes the amount of time that must elapse between dispatches

Recurring events are dispatched first at the normal SCHEDULE time, or early time if one is defined, and next dispatched after the FREQUENCY time has elapsed.

The conversion tool converts ZEKE recurring events into Control-M cyclic jobs as follows:

  • When the ZEKE dispatch FREQUENCY parameter is specified,

    • the Control-M MAXRERUN parameter is set to the Zeke TIMES parameter

    • the TASKTYPE parameter is set to CYC

    •  

      the MAXWAIT parameter is set to the Control-M default value of MAXWAIT (see WM2367 in member IOADFLT in the IOA IOAENV library)

  • The ZEKE dispatch FREQUENCY is converted to minutes and used to set the Control-M INTERVAL parameter, which specifies the number of minutes to wait between cyclic reruns.

Jobs on Distributed Platforms

Zeke supports jobs running on non-z/OS platforms by defining a non-MVS platform (such as UNIX and WINDOWS) in the job definition or by using the Universal Command facility.

The Control-M conversion tool supports Zeke JCL members specifying that a distributed job must be submitted when the job's JCL member executes the Universal Command procedure or program, as specified by the UCMDNM conversion option. These JCL members contain information which specify the host (Node ID) on which the job must be run, the script(s) to be executed, and the LOGON or Owner in the distributed environment. Such parameters have no counterpart in Control-M mainframe job definitions.

Since the conversion tool is run on the mainframe platform, these parameters are initially converted to SETVAR definitions. The parameters are then post-processed by the Control-M CTMTLB utility, which creates XML job definitions for uploading to the distributed platform. The SETVAR statements are then transformed to appropriate XML parameters supported on the distributed platform (such as NODEID and Embedded Script). See details below.

When a Zeke job definition specifies a non-MVS platform, the conversion tool directly converts the contents of the JCL member (specified in the job definition) to an Embedded Script using the SETVAR statements.

Distributed jobs are also supported via the OASIS Client/Server feature which allows Zeke to communicate with other ZEKEs running on different systems or platforms, as well as enabling cross-platform scheduling using Zeke Agents for NT, OS/400, and UNIX, for example. When the Zeke TARGET field is specified, it is converted to the Control-M NODEID parameter.

For distributed job definitions, the following Control-M statements/parameters are not created:

  • DO IFRERUN

  • DO SYSOUT=C

The conversion tool does not currently support distributed file triggering.

Universal Command Support

The Universal Command program is supported in JCL by creating distributed job definitions with embedded script parameters, using the SYSIN, Script and Logon DD statements in the job's JCL member.

The Universal procedure or program name is specified in the UCMDNM option.

The SYSIN file contains the following information:

  • The DDname of the script file.

  • The host (Node ID) specified by either the -i or -host switch.

  • The DDname of the logon file (containing userid/owner).

The script file contains the text of the commands that is placed in the Control-M Embedded Script statement.

The host name is placed in the Control-M NodeID field.

The member name of the logon PDS file is set to the Control-M OWNER parameter (see "OWNER" in Conversion Parameters for further details).

Multiple Universal Command steps within a single job are supported (i.e., all the script lines are concatenated together) as long as the logon member name and host name specified in the different steps are the same.

As part of the above support, a file that provides a DSN translation table for the production JCL libraries when a job's JCL members refer to Universal Command scripts is built for use by JOB2 with a suffix name Z2M.DSNXLT. The format of each file entry is:

  • Col 1: DSN of production SYSIN/script library.

  • Col 45: DSN of corresponding copied SYSIN/script library (max 36 characters).

  • Col 72–80: must not contain TSO line numbers.

Control-M ZEKE Conversion Tool

The conversion consists of a sequence of tasks performed via the BMC ICE facility. Although these tasks are independent of ZEKE and Control-M, Control-M must be installed in order to perform the conversion.

The conversion does the following:

  • Builds the Control-M tables and definitions, based on the ZEKE LIST EVENTS report.

  • Builds all necessary Control-M calendars, based on the ZEKE LIST CALID * report.

  • Builds Control-O rules library definitions for various job events.

  • Builds a JCL library from the ZEKE JCL stored on the ZEKE database (LISTJCL report).

  • Converts ZEKE JCL variables and ZEKESET steps to Control-M/IOA Global Variable format.

  • Creates JCL members for SCOM, ZCOM, COMM, and WORK-type events.

  • Enables customers to automatically set unique Control-M options in the resulting Control-M tables.

  • Provides a set of independent utilities that can be very useful during and after the conversion process.

  • Issues messages if problems and errors are encountered in the ZEKE definitions.

The conversion tool is delivered in source and load module format and does not require compiling/assembling of source code.