Conceptual Overview

Introduction

This conceptual overview is intended for production control personnel who are familiar with CA ESP terminology. Experience with Control-M and Control-O is recommended and also with Control-M and Control-M/Enterprise Manager (Control-M/EM).

The CA ESP to Control-M conversion tool is provided by BMC to assist in the creation of the primary product elements for Control-M for z/OS, Control-O, and Control-M. It is designed to expedite the conversion process by automatically translating the most commonly built CA ESP scheduling elements into functionally equivalent processes in the above INCONTROL family of products. For more information on the CA ESP conversion tool, see Conversion Installation.

The primary scheduling units in CA ESP are events that define when CA ESP must perform the work, and what actions CA ESP must take to perform the work.

CA ESP procedures are a set of stored instructions that CA ESP invokes to define a group of jobs and tasks as a CA ESP application. CA ESP Procedures are used to:

• Define processing requirements for a group of jobs and tasks in a CA ESP Application

• Define and work with symbolic variables

• Perform different actions based on other criteria, such as a job failure

Under CA ESP, defining a production application requires the use of a free-format script-type language (CLANG) and job specification statements.

Under Control-M and Control-O, all comparable definitions are handled using the following screens; the Job Scheduling Definition screen (Screen 2), the IOA Calendar facility (Screen 8), the Control-M Event Manager (CMEM) (Screen C), the Control-O RULE DEFINITION screen (Screen OR), and Control-M/EM and Control-M.

The components of the CA ESP definitions are discussed on the following pages in relation to the management of corresponding INCONTROL products and components.

Job Definition

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 SMART table libraries. Application job grouping is performed by defining all related jobs in one SMART Table. The CA ESP procedures correspond to Control-M SMART Tables. The names of the converted tables are assigned from the procedure member name.

The CA ESP job name is used for the Control-M MEMNAME parameter.

The same job name may appear more than once in one Control-M table.

Job Dependencies

In CA ESP, job dependency is controlled by means of the AFTER, RELEASE, PREREQ, POSTREQ, NOTWITH, and COREQ parameters. Prerequisite conditions can be specified by various criteria including

• end of job

• normal or abnormal end of job

• close of data set

• file triggering (on distributed platforms)

• job arrival

• ’external’ job definitions

• jobs which are mutually exclusive

In Control-M, the 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 DO COND 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 CA ESP job dependencies into IN or OUT prerequisite condition definitions to establish the same schedule tree structure. In some cases, the Control-M Event Manager (CMEM) (for dataset triggering) or Control-O are necessary to post conditions or issue DO FORCEJOB commands. CA ESP jobs that have mutual exclusive dependencies are converted with Control-M CONTROL shared/exclusive resources.

Scheduling

In CA ESP, scheduling information, such as daily or last day of the month, is specified using the RUN/SCHEDULE and NORUN/NOSCHED parameters. The [NO]RUN/[NO]SCHEDULE parameters consist 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 CA ESP [NO]RUN/[NO]SCHEDULE parameter keywords are converted to Control-M Basic Scheduling parameters. The ESP RUN REF scheduling statement is also supported by creating a Control-M RBC (regular or Exclude) containing the referenced job scheduling criteria. For details of the conversion of each RUN/SCHEDULE element, see 13. RUN/SCHEDULE, NORUN/NOSCHED.

The same keyword vocabulary may also be specified in CA ESP conditional statements of the form:

IF TODAY(‘scheduling keywords’) THEN SELECT (job1, …, jobn)

Or

IF TODAY(‘scheduling keywords’) THEN DESELECT (job1, …, jobn)

Or

IF TODAY(‘scheduling keywords’) THEN DO JOB job-definition

The SELECT and DO JOB forms of the statement are handled by converting the scheduling keywords into Control-M basic scheduling criteria in a Rule-Based Calendar (SCHEDULE RBC) definition in the SMART Table Entity of the table and then adding this RBC to each job definition specified in the SELECT clause or DO JOB definition.

The SELECT statement is also supported as a stand-alone statement in an ESP job definition when SELECT job-name is the same as the job-name of the job in which it is specified. In such cases, it is converted to SCHEDULE RBC *.

