Handout JCL

7/29/2019 Handout JCL

1/46

JCL

Version: JCL/HANDOUT/0605/2.0

Date: 14-06-05

Cognizant Technology Solutions500 Glen Pointe Center West

Teaneck, NJ 07666Ph: 201-801-0233

www.cognizant.com


2/46

JCL

Copyright 2004, Cognizant Academy, All Rights Reserved 2

TABLE OF CONTENTS

Introduction................................................................................................................................... 6

About this Module......................................................................................................................... 6

Target Audience........................................................................................................................... 6

Module Objectives........................................................................................................................ 6

Pre-requisite................................................................................................................................. 6

Chapter 1: Overview of JCL.......................................................................................................... 7

Learning Objectives ..................................................................................................................... 7

What is JCL?................................................................................................................................ 7

Job and a Job step....................................................................................................................... 7

Sample JCL.................................................................................................................................. 7

Job Entry Subsystem ................................................................................................................... 8

How JES2 and JES3 process Jobs.............................................................................................. 8

SUMMARY................................................................................................................................... 9

Test your Understanding............................................................................................................ 10

Chapter 2: Structure of JCL statements .................................................................................... 11

Learning Objective ..................................................................................................................... 11

Introduction................................................................................................................................. 11

The identifier field....................................................................................................................... 11

The name field ........................................................................................................................... 11

The operation field ..................................................................................................................... 11

The parameters field .................................................................................................................. 11

The comments field.................................................................................................................... 12

How to continue JCL statements ............................................................................................... 12

SUMMARY................................................................................................................................. 12


Chapter 3: The JOB statement ................................................................................................... 13

Learning Objectives ................................................................................................................... 13

Functions of the JOB statement.................................................................................................13


3/46

JCL


A simplified job statement .......................................................................................................... 13

Job name ................................................................................................................................... 13

Accounting Information .............................................................................................................. 13

Programmer Name .................................................................................................................... 14

User and Password.................................................................................................................... 14

Class .......................................................................................................................................... 14

Notify .......................................................................................................................................... 14

MSGCLASS and MSGLEVEL.................................................................................................... 15

Time ........................................................................................................................................... 15

Job Statement Examples ........................................................................................................... 15

SUMMARY................................................................................................................................. 16

Chapter 4: The EXEC statement ................................................................................................. 17


The EXEC statement ................................................................................................................. 17

Basic format of an EXEC statement .......................................................................................... 17

The PGM parameter .................................................................................................................. 17

The PARM parameter ................................................................................................................ 17

The COND parameter................................................................................................................ 18

SUMMARY................................................................................................................................. 19


Chapter 5: The DD statement...................................................................................................... 20


The DD statement...................................................................................................................... 20

Three formats of the DD statement............................................................................................ 20

The DD statement for DASD data sets ...................................................................................... 21

The DISP parameter .................................................................................................................. 21

The UNIT and VOLUME parameters ......................................................................................... 23

The SPACE parameter .............................................................................................................. 23

The DCB Parameter................................................................................................................... 25


4/46

JCL


The DD statement for in-stream data sets................................................................................. 26

The DATA parameter................................................................................................................. 26

The DLM parameter................................................................................................................... 27

The DD statement for SYSOUT data sets ................................................................................. 27

SUMMARY................................................................................................................................. 28


Chapter 6: Special JCL statements and Data sets ................................................................... 29


The null statement...................................................................................................................... 29

The comment statement ............................................................................................................ 29

DUMMY data sets ...................................................................................................................... 29

Temporary data sets .................................................................................................................. 29

Concatenating data sets ............................................................................................................ 31

SUMMARY................................................................................................................................. 33


Chapter 7: JCL Procedure........................................................................................................... 34


JCL Procedure ........................................................................................................................... 34

Invoking a procedure.................................................................................................................. 34

Cataloged and in-stream procedures......................................................................................... 35

Code a job that uses an in-stream procedure............................................................................ 35

Code a job that uses a cataloged procedure ............................................................................. 36

The JCLLIB statement ............................................................................................................... 36

SUMMARY................................................................................................................................. 37


Chapter 8: Modifying a Procedures statements - overrides................................................... 38


Introduction................................................................................................................................. 38

Modify EXEC statement parameters.......................................................................................... 38


5/46

JCL


Modify DD statement parameters .............................................................................................. 38

Adding a DD statement.............................................................................................................. 39

SUMMARY................................................................................................................................. 39

Chapter 9: Symbolic parameters ................................................................................................ 40


Introduction................................................................................................................................. 40

Symbolic parameters ................................................................................................................. 40

Code symbolic parameters ........................................................................................................ 40

Specify values for symbolic parameters..................................................................................... 40

Symbolic parameter values........................................................................................................ 41

Assign default values to symbolic parameters........................................................................... 43

SUMMARY................................................................................................................................. 44


REFERENCES............................................................................................................................... 45

WEBSITES................................................................................................................................. 45

BOOKS....................................................................................................................................... 45

STUDENT NOTES: ....................................................................................................................... 46


6/46

JCL


Introduction

About this Module

This Module is a basic Information and instructional handout on Job Control Language (JCL)

Target Audience

This Module is specifically intended for Entry Level Programmer Trainees who need a basic

idea of JCL.

Module Objectives

The main objective of the module is to provide knowledge on the following areas:

Need of JCL in Mainframe

Various JCL statements

Preparing a JCL for batch application

Pre-requisiteThe Module assumes that the student shall have a prior knowledge in the following areas:

Programming in COBOL or any other mainframe language,

Understanding of MVS operating system


7/46

JCL


Chapter 1: Overview of JCL

Learning Objectives

The chapter shall achieve the following objectives:

Understanding Job and JES

Understanding the need of a Job

What is JCL?

Job Control Language (JCL) is a means of communication between an application program

and the computer's operating system. It is a set of control statements that provide the

specifications necessary to process a JOB.

Job and a Job step

A Job is nothing but the execution of one or more related programs in sequence. Each

program to be executed by a job is called a Job Step.

To illustrate, suppose you want to process a job that executes two programs: the first updates

a customer file, and the second prints a report that lists customers by name. This is a two step

job because two programs are involved. The entire set of statements that provide the

specifications like the name of the program, the name of the customer file, the daily

transaction file, and the details about the printer form the Job Control Language.

JCL statements mainly perform the following functions:

Specify the input data sets (files) that must be accessed

Identifies the output data set to be created or updated

Allocates the resources for the programs that are to run, using this input and output data sets.

Sample JCL

//First JOB SAMPLE JOB, CLASS=S

//STEP01 EXEC PGM=REPORT

//INPUT DD DSN=CUSTOMER.FILE,

// DISP=SHR

//OUTPUT DD DSN=REPORT.FILE,

// DISP=(NEW,CATLG,DELETE)

// UNIT=SYSDA,DCB=(RECFM=FB,LRECL=80),

// SPACE(TRKS,(100,20),RLSE)

//SYSOUT DD SYSOUT=*


8/46

JCL


You normally store the set of JCL statements for a job as a member of a partitioned data set.

Job Entry Subsystem

To process a Job, an important component of MVS called the Job Entry Subsystem (JES) is

used. In simple terms, the JES is the MVS component that keeps track of jobs that enter the

system, presents them to MVS for processing, and sends their spooled output to the correct

destination.

There are two versions, JES2 and a later version with additional capabilities, JES3. Although

you should know whether your operating system uses JES2 or JES3, it doesnt really matter in

most cases. For typical jobs that dont have unusual processing requirements that depend on

the unique characteristics of JES2 or JES3, both Job Entry Subsystems provide essentially the

same functions: they let you enter a job into the system, they decide when your job should be

