Conceptual Overview

This chapter includes the following topics:

• Introduction

• Application Definition

  • Job Definition

  • Scheduling

  • Cyclic Jobs

  • Job and Dataset Triggering

  • Job and Dataset Connections

  • Prose Information

  • Virtual Resource Management (VRM)

  • Control-M Calendars

  • Control-M/Restart Automated Rerun and Restart Processing

  • Automated Recovery Facility (ARF)

  • Jobs on Distributed Platforms

• Control-M Table Creation

• Production Control

  • Production Management

  • New Day Processing and Schedule Scan

  • DEMAND[H] and POST Commands

  • Workload Balancing

  • JCL Considerations

  • Special Override Library

  • CA-DRIVER Procedures and JCL Libraries

  • Network Communications Facility

  • Control-M Event Manager

  • Customization

• Control-M CA-7 Conversion Tool

Introduction

This conceptual overview is intended for production control personnel who are familiar with CA-7 and Control-M terminology.

The CA-7 to Control-M conversion tool is provided by BMC Software 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 CA-7 scheduling elements into functionally equivalent processes in Control-M. For more information on the CA-7 conversion tool, see Control-M CA-7 Conversion Tool.

The following issues are described in this chapter:

• Application Definition: Logic used by the conversion tool for converting components of CA-7 application definitions to corresponding Control-M components.

• Control-M Calendar Creation: Logic used by the conversion tool for creating Control-M calendars.

• Control-M/Restart Automated Rerun and Restart Processing: Logic used by the conversion tool for automating rerun and restart processing as provided by Control-M/Restart.

• Control-M Table Creation: Logic used by the conversion tool for creating Control-M tables.

• Production Control: Issues important to daily production management, such as the New Day procedure, on-demand and temporary job scheduling, and workload balancing.

• Control-M Event Manager: Logic used by the conversion tool for creating Control-M CMEM rules.

• JCL Processing: Logic used by the conversion tool to convert CA-7 and CA-11 scheduled JCL override statements and steps, as well as JES statements, to Control-M format. Control-M support for the CA-7 Special Override library is also described.

• CA-DRIVER: Logic used by the conversion tool to convert the CA-DRIVER components used to automate JCL and control card setup.

• Network Communication Facility: Describes Control-M standard and extended NJE job tracking support.

• Customization: Describes additional methods of customizing the conversion.

• Automated Recovery Facility (ARF): Logic used by the conversion tool for converting CA-7 ARF functions to Control-M and Control-M/Restart automated rerun and restart processing.

• Control-M/EM GUI and the Planning domain in Control-M: Logic used by the conversion tool to convert jobs to job definitions in the Control-M/EM GUI and in the Planning domain in Control-M.

Application Definition

In CA-7, defining an application requires the use of numerous definition screens. These screens include:

• the Job Definition (JOB) screen, used to define data related to CPU jobs

• the Job Scheduling (SCHD, JOB) screen, used to define the scheduling information of a job

• the Job Triggering (SCHD, JTRG) screen, used to define jobs that trigger other jobs

• the Dataset Triggering (SCHD, DTRG) screen, used to define data set events that trigger jobs

• the Job Predecessor/Successor Triggering (JOBCONN) screen, used to define job connections (prerequisites)

• the CPU Job Documentation (PROSE) screen, used to enter job-level documentation

• the Modification To Resolved Schedule Dates screen

• the Virtual Resource Management (RM) screen

• The Automated Recovery Facility (ARF) panel definitions (AR.n)

In addition, numerous other components are required to complete the application definition. These include:

• a CALENDAR Macro to define CA-7 Base calendars

• Workload Balancing macros to dynamically balance CPU work based on user-defined processing objectives

• the CA-7 Initialization file

• a User Option Table macro to define CA-11 requirement s

Under Control-M, all comparable definitions are handled using:

• the Job Scheduling Definition screen (Screen 2)

• the IOA Conditions and Control-M Resources screen (Screen 4)

• the IOA Calendar facility (Screen 8)

• the Control-M Event Manager (CMEM) (Screen C)

• the Control-M/Enterprise Manager user interface

Each component of the CA-7 application definition is discussed in the following pages in relation to the management of corresponding components under Control-M.

Job Definition

In CA-7, job definition is performed using the Job Definition (JOB) screen that contains information relevant to a specific job. Each job definition is a separate entity in the CA-7 database. CA-7 job definitions can specify JCL member names that differ from the name of the job. CA-7 forces the submitted job name to match the name of the defined job.

In Control-M, job information, such as scheduling criteria, runtime criteria, and so on, is stored in job scheduling definitions. Job scheduling definitions and SMART Table Entities are defined using the Job Scheduling Definition screen, and are stored in SMART Scheduling Table libraries. In Control-M, job control is independent of the job name in the JCL JOB statement. Control-M controls the job using the JCL member name, which is specified in the MEMNAME parameter of the Control-M job scheduling definition. For more information, see 1. JOB and MEMBER and 2. JCLID.