The DESELECT form of the statement transforms the scheduling keywords into their logical negative (for example, the last day of the month, L1, is transformed into –L1) and then adds these criteria into the basic scheduling parameters of the job definitions specified in the DESELECT clause. In addition, an RBC relation of ‘A’ (And) is added to the job definition.

Support for generalized conditional IF statements within an ESP job definition of the form:

IF TODAY(xxx) THEN [DO]
   yyy
   zzz
   ...
 [ENDDO]

     where xxx is any combination of scheduling criteria and yyy, zzz, ... are any ESP statements

is as follows:

• Whenever an internal (within an ESP job definition) IF statement of the above form is encountered, upon conversion the job definition is duplicated with the scheduling criteria in the TODAY statement, overriding the original scheduling criteria. Similarly, the converted values of the ESP yyy, zzz, ... statements override the original values in the duplicated job definition. The scheduling criteria within the IF TODAY statement are also added to the original job definition as an EXCLUDE RBC (with a name +Zxxx).

• Duplicate job definitions are created for as many (supported) IF statements that are contained in the original ESP job definition.

  If xxx or yyy specify scheduling criteria, such as a RUN statement, then the scheduling criteria inside the TODAY clause is ANDed with the scheduling criteria of the RUN phrase.

• Nested IF statements are NOT supported.

• If the THEN clause specifies NORUN TODAY, then all the scheduling criteria in the IF-clause are converted as negative scheduling criteria.

The conversion also supports special ‘shorthand’ symbolic variables defining scheduling keywords and names of Special days defined in ESP calendars. The Special days are converted to Control-M Periodic scheduling criteria in conjunction with the ESP calendar in Periodic format. See 68. Calendar Special days names for more details.

In addition to TODAY, the conversion also supports TOMORROW and YESTERDAY. Non-conditional SELECT statements are converted by creating an RBC containing the DAYS=ALL scheduling criteria. When multiple SCHEDULE statements appear in CA ESP events, multiple Control-O EVENT rule definitions are created, one for each SCHEDULE statement.

The ‘IF TODAY’ scheduling format is also supported in JCL %INCLUDE/%EXCLUDE statements. See 66. %INCLUDE/%EXCLUDE/%ENDINCL/%ENDEXCL for more details.

Support for generalized conditional IF statements within an ESP job definition of the form:

IF [%]ESP[S|A]xxx oper operand [boolean-oper] THEN [DO]

yyy

zzz

...

[ENDDO]

where

• xxx in the ESP System variable can be any of the following:

  • MMM (month name)

  • MM (month number)

  • DD (day-in-month number)

  • DAY (day name)

  • HH (hour)

  • MN (minute)

  • TIME (hh.mm.ss)

• oper can be any of the following: =, EQ, LE, LT, GE, GT, >, <

• boolean-oper can be: AND, &&, OR, |

• yyy, zzz, ... are any ESP statements

is as follows:

• Whenever an internal (within an ESP job definition) IF statement of the above form is encountered, upon conversion the job definition is duplicated with the any of the time criteria represented by the %ESPxxx statement, overriding the original time criteria.

• If the IF block does not contain any scheduling criteria, then the scheduling criteria of the original job definition is copied to the duplicate job definition. Otherwise, the original scheduling criteria are overridden.

• Similarly, the converted values of the ESP yyy, zzz, ... statements override the original values in the duplicated job definition.

• In particular, statements of the type %ESPSHH = hh or %ESPSHH EQ hh are converted as enhanced Cyclic Specific Runtimes hh00. Multiple specific runtimes result when these ESP system variables are connected via ‘OR’ Boolean operators. When %ESPSHH is coded together with %ESPSMN and connected by ‘AND’, the specific runtime is converted to hhmn.

• IF the oper following %ESPSHH is GT, GE or > is specified, then the FROM TIME is used. If LT, LE or < is specified, then UNTIL TIME is used.

• IF clauses with mixed TODAY functions and %ESPSxxx system variables are supported. The last 4 bulleted items specified for TODAY functions apply equally to IF %ESPSxxx formats.

