Conversion Details

This chapter includes the following topics:

• Overview of Conversion Details

• Component Conversion Summary

• CA-SCHEDULER Parameters

  • 1. SCHEDULE NAME (in Schedule Definition)

  • 2. PRIORITY

  • 3. AUTO SELECT

  • 4. USERS

  • 5. EARLIEST START TIME

  • 6. MUST START BY TIME

  • 7. COMPLETION DEADLINE TIME

  • 8. DATETABLE NAME

  • 9. BACKLOG

  • 10. RUN ON SYSID

  • 11. NODE ID

  • 12. JOB NAME

  • 13. JOB NUMBER

  • 14. STATION ID

  • 15. SCHEDULE NAME (in Job Definition)

  • 16. MEMO

  • 17. CPU JOB

  • 18. JCLLIB DDNAME

  • 19. FAIL CODE/FAIL OPER

  • 20. ABEND

  • 21. INTERRUPT

  • 22. INSERT RMS PROC

  • 23. SEND START/END MESSAGE

  • 24. SEND LATE MESSAGE

  • 25. SEND FAIL/ABEND MESSAGE

  • 26. SEND INTERRUPT MESSAGE

  • 27. jobName [Schedule Name Qualifier]

  • 28. NJE Jobname

  • 29. PRED

  • 30. START [NJE] jobName

  • 31. DSN and GDG

  • 32. MVS

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

  • 34. Gregorian Calendar, Workday Conditions, and Accounting Conditions Criteria Language

  • 35. MAXIMUM EXECUTION TIME

  • 36. SEPARATE DSNAME

  • 37. SEPARATE/EXCLUSIVE JOB LIST

  • 38. STAGE JCL

  • 39. LIBTYPE=TESTLIB

  • 40. DESCRIPTION

  • 41. DASD, TAPE, U/R

  • 42. LIBTYPE=DRIVER

  • 43. PROC, STEP, FAIL OPER, FAIL CODE

  • 44. WLM SCH ENV

  • 45. START SCD schedule-name

  • 46. JES ROUTE PRINT

  • 47. NON-EXEC

  • 48. REPEAT

  • 49. JOB TYPE

  • 50. HOLD

• CA-DRIVER Parameters

  • 51. DPROC

  • 52. DSTEP

  • 53. DGOTO

  • 54. DSET

  • 55. DIF

  • 56. DATA, DEND

  • 57. DNEST

  • 58. DABORT/DFLUSH

  • 59. Variable parameters

  • 60. Date Functions

  • 61. Attribute Functions

  • 62. CAJUCMD0 utility

  • 65. NODE

  • 66. COMMAND

  • 67. TYPE (DSCLOSE)

  • 68. DOMAIN

  • 70. HISTRET

• Unique Control-M Parameters

  • DO SYSOUT

  • RESOURCE

  • ADJUST CONDITIONS

Overview of Conversion Details

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

Component Conversion Summary

The following conversion tables list CA-SCHEDULER parameters and CA-DRIVER commands that are converted to corresponding Control-M parameters, with cross-references to the topics dealt with in this chapter.

CA-SCHEDULER parameters in a Job Definition screen are converted to Control-M Job Scheduling parameters.

CA-SCHEDULER parameters in a Schedule Definition screen are converted to Control-M SMART Table Entity parameters.

Table 6 Conversion of CA-SCHEDULER Screen Parameters

Table 7 Conversion of Schedule/Job Message Definition Screen Parameters

Table 8 Conversion of Job Resource Definition Screen Parameters

Table 9 Conversion of Schedule/Job Criteria Definition Screen Parameters

Table 10 Conversion of Schedule and Job Information Record Screen Parameters

Table 11 Conversion of JCL and CA-DRIVER Commands

CA-SCHEDULER Parameters

The items in the following section describe the conversion of CA-SCHEDULER parameters.

1. SCHEDULE NAME (in Schedule Definition)

In CA-SCHEDULER, the unit used for controlling the execution of jobs is the schedule. The schedule consists of one or more jobs.

In Control-M, jobs are grouped by defining all related jobs in a single Control-M SMART Table.

The conversion tool assigns the CA-SCHEDULER SCHEDULE NAME to the new Control-M SMART Table name. In addition, the conversion tool assigns this name to the Control-M GROUP parameter, the SMART Table Entity, and the Control-M APPL parameter.

Specification of IN and OUT conditions and various scheduling criteria in the SMART Table Entity are used to control the processing of the entire table. For example:

• If the CA-SCHEDULER schedule has predecessors, appropriate IN conditions are added to the SMART Table Entity scheduling definition to ensure that processing of the jobs in the table does not begin until the tables that correspond to predecessor schedules have been processed. In particular, the following IN condition is always added to all groups created by the conversion tool:

  tableName-SCHED-OK PREV

  This conforms to the action of CA-SCHEDULER, which does not permit a schedule to execute until the previously scheduled occurrence has completed.

• An OUT parameter in the SMART Table Entity adds a prerequisite condition to identify the end of the table. The format of the condition is:

  tableName-SCHED-OK

  where tableName is the name of the Control-M table. This condition invokes the processing of dependent tables.

2. PRIORITY

The JOB/SCHED PRIORITY CA-SCHEDULER job scheduling definition parameter can specify job scheduling execution priority. JOB/SCHED PRIORITY can be any value from 01 through 99, where 01 is the highest priority, and 99 is the lowest priority.

The Control-M job scheduling definition parameter PRIORITY specifies job scheduling priority as two numeric characters, corresponding to CA-SCHEDULER schedule priority value, where 01 is the lowest priority and 99 is the highest priority.

The conversion tool converts the value of the JOB/SCHED PRIORITY CA-SCHEDULER parameter to the PRIORITY parameter of the Control-M Job scheduling definition.

3. AUTO SELECT

The AUTO SELECT CA-SCHEDULER schedule definition parameter specifies whether the schedule can be automatically evaluated for selection by CA-SCHEDULER.

The Control-M New Day procedure is the primary mechanism used to issue new job orders for the Control-M Monitor.

If YES is specified in the AUTO SELECT field, the conversion tool adds the schedule name to the daily tables list.

4. USERS

The USERS CA-SCHEDULER schedule definition parameter identifies users authorized to maintain and control this schedule.

The OWNER Control-M job scheduling definition parameter identifies a user who requests Control-M services. This parameter is mainly used for security purposes.

The conversion tool populates the Control-M OWNER job scheduling definition depending on the setting of the OWNER parameter (see Conversion Parameters):

• If OWNER is set to SCNAME or =xxxxxxxx, then the OWNER in both the SMART Table Entity and job definitions of the Control-M SMART Table corresponding to the CA-SCHEDULER schedule are assigned the CA-SCHEDULER schedule name or the fixed constant xxxxxxxx, respectively.

• If OWNER is set to USERID, then the OWNER in both the SMART Table Entity and job definitions of the Control-M SMART Table corresponding to the CA-SCHEDULER schedule are assigned the CA-SCHEDULER user ID derived from the Schedule Names table (see JOB1 – Create the Schedule Names Table and Control-M Calendar Library).

