JCL and AutoEdit Facility

This chapter includes the following topics:

• Overview of JCL and AutoEdit Facility

• System Variables

• User-Defined Variables

• Rules of Variable Resolution

• Control Statements

• Operators

• Functions

• Testing AutoEdit Syntax

• AutoEdit Usage in the Job Scheduling Definition

• Examples for JCL Setup and AutoEdit

Overview of JCL and AutoEdit Facility

In the production environment, it is often necessary to manually modify JCL prior to submission of a job, as in the following cases:

• changing a parameter or a date card

• supplying tape numbers in JCL procedures

• eliminating steps under different run conditions (for example, end of month processing versus normal daily run)

Manual modification of JCL is inconvenient at best, and it may, in fact, be error prone and lead to serious problems.

The AutoEdit facility offers an automated alternative to manual JCL modification. This facility permits AutoEdit terms (variables, functions, and similar terms, described in this chapter) to be specified in the JCL in place of values that change from job submission to job submission. At time of job submission, these terms are resolved to their actual values.

The inclusion of AutoEdit terms in the job stream can eliminate the need to continually change the JCL. Some AutoEdit terms can also be used in job scheduling definitions.

AutoEdit terms are prefaced by a %% symbol, which distinguishes them from terms that are not AutoEdit terms. For example, the term %%ODAY is recognized as an AutoEdit term.

The components of the AutoEdit facility are described briefly in the following sections and in greater detail later in this chapter.

Variables Overview

Variables are the main components of the AutoEdit facility. Variables are used to replace manually changed values, generally within the JCL. AutoEdit variables can be either of the following types:

• System Variables

  System variables are predefined, reserved variables that represent information about the system.

  System variable %%ODATE is replaced by the job’s original scheduling date.

• User-Defined Variables

  User-defined variables are created by the user. The user must provide the value (or the tools to derive the value) that replaces the variable at time of job submission.

  The user can define a variable, %%SPACE-TYPE, to represent the type of storage unit (cylinder or track) on disk.

  User-defined variables are either:

  • Local variables

    Local variables are used only within the job stream. The value of a local variable can be set or changed within the job stream by Control-M, but the changed value is kept only in memory for use during submission of that job stream. The value is not passed to another job stream.

  • Global variables

    Global variables are user-defined variables that are placed in the IOA Global Variable database, from which they can be accessed and updated by other Control-M jobs and Control-O rules.

  • Pool variables

    Pool variables are variables that are contained in a pool, which is a collection of variables and which can be referenced by the pool name from any job that is currently active.

    System variables and user-defined variables are discussed in detail below. Local variables, Global variables, and Pool variables are also discussed in detail, under the topic of user-defined variables.

• Control Statements

  AutoEdit control statements in the JCL define the environment for user-defined variables. The AutoEdit facility supports many AutoEdit control statements, and this is discussed in detail later. Some of the more important control statements are described here briefly.

Table 247 AutoEdit Control Statements

Operators Overview

AutoEdit operators modify the values of AutoEdit variables in the JCL. For example, in the following statement, operator %%PLUS assigns a number to a scratch tape that is one higher than the previously assigned tape number:

//* %%SET %%SCRATCH=%%SCRATCH %%PLUS 1

Functions Overview

AutoEdit functions perform functions on specified AutoEdit variables in the JCL. For example, in the following statement, the %%CALCDATE function sets AutoEdit variable %%NEXTDAY to one day after the current System variable %%ODATE:

//* %%SET %%NEXTDAY=%%CALCDATE %%ODATE +1

The format of a function statement depends on the function.

AutoEdit Components in the Job Scheduling Definition

Although the most important and common use of AutoEdit components is in JCL setup, certain AutoEdit components can also be used in the job scheduling definition.

SET VAR and DO SET job scheduling definition statements assign values to user-defined variables. These statements perform a similar function as, and work together with, %%SET and %%SETB control statements specified in the JCL.

Other job scheduling definition statements (for example, SYSOUT, SHOUT, MEMLIB) allow specification of System variables.

JCL Setup and AutoEdit Features

The rest of this chapter contains a description of the following JCL Setup and AutoEdit topics:

• System variables

• User-Defined Variables

• JCL Setup Operation Flow

• Rules of Variable Resolution

• Control Statements

• Operators

• Functions

• Testing AutoEdit Syntax

• AutoEdit Usage in the Job Scheduling Definition

• Examples for JCL Setup and AutoEdit

System Variables

Control-M System variables are predefined, reserved, commonly used variables whose values are automatically updated and maintained by Control-M. The System variable format is:

%%var

where var is the name of the System variable.

Each variable resolves to the corresponding system value. The length of the line is changed accordingly. For example:

//EJ%%ODATE   JOB (0,l5, ...
//  EXEC ACCOUNTS,DAY=%%ODAY,MONTH=%%OMONTH

If the original scheduling date is June 5, 2001, the variables are resolved as follows:

//EJ000603   JOB (0,l5, ...
//  EXEC ACCOUNTS,DAY=05,MONTH=06

Non-Date System Variables

The following AutoEdit System variables are supported by Control-M (in both JCL and in job scheduling definitions):

Table 248 Non-Date AutoEdit System Variables