processed, they pass your job to MVS for processing, and they deliver your jobs printed

output to the correct destination.

How JES2 and JES3 process Jobs

The life cycle of a typical job is as follows:

The job is submitted

The jobs is selected for execution

The job is executed

The jobs output is processed

The job is purged

How a job is entered into the system

As already mentioned, you write all the JCL statements in a DASD file.

To enter, or submit, the job into the system, you issue a SUBMIT command. That causes

JES2 or JES3 to read the job stream from the DASD file and copy it to a job queue, which is a

part of a special DASD file called the JES spool.

How a job is scheduled for execution

MVS does not necessarily process jobs in the order in which you submit them. Instead, JES

examines the jobs in the job queue and selects the most important jobs for execution. That

way, JES can prioritize its work, giving preference to more important jobs.

JES uses two characteristics to classify a jobs importance, both of which can be specified in

the jobs JCL: job class andpriority. Of the two, job class is more significant. If two or morejobs of the same class are waiting to execute, the JES scheduler selects the one with the

higher priority.

A single character, either a letter (A-Z) or a digit (0-9) represents each job class. Job classes

are assigned based on the processing characteristics of the job. As an illustration, Class A

jobs can execute only for 15 minutes, Class B jobs for 30 minutes, Class C jobs with unlimited

time and Class T is reserved for jobs that require tape files. However, bear in mind that the


9/46

JCL


above job class assignments are only an example. Each installation makes is own job class

assignments, so the job classes your installation uses will certainly be different.

Before we proceed, let us discuss about a special type of program called the initiator, because

that knowledge will help you understand not only job scheduling, but MVS multiprogramming

as well. An initiator is a program that takes care of all the job related activities - it examines the

JES spool, selects an appropriate job for execution, executes the job in its address space, and

returns to the JES spool for another job.

The number of active initiators on a system determines the number of batch jobs that can be

multiprogrammed at once. Each initiator has one or more jobs associated with it; it executes

jobs only from those classes. Within a job class, initiators select jobs for execution based on

their priorities, which can range from 9 to 15. Jobs with higher priority values are selected for

execution before jobs with lower priority values. If two or more jobs have the same class and

priority, they are executed in the order in which they were submitted.

How a job is executed

The first thing after an initiator does after it selects a job for execution is to invoke a program

called the interpreter. The interpreters job is to examine the job information passed to it byJES and create a series of control blocks in the scheduler work area (SWA), a part of the

address spaces private area. Among other things, these control blocks describe all of the data

sets the job needs.

After the interpreter creates the SWA control blocks, the initiator goes through three phases

for each step in the job. First, it invokes allocation routines that analyze the SWA control

blocks to see what resources (units, volumes, and data sets) the job step needs. If the

resources are available, they are allocated so the job can process them. Next, the initiator

builds a user region where the users program can execute, loads the program into the region,

and transfers control to it. When the program is completed, the initiator invokes unallocation

routines, which release any resources used by the job step.

Input to a program need not always be got from a data set. You can also give it in the JCLitself. Input data processed in this way is called SYSIN data or in-stream data. Similarly, the

users program can produce output data thats not written to any data set but stored in the JES

spool; the program treats the data, called SYSOUT data, as if it was written to a printer.

How a jobs output is processed

Like jobs, SYSOUT will be assigned an output class that determines how the output will be

handled. Most likely, an output class indicates which printer can be used to print the output. Insome cases, an output class specifies that the output not be printed; instead, it is held so that

you can view it from a display terminal.

How a job is purged

After the jobs output has been processed, the job is purged from the system. Simply put, thatmeans that the JES spool space the job used is freed so it can be used by other jobs.

SUMMARY

A Job is the execution of one or more related programs in sequence


10/46

JCL


JES is the MVS component that keeps track of jobs that enter the system,

presents them to MVS for processing, and sends their spooled output to the

correct destination.

Test your Understanding

1). What is JCL?

A. One type of Programming Language

B. Operating System Component

C. Interface between Operating System and Application program

D. Sub System of Operating System

Answer:

1) B


11/46

JCL


Chapter 2: Structure of JCL statements

Learning Objective

The chapter shall achieve the following objective:

Understanding the basic structure of JCL statement

Introduction

JCL statements are coded in 80-byte records; however, only 72 of the 80 characters areavailable to code JCL. The last eight columns of each record are reserved for an optionalsequence number. Each JCL statement is divided into several fields, which are summarizedbelow in Fig 2.1.

Fig 2.1 - Basic structure of a JCL statement

The identifier field

The identifier field identifies a record as a JCL statement. For most JCL statements, theidentifier field occupies the first two character positions and must contain two slashes (//).There are two exceptions. First, the delimiter statement has a slash in column 1 and anasterisk in column 2 (/*). Second, the identifier field for a comment statement is threecharacters long: The first two columns contain slashes and the third contains an asterisk (//*)

The name field

The name field associates a name with a JCL statement. It is not mandatory everywhere; but itis always required on a JOB statement, where it supplies a name for your job. If you code aname field, it must begin in column 3, right after the identifier field. It consists of one to eightcharacters, which may be letters, numbers or national characters (#, @, and $) Also, the firstcharacter of a name should be a letter or a national character.

The operation field

The operation field follows the name field and specifies the statements function. JOB, EXEC,and DD are the different operation fields. You can code this field anywhere in the JCL, as longas it is separated from the name field by at least one blank. However, conventionally, we startthe operation field in column 12.

The parameters field

The parameters field begins at least one position after the end of the operation field and canextend into column 71. Within the parameters field, you code one or more parameters thatsupply information that influences how the statement is processed. When a parameters fieldconsists of more than one parameter, you separate the individual parameters with commas.MVS assumes that the parameters field is complete when it encounters a space so dontinclude a space by accident. If you need to include a space as part of a parameter value, youmust enclose the parameter value in apostrophes. A parameter may be one of two types:positional or keyword. A positional parameter must occur in a specific position within the

Identifier [Name] [Operation] [Parameters] [Comments]


12/46

JCL


parameters field. In other words, MVS interprets the meaning of a positional parameter basedon its position in the parameters field. If you need to omit a positional parameter, you mayneed to account for the missing parameter by coding an extra comma. You will see manyexamples later; so dont let it confuse you now. Most JCL parameters are keywordparameters. When you code a keyword parameter, you dont have to worry about its positionin the parameters field. Example CLASS=A, REGION=104K. The positions of the parametersCLASS and REGION can be interchanged and written as REGION=104K,CLASS=A.

The comments field

Following the parameters field, you can code brief comments in the comments field. Thecomments field begins in the position after the space that marks the end of the parametersfield and ends in column 71. MVS ignores what you code here, so you can record anycomments you wish. You can also use an entire line as a comment. For this, you need tocode //* starting from column one of the JCL record.

How to continue JCL statements

Often, you wont be able to fit all the parameters you need to code on a single 80-characterline. When that happens, youll have to continue the statement onto one or more additional

lines. Follow the steps given below when you want to code continuation lines: Break the parameter field after the comma that follows a parameter or sub-

parameter

Code slashes in columns 1 and 2 of the following line

Code the next parameter beginning anywhere in columns 4 through 16

SUMMARY

Format of JCL statements


1). Which of the following are Operation Fields in JCL statements?

A. JOB

B. EXEC

C. PROGRAM

D. DD

2). How many different types of Parameter Fields are there?

A. 4

B. 3

C. 2

D. 1

Answer:

1) A 2) A


13/46

JCL


Chapter 3: The JOB statement

Learning Objectives

Understanding JOB statement and its various parameters.

Functions of the JOB statement

The JOB statement (or the JOB Card), which must always be the first JCL statement coded

for a job, has three basic functions.

