Conceptual Overview

This chapter includes the following topics:

• Overview of Conversion Details

• Schedule Definition

• Job Definition

• Job Dependencies

• Scheduling

• Control-M New Day Processing

• User Documentation

• Message Definition

• Job Resources

• CA-DRIVER Procedures and JCL Libraries

• Control-O Rule Definition Facility

• Jobs on Distributed Platforms

• Control-M CA-SCHEDULER Conversion Tool

Overview of Conversion Details

The conversion tool converts CA-SCHEDULER parameter definitions, which correspond to fields in CA-SCHEDULER screens, into Control-M job scheduling definition parameters, corresponding to the fields in the Control-M Job Scheduling Definition screen, and to Control-O rules corresponding to criteria that trigger performance of these rules. In addition, CA-DRIVER procedure definitions are converted to Control-M AutoEdit statements.

Introduction

This conceptual overview is intended for production control personnel who are familiar with CA-SCHEDULER terminology. Experience with Control-M is recommended. If your CA-Scheduler schedule/job definitions contain distributed job definitions (for example, UNIX, AIX, NT Windows), experience with Control-M/Enterprise Manager and Control-M is also recommended.

The CA-SCHEDULER to Control-M conversion tool is provided by BMC to assist in the creation of the primary product elements for Control-M and Control-M. It is designed to expedite the conversion process by automatically translating the most commonly built CA-SCHEDULER scheduling elements into functionally equivalent processes in the above INCONTROL family of products. The primary conversion units are the CA-SCHEDULER schedule definition and the Control-M SMART Table. A brief overview of these units is provided on the following pages. The logic used by the conversion tool to create Control-M SMART Tables from CA-SCHEDULER schedule definitions is also provided. For more information on the CA-SCHEDULER conversion tool, see Control-M CA-SCHEDULER Conversion Tool.

In CA-SCHEDULER, defining a schedule is a process that requires the use of the definition screens shown in the following table:

Table 1 CA-SCHEDULER Definition Screens

Under Control-M and Control-O, all comparable definitions are handled using the following screens:

• Job Scheduling Definition screen (screen 2)

• IOA Conditions screen (screen 4)

• IOA Calendar facility (screen 8)

• Control-O Rule Definition facility (screen OR)

• (For distributed jobs) Control-M

In this chapter, each of the components of the CA-SCHEDULER schedule definition is discussed in relation to the management of the corresponding components under Control-M.

Schedule Definition

In CA-SCHEDULER, schedules are defined using the Schedule Definition screen and its associated screens. Information relevant to a specific schedule, such as input attributes, priority, early start time, and scheduling parameters, is specified in this screen. All definitions made through the Schedule Definition screen apply to all jobs in the schedule.

The conversion tool converts each CA-SCHEDULER schedule definition into a Control-M SMART Table in which all the jobs in the schedule are defined.

In Control-M, related scheduling definitions are stored in PDS libraries as members called tables. Each table contains one or more related jobs. The number of table libraries that can be used at a site is unlimited. This feature of Control-M enables you to decentralize your production control.

The CA-SCHEDULER schedule definition is converted to a Control-M SMART Table Entity and the CA-SCHEDULER job definitions are converted to Control-M job scheduling definitions.

Job Definition

In CA-SCHEDULER, jobs are defined using the Job Definition screen and its associated screens. Information relevant to a specific job, such as job number, JCL member name, and CPU ID, is specified in this screen. Each job definition is stored as a separate entity in the CA-SCHEDULER database.

In CA-SCHEDULER, a job is uniquely identified by the following values:

• Job name

• Job number (default value 01)

• Workstation number (default value 40)

• Schedule name

In CA-SCHEDULER, a job definition may specify a JCL member name that differs from the name of the job. CA-SCHEDULER forces the submitted job name to match the name of the defined job.

In Control-M, job control is independent of the job name in the JCL JOB statement. Control-M controls the job through the JCL member name, which is specified in the MEMNAME parameter of the Control-M job scheduling definition.

The conversion tool uses the CA-SCHEDULER job name for the Control-M MEMNAME parameter. For details of what happens when a CA-SCHEDULER job name differs from its JCL member name, see 18. JCLLIB DDNAME.

Job Dependencies

In CA-SCHEDULER, the Schedule/Job Criteria screen can be used to establish the execution order of the jobs. Job dependency is controlled by means of explicit and implicit predecessors. An explicit predecessor is a condition name, explicitly stated, that must be met before a job is allowed to start. An explicit predecessor can be specified in any of the following formats:

• [MVS/NJE] job name

• job name[.procstep name].step name[.CC.operator.return code]

• SCD schedule name

• START [NJE] job name

• START SCD schedule name

Implicit predecessors are predecessors that need not be defined in the Criteria Language. When the same schedule, job, or job number exists for more than one station, the sequential order of the stations defines implicit predecessors.

