You are on page 1of 122

Unit 1

Introduction to JCL

At the end of this unit, you will be able to:

• Explain the purpose and syntax of the JOB statement


• Define the JOB name
• Code positional parameters and keyword parameters
• Code the most commonly used keyword parameters on a JOB statement
• Complete the JOB statement
• Code additional JOB statement parameters

1
z/OS MVS JCL – Unit I
Unit: Introduction to JCL

Job Control Language


What is 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

JCL provides information to the system about job details:


//JOB1 JOB 504,SMITH
//JOB1 JOB CLASS=A

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

A job consists of one or more individual job steps.

Each job step starts with an EXEC statement and


is associated with the execution of one program.

The data sets required for each job step can be


defined using a DD statement.

You then submit each job for processing as part


of the job stream

Notes:

5
z/OS MVS JCL – Unit I
Unit: Introduction to JCL

Defining Job Control Statements

Job control statements define jobs and job steps.

Job control statements are JCL statements //JOBNUM1 JOB 504,SMITH


created to provide the following information:

• Programs to be executed

• Sequence of program execution

//STEP1 EXEC PGM=PROGRAMA


• Data sets required by the programs

//DD1 DD DSN=INPUT

Notes:

What details do you have to specify for each job?


Each job requires you to specify at least the following:
 Job to begin (using a JOB statement)
 Program(s) to be executed (using EXEC statements)
 Data sets to be used (using DD statements)
You can also add a null statement to mark the end of a job and comment statements to document your
JCL statements.
Job control statements may provide other kinds of information as well. For example, a job control
statement can specify how the system should process a job by providing accounting information

6
z/OS MVS JCL – Unit I
Unit: Introduction to JCL

The JOB Statement

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.

//JOBNUM1 JOB 504,SMITH


//STEP1 EXEC PGM=PROGRAMA

//DD1 DD DSN=OUTPUT

//JOBNUM2 JOB 600,JONES

Parts of a Job

End of Job marker

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

The EXEC Statement


An EXEC statement often follows the JOB statement. It names a program to be executed.

Programs are stored in program libraries and retrieved by the operating system when they are
referenced by an EXEC statement.

Program
Library
PROGRAMA

INPUT //JOBNUM1 JOB 504,SMITH


//STEP1 EXEC PGM=PROGRAMA
//DD1 DD DSN=INPUT

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.

//JOBNUM1 JOB 504,SMITH


//STEP1 EXEC PGM=PROGRAMA
//DD1 DD DSN=OUTPUT
//DD2 DD DSN=INOUT

Data Sets

Notes:

By using a proper combination of options, DD statements may do the following:


 Give the data set name
 Specify the initial status and final disposition of the data set
 Specify volumes
 Specify record length, format, and blocking
 Request I/O devices
 Specify storage allocation for new data sets

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:

•Have to run sequentially


•Have the same job accounting information 10
01
•Are dependent on each other

INPUT
10
01

10
01 INOUT

OUTPUT OUTPUT
1 2

Notes:

Consider two programs:


Program A takes input from the INPUT data set and uses it to create the INOUT data set.
Program B uses the data set created by Program A as its input and creates two more data sets called
OUTPUT1 and OUTPUT2.
Can you group Program A and Program B?
Since these programs must run sequentially and Program B is dependent on Program A, they can be
grouped into a single job.

10
z/OS MVS JCL – Unit I
Unit: Introduction to JCL

Grouping Programs: An Example

//JOBNUM1 JOB 504,SMITH


//STEP1 EXEC PGM=PROGRAMA
//DD1 DD DSN=INPUT,
// DISP=SHR
//DD2 DD DSN=INOUT,
// DISP=(NEW,PASS)
//STEP2 EXEC PGM=PROGRAMB
//DD3 DD DSN=INOUT,
// DISP=(OLD,CATLG)
//DD4 DD DSN=OUTPUT1,
// DISP=(NEW,CATLG,DELETE)
//DD5 DD DSN=OUTPUT2,
// DISP=(NEW,CATLG,DELETE)

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

Other JCL Statements

Besides the JOB, EXEC and DD statements, there are some less frequently used JCL statements.
These include:

• Comment statements:

• Null statements:

//JOBNUM1 JOB 504,SMITH


//* COMMENTS CAN GO HERE
//STEP1 EXEC PGM=PROGRAM1
//DD1 DD DSN=TRANS1,
// DISP=OLD
//
Comment
statement

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

Identifier Name Operation Parameter Comment


Field Field Field Field Field

// JOBNUM1 JOB 501,SMITH COMMENT


1 2 3 71

Notes:

The Identifier Field


