Professional Documents
Culture Documents
Introduction to JCL
1
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Job Control Language (JCL) is a control language used to identify a job to an operating system and to
describe the job’s requirements. It consists of a series of statements, each of which provides specific
instructions or information for batch processing jobs.
The three main types of JCL statements are: JOB, EXEC and DD
What is a job?
A job is a unit of work defined by a user to be accomplished by a computer, including computer programs, files
or control statements.
Notes:
JCL is used to describe the work you want a system using multiple virtual storage (MVS) to perform.
The three main types of JCL statements are: JOB, EXEC and DD JOB - It marks the beginning of a job
and identifies the job name
EXEC - It marks the beginning of a job step and specifies the name of the program to be executed
DD - It describes data sets to be used within individual steps
JCL provides information to the system about job details including:
The programs to execute
The location of the required data sets
The department to be billed for CPU processing time
The job class
Job example:
For example: The request to perform a task of updating one data set with information from another data
set is called a job.
JCL provides the operating system with information about the resources, programs, and data necessary to
complete the job.
2
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Jobs – An Example
After
Execution
10
01
10
01 10
01
Example: A job may direct the computer to run a program that combines two data sets into one new data set.
Notes:
3
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Job Stream
One or more jobs placed in a series and ready to be submitted to the system are referred to as a job stream.
Notes:
This series of jobs is entered through one input device. You can use JCL to structure a job stream.
The JCL for each job begins with a JOB Statement.
4
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Job Steps
Notes:
5
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
• Programs to be executed
//DD1 DD DSN=INPUT
Notes:
6
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
The JOB statement is the first control statement in a job. It marks the beginning of a job and specifies
the job name.
The JOB statement may also provide details and parameters that relate to the overall job, such as
accounting information and conditions for job termination.
//DD1 DD DSN=OUTPUT
Parts of a Job
Notes:
Null Statement is a blank statement beginning with a double slash - // that marks the end of a job
Each job must begin with a JOB statement. All statements that follow up to the next JOB statement, are
parts of one job.
The end of a job is marked by either another JOB statement or by a null statement.
7
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Programs are stored in program libraries and retrieved by the operating system when they are
referenced by an EXEC statement.
Program
Library
PROGRAMA
Notes:
A job contains one or more EXEC statements, each followed by statements that define one or more data
sets needed for that job step.
A job step ends with the next EXEC statement, the JOB statement for the next job, or a null statement.
8
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
The DD Statement
DD statements define the data sets the program uses during execution. Each data set used in the
job requires at least one DD statement.
The number of DD statements following an EXEC statement depends on the number of data sets
required by a program. The order of DD statements within a job step is not usually significant.
Data Sets
Notes:
9
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Grouping Programs
When deciding which programs to group together as a single job, you may consider programs that:
INPUT
10
01
10
01 INOUT
OUTPUT OUTPUT
1 2
Notes:
10
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Notes:
In the example, an EXEC statement marks the beginning of the first job step (STEP1) and invokes a
program called PROGRAMA.
Because PROGRAMA uses one data set to create another, two data definition statements are needed. One
for each of the following:
INPUT
INOUT
When the system invokes PROGRAMB, another step begins in the job, which is STEP2.
Because PROGRAMB uses the output of PROGRAMA as input and then creates two output data sets of
its own, PROGRAMB needs three data definition statements, one for each of the following:
INOUT
OUTPUT1
OUTPUT2
11
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Besides the JOB, EXEC and DD statements, there are some less frequently used JCL statements.
These include:
• Comment statements:
• Null statements:
Null
statement
Notes:
Comment statements: You can use these to document JCL statements. A comment statement is coded
with two forward slashes and an asterisk (//*) in the first 3 positions. The comment text is coded in
positions 4 through 71.
Null statements: You can use a null statement to mark the end of a job. It is coded with two forward
slashes (//) in positions 1 and 2 and no other characteristics.
12
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
JCL Statement Fields Most JCL statements have the same format consisting of five fields:
•The identifier field.
•The name field
•The operation field
•The parameter field
•The comment field
Notes:
13
The Parameter Field
The parameter field contains one or more parameters separated by commas. Each JOB, EXEC and DD
statement has its own set of parameter information.
The parameter field of each JCL statement must:
Follow the operation field
Include one or more blanks between it and the operation field
Use commas to separate parameters
Have no blanks between parameters
14
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Name Field
Notes:
Special characters:
The following special characters can not be included:
& (ampersand)
! (exclamation mark)
(asterisk)
, (comma)
= (equal sign)
- ( hyphen); .(period)
+ (plus sign)
/ (slash)
( (left parenthesis)
) (right parenthesis).
15
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
You should remember the following rules while writing a JCL statement:
• Do not embed blanks within any field. For example, do not code a blank to separate parameters in
the parameter field.
Notes:
Apart from these rules, JCL coding is free form. Fields (except for the name field) and parameters do not
have to begin or end in any particular position.
16
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
In the JCL statements that you have seen so far, the //JOB1 JOB 504,SMITH
//STEP1 EXEC PGM=PROGRAM
operation fields contain the operators JOB, EXEC, //DD1 DD DSN=INPUT,DISP=SHR
and DD.
Operation Field
Notes:
17
z/OS MVS JCL – Unit I
Unit: Introduction to JCL
Following is an example of a single JCL statement that continues on 2 additional lines. All 3 lines
comprise one JCL statement.
//STEP1 EXEC PGM=PROGRAMA,
// TIME=1,
// PARM=LIST
Blank
position
Comment: Examples
Notes:
18
Unit 2
Analyzing Job Output
19
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
Use SDSF to view the output and determine whether the job completed successfully.
Notes:
DA Active users
The Display Active Users (DA) panel allows authorized users to display information about jobs, users,
started tasks, and initiators that are active on the system. It also shows system-wide data, such as CPU
usage and paging rate.
In a sysplex environment, the DA panel displays data for all systems in the sysplex. A sysplex-wide DA
panel requires the use of RMF as the source of the data.
Note: Some of the values on the DA panel, such as CPU% and SIO, are approximate. For detailed and
precise performance monitoring, use RMF.
I Input queue
The Input Queue panel allows authorized users to display information about jobs that are on the JES2
input queue or that are executing.
O Output queue
The Output Queue panel allows authorized users to display information about output data sets for jobs,
started tasks, and TSO users on any nonheld output queue.
20
H Held output queue
The Held Output Queue panel allows authorizedusers to display information about SYSOUT data sets for
jobs, started tasks, and TSO users on any held JES2 output queue. There is one row for each output group
for each job.
ST Status of jobs
The Status panel allows authorized users to display information about jobs, started tasks, and TSO users
on the JES2 queues.
Action characters
Action characters that can be entered in the NP column by authorized users are:
// Block repeat; type // on the first row and another // on the last row to be processed
= Repeat previous action character or overtype
+ Expand the NP column. (Use RESET to reset.)
? Display a list of the data sets for a job. (Access the Job Data Set panel.)
A Release a held job.
C Cancel an active job or a job waiting to be processed
CA Cancel a job that is defined to Automatic Restart Manager (ARM).
CD Cancel a job and take a dump.
CDA Cancel a job that is defined to ARM, and take a dump.
D Display job information in the log.
DL Display job information in the log, long form
E Process a job again.
EC Process a job again, but hold it prior to execution.
H Hold a job.
I Display job delay information.
J Start a job immediately (WLM-managed classes only).
L List a job's output status in the log.
LL List a job's output status in the log, long form.
O Release held output for printing.
P Cancel a job and purge its output.
PP Cancel a protected job and purge its output.
Q Display output descriptors for all of the data sets for a job. (Access the Output Descriptors panel.)
S Display the data sets for a job. (Access the Output Data Set panel.)
SB Use ISPF Browse.
SE Use ISPF Edit.
SJ Use ISPF Edit to edit the JCL.
W Cause job and message logs to spin .
X Print output data sets. You can add the following:
C Close the print file after printing (XC)
D Display the Open Print Data Set panel (XD or XDC)
F Display the Open Print File panel (XF or XFC)
S Display the Open Print panel (XS or XSC)
21
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
Notes:
PREFIX Command
Purpose: Limit the jobs that are displayed by job name.
Where used: Any SDSF panel (except help and tutorial), but affects only the DA, I, O, H, PS and ST
panels.
Format: PREFIX (string | * | ?)
string is the name of the job, up to 8 characters, including* (any string of characters) or % (any single
character). “?”displays the current setting on the command line or pop-up.
Examples: PREFIX IEB - Displays only jobs with the name IEB.
PRE IEB* - Displays only jobs whose names begin with IEB.
PREFIX with no parameters displays all jobs, except on the Held Output Queue panel, where it displays
all jobs with names that begin with your user ID.
22
OWNER Command
Purpose: Limit jobs displayed by owning user ID. You must be authorized to use this command.
Where used: Any SDSF panel (except help and tutorial panels) but only affects the DA, I, O, H, PS and
ST panels.
Format: OWNER (ownerid | *| ?) ownerid is the owning user ID of the job, or the netmail ID. It can be
up to 8 characters including * (any string of characters) or % (any single character). “?” displays the
current setting on the command line or pop-up.
Examples: OWNER KENJON2 (with no other filtering in effect). Displays only jobs for that owner.
OWNER * (with no other filtering in effect). Displays all jobs for all owner IDs.
23
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
The Output Data Set panel allows authorized users to browse data, such
as a job's output data sets
Notes:
The Output Data Set panel allows authorized users to browse data, such as a job's output data sets. It
displays output formatted for a line-mode printer.
Access it with the S action character.
When used to browse a job's output data set, the panel also displays the JES2 job log, JCL for the job, and
any job-related messages.
24
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
Notes:
JCL statements can also be statements from any invoked procedure. The XX in the identifier field
precedes invoked procedure statements
Statements from the invoked procedures may also appear in the output listing. The first MSGLEVEL
subparameter determines if these statements appear in the output listing.
25
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
Notes:
Allocation Messages
Allocation messages show how the system assigns resources to a job.
In an output listing, each of the allocation messages always follows a specially numbered statement called
a system message identifier.
Each allocation statement follows the system message identifier IEF237I.
Termination Messages
Termination messages show job termination and job step termination, as well as the disposition (or status)
of the job’s data sets at the time of termination.
In this example, the termination messages indicate the COMP step of the COB job terminated with a
condition code of 12.
At the time of termination, the system kept the VSCOB.LINKLIB data set, sent the JES2 control
messages to the SYSOUT data set, and deleted the
SYS86357.T103552.RA000.OL29EX00.R000001ystem data set.
Like allocation messages, termination messages are characterized by specially numbered statements.
26
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
JCL error messages point to any JCL statements that contain coding errors or fail to execute properly.
Usually JCL error messages contain the JCL statement number of the statement that caused the error to occur.
The statement number of the statement that caused the error precedes the system message identifiers.
Notes:
Just like allocation and termination messages, system message identifiers precede JCL error messages.
In the example, the value of the message class is too long (MSGCLASS=12).
The value of the MSGCLASS parameter is only one character (e.g., MSGCLASS=A).
27
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output
Example 2
Missing comma
Notes:
Example 1:
Here the MSGLEVEL parameter in the JOB statement is misspelled.
The JCL error message would occur if the JOB statement was run.
Example 2:
In some cases, there might be errors in the JCL, even if no error messages appear in the output listing.
Here in this example, a space exists between the MSGLEVEL and MSGCLASS parameters.
The operating system considers anything after the space as comment and so will ignore the request for
message class.
And as MSGCLASS=A is considered a comment, no error message will be listed.
Example 3:
In the example, the comma between the 2 and 1 in the MSGLEVEL parameter was accidentally omitted.
Running a job with this JOB statement would cause an JCL error message as shown.
28
Unit 3
Coding JOB Statements
29
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
A JOB statement is the first statement in any JCL code and marks the start of a job and gives the name of
the job.
The parameters included in the JOB statement, such as accounting information and condition settings for
job termination, apply to the entire job.
Parameter Fields
The parameter field, in the JOB statement defines information that applies to the entire job. This information
includes accounting information, programmer name, and additional information regarding the job.
Notes:
The JOB name is a 1 to 8 character name that identifies the job so that other JCL statements or the
operating system can refer to it.
The JOB name must begin in position 3 with no spaces between it and the identifier.
The operation field follows the job name. For a JOB statement, the operator in the operation field is JOB.
Parameter Fields
One or more spaces separate the job parameters from the JOB operation field.
The parameter field can specify job accounting information and the programmer's name as has
been shown on the right.
A comma separates the job accounting information and the programmer's name.
Many organizations require the accounting information in order to charge computer time to the
appropriate department.
Often organizations require the programmer name information so that any problems return to the
appropriate individual or group.
30
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements Topic: The JOB Name
Notes:
The job name is the second field in a JOB statement. It follows the identifier field (//).
A JCL programmer should select the mandatory job name to identify the job to the operating system.
The operating system will not run jobs having the same name concurrently. Therefore, it is important that
each job should be assigned a unique name.
If two jobs having the same name try to execute at the same time, the second one gets delayed till the first
one completes.
31
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
Positional Parameters
Positional parameters are parameters that are characterized by their location in the parameter field in
relation to other parameters.
The two positional parameters for a JOB statement are:
• Job accounting information
• Programmer name.
For example: The job statement shown here uses a job accounting number of 776 and identifies the
programmer of this job as K.YALE.
Keyword
Parameter
Notes:
32
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The value that you code for job accounting information depends on your installation. The code is usually a
number to identify a department or person to whom processor time is billed.
Multiple Parameters
If you omit the job accounting parameter, you must indicate its absence with a comma if you are
coding the programmer name.
Notes:
When job accounting information consists of multiple subparameters, the job accounting subparameters
must be enclosed in either parenthesis or apostrophes.
What is an installation?
Instalation refers to a particular computing system, including the work it does and the people who manage
and operate it.
In addition to the basic job accounting number, your installation may require information such as:
Date
Project director
Project number
The job accounting information appear in parentheses here because it appears in parentheses because it
consists of two subparameters:
255
DEPT/OPS
The parentheses indicate to the operating system that both subparameters comprise the job accounting
information.
Can you use special characters in subparameters?
Special characters can be used in subparameters, provided the subparameters are enclosed in apostrophes.
For example: The subparameter ‘DEPT/OPS’ shown is enclosed in apostrophes because theslash (/) is a
special character.
33
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The programmer name parameter identifies the person or group responsible for a job.
If you decide to include this information, the programmer name must immediately follow the job
accounting information parameter (or a comma to indicate its absence).
255,SMITH,MSGLEVEL=(1,0)
255,LONGPROGRAMERNAME
255,’JOHN SMITH’
255,’O”HARA’
Notes:
34
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
Apart from positional parameters, the parameter may also contain keyword parameters.
Keyword parameters are parameters consisting of a keyword and equal sign and variable information
and supply information to the operating system for control of jobs. The commonly used keyword
parameters are:
• MSGLEVEL
• MSGCLASS CLASS REGION
COND RD
GROUP LINES
MSGCLASS RESTART
MSGLEVEL SECLABEL
Keyword Parameters CARDS TIME
NOTIFY TYPRUN
PASSWORD USER
PERFORM BYTES
PRTY PAGES
CCSID SCHENV
Notes:
35
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
Statement
Message
The MSGLEVEL parameter controls how the JCL, allocation messages, and termination
messages are printed in the job's output listing (SYSOUT).
The MSGLEVEL parameter includes two subparameters: Statements and Messages. Syntax:
MSGLEVEL=(statements,messages)
Notes:
You can request the following outputs using the MSGLEVEL parameter:
A listing of the JOB statement only
A listing of all user-supplied job control statements
A listing of all user-supplied job control statements plus all inserted statements for procedures
invoked by any of the job steps
Allocation, disposition, and termination messages
36
The MSGLEVEL Parameter – Messages Subparameter
The messages subparameter indicates which messages the system is to print on the job log.
A messages subparameter can have one of the three values:
0 – Print only JCL messages. Print JES and operator messages only if the job terminates
abnormally
1 – Print all allocation/termination messages
Examples:
//JOB2 JOB 255,SMITH,MSGLEVEL=(1,1)
//JOB1 JOB 255,SMITH,MSGLEVEL=(0,0)
37
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
You can use the MSGCLASS keyword parameter to assign an output class for your output listing
(SYSOUT). Output classes are defined by the installation to designate unit record devices, such as printers.
• A letter (A-Z)
or
• A numeral (0-9)
Notes:
For example: In order to assign class A as the output class for your listing, you would code the
MSGCLASS
38
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
Both the MSGLEVEL and MSGCLASS parameters may have default settings, depending on your
installation. Omitting one or both of the keyword parameters from the JOB statement, would make the
operating system use these default settings.
In this case, you would code these parameters only if you want to have a different message level or
message class than the preset.
Default: MSGLEVEL=(1,1)
Default: MSGCLASS=A
Notes:
The MSGLEVEL subparameters are universal but output class assignments and the default settings for
both parameters depend on your installation.
39
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The condition (COND) parameter specifies the conditions under which a job terminates.
Operator Meaning
GT Greater than
GE Greater than or equal to
EQ Equal to
NE Not equal to
LT Less than
LE Less than or equal to
Notes:
40
What happens if you try to code more than eight comparisons?
Attempting to code more than eight comparisons will result in you receiving a JCL error message and
termination of the job abnormally. Therefore it is not possible to do so.
You can include the COND parameter in either the EXEC statements or the JOB statements. COND
parameters coded in the JOB statement are tested before any COND parameters coded in EXEC
statements within the job. When coded in the EXEC statement, it is possible to test the return code of
specific steps. In the JOB statement, tests apply to all steps in the JOB.
41
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The job executes the remaining job steps only if the return code is 1 through 12. If the
return code is 13 or higher, the remaining steps will be bypassed.
This example helps you to make multiple comparisons, which might be needed in some cases.
Notes:
Example 1(slide):
This example helps you read the COND parameter in the JOB statement in the JOB statement as: "If 12 is
less than the return code, do not execute any more job steps.“
Example 2 (slide):
This example helps you to make multiple comparisons, which might be needed in some cases. Here you
can read the COND parameters in the JOB statement as: "If 16 is less than the return code or if 8 is
greater than the return code, do not execute any more job steps.“ The job executes subsequent job steps
only if the return code is 8, 9, 10, 12, 13, 14, 15, or 16 for each previous job step.
Example 3:
//JOB2 JOB 776,SMITH,COND=(12,GT)
//STEP1 EXEC PGM=PROGRAMA
//STEP2 EXEC PGM=PROGRAMB
This example helps you to read the COND parameter in the JOB statement as: "If 12 is greater than the
return code of any job step, do not execute any more job steps."
The job executes the remaining job steps only if the return code is 12 or greater. If the return code is 0
through 11, the remaining steps will be bypassed.
42
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The CLASS Parameter Jobs are grouped into various job classes.
A good balance of job class assignments helps to make the most efficient use possible of the system.
Job class is a single character subparameter that can take the values A through Z or 0 through 9.
Job class
Notes:
43
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The NOTIFY parameter indicates the TSO/E user the system must notify upon job completion. For example,
to have the system send a message to JSMITH when the job EX completes, you would code the NOTIFY
parameter on a JOB statement as:
Notes:
If you use the NOTIFY parameter to specify your TSO/E user ID, the operating system automatically
sends you a job completion message when your job ends.
44
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The PRTY parameter specifies a job's priority for selection within its job class. Usually, this
parameter is meant to designate one job for execution over others in a class.
The range of PRTY values is usually 0 through 15 for JES2 and 0 through 14 for JES3, with 0 having
the lowest priority.
PRTY
Parameter
If you have to give a specific priority to a job within a specific class, you will code both the CLASS
and the PRTY parameters on the JOB statement.
Notes:
When no priority has been specified, the system processes jobs within the same class in a first-in, first-out
manner.
Example: If you have to give a specific priority of 3 to a job (within its default class), you will code the
PRTY parameter on a JOB statement as has been shown here
45
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The REGION parameter specifies the amount of storage space (in kilobytes or megabytes) that has to
be allocated to a particular job.
You can make use of this parameter to override the default region size set at your installation.
Kilobytes Megabytes
Notes:
Incase of a JOB statement, the region specified in the REGION parameter applies to all steps in a job and
it overrides any REGION parameter coded on an EXEC statement.
Normally, when the REGION parameter makes a GETMAIN request or a dynamic request for more
storage, it limits the amount of virtual storage available to a program.
Different programs operate best at different region levels. Fir instance, in order to limit the virtual storage
space of a job to 512 KB, you will need to code the REGION parameter on the JOB statement as:
//EX JOB ...,REGION=512K
In a similar manner, in order to limit a job's virtual storage space to 1024 KB bytes or 1MB, you will need
to code the REGION parameter as:
//EX JOB ...,REGION=1M
When you use the REGION parameter in conjunction with ADDRSPC=REAL, REGION specifies the
amount of real storage.
For instance, to limit a job's real storage space to 512 KB, you code the REGION parameter, along with
the ADDRSPC parameter on the JOB statement as:
//EX JOB ...,REGION=512K,
// ADDRSPC=REAL
46
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The TIME parameter specifies a maximum amount of processor time available for the job. If the limit in the
TIME parameter is reached, the job will terminate abnormally. The syntax for the TIME parameter is:
The TIME parameter preserves processor time in case of an undetected error (like an endless loop) that may
surface only during execution of program.
Examples
Notes:
For example, to limit the CPU execution time to 2 minutes and 45 seconds, you will need to code the
TIME parameter on a JOB statement as:
//EXAMPLE1 JOB 776,STUDENT,TIME=(2,45)
TIME Subparameters:
The 1440 indicates that a job is allowed to run for an unlimited amount of time. Literally, the
subparameter 1440 means 1,440 minutes (i.e. 24 hours). However, the 1440 subparameter has special
meaning to the operating system.
For instance, in order to allow your job to run indefinitely, you will code a JOB statement using the
NOLIMIT subparameter as:
//EXAMPLE JOB 776,STUDENT,TIME=1440
The NOLIMIT subparameter is identical in function to the 1440 subparameter.
Coding NOLIMIT with the TIME parameter will lead to the associated job running for an unlimited
amount of time.
For instance, in order to allow a job to run indefinitely, you will have to code a JOB statement using the
NOLIMIT subparameter as:
//EXAMPLE JOB 776,STUDENT,TIME=NOLIMIT
The MAXIMUM subparameter indicates that the associated job can run for 357,912 minutes, which is the
maximum time the operating systems allows for a job (other than unlimited).
For example to limit the job’s CPU processing time to 357,912 minutes, you would the code a JOB
statement as:
//EXAMPLE JOB 776,STUDENT,TIME=MAXIMUM
47
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The TYPRUN parameter identifies jobs that have special processing requirements.
The subparameters that can be used with the TYPRUN keyword are as follows:
• COPY (for JES2 only) - This is used to tell the system to copy the input to a SYSOUT data set for
output processing, but not to execute it.
• HOLD - this is used to tell the system to hold the job prior to execution, until the operator releases
the job.
• SCAN - This is used to tell the tell the system to scan the JCL for syntax errors, but not to execute it.
Notes:
48
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
The USER parameter identifies the user ID of the person who submitted the job.
This parameter uses a USERID subparameter which must be 1 to 7 alphanumeric characters or national
symbols. The first character cannot be numeric.
To specify a password of XYZ123, with a user ID of HARRIS, you would code the PASSWORD and USER
parameters as shown here.
Notes:
In most cases, the USER parameter is used in conjunction with the PASSWORD parameter.
Many system facilities, including the Resource Access Control Facility (RACF) and the System Resource
Manager (SRM) use the USERID subparameter.
Just as in the case of the USER parameter, the PASSWORD parameter may or may not be required at
your site.
49
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements
You can code multiple keyword parameters on a single JOB statement in any order that you
choose after any positional parameters are coded.
Notes:
Here, the JOB1 job is limited in processing time to 2 minutes, 45 seconds, and has been allocated a
limited space of 768 KB.
This job has a class of T, and a job priority of 3 within class T. This means that this job named JOB1 will
run ahead of all other jobs in class T that have a lower priority value (PRTY value) than 3.
The operating system notifies user JSMITH, upon the complete execution of the job.
50
Unit 4
Coding EXEC Statements
51
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
To execute each program in a job, you need to code one EXEC statement. Each job step begins with
an EXEC statement that identifies a program name.
In addition to this, you can also use the EXEC statement to invoke a procedure.
A procedure refers to a set of JCL statements that are stored in a library and retrieved by its name.
A procedure may contain one or more EXEC statements.
Procedure
Notes:
The EXEC statement has to be coded using a particular JCL syntax. Like the JOB statement, the EXEC
statement too has five fields. The EXEC statement format includes the following:
52
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
Following are the coding rules for the step name: //STEP1 EXEC
Notes:
Examples:
The step name LA$JOE is acceptable because it fits all the requirements defined in the rules for coding a
step name( the $ is one of the national symbols).
However, STEP#FOUR is not a valid step name because it contains more than eight characters.
53
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
The parameter field follows the EXEC operator and may contain multiple parameters. The first parameter in an
EXEC statement is a positional parameter that designates the program or procedure the system executes
during the jobstep.
This positional parameter is often coded like a keyword parameter using either PGM= or PROC=.
PGM= designates a program the system executes during the job step.
PROC= designates a procedure the system executes.
If you omit the PGM= or PROC= keyword, the operating system automatically looks for a procedure by the
specified name
Positional
Parameter
Notes:
PGM= designates a program the system executes during the job step. Shown here is the syntax of PGM
as a positional parameter in the EXEC statement.
PROC= designates a procedure the system executes. The syntax of PROC as a positional parameter in an
EXEC statement.
If you omit the PGM= or PROC= keyword, the operating system automatically looks for a procedure by
the specified name
54
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
Notes:
JCL errors occur if you, as a JCL programmer fail to follow any of the coding rules regarding the PGM
and PROC positional parameters.
For example, the misspelling of PGM (as PGR) in the EXEC statemen returns a JCL error.
55
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
Keyword Parameters
You may code keyword parameters on the EXEC statement in any order, following the program or
procedure name being executed.
The two keyword parameters used most frequently with the EXEC statement are:
• The PARM parameter
• The COND parameter ACCT
RD
DYNAMNBR
ADDRSPC
PGM=PROGA,keyword PERFORM
REGION
PARM
COND
TIME
DPRTY
CCSID
Notes:
You can use any of the keyword parameters shown here on the EXEC statement.
If you code one of these keyword parameters on the EXEC statement, the keyword parameter value will
apply only to that step.
56
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
The PARM parameter passes information to the executing program. Some programs accept information from
the PARM parameter about how many times to execute.
Examples
//JOB1 JOB 766,SMITH
//RUN#2 EXEC PGM=REPORT,
// PARM=MONTHLY
Notes:
The PARM parameter passes information to the executing program. Some programs accept information
from the PARM parameter about how many times to execute.
For example, a program may need to know whether a report cycle is "annual" or "monthly".
The records the program uses vary depending on which value is passed to it.
Similarly, the PARM parameter can supply a password to the program that is required before the program
executes.
Rules for Coding the PARM Parameter
The general syntax and rules for coding the PARM parameter are:
The PARM parameter can include up to 100 characters
The PARM parameter can consist of several subvalues separated by commas.
Subparameters must be enclosed in parentheses or apostrophes
Special characters must be enclosed in apostrophes
Example 1 (slide):
This EXEC statement passes one value (MONTHLY) as input to a program named REPORT.
57
Example 2 (slide):
This EXEC statement passes the date (10-31-98) as input to the program called REPORT. The
subparameter is enclosed in apostrophes because special characters are used.
Example 3 (slide):
In this example, the EXEC statement passes both the type of report (MONTHLY) and the date (10-31-98)
as subparameters of the PARM parameter. The two subparameters are enclosed in parentheses.
58
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
To provide control over the whole job, you can code the condition (COND) parameter on the JOB statement.
The syntax for the COND is:
COND=(code,operator[,stepname][.procstepname])
When you use the COND parameter on an EXEC statement, the parameter specifies the conditions
that allow the system to bypass a step by testing return codes from any or all previous steps.
If the result of any test is true, the system will bypass the step.
Like the JOB statement COND parameter, each test in an EXEC statement COND parameter has
its own operator. This operator is independent of any other operators in any other tests.
GT Greater than
GE Greater than or equal to
EQ Equal to
NE Not equal to
LT Less than
LE Less than or equal to
Notes:
As on the JOB statement, the code subparameter indicates a return code, and the operator subparameter
indicates the type of test used for the comparison.
What happens if you specify only the code and operator subparameters?
If you specify only the code and operator subparameters, the test runs for all previous return codes in the
job.
The stepname.procstepname subparameter (instead of the stepname subparameter) compares a code value
against the return code from a specific previous procedure job step.
The actual return code value, which may range from 0 to 4095, is compared with the return code specified
in the COND parameter.
You can code up to eight comparisons. If any comparison is true, the system bypasses the step.
59
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
//DD1 DD DSN=INPUT
// COND=(8,GT,EXAMPLE2) "If the return code from step EXAMPLE2 is less than 8,
//DD1 DD DSN=INPUT then bypass step EXAMPLE3."
Notes:
60
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
The EVEN subparameter allows the current step to execute even if any previous step terminates abnormally.
Conversely, the ONLY subparameter allows the current step to execute only if any previous step terminates
abnormally.
Program STEP3 always executes, even if a previous step (e.g. STEP2) in the job terminates abnormally.
Program STEP3 will execute only if a previous step in the job terminates abnormally.
Notes:
In addition to code, operator, stepname, and procedure stepname, the EVEN and ONLY subparameters
may also be coded on the COND parameter.
These subparameters do not apply to condition codes returned by a program after normal termination.
They relate to abnormal termination of a prior step. Abnormal termination occurs when unexpected
conditions arise during execution of a step.
Without the use of EVEN or ONLY, a job bypasses all remaining steps following an abnormal program
termination.
The EVEN and ONLY subparameters cannot appear on the same step. They are mutually exclusive.
However, EVEN or ONLY can be coded in place of one of the eight return code test allowed for each
step. The order in which tests are coded does not matter.
Example EVEN:
//JOB1 JOB 778,SMITH
//EXAMPLE1 EXEC PGM=STEP1
//EXAMPLE2 EXEC PGM=STEP2
//EXAMPLE3 EXEC PGM=STEP3
//EXAMPLE4 EXEC PGM=STEP4,
If you code COND=EVEN on an EXEC statement as shown here, the program STEP4 always executes,
even if a previous step (e.g. STEP3) in the job terminates abnormally.
61
Example ONLY:
//JOB1 JOB 778,SMITH
//EXAMPLE1 EXEC PGM=STEP1
//EXAMPLE2 EXEC PGM=STEP2
//EXAMPLE3 EXEC PGM=STEP3
//EXAMPLE4 EXEC PGM=STEP4,
// COND=ONLY
//DD1 DD DSN=INPUT
If you code COND=ONLY on an EXEC statement as shown here, the program STEP4 will execute only
if a previous step in the job terminates abnormally.
62
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
Program Libraries
In a job, each job step beings with an EXEC statement //RUN31 JOB 777,CLASS=B
that identifies a program name. In order to run the
program in the EXEC statement, the system searches //STEPA EXEC PGM=REPORT
for it in program libraries.
CSV003I REQUESTED MODULE REPART NOT
In the example, the programmer wanted to execute a FOUND
program called REPORT and coded the JCL as shown. CSV028I JOBNAME=RUN31 STEPNAME=STEPA
Notes:
In the example, the programmer wanted to execute a program called REPORT and coded the JCL as
shown.
The operating system searches SYS1.LINKLIB or LINKLIST for REPART. The error messages shown
occur because REPORT was misspelled as REPART in the JCL
In a job, each job step beings with an EXEC statement that identifies a program name. In order to run the
program in the EXEC statement, the system searches for it in program libraries.
It will search one or more system program libraries automatically or you can direct the system to search
for the program in a private program library.
The operating system searches SYS1.LINKLIB or LINKLIST for REPART. The error messages shown
occur because REPORT was misspelled as REPART in the JCL
63
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements
The JOBLIB DD statement causes the system to search a private library for all programs before
searching SYS1.LINKLIB.
//JOB1 JOB 776,SMITH
//JOBLIB DD DSN=LIBRARY,DISP=SHR
//STEP1 EXEC PGM=MYPROG1
//STEP1 EXEC PGM=MYPROG2
The STEPLIB DD statement makes more sense to direct the system to search a private library on a
step-by-step basis.
//STEP1 EXEC PGM=PROGA
//STEPLIB DD DSN=MYLIB,DISP=SHR
//*
//STEP2 EXEC PGM=PROGB
//STEPLIB DD DSN=MYLIB,DISP=SHR
If a STEPLIB and JOBLIB DD statement both appear in a job, the system ignores JOBLIB
Notes:
64
What if a STEPLIB and JOBLIB DD statement both appear in a job?
In this case the STEPLIB DD statement overrides the JOBLIB statement. The system ignores JOBLIB
and it does not search it in the step. It starts search only with the step library.
Example:
//JOB1 JOB 777,SMITH
//JOBLIB DD DSN=USER1
//STEP1 EXEC PGM=MYPROG
//STEPLIB DD DSN=LIBRARY,
// DISP=SHR
Just like a JOBLIB DD statement, the STEPLIB DD statement searches a private library for a specified
program, but the STEPLIB DD statement is in effect only for the duration of the step it follows.
If the system does not find the program in library specified by the STEPLIB DD statement, it searches the
system libraries (SYS1LINKLIB and LINKLIST) next.
If it does not find the program there, the job step terminates abnormally.
Example:
//JOB1 JOB 777,SMITH
//STEP1 EXEC PGM=PROGA
//STEP2 EXEC PGM=MYPROG
//STEPLIB DD DSN=LIBRARY,
// DISP=SHR
//STEP3 EXEC PGM=PROGB
When executing STEP1, the system will search in SYS1.LINKLIB and LINKLIST for PROGA.
But when executing STEP2, the system will look first in the private library named LIBRARY for
MYPROG, ignoring SYS1.LINKLIB and LINKLIST. If it does not find MYPROG in LIBRARY it will
search in SYS1.LINKLIB and LINKLIST.
And in STEP3 the system will look for PROGB in SYS1.LINKLIB and LINKLIST but not in LIBRARY.
65
Unit 5
Coding DD Statements
66
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The DD statement
Each data set used or created in a job step requires a separate DD statement.
//ddname DD parameter(s)
The DD statement identifies the basic information about a data set including:
Exemple:
//MYJOB JOB
//STEP1 EXEC PGM=PAYROLL
//PAY DD DSN=WEEKPAY1
Notes:
Example:
The PAYROLL program might specify a DDNAME of PAY for the weekly payroll data set. The program
uses DDNAME PAY to point to the data set for input to the payroll program.
If the payroll data set for that week is WEEKPAY1, then the JCL might appear as
//MYJOB JOB
//STEP1 EXEC PGM=PAYROLL
//PAY DD DSN=WEEKPAY1
67
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The format for coding a DDNAME in a program depends on the language in which the program is
written.
The way the DDNAME is coded is different in COBOL, PL/1, and Assembler. In the example the
DDNAME used is DD1.
COBOL
SELECT FILEIN ASSIGN TO DD1
PL/1 //MYJOB JOB
//STEP1 EXEC PGM=PAYROLL
READ FILE(DD1)
//DD1 DD DSN=WEEKPAY1
Assemble
r
FILEIN DCB DDNAME=DD1,...
Notes:
The ASSIGN clause in the Environment Division of the COBOL program identifies the DDNAME that
must be used in the DD statement.
68
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
DD Statement Parameters
Notes:
69
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
//DATA1 DD DSN=&&FIRST
or
//DATA1 DD (all needed parameters except DSN parameter)
It can be saved and reused after the job has completed. Non-temporary data sets must be
given a data set name. Syntax:
//DATA2 DD DSN=SECOND
Notes:
70
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The data set disposition parameter (DISP) specifies the current status of a data set and tells the
system which method to use for handling the data set after the job step terminates.
Notes:
For example, the DISP parameter can tell the system to delete a temporary data set at the end of a job or
save a non-temporary data set. The DISP statement can also setup a data set to be shared or passed to
another job, cataloged in a library, or used to create a new data set.
71
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The I/O UNIT parameter is used to request the type (or group) of hardware device(s) used to
store or access a data set.
//DATA2 DD UNIT=3390
Device
//DATA2 DD UNIT=SYSDA
Group
Notes:
Using the UNIT parameter, you can specify a particular tape drive, printer, or DASD device based on its
hardware address, device type or group name.
Interaction with I/O devices can be accomplished by specifying its:
Hardware address
Device type
Group name
72
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The Volume (VOL) parameter is used to indicate the specific media volume a tape data set has to
access.
A media volume might be a specific tape volume named ACCT01 or specific disk pack named
TSO001.
//INPUT DD DSN=MYTAPE,
// UNIT=TAPE,
// VOL=SER=ACT001
//INPUT DD DSN=ABC,
// UNIT=DISK,
// VOL=SER=TSO001
Notes:
A media on a storage device such as a tape reel or a Direct Access Storage Device (Disk unit) is called a
volume.
73
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
By using the SPACE parameter the required amount of space for a data set can be allocated.
SPACE= ({TRK,}(primary-qty[,second-qty][,directory])[,RLSE])
{CYL,}
//DATA1 DD DSN=FIRST,
// DISP=(NEW,CATLG),
// UNIT=SYSDA,
// SPACE=(TRK,(10,20),RLSE)
Notes:
74
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The Data Control Block (DCB) parameter is used during execution to complete information in the
program's data control block for a data set.
The DCB parameter identifies the type, block size, and length of records in a data set:
• LRECL=bytes Used to specify the size of the registers for a new data set.
• BLKSIZE=bytes Used to specify the maximum size of a block in bytes.
• RECFM = parameter Used to specify the format and the characteristics in the new data set.
• DSORG=organization Specifies the organisation for a data set
//DATA1 DD DCB=(RECFM=FB,
// LRECL=80,BLKSIZE=6400)
//DATA2 DD RECFM=FB,DSORG=PO,
// LRECL=80,BLKSIZE=6400)
Notes:
RECFM = parameter Used to specify the format and the characteristics in the new data set.
F fixed size
FB blocked fixed size
V variable size
VB blocked variable size
75
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
The output stream, or SYSOUT data set, is the data set that contains the results of a job to be
printed.
The SYSOUT parameter specifies a system output data set and its output class.
The DD statement routes the output to a printer of the specified output class.
The output class can be any alphanumeric character (A-Z, 0-9) or an asterisk.
//DATA1 DD SYSOUT=A
Notes:
The output class in an installation can be used for printing on special forms or for high-volume and high-
priority output.
The asterisk tells the system to use the same class as the MSGCLASS parameter in the JOB statement.
76
z/OS MVS JCL – Unit VI
Unit: Using Special DD Statements Topic: Dummy Data Sets
A dummy data set is a data set for which all Input or Output (I/O) operations are bypassed.
A special DD statement, DD DUMMY, is used to ignore a data set during the execution of a program.
When a data set is assigned dummy status, all I/O operations are bypassed and device allocation, space
allocation and data set disposition are ignored.
Dummy data sets can be specified in DD statements by doing one of the following:
//ddname DD DUMMY
• Coding DSN=NULLFILE
//ddname DD DSN=NULLFILE
Notes:
Each data set that is referred by a program should have a ddname. The JCL for the program must contain
the corresponding DD statements.
If a data set is not coded by a DD statement, then the program will abnormally end (ABEND) as shown.
When an input data set is optional for the program’s processing or when an output data set is not required
dummy data sets can be used.
77
z/OS MVS JCL – Unit VI
Unit: Using Special DD Statements Topic: Concatenating Data Sets
A programmer can code DD statements to request that several data sets be concatenated.
Data set concatenation enables the system to process several separate physical data sets as one logical
data set.
//ddname DD DSN=JAN.DATA
// DD DSN=FEB.DATA
// DD DSN=MAR.DATA
Notes:
Consider a cost ledger system to produce a monthly cost summary file. At the year end, it is required to
process all 12 monthly data sets to produce an annual report. All the data sets are concatenated so that
they can be processed sequentially.
In this example, the program uses a ddname of LEDGER and the monthly data sets are named JAN,
FEB, MAR and so on.
The operating system draws the concatenated data sets sequentially, treating them as a single logical data
set.
How concatenation is useful?
Using concatenation, a program can be run with one or several input data sets by merely changing the DD
statement.
While concatenating data sets the following points must be considered:
The concatenated data sets must have the same (or compatible) DCB subparameters. Namely,
RECFM, LRECL and BLKSIZE.
A maximum of 255 sequential and 16 partitioned data sets can be concatenated.
78
z/OS MVS JCL – Unit V
Unit: Using Special DD Statements Topic: Using Backward Reference
Backward Reference
It is a technique that directs the system to copy parameter values from preceding DD statements. Syntax:
Notes:
79
Example:
//LKED EXEC PGM=LINKEDIT
//SYSLMOD DD DSN=&&GOSET(GO),
// DISP=(NEW,PASS)
//STEPA EXEC PGM=*.LKED.SYSLMOD
Example:
//STEP1 EXEC PGM=PROG1
//DD1 DD SPACE=(TRK0,(200,20,2)),
// DISP=(NEW,PASS),DSN=WEEK1
//STEP2 EXEC PGM=PROG2
//DD2 DD DSN=*.STEP1.DD1,DISP=OLD
Consider a payroll job consisting of several steps, all referring to the same data set. The job needs to be
executed each week using a data set that contains the week’s transactions.
This requires that, each week the data set name must be changed in the order WEEK1, WEEK2 and so
on.
By using a DSN backward reference, the data set can be retrieved each week by changing only one DD
statement, DD1.
80
VOL Backward Reference:
The VOL backward reference is useful when you want to create a new data set on the same volume on
which an existing data set resides, but you do not know the volume identification.
A VOL backward reference is a coding technique that points to the volume serial number of an existing
data set.
The general form of the VOL backward reference is shown below:
//ddname DD VOL=REF=dsname
Example:
//STEPA EXEC PGM=PROGA
//DD2 DD DSN=ABC,VOL=SER=123456,
// DISP=SHR,UNIT=SYSDA
//DD1 DD DSN=XYZ,
// DISP=(NEW,CATLG),
// VOL=REF=*.DD2,…
In this example the backward reference refers to a specific volume serial number coded on a prior DD
statement.
The data set XYZ will be created on the volume referred to by the DD statement DD2 (volume 123456).
81
For example, notice the DCB characteristics in statement DD1 below:
//STEP3 EXEC PGM=PROG3
//DD1 DD DCB=(RECFM=F,BLKSIZE=800),…
//DD2 DD DCB=(*.DD1,RECFM=FB,LRECL=80)
//DD2 DD DCB=(RECFM=FB,
// LRECL=80,BLKSIZE=800)
82
z/OS MVS JCL – Unit VI
Unit: Using Special DD Statements Topic: Storage Dumps
Storage Dumps
Notes:
When a program abnormally terminates, the user can often find clues to the reason for the ABEND in the
contents of the computer’s storage.
These reserved ddnames request storage dumps in the event that a program terminates abnormally:
Special DDnames
SYSUDUMP: Requests a formatted dump of the processing program area. It is most generally
used for debugging problem programs.
SYSABEND: Requests a formatted dump of the processing program area, system programs and
the system control blocks. It is often spooled for printing, although it may be written onto any
output device.
SYSMDUMP: Requests an unformatted dump of the processing program area and the system
nucleus in machine-readable form. It is generally directed to tape (or to direct access storage) to
allow subsequent processing by a dump analysis utility.
83
z/OS MVS JCL – Unit V
Unit: Coding DD Statements
SMS Considerations
A Storage Management Subsystem (SMS) may be an optional facility at the installation. When
installed and active, the SMS manages many data sets within the installation.
If the SMS is active, the storage administrator at the installation decides which data sets it manages.
Notes:
For instance, SMS may decide which units and volumes are to be used for newly created data sets, freeing
you from coding UNIT and VOLUME on DD statements.
In general existing JCL continues to perform correctly with SMS installed and activated. SMS provides
the benefit of data class, management class and storage class constructs without necessarily changing
existing JCL.
Installation-defined Automatic Class Selection (ACS) routines can be used to select appropriate
characteristics for data sets, eliminating the necessity of coding some JCL parameters.
The characteristics of SMS include:
SMS can manage:
Physical Sequential (PS) data sets
Partitioned Data Sets (PDS)
Partitioned Data Sets Extended (PDSE)
Virtual Storage Access Method (VSAM) data sets
SMS does not manage tape or SYSOUT data sets
SMS supplies default information and simplifies JCL coding for data sets it manages
84
Unit 6
Conditional Processing
85
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct
Relational-Expression
Field
Notes:
86
What is the Operation Field?
The operation field contains the operators IF, ELSE, or ENDIF.
ELSE statement
Following the ELSE statement are all the JCL statements to be executed when the relational-expression is
false. If there are none, then the ELSE statement can be omitted.
The ELSE statement has no parameters. Anything following the ELSE operator is considered a comment.
ENDIF statement
The required ENDIF statement signifies the end of the IF/THEN/ELSE/ENDIF statement construct.
There must be at least one EXEC statement following either the IF statement or the ELSE statement.
Anything coded after the ENDIF statement is considered a comment by the operating system.
THEN clause
The THEN clause in an IF/THEN/ELSE/ENDIF statement construct contains the JCL statements that
exist between the IF/THEN statement and either:
A corresponding ELSE statement (if one is specified) or A corresponding ENDIF statement
The purpose of the THEN clause is to provide a route of execution if the condition specified in the
IFstatement tests true. If no JCL statements are specified, then the THEN clause becomes a null THEN
clause.
Relation Expression
A relational-expression can consist of any of the following, alone or in combination:
Comparison operators
Logical operators
NOT operators
87
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct
Comparison Operators
Comparison operators compare a relational-expression keyword to a numeric value. The result of the
comparison is either true or false.
Operator Meaning
Notes:
The use of parentheses in the relational-expression is optional, but it is useful when coding combinations
of expressions.
The comparison operators are either alphabetic or arithmetic
In the example, the statement tests if a return code is equal to 8.
The relational-expression (RC=8) must be both preceded and followed by at least one space.
No spaces are required before or after an arithmetic operator, such as = or >.
At least one space is required both before and after alphabetic comparison operators, such as EQ or GT
88
z/OS MVS JCL – Unit VII
Unit: Conditional Processing Topic: IF/THEN/ELSE/ENDIF Construct
• The AND (&) operator returns a value only if both relational-expressions are true.
• The OR (|) operator returns a true value if either of the relational-expression is true.
• The NOT (¬) operator reverses the testing of a relational-expression. The system evaluates the NOT
operator before any comparisons or logical operators.
Notes:
89
z/OS MVS JCL – Unit VII
Unit: Conditional Processing Topic: IF/THEN/ELSE/ENDIF Construct
Relational-Expression Keywords
Relational-expression keywords are used to test a return code, abend condition or abend completion code, or
to test if a step began executing. The relational-expression keywords are:
• RC
• ABEND
• ¬ ABEND
• ABENDCC
• RUN
• ¬RUN
Preceding the keyword with a step name relates the expression to a specific job step.
Syntax: stepname.keyword
Notes:
Preceding the keyword with both a step name and procedure step name relates the expression to a specific
procedure step.
90
z/OS MVS JCL – Unit VII
Unit: Conditional Processing Topic: IF/THEN/ELSE/ENDIF Construct
Relational-Expression Keywords RC
RC represents the highest return code received from a previous job step.
Notes:
In the example, the first statement checks if the previous job step had a return code greater than 4.
The second statement tests if a prior job step named COMPILE produced a return code greater than 4.
The third one checks if a specific procedure, PROG1 in the job step COMPILE, produced a return code
greater than 4.
91
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct
The keyword ABEND tests for abnormal termination from any previous job step. Syntax used for ABEND:
The keyword ¬ABEND will test to ensure an abnormal termination did not occur in any of the
previous steps. The syntax is:
Notes:
Keywords ¬ABEND To check that a specific step did not result in an abnormal termination
¬stepname.ABEND
or stepname.ABEND = FALSE
To check that a specific procedure step did not result in an abnormal termination
¬stepname.procstepname.ABEND
or stepname.procstepname.ABEND = FALSE
Both formats can be preceded with a step name or procedure step name to ensure that abnormal
termination did not occur in specific job steps or procedure steps
92
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct
The relational-expression keyword ABENDCC tests for a specific system abend completion code or user
defined abend completion code from any previous job step.
Example
Notes:
The character S in the first expression indicates an abnormal system completion code, and the xxx
represents the three digit hexadecimal abend code.
The U in the second expression indicates an abnormal user-defined completion code, and the xxxx
represents the four digit hexadecimal abend code.
To test the abend code from a specific step
stepname.ABENDCC = Sxxx
stepname.ABENDCC = Uxxxx
To test the abend code from a specific procedure step
stepname.procstepname.ABENDCC = Sxxx
stepname.procstepname.ABENDCC = Uxxxx
Both formats can be preceded with a step name or procedure step name to test the abend code from
specific job steps or procedure steps.
In the example, The first statement tests for an abnormal system completion code of 0C1 in the previous
job step.
The second statement tests for an abnormal user-defined completion code of U0100 in a prior job step
named RUNPGM in the previous job step.
93
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct
The keyword RUN tests to make sure that a specific job step or procedure step has been executed. Syntax:
• //name IF stepname.RUN THEN
or
• //name IF stepname.RUN = TRUE THEN
The keyword ¬RUN tests to see if a specific job step or procedure step failed to execute. Syntax:
• //name IF ¬stepname.RUN THEN
or
• //name IF stepname.RUN = FALSE THEN
Notes:
A step name or both step name and procedure step name must precede the RUN or ¬RUN keywords.
To test if a specific procedure step has been executed
//name IF stepname.procstepname.RUN THEN
In the example, the ¬RUN keyword tests if a step called LINK did not execute:
94
z/OS MVS JCL – Unit VII
Unit: Conditional Processing Topic: IF/THEN/ELSE/ENDIF Construct
Example 1
To illustrate the working of the THEN clause consider the following JCL code:
Example 2
To illustrate the working of the ELSE clause consider the following JCL code:
Notes:
Example 1.
The THEN clause contains one JCL statement named ERROR. The program DELFILES, specified in the
ERROR EXEC statement, will not execute unless the return code from any previous step is greater than
or equal to 8.
Irrespective of the value of the return code, the program IEBCOPY specified in STEP2 will run as it is
not part of the IF/THEN/ELSE/ENDIF statement construct.
Example 2.
The THEN clause contains one JCL statement named GOOD. The Program CREATE, specified in the
GOOD EXEC statement, will not be executed unless STEP1 has been executed successfully.
If STEP1 failed to execute, then a program DELFILES (specified in the statement named ERROR) will
be executed as it is contained under the ELSE clause.
Irrespective of whether STEP1 was executed successfully or not, the program COMPRESS specified in
STEP2 will run as if it is not part of the IF/THEN/ELSE/ENDIF statement construct.
95
z/OS MVS JCL – Unit VII
Unit: Conditional Processing Topic: Nesting Conditional Constructs
In a nested conditional construct the THEN clause or the ELSE clause (or both) will contain an
additional IF/THEN/ELSE/ENDIF construct.
Each additional construct will have its own corresponding IF/THEN,ELSE and ENDIF statements.
Notes:
The example shows a nested conditional construct where the value of return code of a program
determines the next step.
In the outer IF/THEN/ELSE/ENDIF construct, the CHKCOMP statement checks to see if the return code
from the step named COMPPGM is less than or equal to 4.
If the COMPPGM return code is less or equal to 4, then the LNKPGM step runs.
Next the inner IF/THEN/ELSE/ENDIF construct is invoked, if the return code from LNKPGM step is
greater than 4, the DELETE program (in the DELPGM step) executes.
If the return code from LNKPGM is less than or equal to 4, step RUNPGM will be run.
Step COMPLIB will be executed regardless of any conditional testing.
96
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct
What is the advantage of using Conditional Processing over using the COND parameter?
Both the IF/THEN/ELSE/ENDIF statement construct and the COND parameter are used to conditionally
control the execution of job steps.
It is always recommended to use the IF/THEN/ELSE/ENDIF statement construct for conditional testing as it is
easier to read and understand compared to the COND parameter.
Notes:
97
Unit 7
Procedures
98
z/OS MVS JCL – Unit VII
Unit: Procedures - Introducing
Procedures
A procedure is a pre-coded set of JCL statements (may consist of one or more job steps) with a unique name.
JCL statements that are used by several users or used repeatedly are placed in a procedure. Use of
procedures not only saves time but also avoids errors.
Example:
//PROCA PROC
//PSTEP1 EXEC PGM=MYPROG
//DDIN DD DSN=INDATA,DISP=SHR
//DDOUT DD SYSOUT=A
//PSTEP2 EXEC PGM=PROG1
//DD1 DD DSN=DATA1,DISP=SHR
//DD2 DD SYSOUT=A
// PEND
Notes:
In the example shown, the name of the procedure (PROCA) is the name on the EXEC statement.
The COMMENT statement (/ /*) can also be included at any appropriate place to aid in documenting the
procedure.
99
z/OS MVS JCL – Unit VII
Unit: Procedures - Introducing
Cataloged Procedure: are stored as members of a partitioned data set that is used as a
procedure library. When a cataloged procedure is used, its JCL is taken from the default procedure
library, or a user-specified procedure library:
MYLIB.PROCS
//EXAMPLE JOB ……
//MYLIBS JCLLIB ORDER=MYLIB.PROCS MYPROC
//PSTEP1 EXEC PROC=MYPROC
In-Stream Procedures: are placed along with the job in the input stream
Notes:
Cataloging
Once an in-stream procedure is tested, it can be cataloged for general use. Cataloging means storing it in a
procedure library (PDS) using a utility program.
Once an in-stream procedure has been cataloged, the EXEC statement that invokes this procedure refers
to it by its member name in the procedure library.
100
Invoking a Procedure
To invoke the procedure PROCA the following statement can be used:
//JSTEP1 EXEC PROC=PROCA
In another way of invoking a procedure, the programmer can omit PROC= in the EXEC statement. In this
format only procedure name is given.
In the example considered, the procedure PROCA can also be invoked in the following way:
//JSTEP1 EXEC PROCA
To invoke a procedure the keyword parameter PROC= can be used before the procedure name or it can be
omitted.
However, to invoke a program, the keyword parameter PGM= must be used before the program name.
When a cataloged procedure is used, its JCL is taken from the default procedure library, or a user-
specified procedure library. You can specify other procedure libraries with the JCLLIB statement:
//[name] JCLLIB ORDER=(library[,library]...)
In-Stream Procedures
In-stream procedures are identical to cataloged procedures, except that they are placed along with the job
in the input stream. When the procedure is invoked, the JCL in the procedure definition is inserted at the
invocation point in the job stream itself.
If a procedure is just created and has to be tested for errors, an in-stream procedure can be used.
An in-stream procedure can be identified by the statements PROC and PEND
An in-stream procedure definition can be included anywhere within a job stream following the JOB
statement, but it must precede the EXEC statement that invokes the procedure.
Generally, the definitions for an in-stream procedure are placed at the beginning of the job stream.
The following points must be considered while using an in-stream procedure:
The JCL for an in-stream procedure is defined with the job stream itself.
In-stream procedures begin with a PROC statement and are terminated by a PEND statement.
The in-stream procedure is placed following the JOB statement but before the first EXEC
statement.
The JCL of an in-stream procedure is merged into the executable portion of the job when an
EXEC statement invokes the procedure.
When to use an in-stream procedure?
If a procedure is just created and has to be tested for errors, an in-stream procedure can be used.
101
z/OS MVS JCL – Unit VIII
Unit: Introducing Procedures
Nested Procedure
Notes:
102
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying EXEC Parameters
Coding Changes
Changes can be made to procedure EXEC statement parameters such as TIME, COND, and PARM:
Override
Nullify Syntax: //JSTEP EXEC procedurename,
Add // parameter.procstepname=value
Notes:
It is possible to use EXEC statement overrides, nullifications, and additions for one or more procedure
steps at the same time. This can be done by combining the changes on the EXEC statement that invokes
the procedure.
A procedure listing helps a programmer to analyze the procedure for its usability. In some cases a
procedure might satisfy all the basic requirements for usability, but might need some minor alterations.
This can be done by changing the EXEC and DD parameters when the procedure is invoked.
However, these alterations are applicable only for one invocation. They do not permanently modify the
procedure definition.
Changes can be made to procedure EXEC statement parameters such as TIME, COND, and PARM.
The programmer can change these parameters in the following ways:
Override the parameters on the procedure EXEC statement
Nullify parameters on the procedure EXEC statement
Add parameters to the procedure EXEC statement
For example, the programmer can change the time restrictions and can also supply the current date for a
particular PSTEP.
103
The following rules must be followed while sequencing multiple changes:
Specify alterations in procedure step sequence. The alterations for one step must be specified
before the alterations for a subsequent step.
Within any one step, alterations can be specified in any sequence.
Alterations should be separated from each other by a comma.
In the example (slide), note that the time that PROG1 can run is 1 minute 30 seconds.
Assume that for a particular week, the transaction file to be processed is too large and the time that
PROG1 can run needs to be increased to 3 minutes.
Note the new parameter in the resulting JCL.However, this override is only temporary. Theprocedure
definition does not change. The next time the procedure is invoked, it will revert to the original definition.
104
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying EXEC Parameters
A procedure can be modified by nullifying an EXEC statement parameter. The format for nullifying an EXEC
statement parameter is:
//JSTEP EXEC procedurename,
// parameter.procstepname=
Notes:
Most installations have values that are assigned to EXEC statement parameters automatically. For
example, a default value may be assigned for the TIME parameter.
The default values may be overridden when the procedure is defined. To return to the installation’s
default value, the programmer can code a statement that nullifies the parameter.
In the example, the procedure definition for PROG1 (in the procedure step PSTEP1) has specified a CPU
time of 1 minute 30 seconds for processing a transaction file. This processing time may not be adequate
for a larger file.
If the default time is adequate, the programmer might want to execute the procedure taking the system
default time for PROG1.
To do this, the programmer needs to nullify the TIME specified in the procedure definition on the
PSTEP1 EXEC statement.
The following EXEC statement which invokes procedure would nullify the time parameter:
//JSTEP1 EXEC TRANSACT,TIME.PSTEP1=
The resulting JCL is shown on the right.
105
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying EXEC Parameters
Addition statements are used to add parameters to a procedure. The programmer can code additions on the
EXEC statement that invokes the procedure.
Notes:
106
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying EXEC Parameters
Notes:
107
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters
If the specifications are not what are needed for a job, changes to the DD statement parameters can be made
at the time of procedure execution.
Some of the changes to the DD statement parameters that can be accomplished at the time of execution
include:
//procstepname.ddname DD parameter=value
Notes:
To change the DD statement parameter when invoking a procedure, the DD statement must be coded
immediately following the EXEC statement.
The DD statement has a two-part name. It consists of the name of the procedure step in which the DD
statement to be changed occurs, followed by a period and the name of the DD statement in the procedure
step.
The parameter to be changed, added or nullified is specified after the keyword DD, followed by an equal
sign and the value of the parameter.
Any number of override and addition DD statements can be coded to invoke a procedure.
The rules for coding multiple parameters are:
Code the EXEC statement to invoke the procedure
Code the override statements (if any) for a step in the same ddname sequence as in the procedure
definition
Code addition DD statements (if any) for that step, following the override statements
Within each procedure step, the override statements must be coded in ddname sequence
To facilitate override sequencing some installation require that DD statements in procedure steps be in
alphabetical order by ddname
108
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters
When the DD statement parameters that already exist in the procedure definition are not what you want for a
particular job execution, you can code an override DD statement.
To override the DD statement parameters, the existing DD statement parameters in the procedure step need
to be explicitly changed or nullified or a mutually exclusive parameter must be coded.
Procedure TRANSACT
Notes:
When coding an override DD statement, the following considerations must be kept in mind:
Code the override DD statement immediately following the EXEC statement used to invoke the
procedure
Supply a name for the override DD statement consisting of the name of the procedure step in
which the DD statement to be overridden occurs, followed by a period and the name of the DD
statement in the procedure step
Specify on the DD statement (in any sequence) the keyword parameters whose values are to be
changed or nullified, separated by commas
The code alongside shows the TRANSACT procedure definition.
The DD statement parameter that is to overridden is highlighted.
The code alongside shows the EXEC statement used to invoke the TRANSACT procedure.
The override DD statement is coded immediately after the EXEC statement, specifying the procedure step
containing the DD statement and name of the DD statement in the procedure, the new data set’s name,
and its location.
The code shows the resulting JCL statement.
The data set to be used during execution has been changed to NEWTRAN.
In this example, you will see that the parameter DISP=SHR, specified for DD1 in the procedure
definition, is retained.
109
Example (slide):
In the TRANSACT procedure, the input transactions are specified in a data set named INTRAN.
A particular week’s input transactions reside in a data set named NEWTRAN.
NEWTRAN is an uncataloged data set that resides on a 3390 direct access volume whose volume
identifier is 12345.
In order to use the existing TRANSACT procedure to process that week’s transactions a DD override
statement that identifies NEWTRAN, rather than INTRAN, as the name of the transaction data set must
be coded.
The override DD statement is as follows:
//PSTEP1.DD1 DD DSN=NEWTRAN,
// UNIT=3390,
// VOL=SER=12345
110
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters
To return the value of a DD statement parameter to the system default, the parameter must be nullified.
To nullify a DD statement parameter, you give the name of the parameter followed by the equal sign:
//procstepname.ddname DD parameter=
Procedure TRANSACT
//PSTEP1 EXEC PGM=PROG1,TIME(1,30)
//DD1 DD DSN=NEWTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR,
// UNIT=3480,VOL=SER=987762
//DD3 DD SYSOUT=A
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD5 DD DSN=MEWTRAN,DISP=SHR
Notes:
In this example assume the TRANSACT procedure definition identifies data set MASTER as an
uncataloged data set residing on a 3480 tape volume with a volume identifier of 987762.
For a particular week, a previous version of MASTER (whose location is recorded in the system catalog)
is required during the execution of TRANSACT.
An override DD statement to nullify the UNIT and VOL=SER parameters and referring to the
uncataloged MASTER data set would be coded as follows:
//procstepname.ddanme DD
// UNIT=,VOL=SER=
111
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters
//procstepname.ddname DD DUMMY
or
//procstepname.ddname DD DSN=NULLFILE
Procedure TRANSACT
//PSTEP1 EXEC PGM=PROG1,TIME(1,30)
//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR,
// UNIT=3480,VOL=SER=98762
//DD3 DD SYSOUT=A
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD5 DD DSN=&&VALID, //PSTEP1 EXEC PGM=PROG1,TIME(1,30)
// DISP=(OLD,DELETE) //DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DUMMY
//DD3 DD SYSOUT=A
//PSTEP2 EXEC PGM=PROG2,TIME=5
//STEP EXEC TRANSACT //DD5 DD DSN=&&VALID,
//PSTEP1.DD2 DD DUMMY // DISP=(OLD,DELETE)
Notes:
112
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters
Addition DD Statements
If a required data set is not found in the procedure definition then an additional DD statement can be coded
along with the invocation of the procedure.
Procedure TRANSACT
Notes:
113
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters
//DD1 DD DSN=MYDSET,DISP=SHR,DCB=(BLKSIZE=800,RECFM=FB)
//PSTEP1.DD1 DD DCB=(BLKSIZE=320)
//DD1 DD DSN=MYDSET,DISP=SHR,DCB=(BLKSIZE=320,RECFM=FB)
//DD3 DD DSN=MYDSET,DISP=SHR,DCB=(RECFM=FB,BLKSIZE=160,LRECL=80)
In order to nullify the entire DCB parameter of the DD statement, each DCB keyword subparameter
specifiedin the procedure definition must be nullified as shown below:
//PSTEP1.DD3 DD DCB=(RECFM=,BLKSIZE=,LRECL=)
Notes:
Some special rules apply when overriding or nullifying the DCB parameter.
Code only those DCB keyword subparameters whose values need to be changed. DCB keyword
subparameters which are not coded remain unchanged.
Code any required DCB positional subparameters regardless of whether or not they are specified on the
DD statement in the procedure definition.
To nullify an existing DCB positional sub parameter simply omit it from the DCB parameter given in the
override DD statement.
To nullify the DCB parameter completely, omit all existing positional subparameters and explicitly
nullify each existing keyword subparameter.
Positional subparameters (such as DSN) are essential to the system. These must be coded, even if they are
specified in the procedure definition.
Keyword subparameters (such as BLKSIZE) supply additional information to the operating system. If
they are specified in the procedure definition, then code only those that are to be changed.
In the example, if the block size and buffer length needs to be changed to 320 at the time of execution,
then the following override DD statement needs to be coded:
//PSTEP1.DD1 DD DCB=(BLKSIZE=320)
The values of the DSN and DISP parameters and RECFM subparameters remain unchanged.
114
Sequencing Multiple Parameters – An Example
Procedure TRANSACT:
• PROG1 obtains its input transactions from a cataloged data set named MYDATA, instead
of from INTRAN.
• PROG1 checks the contents of MYDATA against the contents of a second cataloged data
set named CKDATA. The PARM value of NOCHECK needs to be overridden with the
value CHECK, and a DD statement named DD2 to reference CKDATA has to added.
• PROG2 writes its output (using ddname DD6) to a data set named INVOICE on a 3390
volume with volume identifier 6929L. The data set requires 10 tracks of space and should
be cataloged.
115
Shorthand form of coding multiple override and addition DD statements can be used in the procedure step
sequence.
To code the shorthand form:
Follow the general form for the first override or addition statement
For subsequent override or addition statements in that procedure step use
//ddname DD ...
116
z/OS MVS JCL – Unit VII
Unit: Procedures - Symbolic Parameters
Symbolic Parameters
• Are preceded by an ampersand (&)
• Consist of up to seven alphanumeric (A to Z, 0 to 9) or national (#,@,$)
characters, beginning with an alphabetic or national character
• Can represent EXEC statement or DD statement parameters
The following statement assigns the value GRP50 to the &DEPT symbolic parameter:
//TRANSACT PROC
//JSTEP EXEC TRANSACT, //PSTEP1 EXEC PGM=PROG1,PARM=&DEPT
// DEPT=GRP50 //DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
Notes:
Symbolic parameters are preceded by a single ampersand, whereas temporary data set names are preceded
by two ampersands.
In the example, a symbolic parameter to represent an EXEC statement parameter is shown on the right.
Here the TRANSACT procedure is defined with a symbolic PARM parameter (&DEPT) for PROG1
(in PSTEP1) and PROG2 (in PSTEP2).
PARM=&DEPT
In this way, several different departments in the company can easily use the TRANSACT procedure.
Each department will simply provide its department number, for accounting purposes, when the
procedure is used.
The rules for assigning values to or nullifying DD statement parameters are:
Separate the value assignments or nullifications from parameters and from each other using comas.
Specify the symbolic parameter without the preceding ampersand, followed by an equal sign and value.
To nullify a symbolic parameter specify the symbolic parameter without the preceding ampersand,
followed by an equal sign. The value for the symbolic parameter should not be coded.
Symbolic parameters can be nullified or assigned values in any sequence.
An appropriate value that represents a data set name must be assigned to the symbolic parameter
If the symbolic parameter is not assigned a value, the system considers the symbolic parameter to be the
name of a temporary data set because it begins with the ampersand character
117
z/OS MVS JCL – Unit VII
Unit: Procedures - Symbolic Parameters
Notes:
For example, it is not possible to assign GRP50 to &DEPT in PSTEP1 and GRP100 to &DEPT in
PSTEP2 unless one of the following conditions exists:
A different symbolic parameter represents each occurrence of the parameter
An EXEC or DD statement override or addition statement is used when invoking the procedure
118
Assigning Different Values – Example 2
Here the procedure has been created without symbolic parameters:
//PSTEP1 EXEC PGM=PROG1
...
//PSTEP2 EXEC PGM=PROG2
At the time of invoking the procedure, an addition statement as shown on the right can be coded to assign
an PARM value of GRP50 for PSTEP1 and GRP100 for PSTEP2.
//JSTEP EXEC TRANSACT,
// PARM.PSTEP1=GRP50,
// PARM.PSTEP2=GRP100
119
z/OS MVS JCL – Unit VII
Unit: Procedures - Symbolic Parameters
The PGM parameter is the only EXEC statement parameter that cannot be modified with an
override statement when a procedure is executed.
Notes:
In the example, the TRANSACT procedure definition with symbolic PGM parameters for the PSTEP1
and PSTEP2 EXEC statements is shown.
The statements used to invoke the procedure and execute programs TEST1 and TEST2 would be:
//JSTEP EXEC TRANSACT,PROG1=TEST1,
// PROG2=TEST2
The statements used to invoke the procedure and execute programs TEST3 and TEST4 would be:
//JSTEP EXEC TRANSACT,PROG1=TEST3,
// PROG2=TEST4
120
z/OS MVS JCL – Unit VII
Unit: Procedures - Symbolic Parameters
Notes:
In the example, the PROC statement assigns the default value G300 to &DEPT and the default value
PROG2 to &PROG.
This would be useful if members of the same department (G300) were the primary users of the procedure
and the program executed in step PSTEP2 was usually PROG2.
121
z/OS MVS JCL – Unit VII
Unit: Procedures - Symbolic Parameters
• The default values specified in the PROC statement is not appropriate for that particular execution
of the procedure
• No default value is specified for the symbolic parameter on the PROC statement in the procedure
Notes:
In the example, the TRANSACT procedure is to be invoked with some input test data (DD1 DD
statement) that resides in a data set named TSTDATA and a test program named TESTPRG for step
PSTEP2.
Because this execution is a test, a department number need not be specified.
Thus, the default values G300 (specified for &DEPT) and PROG2 (specified for &PROG) are not
needed.
Nullifying the &DEPT in this example has same effect as omitting the symbolic parameter from the
procedure definition.
122