In Control-M, job dependency, that is, job flow, is controlled by means of prerequisite conditions. A prerequisite condition is a descriptive name given to a specific situation, event, or condition. A prerequisite condition can be defined as an IN condition or an OUT condition for the job.

• An IN condition for a job is a prerequisite condition that must exist, in a file called the IOA Conditions file, before the job can be executed.

• An OUT condition for a job is a prerequisite condition that generally is added to the IOA Conditions file upon completion of the job.

Job dependencies can be established by defining a prerequisite condition as an IN condition of one job, and an OUT condition of another job. For more information, see the discussion of the prerequisite condition concept in the Control-M for z/OS User Guide.

The conversion tool automatically converts CA-SCHEDULER job sequences into IN and/or OUT prerequisite conditions, in order to establish the same schedule tree structure. In some cases, the Control-O Rule Definition facility is required, to post conditions for DSNEVENT, JOBARRIVAL, JOBEND and STEP events. For more information, see

• 30. START [NJE] jobName

• 31. DSN and GDG

• 32. MVS

• 33. jobName[.procName].stepName[.CC.operator.nnn]

Condition names are created in the format precessorJob_successorJob where both the precessor and successor jobs are fully qualified as:

{Boolean-operator}{prefix}scheduleName-jobName{-jobNumber}{-stationID}

The jobNumber and stationID are suppressed when their values are the same as their default values (01,40). Using this format provides greater granularity in controlling the job flow, since every job dependency relationship now has a unique condition associated with it.

For job pre-requisites that are connected by a 'true OR' relationship (criteria keyword '-OR-') the appropriate Boolean operators (open/close parentheses, '|') are appended to the condition name. Various prefixes can also be appended to the condition name, depending on the setting of the CNDPFX parameter.

For more information, see Conversion Parameters.

At successful job completion the Control-M job definition deletes, using the OUT parameter, the conditions added by its predecessor job, that is the conversion creates these OUT conditions (for deletion purposes) in the JOB that requires them as IN conditions. Only those OUT conditions that are created as a requirement for serializing a job that appears in multiple stations (within the same schedule) are created in the SMART Table Entity.

CA-SCHEDULER predecessor handling is conditional upon the selection of predecessor jobs. If a job under CA-SCHEDULER has predecessor prerequisites and those predecessor jobs have been selected for scheduling, CA-SCHEDULER does not schedule the successor job unless the predecessor jobs have successfully completed execution. However, if a predecessor job is not selected in the workload for the day, CA-SCHEDULER ignores it, and the successor job runs without waiting for the predecessor.

In Control-M, the ADJUST CONDITIONS parameter determines whether IN prerequisite conditions are to be ignored if the predecessor jobs that set the conditions are not scheduled. This parameter, which appears in the SMART Table Entity applies to all jobs in the SMART Table.

The ADJUST CONDITIONS parameter is set to either D or Y by the conversion tool, depending on the ADJCND parameter (for details see "ADJCND" in Conversion Parameters), to allow customization of conditional handling of predecessor prerequisites.

The following points must also be noted about prerequisite conditions.

• While most prerequisite conditions are added automatically upon job completion, prerequisite conditions, such as Criteria Language keyword GBLxnn, can also be added manually.

• When a job name predecessor is specified in the CA-SCHEDULER Criteria Language with a schedule name qualifier, the IN/OUT condition name is created with that schedule name, rather than the first schedule name in which the job is found.

• Jobs or schedules controlled by CA-SCHEDULER that are listed in a criteria statement qualify as predecessors if they are jobs scheduled that day. In particular, a criteria statement like NOT JOBA still defines JOBA as a predecessor. In addition, all selection-defined explicit predecessors and jobs and schedules preceded with the keyword PRED have an implicit AND relationship, that is, there are no OR relationships with selection-defined explicit predecessors–all ORs become ANDs.

  The conversion tool creates IN conditions for all explicit predecessors in the criteria statement. The logical Boolean relationship between selection-defined predecessors is always AND. The conversion tool places the | (Hexadecimal 4F) OR Boolean operator at the beginning of the condition name only for keyword-defined predecessors related by the OR criteria keyword. For example,

  Copy

  GBLC01=YES OR BLC02=NO

  is converted to

  Copy

  (|GBLC01=YES|GBLC02=NO)

  Predecessors related by Boolean OR logic are enclosed in parentheses to be properly converted.

  In summary, when Boolean OR or NOT operators connect jobs or schedules, they affect selection criteria only. They do not affect run-time predecessor determination. For the purpose of run-time predecessor determination, all Boolean operators are treated as AND, and the conversion tool converts them accordingly.

  However the -OR- ("true OR") Boolean operator is always interpreted as an OR, both during selection and during predecessor evaluation. So, for example, JOBA -OR- JOBB would be converted as:

  Copy

  (|JOBA   |JOBB)