• If OWNER is set to JCLUSER, JCLGRP, NOTIFY or ACF2USER, then the OWNER in the SMART Table Entity of the Control-M SMART Table corresponding to the CA-SCHEDULER schedule is assigned the CA-SCHEDULER user ID derived from the Schedule Names table (see JOB1 – Create the Schedule Names Table and Control-M Calendar Library) and the OWNER in job definitions are populated from the respective JCL parameters (see Conversion Parameters). The OWNER parameter in dummy job definitions are populated from the Schedule Names table.

For distributed CA-Scheduler job definitions (NODE ID=*REMOTE or JOB TYPE=XPLAT), you can optionally specify a USER parameter in the JCL member associated with the job. This USER parameter takes precedence over option OWNER in setting the
Control-M OWNER job scheduling parameter.

5. EARLIEST START TIME

The EARLIEST START TIME CA-SCHEDULER job and schedule definition parameter specifies the start time for the job scheduling.

The TIME FROM Control-M job scheduling definition parameter specifies the earliest time a job can be submitted. The conversion tool converts this parameter by assigning the value of the EARLIEST START TIME CA-SCHEDULER parameter to the FROM TIME parameter in the Control-M job scheduling definition. In addition, in all definitions to which a FROM TIME is assigned, the UNTIL TIME '>' is also added.

For users converting from versions of CA-SCHEDULER lower than 9.0, if the CA-SCHEDULER EARLIEST START TIME is between midnight and the Control-M New Day time, the Control-M SAC parameter is set to P. The New Day time is set by the Control-M DAYTIME installation parameter in the CTMPARM member. For more details, see Step 10: Perform Final Adjustments.

6. MUST START BY TIME

The MUST START BY TIME CA-SCHEDULER job and schedule definition parameter specifies the time before which the job must start.

The SHOUT WHEN LATESUB Control-M job scheduling definition parameter sends a message if the job has not been submitted at the start time specified. The conversion tool converts the MUST START BY TIME parameter by assigning its value to the SHOUT WHEN LATESUB Control-M parameter.

7. COMPLETION DEADLINE TIME

The COMPLETION DEADLINE TIME CA-SCHEDULER job and schedule definition parameter specifies the latest time the job can be completed.

The DUE OUT Control-M job scheduling definition parameter specifies a time by which a job must finish executing. The conversion tool converts the COMPLETION DEADLINE TIME parameter by assigning its value to the DUE OUT Control-M parameter.

The SHOUT WHEN LATESUB * Control-M job scheduling definition parameter sends a message if the job is not submitted on time, based on the calculated due-in time of the job. The conversion tool always adds this SHOUT to the job scheduling definition whenever the job has a defined DUE OUT time.

8. DATETABLE NAME

The CA-SCHEDULER schedule definition can contain a base calendar used to resolve the requested schedule days against the working days in the calendar.

The conversion tool uses the DATETABLE CA-SCHEDULER parameter as the Control-M DCAL or WCAL value, which is used in conjunction with the values set for the DAYS and WDAYS Control-M parameters.

9. BACKLOG

The BACKLOG CA-SCHEDULER job and schedule definition parameter specifies whether the job is carried over to the workload for the next day.

The MAXWAIT Control-M job scheduling definition parameter specifies the number of extra days a SMART Table or job can wait in the Active Jobs file to be executed, after which it is deleted.

If the value in the BACKLOG CA-SCHEDULER parameter is NO, the MAXWAIT Control-M parameter is set to 0.

If the BACKLOG parameter in the CA-SCHEDULER schedule or job definition is set to YES, the value specified in optional wish WM2367 (see member IOADFLT in the IOA IOAENV library) is specified in the Control-M MAXWAIT parameter in the SMART Table Entity or job definition. Job definitions with a blank BACKLOG value inherit the value from the corresponding schedule definition.

10. RUN ON SYSID

The RUN ON SYSID CA-SCHEDULER job and schedule definition parameter specifies the CPU ID of the CPU designated to execute the job.

The SYSTEM ID Control-M job scheduling definition parameter specifies the CPU ID of the CPU designated to execute the job, and causes one of the following JES control statements to be inserted into the JCL of the job before the first step:

For JES2