In Control-M, application job grouping is performed by defining, in one SMART Table, all related CA-7 jobs, that is, all jobs that have a triggering relationship.

Scheduling

In CA-7, after application jobs are defined as described in the preceding section, scheduling information is specified using the CPU Job Scheduling Parameter Edit (SCHD,JOB) screen. The schedule is determined by the first job of the application, referred to as the "head-of-tree" job. The remainder of the application jobs are associated with the head-of-tree job by means of "triggering," which is discussed in the following section.

A CA-7 scheduled job can be defined with a number of different schedule IDs. Each schedule ID can define different scheduling dates, execution environments, sets of jobs, JCL statements, and so on.

In Control-M, jobs can be scheduled individually or can be included in a SMART Table schedule. A job can be defined in several tables, or several times in the same table, with different scheduling or runtime criteria in each job scheduling definition.

The conversion tool creates a SMART Table for each CA-7 job grouping. The SMART Table Entity is used to define sets of basic scheduling criteria to be applied to a set of job scheduling definitions. Each set of basic scheduling criteria in the SMART Table Entity is assigned a unique label, specified in the SCHEDULE RBC parameter, which is used for referencing that set of criteria. For more information, including details regarding the SCHEDULE RBC parameter, see 36. SCHID. For more information on SMART Table scheduling, see the Control-M for z/OS User Guide.

Cyclic Jobs

In CA-7, there are several varieties of cyclic jobs, that is, jobs that run several times a day, depending on specific times or intervals during the day, or recursively scheduled every nnn days.

These jobs can be defined explicitly within a CA-7 schedule-id using the REPEAT or SYMETRIC keywords, or can be defined implicitly by specifying multiple schedule-ids, which differ only in their start times, within a head-of-tree job.

All of these cyclic varieties and how they are converted are described in detail in 17. Scheduling Information.

Job and Dataset Triggering

In CA-7, job triggering is usually performed after the schedule IDs are defined, as described in the preceding section. Triggering defines the execution sequence of the application jobs. The CA-7 Job Triggering (SCHD,JTRG) screen is used to define a list of triggered jobs for a specific job. Job triggering can be limited to a specific schedule ID. SCHID=000 means that the triggered job is initiated by a job with any schedule ID. By default, the schedule ID of a job is passed to the triggered job unless otherwise specified in the TRGID parameter.

Jobs, in the role of both triggering jobs and triggered-by jobs, can specify changed schedule IDs to affect the job flow triggering hierarchy. By specifying change schedule IDs, a job can be recursively executed within a job flow without causing a triggering loop. The conversion option JOBMXOC can be set to specify the maximum number of recursions that the conversion tool will allow. When a TRIGID changes the schedule ID of a triggered job, the conversion adds the Control-M auto-edit variable %%CHG_SCHID=nnn to the job definition.

In Control-M, the 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 terminology, an IN condition is specified for a job when the job must wait for the occurrence of an event. A condition can be added to the IOA Conditions file when an event occurs, such as job completion. Conditions can be added or deleted after successful job completion, based on user specification, using the OUT statement of the job scheduling definition. For more information about prerequisite condition concepts, see the Control-M for z/OS User Guide.

Conditions are entities in their own right, since they are not related to specific jobs. A condition exists after it is added, and does not exist after it is deleted. When a condition is added, that condition is satisfied for all jobs specifying it as an IN condition. Conditions can be listed, added and deleted using the IOA Conditions screen (Screen 4).

Each prerequisite condition is associated with a specific scheduling date. This scheduling date is used to differentiate between different runs of the same job for different scheduling dates.

Control-M identifies conditions in the system that must be confirmed manually by operations personnel. These conditions are called manual conditions. Addition and deletion of manual conditions is performed in the IOA Manual Conditions screen (Screen 7).

The conversion tool converts CA-7 job triggering, starting from the head-of-tree job, into Control-M IN and OUT conditions, to establish the same application tree structure. The conversion tool takes into account the CA-7 schedule ID, as shown in the SCHID parameter, and the Triggering schedule ID, as shown in the TRGID parameter, when building an application tree structure that it converts to a Control-M table. For more information on how the schedule ID is processed, see 36. SCHID. For more information on the Triggering schedule ID, see 18. Job Triggering and #NTR.

In addition to job triggering, the conversion similarly supports dataset triggering. For details, see Control-M Event Manager.

Job and Dataset Connections

In CA-7, the next stage of an application definition is to define specific job connections, which are prerequisite conditions, using the Job Predecessor/Successor (JOBCONN) screens. CA-7 distinguishes between various types of job connections. For example, a JDEP connection is an automatic dependency between one job and the completion of another job, while a USR connection is a descriptive text connection that requires manual operator intervention before the connected job can execute.