• Partial support is provided for ESP ELSE clauses, which are specified as part of supported IF clauses within job definitions (those IFs which specify scheduling or time criteria, for example IF TODAY(xxx) ... ELSE xxx).

• Only non-nested IF and ELSE clauses are supported.

When schedule criteria is specified in an Event (via the SCHEDULE/NOSCHEDULE keyword), then, if the Event specifies an INVOKE of an ESP procedure (that is, the equivalent of a Control-M DO FORCEJOB), the scheduling criteria is copied from the Event into the invoked Control-M SMART table as a SCHEDULE RBC and all the jobs in the table are made to reference this RBC. Whenever an event’s RBC is copied into a SMART table, all the jobs’ RBC RELATIONSHIP parameters are set to A (AND). Multiple SCHEDULE RBC definitions may be added to a SMART table when multiple Events invoke the same table.

Calendars

CA ESP events may optionally be associated with a CA ESP calendar. When the CA ESP schedule function runs, it uses a calendar to determine the workdays, holidays, and other terms in the [NO]RUN parameter which must be resolved. Users can explicitly define a calendar to be used using the CALENDAR statement or can depend on the CA ESP default calendar or the SYSTEM calendar if no default calendars are defined.

The conversion tool converts these calendars to IOA Calendars for use in the converted job scheduling definitions. In addition, when ESP calendars define ‘Special Days’, periodic Control-M calendars are created, with the name #calname, and are used in job definitions which reference these Special days. For additional information on Special days, see 68. Calendar Special days names.

For RUN or TODAY statements that specify the 'HOLIDAY' keyword, holiday calendars are built with the name @calname.

Templates

CA ESP scripts may contain templates which can be used as models to generate one or more script statements within the CA ESP script file. This not only saves the user from repeating many similar statements or jobs but also allows the user to substitute symbolic variables for parameters that might change for individual invocations of the script lines on which they are contained.

The conversion tool supports templates by expanding the template invocations into their full script lines and by resolving all positional and keyword symbolic variables defined locally in the template. The conversion also resolves variables defined externally to the template (but in the same member or defined with an INVOKE command). Variables defined on the template invocation whose values are continued on multiple lines are not supported.

Symbolic Variables

CA ESP symbolic variables are objects whose value can be changed during CA ESP Workload Manager processing. They can be inserted in various different places, such as

• CA ESP Workload Manager Procedures

• Job documentation members

• Events

• JCL

• Symbolic-variable libraries

• SYMLIB command in Events

• Global-variable tables

• CA ESP Workload Manager initialization parameters

• USER1, USER2, USER3, and USER4 parameters

  By default, SETVAR values USER1=USERn (n=1,2,3, and 4) are added to every folder definition.

• Text of the TITLE and FOOTING commands of CA ESP Workload Manager

Control-M converts CA ESP symbolic variables to Control-M AutoEdit variables within job scheduling definitions, event rule definitions and converted JCL members.

Control-M Event Manager

In Control-M, the Control-M Event Manager (CMEM) manages external events. CMEM performs predefined actions in response to the occurrence of events in the system. Several types of CA ESP events are converted to CMEM rules:

• In CA ESP data set triggering events can be used to indicate job dependency. This is accomplished using the CA ESP DSTRIG statement. The CA ESP DSTRIG statement is equivalent to the CMEM DSNEVENT event, which adds prerequisite conditions to the IOA Conditions file.

• For details on the exact conversion process, see 7. DSTRIG. For more information regarding the CMEM facility, see the Control-M for z/OS User Guide.

• In addition to data set triggering, the CA ESP CCCHK and CCFAIL statements can be used to identify specific completion codes and indicates how CA ESP will handle the job when those completion codes are matched. When an action of STOP is specified, the CCCHK statement is converted to a CMEM ON STEP rule that contains a DO STOPJOB statement. For further details, see 21. CCFAIL and 22. CCCHK/EXITCODE.

• the CA ESP NOTIFY JOBSTART EVENT(event-id) statement can be used to trigger an ESP event when a job starts. The event-id is associated with a converted Control-M table and a CMEM ON JOBARRIVAL rule is created that contains a DO FORCEJOB statement for the corresponding table. For further details, see 31. NOTIFY.

