Conceptual Overview

This chapter includes the following topics:

Introduction

This overview is intended for production control personnel who are familiar with OPC terminology. Experience with Control-M is recommended.

The OPC 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 OPC scheduling elements into functionally equivalent processes in Control-M.

The conversion tool converts OPC application, operation, calendar, and period information to appropriate Control-M job scheduling and calendar definitions. OPC concepts and parameters are translated to corresponding Control-M concepts and parameters. For more information on the OPC conversion tool, see Control-M OPC Conversion Tool.

The OPC Conversion tool also supports the conversion of distributed job definitions. For details, see JOB3: Construct Control-M Calendars, Table and CMEM Libraries.

Application Definition and Control-M SMART Table Scheduling

OPC applications are converted to Control-M SMART Tables.

In OPC, job grouping is performed by connecting a group of logically related operations into a single application. In Control-M, logically related jobs are grouped into Control-M SMART Tables, and each application is converted to one SMART Table.

The conversion tool supports the handling of related jobs as a group by creating them in a special table called a SMART Table. Scheduling and group handling criteria for the entire group of jobs are specified in the SMART Table Entity. For additional information on Group Scheduling, see the discussion of handling of job groups in the Control-M for z/OS User Guide. The conversion supports like-named Applications with different VALID FROM - TO dates. The Application Name file (see JOB1 Output) is used to ensure that the corresponding tables are created with unique names.

The conversion tool creates one Rule-Based Calendar (RBC), which contains basic scheduling criteria in the SMART Table Entity for each normal run cycle defined in the OPC application. The OPC Period name is specified as the RBC name. OPC applications not containing run cycles are converted with the RBC name #RBCDFLT, which contains default values for the basic scheduling parameters. All jobs in the SMART Table refer to RBCs defined in the SMART Table Entity, using the generic RBC name ' * '.

The SMART Table Entity also controls the ordering and runtime scheduling criteria of the entire application, by specifying the following:

  • Control-M SCHEDULE ACTIVE FROM and SCHEDULE ACTIVE UNTIL dates derived from the OPC Run Cycle Valid From and To dates.

  • Control-M TIME FROM and TIME UNTIL times derived from the OPC Arrival and Deadline times.

  • Control-M KEEP JOBS UNTIL REMOVED is set to Y.

OPC also allows you to group applications by assigning each application a Group Definition Application ID. These Group Definition Application IDs point to a common Group Definition, with the result that the applications inherit the run cycle definitions specified in the Group Definition. When the conversion tool converts OPC applications that point to Group Definitions, the Control-M RBCs corresponding to the run cycles in the OPC Group Definition Application ID replace the RBCs in the Control-M SMART Table Entity. For users of Control-M v9.0.18 and above, this inheritance includes OPC Applications that have multiple offset-based run cycles defined for the purpose of executing the operations contained therein more than once a day, which are converted to Control-M cyclic tables using the Enhanced Cyclic feature (specific run times execution). See 27. Rule/Period Name for details.

Job Predecessor and Successor Relationships

OPC predecessor and successor job relationships are translated to appropriate Control-M prerequisite IN and OUT conditions.

In Control-M, each OPC operation dependency, that is, job flow, is implemented using 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. A condition date reference is associated with each condition.

  • 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. The job is submitted for execution only if all IN conditions with the required date exist in the IOA Conditions file.

  • An OUT condition for a job is a prerequisite condition that is added, generally, to the IOA Conditions file upon completion of the job. Ajob is considered to be ended OK if it terminates with a condition code of less than 5 in all its steps. This is the default.

OPC manual workstation operations (GENERAL and PRINT) are converted to Control-M manual dummy jobs containing IN conditions.

In Control-M, the ADJUST CONDITIONS parameter, which is described in the Control-M for z/OS User Guide, determines whether IN prerequisite conditions are to be ignored if the predecessor jobs that set the conditions are not yet scheduled. The ADJUST CONDITIONS parameter appears in the SMART Table Entity, and applies to all jobs in the SMART Table. The conversion program sets this parameter to D, to correspond to the OPC conditional handling of predecessor prerequisites. You can do the same for OPC external dependencies, which are described in 5. Operation Dependencies, by setting the MAYBE conversion parameter appropriately. For more information on this conversion parameter, see "MAYBE" in Conversion Parameters. For more information on the ADJUST CONDITIONS parameter, see Unique Control-M and Control-M/Restart Parameters.