In Control-M, job connections are implemented using the same IN and OUT prerequisite condition mechanism discussed in Job and Dataset Triggering. For more details on how the various job and dataset connection entities are converted to Control-M conditions, see 19. DEP-JOB, 21. DSN, and 23. USER REQUIREMENTS.

Prose Information

In CA-7, documentation is specified in the documentation (PROSE) screens.

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

Depending on the number of lines contained in the job's Prose paragraph, the conversion will process it in different ways. If the number of lines exceeds 57 then the conversion tool copies CA-7 PROSE information into a member of a Control-M documentation library, preparing it for viewing and/or updating in the Job Scheduling Definition screen. If the number of lines does not exceed 57, then the PROSE information will be converted directly to a (multi-line) DESC field in the Job Scheduling Definition screen. Prose lines containing more than 70 characters will be split on 2 lines upon conversion.

Non-displayable characters in prose lines are converted to blanks.

Virtual Resource Management (VRM)

The Virtual Resource Management facility of CA-7 defines job-to-resource dependencies that control execution of the job based on resource availability at job submission time. This is implemented in the RM screen (the RSRC screen in CA-7 release 3.0 and earlier). The resource connected to a job can be a real resource, such as a data set or a started task, or a virtual resource used by multiple jobs to control job execution in a required cycle.

This facility provides the following features:

• resource control at the job, system, or step level

• job submission control for jobs that use shared or exclusive resources

• job "corequisite requirements"

• resource control for physical data sets, virtual data sets, or a group of data sets

• address space resources that control job submission based on the status of an address space

• Scheduling Environment specification

In Control-M, virtual resource management is implemented using Control resources, Quantitative resources, and manual IN conditions that are defined in the Job Scheduling Definition screen.

If Virtual Resource Management is used at your site, the conversion tool converts the resource information and places it into Control-M tables. For more information, see 25. Virtual Resource Management.

Control-M Calendars

In CA-7, Base calendar definitions must be assembled and link-edited into load modules. In Control-M, calendar definitions are simply created online using the IOA Calendar facility (Screen 8).

The CA-7 conversion tool automatically creates Control-M calendars in several situations:

• when you specify CA-7 Base calendars in Stage 1 of the ICE Installation, as discussed in Extract the Data from CA-7 Environment.

• when CA-7 job schedule parameters cannot be consistently converted to Control-M basic scheduling parameters.

• when non-standard periodic calendars must be utilized.

• when a schedule contains more than 24 DATES.

• when a schedule specifies negative criteria of the type WDAYS=-DmWn, such as “do not schedule on the 3rd day of the 4th week.”

• for criteria that involves the nth day of the LAST mth week of the month

• any mixture of DAYS criteria with DATES criteria

• negative DATES criteria

• for scheduling every n WORKING days

• for scheduling every n days when n>45

• when a CA-7 job has the SCHDMOD CURRENT indicator set in its scheduling information.

• This CA-7 facility allows on-line modifications of the permanent scheduling criteria in the job definition with temporary criteria.

• when an Extended Shift must be applied to specific criteria and not just to the final scheduled resolution.

• When the limitations of the Control-M on-line Screen 2 have been exceeded: 2 lines for DAYS criteria; 1 line for WDAYS criteria; maximum of 11 DmWn type criteria; 8 periodic formats

Several of these situations are described in detail in 13. SCAL.

To minimize the number of calendars created by the conversion, BMC recommends that conversion option SCHDMOD be set to I. For details, see Appendix A, Conversion Parameters.

Control-M/Restart Automated Rerun and Restart Processing

In CA-7, automated rerun and restart job processing is accomplished using an interface to CA-11, if CA-11 has been installed. CA-7 can automatically insert CA-11 JCL steps into jobs scheduled and submitted by CA-7.

CA-11 performs the typical functions of rerun and restart systems. However, to realize the full functionality of CA-11, manual modification is required for JCL members that are to be restarted.

For example, specifying that a job is to be rerun after an abend, or specifying a specific step name from which a job is to be restarted, requires:

• manual modification of the JCL of the job, by changing the PARM of the U11RMS step or inserting a //*CA-11 comment statement, or

• issuance of online commands (PRE)

In contrast, Control-M/Restart is a fully automated rerun and restart system that is tightly integrated with Control-M. It normally requires no manual intervention, unless you specify manual confirmation.

Definition of Control-M/Restart processing is performed by means of parameters defined in the job scheduling definition for the job. This consolidates and simplifies the job scheduling and restart process. The following fields in the Control-M Job Scheduling Definition screen determine the processing to be performed by Control-M/Restart:

• DO IFRERUN

• DO RERUN

• PREVENT-NCT2

• AUTO-ARCHIVE, SYSDB, MAXDAYS, and MAXRUNS

In addition, it is possible to override the default Control-M/Restart parameters by using control parameter members in the library allocated to the DACTRCTL DD statement of the CONTROLR step. For more information, see the Control-M/Restart User Guide. One option that many CA-7 conversion sites specify is NORECAPTABEND, which prevents automatic abend code recapture.