• An ON JOBARRIVAL rule specifying DO FORCEJOB is created when an ESP job definition specifies a HELD_MANUAL job, which is a job that is submitted externally to ESP with TYPRUN=HOLD in its JCL. For further details, see 76. HELD_MANUAL.

• An ON JOBARRIVAL rule specifying DO FORCEJOB is created when an ESP Mainframe job definition specifies an EXTERNAL job whose ‘home’ definition cannot be found. For further details, see 45. EXTERNAL, APPLID.

Events

In CA ESP, an event is a basic unit of work that defines when CA ESP must perform workand the actions it must take to do so. The trigger for an event can be:

• a scheduled date and time

• a data set trigger

• a manual trigger

• a job monitor or alert trigger

• a signal with a scheduled date and time

CA ESP events can perform a variety of tasks, including:

• sending a message to you, other users, or operator consoles

• submitting JCL

• invoking a CA ESP procedure

• issue an operating system command

CA ESP events are converted to Control-O ON EVENT, JOBARRIVAL, JOBEND and DSNEVENT type rules. These rules are triggered by runtime conditions, as designated in the Control-O Runtime Scheduling parameters, and by data set events.

In CA ESP an Event can be defined with the REPLACE attribute which indicates that it is a new Event. If one already exists with the same name, it is to be replaced. The conversion ignores this attribute since this is the default action taken by Control-O.

An internal parameter, PRCPATH, determines the methodology of converting the ESP Events file and Procedure libraries. This parameter is set so that the conversion only processes ESP procedures that are referenced via ESP Event INVOKE statements or embedded procedures. Unreferenced ESP procedures are ignored.

Events that INVOKE an ESP procedure cause the conversion tool to copy any scheduling criteria specified in the event (via a SCHEDULE statement) to an RBC in the corresponding table entity created from the ESP procedure, if it exists. This RBC overrides the existing default RBC in the table (named NULL) with which the table was initially created. If no scheduling criteria was specified in the Event, then the NULL RBC (which contains WDAYS ALL) remains. This RBC determines when the SMART table will be scheduled and limits the scheduling eligibility of all the table’s jobs. The actual scheduling of any individual job is then determined by any RBCs and local scheduling criteria in the job definition. In addition to scheduling criteria, run-time criteria (time from, time until, interval) are also copied to the table-entity. When a Control-O rule has a non-zero interval, the corresponding scheduling table is converted into a cyclic-table. The Control-O rule from which the scheduling criteria is copied remains unchanged, since the rule might perform other actions besides the INVOKE statement. The INVOKE statement, which is usually converted to Control-M DO FORCEJOB, is removed from the Control-O rule. If no DO actions remain in the Control-O rule after all the INVOKE statements are converted to DO FORCEJOBs, then the entire rule is removed from the Control-O member.

Multiple ESP Event rules which INVOKE the same procedure but have different scheduling criteria cause multiple schedule RBCs to be added to the corresponding table definitions. In such a case, if the multiple ESP Events also have different FROM times specified, then a warning message is issued about the different times.

However, when multiple events specify DO FORCEJOB and the events have the same scheduling criteria and different FROM times, then instead of adding another (duplicate) RBC, the table is turned into a Cyclic table by using the enhanced cyclic-specific run times. When there is no time specified, the Newday time is used. When the Event specifies SUSPEND/RESUME commands, the respective times are placed in the TIMEUNTIL/TIMEFROM parameters.

In all cases where a SMART table is converted to a Cyclic table, the KEEP JOBS UNTIL REMOVED field is set to Y. Similarly, in all cases where a TIMEFROM is added to the table entity, or the table is turned into an Enhanced Cyclic table, then any SAC indicator is disabled (blanked). For details, see AAbsolute vs. Logical Days and New Day Processing.

For ESP EVENTS which contain WOBTRIG FILE_TRIGGERRING commands see 9. [xxx_]JOB name

ON EVENT rules are particularly useful for time-initiated events and pro-active processes. For details on how the CA ESP events are converted to Control-O rules, see Conversion Details