• In CA-SCHEDULER, Boolean logic can be used to determine job selection by combining calendar keywords, such as DAILY, SUN, and 1ST, with schedule or job predecessors. For example:

  Copy

  WDOM-1 OR JOB1

  This example selects the job if it is now the last working day of the month, or if JOB1 is selected.

  In Control-M, the relationship between the Basic Scheduling parameters, which are calendar-related parameters, and the prerequisite conditions, is implicitly AND. A warning message is issued if selection-defined predecessors with a Boolean OR or NOT relationship is detected.

Scheduling

In CA-SCHEDULER, after a schedule has been defined, as described in the preceding sections, scheduling information, such as every day or once a month, is specified using the Schedule Criteria Record screen. All schedule jobs get the same scheduling information, unless you want a job to run less frequently than its schedule, when scheduling information is specified for the job using the Job Criteria Record screen.

In CA-SCHEDULER, the criteria language consists of a criteria vocabulary, which are reserved words, and a set of calendar mechanisms is used to construct a reason, or a set of reasons, for selecting a schedule or job for execution.

The conversion tool builds SMART Table scheduling definitions that correspond to CA-SCHEDULER scheduling structure. A SMART Table Entity is defined in the SMART Table with a Rule-Based Calendar (RBC) containing the Basic Scheduling parameters that correspond to the Schedule criteria in the CA-SCHEDULER schedule record. This RBC is in addition to the RBCs created as a result of implicit job scheduling described in Job Dependencies.

Scheduling criteria contained in a CA-SCHEDULER job record are converted to Basic Scheduling parameters in the relevant job scheduling definition with an A (And) RELATIONSHIP set between these criteria and the Rule-Based Calendar in the SMART Table Entity.

In CA-SCHEDULER, a job can be used to do both of the following, in parallel:

• Determine selection criteria, meaning scheduling criteria

• Automatically become a predecessor requirement

In Control-M, job and schedule (that is, SMART table) dependency predecessor prerequisite relationships are not used as scheduling criteria to determine the ordering of jobs

However, such implicit job scheduling is supported by creating a Control-M Schedule Rule-Based Calendar (RBC), either regular or Exclude, that contains the referenced job dependency’s scheduling criteria. A Control-M Level RBC is placed in the SMART Table entity with a reference to it in the appropriate job definition. The full RBC definition is then placed in the IOA RBC library. Note that RBCs for all nested levels of a job’s predecessors are added to the SMART table entity.

RBC names are created in the following format:

[jobname_][jobnumber_][stationid_]tablename

where:

• The jobnumber is included only when the source of the RBC is a job whose job-number is not 01.

• The stationid is included only when the source of the RBC is a job whose station-id is not the default specified in the &CPUSTAT conversion option.

• The jobname is always included, except when the source of the RBC is a CA-Scheduler schedule (SCD schedule-name).

Control-M 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 CA-SCHEDULER, begin every workday at the first moment of a new calendar day. The Control-M CA-SCHEDULER conversion tool is designed to convert CA-SCHEDULER scheduling data so it can be used in Control-M scheduling.

The following example illustrates how the CA-SCHEDULER scheduling method is converted to the Control-M scheduling method.

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

The conversion tool handles this conversion process automatically.

For users converting from versions of CA-SCHEDULER earlier than 9.0, see details on how the conversion tool handles this product difference in Step 10: Perform Final Adjustments.

User Documentation

In CA-SCHEDULER, documentation is specified using full screen editing facilities.

In Control-M, documentation is specified in the Job Scheduling Definition screen.

The conversion tool copies CA-SCHEDULER user documentation from the CA-EARL Documentation Directory and Member Report into a Control-M documentation library, and prepares it for viewing or updating in the Job Scheduling Definition screen. The member names used are the CA-SCHEDULER DISPLY-KEY MEMBER-NAMEs.

Message Definition

In CA-SCHEDULER, the Schedule/Job Message Definition screen can be used to implement message capability by notifying users of a schedule's progress.

In Control-M, the SHOUT facility enables you to specify messages to be sent to various destinations upon different execution events. The SHOUT messages are defined in the Job Scheduling Definition screen.

In the event that a CA-SCHEDULER schedule or job definition does not have a Message Record defined for it, the conversion tool will still create Shout messages, if required, for the following fields: MUST START BY TIME, COMPLETION DEADLINE TIME, MAXIMUM EXECUTION TIME.

Job Resources

In CA-SCHEDULER, the Resource Definition screen can be used to provide resource information needed to run simulations. Information identifying datasets that can only be used by one job at a time, and jobs that cannot run while other jobs are running, can be specified.