For more information on how CA-11 PARM parameters are converted to Control-M/Restart parameters, see 31. CA-11 U11RMS Step.

The Control-M/Restart Simulation facility, which corresponds to the CA-11 PSEUDO=YES processing option, enables you to see what actions will be taken by Control-M/Restart without actually performing a restart.

Control-M/Restart also has an interface with a Tape Management System similar to the CA-11/CA-1 or the CA-11/CA-DYNAM/CA-TLMS interface. For more information, see the Control-M/Restart User Guide, and the CTRX001 sample Exit in the IOA SAMPEXIT library.

Automated Recovery Facility (ARF)

User of CA-7 (R3.1 or above) can make use of the Automated Recovery Facility (ARF) to monitor exception conditions for production jobs and to schedule recovery actions to execute at or near the point of failure. Kinds of exception conditions monitored by ARF include:

• Abend exceptions tested at the job or step level.

• Condition code exceptions tested at the job or step level.

• Jobs whose elapsed execution time falls outside a range specified by the user.

• Jobs considered late according to CA-7.

• Jobs considered late according to user-specified criteria tested when the job begins or completes.

These exception types are categorized as follows:

• EC – Elapsed Time Check at Completion

• EE – Elapsed Time Check During Execution

• IS – Interrupt Submission

• JC – Job Completion Check

• LA – Late Notification at CA-7 Prompting

• LB – Late Notification When Job Begins

• LE – Late Notification When Job Ends

• LS – Late Notification at Job Submission

• SC – Step Completion Check

The kinds of recovery actions that may be executed in response to the exception conditions detected by ARF include

• scheduling and tracking special recovery jobs

• issuing special messages to a specified TSO user or to the MVS console

• issuing CA-7 or MVS commands

• restarting, canceling, or forcing the completion of jobs as the final step (disposition) in the recovery for job completion exceptions

These response types are categorized as follows:

• AC – Issue a Command (commands supported by the conversion: DEMAND, POST, PRSQ, /LOG, /EMAIL, CANCEL)

• AW – Wait

• AM – Issue a Message

• AJ – Schedule a Recovery Job

Final disposition actions include

• N – Take no action; the job is left for manual recovery

• R – Restart the job using the CA-7 top-line RESTART command. Additional parms for the command may be supplied using other input fields in the final disposition section.

• C – Cancel the job using the CA-7 top-line CANCEL command.

• F – Force completion of this job using the RESTART command.

• P – Issue an ARFP command to purge ARF records for this job.

The conversion tool converts ARF monitoring and recovery actions to Control-M and Control-M/Restart post-processing parameters in the corresponding job scheduling definitions that reference the CA-7 ARFSETs. This consolidates and simplifies the job scheduling and restart process. ARFSET is supported whether it is named on the DB.1 panel (and extracted from the LJOB report), overridden using the #ARFSET statement in the JCL, or overridden using the ARFSET keyword on the DEMAND command.

The above ARFSET elements are converted to the following Control-M and Control-M/Restart parameters.

The conversion tool creates a library with a single table named ARFTABLE. The various ARFSET definitions in the CA-7 LARF report are placed in this table as job scheduling definitions using the ARFSET name as the ‘job name’. This name is also specified in the Control-M DESC parameter as ARFSET=jobname. CA-7 jobs that reference a particular ARFSET will have the ARFSET job scheduling parameters incorporated into their definitions via the Control-M CTMBLT MODEL parameter.

In addition, when the LARF report fields STEP and PROC specify a generic name (using masking characters * and/or +) or the STEP/PROC operator specifies NE or any PGM is specified (not ‘*’), then a corresponding record is instead created in member PGMST in the CTM PARM library. In such cases, the STATUS code, instead of being set to OK/NOTOK, is set to a special step completion code *xxxx which connects this PGMST entry to an ON PGMST statement created in the job scheduling definition. For details, see the INCONTROL for z/OS Administrator Guide.

When the RSTC (restart count) specifies an operator of LE or LT, the conversion modifies the standard Control-M ON PGMST statement into a compound statement by ANDing it with:

ONPGM STEP=ANYSTEP CODES=FCnnn A/O=A

An RSTC value of LT 1 is ignored.

The ARF Exception types are converted as follows:

• For JC and SC type exceptions, the conversion uses the ARF STEP/PROC names together with the CC/ABENDs (of types JCL, FL, HRC, CC, USER, or SYS) and comparative operators (EQ, NE, LE, LT, GE, GT) to create a Control-M ON PGMST statement:

  ON PGMST step   PROCST proc  CODES code1  code2  code3

  Note that ARF wildcard characters are supported in the CC and Abend codes.

• For EC and EE type exceptions, the conversion creates Control-M SHOUT-WHEN EXECTIME statements.

• For LA and LS type exceptions, the conversion creates Control-M SHOUT-WHEN LATESUB statements.