First, it identifies a job to MVS and supplies ajob name that MVS uses to refer to the job.

Second, it supplies accounting information so that MVS can determine who is responsible for

the job, and, if necessary, who should be billed for the computer resources the job uses.

Third, it supplies various options (like the Class parameter we discussed before) that influence

or limit how the job is processed.

A simplified job statement

Fig 3.1 - Structure of a Job statement

The above Figure 3.1 shows a simplified job statement (or card). Let us discuss each of these

parameters in detail.

Job name

You must always code a name on the JOB statement; the name you supply becomes the job

name MVS uses to identify your job. Depending on the installation and how you use the

system, there may be rules that govern how you can form job names. If you are submitting a

job from TSO or ISPF, you should follow a rigid format for creating job names: your TSO user-

id followed by a single alphanumeric character and the job name can be a maximum of eight

characters. For example, if your TSO id is TRG0001, then the job names can be TRG0001A

or TRG0001B.

Accounting Information

The accounting information parameter is an installation dependent positional parameter (some

dont require this at all!) that supplies information used to determine whos responsible for the

//jobname JOB [accountinginformation] [,programmername]

[,USER=user-id] [,PASSWORD=password]

[,NOTIFY=user-id] [,MSGCLASS=class]

[,MSGLEVEL=(stmt,msg)] [,TIME=(mins,secs)]


14/46

JCL


job and how its billing should be handled. Usually, this parameter consists of several positional

sub-parameters, the first of which is normally an account number.

Examples: (MMA2AB14,206)

Programmer Name

This is again installation dependent and may or may not be required. If required, you can code

upto a maximum of 20 characters. Also, you must enclose the programmer name field in

apostrophes if it contains special characters or spaces. Examples: Rick, 205-BILL (This is

enclosed in apostrophes because of the hyphen)

Please note that accounting information and programmer name are positional parameters. So,

you have to code them in the correct sequence and also replace them with a comma if you are

not coding any of the two parameters. All other parameters of the job card are keyword

parameters; so you need not worry about the order of sequence while writing them.

User and Password

You should have learned about RACF, which is a security manager that controls access to

MVS resources. If your job processes resources that are protected by RACF, you must be

authorized by RACF to use those resources. Two JOB statement parameters let you identify

yourself to RACF: USER and PASSWORD. The USER parameter specifies your RACF user-

id, which is usually the same as your TSO user-id. Similarly, the PASSWORD parameter

supplies a RACF password thats valid for the user-id you specify; it is usually the same as

your TSO password.

If you submit a batch job from TSO, your RACF user-id and password are automatically

passed on to the batch job. So you dont have to specify USER and PASSWORD on a JOB

statement submitted from TSO.

Class

You learnt earlier that initiators select jobs for execution based on job classes. Normally, when

you submit a job JES2/JES3 assigns a default job class that is determined by the reader that

processes the job. To change the default job class to a user specified one, you use the

CLASS parameter on the JOB statement. For example, the following statement will submit the

job in the class B.

//TRG0001Z JOB CLASS=B

Notify

If you submit a job from a TSO terminal, you can code the NOTIFY parameter on the JOBstatement so that youll automatically be notified when the job completes. For example,

suppose you code this JOB statement:

//TRG0001Z JOB NOTIFY=TRG0001

When the job completes, a message like the one below will be sent to your TSO terminal.

15.16.16 JOB 5969 $HASP165 TRG0001Z ENDED AT MVSPS1 CN (00)


15/46

JCL


MSGCLASS and MSGLEVEL

Whenever MVS executes a job, it lists the JCL statements and various system messages.

You can control these output messages with the help of two parameters, MSGCLASS and

MSGLEVEL.

MSGCLASS lets you specify an output class where the system messages can be directed, like

a printer. Example: MSGCLASS=X.

The MSGLEVEL parameter lets you specify the type of messages you want included in your

output.

MSGLEVEL has two positional sub-parameters:

MSGLEVEL = (stmt, msg)

The first, stmt, controls which JCL statements appear in the JCL statement listing. The

second, msg, controls the amount of message output that appears in the message log. The

default value is MSGLEVEL = (1,1).

Stmt Values

01

2

Print only the Job statementPrint only JCL statements, include those thatcome from procedures

Print only JCL statements submitted throughthe input stream; dont print statements fromprocedures

Msg Values

0

1

Print step completion messages only; dont printallocation and deallocation messages unlessthe job fails

Print all messages

Table 3.1 - Different values of MSGCLASS parameter

Time

The Time parameter helps you to limit the amount of time the job can use the processor. The

format of the Time parameter is

Time=(minutes, seconds)

Job Statement Examples

Finally, here are some examples of the JOB statement.

//TRG0001A JOB MMA2AB14,PATRICK

Account number MMA2AB14, programmer name PATRICK

//TRG0001A JOB (MMA2AB14,206),HARRY POTTER,MSGCLASS=A,

// MSGLEVEL=(0,1),TIME=(10,50)

//TRG0001A JOB ,HARRY P,USER=TRG0001,PASSWORD=PASXXXX


16/46

JCL


Note the comma before the programmer name. This is because we have not coded the

accounting information parameter, which is a positional parameter.

SUMMARY

The JOB statement must always be the first JCL statement coded for a job

It has three basic functions

It identifies a job to MVS and supplies a job name that MVS uses to refer to the

job

It supplies accounting information

It supplies various options like the Class parameter


17/46

JCL


Chapter 4: The EXEC statement

Learning Objectives

Understanding the EXEC statement and its parameters.

The EXEC statement

An EXEC statement identifies each step in a job. As you know, each program to be executed

by a job is called a Job Step.

Basic format of an EXEC statement

Fig 4.1 - Structure of the EXEC statement

The PGM parameter

In the PGM parameter, you specify the name of the program you want to execute for the job

step. Actually, the name you specify is the name of a member of a partitioned data set. The

member must be a load module (an executable file); that is, a module that has been compiled,

link-edited and is ready to execute.

Normally, the program you specify must be a member of a system load library, such as

SYS1.LINKLIB. However, youll learn in due course, how to use a private library to execute a

program that is written by you and that dont reside in any of the system libraries.

The PARM parameter

In the PARM parameter, you can code information that can be accessed by the program you

specify in the PGM parameter. This kind of information is usually used to influence the way the

program works. For example, many IBM-supplied programs, like utilities, compilers, and thelinkage editor, use PARM information to set various processing options. User programs can

use this facility too.

//stepname EXEC PGM=program-name

[,PARM=information]

[,COND=([(code,operator,step)][,EVEN/ONLY])]


18/46

JCL


The COND parameter

When a program completes execution (normally or with an abend), it passes a value called a

return code back to MVS.

The return codes usually follow the conventions described below in Table 4.1:

Return Code Meaning

0 Program ran to successful completion

4 Program encountered a minor error but was

able to recover

8 Program encountered a problem that prevented

successful execution

12 Program encountered a problem that prevented

successful execution; normally, this indicates a

more serious error than return code 8

16 Program encountered a serious error and was

not able to continue

Table 4.1 Different return codes and their meanings

Other return codes, especially for user-written programs, might indicate specific conditions

that were encountered. Although a return code can range in value from 0 to 4095, most return

codes are multiples of four between 0 and 16, according to the conventions described above.

In some cases, the value of a job step's return code may affect subsequent processing.

To illustrate, let us say you have two steps (or programs) in a job; the first program debits

money from an account and the next program credits the same amount of money (that was

debited in the first step) to another account. As you can clearly understand, the second step

(credit action) can be done only if the first step (debit) is successful.

Using the COND parameter, you can decide to execute a step based on the return code of the

