Conversion Process Flow

This appendix includes the following topics:

Overview of Conversion Process Flow

This section describes in detail the components of the conversion process from the perspective of jobs, programs, and data sets. A familiarity with the conversion process will help you understand the conversion logic and the installation and operation steps discussed in Conversion Steps.

The process comprises the following primary jobs:

Table 5 Jobs in the Conversion Process

Job

Description

JOB0

Produce CA-7 reports.

JOB1

Produce an updated LJOB report file, a list of job names used as a basis for Control-M table names, and create the Control-M Calendar library and the Calendar Names List file.

JOB2

Create Control-M tables, CMEM rules, and XML definitions.

JOB3

Convert JCL members.

JOB4

Convert CA-DRIVER procedures and JCL libraries.

JOB0

JOB0 performs Stage 1 of the conversion (see Stage 1. Data Extraction).

The following CA-7 commands are executed to extract all required information:

Begin

  1. LJOB,JOB=*,LIST=NODD retrieves job and scheduling information from the CA-7 database and produces the LJOB report file.

  2. LSCHD,JOB=*,LIST=BYSID retrieves scheduling information from the CA-7 database and produces the LSCHD report file. (If you override the value of JOB to anything other than * (Asterisk), it must match exactly the value specified in the CA-7 LJOB command above.

  3. PRINT retrieves Base calendar information from the CA-7 database and produces the Base Calendar report file.

    One PRINT,YEAR=yy,SCAL=xx command is specified for each CA-7 Base calendar identified in the CALBLK statement of the CA-7 Initialization file.

  4. For CA-7 Release 3.0 or earlier, if the CA-7 Virtual Resource Management facility is installed, the LXRSC command must be used to produce the Job-to-Resource Cross Reference report file. For CA-7 Release 3.1 and 3.2, the commands RM.2 followed by LIST,RM.2,RSRC=* are used to produce this report. For Release 3.3 and later, this file is not necessary since all the required information is contained in the CA-7 LJOB report. In such a case, STEP4 is omitted from JOB0.

  5. For CA-7 Release 3.1 and later, the ARFSET report file is produced using the CA-7 commands LARF,ARFSET=*,LIST=DEFS.

  6. /DISPLAY,ST=JCLVAR retrieves JCL variable names specified in the JCLLIB field used in resolving JCL DSNs.

  7. For CA-7 Release 12 and later, the LGVAR report file (Global Variables) is produced using the CA-7 command LGVAR,NAME=*,LIST=ALL.

See the JCL generated for JOB0 for the file names and attributes assigned to the output files.

JOB1

Description of JOB1

JOB1 uses the report files created in JOB0 to produce:

  • an updated LJOB report file

  • a list of all defined head-of-tree job names that are used as a basis for Control-M table names (Application Report file)

  • the Control-M Calendar library and the Calendar Names List file. For more information, see Control-M Calendars.

    The Calendar Names List file is used in JOB2 to assign calendar names to the Control-M DCAL scheduling parameter when any of the following events occur:

    • SCHDMOD CURRENT processing is requested

    • inconsistencies exist between CA-7 scheduling definitions and Control-M basic scheduling parameters

    • non-standard CA-7 calendars are converted to standard Control-M calendars

  • a Control-M job scheduling library that is used as input to JOB2. For more information, see Automated Recovery Facility (ARF).

JOB1 Input

  1. The LJOB, LSCHD, LARF (ARFSET), and Base Calendar report files created by JOB0.

  2. The CA-7 Initdeck Initialization File (described in JOB2 Input).

    For performance reasons, any JCL libraries that do not contain DEMAND commands should be removed from this file for the duration of JOB1 only. For details of these commands, see 28. CA-7 Batch Terminal Commands.

  3. The non-standard (Periodic) Base Calendar definitions specified in the NONSTANDARD (PERIODIC) BASE CALENDAR panel. The format of the control statements is shown in Table 7 below.

    Specify one line per non-standard calendar per year.

Table 7 Periodic Calendar Control Statements Format

Column

Description

01–48

Twelve pairs of 2-digit beginning and ending days for each of the twelve non-standard months in the calendar.

50–51

Calendar name (that is, the xx portion of SCALyyxx).

52–53

Calendar year (that is, the yy portion of SCALyyxx).

For calendar AA, year 2011, B01=25, E01=23, B02=26, E02=21, B03=23, E03=29, and so on.

Copy 
Column:
----+----1----+----2----+----3----+----4----+----5----+----6----+----
Code:   //SYSIN DD *
        252326212329...                                  AA11

JOB1 Output

  1. The updated LJOB report file.

  2. List of the jobs that require auxiliary calendars.

  3. The Message Report file.

  4. The Applications Report file - containing a list of CA-7 head-of-tree job names with corresponding Control-M table names to be assigned.

    Table 8 Application Report Layout

    Column

    Description

    01–08

    CA-7 head-of-tree job name.

    11–13

    CA-7 scheduleID. 000 indicates an independent or special purpose job.

    16–23

    Intermediate Control-M table name.

    41–48

    The Control-M table name. By default, this is the head-of-tree job name.

    51–58

    The CA-7 system name.

    61

    Indicates whether the head-of-tree is scheduled.

    Valid values are:

    • (Blank): the head-of-tree is scheduled

    • X: the head-of-tree is not scheduled.

    65

    Whether SCHDMOD CURRENT calendar processing is manual or automatic.

    The SCHDMOD CURRENT indicator is globally set by the SCHDMOD conversion parameter. You can individually set the SCHDMOD CURRENT indicator for each scheduled application by editing column 65 of this file.

    Valid values are:

    • Y (Yes): processing is automatic
      Some job scheduling information is modified for all jobs in the application for which a SCHDMOD CURRENT calendar has been created, as described in 13. SCAL.

    • N (No): processing is manual
      The original job scheduling information is retained in the job scheduling definition.

    71

    ‘C’: The job is converted to a cyclic SMART table.

    ‘D’: see Appendix A, conversion option MULTSCHD for details

    An editor can be used to modify only the table names (columns 41 through 48), and the SCHDMOD CURRENT indicator. When editing, it is important to ensure that the table names remain unique, valid PDS member names.

    WARNING: Do not delete any records from this file.

  5. The Control-M Calendar library containing the Base calendars and Auxiliary Control-M calendars, including SCHDMOD CURRENT calendars.

    The format of Auxiliary calendar names is xynnnnnn,

    where

    • x is ,S,T,...,Z

    • y is A-Z

    • nnnnnn is CA-7 DSNBR, the database schedule member number that was assigned to the schedule when it was added to the CA-7 database

    For more information on Auxiliary calendars, see 13. SCAL.

  6. The Calendar Names List file containing a list of calendar names and related information, sorted by job name, scheduleID, and system name. (For internal system use only.)

  7. The SCHDYONLY and Periodic Base Calendar Name List file. (For internal system use only.)
    This contains a list of all CA-7 calendar names that were created with OPTION set to SCHDYONLY, using the CA-7 CALENDAR macro, or that are defined as nonstandard in the NON-STANDARD (PERIODIC) BASE CALENDAR panel.

    Table 9 JOB1 Base Calendar Name List Record Layout

    Column

    Description

    01–08

    CA-7 Base Calendar name.

    09

    P if a non-standard (Periodic) calendar.

    10

    Reserved for future use.

    This file is automatically created by the conversion tool.

  8. The Control-M ARFSET scheduling library containing job scheduling definitions for each ARFSET defined in the LARF report. These definitions will be incorporated into the job definitions produced from the LJOB report for those CA-7 jobs which utilize ARFSETs.

JOB2 - Create Control-M Tables, CMEM Rules, and XML Definitions

Description of JOB2

JOB2

  • processes the LJOB (and the Job-to-Resource Cross Reference report, depending on the CA-7 release) files created by jobs JOB1 (and JOB0) and for every CA-7 job, extracts all information relevant to the conversion.

    The JCL member for each job is read in order to process CA-7 or JCL override control statements that may affect the scheduling process, such as JCL job class and #SCC.

  • creates the Control-M SMART Tables Library. Independent and ad hoc jobs, which would normally be created as SMART Table schedules containing a single Rule-Based Calendar and a single job scheduling definition, are all merged into one table.

    In Minor Step 12, if the CONVERTED SCHEDULING LIBRARY BE IN SMART TABLE FORMAT option is set N, then the resulting Control-M Scheduling library is created in non-SMART table format. In such a case, all the scheduling criteria are placed in CTM LEVEL RBCs in the regular job definitions of the tables and the requisite RBCs are placed in an RBC library.

  • creates a CMEM rules table for jobs triggered by DATASET events

  • invokes utility CTMTLB to create XML table definitions from the Control-M job scheduling library

  • invokes utility IOACLB to create XML calendar definitions from the Calendar library

JOB2 Input

  1. The reformatted LJOB report file (created by JOB1)

  2. The Applications Report file (created by JOB1)

  3. The file containing the Job-to-Resource Cross Reference report (created by JOB0) when the CA-7 release is R3.2 or earlier.

  4. The SCHDYONLY and Periodic Base Calendar Name file (created by JOB1)

  5. CA-7 Initdeck Initialization File statements

    These are used for several purposes:

    1. The conversion tool determines which JCL libraries to access using the JCL Library Variables report (see item #11 below) and the following Initialization File statement:

      JCL,DSN=dsname,INDEX=nnn[,ALT=mmm]

      where dsname must reference the data set names of the copies of the JCL libraries.

      If no JCL library names are found in the CA-7 Initdeck, JCL library processing is bypassed. Thecopied JCL libraries must be cataloged.

      CA-7 jobs are contained within specific JCL libraries. The library names are used in specifying the Control-M MEMLIB parameter, as described in 2. JCLID. When converting job definitions of jobs in libraries with many members, you may be able to improve performance by avoiding mass allocations and deallocations. You can do so by programming the conversion tool to specify GENERAL as the value of the MEMLIB parameter, rather than the CA-7 JCL library name.

      To do this, you should change the Initialization File statement in relation to each of these JCL libraries, by doing the following, in order:

      • Instead of the statement set out at the beginning of this section, use the following statement:

        JCL,DSN=dsname,INDEX=nnn[,ALT=mmm],GENERAL

      • In member IOADSN in the IOA IOAENV library (or member IOADSNL in the IOA PARM library) code a KEY parameter for a DALIB DD statement and concatenate all the necessary JCL libraries therein.

      For further information about the IOADSN member, see the section about Allocation Members in the INCONTROL for z/OS Administrator Guide. For on-line considerations when using DALIB, see the description of the MEMLIB parameter in the parameters chapter of the Control-M for z/OS User Guide.

    2. The conversion tool determines which job entry subsystem (JES) is in use at the site using the following Initialization File statement:

      CPU, HOST=JESn,...

      where n is 2 or 3

    3. The conversion tool obtains information on CA-11 using the following Initialization File statement

      RESTART,RMS=xxx,PROCRMS=procname,STEPRMS=stepname, PARMRMS=parm

      For details on how these parameters are utilized, see

  6. Dynamically allocated CA-7 and CA-11 JCL libraries (derived from the CA-7 Initdeck Initialization File statements and the JCL Library Variables report), used to process CA-7 and/or CA-11 control statements

  7. Calendar Name List file (created by JOB1)

  8. JCL Job Class Translation Table containing a list of all JCL job classes for which Quantitative resource statements are to be created
    This file is only needed if the JCL job classes in the JOB statement are to be converted into Control-M Quantitative resources. For more information, see "JOBCLAS" in Conversion Parameters.

    The table must be a card-image (LRECL=80) or in-stream file.

    The layout of each record in the Job Class Translation Table is as set out in the following table:

    Table 10 JCL Job Class Translation Table Record Layout

    Column

    Description

    01

    JCL job class

    02

    Generic resource name indicator

    Valid values are:

    • '' (Blank)

    • $ (Dollar sign)

    03 – 11

    User-specified text to be used as the Control-M Quantitative resource name.

    The layout of the JCL Job Class Translation Table is as follows:

    • The first column of the Translation Table must be in ascending alphabetic order.

    • An asterisk (*) in the first position of the first row indicates that the JCL job class must be used as the resource name for any JCL job class that is not listed in the table, or for which no user text is specified in the table.

    • A dollar sign ($) in the second position, including after the asterisk in the first row if desired, indicates that a $ sign is appended to the resource name. For the significance of the $ mask character, see the description of the RESOURCE conversion parameter in the Control-M for z/OS User Guide.

  9. ARFSET Scheduling library (created by JOB1)

  10. The CA-7 PROFILE library specifying-member CACCENV. CACCENV contains keyword entries specifying environment parameters for the Submit Function of CA-7 distributed jobs activated by program CA7TOUNI. This file is only required if it contains parameters NODE, DOMAIN, or SUBUSER, or XTRK XEVENTS have been added to it (see Stage 1. Data Extraction).

  11. JCL LIBRARY VARIABLES report

    The conversion tool determines which JCL libraries to access using this report and the CA-7 Initdeck file. When a job’s LJOB definition does not contain a JCLLIB field or the JCLLIB specifies '*NUMERIC JCLID*', the JCL library name is determined by the JCL ID and the Initdeck. When the JCLLIB field specifies a variable name, the JCL ID is ignored and the JCL library name (and any alternate JCL library name) is determined using this report. See items #5 above as to how the JCL library names are used.

  12. The LGVAR global variable file (created in JOB0).

JOB2 Output

  1. The Control-M Documentation library

  2. A file containing all conversion exception messages

  3. The Control-M CMEM rule table, $DSNEVT, in the CMEM Rule library containing the ON DSNEVENT data set triggering events

  4. The JCL Library DSN list

    This contains a list of all the modified JCL Library data set names extracted from the CA-7 Initdeck Initialization file and the JCL Library Variables report.

  5. A file from which appended Rule-Based Calendars are added to job scheduling definitions when CA-7 basic scheduling criteria are too complex to correspond to a single Control-M Rule-Based Calendar

  6. A file containing CTMBLT utility control statements to build (intermediate) scheduling tables.

  7. Control-M SMART Table library

    Review the members in this library carefully.

    The conversion tool generally attempts to combine like-named jobs in a table with different scheduling IDs into the same job scheduling definition with multiple Rule-Based Calendars. However, in some instances, minor differences in job scheduling parameters prevent this from being done. In this case, you may want to modify these job scheduling definitions and combine them using multiple Rule-Based Calendars.

    In addition, a set of Rule-Based Calendars with different names may have the same Basic Scheduling parameters. You may choose to retain only one of these tags in the SMART Table Entity, delete the rest, and rename all occurrences of the deleted tags in the job scheduling definitions to the name of the retained tag.

  8. A file containing JCL for the New Day procedure, which must be customized

  9. XML files containing mainframe and distributed job definitions

  10. XML files containing mainframe and distributed calendar definitions

JOB3 - Convert JCL Members

Description of JOB3

JOB3 converts JCL members from CA-7 and CA-11 format to Control-M format. For details of how the override statements and other CA-7 and CA-11 components in the JCL member are converted to Control-M equivalents, see Conceptual Overview.

JOB3 converts CA-7 JCL Batch Terminal steps to equivalent Control-M JCL steps. For more information, see the discussion of DEMAND and POST in DEMAND[H] and POST Commands, and 28. CA-7 Batch Terminal Commands.

If Control-M/Restart is installed, all appropriate rerun and restart parameters of the CA-11 JCL U11RMS steps are converted to their Control-M/Restart equivalents. The actual conversion is performed in JOB2. The U11RMS steps are then removed from the JCL in JOB3. For more information, see 31. CA-11 U11RMS Step.

JOB3 Input

  1. Dynamically allocated copies of CA-7 and/or CA-11 JCL and BTI parameter libraries

  2. The JCL library DSN list, created by JOB2

  3. A Batch Terminal Parameter file

    The Batch Terminal Parameter file provides information on how the conversion tool is to convert CA-7 Batch Terminal Steps. The format of the Batch Terminal Parameter control statements is:

    Copy 
    BTERM=batch-terminal-name[,PARM=parm-parameters]

    The subparameters must comply with the following rules:

    • They must begin in column 1 and be separated by commas with no intervening blanks.

    • They must be contained on one line.

    • BTERM is a mandatory subparameter.

    • PARM is an optional subparameter.

    One Batch Terminal Parameter control statement is required for each Batch Terminal PROC used in the CA-7 JCL libraries. Amaximum of 10 control statements is allowed.

    The value of the batch-terminal-name subparameter is the program or procedure (PROC) name of the CA-7 Batch Terminal Step, such as SASSTRLR or U7VSC. There is no default.

    The value of the parm-parameter subparameter can be set by one of the following methods:

    • Specify the JCL PARM parameter designation used in the CA-7 Batch Terminal procedure. The default is PARM=PARM

    • Indicate that the CA-7 Batch Terminal procedure is issuing a CA-7 DEMAND or POST command, use the JCL PARM parameter, and display symbolic variables for various subparameters of the command.

    The type of CA-7 command, and the symbolic variable names, are specified in the control statement, using the following syntax:

    Copy 
    PARM=(command-type[,variable-1][,variable-2])

    where

    • command-type is one of the following types of command:

      • DE: a DEMAND command

      • PU: a POST command with a user-defined requirement

      • PJ: a POST command with a predecessor job dependency requirement

    • variable-1 is the symbolic variable name of the JOB parameter value in the command. The default variable name is JOB.

    • variable-2 is the symbolic variable name of a parameter value, as follows:

    • Where the command-type specified is DE, variable-2 is the symbolic variable name of the SCHID parameter value. The default variable name is SCHID. If the SCHID variable is not found in the JCL, a symbolic schedule ID of 000 is assigned.

      When Batch Terminal Procedures are specified using DE as the value for command-type, you must incorporate the demanded jobs into a Control-M table, and specify the appropriate IN conditions in their job scheduling definitions.

    • Where the value of command-type is set to PU, variable-2 is the symbolic variable name of the USR parameter value. The default variable name is USR

    • Where the value of command-type is set to PJ, variable-2 is the symbolic variable name of the DEPJOB parameter value. The default variable name is DEPJOB.

    The usage of the parm-parameter subparameter value is further clarified in the following example.

    Suppose a site has six types of Batch Terminal Procedures in the CA-7 JCL libraries.

    1. The BTERM1 procedure specifies all CA-7 Batch Terminal Commands using one of the following SYSIN DDstatements:

      Copy 
      //stepx EXEC BTERM1
      //SYSIN DD   *
      CA-7 commands
      /*
      Copy 
      //stepx      EXEC BTERM1
      //SYSIN DD   DISP=SHR,
      //   DSN=pdsmember_or_seq_file

    2. The BTERM2 procedure specifies a CA-7 Batch Terminal command using the JCL EXEC PARM parameter, as follows:

      Copy 
      //stepx EXEC BTERM2,PARM='CA-7 command'

    3. The BTERM3 procedure specifies a CA-7 Batch Terminal command using a symbolic PARM parameter P, as follows:

      Copy 
      //stepx EXEC PGM=SASSTRLR,PARM='&P'

    4. The BTERM4 procedure specifies symbolic variables for the job name (JOB) and scheduleID (SCHID) parameters of the CA-7 DEMAND command, as follows:

      Copy 
      //stepx EXEC BTERM4,JOBNM=jobname,SCH=schid

      where the BTERM4 procedure contains

      Copy 
      //stepy EXEC PGM=U7SVC,
      // PARM='/logonid;DEMAND,JOB=&JOBNM,SCHID=&SCH'

    5. The BTERM5 procedure specifies symbolic variables for the job name (JOB) and user-defined requirement (USR) parameters of the CA-7 POST command, as follows:

      Copy 
      //stepx EXEC BTERM5,JOBN=jobname,USREQ=usr

      where the BTERM5 procedure contains

      Copy 
      //stepy EXEC PGM=U7SVC,
      // PARM='/LOGON operid;POST,JOB=&JOBN,USR=&USREQ'

    6. The BTERM6 procedure specifies CA-7 Batch Terminal commands using a SYSIN DDstatement, and contains a symbolic parameter (ID) that specifies a relative batch terminal number, as follows:

      Copy 
      //stepx  EXEC BTERM6,ID=1
      //SYSIN  DD   *
      CA-7 commands
      //

      where the BTERM6 procedure contains

      Copy 
      //stepy EXEC PGM=SASSBSTR,
      // PARM='&ID,...'

      The symbolic parameter ID is irrelevant to the proper conversion of the CA-7 commands in the SYSIN file. However, the corresponding Control-M procedure, CTMUTIL, which is explained in Conceptual Overview must take the ID into account to avoid a JCL error when resolving symbolic parameters. One method of accomplishing this is by having the CTMUTIL procedure use the symbolic parameter in a "harmless" way.

      For example, define the CTMUTIL procedure with the symbolic parameter ID as follows:

      Copy 
      //CTMUTIL PROC ID=1
      //step1   EXEC PGM=CTMUTIL,TIME=&ID

      The contents of the DABTERM file for the above example must be coded as follows:

      Copy 
      BTERM=BTERM1
      BTERM=BTERM2
      BTERM=BTERM3,PARM=P
      BTERM=BTERM4,PARM=(DE,JOBNM,SCH)
      BTERM=BTERM5,PARM=(PU,JOBN,USREQ)
      BTERM=BTERM6

    The conversion tool is delivered with three Batch Terminal programs or procedures named SASSTRLR, U7SVC and CAL2X2WB

  4. The LGVAR global variable file (created in JOB0).

JOB3 Output

  1. JCL libraries in Control-M format

  2. the JCL conversion report

JOB4 - Convert CA-DRIVER Procedures and JCL Libraries (Optional)

See the chapter about JOB5 in the Control-M for z/OS for CA-SCHEDULER Conversion Guide for details regarding CA-Driver components.