• For LB type exceptions, the conversion creates Control-M SHOUT-WHEN LATE statements.

• For IS type exceptions, the conversion adds a CONFIRM=Y to the job scheduling definition.

Various ARF responses and final disposition actions are converted to Control-M DO actions within the ON PGMST block and other post-processing parameters.

AC,M=DEMAND,JOB=jobname

DO FORCEJOB TABLE table JOB jobname DATE ODAT LIBRARY %%$SCHDLIB

AC,M=POST,USER=USR-TXT

DISP=F

DO=OK

DISP=R
STEPS:   START=procstepfrom.stepfrom      END=procstepto.stepto

AW,TIME=10

INTERVAL=10

DISP=C
DO SHOUT TO TSO-CMD URGENCY R
MSG = S CTMAPI AJF DELETE

Jobs on Distributed Platforms

CA-7 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-7 JCL members specifying that a distributed job must be submitted via JCL Override statement #7UNI. These JCL members and the CA-7 XPS Profile member CACCENV specify a variety of parameters specific to the distributed environment. Such parameters have no counterpart in Control-M mainframe job definitions.

Because the conversion tool is run on the mainframe platform, these parameters (NODE, SUBFILE, and so forth) are initially converted to SETVAR definitions. The parameters are 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, etc.). The SUBUSER (and DOMAIN) parameters are converted to the Control-M OWNER parameter.

Alternatively, CA-7 provides the option of defining cross platform jobs directly in the CA-7 job definition. The distributed parameters (Node, Exec and PARM) are then extracted from there (the LJOB report) and processed as above.

Distributed jobs with long job names specified in their LJOB job definitions (more than 8 characters) are supported.

Currently, the following distributed platforms (as specified in the CA-7 MAINID) are supported:

• AS400

• Windows NT

• FTP

• SAP

• PS (PeopleSoft)

• UNIX

• FTRG (File triggering)

• BWPC (SAP Business Warehouse)

• OMDK (On-line Disk Monitor – passive support only)

• NSTP (Non-stop jobs – passive support only)

• OMEL (Eventlog Monitor – passive support only)

• OMPM (Process Monitor – passive support only)

• OMCP (CPU Monitor – passive support only)

• OMTF (Text Monitor – passive support only)

In addition to supporting jobs on distributed platforms, CA-7 also supports external event tracking, including file triggering for files that originate on distributed platforms (TYPE(DSN)); this allows building jobs that contain a dependency based on file activity. The conversion tool supports distributed file triggering. For more information, see Control-M Event Manager.

Control-M Table Creation

The conversion tool builds a Control-M table for every CA-7 job grouping, incorporating all the jobs of the application. Each table contains all jobs that are triggered by any job from that application.

The conversion tool searches the CA-7 LJOB report for head-of-tree jobs, and tracks the triggering data in order to build the entire application job tree. A head-of-tree job is either

• a job that is scheduled, that is, a job that contains scheduling information, or

• a job that is not scheduled or triggered by another job

If a head-of-tree job is scheduled, the tree of this job is called a scheduled tree. Otherwise, it is called an independent tree, usually defined in CA-7 for special purpose or on-demand execution. These trees can contain one or more jobs based on triggering information. All CA-7 job trees are converted to Control-M SMART Tables with the head-of-tree job name assigned to the Control-M table.

Production Control

In CA-7, numerous online transactions are required to achieve production control. These transactions access CA-7 queues in order to assist in tracking and controlling the daily production environment.

Under Control-M, production tracking and control is performed using the Active Environment screen (Screen 3) or the Control-M/Enterprise Manager.

Production Management

CA-7 manages production jobs using a set of queue files. When a production job is to be executed, it is loaded into the Request Queue where its prerequisites are handled. After all prerequisite conditions are satisfied, the job is moved to the Ready Queue where it waits to be submitted for execution based on physical resource availability, such as tape drives and priority. When job execution starts, the job is moved to the Active Queue where CA-7 monitors its execution. Additional CA-7 queues manage statistics, JCL decks, and so on.

In Control-M, production tracking and control is managed using a single file, the Active Jobs file (AJF). When a job is scheduled or FORCEd (demanded), Control-M loads its definition to the AJF. The AJF is then used to track and control the life cycle of the job. Access to the AJF is provided using the Active Environment screen (Screen 3) or Control-M/Enterprise Manager, which enable you to monitor, track, and control the entire life cycle of a job. You can see the status of the job, "hold" the job in order to modify its definition, "free" the job for execution, view the sysout of the job, browse the Log information relating to the job, display predecessor and successor job chains and network dependencies, perform deadline scheduling tasks, and carry on a variety of other activities.

New Day Processing and Schedule Scan

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.

In CA-7, by default a day is considered to be an absolute day beginning at midnight (00:00). To override the default, you can define a calendar as logical and identify the start time of your logical day.