previous step(s). The COND parameter lets you specify a return code and a relational

operator to determine whether to skip a particular job step. The format of the COND statement

is shown in Figure 4.2

Fig 4.2 - Format of the COND statement

The "code" value can be any decimal value in the range 0 to 4095; the "operator" can be oneof the following:

EQ - equal

LT - less than

LE - less than or equal to

NE - not equal to

GT - greater than

GE - greater than or equal to

COND=(CODE, OPERATOR, STEPNAME)


19/46

JCL


Let us see how the COND parameter works. Consider the example,

//STP0200 EXEC PGM=PRINT,COND=(4,LT,STP0100)

The above COND statement means that if 4 is LESS THAN the return code of STP0100,

then STP0200 will not execute. Let us say, that the return code of STP0100 is 8. Since 4 is

less than 8, STP0200 will not execute. On the other hand, if STP0100 returns 0 or 4, then

STP0200 will execute as 4 is not less than 0 or 4. Consider another example,

//stp0010 EXEC PGM=SORT, COND=(7,LT)

As you can see, we have not mentioned any step name in the COND parameter. The COND

parameter in the above example says to bypass STP0010 if 7 is less than the return code

issued by any previous step. You can also compare the return codes of more than one

previous specific step as below:

COND=((8,EQ,STEP1),(12,LE,STEP2))

There are two additional sub-parameters, EVEN and ONLY, that let you specify how an abend

affects job step execution. When you specify COND=EVEN, you tell MVS to execute the job

step EVEN if any of the previous steps has abended (that is, ended abnormally due to a

program failure). That is the step will be executed irrespective of the previous step(s) return

code(s).

On the contrary, COND=ONLY tells MVS to execute the job step ONLY if a previous step has

abended; if an abend has not occurred, the step is not executed. EVEN is useful for steps that

dont depend on the successful completion of previous steps. ONLY is useful for steps that

perform recovery processing that should be invoked only in the event of an abend.

SUMMARY

An EXEC statement identifies each step in a job


1). What is COND=EVEN?

A. execute this step even if any of the previous steps, terminated abnormally.

B. execute this step only if any of the previous steps, terminated abnormally.

C. Both

D. None of the following

Answer:

1) A


20/46

JCL


Chapter 5: The DD statement

Learning Objectives


Understanding the parameters of the DD statement

The DD statement

You should know that before a job steps program is executed, any data sets the program will

process are allocated. To describe the data sets that are used by the program, you code DD

(Data Definition) statements. Normally, you code one DD statement for each data set your

program will process. You code the DD statements after the EXEC statement that identifies

the job step.

Three formats of the DD statement

The DD statement is the most complicated of the JCL statements. The three simple formats of

the DD statement are given in the figure 5.1.

Fig 5.1 - The three different formats of the DD statement

There is one thing each of the DD statement formats have in common: each requires a

ddname. The ddname is a one to eight character symbolic name that the processing program

uses to refer to the file. In a COBOL program, the ddname is the name specified in the

ASSIGN clause of the files SELECT statement. In an assembler language program, it is the

1. DD statement for DASD data sets

//ddname DD DSNAME=data-set-name

// ,DISP=(status,normal-disp,abnormal-disp)

// [,UNIT=unit]

// [,VOL=SER=vol-ser]

// [,SPACE=unit,(primary,secondary,dir)]

// [,DCB=(option,option)]

2. DD statement for in-stream data sets

//ddname DD *

// [,DLM=XX]

3. DD statement for SYSOUT data sets

//ddname DD SYSOUT=*


21/46

JCL


name specified in the DDNAME parameter on the files DCB or ACB macro. Other

programming languages have similar facilities to specify a files ddname.

It is crucial at this point for you to realize that the ddname is not necessarily the actual name of

the file as indicated the files label. Instead, the ddname is an intermediate name that lets a

program refer to the file without using its actual data set name.

The DD statement for DASD data sets

The DSNAME parameter

The DSNAME parameter supplies the data set name as it is stored in the data sets label or in

the files catalog entry. It is always required for a permanent data set.

Example:

//INPUT DD DSNAME=TRG0001.CUSTOMER,

// DISP=SHR

To refer to a member of a partitioned data set, you code a standard data set name followed by

the members one-to-eight character name in parentheses. For example, consider this

DSNAME parameter:

DSNAME=TRG0001.TEST.COBOL (ORD1100)

Here, the member named ORD1100 in a partitioned data set named TRG0001.TEST.COBOL

is allocated.

You can abbreviate the DSNAME parameter as DSN.

The DISP parameter

The DISP parameter describes the "disposition" or status of a data set to MVS and to tell MVShow to handle the data set after the end of the step or job. The DISP parameter has three

positional sub-parameters: status, normal disposition, and abnormal disposition. Status

specifies

the current state of the data set, whether it needs to be created (NEW), or shared with other

jobs (SHR), or given exclusive access to the job (OLD) or records appended to the data set

(MOD).

Normal Disposition specifies what the system should do with the data set if the job step ends

normally; you can keep the file (KEEP), delete it (DELETE), catalog it (CATLG), uncatalog it

(UNCATLG), or retain it for use by a subsequent job step (PASS).

Abnormal Disposition specifies what to do if your program fails or abends; you specify any of

the values you can specify for normal disposition except for PASS.The following Table 5.1 shows the values you code for each of the three DISP sub-

parameters, describes each option, and explains how MVS selects default values for sub-

parameters you omit.

Status

NEW The data set does not exist and should be

created


22/46

JCL


Status

OLD The data set exists and should be allocated for

exclusive use

SHR The data set exists and should be allocated for

shared use

MOD The data set is allocated for exclusive use andis positioned at the end of the data, so

additional records may be added after the last

record

Table 5.1 - Values of the Status sub-parameter and their meanings

Normal and abnormal disposition

DELETE The data set is deleted and also uncataloged

KEEP The data set is retained

CATLG The data set is retained and a catalog entry is

made

UNCATLG The data set is retained, but its catalog is

removed

PASS Normal disposition only. The data set is

retained for use by a later job step

Table 5.2 - Values of the Normal and Abnormal sub-parameters

Default Values

Status If omitted, MVS assumes NEW

Normal Disposition Depends on the value specified or assumed for

status; if NEW, normal disposition is DELETE;

if OLD, SHR, or, MOD, normal disposition isKEEP

Abnormal Disposition Takes on the value specified or assumed for

normal disposition

Table 5.3 - Default values of the Disp parameter

The Table 5.2 specifies the values of the Normal and Abnormal sub-parameters and the Table

5.3 gives the default values of the Disp parameter. Table 5.4 gives the examples for the DISP

parameter.

DISP=SHR Allocate an existing data set for shared access;

normal and abnormal default to KEEP

DISP=OLD Allocate an existing data set for exclusive

access; normal and abnormal disposition

default to KEEP

DISP=MOD If the data set exists appends data to it;

otherwise, create it. Access is exclusive; normal

and abnormal disposition default to KEEP


23/46

JCL


DISP=(NEW,CATLG) Allocate a new data set and catalogs it;

abnormal disposition defaults to CATLG

DISP=(OLD,DELETE) Allocate an existing data set and delete it;

abnormal disposition defaults to DELETE

DISP=(,KEEP,DELETE) Allocate a new data set and keep it if the job

step ends normally, if the job step ends

abnormally, delete the data set

Table 5.4 - Examples for the Disp parameter

The UNIT and VOLUME parameters

The UNIT and VOLUME parameters work together to specify the location of a data set. UNITindicates the device where the data set resides (like, DASD or tape), and VOLUME indicatesthe VOL-SER of the data sets volume. You specify UNIT and VOLUME when you are creatinga new data set or when you are retrieving an existing uncataloged data set. For a catalogeddata set, the unit and volume information is stored in the catalog, so you dont need to code it