Quantitative (Workstation) Resources

OPC operations may require a maximum of three different workstation resources: server, resource 1, and resource 2. These resources are converted to Control-M Quantitative resource statements. For more information, see 7. Workstation Resources, Workstation Servers.

Data Dependencies

OPC special resources (data dependencies) are converted to Control-M CONTROL resources or Quantitative resources.

In OPC, SHR or EXC allocation status is assigned to each special resource. The resource availability status can be changed from YES to NO by a program. The resource is considered in use by the operation until the operation is rerun and reaches completed status.

In OPC, data dependencies perform the following functions:

  • They control parallel execution of operations (jobs).
    In Control-M, this is implemented by using CONTROL resources.

  • They validate availability of the resource.
    In Control-M, resource validation is performed using IN conditions.

In Control-M, CONTROL resources can be used in exclusive or shared state. If a CONTROL resource is used in an exclusive state, then only the job that acquires it first can use it. A CONTROL resource that is used in a shared state can be used to control the parallel execution of jobs.

When conversion option SPECCND specifies Y, N or D (see Conversion Parameters) and the OPC Special Resource has numeric value in the quantity field, a Control-M Quantitative Resource is created instead of a Control Resource. When SPECCND is set to Q, a Quantitative Resource is always created, and a blank or '*' in the quantity field is interpreted as a quantity of 1.

A GDG control or quantitative resource of the form dsname.gdg(+|-nnn) is converted to dsname.gdg*.

Run Cycles, Calendars, and Periods

OPC provides two methods for specifying date-based scheduling criteria.

In OPC/ESA, you can specify rule-based run cycles so you can define date-based scheduling criteria through a rule-based language. These rules are converted into Control-M basic scheduling criteria. For example the OPC rule:

Copy 
ONLY(005 007 009) DAY(WORKDAY) MONTH

is converted as follows:

  • The DAYS Control-M parameter is set to D5, D7, D9.

  • The DCAL Control-M sub-parameter is set to WORKDAY.

The OPC free-day rule is also converted into the Control-M CONFCAL and SHIFT parameters.

Scheduling can also be specified by offset-based run cycles. In this case, the conversion tool creates Control-M calendars only, based on the OPC offset run cycle, calendars, periods, and free-day rule.

OPC Applications that have multiple offset-based or rule-based run cycles defined for the purpose of executing the operations contained therein more than once a day are converted to Control-M cyclic tables using the Enhanced Cyclic feature (specific run times execution). For details, see 27. Rule/Period Name. OPC Applications with rule-based run cycles can also be converted to Control-M cyclic tables under additional circumstances. For details, see 41. ADRULE, REPEAT, and SHIFT (Rule-Based Run Cycle) (for OPC/ESA Release 3 and Later Only). Only run cycles that have non-expired VALID-TO dates participate in the process of creating cyclic tables.

JCL Processing

  1. OPC JCL batch operations that issue the SRSTAT and OPSTAT commands are converted to equivalent Control-M JCL steps, which execute utility CTMUTIL. For more information, see Conversion Details.

  2. OPC JCL directives and variables operations are converted to Control-M AutoEdit statements and JCL steps.

    1. OPC/ESA JCL directives, namely BEGIN, END, FETCH, SEARCH, TABLE, RECOVER, SCAN, SETFORM, and SETVAR.

      • Allow the conditional execution of blocks of JCL statements.

      • Allow the inclusion of external JCL statements.

      • Allow the inclusion of variable tables used to assign initial values to JCL variables.

      • Enable job rerun and restart.

      • Determine whether variable substitution is to occur.

      • Defines the format of dynamic-format supplied variables.

      These OPC directives are converted to equivalent Control-M AutoEdit statements and job scheduling parameters, as follows:

      • %%GLOBAL defines a member that contains a set of user-defined variables and their assigned values.

      • %%INCLIB defines a library or DDstatement that is to be included in the current job stream.

      • %%IF, %%ELSE, and %%ENDIF provide the Control-M AutoEdit facility with powerful Boolean logic capability.

      • %%GOTO provides the Control-M AutoEdit facility with GOTO logic, permitting simple inclusion or exclusion of job steps, DDstatements, input statements, and so on.

      • ON PGMST... DO job scheduling parameters define post-processing parameters for job rerun and restart actions.

      • AutoEdit variables and functions.

    2. The & and % variables are converted directly to Control-M AutoEdit variables and are placed in a Control-M AutoEdit variable library. For more information, see 16. &, %, and ? Variables (for OPC/ESA Only). ?-variable types are partially supported.

  3. PSS (MVS Production Shop Support Program: Job Preparation and Submission) special JCL comment statements and JCL variables are converted to Control-M AutoEdit statements and variables. Thespecial PSS JCL comment statements are converted to %%SET AutoEdit statements and % variables are converted directly to AutoEdit variables. For more information, see Items 30 through 34 in Conversion Details.

  4. Members in JCL libraries that contain parameters for distributed (non-mainframe) job definitions. For details, see Jobs on Distributed Platforms.

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.

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

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

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