The Control-M conversion tool assumes that Control-M New Day time has been properly chosen to correspond with the CA-7 logical day start time. Therefore, no modification (shift in scheduling days) is necessary. If this is not the case, or if calendars with different logical start times are in use, then the conversion tool converts the CA-7 scheduling data so it can be used in CONTROL-M scheduling by specifying the Control-M SAC job scheduling parameter to synchronize the Control-M and CA-7 scheduling criteria based on the New Day/Logical Day time differences.

Example Conversion of CA-7 Scheduling to Control-M Scheduling

The following example illustrates how the CA-7 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-7 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-7 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 difference automatically. For more information, see Post Step 1. Customize Control-M and Install User Exits.

Converted SMART Tables and the SAC parameter

If any jobs in a converted SMART Table have their SAC parameter set to P (indicating that their scheduled FROM time is between midnight and the Control-M New Day time), then the SMART Table Entity to which the job belongs will also have its SAC parameter set to P, even if not all of the jobs in the group have SAC set to P. Logically, this results in the SMART Table Entity being scheduled twice: both on its original scheduled day (for jobs not set to P) and the previous day (for jobs set to P). If all the jobs in the group have SAC set to P, then the group's SAC parameter is set to '-'. This causes the group to be scheduled only once on the 'previous' day.

DEMAND[H] and POST Commands

In CA-7, non-recurring jobs are requested using the DEMAND[H] command. The prerequisites of the job can be manually satisfied using the CA-7 POST command. Both of these commands are executable in the CA-7 online environment and in batch mode.

In batch mode, DEMANDs and POSTs are executed in order to control production flow based on prior step condition codes or any other user requirement. CA-7 provides JCL procedures such as SASSTRLR for this function. The batch mode can also be executed from within batch jobs or started tasks that are not controlled by CA-7.

In Control-M, the FORCE (F) line command in Screen 2 operates similarly to the CA-7 DEMAND command. The Control-M ADD COND command in Screen 4 is comparable to the CA-7 POST command. These two Control-M commands can be executed in the Control-M online environment, in batch mode or via Control-M/Enterprise Manager. In batch mode, Control-M provides the Control-M CTMAPI and IOA IOAAPI utilities to order or force jobs and add conditions for which other jobs are waiting.

The DEMAND[H] command in CA-7 JCL members is converted to an ORDER command to FORCE the job into the daily schedule. This command is executed by a CTMUTIL step which invokes the Control-M CTMAPI utility. For more information on the CTMUTIL utility, see Conceptual Overview. When the Demand command is invoked from within the CA-7 CAL2X2WB utility, then CTMUTIL orders a job on-the-fly (via CTMBLT) that performs a remote FORCEJOB of the demanded job using the DATACENTER parameter.

The conversion tool converts POST commands in a CA-7 Batch Terminal Step to a utility step containing an ADD COND, with a condition name based on the POST type. For more information, in particular on DEPJOB, NW (network), and USR type POST condition names, see 19. DEP-JOB, 22. NWK, and 23. USER REQUIREMENTS.

For more information on the format of IN and OUT conditions related to the DEMAND[H] and POST commands, see 19. DEP-JOB.

Workload Balancing

In CA-7, the Workload Balancing facility dynamically balances CPU work based on user-defined processing objectives. The Workload Balancing facility analyzes jobs awaiting execution, and sets priorities for jobs submitted based on the following criteria:

• job start times

• CPU usage

• tape drive usage

• job class structure

• threshold priorities

In Control-M, maximizing throughput is achieved through the specification of Quantitative resources (using the RESOURCE job definition parameter and the Control-M Resources file), job priority, and the CTMRELRS utility. In addition, you can implement the Dynamic Tape Drive Quantity Adjustment feature, using the AUTOTAPE parameter in the CTMPARM member in the IOA PARM library.

The conversion tool converts the following CA-7 Workload Balancing entities to Control-M RESOURCE and PRIORITY parameters:

• class barriers

• class and priority specified in the CA-7 JCL #RES override statement

• tape drives, class, and priority specified in the CA-7 Job Definition screen

Tape drives, class, and priority specifications coded in the CA-7 Job Definition screen serve as initial Workload Balancing values. These initial values can be overridden by values specified in

• the RESCHNG command

• the #RES JCL override statement

Tape drives specified in CA-7 JCL batch RESCHNG commands and #RES override statements are converted to input parameters for the CTMRELRS utility, to change Quantitative resources.

The RESCHNG command and the #RES JCL override statement are discussed in Command RESCHNG and #RES JCL Override Statement.

Class Barriers

CA-7 Class Barriers establish the maximum number of jobs that can be submitted concurrently in an associated job class. For more information on how class barriers are converted to Control-M Resources, see 12. CLASS and #RES.

Command RESCHNG and #RES JCL Override Statement

You can use the CA-7 RESCHNG command and the #RES JCL override statement to free tape drives that are no longer required. When the Workload Balancing facility schedules jobs, the high-water mark for tape drives is reserved until job completion, unless this command is used. Using the RESCHNG command, you can insert the Trailer Step into the job after the maximum number of tape drives is no longer needed.