in the JCL.

Examples of Unit parameter:

UNIT=SYSDA to indicate that the referred data set is on DASD

UNIT=TAPE to indicate that the referred data set is on a tape drive

Also, there can be other values for the UNIT parameter, which depends on the installation that

you are working on.

The VOLUME parameter lets you specify which volume you want to allocate for your data set.

That is called a specific volume request. For a new data set, the VOLUME parameter is

optional; if you omit, MVS scans the eligible volumes based on how you code the UNIT

parameter to determine which volume is best to contain your file. That is called a non-specific

volume request.

On the VOLUME parameter, you specify a volume serial number, like this:

VOLUME=SER=ABC100

Here, the volume serial number is ABC100. Usually, you abbreviate the volume parameter,

like this:

VOL=SER=ABC100

Note that, if you code the VOLUME parameter, you should always code the UNIT parameter

too.

The SPACE parameter

For a new data set, you must code the SPACE parameter to tell MVS how much primary and

secondary space to allocate to the data set. The SPACE parameter format has two positional

parameters and the second positional parameter itself has three positional sub parameters.

Figure 5.2 depicts the Format of the SPACE parameter.


24/46

JCL


Fig 5.2 - Format of the SPACE parameter

The first parameter, unit indicates the unit of measure used for the space allocation. Most

often, you will allocate space in terms of cylinders (CYL) or tracks (TRK). For example, in the

space parameter

SPACE=(CYL,(10,1))

The unit of allocation is cylinders.

The second SPACE sub-parameter indicates how much space to allocate to the data set. It

has three positional sub-parameters that specify primary, secondary, and directory space. The

primary allocation indicates how many units of space to allocate for the data sets primary

extent.

If the file requires more space than the primary allocation, up to 15 secondary extents can be

allocated, each as large as the secondary amount you specify.

The third sub-parameter, directory allocation is only for partitioned data sets. It indicates how

large the librarys directory should be.

The directory allocation ignores the unit of measure you specify and allocates the directory

instead in units called directory blocks, each of which is large enough to define 21 members.

So, if you expect the library to hold 40 members, allocate two directory blocks. Here are a few

more examples of the space parameter:

SPACE=(CYL,(10,2))

SPACE=(TRK,(5,2))

SPACE=(CYL,(4,1,5)) Directory blocks is 5

SPACE=(unit,(primary,secondary,dir))


25/46

JCL


The DCB Parameter

The DCB parameter lets you specify the file characteristics that are stored in the files DataControl Block. You code the DCB parameter only for new files. The following table 5.5 shows

four commonly used DCB sub-parameters.

DSORG=XX Specifies the data sets organization, as follows:

PS Physical Sequential

PO Partitioned

DA Direct

IS Indexed Sequential

RECFM=n Specifies the format of the files records, as

follows

F Fixed length, unblocked

FB Fixed length, blocked

V Variable length, unblocked

VB Variable length, blocked

VBS Variable length, blocked, spanned

U Undefined

LRECL=n Specifies the length of the files records

BLKSIZE=n Specifies the length of the files records; for FB,

BLKSIZE is normally a multiple of LRECL

Table 5.5 - Commonly used DCB sub-parameters

All the above mentioned are keyword parameters, so you can code them in any order youwish.

There arent any default values for the DCB subparameters, but their values are often supplied

from the processing program, rather than from the DD statement. So, when you code a DD

statement to create a data set, you need to code only the DCB subparameters that arent

specified in the program you are executing. Often, the program supplies all of the DCB

information except block size, so youll need to specify BLKSIZE in the DD statements DCB

parameter. Here are a few examples:

DCB=(DSORG=PS,RECFM=F,LRECL=133) Sequential file with fixed-length 133-byte

unblocked records

DCB=(DSORG=PO,RECFM=FB,LRECL=80,BLKSIZ

E=800)

Partitioned data set with fixed-length 80-

byte records in 800-byte blocks

DCB=BLKSIZE=3200 Block size is 3200 bytes; other

information is supplied by the processing

program

Table 5.6 - Examples of the DCB parameter


26/46

JCL


The DD statement for in-stream data sets

As you know already, your program can also take input from in-stream data sets. The in-

stream data set is in the form of an 80-byte record and your program treats the data as if it

was a standard sequential file.

Let us consider a situation, where you have written a report program that will produce a report

of a customer master file based on the customer name given to it. As you will understand,there are atleast two input files, one is the customer master file and another file containing the

name(s) of the customers for whom the report will be generated. Now instead of giving the list

of customers name through a sequential file, you can enter the same customers name(s) in

the JCL itself, with the help of an in-stream data:

Figure 5.3 gives an example for a DD statement for coding in-stream data sets.

Fig 5.3 - Example of a DD statement for coding in-stream data sets

The above example shows a typical way of coding in-stream data sets. A DD * statement

indicates that the records that follow are data for the in-stream data set. Notice that there is

not data set name in the DD statement. After the DD * statement, the data is coded. Following