CA ESP events can contain embedded CA ESP procedures. These embedded PROCs are supported as follows:

The embedded 'PROC' statement is internally converted to an ESP INVOKE any-lib-name(procname) statement, where procname is PROCnnnn (nnnn is a sequential number).

The PROC ending with the 'ENDPROC' statement is then added to the file containing the CA ESP procedures and removed from the event.

Production Control

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

Absolute vs. Logical Days 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.

In CA ESP, 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 ESP 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 ESP 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 ESP scheduling criteria based on the New Day/Logical Day time differences.

Warning: Due to the differences between Control M and CA ESP, BMC strongly recommends that you set the Control-M Newday time to 00:00 (midnight), as a best practice. In this manner, you avoid potential problems in scheduling synchronization of jobs that specify various time constraints and in external job scheduling, limitations on Control-M distributed job scheduling, and problems in scheduling coordination of jobs and their invoking events that have differing time criteria.

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

When an ESP Event time requires a SAC parameter to be set to P (that is, it is scheduled before Newday time), then SAC=- is placed on the folder and is propagated to every job in the folder as SAC=P. The SAC value of '-' prevents the folder from being ordered on its original scheduling days (as would normally happen with SAC=P), so that it is ordered only on the previous scheduling days. In addition, if any job in the folder normally would not have required SAC=P (its time being after Newday), then a Days-offset of +1 is added to the job definition besides the SAC.

When an Event time does NOT require the SAC parameter, then SAC is removed from every job in the folder, even if a job's time is earlier than Newday.

All of the above is done regardless of whether the DELAYSUB specifies TOMORROW.

Jobs on Distributed Platforms

CA ESP supports jobs running on a variety of distributed platforms such as Windows NT, AS400, UNIX, AIX, SUN, HPUX, LINUX, NCR, FTP, SCP, SAP, INFORMATICA, TANDEM, and PEOPLESOFT. The Control-M conversion tool supports CA ESP scripts which specify distributed job definitions. These definitions contain a variety of parameters which are specific to the distributed environment and have no counterpart in Control-M mainframe job definitions.

Since the conversion tool is run on the mainframe platform, these parameters (AGENT, SCRIPTNAME, SHELL, CMDNAME, CLPNAME, ARGS, EXITCODE, ENVAR, FILENAME, JOBNAME, SQL, TEXTSTRING, etc.) are initially converted to SETVAR definitions and then post-processed by the Control-M 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.)

In addition to jobs on distributed platforms, CA ESP also supports the following:

• file triggering for files that originate on distributed platforms (FILE_TRIGGER or FM), which allows building jobs that contain a dependency based on file activity. The conversion tool supports distributed file triggering by converting the CA ESP FILE_TRIGGER event into a distributed File Watcher job definition.

• jobs that execute SQL queries, which contain SQL statements such as SELECT, DELETE, UPDATE, or INSERT. The conversion utilizes various SETVAR and CM (Control module) parameters to pass information about the SQL query to Control-M/EM.

• jobs that monitor the contents of a distributed platform text file, which searches for a text string. Typically, these jobs monitor for an error message in a log file after execution of a script

• For several of these platforms (FTP, SCP, SAP, SQL), the conversion tool creates XML Account scripts containing the necessary global information needed to execute jobs on that platform.

For more information about the above features, seeConversion Details

Restart Automated Rerun and Restart Processing

In ESP, automated rerun and restart job processing is accomplished using an interface to CA Workload Automation Restart Option ESP Edition and/or CA Workload Automation Restart Option for z/OS Schedulers (CA-11), if they have been installed. ESP can automatically insert CA-11 JCL steps into jobs scheduled and submitted by ESP.

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

• RET-DAYS and RET-GENS

When Control-M/Restart is installed with Control-M, the following ON PGMST statement is inserted into the mainframe (non-Started task) job scheduling definitions only:

ON PGMST ANYSTEP CODES EXERR
DO IFRERUN FROM $EXERR
DO RERUN