Figure 1 New Day Processing

The above example assumes that your logical business date changes at 8:00 A.M. You want to take a job scheduled in OPC 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 OPC job to a Control-M job that begins at 4:00 A.M. on the March 14th logical business day.

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

The conversion tool handles this conversion process automatically.

For OPC/ESA Version 1, Release 2.1 and later, set the CTMPARM DAYTIME parameter New Day time to the Work-Day End Time in the OPC/ESA Calendar that controls most of the work at the site.

For more details on how the conversion tool handles this product difference, see Post Step 2: Perform Final Adjustments.

Converted SMART Tables and the SAC Parameter

If any jobs in a converted SMART Table scheduling 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 set to P) and the previous day (for jobs not set to P). If all the jobs in the table have SAC set to P, then the SMART table entity's SAC parameter is set to '-'. This causes the table to be scheduled only once on the 'previous' day.

Event-Trigger Tracking (ETT)

The OPC/ESA ETT facility corresponds to the Control-M CMEM facility. It is your responsibility to manually convert OPC/ESA ETT events to corresponding CMEM events by coding the appropriate CMEM rule definitions. For more information, see the CMEM chapter in the Control-M for z/OS User Guide.

Catalog Management

The catalog management (CM) function in OPC/ESA can be used to automatically delete, uncatalog, or catalog data sets that have been created or modified in a job or started task that has ended in error, or requires rerun. In addition, references to relative generation data group (GDG) numbers are reset.

In Control-M, the equivalent function is performed by setting the Control-M/Restart PREVENT-NCT2 parameter. Conversion parameter CTR must be set to Y (Yes) and conversion parameter NCT2 must be set to OPC to activate this feature. These conversion parameters are described in Conversion Parameters.

When converting from a previous release of OPC, you have the opportunity of utilizing the Control-M/Restart PREVENT-NCT2 feature on a global basis, rather than on a job-by-job basis as in OPC/ESA Release 2, by setting to Y (Yes) the conversion parameters CTR and NCT2.

Automatic Event Reporting (AER) Facility

The OPC Automatic Event Reporting facility (AER) can help coordinate a variety of tasks that are not normally seen by OPC. For example, AER can be used to trigger the start of an operation when a particular step in a job is complete, or as acknowledgment that a file has been received across the network. The OPC OPSTAT command provides a portable method of using AER, by enabling the setting or changing of the status of an operation.

The OPC OPSTAT command in JCL steps can set a "job successfully completed (C)" status. The conversion program converts this to a Control-M batch JCL IOACND step, which adds a condition to the IOA Conditions file. For more information, see 25. OPSTAT.

Job Completion Checker (JCC) Facility

The OPC JCC feature does the following:

  • Scans the sysout data set of a job or started task to set an error code for an operation.

  • Records error conditions in an incident log file.

The conversion tool converts the OPC EQQJCCT macros in the JCC message table members of the EQQJCLIB library into Control-M ON SYSOUT parameters in the job scheduling definitions. See Conversion Steps for details.

In addition, you may also obtain similar functionality by using Control-M Exit 3 to do the following:

  • Alter the way in which a job in Control-M finishes.

  • Turn on an event for the current job.

  • Write a message to the Control-M log.

  • Extract data from the sysout and write it to an external file for use later.

JCL Repository Facility

OPC stores JCL in the JCL repository (JS) data set when the JCL is edited and saved, or when the job is submitted. This enables you to dynamically make temporary changes to the JCL of a job without changing the original source of the JCL. The same functionality can be obtained in Control-M using REXX procedures CTMIMACx in the IOA CLIST library, where x is 1, 2 or 3.

Using procedure CTMIMACx, JCL is dynamically copied from the MEMLIB library to the OVERLIB library, if no member by that name already exists, and is then edited in 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.