/*JOBPARM    S=sys-id

or, for JES3,

//*MAIN SYSTEM=sys-id

where sys-id is the designated CPU.

11. NODE ID

The NODE ID CA-SCHEDULER job and schedule definition parameter specifies the remote node designated to execute the job.

The NJE NODE Control-M scheduling definition parameter specifies the remote node designated to execute the job, and causes one of the following JES control statements to be inserted into the JCL of the job before the first step:

For JES2

/*ROUTE XEQ    node-id

or, for JES3

//*ROUTE XEQ node-id

where node-id is the designated remote node.

When the NODE ID specifies a value of '*REMOTE', then the jobs in the schedule are not z/OS NJE jobs; the jobs run on a non-z/OS platform (distributed) controlled by Unicenter TNG. In such a case, the conversion utility searches the JCL libraries for the member containing the distributed job parameters. For more information, see the following references:

• JOB2 – Convert Information from CA-SCHEDULER Report; Create Input for Utility CTMBLT; Create the Control-M Tables Library and XML Definitions

• 4. USERS

• 65. NODE

• 66. COMMAND

12. JOB NAME

In CA-SCHEDULER, the job name, which is specified in the JOB NAME parameter of the Job Definition screen, does not correspond to the JCL member name. The JCL member name is specified in the LIBMEMB CA-SCHEDULER parameter.

In Control-M, the JCL member name is specified in the MEMNAME job scheduling definition parameter, and the job name is determined at time of submission.

The conversion tool specifies the CA-SCHEDULER JOB NAME as the Control-M MEMNAME parameter. If the CA-SCHEDULER JOB NAME differs from the CA-SCHEDULER LIBMEMB member name see 18. JCLLIB DDNAME.

13. JOB NUMBER

The JOB NUMBER CA-SCHEDULER job definition parameter is a 2-digit job number used for identifying multiple occurrences of the same job within the same schedule.

The conversion tool converts this parameter by assigning the value of the JOB NUMBER CA-SCHEDULER parameter to the SETVAR %%JOBNUM statement in the Control-M job scheduling definition, which is also used later in the CA-DRIVER JCL conversion. The JOB NUMBER may affect the format of IN and OUT conditions relating to this job. For more information, see the following item, 14. STATION ID.

14. STATION ID

The STATION ID CA-SCHEDULER job definition parameter is a 2-digit station identifier used for defining a job path. In CA-SCHEDULER, when jobs are defined with the same job name, job number, and schedule name, you can assign the job to run at different stations. A station ID identifies a phase in the processing of the job. For example, station ID 40 is commonly used to identify CPU processing, while other station IDs can be used to identify any phase the user may choose.

The conversion tool converts this parameter, for non-CPU jobs, by assigning the value of the STATION CA-SCHEDULER parameter to the SETVAR %%STTNUM statement in the Control-M job scheduling definition. The conversion tool creates a special dummy job for every station ID other than a CPU station. By specifying IN and OUT conditions, dependencies between station IDs for the same job within a schedule are established. The format of the conditions is:

tableName-jobName##-ss

where:

• tableName is the name of the Control-M table

• jobName is the CA-SCHEDULER JOB NAME parameter value

• ## is the CA-SCHEDULER JOB NUMBER parameter value. When the job number is 01 this field is omitted.

• ss is the CA-SCHEDULER STATIONID parameter value
  If a job has the same STATIONID as specified in parameter CPUSTAT (see Conversion Parameters), the suffix OK is used.

15. SCHEDULE NAME (in Job Definition)

The SCHEDULE NAME CA-SCHEDULER job definition parameter specifies the schedule name for which this job is assigned.

The conversion tool converts this parameter by assigning the value of the SCHEDULE NAME CA-SCHEDULER parameter to the GROUP and APPL parameters in the Control-M job scheduling definition.

16. MEMO

The MEMO CA-SCHEDULER job definition parameter specifies whether a confirmation message is sent to the system console when the job starts. The CA-SCHEDULER operator must reply OK to the message to allow the job to begin executing, or TERM to terminate the job immediately.

If text is specified in the MEMO parameter, the conversion tool adds a manual IN condition to the Control-M Job scheduling definition to indicate that manual intervention is required. The format of the condition is:

MM_tableName_jobName

where:

• tableName is the name of the Control-M table

• jobName is the CA-SCHEDULER JOB NAME parameter value

17. CPU JOB

The CPU JOB CA-SCHEDULER job definition parameter indicates whether the job requires CPU processing.

If the value NO is specified in the CPU JOB CA-SCHEDULER parameter, the conversion tool sets the MEMLIB parameter of the Control-M job scheduling definition to DUMMY, which means that the job is a dummy job.

In addition, the CONFIRM parameter of the Control-M job scheduling definition is set to Y to ensure manual confirmation before the dummy job is posted as ended.

18. JCLLIB DDNAME

In CA-SCHEDULER, for library type of PDS, the default name of the partitioned data set containing the JCL of the jobs in a schedule. Individual jobs can override this value.

The conversion tool uses the CA-SCHEDULER job name for the Control-M MEMNAME parameter. If the CA-SCHEDULER job name differs from its JCL member name, and is not accessed via CA-DRIVER, the job definition is created with In-Stream JCL specifying a Control-M autoedit statement:

//* %%INCLIB DDNAME=jcllib-ddname %%INCMEM libmemb

which causes the member libmemb specified in the CA-SCHEDULER LIBMEMB parameter to be submitted from the JCL library pointed to by the DD statement jcllib-ddname specified in the CA-SCHEDULER JCLLIB DDNAME parameter. If the ddname field is blank then the conversion uses the DALIB DD statement in member IOADSN in the IOA IOAENV library as specified in Step 10: Perform Final Adjustments.

19. FAIL CODE/FAIL OPER

The FAIL CODE CA-SCHEDULER job definition parameter specifies the condition code threshold that indicates job failure.

The Control-M job scheduling definition enables you to check condition codes at the step level as well as job level. The Control-M default is that a job is considered as having ended OK if no step has a condition code higher than 4.

The conversion tool converts the FAIL CODE value to the following Control-M specification:

ON PGMST ANYSTEP CODES <Cfail-code
DO OK

When the FAIL CODE value is less than 4, the conversion tool converts it as follows:

ON PGMST ANYSTEP CODES >Cfail-code
DO NOTOK

For releases of CA-SCHEDULER which support the FAIL OPER parameter, when the FAIL OPER field is non-blank, the FAIL CODE/FAIL OPER combination is converted as described in 43. PROC, STEP, FAIL OPER, FAIL CODE.

20. ABEND

The ABEND CA-SCHEDULER job definition parameter specifies what action is taken if the job abends. ABORT is the default value of ABEND. It indicates that successors to this job are not posted as satisfied if this job abends. ABEND=CONT indicates that successors to this job continue to be posted as satisfied even if this job abends.

The Control-M job scheduling definition enables you to specify the condition codes on which the actions are to be performed.

The conversion tool converts the CA-SCHEDULER ABEND=CONT value to the following Control-M specification:

ON PGMST ANYSTEP CODES S*** U****
DO OK

21. INTERRUPT

The INTERRUPT CA-SCHEDULER job definition parameter specifies whether this job is to be interrupted for operator intervention before it is posted as completed.

If the value YES is specified in the INTERRUPT parameter, the conversion tool forces an order of a special dummy job when this job ends OK. The name assigned to this dummy job is INTRPTnn, where nn is a sequential number within the group. The INTRPTnn dummy job waits for a confirmation to indicate that a manual intervention is required.

After the INTRPTnn dummy job is confirmed, it adds an OUT condition to identify the end of the interrupted job to permit the continuation of the job flow.

INTRPTnn jobs are identified by a DESCription field containing the following:

INTERRUPT FOR tableName jobName jobNumber

22. INSERT RMS PROC

The INSERT RMS PROC CA-SCHEDULER job definition parameter specifies whether the job is restarted through CA-11.

Control-M supports the same feature only in sites where Control-M/Restart is installed. For details, see the CTR conversion parameter in "CTR" in Conversion Parameters.

If the value in the INSERT RMS PROC field is YES, the conversion tool adds the following specification to the Control-M job scheduling definition:

PREVENT-NCT2 Y
MAXRERUN 255  (99 for distributed jobs)
ON PGMST ANYSTEP CODES EXERR
DO IFRERUN FROM $EXERR CONFIRM Y
DO RERUN

For cyclic jobs and started tasks not all of the above Control-M job scheduling definition parameters are supported and are omitted from the converted job definition.

23. SEND START/END MESSAGE

The SEND START/END MESSAGE CA-SCHEDULER job and schedule message definition parameter specifies whether a message is sent to notify that the job has been started or has ended.

The SHOUT WHEN OK Control-M job scheduling definition parameter sends a message if the job finishes executing OK. The conversion tool converts the SEND END MESSAGE parameter to the SHOUT WHEN OK parameter in the Control-M scheduling definition. If this is a START schedule message definition, the SHOUT parameter is added to a DUMMY job named $SHOUTST that is triggered immediately upon the schedule starting.

24. SEND LATE MESSAGE

The SEND LATE MESSAGE CA-SCHEDULER schedule and job message definition parameter specifies whether a message is sent to notify that the schedule or job started later than its MUST TIME, or has been ended late, having missed its DEADLINE TIME, or has exceeded its MAXIMUM EXECUTION TIME.

The SHOUT WHEN LATESUB Control-M job scheduling definition parameter sends a message if the job is still not submitted at the specified time. The SHOUT WHEN LATE TIME parameter sends a message if the job does not finish executing by the specified time, and the SHOUT WHEN EXECTIME parameter sends a message if the elapsed runtime of the job is outside acceptable limits. The conversion tool converts CA-SCHEDULER MUST START BY TIME, COMPLETION DEADLINE TIME, and MAXIMUM EXECUTION TIME to the SHOUT WHEN LATESUB, the SHOUT WHEN LATE TIME, and the SHOUT WHEN EXECTIME parameters in the Control-M job scheduling definition.

25. SEND FAIL/ABEND MESSAGE

The SEND FAIL/ABEND MESSAGE CA-SCHEDULER job message definition parameter specifies whether a message is sent to notify that the job fails or abends.

The SHOUT WHEN NOTOK Control-M job scheduling definition parameter sends a message if the job finishes executing NOTOK. The conversion tool converts this CA-SCHEDULER parameter to the SHOUT WHEN NOTOK parameter in the Control-M job scheduling definition.

This SHOUT is also added to non-dummy job definitions for which there is no corresponding CA-SCHEDULER Message definition.

26. SEND INTERRUPT MESSAGE

The SEND INTERRUPT MESSAGE CA-SCHEDULER job message definition parameter specifies whether this job is interrupted for operator intervention before it is posted as completed.

The SHOUT WHEN OK Control-M job scheduling definition parameter sends a message if the job finishes executing OK. The conversion tool converts this parameter to the SHOUT WHEN OK parameter in the Control-M job scheduling definition.

27. jobName [Schedule Name Qualifier]

For more information on how CA-SCHEDULER job dependencies are converted to Control-M IN/OUT conditions, see Job Dependencies.

For alternate condition name formats, see "CNDFRMT" in Conversion Parameters.

28. NJE Jobname

The NJE CA-SCHEDULER criteria definition parameter specifies dependency on the end of a job at another node. The conversion tool treats the NJE parameter in the same way as a regular job name; for more information, see the preceding item. Control-M NJE support must be installed for this feature to operate properly. For more information, see the DOCMNJE member in the IOA DOC library. In addition, set the ENHNJE parameter in the CTMPARM member of the IOA PARM library to Y.

29. PRED

The PRED CA-SCHEDULER criteria definition parameter is used to specify that the predecessor is a job, schedule, or data set that completed or was closed on a previous day and therefore has no effect on the selection of its successor. PRED can be used with any of the following criteria words: DSN, GDG, NJE, MVS, SCD, or can simply be followed by a job name, and if necessary, the qualifying schedule name.

The conversion tool converts the PRED parameter by specifying the PREV date reference in the IN condition created by the parameters following the PRED keyword.

30. START [NJE] jobName

The START [NJE] CA-SCHEDULER criteria definition parameter specifies dependency on the start of a job or the start of a job at another node.

The conversion tool converts this criteria definition as follows:

1. An IN condition is placed in the Control-M job scheduling definition. The format of the condition is:

   pfx[tableName]-jobName

   where

   • jobName is the job name in the START [NJE] parameter.

   • tableName (when specified) is the name of the Control-M table that corresponds to the CA-SCHEDULER schedule.

   • pfx is set according to the CNDPFX conversion option (see Conversion Parameters)

2. A Control-O rule definition defining a JOBARRIVAL event is created. The rule specifies that upon the arrival of job jobName, the condition

   pfx[tableName]-jobName ODAT

   is to be added to the IOA Conditions file.

31. DSN and GDG

The DSN and GDG CA-SCHEDULER criteria definition keywords specify dependency on the close of an output data set or generation data group.

The conversion tool converts the criteria definitions as follows:

1. An IN condition is placed in the Control-M job scheduling definition. The format of the condition is:

   prefix-dsn

   where

   • prefix is set according to the CNDPFX conversion option (see Conversion Parameters)

   • dsn is the first 38 characters of the data set name or the generation data group name

2. A Control-O rule definition defining an ONDSNEVENT statement is created. The rule specifies that upon closing of the DSN or GDG dsn (occurring in any job) the condition

   prefix-dsnpref ODAT

   is to be added to the IOA Conditions file

   where

   • dsn is the data set name or the generation data group name, with .G* appended to indicate that the data set is part of a GDG

   • prefix is set according to the CNDPFX conversion option (see Conversion Parameters)

   • dsnpref is the first38 characters of the data set name or the generation data group name

32. MVS

The MVS CA-SCHEDULER criteria definition parameter specifies dependency on the end of an MVS job that is not under the control of CA-SCHEDULER.

The conversion tool converts this criteria definition as follows:

1. An IN condition is placed in the Control-M job scheduling definition. The format of the condition is:

   pfxjobName

   where:

   • jobName is the name of the MVS job

   • pfx is set according to the CNDPFX conversion option (see Conversion Parameters)

2. A Control-O rule definition defining a JOBEND event is created. The rule specifies that upon the successful end of MVS job jobName, which is not under Control-M control, the condition pfxjobName ODAT is to be added to the IOA Conditions file.

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

This CA-SCHEDULER criteria definition keyword specifies dependency on the end of a job step. An optional procstep can be specified. Optionally, a step condition code relationship can also be specified.

The conversion tool converts the criteria definitions as follows:

1. An IN condition is placed in the Control-M job scheduling definition. The format of the condition is:

   prefix-string

   where:

   • prefix is set according to the CNDPFX conversion option (see Conversion Parameters)

   • string is the first 38 characters of jobName[.procName].stepName[.opernnnn]

     In string,

     • jobName is the name of the job to be monitored for step termination

     • procName is the name of a step invoking a procedure; if omitted, all procedure steps in the selected job are monitored

     • stepName is the name of a step invoking a program

     • opernnnn is the return code returned on termination of the specified step that satisfies the step termination criteria as specified by oper.nnn

2. A Control-O rule definition defining an ONSTEP statement is created. The rule specifies that upon the end of the specified step of the specified job the condition prefix-string ODAT is to be added to the IOA Conditions file

   where prefix-string takes the form set out in the preceding paragraph.

34. Gregorian Calendar, Workday Conditions, and Accounting Conditions Criteria Language

The following table shows how CA-SCHEDULER Gregorian Calendar, Workday Conditions, and similar Criteria Language keywords are converted to Control-M job scheduling parameters.

Table 12 Conversion of Criteria Language Keywords

Notes

1. Assumes that the SWEEK IOA installation parameter was set to MON. If SWEEK is set to SUN, add one (modulo 7) to all WDAYS or Dn specifications.

2. tableName is the name of the Control-M job table corresponding to the CA-SCHEDULER SCHEDULE NAME. For more information on tables and related IN/OUT conditions, see 1. SCHEDULE NAME (in Schedule Definition).

3. Values for the accounting condition prefix (x) are specified using the ACCTNG conversion parameter. For more information, see "ACCTNG" in Conversion Parameters.

   The name of the periodic calendar is formed by concatenating "PERIOD" to the accounting condition prefix. For example, the DCAL periodic calendar for accounting condition QDAY is QPERIOD. It is your responsibility to create the necessary calendars; for more information, see the discussion of the IOA Calendar facility in the Control-M for z/OS User Guide. For the WOYn keyword, WPERIOD calendars are specified.

   All xPERIOD calendars must correspond to the CA-SCHEDULER Datetable definitions that define accounting days.

   For the WEEKnOFm keyword, WEEKnOFm calendars are specified.

   WARNING: Jobs specifying mixed accounting conditions, that is, conditions whose accounting criteria keywords have different prefixes, must be checked to ensure that they are properly scheduled by the Control-M periodic scheduling parameters produced by the conversion program.

4. The period indicator (i) in the D*Pi parameter is converted as follows: for n=1–53

   i= 1–9, A–M, O–X, Z, @, #, $, %, *, (, ), -, _, =, +, ., <, >, /, ?, ;, :, \

5. When the NOT form of this parameter is specified, a minus sign is placed in front of the DAYS or WDAYS values and a DCAL or WCAL parameter is added when required.

   The NOT criteria keyword is also supported in simple compound NOT expressions, such asNOT (xxx OR yyy OR zzz), but not in complex compound expressions, such asNOT ((xxx OR yyy) AND zzz).

6. NOT GBLxnn is treated the same as GBLxnn.

7. This assumes that the DATETYP IOA installation parameter was set to W. If DATETYP is set toA orJ the DATES format is mmdd. Invalid combinations of month and day are rejected as errors (for example FEB and 30).

8. When the NOT form of this parameter is specified, the months specified in the NOT expression are left blank in the MONTHS Control-M parameter and all other months are marked Y.

9. The xWOMn keyword results in a valid Control-M scheduling definition if n is less than or equal to 6.

10. The SCHEDULE RBC (DEFINITION) ACTIVE FROM and UNTIL parameters do not cause a job to be scheduled during the specified date range. They only prevent the job being scheduled by the other basic scheduling criteria that are outside the specified date range. Only the year 2000 and years later than 2000 are supported.

11. Multiple RDnn parameters are not supported unless they specify the same shift (mm) values. The CONFCAL calendar is the calendar specified in the CA-SCHEDULER schedule or job definition. When the value of mm is 1, then the Control-M scheduling parameter is converted as:

    DAYS >(nn+1) DCAL=cal for RDnn=+1

    DAYS <(nn-1) DCAL=cal for RDnn=-1

12. NOT DAILY and NOT REQUESTED are ignored.

13. For further details, see "REQOPT" in Conversion Parameters.

35. MAXIMUM EXECUTION TIME

The CA-SCHEDULER schedule and job definition parameter MAXIMUM EXECUTION TIME specifies a limit on how long a schedule or job runs, respectively.

The Control-M job scheduling parameter SHOUT WHEN EXECTIME sends a message if the elapsed runtime of a SMART Table or job is outside acceptable limits.

The conversion tool assigns the MAXIMUM EXECUTION TIME value to the SHOUT WHEN EXECTIME parameter in the Control-M SMART Table Entity for CA-SCHEDULER schedules, or job scheduling definition for CA-SCHEDULER job definitions.

36. SEPARATE DSNAME

The SEPARATE DSNAME CA-SCHEDULER field identifies a data set that can only be used by one job at a time.

The CONTROL Control-M job scheduling definition parameter is used to control all job resource sharing.

The conversion tool converts this CA-SCHEDULER SEPARATE DSNAME by specifying the first 20 characters of the data set name in the CONTROL parameter with the Exclusive option.

37. SEPARATE/EXCLUSIVE JOB LIST

The CA-SCHEDULER SEPARATE/EXCLUSIVE JOB list identifies up to eight jobs that cannot run while this job is running.

The CONTROL Control-M job scheduling definition parameter is used to prevent concurrent runs of jobs.

The conversion tool converts the job names in the SEPARATE/EXCLUSIVE JOB LIST by specifying CONTROL resources in the following format:

EXCLUSIVE_jobName

Each Control resource is specified for the job itself with the Exclusive option, and for the job names specified in the SEPARATE/EXCLUSIVE JOB LIST with the Shared option.

The conversion tool supports use of CA-SCHEDULER mask characters that identify groups of jobs that have job name characters in common. Wildcard characters * and ? are supported. All jobs with job names that match the mask are assigned the Control resource with the Shared option.

38. STAGE JCL

CA-SCHEDULER job and schedule definition parameter STAGE JCL specifies whether the production JCL requires editing before it can be submitted.

If the value YES is specified in the STAGE JCL parameter, the conversion tool adds a manual IN condition to the Control-M job scheduling definition to indicate that manual JCL editing is required.

The format of the condition name is:

JC_tableName_jobName

where:

• tableName is the name of the Control-M table

• jobName is the value specified in the CA-SCHEDULER JOB NAME parameter

39. LIBTYPE=TESTLIB

The LIBTYPE CA-SCHEDULER job definition parameter specifies the type of library that contains the JCL for the job. A specification of TESTLIB indicates a virtual library that is used during testing and allows you to perform "dry runs" of new schedules or jobs without submitting the actual JCL. This is implemented using a CA-SCHEDULER utility program with a parameter called TESTLIB PARMS, which accepts parameters allowing simulation of elapsed time, fail codes, and abend codes.

In Control-M, the IOATEST utility performs simulation of elapsed time, fail codes, and abend codes. For each CA-SCHEDULER job that sets LIBTYPE to TESTLIB, the conversion tool creates instream JCL in the job scheduling definition to execute the IOATEST utility.

For more information, see JOB2 – Convert Information from CA-SCHEDULER Report; Create Input for Utility CTMBLT; Create the Control-M Tables Library and XML Definitions.

The conversion tool converts the parameters specified in the TESTLIB PARM field to IOATEST parameters as follows:

Table 13 Conversion of TESTLIB PARM Parameters

40. DESCRIPTION

The DESCRIPTION CA-SCHEDULER job and schedule definition parameter in the Schedule/Job Information Record contains descriptive information about the job and/or schedule. It accepts any keyboard input.

The DESC Control-M job scheduling parameter provides a description of the job in free text.

The conversion tool converts this parameter by placing the schedule DESCRIPTION in the DESC field of every job in the corresponding table. A DESCRIPTION in the job definition overrides the schedule DESCRIPTION, if any, for that particular job.

41. DASD, TAPE, U/R

The DASD, TAPE, and U/R CA-SCHEDULER parameters identify how many of each type of DASD, tape, and unit record devices a job uses, and how many must be available before a job can start.

The RESOURCE Control-M job scheduling definition parameter specifies the Quantitative resources required by a job, and the quantities of those resources. The conversion tool converts these CA-SCHEDULER resources to Control-M Quantitative resources, using the same resource names.

The various Quantitative resources created by the conversion tool, and their maximum quantities, must be added to the Control-M Resources file.

42. LIBTYPE=DRIVER

The LIBTYPE=DRIVER CA-SCHEDULER schedule and job definition parameter specifies that a self-contained procedure is to be submitted. Self-contained procedures must contain the full job stream including the MVS JOB statement.

The conversion tool reads the CA-SCHEDULER LIST SCHEDULE NAME=* Report file, and analyzes the records for LIBTYPE=DRIVER definitions. If the CA-SCHEDULER job definition or the schedule definition (which is used as the default for all jobs in the schedule) specifies LIBTYPE=DRIVER, instream JCL is created in the converted Control-M job definition and contains the following Control-M AutoEdit statements:

• %%SET statements

  In CA-SCHEDULER, default values can be specified in the DRIVER PARMS definition parameter for the variables of the procedure. The conversion tool converts each default value assigned to a variable in the DRIVER PARMS definition parameter into an appropriate Control-M AutoEdit %%SET control statement.

  When the CA-SCHEDULER job definition specifies Restart CA-Driver parameters, the conversion tool converts them exactly the same as normal CA-Driver parameters, but encloses the %%SET statements within the following Control-M Autoedit statements:

  %%IF %%RN GT 00001

  %%ENDIF

  This ensures that the %%SET statements take affect only when the job is restarted or rerun.

• %%INCLIB and %%INCMEM statements

  These statements copy the self-contained procedure from the member name specified in the LIBMEMB CA-SCHEDULER parameter. The %%INCLIB statement specifies the name of the PROCLIB library. The %%INCMEM statement specifies the LIBMEMB CA-SCHEDULER parameter value.

43. PROC, STEP, FAIL OPER, FAIL CODE

The CA-SCHEDULER job step record (JSR) is used to define FAIL CODEs for job steps. If a job step ends with a condition code that falls within the range specified by the FAIL CODE and FAIL OPER values defined in the JSR, CA-SCHEDULER assigns the job a status of FAILED. The PROC and STEP fields are used to identify the procedure step name and program step name that must be checked for a particular FAIL CODE value.

In Control-M, step-level condition code processing is done using the ON PGMST parameter. The contents of the PROC and STEP CA-SCHEDULER parameters are copied to PGMST and PROCST Control-M parameters. FAIL OPER and FAIL CODE values are converted in the way described in the following table:

Table 14 Conversion of FAIL OPER and FAIL CODE Values

44. WLM SCH ENV

The WLM SCH ENV CA-SCHEDULER job and schedule definition parameter specifies the MVS workload management scheduling environment that is required to execute the job.

The SCHENV Control-M scheduling definition parameter specifies the MVS scheduling environment that is required to execute the job. It causes the following expression to be inserted into the JCL job statement of the job:

SCHENV=sched_environment

In this expression, sched_environment is the designated MVS scheduling environment.

45. START SCD schedule-name

The START SCD schedule-name CA-SCHEDULER criteria definition parameter determines dependency on the start of an CA-SCHEDULER schedule.

The conversion tool converts this criteria definition as follows:

1. An IN condition is placed in the Control-M job scheduling definition. The format of the condition is

   tableName-START-OK

   where tableName is the name of the Control-M table that corresponds to the CA-SCHEDULER schedule.

2. An OUT condition is placed in a dummy Control-M job scheduling definition named $START in the table corresponding to schedule-name in the START SCD statement. The format of the condition is

   tableName-START-OK

   where tableName is the name of the Control-M table that corresponds to the CA-SCHEDULER schedule.

46. JES ROUTE PRINT

When the JESRPRT conversion parameter is set to Y (see "JESRPRT" in Conversion Parameters), the conversion tool searches the JCL member of each job for JES ROUTE PRINT new-dest statements, and converts them to Control-M SYSOUT post-processing parameters in the format

SYSOUT OP N new-dest

where

• N specifies that the held output destination of the job is to be changed to new-dest

• new-dest is the first eight characters of the destination parameter specified on the JES ROUTE PRINT statement

The JES ROUTE PRINT statement is deleted from the JCL run stream.

47. NON-EXEC

The NON-EXEC CA-SCHEDULER parameter determines whether the job is submitted normally. If the job is marked as Non-Executable, the job is immediately marked as successfully completed (with a return code of NOEX) and successor jobs are posted. Non-Executable jobs still wait for early start times, all predecessors, virtual resources, and so on. A job or jobs can be marked as Non-Executable to remove them from a job stream without having to change any of the successor jobs.

When NON-EXEC is set to YES, the conversion tool sets the Control-M OVERLIB parameter to DUMMY to indicate that the job is not to be executed. Instead, the job is marked as ENDED-OK and allows all post-processing actions to proceed.

48. REPEAT

The REPEAT CA-SCHEDULER schedule and job definition parameter determines whether the job is repeated once it has completed. Logically related to the REPEAT parameter are the following:

• INTERVAL – Indicates the amount of time between iterations of the job.

• FROM – Determines whether the interval between iterations is added to the previous start or end time.

• COUNT – Indicates the maximum number of times that the job is repeated. In other words, the job executes COUNT + 1 times.

• END TIME – Indicates that the job is not repeated after this time.

In Control-M, repeated schedules and jobs are referred to as cyclic tables and jobs. Cyclic entities are defined using several job definitions. When REPEAT is set to YES, the TASKTYPE parameter of the table or job is set to TBC/CYC, MAXWAIT is set to 0, and the conversion tool converts the remaining CA-SCHEDULER parameters as follows:

49. JOB TYPE

The JOB TYPE CA-SCHEDULER parameter indicates the type of this job. Job type determines how the job is submitted. The various job types are:

• BATCH – Indicates that the job is written to the internal reader.

• XPLAT – Indicates that the job is sent to another system as a cross-platform job.

• OSCMD – Indicates that the job consists of operator commands.

• STC – Indicates that the job is a started task.

The conversion tool supports the BATCH and STC options by setting the Control-M TASKTYPE parameter to JOB and STC, respectively. For Started tasks, the normal JCL member (defined by the LIBTYPE, DDNAME, and MEMBER fields) is read. If the member does not exist, the conversion sets the MEMLIB parameter to '*'. If the member is found, then the contents are used as parameters in the START command (ignoring lines starting with an asterisk (*) in column one). Parameters may be continued on multiple lines.

In such cases (JOB TYPE=STC), the MEMLIB is set to '*,parms'.

If the length of the parms exceed 42 characters, then the text of the parms are placed in Control-M SETVAR parameters %%P1, %%P2, and %%P3; and the MEMLIB is set to '*,%%P1.%%P2.%%P3'.

The conversion tool supports the XPLAT option for cross-platform jobs in the same way it processes the NODE ID *REMOTE parameter. For more information, see 11. NODE ID.

The conversion tool supports the OSCMD option by setting the Control-M MEMLIB job definition parameter to DUMMY. The normal JCL member (defined by the LIBTYPE, DDNAME, and MEMBER fields) is read. Each (non-comment) line of the JCL member is placed into a Control-M SHOUT statement as follows:

SHOUT WHEN OK    TO TSO-CMD          URGN R
  MS command-text   

The user must install IOA sample exit IOAX034A that causes the above SHOUT statement, with the special destination of TSO-CMD, to be treated as a request for issuing an operator command. See Step 10: Perform Final Adjustments for further details.

50. HOLD

The HOLD CA-SCHEDULER parameter determines whether the schedule or job should be held when entering the active workload. If YES, the schedule or job is held when added to the workload.

When HOLD is set to YES, the conversion tool sets the Control-M CONFIRM parameter to Y to indicate that the SMART Table or job is to wait for manual confirmation before becoming eligible for submission.

CA-DRIVER Parameters

The items in the following section describe the conversion of JCL and CA-DRIVER parameters.

51. DPROC

The DPROC CA-DRIVER procedure definition statement is used to start a procedure. The procedure consists of all the statements following the DPROC statement. A default value can be optionally defined for each variable.

The conversion tool creates one member for every CA-DRIVER procedure, and places them in a special library called PROCLIB.

The Control-M AutoEdit %%SET control statement is used to set values for user-defined variables. The conversion tool converts each default value that is assigned to a variable in the DPROC statement into an appropriate Control-M AutoEdit %%SET control statement, as follows.

//* %%RESOLVE NO                   
//* %%SET %%A=%%SUBSTR %%variable-name 1 2
//* %%IF %%A EQ %%                 
//* %%SET  %%variable-name=variable-default-value
//* %%ENDIF

The effect is as follows:

• All variable values are treated as non-numeric character data.

• In CA-DRIVER, a variable parameter can be assigned multiple values or array elements. The conversion tool converts each array element to a Control-M AutoEdit variable name, consisting of the CA-DRIVER array name with the element number appended to it (variable-name_nnn).

• In CA-DRIVER, default values can be specified for the procedure variables in the EXEC statement. If values are specified in both the DPROC statement and the EXEC statement, the values in the EXEC statement override the DPROC default values.

The CA-SCHEDULER JCL member that EXECutes a CA-Driver procedure (DPROC) is modified in-place. This member may also specify variable parameters that override those defined in the CA-Driver procedure. The way a JCL member (which may invoke multiple procedures) is converted and the override variables are processed is as follows:

In Control-M, the current AutoEdit %%SET control statement overrides the previous value of the variable. A Control-M AutoEdit %%SET control statement is assigned to each override variable in the EXEC statement.

These are followed by the invocation of the converted CA-Driver procedure as follows:

%%INCLIB converted-procedure-lib-name %%INCMEM procedure-member-name

52. DSTEP

The DSTEP CA-DRIVER procedure command is used to assign a name to a control statement. Naming a control statement allows branching to the statement from DIF or GOTO/DGOTO commands.

The Control-M AutoEdit %%GOTO and %%LABEL control statements provide the AutoEdit facility with GO TO logic, permitting simple inclusion or exclusion of job steps, DD cards, input cards, and so on.

The conversion tool converts the DSTEP CA-DRIVER command to a Control-M AutoEdit %%LABEL control statement.

53. DGOTO

The GOTO/DGOTO CA-DRIVER procedure command is used to stop procedure expansion, branch forward and backward to another control statement, and continue expansion from that point.

The Control-M AutoEdit %%GOTO control statement provides the AutoEdit facility with GO TO logic, permitting simple inclusion or exclusion of job steps, DD cards, input cards, and so on.

The conversion tool converts the GOTO/DGOTO CA-DRIVER command to a Control-M AutoEdit %%GOTO control statement.

54. DSET

The DSET CA-DRIVER procedure commands are used to change the value of a variable during conditional expansion.

The Control-M AutoEdit %%SET control statement is used to set values to user-defined variables.

The conversion tool converts the DSET CA-DRIVER command to a Control-M AutoEdit %%SET control statement, as follows.

• Arithmetic operators + and – are converted, respectively, to %%PLUS and %%MINUS Control-M functions.

• A blank character included in a string is converted to a Control-M AutoEdit %%BLANK control statement.

For a list of the special pre-defined date functions specified in the DIF/DSET statements which are supported by the conversion tool, see 60. Date Functions.

55. DIF

The DIF CA-DRIVER procedure command is used for conditional forward and backward branching.

The Control-M AutoEdit %%IF, %%ELSE, and %%ENDIF control statements provide the AutoEdit facility with a powerful Boolean IF logic capability. These statements, as well as the %%GOTO and %%LABEL control statements, permit branching based on different runtime criteria.

The conversion tool converts the DIF CA-DRIVER command to Control-M AutoEdit %%IF and %%ENDIF control statements.

56. DATA, DEND

The DATA and DEND statements from the CA-DRIVER procedure and execution JCL, respectively, are used to read one or more records from the JCL job stream. CA-DRIVER replaces the DATA statement with the statements that follow the EXEC statement in the execution JCL job stream until a DEND statement is reached. This means that each DATA statement acts as a place holder for the actual data which is supplied by execution JCL member, and the DEND statement is the data stream delimiter.

When there are multiple DATA and DEND statements in a procedure and its corresponding execution JCL member, then the data stream for each DATA statement is copied beginning from the prior DEND statement until the next DEND statement is reached.

For each DATA and DEND pair, the conversion tool creates a member in a special library called DATALIB. This member contains the statements between the EXEC and the next DEND statement, as well as the statements between two DEND statements. The name assigned to this member is DATnnnnx, where

• nnnn is a number, in ascending order, for each EXEC statement encountered in the JCL library which executes a CA-DRIVER procedure

• x is a suffix (A-Z, @,#,$) which is iterated for each DATA and DEND pair in the procedure

The assignment of this member name is set in the AutoEdit variable %%DATPREF.

The conversion tool establishes the connection between the statements in the member and the converted procedure by converting the CA-DRIVER DATA statement to Control-M AutoEdit %%INCLIB and %%INCMEM control statements. These control statements copy the statements in the member. The %%INCLIB statement specifies the name of the DATALIB library. The %%INCMEM statement specifies the AutoEdit %%DATPREF%%.x variable, where x is the same suffix in the DATnnnnx member name.

57. DNEST

The NEST/DNEST CA-DRIVER procedure commands are used to call another CA-DRIVER procedure, which can, in turn, call another procedure.

The Control-M AutoEdit %%INCLIB and %%INCMEM control statements define a library and a member that are to be included in the job stream.

The conversion tool converts the NEST/DNEST CA-DRIVER statement to Control-M AutoEdit %%INCLIB and %%INCMEM control statements that copy the called procedure into the job stream.

If a CA-DRIVER nested procedure specifies override parameters, the conversion tool does the following:

• Converts the override parameters into a member containing AutoEdit user variable definitions. The member name is of the form NSTnnnnn and is placed in a special LIBSYM library.

• A %%LIBSYM/%%MEMSYM statement that refers to the NSTnnnnn member is added prior to the %%INCLIB statement that calls the procedure.

• Following the %%INCLIB/%%INCMEM statement that invokes the procedure, adds a %%LIBSYM/%%MEMSYM statement that cancels the effect of these variable definitions by placing a minus sign in front of the member name.

When there are no override parameters on the DNEST statement, the NSTnnnnn member created is empty.

58. DABORT/DFLUSH

The DABORT/DFLUSH CA-DRIVER procedure commands are used to terminate the procedure expansion completely.

The conversion tool converts DABORT/DFLUSH CA-DRIVER commands to invalid Control-M AutoEdit control statements. As a result, the job is not submitted by Control-M, and a warning message is issued. The format of the invalid control statement is:

//*  %%ABORTED DELIBERATE SYNTAX ERROR !

59. Variable parameters

CA-DRIVER variable parameters are converted to Control-M %% AutoEdit variables. When a CA-DRIVER variable contains a substring reference, it is converted to an AutoEdit %%SUBSTR function when referenced in DSET CA-DRIVER commands.

Array type CA-DRIVER variables are also supported.

The CA-DRIVER Reserved-Name Variable parameters in the following table are supported when referenced in CA-DRIVER DIF and DSET commands. Entries in the Note No. column refer to the notes that follow the table.

All these variables are translated in the DAYMONTH AutoEdit Global Definition member. For more information, see Step 10: Perform Final Adjustments.

Table 15 Supported CA-DRIVER Reserved-Name Variables

Notes

1. This variable definition depends on the site date format standard.
   If the DATETYP IOA installation parameter was set to J, the AutoEdit Variable Definition is %%YEAR%%./%%MONTH%%./%%DAY. If the DATETYP parameter was set to W, the format is %%DAY%%./%%MONTH%%./%%YEAR.
   If the DATETYP parameter was set to A, the format is %%MONTH%%./%%DAY%%./%%YEAR. Setting %%OUTDATE to its proper value is done in the DAYMONTH AutoEdit Global Definition member. For more information, see Step 10: Perform Final Adjustments.

2. Operators * (multiply) and / (divide) are not supported.

3. %%JOBNUM is defined in a SETVAR parameter of the Control-M job-scheduling definition.

4. The parameter names &DATE, &TIME, &DAY, and &MONTH conflict with Control-M system variable names; to avoid this problem, the conversion tool converts them to %%@ATE, %%@IME, %%@AY, and %%@ONTH respectively. If these parameters are used as CA-SCHEDULER reserved-variable names, customize the DAYMONTH member as instructed in Step 10: Perform Final Adjustments.

60. Date Functions

CA-DRIVER Date functions are converted to Control-M %% AutoEdit functions when referenced in DIF/DSET CA-DRIVER commands.

In most cases, a block of AutoEdit variables is necessary to fully convert the CA-DRIVER date function. The following table lists the CA-DRIVER Date functions that are supported, but includes only the main operative AutoEdit functions involved, without listing any secondary AutoEdit functions needed.

The DAYMONTH member is also necessary for many of the functions listed below. For more information, see the preceding item, Item 59, particularly notes 1 and 2.

The CA-DRIVER Date functions that are supported are shown in the following table.

Table 16 Conversion of CA-DRIVER Date Functions

61. Attribute Functions

CA-DRIVER ATTRIBUTE functions are converted to Control-M %% AutoEdit functions when referenced in CA-DRIVER DIF or DSET commands.

The CA-DRIVER ATTRIBUTE functions that are supported are shown in Table 17.

Table 17 Supported CA-DRIVER ATTRIBUTE Functions

62. CAJUCMD0 utility

The CA-Scheduler CAJUCMD0 utility is a batch program which can be used to

• Send messages to the console operator.

• Issue CA-Scheduler control commands.

• Issue VM commands (when running on an MVS VM guest).

The CA-Scheduler commands perform various control, monitoring, and tracking functions, including:

• Add jobs or schedules to the workload.

• Hold a job or schedule.

• Release the hold on a job or schedule.

• Rerun ABENDed, failed, interrupted, canceled, completed jobs.

• Satisfy a predecessor condition by supplying a value that matches the value specified by GBLxnn on the CRITERIA keyword.

The CTMUTIL Control-M utility provides similar functionality. Table 18 lists the supported commands and how they are converted.

Table 18 Conversion of CA-Scheduler CAJUCMD0 Commands

Conditional CA-Scheduler commands (SC IF . . ) are not supported.

The only Batch commands converted are those specified as input to programs and procedures CAJUCMD0 and CAJUTIL0. The commands must be specified in non-concatenated SYSIN-type statements, with or without a stepnamequalification. Only one command is recognized in each line, and can appear in any one of the following positions:

• In a PDS member.

• In a sequential data set.

• In stream, for example, following the statements //SYSIN DD * or //SYSIN DD DATA, or no SYSIN statement at all.

For more information on see "PNIBTSD" in Conversion Parameters.

Unsupported commands in SYSIN and extraneous DD statements are deleted.

The CTMUTIL utility is the Control-M equivalent of the CA-Scheduler Batch CAJUCMD0 procedure. CTMUTIL serves as the umbrella procedure for invoking IOAAPI, CTMAPI and IOATEST whenever their functionality is required. For more information on the CTMUTIL utility, see Conversion Parameters.

65. NODE

The NODE statement contained in a JCL member for a distributed CA-Scheduler schedule/job definition identifies the specific distributed platform where the job runs. The conversion sets the Control-M NODEID parameter (host name of an agent computer) to the NODE name.

66. COMMAND

COMMAND statements contained in a JCL member for a distributed CA-Scheduler schedule/job definition identify Agent-platform commands to run when defining jobs for the Agents running on non-z/OS platforms. You can specify multiple COMMAND statements, which are concatenated to form the full directory/path name.

The conversion tool converts the COMMAND as follows:

The Control-M TASKTYPE parameter is set to 'Command'. The Control-M CMDLINE parameter is set to the command string in the COMMAND statements. If the command string is very long, the conversion breaks the string into two SETVAR auto-edit variables—%%0 and %%1—and the CMDLINE parameter is then set to %%0.%%1.

When a CMDLINE parameter is created in the job definition XML, neither a MEMLIB nor a MEMNAME parameter are created.

67. TYPE (DSCLOSE)

CA-Scheduler Cross-Platform External Tracking event type DSCLOSE specifies the name of a file (on a distributed platform) to monitor for a file update event. When the event occurs, the CA-Scheduler command in parameter COMMAND is executed.

To convert DSCLOSE events (other event types are not supported), a Control-M/EM file-watcher rule is created with the CMDLINE parameter set to ctmfw filename where

• ctmfw is the Control-M/EM file watcher program that performs the file triggering function

• filename (in parameter NAME) is specified as a parameter to program ctmfw

The following CA-Scheduler commands are supported:

• RUN (either S(chedule) or J(ob)), which is converted to the Control-M ON PGMST . . . DO FORCEJOB statement.

• COMPlete and RELease commands, which are converted to the Control-M OUT DSTRGnnn_jobname_station-id statement. The job that is to be completed or released has a corresponding IN condition added to its job definition.

68. DOMAIN

On some platforms, such as Microsoft Windows NT, users can be defined within domains. The DOMAIN statement might be contained in a JCL member for a distributed CA-Scheduler schedule/job definition and is converted along with the USER statement to the Control-M OWNER parameter with the value domain\user.

70. HISTRET

For CA-Scheduler R11.0 and above, the CA-SCHEDULER HISTRET job or schedule definitions are converted to Control-M RETENTION: # OF DAYS TO KEEP nnn. For all releases below R11.0, the HISTORY parameter, described in Conversion Parameters is used to determine the setting of the Control-M Retention parameters. Any value nnn greater than 999 is set to 999.

Unique Control-M Parameters

Several unique Control-M job scheduling definition parameters can be set by the conversion tool in the process of creating the Control-M tables. The DEFAULTS member in the conversion source library contains these unique conversion parameter settings, and must be reviewed and if necessary modified to specify your local Control-M preferences. For more information regarding these parameters, see Conversion Parameters and the Control-M for z/OS User Guide.

The unique Control-M parameters are as follows.

DO SYSOUT

Specifies how the output of the job is handled.

At job completion, Control-M analyzes the output of the job. To enable Control-M to locate the output of the job on the system spool, Control-M modifies the JCL MSGCLASS parameter of the job at time of submission to the automatically held output class defined during installation (the Control-M HLDCLAS parameter). After analyzing the sysout, Control-M can be ordered to requeue the sysout. For more information regarding DO SYSOUT options, see the Control-M for z/OS User Guide.

The conversion tool can be instructed to specify various actions using the Control-M DO SYSOUT facility.

The TOCLS conversion parameter specifies the output class to which Control-M requeues the job output. For more information, see "TOCLS" in Conversion Parameters.

The RELEASE conversion parameter instructs Control-M whether to release the output of the job for printing on the system spool. For more information, see "RELEASE" in Conversion Parameters.

RESOURCE

A Control-M Quantitative resource, INIT, that is added, with a quantity of 1, to the job scheduling definition of each non-dummy executable job, to control initiators.

ADJUST CONDITIONS

The ADJUST CONDS parameter indicates whether to ignore prerequisite conditions normally set by predecessor jobs, if the relevant predecessor jobs are not scheduled. Ignoring prerequisite conditions normally set by predecessor jobs can cause dependent jobs to run out of order. The conversion tool maintains the Job order by setting the ADJUST CONDS parameter to D(ummy), which is the equivalent of inserting dummy jobs in place of the prerequisite jobs that are not run.

For jobs running on Control-M distributed platforms, the AJUST CONDS parameter is set to Y; the Control-M/Server CTM_GROUP_ADJUST_DUMMY configuration parameter controls the creation of dummy jobs that run in place of unscheduled prerequisite jobs, as follows:

• Y: a dummy job waits for the prerequisite conditions expected by the job it is replacing, and performs the post- processing of the job.

• N: Out conditions of the jobs that were not ordered are ignored by the ordered jobs in the SMART Table. (Default)