AutoEdit and JCL
This chapter includes the following topics:
Overview
In the production environment, JCL must often be manually modified 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 the JCL is inconvenient at best, and it can be error-prone and lead to serious problems. The JCL and AutoEdit facility offers an automated alternative to manual JCL update.
The JCL and AutoEdit facility enables AutoEdit terms, variables, functions, and control statements to be specified in the JCL, in place of values that change from job submission to job submission. AutoEdit terms are prefixed by a pair of percent symbols, %%, which distinguishes them from other terms. For example, the term %%ODAY is recognized as an AutoEdit term.
At time of job submission, AutoEdit terms in the JCL are resolved to, or replaced by, their actual values. The inclusion of AutoEdit terms in the job stream can eliminate the need to change JCL once it is defined.
Certain AutoEdit terms can also be used within job scheduling definitions, and can include system and user-defined variables, functions, operators, and control statements.
You can also define Global AutoEdit variables in a database that allows the variables to be accessed and updated by different jobs.
In this chapter, you will
-
see the results of using AutoEdit terms in the JCL of the job, and examine a number of AutoEdit variables
-
use one or two AutoEdit functions
-
use AutoEdit terms in the job scheduling definition
-
look at the online utility facility and use the AutoEdit simulation facility to check the results of our AutoEdit usage
Preparations
For this chapter, do the following:
-
Create a new table, not a SMART Table, called IDGS3.
-
In table IDGS3, create four very basic job scheduling definitions, for IDJOB6, IDJOB7, IDJOB8 and IDJOB9, as follows:
-
In the MEMNAME field, specify, respectively: IDJOB6, IDJOB7, IDJOB8, or IDJOB9.
-
In the GROUP field, specify: IDGRP5.
-
In the DESCRIPTION field, specify: THIS IS IDJOB6 (or, respectively, IDJOB7, IDJOB8, or IDJOB9).
-
In the DAYS field, specify: ALL.
-
In the MONTHS field, specify: Y.
-
Do not specify any IN or OUT conditions, nor any Runtime Scheduling parameters.
-
Do not specify any Post-processing parameters.
-
-
In your JCL table, create separate JCLs that do nothing—for example, IEFBR14—for jobs IDJOB6, and IDJOB7, IDJOB8, and IDJOB9. Use the JCL from IDJOB1 as the basis for this JCL.
You will make changes to the JCL and job scheduling definitions, as required, during the performance of these exercises.
Using AutoEdit System Variables in the JCL
Suppose that before a job submission you had to update the JCL with the current date, or the jobid of a previously run job. As mentioned in the introduction, such updates are inconvenient at best, and can be a source of errors, as well.
You can use AutoEdit terms to eliminate the need for such updates. In your exercise, you will use several AutoEdit variables in trivial comment lines, but these comment lines will nonetheless demonstrate the usefulness of AutoEdit terms.
-
Edit the JCL of IDJOB6, add the following comment lines, and then exit:
//* Today’s working date is: %%ODATE
//* Today’s system date is: %%DATE
//* Today’s working day is: %%ODAY
//* The current job order id is: %%ORDERID
-
Enter the Scheduling Definition facility and order IDJOB6 (in table IDGS3). The Message screen is displayed indicating that the job ran.
-
Go to the Active Environment screen and request the Sysout display for the job (enter option V for the job to display the Job Order Execution History screen, and then enter option S to display the Sysout Viewing screen). The Sysout for job IDJOB6 is displayed.
-
Page down, or enter the command N (NEXT) in the COMMAND field (Command NEXT is discussed in Navigating the Active Environment.).
The Sysout contains the comment lines you inserted in the JCL, as shown in Figure43). Notice that the AutoEdit variables in the JCL resolved to their appropriate values.
Figure 43 Sysout for Job IDJOB6
Copy------------- CONTROL-M/CONTROL-R SYSOUT VIEWING ------ PAGE 2 OF 3
COMMAND ===> SCROLL===> CRSR
MEMNAME IDJOB6 OWNER ID JOBNAME M21 ODATE 020201
----+----1----+----2----+----3----+----4----+----5----+----6----+----7----+----8
1 //M21 JOB APERLMAN,CLASS=A,
// MSGCLASS=X,NOTIFY=M21,
// MSGLEVEL=(1,1)
//*---- SUBMITTED BY CONTROL-M (FROM MEMLIB) ODATE=010131
//*---- SCHEDULE CTM.TEST.SCHEDULE(IDGS3)
//*---- JCL CTM.TEST.JCL(IDJOB6)
//*---- CONTROL-M JOB IDENTIFICATION: ORDER ID=001S2 RUN NO.=00001
//* TODAY'S WORKING DATE IS: 010202
//* TODAY'S SYSTEM DATE IS: 010202
//* TODAY'S WORKING DAY IS: 02
//* THE CURRENT JOB ORDER ID IS: 001S2
2 //S1 EXEC PGM=IEFBR14
**** END OF DATA SET - ADDED BY CONTROL M **** DO NOT USE IT IN YOUR PROGRAM !!
ICH70001I STCUSER LAST ACCESS AT 02:00:13 ON FRIDAY, FEBRUARY 02, 2001
ICH70001I STCUSER LAST ACCESS AT 02:00:13 ON FRIDAY, FEBRUARY 02, 2001
IEF142I M21 S1 - STEP WAS EXECUTED - COND CODE 0000
--------------------------------- - BMC - -----------------------------------
- CPU (Total) Elapsed CPU (TCB)
-Program Stepname ProcStep RC I/O hh:mm:ss.th hh:mm:ss.th hh:mm:ss.th
COMMANDS: LEFT, RIGHT, FIND str, FIND str PREV, N n, P n, END 03.20.12It you were to run this job again tomorrow, then the variables would resolve accordingly. It should be apparent, that use of AutoEdit system variables such as %%ODATE can eliminate the need to manually update the JCL before a job is run.
Before continuing with the exercise, take a closer look at certain date concepts and AutoEdit date variables.
System Date, Working Date and ODATE
Control-M distinguishes between system date, current working date, and ODATE (original date).
System Date
System date corresponds to the actual calendar date. At any hour on the 9th of September in the year 2000, the system date is the 090900. At the end of the day, when midnight is reached, the system date changes to the 10th of September (100900).
(Of course, your system clock can be set incorrectly. For example, if the system clock is an hour slow, then your system date will not advance at midnight, but rather at 1:00 a.m. Assume that your system clock is set correctly, and that the system time and date correspond to the true time and date.)
Current Working Date
Working date is a Control-M concept that is generally useful in data centers. Basically it allows you to define your day to begin and end at some other time than midnight.
The advantage of using a working day in the production data center is that end of day jobs performed after midnight can have the same working date as jobs performed before midnight; they all have the same working day.
Each site defines its own working day for Control-M. Actually, the site defines the start time of the new working day, which also marks the end of the old working day.
For example, if the new working day at the site begins at 5:00 a.m.:
-
A job that runs at 11:00 p.m. on September 9th, 2000 has the following dates (yymmdd format):
-
System date: 000909
-
Current working date: 000909
-
-
A job that runs at 3:00 a.m. on September 9, 2000 has the following dates (yymmdd format):
-
System date: 000910
-
Current working date: 000909
-
ODATE
You have seen the term ODAT several times when using date references in conditions in IN and OUT and DO COND statements. ODAT is a four-letter abbreviation of ODATE; the term is abbreviated in conditions because the date field of conditions only allows entry of four characters.
ODATE is a keyword that means Original scheduling date, and it refers to (and resolves to) the working date on which the job was originally scheduled.
The important points to note are that:
-
ODATE refers to the working date, not the system date.
-
The ODATE may in some cases be different than the current working date. For example, if a job was delayed so that it did not run on its ODATE, but instead ran on the next working day, then its current working date would be one day later than its ODATE.
The ODATE allows Control-M (and you) distinguish between different orders of the same job, and determine which job order of the job applies to which date. The same applies to conditions.
Date System Variables
In the preceding steps, you specified a number of variables in the JCL, including, %%ODATE, %%DATE, and %%ODAY. These variables are predefined system date variables, with the following characteristics:
-
Predefined system date variables defined to Control-M with recognized meanings.
-
Predefined system date variables have values that are not user-supplied, but are resolved from values that are system-supplied.
-
Predefined system date variables resolve according to date information.
The AutoEdit facility recognizes many system date variables. These are listed and defined in the JCL and AutoEdit facility chapter of the Control-M for z/OS User Guide. However, rather than considering them individually, it is easier to think of system date variables in terms of groupings. Once you have considered the groupings, you can probably anticipate the correct variable name, as illustrated below:
-
Date variables can be used for system date, original scheduling date, and current working date.
For example, you saw %%DATE resolve to the system date and %%ODATE resolve to the original scheduling date. You also could have specified %%RDATE, which resolves to the current working date.
While there is no special prefix to indicate system dates, original scheduling date variables have a prefix of %%O, and current working date variables have a prefix of %%R.
-
Different date units can be requested.
-
For example, you saw %%ODAY provide the day unit (1 - 13) of the original scheduling date.
-
Some of the more common system date units are %%DAY, %%MONTH, %%YEAR, %%WDAY, which indicates weekday, and %%WEEK, which indicates the week number in the year, 1through53.
-
The corresponding variables, such as %%OWDAY or %%RWDAY, are available for original scheduling dates and current working dates.
-
Other date units of the original scheduling date include %%OMONTH, %%OYEAR, %%OWDAY, for weekday, and %%OWEEK, for week of the year, 1through53.
-
-
Julian day variables can also be requested. These are all suffixed JULDAY.
%%JULDAY, %%OJULDAY, and %%RJULDAY are examples of valid Julian date variables.
-
Years in the variables described above are 2-character years. If a 4-character year is desired, a $ should follow the %%.
For example, %%$DATE, %%$ODATE, and %%$RDATE each return the appropriated date in yyyymmdd format, or a different 4-character year format, depending upon the standards in place at your site.
Non-Date System Variables
In addition to the date system variables discussed above, many system variables that do not relate to dates are available. %%ORDERID, which you specified in the JCL of IDJOB6, and which indicates the ID assigned by Control-M to the job order, is a non-date system variable. Available AutoEdit non-date system variables are listed in the following table:
Table 11 Non-Date AutoEdit System Variables
|
Variable |
Description |
|---|---|
|
%%. |
Concatenation symbol. |
|
%%APPL |
Application to which the job belongs. |
|
%%BLANK |
Blank. |
|
%%BLANKn |
Resolves to n blanks, where n is a number between 1 and 99. |
|
%%GROUP |
Group to which the job belongs. |
|
%%JOBNAME |
Name of the submitted job as specified in the JCL job statement. If %%JOBNAME is resolved before the job submission (for example, %%JOBNAME is used in a SHOUT WHEN LATESUB statement, and the job has not been submitted), its value is assigned the %%$MEMNAME value. |
|
%%ORDERID |
Unique job order ID under Control-M (5 characters). |
|
%%OWNER |
Owner of the job, as specified in the scheduling definition. |
|
%%RN |
Run number (can exceed one for cyclic and rerun and restarted jobs). |
|
%%TIME |
Time of day (format hhmmss). |
|
%%$MEMNAME |
Name of the JCL member from which the job is submitted. (This corresponds to the value specified in the job scheduling definition.) |
|
%%$QNAME |
Qname (unique identifier) of the monitor that submitted the job. |
|
%%$SCHDLIB |
Name of the scheduling library that contains the job scheduling definition of the job. |
|
%%$SCHDTAB |
Name of the table that contains the job scheduling definition of the job. |
|
%%$SIGN |
1-character ID of the computer on which the job is running. |
|
%%$RBC |
Name of the Schedule RBC by which the job was scheduled. If the SMART Table was forced, or if the job was scheduled based on basic scheduling criteria other than a Schedule RBC, this value resolves to blanks. |
Thus far, you have used AutoEdit predefined system variables. These included date system variables, such as %%ODATE, and non-date system variables, such as %%ORDERID.
Introduction to AutoEdit Control Statements and Functions
-
Edit the JCL of IDJOB6, delete the previously added comment lines, and add the following comment lines in their place. Do NOT exit the JCL.
//* %%SET %%A=%%$CALCDTE %%$ODATE -1//* THE VALUE OF A IS: %%AYou can now examine the components of the preceding %%SET statement.
%% SET
where %%SET is an AutoEdit control statement.
Control statements are used to define the AutoEdit environment, and to control AutoEdit processing, in the JCL. 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, in 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.
Control statement %%SET sets values of user-defined variables. The format of the statement is:
%%SET %%varname=expression
where:
-
varname is the user-defined variable
-
expression can consist of
-
a value, such as 5
-
a variable, such as %%ODATE
-
a combination of values, variables, operators, functions, and so on, such as %%GENERATION_NUMBER %%PLUS 1
-
%%A
%%A is a user-defined AutoEdit variable.
Unlike system variables whose names and meanings are predefined and recognized by Control-M, user-defined variables are defined by the user. You could just as easily have called this variable %%FRED or, if you wanted a more meaningful name, %%BACKDATE.
%%$CALCDTE
%%$CALCDTE is an AutoEdit function. Like system variables, AutoEdit functions are predefined and have set meanings. In the JCL, AutoEdit functions can only be specified in a %%SET control statement.
Function %%$CALCDTE performs date manipulation by adding or subtracting a specified number of days from a specified date.
AutoEdit Function Details
%%$CALCDTE
In the preceding step, the principal AutoEdit term is %%$CALCDTE. It is true that the function needed to be placed in a %%SET control statement, and it is also true that the returned result needed to be represented by a user-defined AutoEdit variable. But the purpose of this %%SET control statement is to perform the date calculation function. The control statement and user-defined variable are incidental to the function.
The format of function %%$CALCDTE is
%%$CALCDTE date ± quantity
where
-
date must be, or must resolve to, a date in format yyyymmdd.
-
quantity is a number, or numeric AutoEdit expression, of days to add or subtract from the date
In this step of your exercise, %%$CALCDTE subtracts one day from the ODATE.
A related function, %%CALCDATE, makes the same calculation for dates having a 2-character year, that is, dates resolving to format yymmdd. This function has a 366 day limit on the number of days that can be added or subtracted. The %%CALCDATE function is supported for reasons of backward compatibility—it is recommended that %%$CALCDTE be used whenever possible.
%%$JULIAN
You can examine one more function before exiting the JCL.
-
Add the following lines below the %%$CALCDTE function in the JCL:
//* %%SET %%B=%%$JULIAN %%A//* THE VALUE OF B IS: %%BFunction %%$JULIAN converts a Gregorian date with a 4-character year, to a Julian date with a 4-character year.
The format of function %%$JULIAN is:
%%$JULIAN datewhere date must be, or must resolve to, a date in format yyyymmdd.
In your exercise, you know that %%A, which is defined in the preceding %%$CALCDTE function, resolves to your ODATE -1. Therefore, %%B should resolve to the Julian version of this date.
-
Exit the JCL. You can now run the job.
-
Return to the Job List screen and order IDJOB6.
-
Go to the Active Environment screen, request the Job Order Execution History screen for the job, then request the Sysout Viewing screen for the job execution, and check the Sysout of the job. Page down to the middle section of the Sysout.
Copy**** END OF DATA SET - ADDED BY CONTROL M **** DO NOT USE IT IN YOUR PROGRAM !!
1 //M21 JOB APERLMAN,CLASS=A,
// MSGCLASS=X,NOTIFY=M21,
// MSGLEVEL=(1,1)
//*---- SUBMITTED BY CONTROL-M (FROM MEMLIB) ODATE=010131
//*---- SCHEDULE CTM.TEST.SCHEDULE(IDGS3)
//*---- JCL CTM.TEST.JCL(IDJOB6)
//*---- CONTROL-M JOB IDENTIFICATION: ORDER ID=001S5 RUN NO.=00001
//* %%SET %%A=%%$CALCDTE 20010202 -1
//* THE VALUE OF A IS: 20010201
//* %%SET %%B=%%$JULIAN 20010201
//* THE VALUE OF B IS: 2001032
2 //S1 EXEC PGM=IEFBR14
**** END OF DATA SET - ADDED BY CONTROL M **** DO NOT USE IT IN YOUR PROGRAM !!
Observe the following:
-
In the first comment statement, ODATE resolves to the current original scheduling date.
-
In the second and third comment lines, %%A resolved to the previous day.
-
In the fourth comment line, %%B resolved to the Julian value of %%A.
Other Available Functions
Shown in the following table is a list of some of the other AutoEdit functions available, besides %%$CALCDTE and %%$JULIAN. They are described in detail in the Control-M for z/OS User Guide.
All date-related functions with a $ symbol, that is, those beginning %%$, require and return 4-character years, in format yyyy.
Table 12 Other AutoEdit Functions
|
Function |
Description |
|---|---|
|
%%$GREG |
Converts a Julian date to a Gregorian date. |
|
%%$LEAP |
Determines whether a specified Gregorian date falls in a leap year. |
|
%%$WCALC |
Performs a shift from the specified date to a working date in the specified calendar, according to indicated instructions. |
|
%%$WEEK# |
Calculates in which of weeks 1 through 53 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. |
|
%%$WEEKDAY |
Calculates on which day of the week a specified date 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, either Saturday or Sunday. |
|
%%$YEARWK# |
Calculates in which of weeks 1 through 53 a specified date falls, and returns the year and the week number according to ISO8601 standards. The function uses the site-defined start of the week—Sunday or Monday— as the first day of each week, and assumes that the first week is the week that includes January 4th. |
|
%%SUBSTR |
Extracts a substring from a string. |
Supplying Variable Values through the Job Scheduling Definition
As mentioned earlier, AutoEdit variables that resolve to desired values can be placed in the JCL. This is useful at sites where changes to the JCL are discouraged or not allowed.
If the variables are system variables, the values, by definition, are automatically supplied by the system. But if the variables are user-defined variables, the user must somehow provide the values for those variables. One method of providing those values is through the job scheduling definition.
For example, suppose the JCL must be provided the ID of a tape that is being mounted and used. A user-defined AutoEdit variable representing the tape ID can be placed in the JCL. Then, before the job is run, the value for that tape ID can be provided in the job scheduling definition.
You can now add a user-defined variable for the tape ID to the JCL, and set its value in the job scheduling definition. To keep this exercise at a basic level, you will again place the variable in a comment line in a trivial JCL.
-
Edit the JCL of IDJOB7, add the following comment line, and then exit the JCL:
//* TAPE ID PROVIDED: %%TAPEIDYou can now edit the job scheduling definition for IDJOB7.
-
Enter the job scheduling definition for IDJOB7.
Notice that the General Parameters section contains a field called SET VAR.
Copy+-----------------------------------------------------------------------------+
MEMNAME IDJOB7 MEMLIB CTM.TEST.JCLLIB
OWNER ID TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GROUP IDGRP5
DESC THIS IS IDJOB7
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR
CTB STEP AT NAME TYPE
DOCMEM IDJOB7 DOCLIB
===========================================================================The SET VAR statement is used for specifying a value for a user-defined AutoEdit variable. Assume that the ID of the tape is 046453.
-
Specify %%TAPEID=046453 in the SET VAR statement. It appears as follows:
CopyJOB: IDJOB7 LIB CTM.TEST.SCHEDULE TABLE: IDGS3
COMMAND ===> SCROLL===> CRSR
+-----------------------------------------------------------------------------+
MEMNAME IDJOB7 MEMLIB CTM.TEST.JCLLIB
OWNER ID TASKTYPE JOB PREVENT-NCT2 DFLT N
APPL GROUP IDGRP5
DESC THIS IS IDJOB7
OVERLIB STAT CAL
SCHENV SYSTEM ID NJE NODE
SET VAR %%TAPEID=046453
SET VAR
CTB STEP AT NAME TYPE
DOCMEM IDJOB7 DOCLIB
=========================================================================== -
Exit the job scheduling definition, and then exit the Job List screen. Save the changes in the Exit Option window of the Job List screen.
Before running the job, take a look at the AutoEdit Simulation facility.
Checking AutoEdit Syntax and Results
When Control-M detects an AutoEdit syntax error in a JCL member during submission, the submission is canceled by Control-M. Therefore, it is good practice 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 AutoEdit Simulation facility, utility CTMAESIM 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.
Utility CTMAESIM can operate in either JCL Library mode or Scheduling Library mode:
-
In JCL Library mode, the utility checks the AutoEdit statements in the JCL of the job, but not in the job scheduling definition.
This mode becomes operational when you specify a JCL member in the utility panel; in this case, the table that contains the job scheduling definition is unknown to the utility, and the job scheduling definition therefore remains unchecked.
-
In Scheduling Library mode, the utility not only checks the AutoEdit statements in the JCL of the job, it also checks the impact that SET VAR statements in the job scheduling definition have on the JCL.
This mode becomes operational when you specify a job scheduling definition in the utility panel. Because the job scheduling definition points to the JCL member, both the job scheduling definition and the JCL can be, and are, checked.
Activating Utility CTMAESIM
-
Display the Online Utilities menu by selection Option 6 of the IOA PRIMARY OPTION MENU.
If Option 6 from the IOA Primary Option Menu does not bring you to the Utilities menu, ask your INCONTROL administrator to assist you in accessing the Utilities menu from TSO, or advise you how to access utility CTMAESIM directly.
The IOA Online Utilities menu is displayed. The particular options displayed in the menu depend on the INCONTROL products available at your site, as well as any limitations your INCONTROL administrator may have placed on the display. The IOA Online Utilities menu, and available Control-M utilities, are described in detail in the INCONTROL for z/OS Utilities Guide.
Copy------------------------------ ON-LINE UTILITIES ------------------------------
OPTION ===>
USERID - M21
TIME - 18:06
TERMINAL - 3278
I1 PREREQ CONDITION - Add/Check/Delete a Prerequisite Condition
M1 JOB ORDER ISSUE - Issue a Job Order
M2 AUTOEDIT SIMUL - Perform an AutoEdit Simulation
M3 SIMUL/TAPE PULL - Prepare Simulation/Tape Pull List Job
M4 PARAM PROMPTING - Parameter Prompting Facilities
M5 QUICK SCHEDULE - Quick Schedule Definition
M6 USER INTERFACE - End-User Job Order Interface
R1 CONTROL-R SIMUL - Control-R Simulation
R2 DATASET CLEANUP - Control-R Dataset Cleanup
R3 JOB DATASET LIST - Prepare a Job Dataset List
R4 STANDALONE - Control-R Standalone
U1 DOCU/TEXT - Invoke DOCU/TEXT
X EXIT - Exit This Menu -
Enter M2 in the OPTION field to access utility CTMAESIM. The AutoEdit Simulation panel is displayed.
Figure 44 AutoEdit Simulation Panel
Copy------------------- PERFORM CONTROL-M AUTOEDIT SIMULATION -------------------
COMMAND ===>
SPECIFY JCL LIBRARY OR SCHEDULE LIBRARY INFORMATION
JCL LIBRARY MODE:
JCL LIBRARY ===>
MEMBER NAME ===>
OWNER ===>
APPLICATION NAME ===>
GROUP NAME ===>
RBC NAME ===>
SCHEDULING LIBRARY MODE:
SCHEDULING LIBRARY ===> CTM.TEST.SCHEDULE
TABLE NAME ===>
JOB NAME ===>
PARAMETER LIBRARY ===> CTM.TEST.PARM
WDATE ===> 02 02 01 (DD MM YY)
ODATE ===> 02 02 01 (DD MM YY)
FUNCTION ===> LIST (LIST/SUBSCAN/SUBMIT)
ENTER YES TO CONTINUE ===> -
Fill in the SCHEDULING LIBRARY MODE parameters with the name of the scheduling library, table, and job scheduling definition, and enter YES in the ENTER YES TO CONTINUE field. Do not change the default values in the GLOBAL LIBRARY, WDATE and ODATE fields; and type LIST in the FUNCTION field.
The screen should look similar to the following before you press Enter:
Copy------------------- PERFORM CONTROL-M AUTOEDIT SIMULATION -------------------
COMMAND ===>
SPECIFY JCL LIBRARY OR SCHEDULE LIBRARY INFORMATION
JCL LIBRARY MODE:
JCL LIBRARY ===>
MEMBER NAME ===>
OWNER ===>
APPLICATION NAME ===>
GROUP NAME ===>
RBC NAME ===>
SCHEDULING LIBRARY MODE:
SCHEDULING LIBRARY ===> CTM.TEST.SCHEDULE
TABLE NAME ===> IDGS3
JOB NAME ===> IDJOB7
PARAMETER LIBRARY ===> CTM.TEST.PARM
WDATE ===> 02 02 01 (DD MM YY)
ODATE ===> 02 02 01 (DD MM YY)
FUNCTION ===> LIST (LIST/SUBSCAN/SUBMIT)
ENTER YES TO CONTINUE ===> YESThe simulation is performed. The output of the simulation is displayed as follows. This is a JCL and AutoEdit scan.
Copy********************************* Top of Data **********************************
SUB131ISUBMITTER STARTED
04.52.06 AES175I JOB SUBMISSION SIMULATION STARTED
SCHEDLIB CTM.TEST.SCHEDULE
TABLE IDGS3
JOB IDJOB7
WDATE 020201
ODATE 020201
LIST
04.52.06 AESL47I 'SCHEDLIB' CONTROL CARD FOUND - SCHEDULE LIBRARY PROCESSING MOD
04.52.06 AES190I IDJOB7 RETRIEVED FROM TABLE IDGS3 IN SCHEDULE LIBRARY CTM.
04.52.06 AESL53I IDJOB7 RETRIEVED FROM MEMLIB LIBRARY CTM.TEST.JCL
04.52.06 AES177I START SUBMISSION SIMULATION OF MEMBER IDJOB7 LIBRARY CTM.TE
-------------------------------------------------------------------------------
//M21 JOB APERLMAN,CLASS=A,
// MSGCLASS=X,NOTIFY=M21,
// MSGLEVEL=(1,1)
//*NET ID=AESUSER
//*---- SUBMITTED BY CONTROL-M (FROM MEMLIB) ODATE=010202
//*---- SCHEDULE CTM.TEST.SCHEDULE(IDGS3)
//*---- JCL CTM.TEST.JCL(IDJOB7)
//*---- CONTROL-M JOB IDENTIFICATION: ORDER ID=ZZZZZ RUN NO.=00001
//* TAPE ID PROVIDED 046453
//S1 EXEC PGM=IEFBR14
SUB133IIDGRP3 IDJOB7 ZZZZZID SUBMITTED FROM LIBRARY (P)
-------------------------------------------------------------------------------
04.52.07 AES178I END SUBMISSION SIMULATION OF MEMBER IDJOB7 LIBRARY CTM.TEST
04.52.07 AES176I JOB SUBMISSION SIMULATION ENDED
SUB159ISHUT DOWN UPON REQUEST OF MAIN TASK
******************************** Bottom of Data ********************************Notice that in the comment line you added to the JCL, the user-defined AutoEdit variable is resolved to, or replaced by, the value provided by the SET VAR statement in the job scheduling definition:
//* TAPE ID PROVIDED: 046453
You can now see that if you run this job, the user-defined variable will resolve correctly.
AutoEdit Variables in Other Job Scheduling Definition Statements
In addition to specifying a value for a user-defined AutoEdit variable in a SET VAR statement in the job scheduling definition, a value can also be provided in a DO SET statement. However, because a DO SET statement, like any DO statement, is a conditional Post-processing parameter, it is only activated on a subsequent run of the job, such as a rerun or restart, and then, only provided that the particular ON criteria are satisfied.
AutoEdit terms can also be specified in the following statements in the job scheduling definition:
-
SYSOUT and DO SYSOUT
File names for SYSOUT and DO SYSOUT handling can be specified using AutoEdit variables whenever SYSOUT Option F, the copy to file or sysout archiving option, is specified, as shown in this example
SYSOUT OP F PRM GPL.%%JOBNAME.D%%ODATE.%%JOBID.T%%TIME
-
SHOUT, DO SHOUT, and DO MAIL
System AutoEdit variables can be used in shouted messages, such as
MSG JCL ERROR IN JOB %%JOBID %%STEP
-
MEMLIB and OVERLIB
AutoEdit variables can be used in the MEMLIB and OVERLIB fields to specify the appropriate library, as shown in this example
OVERLIB CTM.LIB.JCL.OVER%%ODATE
Supplying Variable Values through an External Member
In the previous steps, you provided the value for a user-defined AutoEdit variable by updating the job scheduling definition. But you can alternatively provide such values through special members dedicated to this purpose. This enables you to provide the values without updating the JCL, and without updating the job scheduling definition.
You can provide these values through an AutoEdit member identified by the AutoEdit control statements %%LIBSYM and %%MEMSYM.
-
Create a member IDTAPE in a work library. For purposes of this exercise, you will call the library CTM.TEST.AUTOEDIT.
-
In member IDTAPE, place the following lines:
%%BRANCH01_TAPE=5554444%%BRANCH02_TAPE=3336666%%BRANCH03_TAPE=7654321 -
Edit the JCL for IDJOB6 as shown in the following instructions:
-
Delete the comment lines, that is, those containing AutoEdit terms, that you added earlier.
-
Add the following statements to the JCL, then exit the JCL:
//* %%LIBSYM CTM.TEST.AUTOEDIT %%MEMSYM IDTAPE//* TAPE ID PROVIDED: %%BRANCH01_TAPE//* TAPE ID PROVIDED: %%BRANCH03_TAPE
-
-
Enter the AutoEdit Simulation utility and run the simulation for IDJOB6. The results of the simulation look similar to those shown in Figure45. Observe the resolved values for the two //* TAPE ID PROVIDED: statements.
Figure 45 AutoEdit Simulation Output
Copy********************************* Top of Data *********************************
SUB131ISUBMITTER STARTED
14.50.17 AES175I JOB SUBMISSION SIMULATION STARTED
SCHEDLIB CTM.TEST.SCHEDULE
TABLE IDGS3
JOB IDJOB6
WDATE 020201
ODATE 020201
LIST
14.50.17 AESL47I 'SCHEDLIB' CONTROL CARD FOUND - SCHEDULE LIBRARY PROCESSING MO
14.50.17 AES190I IDJOB6 RETRIEVED FROM TABLE IDGS3 IN SCHEDULE LIBRARY CTM
14.50.17 AESL53I IDJOB6 RETRIEVED FROM MEMLIB LIBRARY CTM.TEST.JCL
14.50.17 AES177I START SUBMISSION SIMULATION OF MEMBER IDJOB6 LIBRARY CTM.T
-------------------------------------------------------------------------------
//M21 JOB APERLMAN,CLASS=A,
// MSGCLASS=X,NOTIFY=ID,
// MSGLEVEL=(1,1)
//*NET ID=AESUSER
//*---- SUBMITTED BY CONTROL-M (FROM MEMLIB) ODATE=010202
//*---- SCHEDULE CTM.TEST.SCHEDULE(IDGS3)
//*---- JCL CTM.TEST.JCL(IDJOB6)
//*---- CONTROL-M JOB IDENTIFICATION: ORDER ID=ZZZZZ RUN NO.=00001
//* %%LIBSYM CTM.TEST.AUTOEDIT %%MEMSYM IDTAPE
//* TAPE ID PROVIDED: 5554444
//* TAPE ID PROVIDED: 7654321
//S1 EXEC PGM=IEFBR14
SUB133IM21GRP3 IDJOB6 ZZZZZM21 SUBMITTED FROM LIBRARY (P)
-------------------------------------------------------------------------------
14.50.18 AES178I END SUBMISSION SIMULATION OF MEMBER IDJOB6 LIBRARY CTM.TEST
14.50.18 AES176I JOB SUBMISSION SIMULATION ENDED
SUB159ISHUT DOWN UPON REQUEST OF MAIN TASK
******************************** Bottom of Data *******************************
Pointing to External Members
In the previous steps, values for user-defined variables were provided in an external member pointed to by a %%LIBSYM / %%MEMSYM control statement. Actually, there are several ways to point to external members, as described in the following table:
Table 13 Pointing to External Members
|
AutoEdit Term |
Description |
|---|---|
|
%%LIBSYM |
Includes the contents of the specified member at the location of the %%LIBSYM / %%MEMSYM control statement in the JCL. The member is read by Control-M before submission. The included member can only contain a list of AutoEdit variables and their values in the format: %%term=value This control statement is useful for providing lists of values to be used during job processing, when both the JCL and the job scheduling definition should not be updated. |
|
%%INCLIB |
Includes the contents of the specified member at the location of the %%INCLIB / %%INCMEM statement in the JCL. The member is read by Control-M before submission. This statement is useful for inserting the following types of information into the JCL:
Example of usage: If a long segment of JCL must be repeated at different points in the JCL, the segment can alternatively be placed in its own member, and an %%INCLIB / %%INCMEM control statement that points to the member can be specified at the required insertion points. |
|
%%GLOBAL |
Includes the contents of the specified member at the location of the %%GLOBAL control statement in the JCL. Like %%MEMSYM, the included member can only contain a list of AutoEdit variables and their values in the format: %%term=value Unlike the %%LIBSYM / %%MEMSYM control statement, %%GLOBAL identifies only the member name; it does not identify the library. The specified member is always taken from the library pointed to by DD statement DAGLOBAL. |
Additional AutoEdit Control Statements
In addition to the %%SET statement that you used at the beginning of this chapter, and control statements that point to external members, several other AutoEdit control statements are available. These are outlined in the following table:
Table 14 Additional AutoEdit Control Statements
|
AutoEdit Term |
Description |
|---|---|
|
%%LABEL lblnam |
%%LABEL creates a label of name lblnam at the location of the statement. |
|
%%IF |
Provide the AutoEdit facility with Boolean "IF" logic capability. These statements, in conjunction with control statements %%GOTO and %%LABEL, permit branching based on submission time criteria. Job steps, DD statements, and so on are easily excluded or included. Format of the statements is: %%IF conditional-expression statements [%%ELSE] statements %%ENDIF |
|
%%RANGE |
Limits the handling of AutoEdit functions and variables to a specified column range. Contents of all columns outside the range remain unchanged. Format of the statement is: %%RANGE fromcol tocol |
|
%%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. For details, see the description of the %%RESOLVE statement in the Control-M for z/OS User Guide. |
Complex AutoEdit Terms
Multiple AutoEdit variables, and constants, can be joined together into a complex term.
The basic rule of AutoEdit resolution is that when a term contains multiple variables, those variables are resolved from right to left.
Multiple variables can be joined together in the following ways:
-
Two variables can be joined to form a single complex variable by linking them together, as follows:
%%BACKUP_TAPE%%ODAY%
On the third day of the month, the variable partially resolves to %%BACKUP_TAPE03.
If the value of %%BACKUP_TAPE03 is known to Control-M as EE1022, this statement would fully resolve to EE1022
-
Two variables can be concatenated into two distinct but joined variables by placing a period between them.
%%ODAY.%%OMONTH
On the 4th of December, %%ODAY.%%OMONTH resolves to 0412
-
Two variables can be concatenated into two distinct variables joined by a period, by placing two periods between them.
ODAY..%%OMONTH
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 %%.
CTM%%MODE%%.01.JCL
If %%MODE=TEST, then CTM%%MODE%%.01.JCL resolves to: CTM.TEST01.JCL
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 shown in the following table:
Table 15 Valid AutoEdit Operators
|
Operator |
Description |
|---|---|
|
%%PLUS |
Adds a value to an AutoEdit variable. |
|
%%MINUS |
Subtracts a value from an AutoEdit variable. |
AutoEdit operators are generally used as follows:
%% SET variable=operand operator operand
where
-
operand is an expression that resolves to a numeric value.
-
operator is %%PLUS or %%MINUS.
Only one operator can be specified in each %%SET statement. Increase the number of generations (%%GENERATION_NUMBER) by one, as follows:
// %%SET %%GENERATION_NUMBER=%%GENERATION_NUMBER %%PLUS 1
If the value of %%GENERATION_NUMBER was initially 1, it is now set to 2.
Local Variables and Global Variables
User-defined AutoEdit variables are classified as either Local variables or Global variables.
Thus far, all the user-defined variables that you have used in this chapter have been Local variables. A characteristic of Local variables is that values given to them by a job do not carry beyond that job—those values cannot be accessed or changed by a different job.
By contrast, Global variables are stored in the IOA Global Variable database and can be accessed and updated by other jobs.
Shortly, you will create Global variables and demonstrate their global nature. Before doing that, however, you should observe the local nature of the Local variables.
-
Enter the job scheduling definition for IDJOB6 and add the following SET VAR statements, and then exit the job scheduling definition:
SET VAR %%LOC1=111SET VAR %%BRANCH01_TAPE=222222 -
Enter the job scheduling definition for IDJOB7 and delete the SET VAR definition. The job scheduling definition now contains no SET VAR definition.
-
Edit the JCL for job IDJOB7, and do the following:
-
Delete the comment line:
//* TAPE ID PROVIDED: %%TAPEID -
Add, in its place, the following comment lines:
//* %%LIBSYM CTM.TEST.AUTOEDIT %%MEMSYM IDTAPE//* BRANCH01_TAPE HAS THE VALUE: %%BRANCH01_TAPE//* LET’S SEE IF THIS RESOLVES: %%LOC1 -
Exit the JCL.
-
-
Order the job scheduling definition of IDJOB6.
-
After job IDJOB6 has successfully ended, order the job scheduling definition of job IDJOB7.
-
Check the results of the job orders in the Active Environment screen. Job IDJOB6 ended "OK", but job IDJOB7 was not submitted.
-
Request the log for IDJOB7, by using Option L.
The log indicates that IDJOB7 was not submitted because variable %%LOC1 could not be resolved. Since IDJOB6, which successfully executed, defined a value for %%LOC1, it is clear that IDJOB7 has no access to this value. This is because %%LOC1 is a local variable.
-
Edit the JCL for job IDJOB7, delete the following comment line, and then exit the JCL:
//* LET’S SEE IF THIS RESOLVES: %%LOC1 -
Rerun job IDJOB7 through Option R in the Active Environment screen. The second run of IDJOB7 ended "OK".
The job order line appears as follows in the Active Environment screen:
CopyIDJOB7 ID 020201 M21 /08316 JOB Ended "OK" (Run 2)
Prior Run: Not Submitted -
Request SYSOUT of job IDJOB7, using Option V in the Active Environment screen followed by Option S in the Job Order Execution History screen, and scroll down to find the value for BRANCH01_TAPE.
%%BRANCH01_TAPE resolved to the original value from %%MEMSYM member, 5554444, not the value set by the SET VAR statement in IDJOB6:
//* BRANCH01_TAPE HAS THE VALUE: 5554444Clearly, the SET VAR statement in IDJOB6 did not impact the value in the external member, which indicates that %%BRANCH01_TAPE is a local variable.
Now that you’ve seen the limitations of Local variables, take a look at Global Variables.
Defining Global Variables
As mentioned above, a Global variable is a user-defined variable that is placed in the IOA Global Variable database.
%%SET 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. These variables can then be used and accessed by other jobs. These jobs can use %%SET, SET VAR and/or DO SET statements to change or update the variable values in the database.
You can now define some Global variables in the job scheduling definition and JCL of job IDJOB8.
-
Enter the job scheduling definition for IDJOB8 and add the following SET VAR statements. When you define a SET VAR statement and press Enter, a new, blank SET VAR statement is opened to allow definition of the next SET VAR statement.
SET VAR %%\VAR1=AAA
SET VAR %%..\VAR2=BBB
SET VAR %%..\IDJOB9\VAR1=CCC
-
Exit the job scheduling definition.
-
Add the following statements to the JCL of job IDJOB8, and then exit the JCL:
//* VAR1 FROM JOB JOB8 EQUALS %%\VAR1
//* VAR2 FROM GROUP GRP3 EQUALS %%..\VAR2
//* VAR1 FROM JOB JOB9 EQUALS %%..\IDJOB9\VAR1
-
Order the job scheduling definition of IDJOB8.
-
Check the sysout of IDJOB8. The following comments appear in the sysout:
//* VAR1 FROM JOB JOB8 EQUALS AAA
//* VAR2 FROM GROUP GRP3 EQUALS BBB
//* VAR1 FROM JOB JOB9 EQUALS CCC
From this sysout, you can see that the AutoEdit variables resolved as they should. However, because they appeared in the job scheduling definition and the JCL of the same job, you have not yet demonstrated their global nature.
You will demonstrate the global nature of these variables shortly, but first, take a look at Global variable syntax.
Global Variable Syntax
Note the following points about Global variable assignment and syntax:
-
Global variables are identified, and distinguished from Local variables, by a backslash immediately following the %% sign. For example, whereas %%VAR1 is a Local variable, %%\VAR1 is a Global variable.
-
A Global variable is assigned an owner at time of creation. This owner can be the component that creates the variable, such as the job, or it can be any other component in the database, such as the job, group, application, or even Control-M. The IOA Global Variable Database has a hierarchical structure to reflect this component hierarchy.
-
Backslashes are used to describe the hierarchical structure of the IOA Global Variable Database, much like they are used to describe the directory and subdirectory structure in Unix and DOS.
The full path of the IOA Global Variable database is indicated as follows:
%%\product\application\group\job\variablename
-
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 backslash immediately following the %% symbol.
-
Paired dots followed by a backslash (..\) indicate movement to the next level up.
Based on the above, you can see that the variables created in IDJOB8 SETVAR statements have the following owners:
-
Table 16 IDJOB8 SET VAR Statement Owners
|
Variable |
Owner |
|---|---|
|
%%\VAR1=AAA |
Global variable %%\VAR1 is owned by job IDJOB8 |
|
%%..\VAR2=BBB |
Global variable %%\VAR2 is owned by group IDGRP3. (The paired dots moved the variable up the hierarchy to the group to which IDJOB8 belongs.) |
|
%%..\IDJOB9\ |
Global variable %%\VAR1 is owned by job IDJOB9. (The paired dots move the variable up the hierarchy to group IDGRP3. The \IDJOB9 moves the variable down the hierarchy from IDGRP3 to job IDJOB9.) |
-
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.
In our example, %%\VAR1=AAA and %%..\IDJOB9\VAR1=CCC result in different variables. As indicated in the above table
-
the Global variable %%\VAR1 that equals AAA belongs to IDJOB8
-
the Global variable %%\VAR1 that equals CCC belongs to IDJOB9
-
-
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.
Global Variable Access by Another Job
You can now take a look at the global nature of these variables.
-
Enter the job scheduling definition for IDJOB9 and do the following:
-
Enter ALL in the DAYS field.
-
Enter ANYSTEP in the ON field.
-
Enter C0000 in the CODES field.
-
Add a DO SHOUT statement whose destination is your userID, and which contains the following message text:
FIRST SHOUT: %%\VAR1
-
Add a second DO SHOUT statement whose destination is your userID, and which contains the following message text:
SECOND SHOUT: %%..\VAR2
-
Add a third DO SHOUT statement whose destination is your userID, and which contains the following message text:
THIRD SHOUT: %%..\IDJOB8\VAR1
-
Exit the job scheduling definition.
-
-
Order the job scheduling definition for job IDJOB9.
-
Order the job scheduling definition for job IDJOB9.
-
Check the Sysout of the job. The Sysout contains the following:
CopyFIRST SHOUT: CCC
SECOND SHOUT: BBB
THIRD SHOUT: AAAThese values clearly indicate that these variables have been globally accessed. You can demonstrate that these variables can be globally updated.
Before running the job, determine the anticipated results.
Table 17 Anticipated Results of Job
|
Shout |
Anticipated Resolution and Explanation |
|---|---|
|
FIRST SHOUT: |
CCC The Shout in IDJOB9 specifies Global variable %%\VAR1, which refers to a Global variable %%\VAR1 that is owned by itself (IDJOB9). Job IDJOB8 assigned the value CCC to the Global variable %%\VAR1 that is owned by IDJOB9. |
|
SECOND SHOUT: |
BBB The Shout in IDJOB9 specifies Global variable %%..\VAR2, which refers to a Global variable %%\VAR2 that is owned its group (IDGRP3). Job IDJOB8 assigned the value BBB to the Global variable %%\VAR2 that is owned by group IDGRP3. |
|
THIRD SHOUT: |
AAA The Shout in IDJOB9 specifies Global variable %%..\IDJOB8\VAR1, which refers to a Global variable %%\VAR1 that is owned by IDJOB8. Job IDJOB8 assigned the value AA A to the Global variable %%\VAR1 that is owned by itself (IDJOB8). |
Global Variable Update by Another Job
-
Enter the job scheduling definition for IDJOB9 and do the following:
-
Delete the DO SHOUT statements
-
Add the following SET VAR statements:
CopySET VAR %%\VAR1=XXX
SET VAR %%..\VAR2=YYY
SET VAR %%..\IDJOB8\VAR1=ZZZ -
Delete the ON STEP / CODES values.
-
Exit the job scheduling definition.
The job scheduling definition for job IDJOB9 will now update the values for the Global variables previously defined by IDJOB8.
-
-
Enter the job scheduling definition for job IDJOB8 and delete the SET VAR statements. Then exit the job scheduling definition.
-
Order job IDJOB9.
-
Once job IDJOB9 has ended, order job IDJOB8.
You should anticipate the following results of these successive job runs.
-
The SET VAR statements in job IDJOB9 have updated the Global variables with the new values.
-
Because the SET VAR statements were removed from job IDJOB8, this job should not have changed the values that were newly set by IDJOB9.
-
Therefore, you can expect that the JCL of job IDJOB8 used the new values set by IDJOB9.
-
-
Check the sysout of job IDJOB8. The following comments should appear in the sysout:
Copy//* VAR1 FROM JOB JOB8 EQUALS ZZZ
//* VAR2 FROM GROUP GRP3 EQUALS YYY
//* VAR1 FROM JOB JOB9 EQUALS XXX
The above values clearly indicate that Global variables can be globally updated.
JCL Setup Operation Flow
You have seen that values for variables can come from several sources, for example, external members and SET VAR statements. Therefore, it is important to know the order in which these sources are checked, and the process involved in AutoEdit resolution in JCL.
-
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, which are identified by the %% symbol prefix, and, unless otherwise instructed, tries to resolve them. Control-M resolves all AutoEdit terms in one 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, as 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 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.
-
DO SET statements can override values specified by a SET VAR or previous DO SET statement. However, since DO SET statements are Postprocessing parameters, they only affect subsequent runs of a job, specifically, 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 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.
SET VAR statements can affect all job submissions.
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 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 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.
-
Exit the Online facility.
This completes the steps in this chapter of the Control-M for z/OS Getting Started Guide.
Review
In this chapter you
-
looked at and used AutoEdit system variables (date and nondate variables) in the JCL of a job
-
learned about the difference between System date, Current Working date, and ODATE
-
used the AutoEdit %%SET control statement in your JCL, and learned about other AutoEdit control statements
-
used AutoEdit functions %%$CALCDTE and %%$JULIAN in your JCL, and learned about other AutoEdit functions
-
used the SET VAR statement in the job scheduling definition to supplied values to user-defined variables in the JCL of your job
-
checked AutoEdit syntax and results using online utility CTMAESIM
-
supplied values to AutoEdit variables through an external member that was pointed to by the %%LIBSYM and %%MEMSYM statement, and learned other ways to point to external members
-
learned about complex AutoEdit terms and AutoEdit resolution
-
learned about AutoEdit operators
-
learned the difference between Local and Global variables
-
learned the syntax of, and defined and updated Global AutoEdit variables
-
learned JCL Setup Operation flow
Recommended Reading
Before continuing with the next chapter, you should read the following in the Control-M for z/OS User Guide:
Communities
Support Center
YouTube
Twitter
Facebook
LinkedIn