In addition, many global Control-M/Restart functions are set in the CTRPARM member of the IOA PARM library (such as NFILVS99, ERRORRC, ABNDTYP, ENHGDG, SAMEGDG, IGNGFGMB, and ALLRUNS) and default Control-M/Restart parameters can be overridden by using control parameter members in the library allocated to the DACTRCTL DD statement of the CONTROLR step. For more information, see parameters NONRESTARTABLE_STEP, [NO]RECAPTCC/[NO]RECAPTABEND, [NO]STEPADJUST, EXCLUDE DSN, and the $EXCLUDE member in the Control-M/Restart User Guide.

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.

There is currently no support for the CA-11 U11RMS JCL step (RUN HANDLER) in the ESP JCL libraries.

In CA-11, the user option module is generated by the U11OPTBL macro, which codes the default return code value issued by CA-11 during rerun processing. If this value is not 0, you must specify the ADDPROC, PROCRC, and NCT2RC parameters in the CTRPARM member of the IOA PARM library. These parameters globally simulate the action of CA-11 in passing the desired return code to subsequent job steps, and are described in the INCONTROL for z/OS Installation Guide: Customizing. Specify these parameters as follows:

• ADDPROC – use the value of the INSRTPC option in the U11OPTBL CA-11 macro which specifies the procedure name that the CA-11 SMF IEFUJV exit will insert into a job's JCL. The value specified by procname should correspond with the name given to the CA-11 U11RMS procedure in the system PROCLIB. CA11RMS is the default value of the procedure name to be inserted by the IEFUJV exit.

• PROCRC – use the value of the RETCODE option in the U11OPTBL CA-11 macro which specifies the default return code value issued by CA-11 during rerun processing.

If you want the Control-M/Restart step to simulate a nonzero return code during the original run of the job for NCT2 processing, specify NCT2RC.

For job level control of the above options specify the following auto-edit variable as SETVARs in the job scheduling definitions: %%ADDPROC (restart proc step name), %%RSTCODE (RC to be returned by ADDPROC step) and %%NCT2CODE (RC to be returned for NCT2 Run).

If you use the CA-11 U11VOLCX macro (Volume INCLUDE/EXCLUDE list) or the U11UCSEX exit (Uncatalog/Scratch exit), you must either specify corresponding Control-M/Restart EXCLUDE DSN statements, or Exit 1 (CTRX001) to perform the equivalent function.

The following ESP ENCPARM sub-parameters are supported the by the conversion:

• AUTOREST – The conversion tool converts AUTOREST to the Control-M/Restart [NO]STEPADJUST parameter specified in the local member of the DACTRCTL library for the job.

  • The following sub-parameters are converted to STEPADJUST: YES (default), ALWAYS, TEMPONLY(YES), NEWPASS(YES)

  • The following sub-parameters are converted to NOSTEPADJUST: NO, TEMPONLY(NO), NEWPASS(NO)

• CLEANUP – The conversion tool converts CLEANUP to the Control-M/Restart PREVENT-NCT2 job scheduling parameter as follows:

  • The following sub-parameters are converted to PREVENT-NCT2=Y: INITIAL/RESTART(YES)

  • The following sub-parameters are converted to PREVENT-NCT2=N: INITIAL(NO)

  • For sub-parameter DYNALLOC(YES) see parameter NFILVS99 in member CTRPARM of the IOA PARM library.

• CONDCODE –

  • For sub-parameter INITIAL/RESTART(N|0) see parameter ERRORRC in member CTRPARM of the IOA PARM library.

  • For sub-parameter FAIL(CC(DFLT)|ABEND) see parameter ABNDTYP=[CC|UABEND] in member CTRPARM of the IOA PARM library.

• FORCE - The conversion tool converts FORCE to the Control-M/Restart PREVENT-NCT2 job scheduling parameter as follows:

  • The following sub-parameters are converted to PREVENT-NCT2=F[lush]: NO

• The FROMSTEP and TOSTEP parameters will not be processed by the conversion tool since they will not be encountered in the ESP procedure library as they are only specified for external jobs via batch restart JCL. The Control-M equivalents are the ON PGMST …. DO IFRERUN FROM|TO statement

• GDGADJ – see parameters ENHGDG, SAMEGDG, IGNGDGMB in member CTRPARM of the IOA PARM library.