In Control-M, the CTMRELRS utility provides comparable functionality. The CA-7 #RES JCL override statement and the RESCHNG command step are converted into the following Control-M CTMRELRS step:

// EXEC CTMRELRS,PARM='CHANGE RESOURCE tape-res1 quant1; tape-res2 quant2'

This command changes the number of resource-name resources allocated to the job to the quantity specified. For information on the two CA-7 tape drive devices that can be controlled using this utility, see "TAPE1" and "TAPE2" in Conversion Parameters, and for more details see 33. RESCHNG and #RES.

Changing Workload Balancing Objectives

In CA-7, you can establish multiple Workload Balancing Environments to properly balance processing objectives. This is done by creating multiple load modules containing the processing objectives defined by the Workload Balancing macros. The criteria defined by the Workload Balancing macro create a virtual configuration for CA-7 to manage. A job that executes a specific Workload Balancing module is then scheduled whenever the corresponding processing objective is required.

In Control-M, the corresponding process of changing the resource environment configuration is done by simply scheduling a job that executes the IOACND utility, using the CHANGE RESOURCE statement.

For example, the CA-7 Workload Balancing module contains the following macros:

WLBPDEF MODNAME=xxx
TAPE1     NAME=TAPE1,MXTAL=25
TAPE2     NAME=TAPE2,MXTAL=15
CLBARR    BARA=5,BARB=1,BAR2=3
WLBEND

These correspond to the following Control-M IOACND utility statements:

CHANGE  RESOURCE TAPE1 25
CHANGE  RESOURCE TAPE2 15
CHANGE  RESOURCE CLASS_BAR_A     5
CHANGE  RESOURCE CLASS_BAR_B     1
CHANGE  RESOURCE CLASS_BAR_2     3

JCL Considerations

CA-7 provides the capability to specify special scheduled JCL override statements. These override statements enable you to perform the following functions:

• modify workload balancing resource requirements

• define step-level condition code checking criteria

• set various types of manual requirements

• make runs non-executable

• turn off job triggering

• send messages at job submission time

• dynamically tailor run-stream contents based on schedule ID, date, and time

• submit cross-platform distributed jobs

These functions are specified by the CA-7 JCL # statements and are converted to Control-M AutoEdit statements, job scheduling definition parameters, or Control-M batch utilities. For more information on how each of these statements is converted, see the component conversion summary in Conversion Details.

In addition, CA-7 commands can also be included in JCL Batch Terminal steps. For details of how they are converted, see DEMAND[H] and POST Commands, and Command RESCHNG and #RES JCL Override Statement.

If you are also converting from CA-11, the CA-11 U11RMS JCL steps and comment statements are analyzed for restart and rerun information. These steps and statements are incorporated into Control-M/Restart Job Scheduling parameters. For more information, see 31. CA-11 U11RMS Step.

Standard JES JCL statements such as ROUTE PRINT are also processed by the conversion tool. For more information, see 42. JES ROUTE PRINT.

CA-7 Global variables are converted to Control-M auto-edit format.

Special Override Library

CA-7 supports a JCL override library that is intended to handle one-time temporary JCL changes. This library is specified in the CA-7 Initialization file as INDEX=254 (JCLID 254) and its use is indicated by setting the USE-OVRD-LIB field in the DB.1 Job Definition Screen to Y. After the job is successfully executed, the JCL is deleted from the Special Override library.

You can obtain the same functionality in Control-M using the CTMIMAC1 REXX procedure in the IOA CLIST library.

Using the CTMIMAC1 procedure, JCL is dynamically copied from the MEMLIB library to the Control-M OVERLIB library, if no member by that name already exists, and is then edited using option J in the Control-M Status screen (Screen 3).

If the rerun of the job ended OK, the JCL member can optionally be deleted from the OVERLIB library by the DELOVRER Control-M installation parameter, which performs the function formerly provided by Control-M Exit CTMX015O.

For more information and installation instructions, see the following:

• the discussion of the OVERLIB parameter in the Control-M for z/OS User Guide

• the discussion of the DELOVRER parameter in the Control-M chapter of the INCONTROL for z/OS Installation Guide

• the CTMIMACx source members in the IOA CLIST library.

CA-DRIVER Procedures and JCL Libraries

See the Control-M for z/OS for CA-SCHEDULER Conversion Guide for full details on converting CA-Driver procedures and JCL libraries.

Network Communications Facility

CA-7/NCF, an optional feature of CA-7, enables jobs submitted by CA-7 to execute at any site within a network of sites as if the site was a local CPU. CA-7/NCF ensures that the CA-7 that submitted a job receives the necessary SMF feedback data to track the job, regardless of which site processed the job.