the data, a delimiter statement (/*) marks the end of data. Actually, the delimiter statement is

optional. If you omit it, the next JCL statement (// in columns 1 and 2) would indicate the end of

the in-stream data set.

The DATA parameter

What happens when you want to code JCL statements (that have // as the first two characters)

as part of in-stream data? As we discussed earlier, the next JCL statement would indicate the

end of the in-stream data set. This is where the DD DATA statement comes in. Simply put, if

you specify DATA instead of an asterisk, you must code a delimiter statement to mark the end

of your data. That way, JCL statement can be read as data. The following example shows how

//STP0100 EXEC PGM=REPORT

//CUSTMAST DD DSN=TRG0001.CUSTOMER.MAST.FILE,

// DISP=SHR

//NAMELIST DD *

ROBERT

ASHOK DESAI

ROSALINE

JAMES MATHEW

/*

//RPTFILE DD DSN=TRG0001.REPORT,

// DISP=(, CATLG, DELETE),

.

.

.


27/46

JCL


example shows how the DD DATA statement works. Figure 5.4 gives an example for the

DATA statement.

Fig 5.4 - Example for the DD DATA statement

The DLM parameter

Consider a situation (although very rare) where you need to have /* as a part of the in-stream

data. If you try to code it following the above example, it will not be possible, because, once

MVS encounters /*, it decides to mark the end of data. However, you can do this with the help

of the DATA, DLM (stands for Delimiter) parameter. The DLM parameter lets you to change

the two-character code used to represent the delimiter statement. That is, you can set the

delimiter to any two-character code other than /*. To illustrate, consider the following exampleas shown in Figure 5.5:

Fig 5.5 - Example for the DLM statement

Here, we have set the delimiter to be $$ using the DLM parameter. So, even if MVSencounters /*, it does not treat that as the delimiter; instead it looks for $$.

The DD statement for SYSOUT data sets

You learnt earlier that JES lets a program produce SYSOUT data sets, which are collected in

the JES spool space before they are actually printed. By coding the SYSOUT parameter on a

DD statement, you indicate that a file is a SYSOUT data set and should be processed by the

JES.

The SYSOUT parameter also specifies the output class associated with the SYSOUT data

set. For example, the DD statement:

//REPORT DD SYSOUT=A

Specifies that the data set identified by the ddname REPORT is a JES SYSOUT file with

output class A, which (depending on the installation) might be associated with any printer.

If you code an asterisk instead of an output class in the SYSOUT parameter, the output class

defaults to the class you specified in the MSGCLASS parameter of the JOB statement. That

way, the SYSOUT data will be printed with the jobs message output.

//SYSUT1 DD DATA

//STEP1 EXEC PGM=SAMPLE

//DD1 DD DSN=TRG0001.TEST, DISP=SHR

/*

//SYSIN DD DATA, DLM=$$

A0010100599CH45

A0010306324AB23/*

B0123034CD/*

$$


28/46

JCL


//REPORT DD SYSOUT=*

SUMMARY

To describe the data sets that are used by the program, you code DD (Data

Definition) statements


1). What does DISP=OLD denote?

A. exclusive control of the dataset

B. no exclusivity

C. dataset can be extended

D. None of the above

2). What is the function of DD DISP parameter?

A. Tells the system what to do with the dataset following normal termination of

the step

B. Describes the status of the dataset

C. Tells the system what to do with the dataset following abnormal termination of

the step

D. All of the above

Answer:

1). A 2). D


29/46

JCL


Chapter 6: Special JCL statements and Data sets

Learning Objectives


Understanding of special JCL statements

Understanding the JOBLIB and STEPLIB statements

The null statement

The null statement consists of slashes in columns 1 and 2 and no other data in the rest of the

record. The purpose of a null statement is to mark the end of a job. However, it is not required

as MVS, by default, processes your JCL till the last record and then terminates.

The comment statement

You can use comment statement to place comments in your job. They can be helpful to clarify

a confusing JCL statement or just to identify the purpose and operation of a job. Comment

statement begin with two slashes and an asterisk starting in column 1, like this:

//* THIS IS A COMMENT

DUMMY data sets

A dummy data set is a data set that doesnt really exist; MVS simulates the data set. By using

a dummy data set, you can execute a program that processes a file without actually having the

file present. When you use a dummy file, MVS simulates all of the housekeeping tasks

associated with file processing; but no data is transferred to or from the file. When a program

tries to read a record from a dummy file, MVS indicates an end-of-file condition. And when a

program writes a record to a dummy file, the data is discarded.

To understand the value of dummy data sets, consider a report preparation program, that

reads the records of a master file and produces five reports, each written to a different output

data set. Sometimes, you may need to run that program to get just one of the five reports. To

do that, you just specify DUMMY for the four output data sets that you dont need.

There are two ways you can specify a dummy file on a DD statement: you can code the

DUMMY parameter, or you can specify DSNAME=NULLFILE (or DSN=NULLFILE).

//SYSIN DD DUMMY

//CUSTMAST DD DSN=NULLFILE

Temporary data sets

Many jobs require data sets that exist only for the duration of the job or a job step. To

illustrate, consider a report-preparation job that requires two steps. The first step sorts a

master file into the sequence required by the actual report program, storing the sorted records

into a new file. Then, the second step reads this sorted file, produces the report and also

deletes the sorted file.


30/46

JCL


To process these kind of files, MVS provides a special kind of data set, called a temporary

data set, that simplifies the coding requirements for this kind of processing. Temporary data

sets are always deleted at the end of a job, unless you explicitly delete them sooner by

specifying DELETE in the DISP parameter.

How to use a single-step temporary data set

To allocate a work file - that is, a temporary data set thats created and deleted in a single job

step- you can code just a bare minimum of information on the DD statement. In fact, only two

DD statement parameters are absolutely required for a work file: UNIT, which should specify a

DASD device type like SYSDA, and SPACE.

You can code DISP=(NEW, DELETE) to indicate that the data set is created and deleted in

the same job step, but thats the default.

And the DSNAME parameter is NOT required since no other DD statement will have to refer

to the data set.

Besides these, you may also need to include a DCB parameter to supply file characteristics

such as block and record size if your program does not supply those.

Examples:

//WORK1 DD UNIT=SYSDA,SPACE=(CYL,(10,5))

Allocate a temporary data set on a SYSDA volume using 10 cylinders of primary and 5

cylinders of secondary space. DISP=(NEW,DELETE) is assumed.

//WORK2 DD

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

// DCB=BLKSIZE=3200

Allocate a temporary data set on a SYSDA volume using 10 cylinders of primary and 5

cylinders of secondary space. DISP=(NEW,DELETE) is assumed. The block size is 3200

bytes.

How to use a multi-step temporary data set

If your temporary data set is to be processed by more than one step of a job, there are a few

other coding details you need to know. Before that, there are two terms that you need to know:

pass and receive.

To pass a data set means to retain it to that a subsequent job step can process it. Passing adata set is like temporarily cataloging it. MVS retains the unit and volume information for

passed data sets in virtual storage, so subsequent DD statements that receive the passed

data set dont have to repeat that information.

To receive a temporary data set means to use a temporary data set that was previously

passed.

To pass and receive a temporary data set, you must assign it a data set name that follows a

specific format. In particular, the name can be no longer than eight characters; compound


31/46

JCL


names joined by periods are not allowed. In addition, the name must be preceded by tow

ampersands.

Examples: &&TEMP and &&ACCOUNT

The DISP parameter controls whether a temporary data set is passed so that it can be

received by a subsequent job step or deleted when the current step completes. In the job step

that creates the temporary data set, the DD statement should specify DSIP=(NEW, PASS).

Then, in subsequent job steps that process the data set, the DD statement should specifyDISP=(OLD, PASS). That way, the data set will be received and passed on to additional job

steps that need the data set.

In the last job step that processes the temporary data set, you should explicitly delete the file

by specifying, DISP=(OLD, DELETE). However, even if you dont explicitly delete the

temporary data set, MVS deletes it automatically when the job ends.

Figure 6.1 - Example of a multi-step temporary data set

Concatenating data sets

Sometimes, you want to treat two or more input data sets as if they were a single data set. To

do that, you concatenate them. (The word, concatenate means to link or chain together.)

Then, if the data sets are sequential input files, MVS processes the records in the

concatenated data sets in the order in which you concatenate them.

To concatenate files, you code the first DD statement just as you normally would. Then, you

code the next DD statement directly after it, but you dont code a DD name for it. Example:

//TRG0001 JOB MSGCLASS=X, CLASS=A

//STP0100 EXEC PGM=SORT


//SORTIN DD DSN=TRG0002.CUSTOMER.MASTER,

// DISP=SHR

//SORTWK01 DD UNIT=SYSDA,SPACE=(TRK,(1,1)



//SORTOUT DD DSN=&&SORTCUST,

// DISP=(NEW,PASS), UNIT=SYSDA,SPACE=(TRK,(1,1)

//SYSIN DD *

SORT FIELD=(2,13,A,20,1,A),FORMAT=CH

/*

//STP0200 EXEC PGM=IEFBR14


//CUSTMAST DSN=&&SORTCUST,DISP=(OLD,DELETE)

//SYSUDUMP DD SYSOUT=*


32/46

JCL


//TRANS DD

DSNAME=TRG0001.TRANS.WEEK1,DISP=SHR

// DD


// DD


Private program libraries - JOBLIB and STEPLIB

When an EXEC statement with the PGM parameter is executed, MVS searches a series of

system libraries to find the program you specify. This includes, among others, the system

program library, SYS1.LINKLIB

Sometimes you need to execute a program that exists in your private library. To do that, you

code a DD statement in your job stream to identify a private library that is searched before the

system libraries are searched. You can specify your private library as a job library or as a step

library.

A job library applies though out the job, that is, for all programs executed in the job, whereas a

step library is searched only for the step to which it applies.

To specify a job library, you code a DD statement using JOBLIB as the ddname. The JOBLIB

DD statement must be the first JCL statement following the JOB statement for the job; JES2

and JES3 statements can be placed between the JOB and the JOBLIB statement, but other

JCL statements cant. The following example will help you understand better.

//TRG0006F JOB CLASS=B,USER=TRG0006

//JOBLIB DDDSN=TRG0006.SAMPLE.LOADLIB,DISP=SHR

//STEP1 DD EXEC PGM=IEBGENER

.

.

.

//STEP2 DD EXEC PGM=REPORT

When a job library is in effect, MVS searches it first to locate any programs specified in the

EXEC statements. If a program is not found in the job library, the system libraries are then

searched. In the above example, the load modules of the programs IEBGENER and REPORT

are searched in the library TRG0006.SAMPLE.LOADLIB; if not found, MVS searches the

system libraries.

To specify a step library, you code a DD statement named STEPLIB after the EXEC statement

for the step in which you want the step library to apply.


33/46

JCL


//TRG0006F JOB CLASS=B,USER=TRG0006//STEP1 DD EXEC PGM=IEBGENER...//STEP2 DD EXEC PGM=REPORT//STEPLIB DD

DSN=TRG0006.SAMPLE.LOADLIB,DISP=SHR...

In the above example, the load module of the program IEBGENER is searched in the system

libraries only (as there is no JOBLIB or STEPLIB) and REPORT is searched in the library

mentioned against the STEPLIB ddname and if not found, the system libraries are searched.

If you include both a JOBLIB and a STEPLIB DD statement, they step library is searched

before the system libraries; the job library is ignored for the job step.

SUMMARY

A job library applies though out the job, that is, for all programs executed in thejob, whereas a step library is searched only for the step to which it applies.


1). JOBLIB should be specified

A. Anywhere in the JCL

B. Before JOB statementC. As the first JCL statement following the JOB statement

D. After STEPLIB

2). What is the function of the STEPLIB DD statement?

A. Identify a library to be searched for programs named in the EXEC statement

B. Identify a library containing executable job steps

C. Override the system step library within a job stream

D. All of the above

Answer:

1). C 2). D


34/46

JCL


Chapter 7: JCL Procedure

Learning Objectives


To understand the types of procedures in JCL

JCL Procedure

Simply put, a JCL Procedure is a pre-written segment of code that you can include in a job

stream. By using procedures, the amount of JCL coding you have to do is reduced.

To illustrate, consider the following piece of JCL.

//STP0100 EXEC PGM=INV3010


//INVMAST DD

DSN=TRG0001.INVENTRY.MASTER,DISP=SHR

//INVSEL DD DSN=&&INVSEL,DISP=(NEW,PASS),

// UNIT=SYSDA,SPACE=(CYL,(20,10))

//SELCTL DD DUMMY

//STP0200 DD PGM=INV3020


//INVMAST DD DSN=&&INVSEL,DISP=(OLD,DELETE)

//INVSLST DD SYSOUT=*

Here, two programs are invoked: INV3010 and INV3020. Suppose that these two programs

are required by many jobs throughout an application. Rather than duplicate this code in each

job, you could place the code in a procedure thats invoked by each job that needs to execute

the programs. That way, you reduce coding and the chance for errors.

Invoking a procedure

You invoke a procedure by specifying its name in an EXEC statement. In that respect,

invoking a procedure is much like invoking a program.

//STEP1 EXEC PROC=INV3000

In the above example, the procedure INV3000 is invoked. Note that PROC is a keyword and is

optional.

//STEP1 EXEC INV3000

An important point to realize is that even though you invoke a procedure with a single EXEC

statement, the invoked procedure may contain more than one EXEC statement. In other

words, by invoking a procedure, you can indirectly invoke more than one job step with a single


35/46

JCL


EXEC statement. The EXEC statements within a procedure, however, must all invoke

programs. You cannot invoke an in-stream procedure from another in-stream procedure.

Cataloged and in-stream procedures

There are two types of procedures: cataloged and in-stream. A cataloged procedure is stored

in a partitioned data set and may be invoked by any job on the system. In contrast, thestatements of an in-stream procedure appear in the job that invokes the procedure. An in-

stream procedure is available only to the job that contains it; other jobs on the system cannot

invoke it.

Most JCL procedures are cataloged so that they can be invoked by any job that needs them.

In-stream procedures are used mostly used for testing procedures.

Code a job that uses an in-stream procedure

Let us take the previously mentioned JCL piece as an example and see how we can code it as

an in-stream procedure.

An in-stream procedure consists of a PROC statement, followed the JCL for the procedure,

followed by a PEND statement

You place the in-stream procedure definition (that is, the PROC statement, the procedures

JCL statements, and the PEND statement) near the beginning of your job stream, before any

EXEC statement that refers to it. When the reader/interpreter encounters a PROC statement,

it treats the statements that follow as procedure statements; they are not executed, but

instead, are scanned for syntax errors and retained as a temporary procedure. When the

PEND statement is encountered, the reader/interpreter returns to its normal processing, and

the JCL statements that follow the in-stream procedure definition are interpreted as normal

JCL.

To understand, look at the code below:

//TRG0001X JOB USER=TRG0001X,CLASS=S,NOTIFY=TRG0001X

//INV3000 PROC//STP0100 EXEC PGM=INV3010


//INVMAST DD DSN=TRG0001.INVENTRY.MASTER,DISP=SHR


// UNIT=SYSDA,SPACE=(CYL,(20,10))

//SELCTL DD DUMMY

//STP0200 DD PGM=INV3020,COND=(0,LT)




// PEND

//STEPA1 EXEC INV3000


36/46

JCL


As discussed earlier, the EXEC statement between the PROC and PEND statements are not

executed when they are first encountered in the job stream. Instead, those statements are

saved as a procedure so they can be processed later. Then when STEPA1 EXEC statement is

processed, the two job steps in the in-stream procedure are executed: first INV3010, then

INV3020.

Code a job that uses a cataloged procedure

Suppose you want to use the above-mentioned JCL piece as a cataloged procedure, this is

what you need to do.

Store all the statements starting from the procedure name (INV3000) till the last statement of

the last step (that is, till the statement just before the PEND statement) as a member of a

partitioned data set. A cataloged procedure should never contain a PEND statement. The

PEND statement is used only in an in-stream procedure to mark the end of the procedure

statements. Also, the PROC statement is optional in a cataloged procedure, but it is a good

practice to code it. Another point to be remembered is that the name of the member of the

PDS should be same as the procedure name (here, it is INV3000.)

The JCLLIB statement

Now that we have stored the cataloged procedure in a partitioned data set, we should tell the

JCL that is invoking the procedure, the location of this cataloged procedure. That is, we should

give the name of the partitioned data set to MVS and ask it to look for the procedure in the

PDS. This is done with the help of the JCLLIB statement.

The format of the JCLLIB is given below in Figure 7.1 :

Fig 7.1 - Format of the JCLLIB statement

You code the JCLLIB statement after the JOB statement and before the first EXEC statement.On it, you list the data set name of your private procedure library. If you want, you can list

more than one procedure library; when you do so, MVS always searches the libraries in the

order in which you list them. And when listing more than one procedure library, always enclose

them in parentheses.

Also, note that there is a system library, SYS1.PROCLIB, which contains mostly system-

oriented procedures. This library is always searched, after your job searches the libraries

mentioned in the JCLLIB statement.

To illustrate the use of JCLLIB statement, here are a few examples:

Example 1

//XYZ JCLLIB ORDER=TRG0001.PROCLIBTRG0001.PROCLIB is searched followed by SYS1.PROCLIB

Example 2

//PRCLIBR JCLLIB

ORDER=(TRG0001.TESTPROC,TRG0001.PROCLIB)

TRG0001.TESTPROC is searched followed by TRG0001.PROCLIB followed by the system

library SYS1.PROCLIB

//name JCLLIB ORDER= ds-1, ds-2


37/46

JCL


SUMMARY

A JCL Procedure is a pre-written segment of code that you can include in a job

stream. By using procedures, the amount of JCL coding you have to do is

reduced.

There are two types of procedures: cataloged and in-stream

A catalogued procedure is stored in a partitioned data set and may be invoked by

any job on the system

The statements of an in-stream procedure appear in the job that invokes the

procedure


1). Which statement identifies a library from which the Cataloged procedures are to

be retrieved

A. JOBLIB

B. STEPLIB

C. PROCLIB

D. JCLLIB

2). What statement marks the end of an in-stream or Catalogued procedure ?

A. STREAM

B. SET

C. PROC

D. PEND

Answer:1) B 2) D


38/46

JCL


Chapter 8: Modifying a Procedures statements -

Overrides

Learning Objective


To modify the procedures using override

Introduction

Frankly, procedures wouldnt be very useful if they provided the same JCL statements every

time you invoked them. The biggest benefit of procedures is that you can make minor

adjustments to the JCL they contain to meet varying processing needs. There are several

ways to do that. Right now, we will see how to code JCL statements that change or

supplement the JCL statements contained in a procedure. Later, we will see how to code more

generalized procedures that use symbolic parameters.

There are three ways you can modify parameters of a procedure that you are invoking. First,

you can modify parameters coded on EXEC statements within the procedure. Second, you

can modify parameters coded on DD statements within the procedure. And third, you can add

entirely new DD statements within the procedure. Note that all these modifications hold good

for both in-stream as well as cataloged procedures

Modify EXEC statement parameters

To change a parameter that is coded on an EXEC statement within a procedure or to add a

parameter to one of the procedures EXEC statements, you code a parameter override on the

EXEC statement that invokes the procedure. The format of a parameter override is this as

shown in Figure 8.1.

Fig 8.1 - Format of a parameter override

To illustrate, consider the procedure INV3000. Let us say we want to change the COND

parameter of STP0200 in the procedure to something like COND(4,LT). We do this when we

invoke the procedure as:

//STEP1 EXEC INV3000, COND.STP0200=(4,LT)

Here, COND is the parameter and STP0200 is the step name of the procedure INV3000.

Modify DD statement parameters

You can also change DD statement parameters that are coded in a procedure or add

parameters to a DD statement. To do that, you code a DD statement following the invoking

EXEC statement in this format:

Parameter.procstepname=value


39/46

JCL


Fig 8.2 - Format of a DD statement modification

Then, the parameter values you specify are used on the DD statement in the procedure. For

example, if you code the statements

//STEPA EXEC INV3000

//INV3010.SYSOUT DD SYSOUT=C

The SYSOUT class for the SYSOUT DD statement is the INV3010 step is changed to C.

When you code an override DD statement, you dont have to override every parameter thats

specified in the procedure DD statement. For example, if you code the override DD statement.

//INV3010.INVSEL DD

SPACE=(CYL,(30,10))

Only the SPACE parameter of the INVSEL data set is changed. The other parameters are

used as they are coded in the procedure.

Adding a DD statement

Sometimes, youll need to add a DD statement to a procedure that you are invoking. There are

two cases where thats likely. The first is when a procedure is invoked repeatedly using a

different input or output file each time. In a case like this, the file may just be omitted from the

procedure, so you have to code a DD statement for it each time you invoke the procedure.

The second case is when a procedure requires in-stream data. In-stream data sets arent

allowed within procedures, so you have to provide them in the invoking JCL.

To add a DD statement to a procedure, all you do is code the DD statement following the

EXEC statement that invokes the procedure. For example, suppose you have not coded theDD name, INVMAST in the procedure. Since, the program INV3010 needs the file, INVMAST

for execution, let us code it in the JCL that executes the procedure INV3000. The statements

would be like this:

//STEPA EXEC INV3000

//INV3010.INVMAST DD

DSN=TRG0001.INVENTRY.MASTER,DISP=SHR

SUMMARY

There are three ways in which the parameters of a procedure that is beinginvoked can be modified

Parameters coded on EXEC statements within the procedure can be modified

Parameters coded on DD statements within the procedure can be modified

The new DD statements within the procedure can be added entirely

//procname.ddname DD parameter=value


40/46

JCL


Chapter 9: Symbolic parameters

Learning Objective


Using Symbolic Procedures for creating procedures for generalised use

Introduction

Although the facilities for modifying procedures that we have discussed so far are flexible, they

can be awkward to use. A better way to create procedures for generalized use is to provide

symbolic parameters.

Symbolic parameters

Symbolic parameters are very much like program variables. You need to substitute them with

values when you invoke the procedures.

Code symbolic parameters

To code a symbolic parameter in a procedure, you code an ampersand (&) followed by a one-

to-seven character name. For example, &FILENAM and &SPACE are valid symbolic

parameters.

In a procedure, you can code the symbolic parameter anywhere you code a JCL statement

parameter or sub-parameter value. For example, you could code the DD statement SYSOUT

parameter like this:

SYSOUT=&CLASS

Here, the value to the &CLASS symbolic parameter will be assigned when the procedure is

executed. We will see how to do this soon. Also, you can use the same symbolic parameter in

a procedure as many times as you wish.

Specify values for symbolic parameters

When you invoke a procedure, that uses symbolic parameters, you supply values for its

symbolic parameters by coding them on the EXEC statement, like this:

EXEC INV3000, CLASS=A

Here, the &CLASS in the procedure statement is replaced by A, the value supplied for the

&CLASS symbolic parameter. Notice that you do not include the ampersand in the symbolic

parameter when you code the EXEC statement that invokes the procedure.

If the value you are giving the symbolic parameter contains any special characters (like

commas, asterisks, and so on), you enclose the entire value in apostrophes, like this:


41/46

JCL


EXEC INV3000, CLASS=(,)

Here, (,) becomes the value of the &CLASS symbolic parameter.

To illustrate how symbolic parameters are used, see another version of the INV3000

procedure. Here, you can see that three symbolic parameters, &CLASS, &DEPT, and

&SPACE, are used to make the procedure more generalized.

Procedure

//INV3000 PROC

//STP0100 EXEC PGM=INV3010

//SYSOUT DD SYSOUT=&CLASS

//INVMAST DD DSN=&FRSTNODE..INVENTRY.MASTER,DISP=SHR


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

//SELCTL DD DUMMY

//STP0200 DD PGM=INV3020,COND=(0,LT)//SYSOUT DD SYSOUT=&CLASS



Invoking EXEC statement

//STEPA1 EXEC INV3000, CLASS=M, DEPT=TRG0001,

SPACE=5,1

Notice that there are two periods following the symbolic &FRSTNODE. You understand the

reason behind this; you need to understand the rules MVS follows when it substitutes symbolic

parameter values. In some situations, those rules can be confusing.

Symbolic parameter values

To illustrate how symbolic parameter values are used in a procedures JCL statements, thefollowing table shows seven examples. In each example, assume that VAR1 and VAR2 are

the two symbolic parameters and the procedure was invoked with this EXEC statement:

// EXEC proc-name, VAR1=TEST, VAR2=LIST

As you would infer, the value of &VAR1 is TEST and the value of &VAR2 is LIST

Example # As coded in procedure As interpreted by MVS

1 DSNAME=&VAR1 DSNAME=TEST

2 DSNAME=A&VAR1 DSNAME=ATEST


42/46

JCL


Example # As coded in procedure As interpreted by MVS

3 DSNAME=&VAR1(&VAR2) DSNAME=TEST(LIST)

4 DSNAME=&VAR1.A DSNAME=TESTA

5 DSNAME=&VAR1..A DSNAME=TEST.A

6 DSNAME=&VAR1&VAR2 DSNAME=TESTLIST

Handout JCL

Documents