For more information and installation instructions, see 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, and the CTMIMACx source members in the IOA CLIST library.

Control-M OPC Conversion Tool

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

The conversion tool performs the following functions:

  • It converts OPC application, calendar, and period reports to Control-M SMART Tables and creates XML job definition and calendar scripts which can be loaded to Control-M/EM.

  • It converts OPC rule-based run cycles to Control-M basic scheduling parameters.

  • It converts OPC offset-based run cycles, in conjunction with calendar and period reports, to Control-M calendars.

  • It converts OPC operator instructions to the Control-M documentation library.

  • It enables the customer to set unique Control-M and Control-M/Restart options in the job scheduling definitions.

  • It creates a Control-M AutoEdit variables library from the OPC/ESA JCL Variable tables report.

  • It converts JCL libraries to Control-M format.

  • It issues messages about problems and errors found in the OPC reports.

The conversion tool can be locally tailored to fit specific requirements.

Jobs on Distributed Platforms

OPC supports jobs running on a variety of distributed (non-z/OS) platforms such as Windows NT, AS400, UNIX, AIX, PEOPLESOFT, and SAP. The Control-M conversion tool supports OPC scripts that are contained in members of OPC JCL or SCRIPT libraries. These members specify distributed job definition parameters when they are associated to distributed workstations. The information on whether a workstation is distributed is reported in the BCIT workstation report (BCITWS file) created as output of the conversion JOB1.

If one of the Fault Tolerant, zCentric, or Dynamic flags is set to Yes, the workstation is a distributed workstation.

These job definitions contain a variety of parameters that 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 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 (such as NODEID, CMDLINE, or OWNER).

In some cases, when a job is associated with a fault-tolerant workstation, the job's member can be located in the OPC EQQSCLIB JCL library, and it is read and scanned for a JOBREC statement. The JOBREC statement defines the OPC fault-tolerant workstation job properties. A JOBREC is specified for each distributed member of the JCL/SCRIPT library.

JOBREC uses the JOBSCR or JOBCMD sub-parameter to specify the script or command to execute, and the JOBUSR sub-parameter to specify the user who is authorized to run the script or command. These parameters are converted to the Control-M CMDLINE and OWNER parameters, respectively.

When the number of characters in the command line exceeds 62, rather than creating a CMDLINE statement, the conversion places the contents into an embedded script.

A //JOBREC - //END JOBREC block can be specified for zCentric jobs. When a //JOBREC block is coded, the conversion expects the actual script or command to immediately follow and is converted to a Control-M embedded script (multi-line). Inside the block, the JOBCMD(SCRIPT|EXECUTABLE) statement is ignored and JOBUSR(xxx) is used to set the Control-M OWNER parameter. Other keywords in the block, such as STDERROR, STDINPUT, STDOUTPUT, PARM, WRKDIR, JOBPWD (taken from USRPSW in a USRREC statement), and JOBTYPE (non-UNIX script type jobs, such as JAVA) are not supported.