The identifier field occupies positions 1 and 2. It usually contains two forward slashes (//) and indicates
that the statement is a JCL statement (as opposed to a data record).
The remaining four fields must be coded from position 3 through position 71.
The Name Field
The name field must begin in position 3 with no spaces between the identifier and the name fields.
The name field identifies the JCL statement by name so that other JCL statements or the operating system
can refer to it.
A name is optional for some EXEC statements, but is required on JOB and almost all DD statements.
The Operation Field
The operation field defines the JCL statement type - JOB, EXEC, or DD.
For every JCL statement, the operation field must follow the name field and it must be preceded by at
least one blank space.

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

The Comment Field


A comment field contains extra documentation which you may choose to include. It contains
documentation relating to the code or other messages from the programmer.
A comment field must follow the parameter field and must be preceded by one or more blanks.

14
z/OS MVS JCL – Unit I
Unit: Introduction to JCL

Rules for Naming JCL Statements

The specifications for JCL statement names are as follows:

• The name must begin in position 3


• The name can be one to eight characters in length
• The first character in the name must be alphabetic character (A to Z) or national character (#, @, $).
• The first character cannot be numeric (0 through 9)
• The remaining characters can be alpha numeric (A to Z and 0 through 9) or national characters
• No special characters or spaces can be included in a name

//JOB1 JOB 504,SMITH


//STEP1 EXEC PGM=PROGRAMA
//DD1 DD DSN=INPUT,DISP=SHR

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

Rules for Writing JCL Statements

You should remember the following rules while writing a JCL statement:

• The identifying characters (//) must be in positions 1 and 2.

• The name field must begin in position 3.

• Each subsequent field must be preceded by one or more spaces.

• A continuation line begins with //.

• Continuing parameters must start in positions 4 through 16.

• Do not embed blanks within any field. For example, do not code a blank to separate parameters in
the parameter field.

• Do not code past position 71.

//STEP1 EXEC PGM=PROGRAM1,


// TIME=4

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

Operation Fields: An example

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

//JOB1 JOB 504,SMITH,


Parameter Fields: An Example // MSGLEVEL=(1,0)
//STEP1 EXEC PGM=PROGRAM1,
The JOB statement here contains parameters // TIME=4
specifying the following: //DD1 DD DSN=INPUT,DISP=SHR
• Accounting information (504)
• The JCL programmer's name (SMITH)
• MSGLEVEL (message level) parameter
Parameter Field

Notes:

Following are examples of three JCL statement


types with different operators:
• The first statement is therefore, a JOB statement, which marks the beginning of a job.
• The second statement is therefore, an EXEC statement, which marks the beginning of a job step
and specifies the program to be executed (PROGRAM1).
• The third statement is therefore, a DD statement, which identifies a data set that PROGRAM1
uses during processing.
Parameter Fields: An Example
The EXEC statement here contains two parameters:
The first one specifies the program name (PROGRAM1). The second one specifies the maximum CPU
time for the program (4 minutes)
The DD statement here has two parameters:
The first one specifies the data set name TRANS1
The second one specifies a status of OLD.

17
z/OS MVS JCL – Unit I
Unit: Introduction to JCL

Continuation statement: An Example

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

The following examples shows a JCL statement that contains:


A comment “INVENTORY JOB”. A blank separates the parameter field from the words INVENTORY JOB
A comment “TEST”. //* in the first 3 positions. The comment text is coded in positions 4 through 71.

//JOB1 JOB 504,KAY INVENTORY JOB


//* TEST

Notes:

You can continue a JCL statement on one or more separate lines.


When can a JCL statement be continued on more than one line?
A JCL statement may be continued on more than one line if:
The JCL statement requires more than 71 positions to specify all the necessary parameters.
You want to make it easier to read all the parameters. For example: You could code one parameter per
line.
In this example, note the following:
The second and the third lines each have a blank in position 3, after the identifier field (//)
The blank in position 3 of the second line, following the ending comma on the first line, indicates that the
second line is a continuation of the first line
The blank in position 3 of the third line, following the ending comma on the second line, indicates that the
third line is a continuation of the second line

18
Unit 2
Analyzing Job Output

At the end of this unit, you will be able to:


• Describe the JCL statement listing that appear in an output listing
• Identify allocation messages that may appear in an output listing
• Identify termination messages that may appear in an output listing
• Identify error messages that may appear in an output listing

19
z/OS MVS JCL – Unit II
Unit: Analyzing Job Output

Use SDSF to view the output and determine whether the job completed successfully.

Action characters can be


entered in the NP column:
?
C
S
P
SJ
….

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

PREFIX, OWNER and SET DISPLAY Commands

OWNER Limit jobs displayed by owning user ID


PREFIX Limit the jobs that are displayed by job name
SET DISPLAY Controls the display of values

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.

SET DISPLAY Command:


Purpose: Controls the display of values for PREFIX, DEST, OWNER, SORT, FILTER (tabular panels
only) and SYSNAME.
Where used: Any SDSF panel (except help and tutorial panels).
Format: SET DISPLAY (ON | OFF | ?)
ON displays the values just above the scrollable data. ONis the default. For SORT, the values are in
the format column/order, or column//order if that column may degrade performance. For FILTER, the
number of filters is shown.
OFF ends the display of values.
? displays the current setting for SET DISPLAY.

Example: SET DISPLAY ON  Displays current values.

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

JCL Statements Listing: // and XX


JCL Statement Listing  //

JCL Statement Listing  XX

Notes:

JCL Statement Listing  //


JCL statements coded as part of the job are preceded by slashes (//) in the identifier field.The JCL
statements are numbered. When the SYSOUT data set is printed, the operating system numbers the JCL
statements automatically.

JCL Statement Listing - XX

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

JCL statements, Allocation and Termination Messages

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

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.

17 IEFC612I PROCEDURE NOT FOUND //LA$TESTC JOB 31SPC03090156W,


18 IEFC630I UNIDENTIFIED KEYWORD ON // COCHRAN,MSGCLASS=12
THE EXEC STATEMENT
19 IEFC629I INCORRECT USE OF
APOSTROPHE IN THE DSNAME FIELD The MSGCLASS value
is only one character

Error Explanation Resulting error message


IEFC642I EXCESSIVE PARAMETER LENGTH
IN THE MSGCLASS FIELD

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

JCL Error Messages – Examples

Example 2

Example 1 //LA$TESTC JOB 31SPC03090156W,


// COCHRAN,MSGLEVEL=(1,1) MSGCLASS=A
//LA$TESTC JOB 31SPC03090156W,
// COCHRAN,MSGLEVL=(1,1) A blank space indicates that a
comment follows
MSGLEVEL was
misspelled

Resulting error message Example 3

IEFC630I UNIDENTIFIED KEYWORD //LA$TESTC JOB 31SPC03090156W,


MSGLEVL // COCHRAN,MSGLEVEL=(21)

Missing comma

Resulting error message


IEFC622I IMPROPER SUBPARAMETER LIST
IN THE MSGLEVEL FIELD

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

At the end of this unit, you will be able to:


• Explain the purpose and syntax of the JOB statement
• Define the JOB name
• Code positional parameters and keyword parameters
• Code the most commonly used keyword parameters on a JOB statement
• Complete the JOB statement
• Code additional JOB statement parameters

29
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements

Defining a JOB Statement

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.

//JOB1 JOB 776,M.FLURY

JOB Name Operation Parameter


Field Field

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

Rules for Job Names: A Summary


Valid Job Names
The rules for coding job names have been discussed in Unit 1
//JOB1 JOB
To summarize once again, these rules require a job name to begin //EXAMPLE4 JOB
in position 3 and to be 1 to 8 characters in length.
//RUN#2 JOB
The first character of a job name should be either alphabetic or a
national symbol. It should not be a number.
Invalid Job Names
The rest of the characters in the job name can be either
alphanumeric or they can be national symbols.
//JOB1+ JOB
Special characters or spaces are not allowed. //EXAMPLE14 JOB
// RUN#2 JOB

(Includes a special character)


(More than eight characters)
(Does not begin in position 3)

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.

//JOB1 JOB 776,K.YALE

//JOB2 JOB CLASS=A


Positional
Parameters

Keyword
Parameter

Notes:

There are two types of parameters:


 Positional parameters
 Keyword parameters

What are positional parameters?


Positional parameters are parameters that are characterized by their location in the parameter field in
relation to other parameters.
Positional parameters appear first in the parameter field in a fixed order if there are multiple parameters.

32
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements

Job Accounting Information

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.

//JOB1 JOB (255,’DEPT/OPS’),K.YALE

Multiple Parameters

If you omit the job accounting parameter, you must indicate its absence with a comma if you are
coding the programmer name.

//JOB1 JOB ,K.YALE

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

Coding Programmer Name

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:

The rules that apply to a programmer's name are as follows:


Separate the programmer's name from a preceding or following parameter by a comma
Make sure the programmer's name does not exceed 20 characters
Enclose the programmer's name in apostrophes when, the name contains special characters (other than
periods or hyphens)
Double any apostrophes in the programmer's name
The programmer's name is not a mandatory part of the JOB statement unless your installation has made it
so. Since the programmer name is the last positional parameter, you do not have to indicate its absence
with a comma if you leave it out.

34
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements

Defining Keyword Parameters

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:

The characteristics of keyword parameters include:


They must follow any positional parameter
They can be coded in any order
They must include a keyword, an equal sign (=), and a value (for example, CLASS=A)
There are a host of other keyword parameters which you can use in your JOB statement.
You can use them to produce the exact results you want.
Some of the most commonly used keyword Parameters:
 COND
 CLASS
 NOTIFY
 PRTY
 REGION
 TIME
 TYPRUN
 USER
 PASSWORD
These parameters follow the same guidelines as the keyword parameters MSGLEVEL and MSGCLASS.

35
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements

Coding the MSGLEVEL Parameter

//JOB1 JOB 255,SMITH,MSGLEVEL=(0,0)

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

The MSGLEVEL Parameter – Statement Subparameter


The statement subparameter indicates which job control statements the system is to print on the job log.
A statement subparameter can have one of the three values:
 0 – Print only the JOB statement
 1 – Print all JCL statements and JES2 or JES3 control statements, including invoked procedure
statements
 2 – Print only JCL statements and JES2 and JES3 control statements from the job stream

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

The MSGCLASS Parameter

//JOB1 JOB 255,MSGLEVEL=(1,1),


// MSGCLASS=A

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.

Each class is one character long and is designated by:

• 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

Defaults for MSGLEVEL & MSGCLASS

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.

//JOB1 JOB 255,MSGCLASS=A

Default: MSGLEVEL=(1,1)

//JOB2 JOB 255,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 COND Parameter

The condition (COND) parameter specifies the conditions under which a job terminates.

//JOBNAME JOB ...,COND=(code,operator)

//JOBNAME JOB ...,COND=((code,operator),(code,operator),... )

The Operator Subparameter


A JCL programmer can specify many ways of how the COND parameter tests a return code. The operator
subparameter specifies the comparison method.

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:

How does the COND parameter check for a condition?


When a program terminates, it generates a return code that indicates the conditions under which the
program terminated.
The COND parameter that you code provides the "test" needed for the comparison by supplying a value
withwhich to compare the return code.
Each COND parameter uses the following two subparameters:
 Code
 Operator
Code - This subparameter specifies a decimal value to be compared with the return code provided upon
completion of a program. The decimal value can range from 0 to 4095.
Operator - This subparameter specifies how the code subparameter is compared with the return code and
specifies the type of text.
You must remember to enclose each test in its own set of parentheses and the whole group of tests in
another pair of parentheses, in order to test more than one return code. You do not have to add the second
pairparentheses, if you want to test only one return code.
You can include a maximum of eight different return code tests on each JOB statement.
If any of the tests is true, the system bypasses all the remaining steps.

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

COND Parameter: Example 1

//JOB1 JOB 776,SMITH,COND=(12,LT)


//STEP1 EXEC PGM=PROGRAMA Return Code <= 12

//STEP2 EXEC PGM=PROGRAMB

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.

COND Parameter: Example 2

//JOB3 JOB 776,SMITH,


// COND=((16,LT),(8,GT))
8 > Return Code < 16
//STEP1 EXEC PGM=PROGRAMA
//STEP2 EXEC PGM=PROGRAMB

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.

//JOB1 JOB 504,SMITH,CLASS=A

Job class

Notes:

Jobs are grouped into various job classes.


Jobs are site-specific. You can check with your operations department about the job classes that are
available for your use.
Why are jobs grouped into classes?
This is done for the following reasons:
Job classes help to achieve a balance between different types of jobs
They help avoid contention between jobs that use the same resources
In order to specify a particular class for your job, you have to code the CLASS parameter on your JOB
statement.
Job class is a single character subparameter that can take the values A through Z or 0 through 9.

43
z/OS MVS JCL – Unit III
Unit: Coding JOB Statements

The NOTIFY Parameter

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:

//EX JOB ...,NOTIFY=JSMITH

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

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.

//JOB1 JOB 504,SMITH,PRTY=3

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.

//JOB1 JOB 504,SMITH,CLASS=T,


// PRTY=3

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

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.

//EXEC JOB ...,REGION=valueK


//EXEC JOB ...,REGION=valueM

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

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:

//jobname JOB ...,TIME=(minutes,seconds)

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

//EXAMPLE1 JOB 776,STUDENT,TIME=(2,45) Limit the CPU execution time to 2


//EXAMPLE2 JOB 776,STUDENT,TIME=1440 minutes and 45 seconds
//EXAMPLE3 JOB 776,STUDENT,TIME=NOLIMIT
//EXAMPLE4 JOB 776,STUDENT,TIME=MAXIMUM

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

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 and PASSWORD Parameters

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.

The PASSWORD parameter identifies a current RACF password for a job.


The PASSWORD parameter uses a job-specific subparameter, which can be 1 to 8 alphanumeric characters
or national symbols.

To specify a password of XYZ123, with a user ID of HARRIS, you would code the PASSWORD and USER
parameters as shown here.

//EXAMPLE JOB 776,STUDENT,PASSWORD=XYZ123,USER=HARRIS

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

Coding Multiple Keyword Parameters

You can code multiple keyword parameters on a single JOB statement in any order that you
choose after any positional parameters are coded.

//JOB1 JOB 504,SMITH,


// TIME=(2,45),
// REGION=768K,CLASS=T,
// PRTY=3,
// NOTIFY=JSMITH

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

At the end of this unit, you will be able to:


• Code an EXEC statement to specify a program to be executed
• Correct coding errors in an EXEC statement
• Identify which JCL statement has caused a “PROGRAM NOT FOUND” error message
• Identify the system library from which programs are retrieved at execution time
• Identify the DD statement names used to specify a private library from which programs are
retrieved at execution time
• Select the place in the job stream where STEPLIB and JOBLIB DD statements should be
located
• Code a JOBLIB DD statement

51
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements

The EXEC Statement

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

Identifier Name Operation Parameter Comment

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:

Identifier Field (//): It occupies position 1 and 2


Name Field: It names the step starting in position 3
EXEC Operator Field: It states the JCL statement type
Parameter Field: It is used to state the parameters used on an EXEC statement
Comment Field: This field is optional

52
z/OS MVS JCL - Unit IV
Unit: Coding EXEC Statements

The Step Name

It is important for you to always follow the JCL


step name coding rules while naming a step. Not
Valid Step Names
doing so will lead to JCL errors.

Following are the coding rules for the step name: //STEP1 EXEC

• The step name must begin in position 3 //EXAMPLE4 EXEC


//RUN#2 EXEC
• The step name must be 1 to 8
characters in length

• The first character in the step name Invalid Step Names


should be either alphabetic or a national
symbol
//STEP1+ EXEC (Includes a special character)
• The first character cannot be a number
//EXAMPLE14 EXEC (More than eight characters)
• Rest of the characters in the step name // RUN#2 EXEC
can either be alphanumeric or they can (Does not begin in position 3)
be national symbols

• Special characters and spaces cannot


be used in a step name

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 Positional Parameter

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

//STEP1 EXEC procedure-name


//STEP2 EXEC PROC=procedure
//STEP1 EXEC PGM=program-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

Positional Parameter Coding Errors

//LA$JOE JOB 3SPO3W,CLASS=B


//STEP1 EXEC PGM = IEFBR14

In the example shown here, the equal sign in the parameter


field is preceded and followed by a space. The system
interprets "PGM" as a procedure name and not as a keyword
for the positional parameter of the EXEC statement. When
this program executes, an error "NOT FOUND" may appear.
You can fix this error byeliminating the spaces before and SYSTEM ABEND
after the equal sign.

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

The PARM parameter passes information to the executing program. Some programs accept information from
the PARM parameter about how many times to execute.

The syntax for the PARM parameter is: PARM=(SUBPARAMETER,SUBPARAMETER)

Examples
//JOB1 JOB 766,SMITH
//RUN#2 EXEC PGM=REPORT,
// PARM=MONTHLY

//JOB1 JOB 766,SMITH


//RUN#2 EXEC PGM=REPORT,
// PARM=’10-31-98’

//JOB1 JOB 766,SMITH


//RUN#2 EXEC PGM=REPORT,
// PARM=(MONTHLY,’10-31-98’)

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

The COND Parameter

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.

COND Parameter Operators

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

COND Parameter – Examples

//JOB1 JOB 778,SMITH


//EXAMPLE2 EXEC PGM=DELETE In the example shown here, the COND parameter reads as
follows:
//EXAMPLE3 EXEC PGM=UPDATE, "If the return code from any previous step is less than 8, then
// COND=(8,GT) bypass this step."

//DD1 DD DSN=INPUT

//JOB1 JOB 778,SMITH


The COND parameter in the step EXAMPLE3, includes
//EXAMPLE2 EXEC PGM=DELETE a stepname subparameter. This causes the COND
//EXAMPLE3 EXEC PGM=UPDATE, statement to read as follows:

// 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 COND Subparameters – EVEN & ONLY

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.

//JOB1 JOB 778,SMITH


//EXAMPLE1 EXEC PGM=STEP1
//EXAMPLE2 EXEC PGM=STEP2
//EXAMPLE3 EXEC PGM=STEP4, COND=EVEN

Program STEP3 always executes, even if a previous step (e.g. STEP2) in the job terminates abnormally.

//JOB1 JOB 778,SMITH


//EXAMPLE1 EXEC PGM=STEP1
//EXAMPLE2 EXEC PGM=STEP2
//EXAMPLE3 EXEC PGM=STEP3, COND=ONLY

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

The operating system searches SYS1.LINKLIB or


LINKLIST for REPART. The error messages shown Error Message
occur because REPORT was misspelled as REPART
in the JCL

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

Private Program Libraries

You can use private libraries to store programs.

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:

You can use private libraries to store programs.


If you want to invoke a program called MYPROGwhich is stored in a private library, you must tell the
operating system the name of the privatelibrary by coding a special DD statement named JOBLIB.
If you want the system to call a program from a private library you should insert the JOBLIB DD
statement in the job before the first EXECstatement in the job.
The JOBLIB DD statement causes the system to search a private library before searching
SYS1.LINKLIB.
If the system does not find the program in the library specified by the JOBLIB DD statement then it goes
on to search the SYS1.LINKLIB and the libraries defined in LINKLIST next. This search sequence
repeats for every step in the job.
The STEPLIB DD statement can be placed anywhere in a job step but it typically appears after an EXEC
statement.
If most of the programs for a job reside in SYS1.LINKLIB or LINKLIST and only a few are in private
libraries, it makes more sense to direct the system to search a private library on a step-by-step basis.
This saves processing time by eliminating unnecessary searching.
To search a private library directly you use a special DD statement called STEPLIB DD statement as
shown.

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

At the end of this unit, you will be able to:

• Identify how to connect a DD statement to the program requirement for input/output


• Identify the number of DD statements required for a given program
• Understand the advantages of identifying the application data set and its location at
program initiation time
• Use backward reference feature with the PGM, DSN, VOL, and DCB parameters
• Code statements to concatenate data sets and create dummy data sets
• Code statements to produce storage dumps

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.

• The syntax used for coding a DD statement in the JCL is:

//ddname DD parameter(s)

The DD statement identifies the basic information about a data set including:

• DDNAME used by the program to reference a data set

• The data set name

• The location of the data set

• The manner in which data set should be accessed

Exemple:

//MYJOB JOB
//STEP1 EXEC PGM=PAYROLL
//PAY DD DSN=WEEKPAY1

Notes:

The advantages of using DD statements in JCL are:


It allows the data set information to change without recompiling the programs that access the data set It
increases reusability of programs
The installation becomes more adaptable

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

Using DDNAME in Programs

How do we code DDNAME in programs?

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

The characteristics of DD Statement Parameters


are: //DDNAME DD parameter(s)

• Adding parameters in the DD statement


allows us to specify the characteristics
of a data set
DSN
• DD statement parameters can be coded
in any order as they are keyword
DISP
parameters UNIT
VOL
SPACE
LABEL
DCB
SYSOUT

Notes:

69
z/OS MVS JCL – Unit V
Unit: Coding DD Statements

DD Statement Parameters - DSN


The Data Set Name (DSN) specifies the name of the data set

Temporary data set


It is used for storage within the life cycle of the job. Syntax:

//DATA1 DD DSN=&&FIRST
or
//DATA1 DD (all needed parameters except DSN parameter)

Non-Temporary Data Set

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:

Temporary Data Sets


The characteristics of a temporary data set are:
 Temporary data set is used for storage within the life cycle of the job
 Naming a temporary data set is optional
 Temporary data set names can be coded either by including two ampersands (&&) before the
name or by leaving out the DSN parameter
The syntax used in coding temporary data sets is:
//DATA1 DD DSN=&&FIRST or
//DATA1 DD (all needed parameters except DSN parameter)
When the DSN parameter is omitted the system assigns a unique name.

Non-Temporary Data Sets


The characteristics of non-temporary data sets are:
 Non-Temporary Data Sets
 Non-temporary data sets can be saved and reused after the job has completed
 Non-temporary data sets must be given a data set name
The syntax used in coding non-temporary data sets is:
//DATA2 DD DSN=SECOND

70
z/OS MVS JCL – Unit V
Unit: Coding DD Statements

DD Statement Parameters - DISP


DISP=([status][,normal-termination-disp] [,abnormal-termination-disp])

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.

• The current status of a data set can be:


• Old (OLD)
• New (NEW) Examples
• Shared (SHR) //DATA1 DD DSN=FIRST,
// DISP=(NEW,CATLG)
• The method of handling a data set after termination can be: //DATA2 DD DSN=SECOND,
// DISP=OLD
• Delete (DELETE) //DATA3 DD DSN=AAAAA,
// DISP=(,CATLG,DELETE)
• Keep (KEEP)
//DATA4 DD DSN=BBBBB,
• Catlog (CATLG) // DISP=(OLD,DELETE,DELETE)
• Uncatlog (UNCATLG) //DATA5 DD DSN=CCCCC,
// DISP=(,PASS)
• Pass (PASS)

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

DD Statement Parameters - UNIT

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

DD Statement Parameters - VOL

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

DD Statement Parameters - SPACE

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:

The characteristics of the SPACE parameter are:


Coding the SPACE specifies how much room on a DASD volume the system should allocate to the new
data set
The space can be reserved by specifying a number of blocks, tracks or cylinders

74
z/OS MVS JCL – Unit V
Unit: Coding DD Statements

DD Statement Parameters - DCB

What are the characteristics of the DCB parameter?

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

DSORG=organization Specifies the organisation for a data set


PS Physical sequential
PO Partitioned data set

75
z/OS MVS JCL – Unit V
Unit: Coding DD Statements

DD Statement Parameters - SYSOUT

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

Dummy Data Sets

What is a dummy data set?

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.

How does it work?

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:

• Coding DUMMY as the first DD parameter

//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

Data Set Concatenation

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.

Following steps are involved in concatenating data sets:

1) Code a standard DD statement for the first data set


only

2) Add a DD statement without a ddname for each data


set to be concatenated

3) Sequence the statements in the order they are to be


processed

//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:

Keyword = *. [stepname] [procstep] ddname

DSN Backward Reference


It is a coding technique that refers to a prior DD statement that names the data set you want to process.

//STEP1 EXEC PGM=PROG1


//DD1 DD DISP=(NEW,PASS),DSN=WEEK1
//STEP2 EXEC PGM=PROG2
//DD2 DD DSN=*.STEP1.DD1,DISP=OLD

DCB Backward Reference


It is a coding technique that allows you to copy a list of attributes from a prior DD statement in the
same or previous job step.

//STEP1 EXEC PGM=PROG1


//DD1 DD DCB=(RECFM=FB,ZRECL=80,BLKSIZE=800)
//STEP2 EXEC PGM=PROG2
//DD2 DD DCB=*STEP1.DD1,...

Notes:

Four common backward references are:

 PGM Reference: Points to a previous data set to specify a program name


 DSN Reference: Points to a previous data set name
 VOL Reference: Points to a previous volume serial number
 DCB Reference: Points to DCB attributes defined in another previous DD statement

PGM Backward Reference:


A PGM backward reference is useful in a program development environment, in which the output from
one job step (typically a linkage edit step) may become the program to execute in a subsequent step. In
such a case, instead of naming the program, you can code a PGM backward reference.
A PGM backward reference is a coding technique that points to a prior DD statement which specifies a
member of a program library.
The general form of a PGM backward reference is as follows:
//STEP EXEC PGM=*.stepname.ddname

79
Example:
//LKED EXEC PGM=LINKEDIT
//SYSLMOD DD DSN=&&GOSET(GO),
// DISP=(NEW,PASS)
//STEPA EXEC PGM=*.LKED.SYSLMOD

The ddname is SYSLMOD and the data name is &&GOSET(GO).


The DISP parameter specifies that the data is NEW and is to be PASSed to another step.
TEPA executes the program, using a PGM backward reference.

DSN Backward Reference:


This technique is useful when coding jobs that consist of several steps, with multiple references to the
same data set. The reference can also be used to retrieve temporary data sets in subsequent job steps,
without knowing the name.
The DSN backward reference is a coding technique that refers to a prior DD statement that names the
data set you want to process.
The general form for the DSN backward reference is as follows:
DSN=*.stepname.ddname

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).

DCB Backward Reference


This coding technique can be used to ensure that the DCB parameters are consistent within the job.
It can also be used to override or add to the subparameters coded on a previous statement.

DCB Backward Reference – Overriding


DCB backward reference is a coding technique that allows you to copy a list of attributes from a prior DD
statement in the same or previous job step.
The general form is as follows:
//ddname DD DCB=*.stepname.ddname
The values of the DCB parameters being referredwill be overridden by the values that are being coded.
Any attributes that do not match the DCB being referred will be added
A DCB backward reference can also be used to override or add to the subparameters coded on a previous
statement.
The format for overriding a previous statementis as follows:
DCB=(*.stepname.ddname,list-ofattributes)

81
For example, notice the DCB characteristics in statement DD1 below:
//STEP3 EXEC PGM=PROG3
//DD1 DD DCB=(RECFM=F,BLKSIZE=800),…

The following override statement:

//DD2 DD DCB=(*.DD1,RECFM=FB,LRECL=80)

would result in these DCB characteristics:

//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

When a program abnormally terminates, storage


dumps are used as a debugging tool to find clues
to the cause for abnormal ending.

Storage dumps are not the most effective debugging tool.

The main drawbacks of storage dumps are:

• They are difficult to read since they are printed


in hexadecimal code

• Printing storage dumps is time consuming

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

At the end of this unit, you will be able to:


• Identify the various types of job conditions that an IF/THEN/ELSE/ENDIF statement
construct can test
• Code IF/THEN/ELSE/ENDIF statement constructs
• Correct invalid IF/THEN, ELSE, and ENDIF JCL statements
• State reasons why IF/THEN/ELSE/ENDIF JCL errors occur
• State the advantages of using the IF/THEN/ELSE/ENDIF statement construct instead of
the COND parameter

85
z/OS MVS JCL – Unit VI
Unit: Conditional Processing - IF/THEN/ELSE/ENDIF Construct

Syntax for the IF/THEN/ELSE/ENDIF Statement Construct

//name IF (relational-expression) THEN


//name JCL statement(s) to be executed when relational-expression is true
//name ELSE
//name JCL statement(s) to be executed when relational-expression is false
//name ENDIF

Relational-expression  specifies the condition that is evaluated at execution.


Depending on the values in the expression, the result of the condition is either true or false.
In the example, the statement tests for a return code of less than eight. Hence the relational-expression is RC<8.

//TESTRC IF RC<8 THEN

Relational-Expression
Field

Notes:

What are the characteristics of the IF statement?


The IF statement always precedes a relational-expression and the identifier THEN.
Following the IF statement are all of the JCL statements to be executed when the relational-expression is
true.
If there are none, then the IF statement should be followed immediately by the ELSE statement.
The name field in the IF/THEN/ELSE/ENDIF statement construct is optional but if specified it must
follow the coding rules for names in JCL statements.
The IF/THEN/ELSE/ENDIF statement construct can be coded anywhere in the job after the JOB
statement
Even though the name field is optional, if one is coded then it must follow the normal coding rules for
names in JCL statements, such as:
The name must begin in position 3. If you do not code a name then leave the position blank
The name must be unique within the job
The first character of the name has to be alphabetical or national and it cannot be a number
The remaining characters can be alphanumeric or national
The name field must be followed by at least one space

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

Also the relational-expression can be enclosed in parentheses


Relational-expressions can be continued on more than one line.
To continue the expression, break the expression a valid blank space and continue on the next line using
columns 4 through 16. Example:
//TESTRC IF (ABEND | RC<8 | // RC=16) THEN
There must be at least one space between the IF operator and relational-expression field and similarly one
space between the expression and the THEN operator.

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

GT or > Greater than


GE or >= Greater than or equal to //TESTIT IF (RC=8) THEN

NG or ¬> Not greater than


Spaces are
EQ or = Equal to not required

NE or ¬= Not equal to //TESTIT IF RC EQ 8 THEN

LT or < Less than


Spaces are
required
LE or <= Less than or equal to
NL or ¬< Not less than

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

Logical Operators- AND, OR and NOT

• 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.

For example, to test if a return code is between 8 and 24:

//TEST1 IF (RC>8 & RC<24) THEN

For example, to test if a return code is either equal to 8 or 16:

//TEST2 IF (RC=8 | RC=16) THEN

For example, to test if a return code is not equal to 12:

//TEST3 IF ¬(RC=12) THEN

Notes:

The logical operators include:


 AND (&)
 OR (|)
 NOT (¬)
The operators AND and OR must be preceded and followed by at least one space.

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.

//TESTRC IF (RC>4) THEN

//TESTRC IF (COMPILE.RC>4) THEN

//TESTRC IF COMPILE.PROG1.RC>4 THEN

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

Relational - Expression Keywords ABEND and ¬ABEND

The keyword ABEND tests for abnormal termination from any previous job step. Syntax used for ABEND:

//name IF ABEND THEN //TEST IF ABEND THEN


or
//name IF ABEND = TRUE THEN //TEST IF TEST1.ABEND = TRUE THEN

The keyword ¬ABEND will test to ensure an abnormal termination did not occur in any of the
previous steps. The syntax is:

//name IF ¬ABEND THEN //TEST IF ¬ABEND THEN


or
//name IF ABEND = FALSE THEN //TEST IF TEST1.ABEND = FALSE THEN

Notes:

Keywords ABEND  To check a specific job step for abnormal termination.


stepname.ABEND
or stepname.ABEND = TRUE
Both formats can be preceded with a step name or procedure step name to check specific job steps or
procedure steps for abnormal termination.

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

Relational - Expression Keywords ABENDCC

The relational-expression keyword ABENDCC tests for a specific system abend completion code or user
defined abend completion code from any previous job step.

ABENDCC = Sxxx ABENDCC = Uxxxx

Example

//TST4ABND IF ABENDCC = S0C1 THEN

//TST4ABND IF RUNPGM.ABENDCC = U0100 THEN

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

Relational - Expression Keywords RUN and ¬RUN

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

//JOB1 JOB 777,SMITH


//COMPILE EXEC PGM=COMPILE
//LINK EXEC PGM=LINK
//TST4RUN IF ¬LINK.RUN THEN
//TEST EXEC PGM=RECOVER

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

To test if a specific procedure step failed to execute


//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:

//TESTRC IF (RC>=8) THEN


//ERROR EXEC PGM=DELFILES
// ENDIF
//STEP2 EXEC PGM=IEBCOPY

Example 2

To illustrate the working of the ELSE clause consider the following JCL code:

//TESTRUN IF STEP1.RUN THEN


//GOOD EXEC PGM=CREATE
// ELSE
//ERROR EXEC PGM=DELFILES
// ENDIF
//STEP2 EXEC PGM=COMPRESS

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

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.

The IF/THEN/ELSE/ENDIF statement construct can be nested up to 15 levels.

//COMPPGM EXEC PGM=COMPILE


//CHKCOMP IF (COMPPGM.RC<=4) THEN
//LNKPGM EXEC PGM=LINK
//CHKLKED IF (LNKPGM.RC>4) THEN
Example //DELPGM EXEC PGM=DELETE
// ELSE
//RUNPGM EXEC PGM=MYPROG
// ENDIF
// ENDIF
//COMPLIB EXEC PGM=COMPRESS

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

The COND Parameter vs. Conditional Processing

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.

//JOB1 JOB 777,SMITH


//STEP1 EXEC PGM=PRG1
//STEP2 EXEC PGM=PRG2
//TST1 IF (RC<5) THEN
//STEP3 EXEC PGM=PRG3
//STEP4 EXEC PGM=PRG4,COND=(1,NE)
// ENDIF

Notes:

97
Unit 7
Procedures

At the end of this unit, you will be able to:


• Define the terms procedure, cataloged procedure and in-stream procedure
• Specify where a procedure can be located
• Code a statement to invoke a procedure
• Invoke a procedure, making temporary alterations to it if necessary
• Add, override or nullify parameters on procedure step EXEC statements
• Add, override or nullify parameters on procedure step DD statements
• Understand the purpose and form of symbolic parameters in a procedure definition
• Assign values to symbolic parameters at the time of invoking a procedure

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:

A procedure may consist of one or more job steps.


When the system encounters the above EXEC statement in a job stream, it locates the definition of
PROCA and brings the pre-coded JCL statements into the current JCL and then executes it.
Most installations have pre-coded procedures that enable you to perform compiles, link edits and tests
quickly and easily.
To use pre-coded procedures, the code must contain the following statements:
A single EXEC statement that invokes the procedure
A DD statement to identify the source program in case of compiles
DD statements for the test data
Advantages of using a procedure are:
 Procedures can greatly simplify JCL
 Procedures help in maintaining complex or lengthy JCL
 Procedures help you to standardize data set and program usage

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:

//[name] JCLLIB ORDER=(library[,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

//MYJOB JOB ,ROSE


//PROCA PROC
//PSTEP1 EXEC PGM=MYPROG
//DDIN DD DSN=INDATA,DISP=SHR This defines the procedure
//DDOUT DD SYSOUT=A
// PEND
//STEP2 EXEC PROCA This executes the procedure

Notes:

A procedure is referred to as either a cataloged procedure or an in-stream procedure depending upon


where it is defined.

What are cataloged procedures?


Cataloged procedures 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-
specifiedprocedure library.
It is not necessary to code a DD statement to identify the library in which the procedure resides since the
system keeps track of the PDS used as procedure library.

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.

When to catalog a procedure?


If a thoroughly tested procedure needs to be used by many people, it is cataloged for subsequent
retrieval.A cataloged procedure is easy to retrieve and maintain.
The example shows a job stream that contains an in-stream procedure definition named PROCA.
The JCL between the PROC and PEND statements defines the procedure. The EXEC statement that
refers to the procedure name executes it.

101
z/OS MVS JCL – Unit VIII
Unit: Introducing Procedures

Nested Procedure

What is a nested procedure? PROCA

When procedures are nested, one procedure //PSTEP EXEC PGM=ABC


invokes another.

//PSTEP EXEC PROCB


Nested procedure – An example
PROCB

There are three procedures:


//STEP1 EXEC PROCC
PROCA
PROCB
//STEP2 EXEC PGM=XYZ
PROCC
PROCC

In the example on the right, there are three


procedures, PROCA, PROCB, and PROCC. //S1 EXEC PGM=KLM
PROCA invokes PROCB, and PROCB invokes
PROCC. //S2 EXEC PGM=RST

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

Overriding Statement Parameters - Example

//PSTEP1 EXEC PGM=PROG1,TIME=(1,30)


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A
//PSTEP1 EXEC PGM=PROG1,TIME=3
//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//JSTEP EXEC TRANSACT,TIME.PSTEP1=3 //PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A

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.

Implementing coding changes to EXEC statements involves the following steps:


 Give the name of the EXEC statement parameter to be overridden, nullified or added, followed by
a period.
 Give the name of the procedure step, followed by an equal sign.
 Give the new value for the parameter if overriding or adding a value. Do not code a value if the
parameter is to be nullified.

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

Nullifying EXEC Statement 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=

//PSTEP1 EXEC PGM=PROG1,TIME=(1,30)


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A

//JSTEP1 EXEC TRANSACT,TIME.PSTEP1=

//PSTEP1 EXEC PGM=PROG1


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A

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

Adding Parameters to a Procedure

Addition statements are used to add parameters to a procedure. The programmer can code additions on the
EXEC statement that invokes the procedure.

//PSTEP1 EXEC PGM=PROG1,TIME=(1,30)


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A

//JSTEP EXEC TRANSACT, PARM.PSTEP1=’01/29/91’,PARM.PSTEP2=’01/29/91’

//PSTEP1 EXEC PGM=PROG1,TIME=(1,30),PARM=’01/29/91’


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,TIME=5,PARM=’01/29/91’
//DD3 DD SYSOUT=A

Notes:

Parameters can be added to one or more procedure steps.


A comma separates the name of the procedure from the first parameter addition, and the parameter
additions from each other.

106
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying EXEC Parameters

Sequencing Multiple Changes – Example

Consider the TRANSACT procedure.


The following alterations are to be made to the
EXEC statement operands in the procedure:

• Increase the time restriction for PSTEP1


to 3 minutes
//JSTEP EXEC TRANSACT,TIME.PSTEP1=3,
• Revert to the installation-defined TIME // PARM.PSTEP1=’01/29/99’,
default for PSTEP2 // TIME.PSTEP2=,
// PARM.PSTEP2=’01/29/99’
• Add a PARM parameter value of
01/29/99 for the EXEC statements in
PSTEP1 and PSTEP2

The JCL statements on the right show how to


combine these alterations on the EXEC statement
that invokes the procedure.

Notes:

107
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters

Changing the DD Statement 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:

• Change a data set name or its storage location


• Nullifying some of the specified parameters that are not applicable to the data set to be used
• Add needed parameters that are not specified

The general form for changing DD statement parameters is as follows:

//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

Overriding DD Statement 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

//PSTEP1 EXEC PGM=PROG1,TIME(1,30)


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//DD3 DD SYSOUT=A
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD5 DD DSN=MASTER,DISP=SHR

//PSTEP1 EXEC PGM=PROG1,TIME(1,30)


//DD1 DD DSN=NEWTRAN,DISP=SHR,
// UNIT=3390,VOL=SER=12345
//STEP EXEC TRANSACT //DD2 DD DSN=MASTER,DISP=SHR
//PSTEP1.DD1 DD DSN=NEWTRAN, //DD3 DD SYSOUT=A
// UNIT=3390, //PSTEP2 EXEC PGM=PROG2,TIME=5
// VOL=SER=12345 //DD5 DD DSN=MASTER,DISP=SHR

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

Nullifying a DD Statement Parameter

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

//PSTEP1 EXEC PGM=PROG1,TIME(1,30)


//DD1 DD DSN=INTRAN,DISP=SHR
//STEP EXEC TRANSACT //DD2 DD DSN=MASTER,DISP=SHR
//PSTEP1.DD2 DD UNIT=,VOL=SER= //DD3 DD SYSOUT=A
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD5 DD MASTER,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

Nullifying the DSN parameter (DUMMY or DSN=NULLFILE)


If a procedure is to be executed without using a data set specified on a procedure step DD statement, a
dummy status can be assigned to the data set.

//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:

When DUMMY or DSN=NULLFILE is coded on an override DD statement, it nullifies all parameters


specified on the corresponding DD statement in the procedure definition except the DCB parameter.
In the example, the override DD statement nullifies the DSN parameter and any other parameters
associated with that data set. During execution of the procedure, the system will not consider the data set
that was designated by DD2. It will pass on to DD3 after DD1.

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

//PSTEP1 EXEC PGM=PROG1,TIME(1,30),


// PARM=NOCHECK
//DD1 DD DSN=INTRAN,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A

//PSTEP1 EXEC PGM=PROG1,TIME(1,30),


//JSTEP EXEC TRANSACT, // PARM=CHECK
// PARM.PSTEP1=CHECK //DD1 DD DSN=INTRAN,DISP=SHR
//PSETP1.DD2 DD DSN=MASTER, //DD2 DD DSN=MASTER,DISP=SHR
// DISP=SHR //PSTEP2 EXEC PGM=PROG2,TIME=5
//DD3 DD SYSOUT=A

Notes:

In the example, the TRANSACT procedure is used to process customer orders.


Every quarter the transaction input file (data set INTRAN) has to be checked against the master customer
list (data set MASTER) to ensure that each transaction has valid customer.
During the routine weekly execution the check is not made, and data set MASTER is not used.
To execute the procedure routinely every week without making the check, you would code the following
EXEC statement to invoke the procedure:
//JSTEP EXEC TRANSACT
For the quarterly execution the transaction input file has to be checked against the master customer list.
To perform the required quarterly check, two statements are required to invoke the procedure:
 An EXEC statement override that includes a PARM parameter value of CHECK to override the
value of NOCHECK
 An addition DD statement to identify data set MASTER that PROG1 needs to access to perform
the check

113
z/OS MVS JCL – Unit VII
Unit: Procedures - Modifying DD Parameters

Overriding the DCB Parameter – Example

This is a DD statement in a procedure step called PSTEP1:

//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)

Nullifying the DCB Parameter – Example

This is a DD statement in a procedure called PSTEP1:

//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:

//PSTEP1 EXEC PGM=PROG1,TIME(1,30),


// PARM=NOCHECK
//DD1 DD DSN=INTRAN,DISP=SHR
//DD3 DD SYSOUT=A
//DD4 DD DSN=&&VALID,
// DISP=(NEW,PASS),
// UNIT=SYSDA,
// SPACE=(TRK,(1,1))
//PSTEP2 EXEC PGM=PROG2,TIME=5
//DD5 DD DSN=&&VALID,
// DISP=(OLD,DELETE)
//DD6 DD SYSOUT=A

//JSTEP EXEC TRANSACT,


// PARM.PSTEP1=CHECK
//PSTEP1.DD1 DD DSN=MYDATA
//PSTEP1.DD2 DD DSN=CKDATA,
// DISP=SHR
//PSTEP2.DD6 DD DSN=INVOICE,
// DISP=(NEW,CATLG),
// UNIT=3390,
// VOL=SER=6929L,
// SPACE=(TRK,10)

In the example, the following changes need to be made:

• 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

Assigning Values to EXEC Statement Parameters


When executing TRANSACT, a value would be assigned to the symbolic parameter on the
EXEC statement that invokes TRANSACT.

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

Different values cannot be assigned to the same symbolic parameter when


invoking the procedure.

//PSTEP1 EXEC PGM=PROG1,PARM=&DEPT


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASATER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,PARM=&DEPT
//DD3 DD SYSOUT=A

Assigning Different Values – Example

//PSTEP1 EXEC PGM=PROG1,PARM=&DEPT1


//JSTEP EXEC TRANSACT,DEPT1=GRP50, //DD1 DD DSN=INTRAN,DISP=SHR
// DEPT2=GRP100 //DD2 DD DSN=MASATER,DISP=SHR
//PSTEP2 EXEC PGM=PROG2,PARM=&DEPT2
//DD3 DD SYSOUT=A

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

Assigning Different Values – Example 1:


Values can be assigned to the symbolic parameters in any order
While invoking the procedure, the symbolic parameter &DEPT1 is assigned a value of GRP50, &DEPT2
a value of GRP100.
To illustrate the first condition, assume the TRANSACT procedure has been created to allow for two
different values for the EXEC statement PARM parameters, as follows:
//PSTEP1 EXEC PGM=PROG1,PARM=&DEPT1
...
//PSTEP2 EXEC PGM=PROG2,PARM=&DEPT2
In the example, the TRANSACT procedure has been invoked with the values GRP50 and GRP100 for
PSTEP1 and PSTEP2 respectively.
//JSTEP EXEC TRANSACT,DEPT1=GRP50,
// DEPT2=GRP100

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

Symbolic PGM Parameters

The PGM parameter is the only EXEC statement parameter that cannot be modified with an
override statement when a procedure is executed.

If a symbolic parameter is specified in the procedure definition, an appropriate value can be


assigned when invoking the procedure.

//PSTEP1 EXEC PGM=&PROG1


//DD1 DD DSN=INTRAN,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=&PROG2
//DD6 DD SYSOUT=A

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

Recognizing Default Values


At the time symbolic parameters are created, creator of the procedure can also assign default values to the
parameters. The characteristics of default values are:
• They are specified in the parameter field of the PROC statement
• They do not have a preceding ampersand
• In the case of multiple symbolic parameters, they are separated by a comma
• They can be assigned in any sequence

//TRANSACT PROC DEPT=G300,PROG=PROG2


//PSTEP1 EXEC PGM=PROG1,
// PARM=&DEPT
//DD1 DD DSN=&WEEK,DISP=SHR
//DD2 DD DSN=MASTER,DISP=SHR
//PSTEP2 EXEC PGM=&PROG,ACCT=&DEPT
//DD3 DD SYSOUT=A

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

Nullifying Default Values


A value for a symbolic parameter should be assigned (or nullified) only if:

• 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

//TRANSACT PROC DEPT=G300,PROG=PROG2


//PSTEP1 EXEC PGM=PROG1,
// PARM=&DEPT
//DD1 DD DSN=&WEEK,DISP=SHR //JSTEP EXEC TRANSACT,DEPT=,
//DD2 DD DSN=MASATER,DISP=SHR // PROG=TESTPRG,
//DD3 DD SYSOUT=A // WEEK=TSTDATA
//PSTEP2 EXEC PGM=&PROG,ACCT=&DEPT
//DD4 DD SYSOUT=A

Notes:

The rules for overriding or nullifying the default values are:


 To override a default value, specify the symbolic parameter without the preceding ampersand,
followed by an equal sign and the appropriate value
 To nullify a default value, specify the symbolic parameter without the preceding ampersand,
followed by only an equal sign
 The overrides and nullifications for default values can be specified in any sequence
 Symbolic parameters can be nullified or assigned values in any sequence.

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

You might also like