• HONORCC – The conversion tool converts HONORCC to the Control-M/Restart [NO]RECAPTCC|[NO]RECAPTABEND parameter specified in the local member of the DACTRCTL library for the job.

  • The following sub-parameters are converted to RECAPTCC: ALL

  • Also consider setting the ALLRUNS parameter in member CTRPARM of the IOA PARM library.

  • The following sub-parameters are converted to NORECAPTCC: NONE

• IGNOREDS - The conversion tool converts IGNOREDS DSNAME/JOBNAME/DDNAME/PGMNAME to Control-M/Restart parameters specified in members of the Control-M/Restart DACTRCTL library for the job as follows:

  • Depending on which sub-parameters are specified, the conversion produces two different results. If the DSNAME parameter is specified, then the conversion writes an 'EXCLUDE DSN' statement to a local job-specific member of DACTRCTL and ignores any other sub-parameter (DDNAME, PGMNAME).

  • If the DSNAME parameter is not specified, then the conversion adds a record to the '$EXCLUDE' member of the DACTRCTL library and fills in the JOBNAME (default is this job) and DDNAME fields. PROCSTEP and PGMSTEP are specified as '*'.

  • Generic values (indicated by ‘-’) are supported. PGMNAME is not supported.

• NODELETE – see the IGNOREDS parameter.

• NRDD is not supported. The only DD names which Control-M recognizes as indicating nonrestartable steps are CTRNORST, CA11NR and UCC11NR. Nonrestartable steps in Control-M/Restart may also be specified using the NONRESTARTABLE_STEP [procstep_name].pgmstep_name statement in a local member of the library pointed to by the DACTRCTL dd statement.

• NRSADJ - The conversion tool converts NRSADJ to the Control-M/Restart [NO]STEPADJUST parameter specified in the local member of the DACTRCTL library for the job.

  • The following sub-parameters are converted to STEPADJUST: YES.

  • The following sub-parameters are converted to NOSTEPADJUST: NO (default)

• PREDICT – The conversion tool converts PREDICT to Control-M/Restart parameters in the DACTRCTL library; application-level PREDICT writes to $DEFAULT member, and job-level PREDICT to the corresponding local member. Sub-parameters are converted as follows:

  • SECURITY(NO) is converted to NOCHKSEC

  • DUPNAME(NO) is converted to PREVENT-NCT2=N

  • PROG(IDCAMS) will issue warning message CTMESP12-02W, which explains that parameter NFILVS99 in the IOA parm library needs to be set to Y to support this option

  • NOTCAT2 is converted to PREVENT-NCT2=N

  All other sup-parameters are ignored.

• PURGE will not be processed by the conversion tool (even if it appears in a job or application definition) since it is set in the ESP Initialization Parameter data set. The Control-M equivalents are the Control-M History file parameters RET-DAYS (corresponding to the ESP AGE parameter) and RET-GENS (corresponding to the ESP KEEP parameter).

• TAPESCR – If the ENCPARM TAPESCR command is used to request that a tape be scratched then you must implement the Control-M/Restart interface with a Tape Management System. This interface is 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.

The following ESP OPTIONS sub-parameters are supported by the conversion:

• [NO]RESTARTSTEP, [NO]FORMAT – set the Control-M PREVENT-NCT2 parameter to either Y or N (for NORESTARTSTEP/NOFORMAT).

The following ESP ENCPARM parameters are not supported by the conversion:

ABENDER, BACKOUT, COMMENT, DELETE, DIAG, EXCLUDE, JOBID, JOBNAME, MODE, MODIFY, NOIGNORE, PREVTIME, PRINT, QUIESCE, RESTART, STATUS, SUBSYS, TRACE, TYPE, VOLUME, WARNING

Control-M CA ESP Conversion Tool

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

The conversion

• builds the Control-M tables, CMEM definitions and Control-O rules, based on the CA ESP procedures and events

• creates XML scripts for job definitions and calendars for uploading to Control-M/EM

• converts CA ESP JCL variables and %INCLUDE/%EXCLUDE statements to Control-M format

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

• issues messages if problems and errors are encountered

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