All scripts are converted to embedded scripts, except the following types that are identified as particular cases, for which special support is available:

  • Jobs running in an SAP distributed environment - when the first (non-comment) line in the JCL member, or within a fault-tolerant wrapper (JOBREC/JOBSCR), begins with '-job', an SAP CM compatible job is created as follows:

    • The -job job-name parameter is converted to SETVAR %%SAPR3-JOBNAME=job-name

    • The -user user-id parameter is converted to SETVAR %%SAPR3-STEP-S01-OWNER=user-id

    • The -flag DISABLE_JOBLOG parameter is converted to SETVAR %%SAPR3-STEP-S01-LOG_STDOUT=N

    In addition, the Control-M MEMNAME is set to SAP_R3 and the following parameters are set for SAP CM job creation:

    • APPL_FORM="SAP R3"

    • APPL_TYPE=SAP

    • APPL_VER=7.0.0.200

    • CM_VER=7.0.0.200

  • Jobs running in a PEOPLESOFT distributed environment - when the first (non-comment) line in the JCL member, or within a fault-tolerant wrapper (JOBREC/JOBSCR), begins with '-process', a Peoplesoft CM compatible job is created as follows:

    • The -process process-name parameter is converted to SETVAR %%PS8-PRCSNAME=process-name

    • The -type process-type parameter is converted to SETVAR %%PS8-PRCSTYPE=type

    • The -runcontrol run-control-id parameter is converted to SETVAR %%PS8-RUNCONTROLID=runcontrol-id

    • The -outputtype output-destination-type parameter is converted to SETVAR=%%PS8-OUTDESTTYPE=output-type

    • The -outputformat output-destination-format parameter is converted to SETVAR=%%PS8-OUTDESTFORMAT=output-format

    In addition, the Control-M MEMNAME is set to PS_JOB and the following parameters are set for PEOPLESOFT CM job creation:

    • APPL_FORM=PEOPLESOFT

    • APPL_TYPE=PS8

    • APPL_VER=8

    • CM_VER=6.1.01

  • Jobs running in an AS400 environment - when any AS400 parameter in the job script is specified, an AS400 CM compatible job is created, as follows:

    • %%OS400-CMDLINE1

    • %%OS400-CLPNAME

    • %%OS400-PRTDEV

    • %%OS400-JOBPTY

    • %%OS400-JOBD

    • %%OS400-JOBQ

    • %%OS400-OUTQ

    • %%OS400-INLLIBL1

    • %%OS400-LOGCLPGM

    • %%OS400-LOG

    • %%OS400-JOB_NAME (PGM)

    • %%OS400-JOB_OWNER (USER)

    • %%OS400-CURLIB

    • %%OS400-INLLIBL

    • %%OS400-MEM_NAME (PGM)

    In addition, the following parameters are set for AS400 CM job creation:

    • SETVAR=%%M=AS400_Job

    • APPL_FORM="OS/400 Full"

    • APPL_TYPE=OS400

    • APPL_VER=ALL

    • CM_VER=700

    • %%OS400-AEV_LEN=4000

    • %%OS400-JOB_AUTHOR=conv

    • %%OS400-OBJTYP=*PGM

    • %%OS400-MEM_LIB=*LIBL

For all of the above distributed options:

  • When a JCL member is read, the first record is checked for '//' in column 1. The associated job definitions of such members are treated as MVS (z/OS) jobs. Leading records beginning with '//*','/*', '%%', 'REM', or '#' are skipped.

  • The Control-M NODEID is set, for distributed jobs, to the value specified in the destination field of the WS.EXT file. The user must edit the file and change the NOD_wsnm default values (initially set during conversion by JOB1) with the actual Control-M NODEIDs.

  • The Control-M JOBNAME is set to the JCL member name.

Universal Command Support

The Universal Command program is supported in JCL by creating distributed job definitions with embedded script parameters using the contents of the SYSIN statements in the job's JCL member.

The Universal Command procedure or program name is specified in the UCMDNM conversion option (default value: UCMDPRC).

The SYSIN file contains the following information:

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

  • Command line (plus arguments) specified by the -cmd switch. Command lines may be continued on multiple input lines.

  • DDname of the script file specified by the -s or -script switch.

  • userid (Owner) specified by the -userid switch

  • Job description specified by the -cmdid switch

No other SYSIN parameters are supported.

The SYSIN DD statement may specify a PDS member name or instream (DD *) data or a concatenation of the these.

Information in the SYSIN file is processed in the following manner:

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

  • The userid is placed in the Control-M Owner field.

  • The command line plus associated arguments (from the -cmd switch or from the contents pointed to by the DDname specified by the -s switch) are placed in the Control-M Embedded Script statement.

  • The cmdid text is placed in the Control-M Desc field.

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

Universal Broker Support

The Universal Broker program is supported in JCL by creating distributed job definitions with embedded script parameters using the contents of the SYSTSIN statements in the job's JCL member.

The Universal Broker procedure or program name is specified in the DSPGMNM option (no default).

The DS script name for all Universal Broker jobs is specified in the conversion option UBSCRIPT (no default value).

The SYSTSIN file contains the following REXX invocation:
STARTUVB host-name xxxx arguments

Information in the SYSTSIN file is processed in the following manner:

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

  • The second parameter xxxx is ignored.

  • The script name specified in option UBSCRIPT plus the arguments are placed in the Control-M Embedded Script statement.

  • The STARTUVB statement may be continued on multiple input lines.

The Control-M Owner is taken from the OPC AD report

Multiple Universal Broker steps within a single job are supported (that is, all the script lines are concatenated together), as long as the host names specified in the different steps are the same.

SSH Support

The SSH program is supported in JCL by creating distributed job definitions with embedded script parameters using the contents of the SYSTSIN statements in the job's JCL member.