In Control-M, this type of resource management is implemented by specifying Control resources in job scheduling definitions.

Information on how many DASD, tape, and unit record devices a job uses is listed in the CA-SCHEDULER Resource Definition screen.

In Control-M, Quantitative resources are specified in the Job scheduling definitions to handle these types of resources.

In addition, a Control-M Initiator Quantitative resource for controlling initiators is added to all non-dummy job scheduling definitions, with a name of INIT and a quantity of 1.

CA-DRIVER Procedures and JCL Libraries

CA-DRIVER is an optional component of CA-SCHEDULER that can be used to automate the JCL or control statement setup.

In Control-M, the JCL Setup and AutoEdit facility is used to automate the changes to the JCL prior to job submission. The AutoEdit facility consists of a simple language that, once included into the job stream, eliminates the need to change the JCL again.

The conversion tool converts each CA-DRIVER procedure definition into a Control-M AutoEdit statement. In addition, JCL libraries and date functions are converted from CA-DRIVER format to Control-M format.

The conversion tool scans CA-SCHEDULER JCL libraries for members containing either of the following MVS JCL statements:

//     EXEC  procname
//     EXEC  PROC=procname

When one of these statements is encountered, the conversion tool searches the converted CA-DRIVER Procedure library for a member name matching the procedure name (PROCNAME). If the member name is found in the converted procedure library, the EXEC statement is replaced with Control-M AutoEdit %%INCLIB and %%INCMEM control statements that copy the converted procedure member to the current job stream. If the member name is not found in the converted procedure library, the EXEC statement remains unchanged.

For more information, see Table 11 in Conversion Details.

The CAJUCMD0 CA-SCHEDULER batch utility is not supported by the conversion tool. If you use this CA-SCHEDULER utility, you can obtain equivalent functions through the Control-M Application Program Interface (CTMAPI). For more information on CTMAPI, see the CTMAPI appendix in the Control-M for z/OS User Guide.

Control-O Rule Definition Facility

In CA-SCHEDULER, events such as the close of an output dataset, the start of a job or NJE job, the end of an MVS job not under control of CA-SCHEDULER, or the end of a job step optionally related to a return code from the step, can be used to indicate job dependency. This is accomplished using one of the following CA-SCHEDULER Criteria Language keywords:

• DSN

• GDG

• START [NJE]

• MVS

• jobname[.procstepname].stepname[.CC.operator.returncode]

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 CA-SCHEDULER Criteria Language keywords referred to above are equivalent to the JOBEND, DSNEVENT, JOBARRIVAL, and STEP events that add prerequisite conditions to the IOA Conditions file. For more information, with details of the exact conversion process, see Conversion Details.

Jobs on Distributed Platforms

CA-Scheduler supports jobs running on non-z/OS platforms by communicating with Unicenter TNG or other Unicenter job management agents. The Control-M conversion tool supports CA-Scheduler schedule/job definitions that specify distributed job definitions ('*REMOTE' in the NODE ID field or a JOB TYPE of 'XPLAT'). The JCL members pointed to by these definitions contain a variety of parameters specific to the distributed environment and have no counterpart in Control-M mainframe job definitions.

Because the conversion tool is run on the mainframe platform, these parameters (NODE, COMMAND, and so forth) are initially converted to SETVAR definitions and then post-processed by the CTMTLB utility, which creates XML definitions for upload to the distributed platform. The SETVAR statements are then transformed to appropriate XML parameters supported on the distributed platform (NODEID, CMDLINE, and so forth). The USER parameter is converted to the Control-M OWNER parameter.

In addition to supporting jobs on distributed platforms, CA-Scheduler also supports external event tracking, including file triggering for files that originate on distributed platforms (TYPE(DSCLOSE)). This functionality allows building jobs that contain a dependency based on file activity. The conversion tool supports distributed file triggering by converting the CA-Scheduler DSCLOSE event into a distributed job definition. The definition specifies the Control-M/EM ctmfw command followed by the file path and name as a parameter in the CMDLINE statement.

Control-M CA-SCHEDULER Conversion Tool

The conversion consists of a sequence of batch jobs. Although these jobs run independently of CA-SCHEDULER and Control-M, Control-M must be installed in order to perform the conversion.

The conversion tool performs the following functions:

• Builds Control-M SMART Tables and the documentation library based on reports

• Converts CA-SCHEDULER instructions in JCL and CA-DRIVER libraries to Control-M format

• Builds Control-O rule definitions for JOBARRIVAL, JOBEND, DATASET and STEP events

• Enables customers to set unique Control-M parameters automatically in resulting Control-M tables

• Issues appropriate messages if problems and errors are encountered during the conversion of CA-SCHEDULER definitions

The conversion tool is delivered in source format. If special requirements exist, the conversion tool can be tailored locally.