NJE support in Control-M is a standard feature, and involves setting up the standard JES and VTAM node definitions. Control-M Extended NJE job tracking provides the ability to detect and display the real-time status of Control-M controlled NJE jobs, by setting to Y the ENHNJE parameter in the CTMPARM member in the IOA PARM library.

In addition to the previously described standard and extended support provided by Control-M, the conversion tool converts the CA-7 MAINID parameter. This parameter is used to specify a CPU from which JES can transmit a job to the proper remote node. The conversion tool provides a sample exit that inserts one of the following into the JCL stream of the job:

• a JES2 /*JOBPARM SYSAFF statement

• a JES3 //*MAIN SYSTEM statement

For more information, see 40. MAINID and Step 14(5) in Conceptual Overview.

Control-M Event Manager

In CA-7, data set and output activity can be used to trigger jobs. Whenever a data set is created or updated, jobs can be triggered by the completion of an activity. In Control-M, the corresponding facility is the Control-M Event Manager (CMEM) Rule Definition facility that manages external events, which are events occurring outside the direct control of Control-M. CMEM performs predefined actions in response to the occurrence of events in the system. CA-7 data set triggers are equivalent to CMEM ON DSNEVENT events which issue a DO FORCEJOB action to ORDER the triggered job.

When the CA-7 Dataset Triggering screen (DB.2.6) shows that a CA-7 data set trigger event is occurring, the conversion tool creates a CMEM rule for the ON DSNEVENT event with the following information:

Table 1 Information in CMEM rule for DATASET event

Every rule in the $DSNEVT member of the CMEM library corresponds to a job scheduling definition in the table DOFORCEJ that resides in the BLTARF library. The job in table FORCEJ contains an in-stream JCL that executes the Control-M CTMAPI utility. The jobname is of the form Dxxxxxxxx, and is specified in the description of the rule. For each rule whose corresponding job in the DOFORCEJ table specifies parameter SELTAG=* (based on the CA-7 scheduled-id=000 — any schedule is converted to *), the job is ordered directly from the rule in $DSNEVT rather than from the DOFORCEJ table. If the specified jobname in the ORDER statement of the job in the DOFORCEJ has the same name as a table in the scheduling library (NEWSCHED), then that table is ordered by changing the triggered table name in the rule, rather than being ordered from DOFORCEJ. Otherwise, the job is ordered from the ad-hoc table @@@@@@@@ (if it exists there), by changing the triggering Table name in the CMEM rule to @@@@@@@@.

All other jobs are ordered indirectly via the DOFORCEJ Table in the BLTARF library.

When a job is ordered directly from the CMEM rule, the corresponding job definition in table DOFORCEJ is deleted.

Multiple CMEM rules are created when multiple job names are listed in the CREATED IN THE FOLLOWING JOB(S) list, one for each job in the list.

For more information regarding the CMEM facility and the CTMAPI utility, see the Control-M for z/OS User Guide.

The above discussion applies to mainframe (non-distributed) jobs only. However, if a job is identified as a distributed job (either by its job definition or by the CA-7 Special Override statement #7UNI in its JCL member) then the datasets specified in the CA-7 Dataset Triggering screen (DB.2.6) are assumed to reside on a distributed remote platform. In such cases, the conversion tool creates a job definition for the triggering dataset that is ultimately transformed into a distributed file watcher (FWJnnnnn) job. Upon occurrence of the event (file trigger), the file watcher adds a DSN_TRIG_jobname condition, for which the triggered job waits (as an IN condition).

For mainframe jobs that are triggered by files on distributed systems, see 21. DSN.

Customization

To customize the way in which the conversion process operates, consider using the following options:

• the conversion parameters described in Conversion Parameters

• the CTMTBUPD Control-M utility, which performs post-conversion mass updates on Table parameters

• a combination of the CTMTLB and CTMBLT Control-M utilities, which can be used to perform post-conversion mass updates on table parameters when it is inappropriate or impossible to use the CTMTBUPD utility. See the INCONTROL for z/OS Utilities Guide for further information regarding these utilities.

Control-M CA-7 Conversion Tool

The conversion consists of a sequence of batch jobs. Although these jobs run independently of CA-7, CA-11, Control-M, and Control-M/EM, Control-M and Control-M/EM must be installed to perform the conversion.

The conversion tool performs the following functions:

• Builds Control-M tables based on CA-7 database definitions and CA-7 and CA-11 JCL override statements.

• Builds all necessary Control-M calendars.

• Creates XML table and calendar definitions for uploading to Control-M/EM.

• Builds Control-M CMEM Rule Table definitions based on CA-7 data set triggering events.

• Converts CA-7 (scheduled) override statements, Batch Terminal Steps, and CA-11 U11RMS Steps in JCL and parameter libraries to Control-M format.

• Converts CA-DRIVER libraries to Control-M format.

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

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

• Issues messages about problems and errors encountered in the CA-7 definitions.

The conversion tool is delivered in executable (without the need to assemble and link-edit modules) and in source format. If special requirements exist, the conversion tool can be tailored locally.