The SSH procedure or program name is specified in the DSPGMNM option (no default).

The DS script name for all SSH jobs is specified in the conversion option SSHSCRPT (no default value).

The SYSTSIN file contains the following REXX invocation:
STARTSSH|STARTJOB host-name arguments

Information in the SYSTSIN file is processed in the following manner:

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

  • The script name specified in option SSHSCRPT plus the arguments are placed in the Control-M Embedded Script statement.

  • The STARTSSH statement may be continued on multiple input lines.

The Control-M Owner is taken from the OPC AD report

Multiple SSH steps within a single job are supported (that is, all the script lines are concatenated together), as long as the host names specified in the different steps are the same.

OPC Long-term Plan (LTP)

The OPC LTP is a high-level plan that can cover a length of time from 1 day up to 4 years consisting of data from the application description database, calendar and period definitions and the current LTP, if one exists.

When an application or job is scheduled in the LTP or current plan, it becomes an occurrence. OPC examines every application and job to determine if an occurrence should be generated in the LTP. An occurrence is generated if an active application has a run cycle with a period and calendar combination that falls within the LTP range. If an application or job has been specified as belonging to a group definition, the run cycles and calendar definition are extracted from the group definition, and an occurrence group is created in the LTP. An occurrence group consists of application occurrences that reference a group definition and have the same input arrival date and time.

Occurrences from the old LTP that you have added, deleted, or changed manually are carried over to the new LTP, except when OPC is creating a new LTP.

The LTP contains an occurrence entry for every planned run of an application. Most applications generate several occurrences in the LTP. Every occurrence in the LTP is uniquely identified by the occurrence name, input arrival date, and time. The input arrival time is calculated from the run cycle defined to the application or job or from the group definition if the application is a member of a group. The LTP also contains external dependency information produced from data in the AD database. It does not, however, know the relationships between operations making up an application.

As time goes on, you can extend the LTP to cover future periods.

When you create your LTP, you specify the start date. Occurrences, however, are not maintained as far back as this date as this would expand the LTP data set indefinitely. When you create a new current plan (NCP) part of the process is to update the LTP with any occurrences that are now complete in the current plan. When you extend or modify the LTP, completed occurrences are removed. The length of the LTP is calculated from the date of the earliest occurrence it contains, that is, from the date of the earliest uncompleted occurrence, and not from the LTP start date.

OPC does not delete occurrences from the LTP that are uncompleted or any occurrences that follow an uncompleted occurrence. OPC deletes occurrences on a day-by-day basis. That is, all occurrences--or none--are removed for a particular day. Hence, non-completed occurrences in the LTP, all occurrences scheduled for that day and all following days are retained, whether the occurrences are completed or not. As part of OPC maintenance, you can assess such uncompleted occurrences and take suitable action, such as manually mark the occurrences as complete, or delete non-required occurrences.

The current plan, which is the OPC detailed schedule, is based on the occurrence information stored in the LTP.

Implementing the LTP Concept Under Control-M

This procedure describes how to implement the LTP concept under Control-M.

Begin

  1. Build a User-Daily job in the following way:

    Copy 
    //DAILY     EXEC CTMDAILY
    //DACHK    DD    DISP=SHR,DSN=parm_lib(date_control_record)
    //DAJOB   DD *                                                    
    ORDER DSN=library MEM=table-name ODOPT=RUN ODATE=%%ODATE   

    Repeat the above line for each table included in the User-Daily.

    See the INCONTROL for z/OS Administrator Guide for further details on creating User-Daily jobs.

  2. Force the User-Daily job, with the future ODATE. This job must be ordered through Control-M.

  3. Run the user-daily as explained above, day after day for the number of days needed. For example, run the user-daily on Friday. After it completes, run it for Saturday and then for Sunday and then for Monday, if needed.

  4. When running for a future date, the User-Daily will prompt the operator for confirmation. Reply either manually or by setting a Control-O rule.

  5. The User-Daily that would normally run on the days that are already loaded, will detect that this is a second run for this data, and notify the operator and ask for guidelines. Set a Control-O rule to tell it to skip that run.

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.

The following OPC feature is converted to CMEM rules: When the Automatic Submission MVS Job option in the OPC/ESA Application report specifies N, a Control-M CMEM On Spool rule for the externally submitted job is created to bring it under the control of the Control-M monitor. For details, see 20. Automatic Submission Option (for OPC/ESA Only).