/*JOBPARM SYSAFF=CPU%%$SIGN

Date System Variables

Many System variables specify dates, or parts of dates, in various formats. Therefore, it is useful to understand the categories of dates with which Control-M is concerned.

Dates are divided into the categories listed below. For a description of these categories, see Date Definition Concepts.

• Working Date

  System variables that specify working dates begin %%R (%%RDATE, %%RDAY, and so on).

• Original Scheduling Date

  System variables that specify original scheduling dates begin %%O (%%ODATE, %%ODAY, and so on).

• System Date

  System variables that specify system dates have no special prefix other than %% (%%DATE, %%DAY, and so on).

Although these types of dates are resolved in Gregorian format, Julian formats can also be requested (%%JULDAY, %%OJULDAY and %%RJULDAY).

The following date AutoEdit System variables are supported by Control-M in JCL and in certain job scheduling definition parameters (for more information, see AutoEdit Usage in the Job Scheduling Definition):

Table 249 Date AutoEdit System Variables

The following AutoEdit System variables, prefixed %%$, resolve to dates having 4-character years:

Table 250 4 Character Year Date AutoEdit System Variables

Special System Variables

Special System variables are resolved during specific parts of the life cycle of jobs.

The following are the types of special System variables:

• those that are resolved after a SMART Table is ordered but before any of the jobs in the table are ordered

• those that can only be resolved after the job has ended

• those that can only be resolved after job submission

Special System variables of the latter types, that is, those that can only be resolved after the job has ended and those that can only be resolved after job submission, can only be used with the post-processing parameters in the job definition, such as SHOUT and DO IF RERUN.

Special System Variables Resolved After a SMART Table Is Ordered, but Before Job Submission

The special System variable shown in Table 251 can only be resolved after a SMART Table is ordered, but before job submission.

Table 251 Special AutoEdit System Variable Resolved after a SMART Table Is Ordered but Before Job Submission

Special System Variables Resolved After End of Job

The special System variables in Table 252 can only be resolved after the job has ended. These variables contain a blank value if the job ends OK or if no step in the job was run.

Table 252 Special AutoEdit System Variables Resolved after Job End

Special System Variables Resolved after Job Submission

The special System variable shown in Table 253 can only be resolved after job submission. This variable contains a blank value if the job ends OK or if no step in the job was run.

Table 253 Special AutoEdit System Variable Resolved after Job Submission

User-Defined Variables

The ability to specify user-defined variables provides additional flexibility. You can define your own variables and assign values to them. Control-M automatically edits the job stream accordingly. This facility is especially useful when it is necessary to share parameters or other information (for example, tape numbers) among jobs.

Control-M assumes that strings that begin with %% are user-defined variables, except for certain reserved System variables (which usually, but not always, begin with %%$).

For a list of all System variables, see System Variables.

User-defined variables are defined as either:

• Local variables, which are discussed in Local Variables

• Global variables, which are discussed in Global Variables

Multiple AutoEdit variables can be joined with each other and with constants, and periods (.) are often part of this process (for example, JOB_%%JOBID%%._ENDED_OK). This is discussed in more detail in Rules of Variable Resolution.

Backslashes (\) are used only in Global variable assignments, and differentiate Global variables from local variables. For more information, see Global Variable Assignment and Syntax.

Unlike System variables, which are predefined and which receive their values from the system at time of job submission, two steps are performed for utilizing user-defined variables:

• The first step consists of specifying (defining) user-defined variables, usually within the JCL, instead of values that require manual modification.

• The second step consists of providing values to replace the user-defined variables at time of job submission. (Since the values are not provided by the system, the user must specify the appropriate values.) It is permissible, however, for user-defined variables to take their values from System variables (for example, %%SET %%VERSION = %%ODATE).)

User defined AutoEdit variables in post-processing statements of the scheduling definition (DO MAIL, DO SHOUT, and so on) are resolved according to the following search order:

• SET VAR statements in the job's definition

• SET VAR statements in the SMART Table Entity (for jobs belonging to a SMART Table)

• AutoEdit definitions loaded into the Control-M AutoEdit cache

Note that during post-processing, it is impossible to refer to an external library member containing AutoEdit variable definitions (that is, through %%LIBSYM xxxxx, %%MEMSYM yyyy, or %%GLOBAL zzzz statements). The only external method of resolving user AutoEdit variables for post-processing is to load the member(s) into the AutoEdit cache (see Loading Members to Cache).

Valid Characters in User-Defined Variables

When defining AutoEdit variables, only certain characters can be used. The validity of characters depends on the purpose for which they are being used.

AutoEdit Variable Names

AutoEdit variable names have a maximum of 163 characters. The following characters can be used in AutoEdit variable names:

• any character from A through Z, both uppercase and lowercase

• any digits from 0 through 9

• the following special characters:

  • & (Ampersand)

  • $ (Dollar)

  • _ (Underscore)

  • # (Octothorp)

  • @ (At)

• the following hexadecimal values:

  • from x'41' through x'49'

  • from x'51' through x'59'

  • from x'62' through x'69'

  • x'71'

• the %% characters indicating an embedded variable name. Use these characters only when the embedded variable will be resolved when the actual user variable is accessed. For example, in a SET command:

  %%SET %%BACKUP_UNIT_%%WDAY=value

AutoEdit Variable Value Fields

Any characters can be used in AutoEdit variable value fields except the following hexadecimal values:

• x'00'

• x'FE'

• x'FF'

AutoEdit Variables in JCL

In any JCL line that contains AutoEdit variables, do not use the following hexadecimal values unless their processing is excluded by a %%RANGE or a %%RESOLVE OFF statement:

• x'00'

• x'FE'

• x'FF'

Global AutoEdit Variables

The following characters have special meanings in Global AutoEdit variables:

• . (Period)

• \ (Backslash)

Do not use these characters in the variable name field unless you require the special meaning assigned to them.

Local Variables

Local variables are user-defined variables that are only within the job stream. The value of a local variable can be changed within the job stream, but the changed value is kept only in memory for use during submission of that job stream. The value is not passed to another job stream.

Local variables can be defined in either of two ways:

• by means of %%SET and %%SETB statements in the JCL and/or SET VAR and DO SET statements in the job scheduling definition

  %%SET and %%SETB statements are described under Control Statements. SET VAR statements are described in SET VAR: General Job Parameter, and DO SET statements are described in DO SET: Post–processing Parameter.

• by placing the variables and their values in special variable members

  Variable members are members dedicated to holding user-defined AutoEdit variables and their values. These variables and values in these members can be used by any number of Control-M jobs or Control-O rules that are given access. However, these jobs and rules cannot update these members.

Members containing user-defined variables can be identified in either of two ways:

• by a %%MEMSYM control statement

  This member must reside in the library specified in the %%LIBSYM statement that must accompany the %%MEMSYM statement. (The control statements %%LIBSYM and %%MEMSYM are described in Control Statements.) Any number of such variable members can be defined.

• by a %%GLOBAL control statement

  This statement differs from the %%MEMSYM statement in that it does not have an accompanying %%LIBSYM statement. Instead, the library in which the %%GLOBAL member resides is pointed to by a DAGLOBAL DDstatement.

//S001.INPUT DD VOL=SER=%%BRANCH_TAPE

%%BRANCH_TAPE=045673

Loading Members to Cache

%%GLOBAL or %%LIBSYM/%%MEMSYM members can be placed in cache memory, from where they can be accessed as needed. If the members are placed in cache, the JCL accesses the contents from the cache, instead of accessing the members themselves.

This can be very advantageous if many jobs access %%GLOBAL or %%LIBSYM/%%MEMSYM members, because each access of the member increases I/O and processing overhead.

Only those %%GLOBAL or %%LIBSYM/%%MEMSYM members that are specifically requested are loaded to cache. Requests are generally made by listing the desired %%GLOBAL or %%LIBSYM/%%MEMSYM members in a special cache list member in the DAGLOBAL library. This cache list member (default name: CACHLST) is pointed to by the AECACHL parameter in the CTMPARM member in the IOA PARM library.

Members are listed in the cache list member in the following format:

%%GLOBAL memname

where memname is the name of the %%GLOBAL member in the Global library.

The cache list member can optionally contain the following control statement as its first non-comment statement:

%%RESOLVE ALLCACHE

This control statement affects AutoEdit processing only if an AutoEdit variable has not been resolved by searching the %%GLOBAL or %%LIBSYM/%%MEMSYM members identified in the job. The statement instructs Control-M to continue the variable resolution process by checking all members loaded into cache. Members in cache are searched in the same sequence they are listed in the cache list member.

%%GLOBAL or %%LIBSYM/%%MEMSYM members are loaded to cache at time of Control-M startup.

To reload %%GLOBAL or %%LIBSYM/%%MEMSYM members to cache between Control-M startups or to stop using AutoEdit cache, see the corresponding topic in the INCONTROL for z/OS Administrator Guide.

Format of Variable Members

A variable member (referenced by %%GLOBAL or %%MEMSYM statements) must be a member in a partitioned data set with a record length of 80. It can contain the following types of lines:

• Remark Line: Line starting with an asterisk (*) in column 1. Remark lines are not processed.

• Assignment Line: Line that assigns a value to a variable. Use one of the following formats:

  • The following format is older, and it supports functions and operators:

    Copy

    %%varname=value

  • The following format enables you to use blanks in the variable value without using %%BLANKn variables, but does not support functions and operators:

    Copy

    %%varname:'value'

Any number of user-defined variables or AutoEdit functions (and their values) can be defined in a variable member. To designate a null value, omit the value.

* Last banking day in each month *
%%LAST_BANKING_DAY_0001=010131
%%LAST_BANKING_DAY_0002=010228
%%LAST_BANKING_DAY_0003=010330
%%LAST_BANKING_DAY_0004=010430
%%LAST_BANKING_DAY_0005=010531
%%LAST_BANKING_DAY_0006=010629
%%LAST_BANKING_DAY_0007=010731
%%LAST_BANKING_DAY_0008=010831
%%LAST_BANKING_DAY_0009=010928
%%LAST_BANKING_DAY_0010=011031
%%LAST_BANKING_DAY_0011=011130
%%LAST_BANKING_DAY_0012=011231

* Days of the week:
%%H0:'SATURDAY    '
%%H1:'SUNDAY        '
%%H2:'MONDAY      '
%%H3:'TUESDAY       '
%%H4:'WEDNESDAY '
%%H5:'THURSDAY    '
%%H6:'FRIDAY           '
*
*  Names of the computers:  
%%NAME_OF_COMPUTER_1=SYSA
%%NAME_OF_COMPUTER_2=SYSB
%%NAME_OF_COMPUTER_3=TEST

%%FIRWORKYY = %%SUBSTR %%DATE 3 2

Global Variables

A Global variable is a user-defined variable that is placed in the IOA Global Variable database.

%%SET and %%SETB statements in the JCL, and SET VAR or DO SET statements in the job scheduling definition, enable Control-M jobs and SMART Table Entities to define Global variables and place them in the IOA Global Variable database.

However, since %%SET, %%SETB, SET VAR, and DO SET statements also define local variables, a distinguishing factor is needed to differentiate Local Variables from Global variables. The distinguishing factor is provided by syntax, which is described in Global Variable Assignment and Syntax.

A Global variable from the IOA Global Variable database can be specified anywhere a local variable can be specified in the JCL or the job scheduling definition (SHOUT, DO SHOUT, SYSOUT, DO SYSOUT, MEMLIB and OVERLIB statements).

Structure of the IOA Global Variable Database

The IOA Global Variable database has a hierarchical structure consisting of several levels. This structure mirrors the hierarchical structure of the Control-M components of which a Control-M job is a part.

The levels in the IOA Global Variable database structure, starting from the lowest, are as follows:

Table 254 IOA Global Variable Database Structure Levels

The importance of this structure is discussed in the topic "Global Variable Assignment and Syntax" below.

The levels in the Pool Variable database structure, starting from the lowest, are as follows:

Table 255 Pool Variable Database Structure Levels

The importance of this structure is discussed in the topic Pool Variables.

Global Variable Assignment and Syntax

Whenever a job (or SMART Table Entity) creates a Global variable and places it in the IOA Global Variable database, it assigns an owner to the variable.

The job that creates the variable can assign itself as the owner (for example, JOBA defines a Global variable that is assigned to JOBA), but it does not have to do this. It can, instead, assign a different owner to the variable (for example, JOBA defines a Global variable that it assigns to GROUP_ABC).

In fact, when a Global variable is created, it can be assigned to any component (job, group, application, or even to Control-M) in the database. It is this ability to assign variables that makes the structure of the IOA Global Variable database so important.

The hierarchical structure of the IOA Global Variable Database, described above, is similar to the directory and subdirectory structure in Unix and DOS. Therefore, the same path structure and syntax that is used to describe directories and subdirectories is used to define and identify Global variables.

Note the following points about Global variable assignment and syntax:

• Global variables are identified (and distinguished from Local variables) by a backslash.

  • Variable %%PROBID is a Local Variable.

  • Variable %%\PROBID is a Global Variable.

• In the IOA Global Variable database, the format for indicating a full path is as follows:

  Copy

  %%\product\application\group\job\variablename

• Two variables with the same name but different paths are different variables. This is comparable to the fact that two Unix or DOS files with the same name but different paths are different files. For example, File A under \A\B\C directory is a different file than File A under \D\E\F directory.

  Due to the different paths, the following variables are all different from each other:

  Copy

  %%\M\APP_1\TBL_1\JOB_A\VAR_XYZ
  %%\M\APP_1\TBL_1\JOB_B\VAR_XYZ
  %%\M\APP_1\TBL_1\VAR_XYZ

• If the particular path has no Group and/or no Application (for example, the job does not belong to a group or application), Control-M utilizes the keyword values "NO_APPL" and "NO_GROUP" in the path, as needed.

• Paths can be specified using the same rules and shortcuts that are available with directories and subdirectories (instead of the full path):

  • A job or SMART Table Entity can assign a Global variable to itself by specifying a slash immediately following the %% symbol.

    If JOB1 job with TBL_A group, which belongs to application APP_1, then the following SET VAR statement in JOB1:

    Copy

    SET VAR=%%\PROBID=123

    creates the following variable assigned to JOB1 (with the indicated full path):

    Copy

    %%\M\APP_1\TBL_A\JOB1\PROBID=123

  • Paired dots with a backslash (..\) indicate movement to the next level up.

    If JOB1 with TBL_A group, which belongs to application APP_1, then the following SET VAR statement in JOB1:

    Copy

    SET VAR=%%..\PROBID=123

    creates the following variable assigned to TBL_A (with the indicated full path):

    Copy

    %%\M\APP_1\TBL_A\PROBID=123

  • To move directly down the hierarchy, it is only necessary to indicate the levels that are lower than the current level. (However, since only SMART Table Entities and jobs utilize variables, only SMART Table Entities can move directly down a level.

    Assume SMART Table Entity with TBL_A assigns variable %%A, with a value equal to 7, (%%A = 7) to JOB2 job. The following statement indicates the syntax of the %% SET statement:

    Copy

    //* %%SET %%\JOB2\A=7

  • To move across the hierarchy (that is, to change paths), you can either:

    • Specify a full path, or

    • Move up to a component common to both paths, and then move down the other path.

      Assume JOB1 job with TBL_A group assigns variable %%A (with a value equal to 7) to JOB2 job in the same group (and assume the group has no application). Any of the following statements can be specified:

      Copy

      //* %%SET %%..\JOB2\A=7
      //* %%SET %%\M\NO_APPL\TBL_A\JOB2\A=7

      Assume JOB1 job, with TBL_A group, which is in application APP_A, assigns variable %%A, with a value equal to 7, to JOB2 job with TBL_B group and which does not have an application.

      Either of the following %% SET statements work:

      Copy

      //* %%SET %%\M\NO_APPL\TBL_B\JOB2\A=7
      //* %%SET %%..\..\..\NO_APPL\TBL_B\JOB2\A=7

• If two statements assign the same Global variable to the same component, the later assignment overwrites the earlier assignment.

  Assume JOB1 job with TBL_A group is run before JOB2 job with the same group (and both belong to application APP_A).

  If JOB1 contains the following SET VAR statement:

  Copy

  SET VAR=%%..\A=7

  and JOB2 contains the following SET VAR statement:

  Copy

  SET VAR=%%..\A=8

  At the end of the job run for JOB2, the IOA Global Variable database contains the following variable (assigned to TBL_A):

  Copy

  %%\M\APP_A\TBL_A\A=8

• A job or SMART Table Entity can utilize a Global variable that has been assigned to it by merely specifying the variable with the backslash, even if the variable was created by a different job. (The full path is not required.)

  Assume JOB1 job contained the following statement that assigned the following variable to JOB2:

  Copy

  DO SET VAR=%%\M\NO_APPL\TBL_A\JOB2\PROBID=123

  JOB2 can then access this variable in a DO SHOUT statement without a full path name by specifying the variable with a backslash.

  Copy

  DO SHOUTTOTSO-U0014URGENCY U
  =*** Problem Encountered. Problem ID=%%\PROBID***

• When changing paths or assigning a variable to a higher level component on the same path, a security check can be required.

• A job or SMART Table Entity can utilize a Global variable that has been assigned to a different component by specifying the appropriate path. However, before the variable could be utilized, security checks, if any, would have to be passed.

  If a Global variable is assigned to JOB1 job as in the following statement:

  Copy

  DO SET VAR=%%\M\NO_APPL\TBL_A\JOB1\PROBID=123

  and JOB2 accesses the variable, it would have to specify the appropriate path name (and pass any required security checks). For instance, JOB2 can access this variable in a DO SHOUT statement as follows:

  Copy

  DO SHOUT TO TSO-U0014 URGENCY U
  =**Problem Occurred. ID=%%\M\NO_APPL\TBL_A\JOB1\PROBID**

Pool Variables

A pool is a collection of variables that can be referenced by name, from any job that is currently active. A variable in a pool is referred to by a %%\\ prefix, followed by the name of the pool, a single backslash (\), and the name of the variable. For example, %%\\POOL\VAR. The "\" is not a valid character for either a pool or a variable name.

The name of a pool can either be a constant or a %%variable, which is resolved at order time. Variables in a pool are resolved during the assignment of the value to the variable.

Using the capabilities of setting variable values at order time and using local variables for the pool names allows the user to pass pre-defined pool names to the jobs at order time (for example, setting %%mypool=MYPOOL and then in the job using %%\\%%mypool\cnt=17), or to set values of variables in a pool to be used by the ordered jobs (for example, %%\\MYPOOL\cnt=17).

The pool variables, in the %%\\poolname\value format, can be used in JCL statements and they will be resolved at submission.

JCL Setup Operation Flow

All JCL setup operations are performed during job submission. At this time, Control-M processes the JCL of the job line by line.

Control-M scans each line for AutoEdit terms (identified by the %% symbol) and tries to resolve them (unless otherwise instructed). Control-M resolves all AutoEdit terms in a line before it moves to the next line.

All changes made during JCL processing (such as variable resolution) are retained only until Control-M has finished submission of the job.

Control-M resolves System variables by taking the values from the system.

Control-M resolves Global variables by taking the values from the IOA Global Variable database.

Values for Local user-defined variables can be taken from any of several possible sources (described below). When Control-M detects a local user-defined variable in the JCL line being processed, it checks these possible sources in a specific order until a value is found for the variable. Control-M creates a user-defined variable environment in which it places each user-defined variable and its value.

The potential sources for local user-defined variable values are listed below in the order in which they are generally checked:

• System variable values

• %%SET and %%SETB control statements

  These statements can be specified in JCL lines, including JCL comment lines. They assign values to variables.

• SET VAR and DO SET statements

  These statements can be specified in the job scheduling definition. They can be used to define new variables, or to assign new values to existing variables.

  SET VAR statements can affect all job submissions.

  DO SET statements can override values specified by a SET VAR or previous DO SET statement. However, since DO SET statements are post-processing parameters, they only affect subsequent runs of a job (rerun and restarted jobs).

• Local variables and values defined in members specified in %%LIBSYM / %%MEMSYM control statements

  These members define local variables and specify their values. Members are searched in the order in which they appear in the JCL.

• Local variables and values defined in members specified in %%GLOBAL control statements

  These members define local variables and specify their values. Members are searched in the order they appear in the JCL.

The order in which Control-M checks potential sources for possible AutoEdit variable resolution is important because once Control-M has resolved a variable, it generally stops checking other sources. Potential values from other sources are ignored, and resolved values are not overridden except by %%SET and %%SETB statements in subsequent JCL lines.

Because JCL is processed sequentially one line at a time, the line being processed can only be affected by external members and %%SET and %%SETB control statements that have previously been processed. If a line contains an undefined variable that is only defined in a subsequent line, the variable cannot be resolved.

By default, if Control-M cannot resolve a variable, it stops submission of the job. This default, however, can be overridden by specifying the %%RESOLVE control statement with a value of NO or OFF (described later in this chapter).

To stop submission of a job because of an unresolved variable, Control-M creates an intentional JCL error that prevents execution of the job’s already submitted JCL. The job ends with the status NOT SUBMITTED for reason JNSUB. The erroneous JCL remains on the spool, but does not affect other job executions except those that depend on the successful execution of this job.

Local variable values taken from variable members (%%MEMSYM and %%GLOBAL members) that are changed during job submission remain in effect only until Control-M finishes submission of the job. Therefore, a change made to such a variable (using the %%SET or %%SETB control statement) affects only submission of that job and does not affect any other job submission or the value of the variable in the variable member.

Rules of Variable Resolution

By default, columns 1 through 72 of JCL lines are searched for variables which are then analyzed and resolved. If column 72 contains an asterisk (*), the active range for resolution is columns 1 through 71 (to support continuation lines).

Multiple AutoEdit variables (and constants) can be joined together into a complex term. When a term contains multiple variables, those variables are resolved from right to left.

The methods of joining multiple variables together are described below.

• Two variables can be joined to form a single complex variable by linking them together (such as %%A%%B).

  Given:	%%A=1, %%B=2, %%A2=100
  Resolve:	%%A%%B
  Explanation:	The process of resolution is as follows:
  	Initial expression to resolve	%%A%%B
  	Resolve %%B	2
  	Replace %%B with value 2	%%A2
  	(%%A%%B partially resolves to a single variable %%A2)
  	Resolve %%A2	100
  Solution:	%%A%%B resolves to 100

  Given:	The day is the 3rd of the month.
  Resolve:	//SYSBKP DD UNIT=TAPE,VOL=SER=%%BACKUP_TAPE_%%ODAY,
  Solution:	This statement partially resolves to:
  	//SYSBKP DD UNIT=TAPE,VOL=SER=%%BACKUP_TAPE_03,
  	%%BACKUP_TAPE_03 is a single user-defined variable. If the value of this variable is known to Control-M as EE1022, the statement would fully resolve to:
  	//SYSBKP DD UNIT=TAPE,VOL=SER=EE1022,
  	//SYSBKP DD UNIT=TAPE,VOL=SER=%%BACKUP_TAPE_03,

• Two variables can be concatenated into two distinct but joined variables by placing a period between them (such as %%A.%%B).

  Given:	%%A=1, %%B=2, %%A2=100
  Resolve:	%%A.%%B
  Explanation:	The process of resolution is as follows:
  	Initial expression to resolve	%%A.%%B
  	Resolve %%B	2
  	(The partially resolved variable now reads	%%A.2)
  	Resolve %%A	1
  	(The partially resolved variable now reads	1.2)
  	Final resolution of the two values (based on the rule that two variables joined by a period resolve to a concatenated value)	12
  Solution:	%%A.%%B resolves to 12

  On the 4th of December, %%ODAY.%%OMONTH resolves to 0412

  (If the expression had been written %%ODAY%%OMONTH (without the period), it would have partially resolved to %%ODAY12, which is a user-defined variable requiring further resolution.)

• Two variables can be concatenated into two distinct variables joined by a period by placing two periods between them (such as %%A..%%B).

  Given:	%%A=1, %%B=2, %%A2=100
  Resolve:	%%A..%%B
  Explanation:	The process of resolution is similar to the resolution of two variables joined by one period:
  	Initial expression to resolve	%%A..%%B
  	Resolve %%B	2
  	(The partially resolved variable now reads	%%A..2)
  	Resolve %%A	1
  	(The partially resolved variable now reads	1..2)
  	Final resolution of the two values (based on the rule that two variables joined by two periods resolve to two values joined by a period)	1.2
  Solution:	%%A..%%B resolves to 1.2

  On the 4th of December, %%ODAY..%%OMONTH resolves to 04.12

• A constant can be appended to a variable by prefixing the constant with the concatenation symbol %%. or %%.. For example, in expression %%AA%%.UP, constant UP is appended to variable %%AA.

  Without symbol %%., the constant would be treated as part of the variable (for example, expression %%AAUP consists of one variable).

  The %%. or %%.. symbol is not required if the constant precedes the variable (for example, UNIT%%AA) since the %% prefix of the variable differentiates it from the constant.

  Given:	%%MODE = PROD
  Resolve:	CTM.%%MODE%%.01.JCL
  Explanation:	The process of resolution is as follows:
  	Initial expression to resolve	CTM.%%MODE%%.01.JCL
  	Resolve %%MODE	PROD
  	(The partially resolved variable now reads CTM.PROD%%.01.JCL)
  	Final resolution (based on the rule that symbol %%. joins a constant to a variable)	CTM.PROD01.JCL
  Solution:	CTM.%%MODE%%.01.JCL resolves to CTM.PROD01.JCL

  To separate a constant (JCL) from a variable (%%MODE) by a period, specifying the period is sufficient. For example: CTM.%%MODE.JCL would resolve to CTM.PROD.JCL.

Order of Precedence for Multiple Value Assignments

If a particular AutoEdit variable can receive a value from more than one source, an order of precedence is necessary to determine which of the possible values is assigned.

The following chart indicates the order of precedence. The chart works as follows:

• Each row in the chart represents a possible source of a value for a variable.

• In each column, a single pair of value sources (rows) are selected and compared for precedence:

  • The source that takes precedence in the pair is identified by label P.

  • The other source in the pair is identified by label O.

When many sources of value assignments are available for a variable, use the chart below to compare those sources one pair at a time, as follows:

• From the list of available sources for the particular variable, select any two sources and use the chart to eliminate the source of lower priority. The list now has one less source available.

• Repeat this process until only the source of highest priority remains.

Table 256 Chart for Determining Priorities of Value Assignment Sources

If there are multiple value assignments for the same variable in the one member, the last assignment in that member is used for the above calculation.

Control Statements

Control statements define the AutoEdit environment and control AutoEdit processing.

Control statements can appear anywhere in the JCL member to be submitted. When a control statement is detected in a JCL line (for example, in a JCL remark statement), the line containing the control statement is submitted as part of the job. If the control statement appears in a non-JCL line (for example, a line beginning without a // symbol), the control statement is resolved and the resolved value can be applied to subsequent JCL lines, but the control statement is not submitted as part of the job.

Available control statements are discussed on the following pages.

%%GLOBAL

Control statement %%GLOBAL defines a member that contains a set of user-defined variables or AutoEdit functions, along with their values. Before job submission, the Control-M monitor reads this member from the library referenced by DD statement DAGLOBAL in the Control-M procedure. The content of the member is added to the user-defined variable environment of the job.

You can specify more than one %%GLOBAL statement for a job. Each statement is added to the user-defined variable environment of the job.

Global members can also be placed in cache, which can significantly improve performance if the member is used by many jobs. For more information, see Loading Members to Cache, and the corresponding topic in the INCONTROL for z/OS Administrator Guide.

If Control-M fails to access the variable member (member not found, and so on), the job is not submitted and a warning message is issued to the user who requested the job.

The format of the %%GLOBAL control statement is:

//* %%GLOBAL memname

where memname is a valid member name of 1 through 8 characters.

//* %%GLOBAL TAPES
//* %%GLOBAL CURRENCY

%%GOTO and %%LABEL

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

The format of %%GOTO and %%LABEL statements is:

%%GOTO labelname
%%LABEL labelname

The %%GOTO statement transfers control to the location in the program designated by a matching %%LABEL statement. The search for a matching %%LABEL labelname is only performed downward (that is, loops are not supported).

Ordinarily, statements between a %%GOTO statement and its matching %%LABEL statement are not processed (that is, no statements are submitted and AutoEdit statements are not resolved). The one exception is %%IF, %%ELSE, and %%ENDIF control statements that are commented (that is, begin with //*), which are submitted but not resolved, in order to clarify the flow of conditions in the generated JCL.

The AutoEdit facility performs a validity check on %%GOTO and %%LABEL control statement pairs in JCL members. If an active %%GOTO control statement is detected without its corresponding %%LABEL control statement, an warning message is issued.

Using the AutoEdit facility, several %%GOTO statements in one JCL member can be combined, so that a number of jobs defined in the member can be combined into one job, which can be submitted by Control-M.

%%GOTO and %%LABEL statements are generally used in conjunction with %%IF, %%ELSE, and %%ENDIF control statements. Examples at the end of this chapter demonstrate how these statements can be combined.

%%IF, %%ELSE, %%ENDIF

%%IF, %%ELSE, and %%ENDIF control statements provide the AutoEdit facility with Boolean "IF" logic capability. These statements, in conjunction with %%GOTO and %%LABEL control statements, permit branching based on submission time criteria. Job steps, DD statements, and so on are easily excluded or included.

The format of %%IF, %%ELSE, %%ENDIF statements is:

%%IF conditional-expression
statements
[%%ELSE]
statements
%%ENDIF

where:

• conditional-expression is the condition that determines whether the accompanying statements are performed. If the condition is satisfied, the statements accompanying the %%IF statement are performed and the statements accompanying the %%ELSE statement (if specified) are not performed. If the condition is not satisfied, the statements accompanying the %%ELSE statement (if specified) are performed and the statements accompanying the %%IF statement are not performed.

  The format of a conditional-expression is:
  operand operator operand

  where:

  • operand – Any character string. It can contain AutoEdit terms.

  • operator – One of the valid comparison operators listed below.

    • Operators for comparison with single values:

      Operator		Short Description
      String Comparison	Numeric Comparison
      EQ	EQ#	is equal to
      NE	NE#	is not equal to
      GT	GT#	is greater than
      GE	GE#	is greater than or equal to
      LT	LT#	is less than
      LE	LE#	is less than or equal to

    • Operators for comparison with multiple values:

      Operator		Short Description	Example with Syntax
      String Comparison	Numeric Comparison
      IL	IL#	is in list	%%IF %%DS IL (MON,TUE,WED,THU) %%IF %%Var IL# (Num1,Num2,...Num_n)
      IR	IR#	is in range	%%IF %%Var IR# (%%Min,%%Max)
      NR	NR#	is not in range	%%IF %%Var NR# (%%Min,%%Max)

  Operators that end with the pound sign (#) are used for numerical comparisons, while operators without the pound sign (#) are used for string comparisons.

  In string comparisons, operands are compared as character strings from left to right.

  In numeric comparisons, the operands must represent valid arithmetic values.

  When numeric operators are used, the following requirements apply to the operands:

  1. Arithmetic values can have leading signs (+ or -). For example: "+12", "-00034".

  2. Arithmetic values can contain decimal points. For example: "1.5", "+2.25", "-3.01".

  3. Leading zeros and blanks are ignored. A leading sign, if specified, must precede any leading zeros. For example: "+0001" but not "000+1.

  4. The following maximum length limitations apply: 39 digits before a decimal point and 40 digits after a decimal point.

  Table 257 Examples of Conditional-Expressions

  Statement	Truth Value
  %%IF  01 EQ# 1	TRUE
  %%IF  01 EQ 1	FALSE
  %%IF  91 GT 1000	TRUE
  %%IF  91 GT#  1000	FALSE
  %%IF  91 GT#  10.00	TRUE
  %%IF  1000 GT# 91	TRUE
  %%IF  -91 GT#  -1000	TRUE
  %%IF  91  GT#  ABC	Syntax error

• statements are any statements specified in the JCL member, including AutoEdit statements, JCL statements and non-JCL statements.

If an operand contains AutoEdit terms, they are resolved into a character string before the conditional expression is analyzed.

An operand must not resolve to a null value (as in CLISTs). If it is possible that an operand resolves to a null value, place a character before the first and second operands in a way that would not affect the comparison. For example, if %%A and/or %%C in the statement:

%%IF %%A GT %%C

might resolve to null, use a substitute expression such as:

%%IF B%%A GT B%%C

An %%IF expression must be terminated with an %%ENDIF statement. If an %%IF expression is not terminated in this way, an %%ENDIF statement is implied as the last statement in the member.

The %%ELSE statement is optional.

The AutoEdit facility performs a validity check on %%IF and %%ENDIF control statement pairs in JCL members. If a %%IF control statement is detected, which is not closed by %%ENDIF control statement, it will be automatically closed at end of member and a warning message is issued.

When the %%IF expression is true, all JCL statements (including non-AutoEdit statements) between the %%IF expression and its %%ELSE statement (or its matching %%ENDIF statement when no %%ELSE statement is present) are submitted by Control-M provided that all AutoEdit variables are resolved.

When the %%IF expression is not true and an %%ELSE statement exists, only statements between the %%ELSE statement and the matching %%ENDIF statement are submitted.

Using the AutoEdit facility, several %%IF statements in one JCL member can be combined, so that a number of jobs defined in the member can be combined into one job, which can be submitted by Control-M.

%%IF statements can be nested.

The following logically connected statements may be specified on one line:

• %%IF

• %%ELSE

• %%ENDIF

• %%GOTO

• %%SET, %%SETB

%%IF expression 
 %%IF expression
       statements
       .
       [ %%ELSE ]
       .
 %%ENDIF
%%ELSE
 %%IF expression
       statements
       .
       [ %%ELSE ]
       .
 %%ENDIF
%%ENDIF

Up to 100 nested %%IF statements can be specified.

%%INCLIB and %%INCMEM

%%INCLIB and %%INCMEM statements contain two elements that together describe the member that is to be included in the current job stream, as follows:

• The %%INCLIB part of the statement defines the location of the member as one of the following:

  • the library name

  • the DDname to be associated with a library or concatenation of libraries

• The %%INCMEM part of the statement defines the member.

These statements are useful for inserting the following types of information into the JCL:

• JCL statements and parameters to be passed to the JCL (for example, sysin)

• AutoEdit control statements, including other %%INCLIB and %%INCMEM statements

The format of the statement is:

%%INCLIB { libname | DDNAME=ddname } %%INCMEM memname

In this statement

• libname is a valid data set name, from 1 through 44 characters in length, of a cataloged partitioned data set (library) with a record length of 80

• ddname is a valid DDname from1 through8 characters in length that points to a cataloged library or concatenation of cataloged libraries
  This DDname must be preallocated to the environment in which the %%INCLIB statement is to be resolved, such as the Control-M monitor or the IOA online logon procedures.

• memname is a valid member name from 1 through 8 characters in length

You can specify multiple %%INCLIB and %%INCMEM statements in a job.

More than one job may contain identical %%INCLIB and %%INCMEM statements, permitting maintenance of common, standardized code.

The %%INCMEM member is read by the Control-M monitor just before job submission, and the contents of the member are submitted as part of the current job. As a result

• a member created by one job in the job stream can be used by a later job in the job stream

• if a job in the job stream updates a member and the member is subsequently used by a later job in the job stream, the later job accesses the updated member

If the %%INCLIB statement is resolved within the JCL, ensure that there are no unnecessary blank lines in the %%INCMEM member.

If Control-M fails to access the included member (member not found, and so on), the job is not submitted and a warning message is issued.

%%LIBSYM and %%MEMSYM

Control statements %%LIBSYM and %%MEMSYM define a library and a member that contain a set of user-defined variables or AutoEdit functions, along with their assigned values. The member is read by Control-M before submission, and its content is added to the user-defined variable environment of the job.

It is possible to specify more than one %%LIBSYM or %%MEMSYM statement for one job. Each statement is added to or deleted from the user-defined variable environment of the specific job.

If Control-M fails to access the variable member (member not found, security constraints, and so on), the job is not submitted and a warning message is issued to the user who requested the job.

The format of the statement is:

%%LIBSYM libname %%MEMSYM [-]memname

where:

• libname – Valid data set name of 1 through 44 characters. It must be a cataloged partitioned data set (library) with a record length of 80.

• memname – Valid member name of 1 through 8 characters.

When a minus sign (-) is specified before memname, the purpose of the %%LIBSYM/%%MEMSYM statement is to cancel the effect of the previously processed %%LIBSYM libname %%MEMSYM memname statement with the same member name, thereby reverting the values of the AutoEdit variables that are defined in the LIBSYM/MEMSYM member to the values that were in effect prior to the previous %%LIBSYM libname %%MEMSYM memname statement. This, in effect, provides the capability of creating local auto-edit variables, whose scope is restricted to specified range(s) of the job run stream.

%%RANGE

A %%RANGE statement limits the handling of AutoEdit functions and variables to a specified column range. The contents of all columns outside the range remain unchanged.

This statement is useful when values must be specified in specific columns and when not every AutoEdit statement need be resolved.

The format of the statement is:

%%RANGE fromcol tocol

where:

• fromcol – First column in the range. Valid values are: 1 through 80. The default (without a range statement) is1.

• tocol – Last column in the range. Valid values are: 1 through 80. tocol must be a value equal to or greater than fromcol.
  The default (without a %%RANGE statement) depends on the following:

  • If the statement being processed is a JCL statement, that is, columns 1-2 contain '//', then the default depends on the setting of optional wish M10042 (see member IOADFLT in the IOA IOAENV library). The default value for wish M10042 is 72.

  • If the statement being processed is a non-JCL data statement, that is, columns 1-2 do not contain '//', then the default value is 80.

The %%RANGE statement can prevent the shifting of constants and variables that appear after an AutoEdit variable in the same line. By limiting AutoEdit resolution to a specified range, all constants and variables outside the specified range are kept in their original positions regardless of the length of the resolved variables.

Each %%RANGE statement is valid until a new %%RANGE statement is specified. Note, however, that the placement of the subsequent %%RANGE statement must be within the column range of the preceding %%RANGE statement (or it is not recognized as an AutoEdit statement).

//* %%SET %%A_VERY_LONG_VARIABLE=XXX
%%A_VERY_LONG_VARIABLE    CONSTANT
//* %%RANGE 1 25
%%A_VERY_LONG_VARIABLE    CONSTANT

//* %%SET %%A_VERY_LONG_VARIABLE=XXX
XXX    CONSTANT
//* %%RANGE 1 25
XXX                         CONSTANT

%%RESOLVE

By default, Control-M must resolve all AutoEdit terms in the JCL or the job is not submitted. This default can be overridden by specifying an appropriate %%RESOLVE statement in the JCL.

Valid %%RESOLVE statements are:

Table 258 %%RESOLVE Statements

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

%%SETB

A %%SETB control statement sets the values of user-defined variables and supports variable values that contain blanks. The statement may be placed in any part of the JCL stream.

The format of the %%SETB statement is:

%%SETB %%varname='expression'

where:

• varname – a valid user-defined variable

• expression – must resolve to a value according to the rules described in Rules of Variable Resolution or submission of the job is canceled (unless a %%RESOLVE NO control statement is specified). The expression must be enclosed in single quotes, and it can contain blanks and special characters (including single quotes). The expression can consist of a:

  • value (for example, 5)

  • variable (for example, %%ODATE)

  • combination of values and variables

To use this variable assignment in the %%LIBSYM and %%MEMSYM members, or in the %%GLOBAL or CACHLST members, use the following format:

%%varname:'expression'

For more information about these variable members, see Format of Variable Members and Example 3 below.

//* %%SETB %%L1='DATE: %%DAY/%%MONTH/%%YEAR , TIME:%%TIMEF     '
//* %%SETB %%L2='CONTROL-M: JOB %%JOBNAME RUN %%RN             '
//* %%SETB %%L3='           APPLICATION: %%APPL, TABLE: %%GROUP'
. . . . . . . . . . . .
//* %%L1
//* %%L2
//* %%L3

//* DATE: 30/10/22 , TIME:13:41:25
//* CONTROL-M: JOB M29JOB3 RUN 00001
//*            APPLICATION: APP1, TABLE: TAB1

//* %%SETB %%LIB= '%%$SCHDLIB'
//* %%SET  %%LIB=  %%SUBSTR %%LIB 1 44
//*
//* %%SETB %%TAB= '%%$SCHDTAB'                           
//* %%SET  %%TAB=  %%SUBSTR %%TAB 1 8
//*
//* LIBRARY: %%LIB TABLE:%%TAB

LIBRARY: CTM.TEST.SCHEDULE                            TABLE:M29TST
LIBRARY: M29.SCHEDULE                                 TABLE:M29JOB1
LIBRARY: IOAA.ENV#R1.SCHEDULE                         TABLE:M29MAIN

%%H1:'SUNDAY    '
%%H2:'MONDAY    '
%%H3:'TUESDAY   '
%%H4:'WEDNESDAY '
%%H5:'THURSDAY  '
%%H6:'FRIDAY    '
%%H0:'SATURDAY  '

%%H%%OWDAY%%.%%TIME
%%H%%OWDAY.085300
%%H1.085300
SUNDAY    085300

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM DAYTIME
....
//STEP02 EXEC PDPRT3
//SYSIN DD *
SUNDAY    085300
//

%%SET

A %%SET control statement sets the values of user-defined variables. The statement may be placed in any part of the JCL stream.

The format of the statement is:

%%SET %%varname=expression

where:

• varname – a valid user-defined variable

• expression – must resolve to a value according to the rules described in Rules of Variable Resolution or submission of the job is canceled (unless a %%RESOLVE NO control statement is specified). An expression can consist of a:

  • value (for example, 5)

  • variable (for example, %%ODATE)

  • combination of values, variables, operators, functions, and so on (for example, %%GENERATION_NUMBER %%PLUS 1).

  The expression must not contain blanks.

%%SET %%BACKUP_UNIT=TAPE

%%SET %%BACKUP_UNIT_%%WDAY=EE%%OMONTH.%%ODAY

//* %%SET %%SCRATCH=%%SCRATCH %%PLUS 1
//SYSUT1 DD UNIT=TAPE,VOL=SER=EE%%SCRATCH,DISP=...

//* %%SET %%SCRATCH=3017 %%PLUS 1
//SYSUT1 DD UNIT=TAPE,VOL=SER=EE3018,DISP=...

Operators

AutoEdit operators are used to add or subtract values from AutoEdit variables in the JCL. These operators can only be specified in a %%SET statement. Valid AutoEdit operators are:

Table 259 AutoEdit Operators

AutoEdit operators are generally used as follows:

%%SET variable=operand operator operand

where:

• operand – Expression that resolves to a numeric value.

• operator – %%PLUS or %%MINUS.

Only one operator can be specified in each %%SET statement.

// %%SET %%GENERATION_NUMBER=%%GENERATION_NUMBER %%PLUS 1

Functions

AutoEdit functions perform operations on specified AutoEdit variables in the JCL. These functions can only be specified in %%SET statements. The following AutoEdit functions are supported by Control-M:

%%$CALCDTE

The %%$CALCDTE function performs date manipulation by adding or subtracting a specified number of days from a specified date.

The format of the %%$CALCDTE function is:

%%$CALCDTE date ± [quantity_type]quantity

where:

• date – must be (or resolve to) a date in format yyyymmdd

• quantity_type – optional 1-character description of the type of data specified as quantity

Valid values are:

• D – days

• M – months

• Y – years

• If no value is specified, the default value is D (days).

• quantity – number (or numeric AutoEdit expression) of date units, depending on the value specified for quantity_type to add to or subtract from the date
  Valid values are: 1 through 999.

//* %%SET %%A=%%$CALCDTE %%$ODATE -1

//* %%SET %%A=%%$CALCDTE %%$ODATE +M1

//* %%SET %%A=%%$CALCDTE %%$ODATE +Y1

%%$GREG

The %%$GREG function converts a Julian date (with a 4-character year) to a Gregorian date (with a 4-character year). The format of function %%$GREG is:

%%$GREG date

where date must be (or resolve to) a date in Julian format yyyyddd.

//* %%SET %%A=%%$GREG 2001196

%%$JULIAN

The %%$JULIAN function converts a Gregorian date (with a 4-character year) to a Julian date (with a 4-character year). The format of the %%$JULIAN function is:

%%$JULIAN date

where date must be (or resolve to) a date in format yyyymmdd.

//* %%SET %%A=%%$JULIAN 20010717

%%$LEAP

The %%$LEAP function determines whether a specified Gregorian date (with a 4-character year) falls in a leap year. If the date is in a leap year, the variable resolves to 1. If the date is not in a leap year, the variable resolves to 0. The format of the %%$LEAP function is:

%%$LEAP date

where date must be (or resolve to) a date in format yyyymmdd.

Leap years are years whose last two digits are evenly divisible by 4, excluding those years that are divisible by 100 but not by 400. Therefore, 2000 is a leap year but the years 2100, 2200 and 2300 are not.

//* %%SET %%A=%%$LEAP %%$ODATE

%%$WCALC

The %%$WCALC function performs a shift from the specified date to a working date in the specified calendar, according to indicated instructions. The format of the %%$WCALC function is:

%%$WCALC date instruction calendar

where:

• date – must be (or resolve to) a date in format yyyymmdd

• instruction – shift instructions.

  Valid values are:

  • +n – Shift to the next nth working date in the calendar.

  • –n – Shift to the previous nth working date in the calendar.

  • > – If the specified date is not a current working date, shift to the next working date in the calendar. (If the specified date is a working date, do not shift.)

  • < – If the specified date is not a current working date, shift to the previous working date in the calendar. (If the specified date is a working date, do not shift.)

• calendar – name of the calendar to check for working dates

//* %%SET %%A=%%$WCALC 20000717 +1 EXCPTCAL
//* %%SET %%A=%%$WCALC 20000717 > EXCPTCAL

%%$WEEK#

The %%$WEEK# function calculates in which week of the year (1 through 54) a specified date falls. The function uses the site-defined start of the week (Sunday or Monday) as the first day of each week, and assumes that January 1st falls in the first week.

This function ensures that every day of the year falls into a week of that year, but it also means that the first week of the year may possibly have a majority of its days come from December of the preceding year.

(By contrast, the %%$YEARWK# AutoEdit function, which also calculates in which week of a year a date falls, counts the week that includes January 4th as the first week. This ensures that the first week in the year has a majority of its days in January. However, it also means that the first days of the year may possibly belong to the last week of the preceding year, and the last days of the year may possibly belong to the first week of the following year.)

The format of the %%$WEEK# function is:

%%$WEEK# date

where date is the date in format yyyymmdd (a 4-character year must be specified).

//* %%SET %%A=%%$WEEK# 20010712

%%$WEEKDAY

The %%$WEEKDAY function calculates on which day of the week a specified date (with a 4-character year) falls. The resolved value is an integer from 1 through 6 or 0, where 1 corresponds to the first day of the week (Sunday or Monday, depending on the site-standard) and 0 corresponds to the last day of the week (Saturday or Sunday).

The format of the %%$WEEKDAY function is:

%%$WEEKDAY date

where date must be (or resolve to) a date in format yyyymmdd.

//* %%SET %%A=%%$WEEKDAY 20000714

%%$YEARWK#

The %%$YEARWK# function calculates in which week of the year (1 through 53) a specified date falls, and returns the year and the week number according to ISO8601 standards. In accordance with those standards, the function uses Monday as the first day of each week (this is so even if the start of the week at your site is defined as Sunday).

The %%$YEARWK# function assumes that the first week is the week that includes January 4th

This function ensures that the first week in the year has a majority of its days in January. However, it also means that the first days of the year may possibly belong to the last week of the preceding year, and the last days of the year may possibly belong to the first week of the following year.

By contrast, the %%$WEEK# AutoEdit function, which also calculates in which week of a year a date falls, counts the week that includes January 1st as the first week. This ensures that every day of the year is part of a week of that year. However, it also means that the first week of the year may possibly have a majority of its days in December of the preceding year.

The format of the %%$YEARWK# function is:

%%$YEARWK# date

where date is the date in format yyyymmdd (a 4-character year must be specified).

The value returned by the function is in the format:

yyyyWnn

where:

• yyyy – year in which the week falls

• nn – number of the week within the year

//* %%SET %%A=%%$YEARWK# 20010214

//* %%SET %%A=%%$YEARWK# 20050101

//* %%SET %%A=%%$YEARWK# 20011231

%%CALCDATE

The %%CALCDATE function performs date manipulation by adding or subtracting a specified number of days from a specified date.

The format of the %%CALCDATE function is:

%%CALCDATE date ± quantity

where:

• date – must be (or resolve to) a date in format yymmdd

• quantity – number (or numeric AutoEdit expression) of days (from 1 to 366) to add to or subtract from the date

%%SUBSTR

The %%SUBSTR function extracts a substring from a string.

The format of the %%SUBSTR function is

%%SUBSTR string startpos length

where

• string – string from which the substring is extracted

• startpos – character position in the original string from which the extraction begins

• length – number of characters to extract

A new string is created composed of the characters extracted from the original string.

startpos and length must be a numeric value or AutoEdit expression that is greater than zero.

When the starting position of the substring is greater than the argument string, the function returns a null value.

When the starting position of the substring falls within the argument string, but the length of the substring falls outside the range of the argument string (startpos + length – 1), the function returns a substring containing the characters from the starting position.

If the character positions of startpos + length – 1 is greater than the string length, submission of the member is stopped.

//* %%SET %%A=%%$CALCDTE %%$ODATE -1
//* %%SET %%AMON=%%SUBSTR %%A 5 2

%%SET %%A=%%SUBSTR CABLE 4 4

%%$LENGTH

The %%$LENGTH function returns the length of a character string.

The format of the %%$LENGTH function is

%%$LENGTH char_string

where char_string is, or resolves to, any character string.

//* %%SET %%A=%%$LENGTH A123

%%$TYPE

The %%$TYPE function returns the type attribute of a character string. Possible type attributes are:

• N – numeric

• M – negative numeric

• C – character

• X – alphanumeric

• 0 – undefined or 0 length

The format of the %%$TYPE function is

%%$TYPE char_string

where char_string is, or resolves to, any character string.

//* %%SET %%A=%%$TYPE A123

//* %%SET %%B=%%$TYPE XYZ

//* %%SET %%C=%%$TYPE -1239

%%$FUNC

%%$FUNC is an AutoEdit function that enables the creation of user-defined functions. You can only use the %%$FUNC function as part of an AutoEdit %%SET statement.

The syntax for such use of the %%$FUNC function is

%%SET output_char_string = %%$FUNC func_name input_char_string

In its operation, it is equivalent to using assembler language to issue the following CALL instruction

CALL func_name,(input_char_string,output_char_string)

In this instruction

• func_name is the name of the user-coded program module

• input_char_string is a string consisting of two parts in the following order:

  • the length of the source string

  • the source string

• output_char_string is a string consisting of two parts in the following order:

  • the length of the result string

  • the result string returned by func_name

The AutoEdit processor passes these parameters as variable-length strings. Each string consists of a half-word binary length field followed by the string itself. The func_name program must return the output string in the same format, as illustrated in the example below.

The source string can contain AutoEdit variables. If it does, these variables are resolved before the function is activated.

The maximum length of the source string, after resolving any AutoEdit variables, is 240 characters.

The maximum length of the result string is also 240 characters.

Neither the source string nor the result string can contain non-displayable characters.

You can use AutoEdit simulation to test your program module. For more information, see M2: Perform an AutoEdit Simulation.

• It must be able to work in AMODE31.

• It must be reentrant.

• To define program modules as resident, include them in the cache members list using the following definition syntax: %%$FUNC func_name[

%%SET %%A = 20
%%SET %%B = 30
%%SET %%C = %%$FUNC MULT %%A %%B

CALL MULT,(PRM1,PRM2)

PRM1 DC H'5'
      DC C'20 30'
PRM2 DC H'0'
     DC CL240' '

PRM2 DC H'3'
     DC C'600'

Testing AutoEdit Syntax

When Control-M detects an AutoEdit syntax error in a JCL member during submission, the submission is canceled by Control-M. Therefore, it is essential to check the syntax of AutoEdit statements while the member is being prepared.

Furthermore, when the syntax is correct, you may want to verify that the AutoEdit statements return the desired results. For example, you may want to check that you specified the correct AutoEdit date variables for a job that performs end-of-year processing.

The CTMAESIM utility tests AutoEdit syntax and JCL setup. This utility simulates the actions of the Control-M submission mechanism, which performs AutoEdit processing and JCL setup, and produces a printed report of the process.

Control-M has a customized interface with the JOB/SCAN and PRO/JCL products. However, this utility can be used with any JCL-checking product.

The CTMAESIM utility can operate in either JCL Library mode or Scheduling Library mode:

• In JCL Library mode, the utility checks the AutoEdit statements in the job’s JCL.

• In Scheduling Library mode, the utility not only checks the AutoEdit statements in the job’s JCL of the job, it also checks the impact that SET VAR statements in the job scheduling definition have on the JCL of the job.

The utility enables system programmers to check the operation of Control-M submission exit CTMX002 without affecting production.

The CTMAESIM utility can be activated by a batch procedure or the Online facility, as follows:

• Batch procedure – using procedure CTMAESIM

• Online facility – using option M2 in the Online Utilities menu or using CLIST CTMCAES

The utility requires specification of various parameter statements that determine how the simulation works, and which provide necessary information for the simulation.

Although the simulation works in much the same manner whether activated by a batch procedure or online, the following differences depend on the method of activation:

• Batch activation allows specification of multiple sets of parameter statements. Online activation allows specification of only one set of parameter statements.

• Batch activation allows inclusion or omission of parameter RDR=INTRDR (described below). This parameter cannot be specified online.

• Command JSCAN (available only at sites where JOB/SCAN or PRO/JCL is installed) can only be specified if the utility is activated through the Online Utilities menu. It cannot be specified if the utility is activated by batch or by CLIST CTMCAES.

• Character masking is not supported in the Online utility. In the batch utility, character masking is supported for the member name in JCL Library mode, and for the job name in Scheduling Library mode. Valid mask characters are:

  • * – Represents any number of characters (including no characters)

  • ? – Represents any one character

• The SET VAR parameter, which can be specified outside the job scheduling definition, is supported in batch mode only. However, SET VAR statements in the job scheduling definition can be checked in both online and batch mode.

• The Control-M GLOBAL LIBRARY parameter is specified only in the Online utility, and only one library can be specified. In batch mode, global libraries are referenced by the DAGLOBAL DDstatement (multiple libraries can be concatenated).

In addition, depending on the command type specified in a parameter statement, the resulting JCL lines can also be written to the output file referenced by the DASUBMIT DD statement.

When the JCL is written to the output file referenced by the DASUBMIT DD statement, the output file can be routed to an internal reader by specifying the parameter RDR=INTRDR in the EXEC statement. In this case, the DASUBMIT DD statement is allocated as SYSOUT=(class,INTRDR) and the job is submitted.

Submission of the job enables the JCL to be checked by the JCL checking mechanism of MVS.

When activated using ISPF, the functioning of the utility is similar to its functioning when activated from batch with the parameter RDR=INTRDR specified.

The CTMAESIM utility, as activated from the Online facility, is described in Online Facilities. The CTMAESIM utility, as activated through a batch procedure, is described in the INCONTROL for z/OS Utilities Guide.

AutoEdit Usage in the Job Scheduling Definition

Certain AutoEdit components can be used in job scheduling definitions. In job scheduling definitions, AutoEdit components in certain statements (SET VAR and DO SET) directly affect JCL. In other statements (SYSOUT and DO SYSOUT, SHOUT and DO SHOUT, MEMLIB and OVERLIB) they do not affect the JCL.

WARNING: When using AutoEdit variables in job scheduling definitions, always test the definitions for proper AutoEdit syntax with the AutoEdit simulation utility. For more information, see Testing AutoEdit Syntax.

In the job scheduling definition, AutoEdit components can be specified in the following parameters:

• SET VAR and DO SET statements

  These two job scheduling definition statements and the %%SET control statements are used to assign values to user-defined variables in the JCL and in Control-M job definition post-processing parameters (for example, in the SHOUT message text). In a SET VAR statement, you can also include AutoEdit functions.

  In this example, AutoEdit statements in the job scheduling definition and the JCL allocate space for the job. If the job abends due to insufficient space, the AutoEdit statements adjust the allocated space and rerun or restart the job.

  The following step in the job’s JCL sets the quantity of available space to five units of whatever type (track or cylinder) is specified in the job scheduling definition.

  Copy

  //STEP10 EXEC PGM=MYPGM
  //OUTFILE  DD DSN=NEWFILE,DISP=(NEW,CATLG,DELETE),
  //                 SPACE=(%%SPACE_TYPE,5),UNIT=SYSDA

  The job scheduling definition contains the following SET VAR statement that sets the space type to "track":

  Copy

  SET VAR  %%SPACE_TYPE=TRK

  In this case, the second line in the above DDstatement resolves to:

  Copy

  //                 SPACE=(TRK,5),UNIT=SYSDA

  The job scheduling definition also contains the following statements that are activated if the job abends due of lack of space (code S*37). These statements change the space type to "cylinder", which provides enough space, and rerun the job. If Control-M/Restart is active, the job is restarted from the abended step.

  Copy

  ON STEP STEP10 CODES S*37
  DO SET %%SPACE_TYPE=CYL
  [DO IFRERUN   FROM $ABEND] ===> If Control-M/Restart is active
  DO RERUN

  If the job abends as above, the second line of the earlier JCL DDstatement resolves to:

  Copy

  //                  SPACE=(CYL,5),UNIT=SYSDA

  when the job is submitted for rerun (or restart).

  To demonstrate the use of an AutoEdit function in a SET VAR statement, the following routine extracts 5 characters from a string, beginning at column 2, using an AutoEdit function:

  Copy

  SET VAR %%VAR=%%SUBSTR %%DATE 5 2

• SYSOUT and DO SYSOUT

  File names for SYSOUT and DO SYSOUT handling can be specified using AutoEdit variables whenever SYSOUT option F (copy to file or sysout archiving) is specified. For example:

  Copy

  SYSOUT OP F PRM GPL.%%JOBNAME.D%%ODATE.%%JOBID.T%%TIME

• SHOUT, DO SHOUT, and DO MAIL

  System AutoEdit variables and variables defined in the Control-M SET VAR or DO SET job definition parameters can be used in shouted messages. For example:

  Copy

  MSG  JCL ERROR IN JOB %%JOBID %%STEP

• MEMLIB and OVERLIB

  System AutoEdit variables and variables defined in SET VAR parameters can be used in the MEMLIB and OVERLIB fields to specify the appropriate library. Examples of this usage are shown on the following pages.

• IN, OUT, and DO COND

  You can use an AutoEdit variable in a condition name, provided that the AutoEdit variable has a value that is known before the job is ordered (for example, a system auto-edit variable). That same value will be used in the condition name regardless of whether the condition name is used in a run-time parameter (IN parameter) or in a post-processing parameter (OUT or DO COND parameters) to ensure that the relationship between the IN and OUT condition names are synchronized.

  Note that as far as AutoEdit variables in condition name parameters are concerned, the values of SET VAR or DO SET parameters in the job definition are not resolved. Likewise, AutoEdit variables defined in a SMART table entity are not resolved in any of the SMART table job definition condition names.

Examples for JCL Setup and AutoEdit

Date Variables

Table 260 Date Variables

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A//STEP01 EXEC PDUPDATE
//SYSIN DD *
%%DATE
//

The JCL submitted on June 6, 2001:

//PDPA0001 JOB (......),BILL,CLASS=A//STEP01 EXEC PDUPDATE
//SYSIN DD *
010606
//

ODATE, RDATE and DATE Usage

//PDPA0001 JOB (......),BILL,CLASS=A
//STEP01 EXEC PDUPDATE
//SYSIN DD *
010606
//

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A
....
//STEP02   EXEC PDPRINT,BUSDATE=%%ODATE
//SYSIN    DD   *
EXAMPLE-RDATE=%%RDATE
EXAMPLE-DATE=%%DATE
//

On July 24th, we need to run the 22nd, 23rd, and 24th (of the same job) because of delays. On the Active Jobs file we can find three job orders:

PDPA0001 of 010722
PDPA0001 of 010723
PDPA0001 of 010724

The job of the 22nd is submitted on July 24th at 2300. The result is:

//PDPA0001 JOB (......),BILL,CLASS=A
....//STEP02   EXEC PDPRINT,BUSDATE=010722
//SYSIN    DD   *
EXAMPLE-RDATE=010724
EXAMPLE-DATE=010724
//

The job of the 23rd is submitted on July 25th at 0025. The result is:

//PDPA0001 JOB (......),BILL,CLASS=A
....
//STEP02   EXEC PDPRINT,BUSDATE=000723
//SYSIN    DD   *
EXAMPLE-RDATE=010724
EXAMPLE-DATE=010725
//

The job of the 24th is submitted on July 25th, 2001 at 0300. The result is:

//PDPA0001 JOB (......),BILL,CLASS=A
....//STEP02   EXEC PDPRINT,BUSDATE=000724
//SYSIN    DD   *
EXAMPLE-RDATE=010724
EXAMPLE-DATE=010725
//

How to Obtain Date Formats – 1

Format ddmmyy:

%%ODAY.%%OMONTH.%%OYEAR

Let’s follow the variable substitution by stages for June 24, 2001:

%%ODAY.%%OMONTH.01
%%ODAY.06.01
%%ODAY.0601
24.0601
240601

Remember Variable substitution is performed from right to left.

A period (.) between two AutoEdit variables is omitted.

How to Obtain Date Formats – 2

Format dd mmm yy (where mmm is the month in character format):

The original JCL:

//PDPA0001 JOB  (......),BILL,CLASS=A
//* %%GLOBAL  CHARMON
//STEP02   EXEC PDPRT3
//SYSIN    DD   *
%%ODAY %%MONTH_IN_CHAR_%%OMONTH %%OYEAR
//

The CHARMON member (in the Control-M Global library) contains:

*
*    MONTHS IN CHAR FORMAT
*
%%MONTH_IN_CHAR_01=JAN
%%MONTH_IN_CHAR_02=FEB
%%MONTH_IN_CHAR_03=MAR
.
.
%%MONTH_IN_CHAR_12=DEC

The symbols substitution by stages:

%%ODAY %%MONTH_IN_CHAR_%%OMONTH 00
%%ODAY %%MONTH_IN_CHAR_06 00
%%ODAY JUN 00
24 JUN 00

The submitted member:

//PDPA0001  JOB  (......),BILL,CLASS=A
//* %%GLOBAL  CHARMON
//STEP02   EXEC PDPRT3
//SYSIN    DD   *
24 JUN 00
//

How to Obtain Date Formats – 3

Format ddmmmyy (where mmm is the month in character format):

According to the preceding example, we might try the following original JCL:

//PDPA0001  JOB  (......),BILL,CLASS=A
//* %%GLOBAL CHARMON
//STEP02   EXEC PDPRT3
//SYSIN    DD   *
%%ODAY.%%MONTH_IN_CHAR_%%OMONTH.%%OYEAR
//

Variable substitution by stages would proceed as follows:

%%ODAY %%MONTH_IN_CHAR_%%OMONTH.00
%%ODAY %%MONTH_IN_CHAR_06.00
%%ODAY %%MONTH_IN_CHAR_0600

However, this results in the following error:

Symbol %%MONTH_IN_CHAR_0600 is not resolved.

This error would not have occurred had we tried the following original JCL:

//PDPA0001  JOB  (......),BILL,CLASS=A
//* %%GLOBAL CHARMON
//* %%SET %%A=%%MONTH_IN_CHAR_%%OMONTH
//STEP02   EXEC PDPRT3
//SYSIN    DD   *%%ODAY.%%A.%%OYEAR
//

How to Obtain the Previous Month’s Last Business Date

//PDPA0001  JOB  (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02   EXEC PDPRT3
//SYSIN    DD   *
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_%%OMONTH.%%OYEAR
//

The LBUSMON member in the CTM.LIB.SYMBOLS library contains:

*
* LAST BUSINESS DATE IN THE PREVIOUS MONTH
*
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0101=001231
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0201=010131
.
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0601=010531
.
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_1201=011130
.
.

Variable substitution by stages (during June 2001):

%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_%%OMONTH.01
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_06.01
%%LAST_BUSINESS_DATE_IN_PREV_MONTH_OF_0601
010531

Automatic Job Order for the Next Day

In many data centers it is necessary to run certain jobs "ahead of time" on a regular basis (such as run today with the business date of tomorrow). The %%$CALCDTE and %%SUBSTR functions can be used to permit automatic scheduling of such jobs on a daily basis by the Control-M monitor. (The output is in mmddyy format.)

//TOMDAILY  JOB  (....),BILL,CLASS=A
//* %%SET %%A=%%$CALCDTE %%$ODATE +1
//* %%SET %%DD=%%SUBSTR %%A   7   2
//* %%SET %%MM=%%SUBSTR %%A   5   2
//* %%SET %%YY=%%SUBSTR %%A   3   2
//STEP01 EXEC  PGM=IKJEFT01,REGION=1000K,DYNAMNBR=30
//SYSPROC DD DISP=SHR,DSN=CONTROL-M-CLIST-LIBRARY
//SYSPRINT DD  SYSOUT=*
//SYSTSPRT DD  SYSOUT=*
//SYSTSIN  DD  *
CTMCJOBS SCHEDLIB(CTM.LIB.SCHEDULE) TABLE(SDP00) -
 ODAT(%%MM.%%DD.%%YY)
//

The %%$CALCDTE and %%SUBSTR AutoEdit functions can be used for any date calculation that is needed in a production environment.

If you want to use the WAIT FOR ODATE option, which is described in Ordering Scheduling Jobs, you can use the WAITODAT(YES) parameter.

CTMCJOBS SCHEDLIB(CTM.LIB.SCHEDULE) TABLE(SDP00) - ODAT(%%M.%%D.%%Y) WAITODAT(YES)

Tape Clearance System: Stage 1

The original JCL:

//PDPA0001  JOB  (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM TAPES
//STEP02   EXEC PDINP3
//S001.INPUT DD VOL=SER=%%FEDERAL_BANK_TAPE
//

The member TAPES in the CTM.LIB.SYMBOLS library contains:

*
* EXTERNAL TAPES LIST
*
%%FEDERAL_BANK_TAPE=045673
%%IRS_TAPE=XXXXX
%%STOCK_EXCHANGE_TAPE=YYYYYY
.
.

The submitted JCL:

//PDPA0001 JOB  (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM TAPES
//STEP02   EXEC PDINP3
//S001.INPUT DD VOL=SER=045673
//

The use of a central member for all external tapes is a very simple management tool. The minute a tape arrives, its number is typed in the member, and the tape is sent to the computer room. There is no need to keep the tapes "at hand" on the schedulers’ table until the job is submitted. The function of receiving tapes can be centralized, controlled, and independent of the production process.

Tape Clearance System: Stage 2

The example provided on the previous page has one basic weakness. It cannot handle delays. If a certain job does not run one day, and on the next day it must be run twice (once for each execution day), there is a danger of overriding the tape number in the control member. To solve this problem, let’s improve our tape clearance system.

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM TAPE%%OMONTH.%%ODAY
//STEP02   EXEC PDINP3
//S001.INPUT DD VOL=SER=%%FEDERAL_BANK_TAPE
//

The TAPE0714 member in the CTM.LIB.SYMBOLS library contains:

:
*
* EXTERNAL TAPES LIST
*
%%FEDERAL_BANK_TAPE=045673
%%IRS_TAPE=XXXXX
%%STOCK_EXCHANGE_TAPE=YYYYYY
.
.

There are other advantages:

• The ability to roll back several dates without losing the dynamic parameters.

• Complete documentation of a tape’s usage.

Use a Control-M job to automatically create a member, TAPEmmdd, for each scheduling date, based on a master copy. For example:

//  EXEC PGM=IEBCOPY
.
//SYSIN DD *
C I=IN, O=OUT
S M=((TAPES,TAPE%%OMONTH.%%ODAY))

Tape Management System

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.TAPES %%MEMSYM PDTAPES
//STEP02   EXEC PDBKP3
//S001.OUTPUT DD VOL=SER=%%PDTAPE_0001_%%OWDAY
//

The PDTAPES member in the CTM.LIB.TAPES library contains:

*
* TAPES OF DP APPLICATION
*
%%PDTAPE_0001_1=045673
%%PDTAPE_0001_2=045683
%%PDTAPE_0001_3=045677
%%PDTAPE_0001_4=043433
%%PDTAPE_0001_5=045543
%%PDTAPE_0001_6=045556
%%PDTAPE_0001_7=045666
*
%%PDTAPE_0010_1=046600

We have created a cycle of seven tapes to be used by this application.

Dynamic Job Name

The required format:

//PDPAddxx JOB (......),BILL,CLASS=A

where dd is the business day of the month, and xx varies according to the job in the application.

The solution:

//PDPA%%ODAY%%.xx JOB (......),BILL,CLASS=A

Controlling the Target Computer by Class

Control-M can dynamically decide to which computer to send a job. The following examples demonstrate the relation between Control-M resource acquisition parameters and local JCL standards implementation.

//* %%GLOBAL CLASSES
//PDPA0001JOB(.....),BILL,CLASS=%%FAST_CLASS_OF_%%$SIGN

The CLASSES member in the Control-M Global library contains:

*
* DEFINITIONS OF CLASSES IN THE COMPUTERS
*
%%FAST_CLASS_OF_1=A
%%FAST_CLASS_OF_2=D
%%FAST_CLASS_OF_3=K
%%SLOW_CLASS_OF_1=W
.
.

Controlling the Target Computer by System Affinity

//* %%GLOBAL SYSAFF
//PDPA0001 JOB (......),BILL,CLASS=A
/*J SYSAFF=%%NAME_OF_COMPUTER_%%$SIGN

The SYSAFF member in the Control-M Global library contains:

*
* NAMES OF THE COMPUTERS
*
%%NAME_OF_COMPUTER_1=SYSA
%%NAME_OF_COMPUTER_2=SYSB
%%NAME_OF_COMPUTER_3=TEST

The submitted JCL (for CPU ID 2):

//* %%GLOBAL SYSAFF
//PDPA0001 JOB (......),BILL,CLASS=A
/*J SYSAFF=SYSB

%%BLANKn Statement

A program expects to receive the day of the week and the time of day as structured input:

• Day of the week in column 1

• Time of day in column 11

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM DAYTIME
....
//STEP02   EXEC PDPRT3
//SYSIN   DD *
%%H%%OWDAY%%.%%TIME
//

The DAYTIME member in the CTM.LIB.SYMBOLS library contains the following AutoEdit user symbols:

%%H1=SUNDAY%%BLANK4
%%H2=MONDAY%%BLANK4
%%H3=TUESDAY%%BLANK3
%%H4=WEDNESDAY%%BLANK1
%%H5=THURSDAY%%BLANK2
%%H6=FRIDAY%%BLANK4
%%H0=SATURDAY%%BLANK2

Variable substitution by stages:

%%H%%OWDAY%%.%%TIME
%%H%%OWDAY.085300
%%H1.085300
SUNDAY    085300

The submitted JCL:

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM DAYTIME
....
//STEP02   EXEC PDPRT3
//SYSIN   DD *SUNDAY     085300
//

%%RANGE Statement

The original JCL:

//PDPA0001 JOB  (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02   EXEC PDPRT3
//*           +      +       +        +
//SYSIN    DD *
%%LAST_BUSINESS_DATE_IN_%%OMONTH      REPORT1
//

The constant REPORT must be in column 40.

The submitted JCL:

//PDPA0001 JOB (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02    EXEC PDPRT3
//*            +      +      +        +
//SYSIN     DD *
030400      REPORT1
//

The correct solution:

//PDPA0001 JOB  (......),BILL,CLASS=A
//* %%LIBSYM CTM.LIB.SYMBOLS %%MEMSYM LBUSMON
//STEP02    EXEC PDPRT3
//*            +      +      +        +
//* %%RANGE 1 39
//SYSIN     DD *
%%LAST_BUSINESS_DATE_IN_%%OMONTH     REPORT1
//

SYSIN Parameter Containing %%

Disabling AutoEdit Resolution

The original JCL:

//PDPA0001 JOB  (......),BILL,CLASS=A
//STEP02    EXEC PDPRT3
//SYSIN     DD   * %%VAR         Do not resolve the AutoEdit variable on this line.
// EXEC ...      PARM='%%ODATE'
//

The solution:

//PDPA0001 JOB  (......),BILL,CLASS=A
//STEP02   EXEC PDPRT3
//SYSIN    DD   *
%%RESOLVE OFF %%VAR         Do not resolve the AutoEdit variable on this line.
%%RESOLVE YES
// EXEC ...      PARM='%%ODATE'
//

If %%RESOLVE=NO is specified, the line is submitted as is.

%%INCLIB and %%INCMEM Statements

The original JCL:

//PDPA0001 JOB (......),BILL,CLASS=A
//STEP01   EXEC PDPRPT1
....
//* %%INCLIB CTM.LIB.COMJCL %%INCMEM PDPRPT2
//

The PDPRPT2 member in the CTM.LIB.COMJCL library contains:

//STEP02   EXEC PDPRPT2
//SYSIN    DD *
%%DATE

The submitted JCL (on June 6, 2001):

//PDPA0001 JOB (......),BILL,CLASS=A
//STEP01   EXEC PDPRPT1
....
//* %%INCLIB CTM.LIB.COMJCL %%INCMEM PDPRPT2
//STEP02   EXEC PDPRPT2
//SYSIN    DD *
010606
//

Boolean "IF" Logic

//PDPA0001 JOB (......),BILL,CLASS=A
//*
//* %%IF %%TIME LT 120000 
//*   %%SET %%PGMA=MORNPGM
//* %%ELSE
//*   %%SET %%PGMA=AFTPGM
//* %%ENDIF 
//*
//STEP01   EXEC PGM=%%PGMA...
//

//PDPA0001 JOB (......),BILL,CLASS=A
//
//* %%IF %%TIME LT 120000 
//* %%ELSE
//*   %%SET %%PGMA=AFTPGM
//* %%ENDIF
//
//STEP01   EXEC PGM=AFTPGM
..
//

//PDPA0001 JOB (......),BILL,CLASS=A
//*
//* %%IF %%WDAY NE 1
//*     %%GOTO RUN_DAILY 
//* %%ELSE
//*     %%INCLIB CTM.LIB.COMJCL %%INCMEM MONTHLY
//* %%ENDIF
//*
//* %%LABEL RUN_DAILY 
//STEPDAI   EXEC PGM=DAILY
...
//

//STEPMON   EXEC PGM=MONTHLY
...

//PDPA0001 JOB (......),BILL,CLASS=A
//*
//* %%IF 1 NE 1
//* %%ELSE
//*     %%INCLIB CTM.LIB.COMJCL %%INCMEM MONTHLY
//STEPMON   EXEC PGM=MONTHLY
...
//* %%ENDIF
//*
//* %%LABEL RUN_DAILY
//STEPDAI   EXEC PGM=DAILY
...
//

//PDPA0001 JOB (......),BILL,CLASS=A
//*
//* %%IF 2 NE 1
//*     %% GOTO RUN_DAILY
//* %%ELSE
//* %%ENDIF
//*
//* %%LABEL RUN_DAILY
//STEPDAI   EXEC PGM=DAILY
...
//