Version 1.

TABLE OF CONTENTS

1.

Introduction................................................................................................................................... 3
Need of JCL ......................................................................................................................................... 3

2.

JCL Syntax .................................................................................................................................... 4

Syntax Rules ........................................................................................................................................ 4
Job Statement....................................................................................................................................... 5
Accounting Information parameter : ................................................................................................... 6
Programmers Name : .......................................................................................................................... 7
MSGLEVEL parameter : ..................................................................................................................... 7
TheMSGCLASS parameter : ............................................................................................................... 8
The Class Parameter : .......................................................................................................................... 8
The PRTY parameter ......................................................................................................................... 10
The TIME Parameter ......................................................................................................................... 11
The REGION parameter .................................................................................................................... 12
The ADDRSPC parameter ................................................................................................................. 13
The NOTIFY parameter .................................................................................................................... 13
The RESTART parameter ................................................................................................................. 13
The TYPRUN parameter ................................................................................................................... 14

3.

The EXEC Statement ................................................................................................................. 15

The REGION Parameter .................................................................................................................... 16
The TIME parameter ......................................................................................................................... 16
The ADDRSPC parameter ................................................................................................................. 17
The ACCT Parameter ........................................................................................................................ 17
The PARM Parameter ....................................................................................................................... 18
The COND Parameter ....................................................................................................................... 19

4.

The DD statement ....................................................................................................................... 24

The DSN Parameter ........................................................................................................................... 24
The DISP Parameter .......................................................................................................................... 25
The UNIT Parameter ......................................................................................................................... 29
The VOL Parameter........................................................................................................................... 30
The SPACE Parameter ...................................................................................................................... 31
The LABEL Parameter ...................................................................................................................... 33
The DCB Parameter........................................................................................................................... 34
Instream Data..................................................................................................................................... 38
The SYSOUT Parameter ................................................................................................................... 40
Concatenation .................................................................................................................................... 41
DUMMY Parameter .......................................................................................................................... 42
The JOBLIB DD Statement ............................................................................................................... 43
The STEPLIB STATEMENT............................................................................................................ 43
STORAGE DUMP ............................................................................................................................ 44

5.

PROCEDURE ............................................................................................................................. 46
SYMBOLIC PARAMETERS & SYMBOLIC OVERRIDES .......................................................... 50
THE PROC STATEMENT ............................................................................................................... 52
IN-STREAM PROCEDURES........................................................................................................... 53

6.

UTILITY ..................................................................................................................................... 54
IEFBR14 UTILITY ........................................................................................................................... 54
IEBGENER UTILITY ....................................................................................................................... 55
SORT UTILITY ................................................................................................................................ 57

1. Day-Wise Schedule
Day 1 Theory

Introduction to JCL
Structure of JCL; why is JCL?
-Syntax of in JCL
-JOB statements and its various parameters

Day 1 Lab

Assignment 1

Day 2 Theory

EXEC statement and its various parameters

COND parameter at JOB and EXEC statement

Day 2 Lab

Assignment 2 and 3.

Day 3 Theory

DD statement and is various parameters

Other forms of DD statements
-JOBLIB/STEPLIB statement
-Storage Dump
SYSUDUMP
SYSMDUMP
SYSABEND

Day 3 Lab

Assignment 4 and 5.

Day 4 Theory

Procedures
- Cataloged procedure
- Instream procedure
- Regular and Symbolic overrides

Day 4 Lab

Assignment 6 and 7

Day 5 Theory

Utilities
-IEFBR14
-IEBGENER
-SORT

Day 5 Lab

Assignment 8 and 9.

1. Introduction
JCL is a language in which the users of a computer systems describes to that
system the requirements of their jobs.

Provides a primary interface between user and the JES.

Used to perform batch mode processing under MVS.

Within a job, JCL provides the specification necessary for MVS to process the job.
Specifications of a job are :

User identity
Data file identity
Resource requirement
Error handling

Need of JCL

Request execution of program under MVS environment

Sets the requirement for a job

2. JCL Syntax
Syntax Rules
General JCL command format
//name

operation parameter1,parameter2

Comments

where;
name
: is not to exceed 8 characters
operation : generally begins in column 12
parameter : generally begins in column 17
comments : are separated from the parameters by a blank
Parameters are broadly classified into 2 categories viz. Positional and Keyword.
A positional parameter is identified by its position relative to other parameters in the
operand field.
Rule 1 : All positional parameters are coded first in the operand field and in their
proper sequence.
e.g. : p1,p2,p3
p1,p3,p2

illegal because they are not in sequence.

A keyword parameter is identified by a keyword followed by an equal sign (=) and

variable information.
Rule 2 : A keyword parameter follows positional parameter and can be coded in any
order.
e.g. : p1,p2,p3,k1=,k2=,k3=
p1,p2,p2,k3=,k2=,k1=
Both are valid.
Note : All parameters are separated by commas with no intervening spaces.
Rule 3 : The absence of positional parameter is noted by a comma(,) coded in its
place, except for the last or remainder of the positional parameter are not
present. The placeholder commas do not need to be coded.
e.g. : p1,,p3,k1=,k2=,k3=
p1,k1=,k2=,k3=

place holder comma required

Rule 4 : Both positional parameters and variable information for keyword parameters
may be composed of subparameters. The subparameters may be either
positional or keyword. Subparameters must be coded as a list. The list must

be enclosed in paranthesis unless only one subparameter is coded. When

only one subparameter is coded the paranthesis are optional.
e.g : p1,(sp1,sp2),p3,k1=(sk1,sk2),k2=,k3=
p1,(sp1),p3,k1=(sk1),k2=,k3=
or p1,sp1,p3,k1=sk1,k2=,k3=
Rules for continuation : The JCL statement can be continued in a simple way. The
statement must be interrupted at a comma. This means that the last valid character of
the line must be a comma followed by atleast one blank. Then the statement can be
continued into the next line by coding two slashes at the beginning of the line and
continuing the parameter field starting anywhere between positions 4 and 16 (4 and
16 included). Note that the comma which indicates continuation, is not an extraneous
character but part of the statement.

//dd1
//
//dd1
//
//
//

dd dsn=da0001t.empfile,disp=(new,catalg,delete),
unit=sysda,space=(trk,(5,1)),dcb=(lrecl=80,recfm=fb,blksize=800)
dd dsn=da0001t.empfile,disp=(new,catalg,delete),
unit=sysda,space=(trk,(5,
1)),dcb=(lrecl=80,recfm=fb,blksize=800)

Eg. 2.1 Examples of valid continuation

Job Statement
The job statement identifies job to the O/S with the job name operand.
The format of the JOB statement is :
//jobname JOB parameters

Note that jobname cannot exceed 8 characters and is usually the userid (loginid)
//da0001ta JOB parameters

Loginid is generally 7 characters, so you need to add a suffix lest the system prompts
you to enter the character when a job is submitted to the system for execution.
When a job is submitted to the system, a job number is also assigned so that the job
can be further identified. This way jobs with the same name can be uniquely
identified. Jobs with the same name cannot execute simultaneously. If several jobs
with the same name are submitted they execute sequentially even if additional jobs
could be executing. Jobs waiting to run because of this time conflict are shown in hold
status.
Remark : 1 A JOB statement must be at the beginning of every job submitted to the
system for execution.
5

2 A JOB statement must have a name. The absence of a jobname will result
in a JCL error.
The rest of the JOB statement contains postional parameters followed by keyword.

Accounting Information parameter :

It is a positional parameter. If present (it normally is), it must be the first in the
parameter field. It can have a maximum of 142 characters (including parenthesis and
commas but not apostrophes) . It is used to tie the resources used by the job to the
appropriate account.
//jobname JOB ([account-number][,additional-accounting-information]),parameters

The account-number is an alphanumeric field from 1 to 4 characters long (many

installations permit the use of more than 4 characters.
Additional-accounting-information is installation dependent. Many of the fields are
not very important and are not often used. Note that except for the account number,
all other subparameters can be supplied through the /*JOBPARM JES2 control
statement. (JES2 control statements are not covered in this book, refer to IBM
Manual.
e.g :
//da0001ta JOB LA2719,parameters

LA2719 is the account number for the training dept. This varies from project to
project. Therefore, consult the right person.
If any portion of the field contains a special character other than a , (comma) or a
- (hyphen), the portion must be enclosed in apostrophes. If an ampersand or quotes
is used in the accounting field, code two consecutive ampersands or quotes.
e.g. :1
//da0001ta JOB LA2719,TRG
or //da0001ta JOB (LA2719,TRG)

e.g. :2
//da0001ta JOB (LA2719,P&&G)

The system assumes a single ampersand.

Remark: An installation has the option of making the account number mandatory and
most installations do. If so, its absence will cause a JCL error.

If the account number is incorrectly specified, in this case its not JCL error.
However when job is submitted to the system for execution, we get the
message JOB NOT RUN in the sysout.

Programmers Name :
Following the accounting information parameter, another positional parameter, the
programmers name can be coded. The installation determines if this parameter is
required or not. If required, it must be coded immediately after the accounting
information, and its omission will cause a JCL error. The programmers name cannot
exceed 20 characters. If it contains any special characters other than a hyphen and a
period in the middle or the beginning (but not at the end) of the name, the name must
be enclosed in apostrophes. The apostrophes are not added to the length of the name.
If a name contains an apostrophe (e.g., DCOSTA), two apostrophes must be coded.
They count as one character in the length of the name.
e.g. : 1
//da0001ta JOB LA2719,Pai,parameters

e.g. : 2
//da0001ta JOB LA2719,DCOSTA,parameters

Note : Accounting information and Programmers name are the only two positional
parameters in the JOB statement, what follows after that are keyword
parameters.

MSGLEVEL parameter :
This parameter specifies whether the submitted JCL and/or JCL-related messages
should be shown on the jobs output.
General syntax
MSGLEVEL=([jcl][,messages])
Jcl - 0, 1, or 2
0
1

Keyword parameter

- only the JOB statement will be shown

- All JCL will be shown
instream
expanded cataloged procedures
symbolic parameter substitutions
- All JCL will be shown, but not expanded procedure listing.(It will show what
output we are expecting)

Messages 0 or 1
0 - No messages will be shown i.e information about step completion.
1 All messages will be shown viz allocation and termination messages.
7

The messages subparameter can be thought of as On (1) or Off (0) .

Remark:
1. If the entire parameter or either of the two fields is omitted, an installation-defined
default is assumed.
MSGLEVEL=1 ------------------MSGLEVEL=(1,default)
MSGLEVEL=(,1) ------------------MSGLEVEL=(default,1)
Parameter omitted ------------------ MSGLEVEL=(default,default)
2. If the job encounter an ABEND failure, the second field always defaults to 1 even
if coded as 0

TheMSGCLASS parameter :
This parameter assigns a sysout class to the Job log. The job log consists of what is
what is known as system or JES datasets:
JES2 or JES3 log
JCL and its associated messages
Allocation and Termination messages
MSGCLASS

- indicates the format of output

- specifies output class for
job log (collection of all operations)
list (collection of all printed output like compiled listing)

General Syntax
MSGCLASS=class
Keyword parameter
Class - A character from A to Z or a number from 0 to 9 (in all 36 classes)
MSGLEVEL parameter indicates whether or not one wishes to print the JCL
statements and allocation messages. The MSGLEVEL can save paper. After a job is
debugged, there may be no need to print all the JCL and allocation messages each
time it runs. To reduce printing to a minimum, one may wish to MSGLEVEL=(0,0).
All datasets to be printed must have a class. This is normally called the output class,
sysout class or message class. Sysout datasets created by the executing programs are
assigned a class by the SYSOUT DISTINCT statement. After the job terminates, the
sysout datasets, which are saved on the spool pack , will be selected and printed by a
JES2 or JES3 component called a printer. There are several printers available, and
each one is assigned one or more sysout classes (from 1 t0 36). The sysout class can
be thought of as a print-scheduling class.
Remark : If the MSGCLASS parameter is omitted, an installation-defined default will
be used.

The Class Parameter :

This parameter assigns a class to a job.
8

General Syntax
CLASS=jobclass
Keyword parameter
Jobclass A letter from A to Z or a number from 0 to 9 ( in all 36 classes)
The jobclass affects jobs processing in these ways :
When job is submitted, it is placed in an input queue where it waits to be
executed. Queues can be thought of as waiting lines for jobs. Each job class
has its own input queue
Job waits in the input queue until it is selected by an initiator to be
processed. Each initiator is set to a list of job classes that it can select from.
Simply put Jobclass identifies the nature of the job
- short running or long running
- resource utilization
Each installation group jobs that have like characterstics into classes. By segregrating
jobs with similar characterstics, an installation can maintain a good mix of the jobs
running at a given moment. This maintains system throughput and efficient use of
resources.
Let us look at the sample table below
Class
Code
1
2
A
B
C

Run Time (in

minutes)
5
>5
5
<5
>5

Tape

Disk

Production

X
X
X
X
X

X
X
X
X
X

X
X

Test

X
X
X

Table 2.1
In the sample table, the job classes were separated by
- Production vs Test
- Tape vs disk
- expected run time
The example shows some of the characteristics an installation may look at, but
certainly not all. Also, resources used by a job may be critical at one installation, but
not at another. What is important is that one should follow installations standard.

For e.g. Suppose the default Class is A

This Job statement
//DA0001TA JOB LA2719,SATYA,MSGCLASS=A,MSGLEVEL=(1,1)

is equivalent to
//DA0001TA JOB LA2719,SATYA,MSGCLASS=A,MSGLEVEL=(1,1),CLASS=A

Remark :
Frequently, installations develop a testing class structure that favors short-running
jobs with minimal resource requirements and penalize long-running jobs with heavy
resource demands. This is achieved by assigning the class used by trivial jobs to many
initiators and class used by heavy jobs to few. To keep people honest, the CLASS
parameter in a testing environment is often tied to several other parameters such as
TIME,PRTY, REGION, etc. For example, a job coding CLASS=A can be given
TIME=(0,5),PRTY=6. Note that the values assigned to these parameters is not shown
in the output. However, if any of these parameters were coded in the JOB statement,
they would be ignored.
Most installation assigns a default job class if the Class parameter is omitted.

The PRTY parameter

This parameter determines the scheduling priority of a job in relation to other jobs in
the job input queue of the same class.
General Syntax
PRTY=priorty
- keyword parameter
Priorty a number from 0 to 15 for JES2 or 0 to 14 for JES3
The PRTY parameter is used to define the jobs input class selection priority :
The higher the number, the better (greater) the priority
The PRTY parameter simply controls the jobs position in the input queue. It
has no affect on the jobs performance.
Jobs with higher priorities will be selected before jobs will lower priority
A jobs priority does not affect its performance. Once the job is selected for
execution, the priority function is finished.
Two jobs having same job class and same priority will be executed in
sequence
Comparing the PRTY parameter of two jobs belonging to different classes is
meaningless.
Remark :
This parameter is of seldom use in a testing environment. Since high priorty would be
used by practically all users negating the very purpose the parameter,. Therefore, in
most installation the PRTY, whether coded or not, will default to an installationdefined value or will be supplied by the CLASS parameter.

10

The TIME Parameter

This parameter specifies the total amount of CPU time that all steps in a job can use
collectively.
General Syntax
TIME=([minutes][,seconds] | [1440])

keyword parameter

minutes - a number from 1 to 1439

seconds - a number from 1 to 59
1440 - The job will not be timed for CPU. It was also not time out (S522
ABEND failure) when a single wait state exceeds the installation-defined
limit (often 10 to 20 minutes). Note that TIME=1440 is rarely used, and
most installation disallow its use in a testing environment. TIME=1440
should be used by an on-line system like CICS OR ADS/O.
When the TIME parameter is omitted, an installation-defined default will be used.
This default is usually ver high and unlikely to cause an S322 ABEND failure unless
the program goes into an endless loop.
If the TIME parameter is also coded in the JOB statement, both will be in effect and
either can cause a S322 ABEND failure. It is not advisable to use them both.
CPU time is the amount of time that the computer devoted to the job after it was
selected for processing. It is not the amount of time it was in the machine.
TIME parameter puts an upper limit on the amount of CPU time that a job may use.
e.g : TIME=(3,20).
All the steps in the job are allowed collectively 3 minutes and 20 seconds of CPU
time. If this amount is exceeded, the result will be a S322 ABEND failure.
If the TIME parameter is coded using only minutes, seconds defaults to zero. For
example, TIME=5 is the same as TIME=(6,0).
If the TIME parameter is coded using only seconds, minutes defaults to zero. For
example, TIME=(,6) is the same as TIME=(0,6).
The TIME parameter is intended almost exclusively for a testing environment and
should be coded to preempt the program going into CPU loop.
The TIME parameter can also be supplied by the CLASS parameter. When the TIME
parameter is omitted and the CLASS parameter does not supply it, the job will not be
timed for CPU time. However each step will be individually timed (TIME parameter
at EXEC statement or its installation-defined default), unless it contains TIME=1440.
Remark:

11

It is possible for a job to get more CPU time than that is specified in the TIME
parameter by a maximum 10.5 seconds. This is due to the fact that the system checks
for violations every 10.5 seconds.

The REGION parameter

This parameter specifies the limit of available storage for each of the steps in the job
within the jobs address space. i.e., the amount of storage the job is allocated. Or, in
other words, it specfies the amount of storage needed by the step (within the job) with
the highest storage requirements.
General Syntax
REGION=value{K|M}
keyword parameter
Value 1 to 2096128 if K (1024 bytes) is used. It should be an even number, it will
be rounded to the next higher even number.
Value 1 to 2047 if M (1024K or 1048576 bytes) is used. M is not available to
MVS/SP, only to MVS/XA and MVS/ESA
When a job is selected by an initiator for execution, it is given an address space of 16
MB ( minus what MVS/SP uses) .Incase of MVS/XA, job is given an address space of
2GB. And all of it is available to the jobs steps. However a step normally requires
only a small fraction of this huge storage, below the 16M line. An ordinary COBOL
or any other language program seldom needs more than 1000k. This is normally what
the value in the REGION parameter represents in the installations. Few jobs like
CICS, IMS, DB2 need storage above the 16M line. An ordinary batch job seldom has
such high requirements and, as a result confined to storage below the 16M line.
Storage availability below this line varies in different installations, but is generally
around 8MB in MVS/SP and around 9 MB in MVS/XA. Storage above the 16M line
can be acquired by coding a value higher than 16M. However, it may be restricted by
the installation to only those jobs that need it.
E.g 1.
Assume REGION=1000K was coded in the JOB statement. All the steps in the job are
limited to this value. If more storage is needed, the usual result is S878 or S80A or
S804 ABEND failure. If one of these failures occurs, the user must increase the value
in the REGION parameter.
E.g 2.
REGION=10M
When the amount of storage requested in the REGION parameter is higher than the
address space can provide, an S822 ABEND failure will result.
Note that for job run under MVS/SP, the entire address space is limited to 16M, of
which usually less than 8M is available to the user. In case of MVS/XA, the entire
address space is limited to 2G, of which usually around 9M is available to the user.

12

E.g 3.
REGION=0K (or 0M) is coded the entire address space except for those areas used by
MVS/SP (or MVS/XA) is available.

The ADDRSPC parameter

This parameter specifies if the job will use real or virtual storage.
General syntax
ADDRSPC={VIRT|REAL}
VIRT The REGION will be virtual storage and is the default
REAL The REGION will be real storage.
Remark:
This is the rarely used parameter because of the default. Note that ADDRSPC=REAL
is a parameter that is disallowed in practically all installation because it can cause
serious performance problems for other jobs.

The NOTIFY parameter

This parameter informs a TSO user when his or his job terminates.
General Syntax
NOTIFY=userid
keyword parameter
Userid A name from 1 to 7 character, identifying a valid TSO user.
E.g NOTIFY=DA0001T
If coded, a message will appear on the users TSO terminal indicating if the job
abended or got a JCL error. If the job terminates while the user was logged off, the
message will appear when the user logs on. If the NOTIFY parameter is omitted, no
message will appear when the job terminates.
Remark :
You can also code NOTIFY=&SYSUID instead of your userid.

The RESTART parameter

This parameter requests that a job begin its execution with a step other than the first
one.
General Syntax
RESTART={stepname|procexec.stepname| *}

keyword parameter

Stepname
The name of the step where execution is to begin.
Procexec.stepname The name of the EXEC statement invoking a procedure and the
name of the step within the procedure where execution is to begin
13

Note : Procedures will be covered on day 4.

* - indicates that execution of the job is to begin with the first step and is the default.
Things to avoid :
Duplicate
name
for
EXEC
statements
invoking
procedure.
If
RESTART=procsexec.stepname is used, the first procexec found will be used.
Duplicate stepnames within procedure. If RESTART=procsexec.stepname is used,
the first stepname within procexec found will be used.
Duplicate stepnames. If RESTART=stepname is used, the first stepname found
will be used.
EXEC statements (invoking procedures or any step) without names. No restart is
possible
Creating and passing temporary datasets. Such datasets are always deleted by the
time the job terminates and, therfore unavailable for restarting.
Creating and passing nontemporary datasets. If such a dataset is not received and
assigned a permanent disposition, Job Termination will delete it, making restart
impossible

The TYPRUN parameter

This parameter requests special processing for the job.
General Syntax
TYPRUN={HOLD|JCLHOLD|SCAN|COPY}

keyword parameter

HOLD - Job will held (and not executed temporarily) until the operator uses a
command to release. A job will be held in the input queue only if syntactically correct
JCLHOLD (JES2 only) Job will held (and not executed) until the operator uses a
command to release it. Note the job will be held in queue if it is syntactically
incorrect. Rarely used
SCAN Job will be scanned for all syntactical JCL errors but will not execute.
COPY (JES2 only)- Job will be printed. No execution and no syntax checking takes
place. Rarely used.

14

3. The EXEC Statement

An EXEC statement identifies a step during the reading the reading process when a
job is submitted to the system. When an EXEC is found, the system accepts all JCL
statements that follow as belonging to the step, until a delimiter is found. There are
four possible delimiters for a step during the reading process :
Another EXEC statement in the input stream. It signals the end of (reading)
one step and the beginning of (reading) of another.
A JOB statement
A null statement i.e //. All JCL statements will be ignored except for a JOB
statement.
End-of-file on the reading device, meaning there are no more statements to
read.

General Syntax
//[stepname] EXEC parameters
stepname is optional. When the stepname is omitted no reference can be made. A job
can contain a maximum of 255 steps.
The PGM Parameter
The PGM parameter identifies the program to be executed in a step.
General Syntax
PGM=pgmname

positional parameter

Pgmname - Name of the program to be fetched from the loadlibrary and executed.
The program specified in PGM is always a member of library (PDS). This is
commonly known as an executable program library or a load library. The EXEC
statement can identify only the member. It has no parameter available to identify the
library. If necessary, this must be done by using a JOBLIB or a STEPLIB DD
statement.
E.g.3.1
//da0001ta job la2719,SATYA,msglevel=(1,1),notify=&sysuid
//joblib
dd dsn=da0001t.lib.loadlib=shr
//s1
exec pgm=ass1

OR
//da0001ta
//s1
//steplib

job la2719,SATYA,msglevel=(1,1),notify=&sysuid
exec pgm=ass1
dd dsn=da0001t.lib.loadlib=shr

15

If neither JOBLIB or STEPLIB is coded, the system searches certain predefined

libraries. They are the system default libraries. If the specified member is found, it is
executed. If not found, the result is S806-04 ABEND failure.
The following keyword parameters can be specified at the EXEC statement. They are
REGION, ADDRSPC, TIME , PARM and ACCT.

The REGION Parameter

This parameter specifies the limit of available storage for the step within the jobs
address space.
General Syntax
REGION=value{K|M}
keyword parameter
Value 1 to 2096128 if K (1024 bytes) is used. It should be an even number, it will
be rounded to the next higher even number.
Value 1 to 2047 if M (1024K or 1048576 bytes) is used. M is not available to
MVS/SP, only to MVS/XA and MVS/ESA
If the REGION parameter is omitted , the REGION parameter in the EXEC
statements within the job will be used. If it is coded in neither the JOB nor the EXEC
statement, an installation-defined default will be used. The default value of most
installations is between 500K and 1000K.
If the REGION parameter is coded in both the JOB and an EXEC statement within
the job, the value in the JOB statement will be used.
The REGION parameter in the JOB statement is used much more often than the one
in the EXEC statement. Coding the same value for all steps would have the same
effect as the REGION parameter in the JOB statement.
E.g. 3.2
//da0001ta
//s1
//steplib

job la2719,SATYA,msglevel=(1,1),notify=&sysuid
exec pgm=ass1,region=500k
dd dsn=da0001t.lib.loadlib=shr

The TIME parameter

This parameter specifies the total amount of CPU time that the step is allowed to use.
General Syntax
TIME=([minutes][,seconds] | [1440])

keyword parameter

minutes - a number from 1 to 1439

seconds a number from 1 to 59

16

- The step will not be timed for CPU. It was also not time out (S522
ABEND failure) when a single wait state exceeds the installation-defined
limit (often 10 to 20 minutes). Note that TIME=1440 is rarely used, and most
installation disallow its use in a testing environment. TIME=1440 should be
used by an on-line system like CICS OR ADS/O.

1440

When the TIME parameter is omitted, an installation-defined default will be used.

This default is usually very high and unlikely to cause an S322 ABEND failure.
If the TIME parameter is also coded in the JOB statement, both will be in effect and
either can cause a S322 ABEND failure. It is not advisable to use them both.
Remark :
It is possible for a step to get more CPU time than that is specified in the TIME
parameter or the default by a maximum 10.5 seconds. This is due to the fact that the
system checks for violations every 10.5 seconds.
E.g 3.3

//da0001ta
//s1
//steplib

job la2719,SATYA,msglevel=(1,0),notify=&sysuid
exec pgm=ass1,region=500k,time=(,3)
dd dsn=da0001t.lib.loadlib=shr

The ADDRSPC parameter

This parameter specifies if the step will use real or virtual storage.
General syntax
ADDRSPC={VIRT|REAL}
VIRT The REGION will be virtual storage and is the default
REAL The REGION will be real storage.
If the ADDRSPC parameter is also coded in the JOB statement, the value in the JOB
will be used.
Remark:
This is the rarely used parameter because of the default. Note that ADDRSPC=REAL
is a parameter that is disallowed in practically all installation because it can cause
serious performance problems for other jobs.

The ACCT Parameter

The parameter specifies accounting information to be used for the step as opposed to
the accounting information in the JOB statement.

17

General Syntax
ACCT=(acctno [additional-acct-info])

keyword parameter

Acctno The account number to be used for the step

Additional-acct-info same as in the JOB statement.
The ACCT parameter is seldom used, and when it is, only the account number
normally appears. This is used to charge resource utilization for a step to a different
account number other than the one coded in the JOB statement.
If an account number is also coded in the JOB statement, the account number in the
EXEC statement will be used.
E.g 3.4
//da0001ta job la2719,SATYA,msglevel=(1,0),notify=&sysuid
//s1
exec pgm=iefbr14,acct=(es0013,hr4200,iefbr14)
//dd1
dd dsn=da0001t.pai.empfile,disp=(mod,delete),
//
space=(trk,0),unit=sysda

The PARM Parameter

This parameter provides a way to supply data of limited size to the executing program
General Syntax
PARM=string

keyword parameter

String A string of characters up to 100. If commas are part of the string, the entire
field must be enclosed in parenthesis (or apostrophes). If any portion of the string
contains special characters (other than hyphen), that portion of the entire string must
be enclosed in apostrophes. Note that any parenthesis used count toward the
maximum. Apostrophes do not.
All information after the = in the PARM parameter, excluding apostrophes, will be
saved by the system within the steps own region. When the program begins
execution by using the appropriate instructions, it can find the saved information in
storage.
In COBOL, the following must be coded :
LINKAGE SECTION.
01 PARM.
05 PLENGTH
PIC S9(04) COMP.
05 INFO
PIC X(05).
PROCEDURE DIVISION USING PARM.
0000-MAIN-PARA.

18

Note that any valid name may be used in place of PARM. The string is stored in
PARM and the PLENGTH is set to the length of the string.

E.g 3.5
//da0001ta job la2719,SATYA,msglevel=(1,1),notify=&sysuid
//s1
exec pgm=ass2,parm=g2 ,time=(,3)
//steplib
dd dsn=da0001t.lib.loadlib=shr

Rules for continuation

E.g 3.6
//da0001ta job la2719,SATYA,msglevel=(1,1),notify=&sysuid
//cob
exec pgm=ikfcbl00,region=1024k,
//
parm=(notrunc,nodynam,lib,size=4096k,buf=116k,
//
apost,nores,seq)
.
.
or
//da0001ta job la2719,SATYA,msglevel=(1,1),notify=&sysuid
//cob
exec pgm=ikfcbl00,region=1024k,
//
parm=(notrunc,nodynam,lib,size=4096k,buf=116k,
//
apost,nores,seq)

.
.
Note that an expression in quotes cannot be continued, we need to enclose the string
in parenthesis and field containing special characters in apostrophes.
E.g.2 PARM=29/06/00 or (29/06/00)
E.g 3
PARM=(A,B,C,D) or A,B,C,D
The two, however , are not the same. When parentheses are used, the information
found by the program is (A,B,C,D). If apostrophes are used, the information found by
the program is A,B,C,D.

The COND Parameter

The COND parameter can be coded in the JOB as well as the EXEC statement. It is
mostly used in the EXEC statement. The main tool for controlling the execution of
steps within a job is the COND parameter.
A Return (or Condition) code
A return code is a number between 0 and 4095, issued by an executing program just
before its execution is finished. It is intended to identify an important event found (or
not found) during the execution. For example, a program may issue a return code of
19

21 to indicate that a problematic event (such as a record is out of sequence) was

detected during the execution or a return code of 0 to indicate that the execution was
trouble free. The return code issued by a program is saved by the system for the
duration of the job. Any subsequent step of the same job can interrogate this return
code by using the COND parameter either in the JOB or EXEC statement. The result
of this interrogation is to permit or bypass the execution of the step. Note that the
return code is never available to a job other than the one issued it. In other words, the
step that interrogates the return code must be in the same job as, and subsequent to,
the step that issued it.
IBM-established conventions.
Return code of 0 indicates a complete success.
Return code of 4 indicates a warning. The warning is benign, so a return code will
normally be treated as acceptable.
Return code of 8 indicates a questionable results.
Return code of 12 indicates bad results.
Return code of 16 indicates a terminal condition.
The COND Parameter in the JOB statement.
The COND Parameter can perform a test (or multiple tests) at the beginning of each
step against the return (condition) codes issued by the previous steps. If a test is
satisfied , none of the steps from that point on will be executed.
General Syntax
COND=((code,operator) [,(code,operator)].)
keyword parameter
Code - is a number between 0 and 4095
Operator provides a comparison between a return code and the code. There are six
operators : LT, LE, NE, EQ, GT, GE
There can be a maximum of eight tests in the COND parameter. Condition is
evaluated from left to right and if a test is satisfied, the job stops execution at that
point.
An example can best illustrate the mechanism of the COND parameter. Consider a job
with five steps. Assume that none will ABEND.
//da0001ta

job la2719,SATYA,cond=((12,lt),(8,eq))

STEP1 issues a return code of 0

STEP2, if executed, issues a return code of 4
STEP3, if executed, issues a return code of 16
STEP4, if executed, issues a return code of 0
STEP5, if executed, issues a return code of 4
(warning : This example does not adhere to conventions.)
STEP 1 is executed by default, since no previous return codes exist and hence, the
COND parameter in the JOB statement will be ignored for the first step.

20

Before STEP2 begins execution, the system interrogates the existing return code (0),
using the tests in the COND parameter and reading the test from left to right,
Is 12 less than 0? The answer is no. The first test of the COND parameter was
not satisfied. The second test is tested.
Is 8 equal to 0? . The answer is no. Neither of the two tests was satisfied, and
therefore, STEP2 is executed.
Before STEP3 begins execution, the system interrogates the existing return codes (0
and 4), using the tests in the same COND parameter. Since the result for return code
0 is already known, only 4 will be tested :
Is 12 less than 4? The answer is no. The first test of the COND parameter was
not satisfied. The second test is tested.
Is 8 equal to 4 . The answer is no. Neither of the two tests was satisfied, and
therefore, STEP3 is executed.
Before STEP4 begins execution, the system interrogates the existing return codes (0 ,
4 and 16), using the tests in the same COND parameter. Since the results for return
code 0 and 4 are already known, only 16 will be tested :
Is 12 less than 16? The answer is yes. The first test of the COND parameter was
satisfied. There is no need for the second test . Executions of the job stops. STEP
4 and the remaining steps will not be executed.
A message will appear in the output:
IEF2011 DA0001TA STEP4-JOB TERMINATED BECAUSE OF CONDITION
CODES.
A formula can be devised and used to code the COND parameter, if return code
conventions are strictly adhered to :
COND=(last-good-return-code,LT)
Or
COND=(first-bad-return-code,LE)
Let us apply this formula to this example 0-4 is a good return code :
4 -is the last good return code.COND=(4,LT)
or
5 - is the first bad return code..COND=(5,LE)
The two COND parameters are logically equivalent to each other, and it makes no
difference which one is used.
Exercise : Code the COND parameter, where 0 is the only good return code.
The COND parameter in the EXEC statement
The COND parameter can perform a test (or multiple tests) before a step begins
execution against the return (condition) codes issued by previous steps. If a test is
satisfied, the step will not be executed.
General Syntax
COND=((code,operator[,stepname])[,(code,operator[,stepname])][,EVEN|ONLY
])
keyword parameter
21

Code - is a number between 0 and 4095

Operator provides a comparison between a return code and the code. There are six
operators : LT, LE, NE, EQ, GT, GE
Stepname Identifies the name of the preceding step whose return code will be
interrogated. It can also appear as two names procexec.stepname where procexec
identifies the name of the EXEC statement invoking a procedure and stepname the
stepname within the procedure.
EVEN - requests that execution be permitted even though a previous (any previous)
step has ABENDed.
ONLY - requests that execution be permitted only if a previous (any previous) step
has ABENDed.
There can be a maximum of eight tests in the COND parameter. EVEN or ONLY
counts toward eight. Condition is evaluated from left to right and if a test is satisfied,
only that step is not executed.

Remark :
EVEN and ONLY cannot make reference to a particular step. They refer to any
previous step that has ABENDed.
EVEN and ONLY are mutually exclusive
EVEN and ONLY have no positional significance. Each can be coded
anywhere in the COND parameter in relation to other tests
Following an ABEND failure, a step cannot be executed unless it contains
EVEN or ONLY in the COND parameter of its EXEC statement
The first step will always be executed unless COND=ONLY appears in the
exec statement. COND=ONLY would cause the first step to be bypassed, since
no previous ABEND failures could have occurred. Any other COND parameter
in the first EXEC statement will be ignored (i.e., COND=(4,LT) or
COND=EVEN) or will result in JCL error (i.e., COND=(5,LT,stepname))
since there are no previous step.
A step that is not executed issues no return code because a program responsible
for for issuing the return code was not even loaded into the storage. As a result
no return code exists. An attempt to interrogate the return code of such a step in
the COND parameter of a subsequent step will be ignored.
A step that ABENDs issues no return code because a program always issues a
return code (conditionally or by default) if it reaches the end of its execution
and intentionally returns control to the system. When an ABEND occurs, the
program loses control instantly. And is evicted from from execution by the
system. As a result when a step ABENDs no return code exists ( a completion
code exists). An attempt to interogate the return code of such a step in the
COND parameter of a step will be ignored until it contains EVEN or ONLY.

22

An example can best illustrate the mechanism of the COND parameter. Consider a job
with five steps. This is a class room exercise.
//da0001ta
//s1
//s2
//s3
//s4
//s5
//s6
//s7
//s8
//s9
//s10

job la2719,SATYA,notify=&sysuid,msglevel=(1,1)
exec pgm=p1
(4)
exec pgm=p2,cond=((0,lt,s1),even)
(12)
exec pgm=p3,cond=(8,lt,s2)
(0)
exec pgm=p4,cond=(4,lt)
(8)
exec pgm=p5,cond=((4,lt,s1),(0,lt,s3))
abend
exec pgm=p6,cond=(even,(0,le,s5),)
(16)*
exec pgm=p7,cond=((0,lt,s1),even)
(0)
exec pgm=p8,cond=((0,lt,s1),(12,lt,s3) )
(0)
exec pgm=p9,cond=only)
(4)
exec pgm=p10,cond=only
(0)

If the COND parameter is coded neither at the JOB nor at the EXEC statement, the
step will be executed regardless of previous return codes. However it will not be if a
previous step has ABENDed.
If the COND parameter is coded in both the JOB statement as well as an EXEC
statement within the JOB. The COND parameter of the JOB statement is tested first.
If none of its tests are satisfied, then the COND parameter of the EXEC statement is
tested. If a test is satisfied, none of the steps from that point on will be executed.

This is a class room exercise.

//DA0001TA JOB LA2719,SATYA,COND=(5,EQ),NOTIFY=DA0001T
//S1
EXEC PGM=P1
(4)
//S2
EXEC PGM=P2,COND=(7,LT)
(ABEND)
//S3
EXEC PGM=P3,COND=((20,GT,S1),EVEN)
(6)
//S4
EXEC PGM=P4,COND=(3,EQ),ONLY)
(8)
//S5
EXEC PGM=P5,COND=(2,LT,S3)
//S6
EXEC PGM=P6
//S7
EXEC PGM=P7,COND=((6,EQ,S5),ONLY)
(5)
//S8
EXEC PGM=P8,COND=EVEN
(0)
//S9
EXEC PGM=P9
-

23

4.

The DD statement

A DD (Data Definition_ statement must appear in a step when the executing program
expects to read from or write to a dataset. In other words DD statement describes the
dataset. The DD statement is the most complicated of all the JCL statements.
The maximum number of DD statements in a step is 3273 . The DD statement can be
coded in any order and always appear after the EXEC statement with the exeception
of
JOBLIB, JOBCAT, PROCLIB DD statement.

The DSN Parameter

The DSN (or DSNAME) parameter identifies the name of the dataset to be created or
retreived.
General Syntax
DSN=name| referback

keyword parameter

Name It could be a qualified name. This name consists of two or more simple
name separated by periods for a maximum of 44 characters.
E.g 1 DSN=da0001t.SATYA.empfile
E.g.2
DSN=da0001t.SATYA.cobol(ass1)
identifies a library
(da0001t.SATYA.cobol) and a particular member. This notation describes a
sequential dataset.
e.g.3 DSN=&&name
A simple name preceded by two ampersands identifies a temporary dataset.
Temporary because it is not retained beyond job termination.
The system generates a name with the following format :
SYSyyddd.Thh.mm.ss.RV001.jobname.name
Yyddd Julian Calender;
hhmmss uses 24 hour clock ;
RV001 system provided information in reference to the reader;
jobname as it appears in the JOB statement ;
Name whatever is coded after &&.

For e.g DSN=&&temp

SYS00173.T090000.RV001.da0001ta.temp
Remark :
If the DSN name is omitted from a DD statement (except DD * , SYSOUT and
DUMMY) also indicates a temporary dataset. However the system generates a name
with the following format :
SYSyyddd.Thhmmss.RV001.jobname.R0000001
24

//SORTWK1

DD UNIT=SYSDA,SPACE=(TRK,(1,2),RLSE)

SYS00173.T100000.RV001.da0001ta.R0000001
This form is basically used when a step requires a work dataset (a dataset created at
the beginning of the steps exeution and deleted at the end). Mostly by utilities.

Most utility uses this form

Referback : This can have three formats :
- *.stepname.ddname Requests that the dataset name be copied from DD
statement ddname found in a previous step stepname.
e.g : DSN=*.step1.dd1
-

*.ddname Requests that the dataset name be copied from a previous DD

statement ddname found in the same step stepname.
e.g : DSN=*.dd1

*.procexec.stepname.ddname Requests that the dataset name be copied

from DD statement ddname found in a previous step stepname found
within procedure procexec. (name of EXEC statement invokinh the
procedure)
e.g : DSN=*.ps1.step1.dd1

The DISP Parameter

The DISP parameter specifies :
- if the dataset is to be created or retreived
- how to dispose of the dataset when the step terminates (normally or abnormally)
General Syntax
NEW
OLD
DISP= ( SHR
MOD

,DELETE
,KEEP
,CATLG
,UNCATLG
,PASS

,DELETE
,KEEP
,CATLG
)
,UNCATG;

keyword parameter

DISP=(status-field,normal-disp-field,abnormal-disp-field)
The status-field : This field tells the system whether the dataset is to be created or
retrieved.
NEW Indicates that the dataset will be created in this step
OLD - Indicates that an existing dataset will be retrieved and demands exclusive
control.
25

SHR - Indicates that an existing dataset will be retrieved. It also indicates that this
dataset ,if on disk, can be shared with one or more other users.
MOD - This subparameter has two possible meanings :
Indicates that an existing dataset will be retrieved . This will be true if
The dataset is either cataloged or passed
The DD statement contains either VOL=SER or VOL=REF (a VOL
VOL=REF referring to a DD statement, which is a nonspecific request for
a new dataset, is not included)
Indicates that the dataset will be created. This is true if :
The DD statement contains neither VOL=SER nor VOL=REF and it
describes a dataset which is neither cataloged nor passed.
The DD statement contains VOL=REF referring to a DD statement which
is nonspecific request for a new dataset.
e.g. 1 //dd1
//

dd dsn=da0001t.empfile,disp=(mod,catlg),
unit=tape

Explanation:
1. The system assumes da0001t.empfile to be an existing dataset, since the DD
statement contains neither VOL=SER or VOL=REF. The system searches the
catalog and gets volume informatiom from the catalog entry. The volume have
been found. This dataset will be treted as existing dataset.
2. Had the dataset been neither cataloged nor passed. The systen would have been
unable to find the volume information and MOD will default to new.
e.g 2 //dd1
//

dd dsn=da0001t.empfile,disp=(mod,catlg),
unit=sysda,vol=ser=bs3003,space=(trk,(1,2))

Explanation: Since VOL=SER is specified, the fate of MOD is sealed, whether or not
it exists. It will be treated as OLD (with appropriate positioning). If the dataset exists
on that volume no problem, however, if it does not exist the result will be S213-04
ABEND failure (i.e dataset does not exists)
Note :When UNIT and VOL=SER is specified the system does not search the catalog
to locate the dataset.
The normal disposition field : This field is used to tell the system how to dispose of
the dataset when the step terminates normally (without an ABEND).
DELETE indicates that the dataset is to be deleted when the step terminates. For an
existing dataset, OLD, SHR or MOD (not defaulting to NEW), the dataset will also
be uncataloged, if the catalog were used while retreiving the dataset. It will only
delete if the catalog were not used during the retrieval. This means that for a cataloged
dataset, if you specify UNIT and VOL=SER the system does not search the catalog.
Note :
1 When a tape dataset is deleted, nothing happens. A tape dataset cannot be deleted
through the DISP parameter. It is effectively deleted when the dataset is written
over.

26

2 A VSAM cluster cannot be deleted by coding DISP=(OLD,DELETE) as it defaults

to DISP=(OLD,KEEP).
3 A member of PDS cannot be deleted, as DISP applies to the entire PDS, and as
result it deletes the entire PDS. Use either TSO or IEHPROGM utility.
4 The system always issues a message indicating DELETED or NOT
DELETED N N indicates the reason for failing.
KEEP Indicates that the dataset is to be kept when the step terminates. The system
takes no action and issues a message indicating the dataset was kept. Again, the
system issues a message KEPT. Note that NOT KEPT message does not exists.
(the funda of retention period comes into picture).
Note : KEEP does not imply CATLG. As a result, DISP=(NEW,KEEP) should be
rarely used because next time you retrieve the dataset, you need to specify UNIT and
VOL=SER.
CATLG Indicates that the dataset is to be kept and an entry for it placed in the
catalog when the step terminates.
Note :
1. If cataloging is successful, the system issues CATALOGED
2. If cataloging fails for a NEW dataset, the message will NOT CATLGD n
(n indicates the reason for failing).
3. If the dataset to be catologed is OLD or MOD , which was opened but did extend
into additional volume(s), the message will RECATALOGED n
4. If the dataset to be cataloged is OLD or MOD and has extended into additional
volume(s), the message will be recataloged
5. CATLG implies KEEP. DISP=(NEW,CATLG,DELETE) is a very common
parameter.
When an attempt to catalog fails ?
Explanation: Under certain conditions, the attempt to catalog a new entry fails. The
step termination routines normally issue a message to inform the user :
IEF287I dataset name
IEF287I VOL=SER=BS3001, BS3003
NOT CATLGD n
Followed by the message identifing the user catalog where the attempt to add the
entry was made.
IEF285I user catalog name
IEF285I VOL=SER=vol serial
KEPT
n identifies the reason for which the cataloging operation failed.
Often, n is 2. There are several reasons for failing to catalog a dataset. Most of them
are seldom encountered. For instance, the failure could be due to an I/O error or an
out-of-space condition in the catalog, both extremely rare. The one that is common is
illustrated by means of an example.
//dd1
//
//

dd dsn=da0001t.empfile,disp=(new,catlg,delete),
space=(trk,(1,2)),unit=sysda,
dcb=(lrecl=80,recfm=fb,blksize=800)

If an entry for DA0001T.EMPFILE already exists in the catalog, the step termination
routines will not replace the existing entry with the new one, however it keeps the

27

dataset and issues the appropriate message. Unfortunately, NOT CATLGD 2 is just
a warning, operator tend to ignore.
Whenever, you get this message. The existing entry must be removed before the one
with the same one is added. Use IEHPROGM or any other utility to remove the
catalog before adding a new one.
What are the implications of ignoring this warning ? Assume that the existing catalog
entry for dataset points to BS3001, which may or may not contain such a dataset. As a
result of DD statement DD1 the dataset by the same name has been created and kept
on different volume say BS3008 while the catalog entry remains unaltered.
Later, the user, who did not notice the NOT CATLGD 2 message submits a job
containing a DD statement.
//infile

dd dsn=da0001t.emfile,disp=shr

The system will search the catalog, retrieves the dataset residing on volume BS3001,
with no outward appearance of failure. If the dataset by that name does not exist, the
result is S213-04 ABEND failure.
Note that an attempt to add a dulpicate entry in the volume encounters a
DULPCIPATE NAME ON DIRECT ACCESS VOLUME JCL error.
This problem is not encountered in MVS/ESA, because the system deletes the dataset
as well as uncatalog.
PASS Indicates that an entry for the dataset (containing dsn, volume and unit
information) be placed on a table in storage (Passed Dataset Queue). This entry is to
be used in a subsequent step to receive the passed dataset. A message will appear
PASSED.
The abnormal (or conditional) disposition field : This field is used to tell the systen
how to dispose of the dataset when the step terminates abnormally (ABENDs). It is
required only if this disposition is different from the normal disposition.
DELETE,KEEP,CATLG, and UNCATLG have the same meaning they do in the
normal disposition. Note that PASS is not permitted in the abnormal disposition field.
The best example of using the abnormal disposition field is
DISP=(NEW,CATLG,DELETE). If there is ABEND, the dataset is to be deleted. This
eliminates future manual intervention to delete and uncatalog the dataset in order to
restart.
Defaults: Some defaults in the DISP parameter are fixed and others variable.
If the DISP parameter is omitted, the default is always (NEW,DELETE.
//sysut1

//*

dd unit=sysda,space=(trk,(1,2))

(NEW,DELETE) IS THE DEFAULT

If the status is omitted, the default is always NEW

DISP=(,CATLG) is same as DISP=(NEW,CATLG)

If the normal disposition field is omitted

- If the status field is NEW, the default is DELETE
- If the status field is OLD or SHR and the dataset name non temporary
If the DD statement is not receiving a passed dataset, the default is
KEEP.
//dd1

dd dsn=da0001t.empfile,disp=shr

28

If a DD statement is receiving a passed dataset, which was created during the

execution of the job and was never given a permanent disposition, the default is
DELETE.

If a DD statement is receiving a passed dataset, which was created during the

execution of the job but was given permanent disposition since being created, the
default is KEEP.

If a DD statement is receiving a passed dataset which existed before the job began
execution, the default is KEEP.

If the status field is OLD or SHR and the dataset name temporary, the default is
pass.
//dd1

dd dsn=old,dsn=&&temp

DISP=OLD defaults to DISP=(OLD,PASS) and the message will appear in the

output INVALID DISP FIELD PASS SUBSTITUTED

If the abnormal disposition field is omitted, the default is the normal disposition
field.

The UNIT Parameter

The UNIT parameter identifies :
The device type or device address where the volume is mounted. The volume is the
one where the dataset resides (or will reside if DISP=NEW).
The number of devices to be allocated to the dataset.

When the mount message is to be shown to the operator.

General Syntax
device address
UNIT =( generic device name
generated device name

,device count

,DEFER ) Keyword parameter

device address Identifies the exact device address. This notation is almost never
used.
Generic device name Identifies the device type using a universal system-supplied
name.
e.g : UNIT=3390 ; UNIT=3400-5 ; UNIT=3480
generated device name Identifies the device type using an installation-defined name.
UNIT=SYSDA ; UNIT=DISK ; UNIT=TAPE
The generated names can be made to mean whatever an installation wishes them to
mean. For example, UNIT=SYSDA can mean all 3380 devices of any density, or
single density only, or a subset of double density devices or a combination of 3380

29

and 3390 device. Their definition can vary from installation to installation. Our GE
machine has UNIT=SYSALLDA.
Of the three, the generated name is far the most commonly used.
Device count Specifies the number of devices to be allocated for the dataset. The
limit is 59 devices. If omitted default is 1 except when DD statement describes a disk
multivolume dataset. In such case, device count=number of volumes.
E.g. 1 UNIT=(SYSDA,5) ; UNIT=(TAPE,2)
E.g. 2 UNIT=SYSDA is same as UNIT=(SYSDA,1) because of default
E.g. 3 //dd1
//
//
//

dd dsn=da0001t.empfile,disp=(,catlg,delete),
unit=sysda,vol=ser=(bs3001,bs3002,bs3003),
space=(trk,(1,2)),dcb=(lrecl=80,recfm=fb,
blksize=800)

In this example UNIT =SYSDA defaults to UNIT=(SYSDA,3)

Note : UNIT=(,2) can also be used if the device is being supplied by the catalog.
DEFER : Requests that the mount message to the operator not be issued by the
allocation routines but by the open routines when, and, if the dataset is opened.
Note : DEFER must never be used with disk. Generally, used for tapes.
There is no default for device name. If it is not coded in the UNIT parameter and it is
also not supplied by the catalog, the Passed dataset Queue, the result will be allocation
JCL error . The message is
IEF210I JOBNAME
STEPNAME DDANAME UNIT FIELD SPECIFIES
INCORRECT DEVICE NAME, which is misleading. It means that the device name
was needed but not coded.

The VOL Parameter

The main function of the VOL (or VOLUME) is to identify the volume(s) by serial
number where an existing dataset resides or where a new dataset will reside.
General Syntax
vol
Volume

,SER=(vol1 [,vol2].
=( ,REF=referback
,REF=dsname

SER=(vol1,vol2.) Specifies the serial number(s) of the volume(s) to be used. The

maximum number of volumes is 255.
A volume serial is a combination of alphabetic , numeric, and national characters ($
@ #) up to 6. A hyphen is also permitted. In a real (or production) environment, the
number of characters is almost never less than 6.
e.g VOL=SER=BS3001 OR VOLUME=SER=BS3001
VOL=SER=(BS3013,BS3014)

30

REF=referback
Referback This can have three formats :
*.stepname.ddname - Requests that the volume be the same as for DD statement
ddname found in the previous step stepname.
VOL=REF=*.STEP2.DD1
*.ddname - Requests that the volume be the same as for previous DD statement
ddname found in the same step stepname.
VOL=REF=*.DD1
*.procexec.stepname.ddname - Requests that the volume be the same as for DD
statement ddname found in the previous step stepname found within a procecure
procexec (name of EXEC statement invoking the procedure.
VOL=REF=*.PR1.STEP2.DD1
Remark:
Referbacks are not encouraged. They should be used only when they are necessary. A
referback with a stepname will cause a JCL error if the referenced step does not
execute. Such referbacks must be avoided where restart is required.
REF=dsname Requests that the volume be the same as the one where dataset
dsname resides on. The dataset must be cataloged or Passed. The dataset does not
even have to exist, as long as it is cataloged or passed. The name of the referenced
dataset need not appear anywhere else in the job.
e.g : VOL=REF=DA0001T.EMPFILE
Remark:
When VOL=REF (referback or dsname) is used, the system supplies the volume as
well as the unit information. Therefore, the UNIT parameter is usually unnecessary.

The SPACE Parameter

The SPACE parameter must be included in a DD statement when :
A new disk dataset is created.

An old dataset needs to alter its entitlement to additional space. i.e., Request
additional disk space for an old dataset when available space is exhausted.

An old disk dataset must free up all unused space.

General Syntax
TRK,
SPACE=( CYL,
(prim-alloc [,sec-alloc] [,directory]) [,RLSE])
Blksize,
TRK Requests that space be allocated in tracks.
31

CYL Requests that space be allocated in cylinders.

Blksize Specifies the average blocksize of the dataset. The system will translate it to
tracks.
Prim-alloc. Primary allocation or primary quantity. It identifies the number of tracks
(if TRK is coded) or cylinders (if CYL is coded) or the number of blocks (if blksize is
coded) that must be allocated during the allocation process for a new dataset before
the step begins execution. The system will allocate the requested space in one extent.
If this is not possible (and CONTIG is not coded), two extents will be used, then three
and so on up to five extents. If as many as five extents still cannot satisy the request,
the result will be a allocation JCL error :
IEF257I jobname stepname ddname SPACE REQUESTED NOT AVAILABLE.
If the request is nonspecific (no VOL=SER or VOL=REF), needing a storage volume,
the JCL error message will be different :
IEF257I jobname stepname ddname INSUFFICIENT SPACE ON STORAGE
VOLUMES.
Remark :
The system will always allocate the primary quantity in the least number of extents
possible on a single volume. The primary quantity cannot be split over multiple
volumes. The primary allocation cannot be omitted (coding 0 is allowed). It is
ignored if the dataset is old.
e.g 1 SPACE=(TRK,3)
e.g 2 SPACE=(CYL,4)
e.g 3 SPACE=(23440,100)
e.g 5 SPACE=(TRK,0)
sec-alloc - Secondary allocation or secondary quantity. It identifies the number of
tracks (if TRK is coded) or cylinders (if CYL is coded) or the number of blocks (if
blksize is coded) that are to be allocated when all available space is exhausted while
writing to a dataset. The system will allocate the secondary quantity in the least
number of extents possible, and just like the primary quantity, it can be given in as
many as five extents, if necessary.
The system will always supply the specified secondary allocation when one is needed
unless one of the two events occurs :
The allocated volume does not have enough space to satisfy the secondary
allocation and no other volumes are allocated.

The needed secondary allocation, if granted, will cause the dataset to exceed 16
extents on the volumes and no other volumes are allocated.

If either of these two conditions arises, the result will be a SB37-04 ABEND failure
(normally for a sequential dataset). For a PDS, the ABEND, can also be SE37-04.
Please note that a PDS is confined to a single volume, ehile a sequential dataset can
extend into a maximum of 59 volumes. The 16-extent-per-volume limit for a dataset
is system-supplied and cannot be altered.
The secondary allocation is optional. If omitted, defaults to 0. When no secondary
allocation is coded and the primary allocation is exhausted, the result is an SD37-04
ABEND failure.
32

Remark :
The secondary allocation can be used for new as well as old datasets. The secondary
allocation requested when the dataset is created is recorded in the datasets DSCB
(VTOC entry). If space is exhausted when the dataset is retrieved as OLD and
extended, the system attempts to provide secondary allocation appearing in the
DSCB. If ,however, a SPACE parameter is included in the DD statement, the
secondary allocation will be based on what is coded in this SPACE parameter rather
than what appears in the datasets DSCB.
E.g 1 SPACE=(TRK,(1,2))
E.g 2 SPACE=(CYL,(7,4))
E.g 3 SPACE=(23440,(200,100))
directory Specifies the number of directory blocks (256 bytes each) to be assigned
to the directory of a PDS.
The directory quantity, if not coded, defaults to zero; therefore, the directory quantity
must be specified for a new PDS. If it is, not S013-14 ABEND failure will occur if an
attempt is made to add the first member to a PDS.
Remark :
The directory quantity is taken away from the beginning of the primary allocation if
TRK or CYL is coded in the SPACE parameter. When blksize is coded, the system
adds the directory blocks to the data blocks and then computes the amount of primary
space.
E.g 1 SPACE=(TRK,(20,5,5)) OR SPACE=(TRK,(20,,5)) if no secondary
E.g 2 SPACE=(CYL,(20,5,5)) OR SPACE=(CYL,(20,,5)) if no secondary
E.g 3 SPACE=(23440,(200,50,5)) OR SPACE=(23440,(200,,5)) if no secondary
RLSE Requests that any unused space be freed when the dataset is closed. This
works for both new and old datasets, provided they were opened for output. Space
will be released on the boundary used in the SPACE parameter. If tracks (or
cylinders) were allocated, unused tracks (or cylinders), will be released.
Remark :
Using RLSE is highly recommended for datasets not intended for future expansions.
Temporary datasets are ideal candidates. For datasets that expand in future runs,
RLSE can result in a larger number of extents, and, possibly, a premature SB37-04
ABEND failure. RLSE will be ignored if the dataset is opened by another user (or
shared by another job) ot the step ABENDs.
e.g: SPACE=(TRK,(5,1),RLSE)

The LABEL Parameter

The LABEL parameter can specify :
The sequence of a tape dataset on a volume.

The type of label of the dataset.

33

General Syntax
LABEL=([seq-no][,type])

keyword parameter

Seq-no Identifies the sequence number of the dataset on a tape volume. 1 to 4 digits.
If omitted, it defaults to 1. If 0 is coded, it defaults to 1. Maximum : 9999
e.g LABEL=3
type Identifies the type of label for the dataset.
There are many types of labels. To name a few, which are important from project
perspective.
SL Indicates IBM standard label. If the subparameter is omitted, SL is the default.
NL Indicates no labels are used. NL is not commonly used. Normally, NL is used
for a tape coming from or going to another installation which has no SL capabilities.
BLP Bypass Label Processing : Indicates that labels will not be recognized and will
be treated as ordinary files. BLP is used as a last resort when neither SL nor NL can
accomplish what is required.
Label Verification : When retrieving an SL tape dataset, both the volume serial and
the dataset name will be verified. When creating an SL tape dataset with VOL=SER
or VOL=REF, only the volume serial will be verified.
When retrieving an NL tape dataset, neither the volume serial nor dataset name can be
verified. However, only an NL tape volume can be mounted. An SL volume will be
rejected.
Defaults : If omitted, the LABEL parameter defaults to (1,SL). There are four ways to
supply the same information.
Omit the LABEL parameter

Code LABEL=(,SL) 1 is the default

Code LABEL=1 SL is the default

SL
VOL

HDR1

HDR2

TM

SL DATA SET # 1

TM

EOF1

EOF2

TM

TM

NL
NL DATASET #1

TM

NL DATASET #2

TM

TM

TM Tape Mark

The DCB Parameter

The DCB parameter specifies values to be used to complete the Data Control Block
(DCB) when a dataset is opened. A DCB is constructed by the language processor
(compiler or assembler), based on the appropriate instructions of the language being
used, and resides inside the code of the program. The compiler, collects this
information and defaults from various parts of the program (For e.g In COBOL,
RECORD CONTAINS 80 CHARACTERS; BLOCK CONTAINS 10 RECORDS and
34

so on ) and constructs the DCB. Note that the DCB exists only for non VSAM
datasets and is checked by the OPEN routines (for input or output). Certain values
must be hard-coded in the DCB by the program. Others can can be left out, giving
the user the option of supplying these values via the DCB parameter( as well as other
means).
There are three suppliers of DCB information :
Values supplied by the program, referred to as hard-coded. When a value is hardcoded, it cannot be changed unless the program is changed.

Values coded in the DCB parameter of the DD statement. These values will be
ignored if they are already hard-coded.

Values from the standard label of the dataset. The values supplied by the label are
limited to : BLKSIZE,LRECL, RECFM, DSORG etc. Values from the label will
not be used if they are hard-coded inside the program or coded in the DCB
parameter.

General Syntax
DCB=([referback] | [model][,subparameter], keyword parameter
Referback This can have three formats :
*.stepname.ddname - Requests that the DCB parameter be copied from the DD
statement ddname found in the previous step stepname.
DCB=*.STEP2.DD1
*.ddname - Requests that the DCB parameter be copied from a previous
statement ddname found in the same step stepname.
DCB=*.DD1

DD

*.procexec.stepname.ddname - Requests that the DCB parameter be copied from DD

statement ddname found in the previous step stepname found within a procecure
procexec (name of EXEC statement invoking the procedure.
DCB=*.PR1.STEP2.DD1
Remark :
The DCB referback copies the DCB parameter as opposed to the DSN and VOL=REF
referbacks which acquire the dataset name and the volser respectively, whether or not
the DSN and VOL parameters are present in the referenced DD statement. If the DCB
referback refers to a DD statement which contains no DCB, nothing is copied and no
message appears.
Model specifies the name of the dataset which :
Must be cataloged. If it is not, the result will be a JCL error :
IEF2121 jobname stepname ddname DATASET NOT FOUND

Must be on disk (Tapes not allowed)

35

Must reside on a volume that is accessible (online)

This dataset is called a model DSCB. The DCB information from the label of the
model is extracted and can be used.
E.g 1. DCB=DA0001T.EMPFILE
E.g 2. In case you want to override some of the subparameters, the overriding
subparameters must follow the DSCB model dataset name.
DCB=(DA0001T.EMPFILE,LRECL=100,BLKSIZE=800)
Models, are generally used, during the creations of GDGs and dummying the PDS.
Subparameters : There is vast number of subparameters, the great majority of which
are seldom or never used.
BLKSIZE -Specifies the size of the block (also known as the physical record).
For RECFM=FB, the blocksize must be multiple of the logical record length, and
it identifies the exact size of the block. For RECFM=VB, the blocksize can be any
value up to the limit but atleast 4 bytes larger than the logical record length. For
RECFM=U, the blocksize can be any value up to the limit
Remark : There is no default for BLKSIZE. Coding BLKSIZE=0, the system will
compute the optimum blocksize based on the device type.
E.g DCB=BLKSIZE=800
LRECL Specifies the size of the logical record. The maximum size is 32,760, and it
cannot be larger than blocksize, unless RECFM=VBS is used.
E.g. DCB=(LRECL=80,BLKSIZE=800)
RECFM Specifies the record format. There are several values (or combinations of
values) that can be coded.
F - All blocks and all logical records are fixed in size.

V - Blocks as well as logical records are of variable size. The first 4 bytes of each
block (and logical record) describes its length.

B One or more logical records reside in each block. B cannot be coded alone. It
is used in conjunction with F or V. For example FB or VB.

U Blocks are of variable size. There are no logical records. Mainly used with
Load Library.

S- For fixed-size records, it indicates that no short blocks are permitted anywhere
but the end of the data. For variable-size records, it indicates that a logical record
can span more than one block. S cannot be coded alone. It must follow F,V,FB or
VB.

36

A Indicates that the first character of each record is an ANSI control character to
be used for printer carriage control. A cannot be coded alone. It must follow
F,V,FB,VB or U.

E.g DCB=(LRECL=80,RECFM=FB,BLKSIZE=800)
If RECFM is not supplied through any means, U is the default.
DEN Identifies the density of the tape. DEN=3(or 4) indicates 1600 (or 6250 ) BPI
density.
BUFNO Identifies the number of buffers to be allocated in virtual storage by the
OPEN routines, which will contain the blocks to be rean in or written out. If omitted,
default is 5. The maximum is 255. Coding for BUFNO a number greater than 5 may
require that the REGION parameter be increased.
EROPT Specifies what action to take if an unrecoverable I/O error occurs while
reading or writing a block.
ABE Cause an ABEND failure (S001-1).

SKP Skip the block containing the error.

ACC Accept the block containing the error

The default is ABE

DSORG Identifies the organization of the dataset
PS Specifies physical sequential organization. Mostly QSAM and sometimes
BSAM.

PO - Specifies partitioned organization (or BPAM)

DA- Specifies direct organization (or BDAM)

IS Specifies indexed sequential organization(or ISAM)

ABEND failures due to inconsistent DCB values :

S013-20 ABEND when RECFM=FB is used but the BLKSIZE is not an exact
multiple of LRECL. Note that SYSOUT is an exception.

S013-34 ABEND when RECFM=FB is used and the LRECL is greater than the
BLKSIZE.

S013-34 ABEND when RECFM=VB is used and the LRECL is greater than the
BLKSIZE-4.

Remark :
If values for BLKSIZE or LRECL are not supplied by any source (hard-coded or the
DCB parameter or DSCB), the result will be an S013-34 ABEND failure.
37

S001-04 ABEND when BLKSIZE in the DCB parameter is smaller than the
actual blocksize and is a multiple of the LRECL in the DSCB of the dataset.

It is important to understand which of these often-used parameters are normally hardcoded and which are not :
BLKSIZE - Seldom hard-coded. The BLKSIZE is unrelated to the logic of the
program and hard-coding its value would cause unnecessary changes whenever
the BLKSIZE is changed. In COBOL, BLOCK CONTAINS 0 RECORDS must
be coded to avoid hard-coding the BLKSIZE. Omitting this clause will cause a
default of 1 to be used. The result will be a hard-coded BLKSIZE is equal to
LRECL. Many installation standards disallow hard-coding the BLKSIZE for
sequential and partitioned datasets.

LRECL Frequently hard-coded. The logic of any ordinary program is dependent

on the LRECL and, as a result, the LRECL cannot be changed without changing
the logic of the program. Many high-level languages like COBOL always hardcode the LRECL.

RECFM Frequently hard-coded. The logic of any ordinary program is dependent

on the RECFM and, as a result, the RECFM cannot be changed without changing
the logic of the program. Many high-level languages like COBOL always hardcode the RECFM.

Instream Data
The input stream submitted to the system for execution consists of two possible parts :
JCL mandatory part of the input stream

Data mixed in with JCL in the input stream. This data is known as sysin data or
input stream data. It is optional part of the input stream and always has a logical
record length of 80. Any records encountered in the input stream which are not
JCL statements will be treated as sysin data.

Sysin data must be preceded by a DD statement such as :

//name
data
/*

dd *

Sysin data encountered by JES2 or JES3 following a DD * statement will be saved on

the SPOOL volume for future use. This is known as input spooling The sysin is
delimited (the spooling stops) by :
A /* (delimiter) statement found.
A valid JCL statement.
An end-of-file condition on reading device.
The asterisk (*) is a positional parameter. The DD * is a special statement which is
under complete JES2 or JES3 control.

38

SYSIN is a very common ddname used by many vendor-written programs to pass

control information to the utility. E.g SORT,IEBGENER,IDCAMS utilities.
In user writtem programs, if you use COBOL ACCEPT statement. In your run JCL one
of the DD statements will be SYSIN dd statement.
//sysin dd *
1234
/*

With the above type of DD statement, one complication arises if the sysin data must
consist of JCL statement. Because any JCL statement delimits sysin data. To
accomplish this, DD DATA instead of DD * must be used.
//sysut1 dd data
1234
abcd
//dd1 dd dsn=da0001t.empfile,disp=shr
/*
A /* must be used to delimit a DD DATA statement. A word of caution: Failure to
supply a /* will cause serious problems. JCL statements following DD DATA will
unintentionally become part of sysin data. However, If you want /* to be part of sysin
data, code DLM parameter.
//sysut1 dd data,dlm=)(
1234
abcd
//dd1 dd dsn=da0001t.empfile,disp=shr
/*
xyz
)(

The two characters that are coded in the DLM parameter (apostrophes must be used for
special characters) will act as a delimiter and /* will be treated as data. Any two
characters can be used. However, characters that are likely to appear in the first two
positions of any record must be avoided to prevent premature delimiting sysin data.
DD parameter
*
DATA
DLM

Function
For reading data without // or /* in columns 1 and 2.
For reading data with // but not /* in columns 1 and 2
containing JCL or statements.
For reading data with either // or /* in columns 1 and 2.

* and DATA are positional parameters whereas DLM is a keyword parameter.

Remark :
If sysin data is not preceded by DD *, the system will generate a statement and place
it in front of the sysin data .

39

E.g
//da0001ta job la2719,..
//s1
exec pgm=ass1
//steplib dd
1234
//dd1
dd

is equivalent to
//da0001ta job la2719,..
//s1
exec pgm=ass1
//steplib dd
//sysin
dd * (generated statement)
1234
//dd1
dd

Note : A line with blanks is the most common offender. It is invisible to the user but it
will be treated as data by the system This may or may not cause problem. Let us look
at the following example.
//da0001ta job la2719,..
//s1 exec pgm=ass1
//steplib dd
//sysin dd *
1234
//dd1 dd

The system will interpret the above JCL in the following way :
//da0001ta job la2719,..
//s1 exec pgm=ass1
//sysin
dd *
//steplib dd
//sysin dd * (generated statement)
1234
//dd1 dd

Conclusion : If there are two or more DD statements by the same name in the same
step. This is not an error condition. When the program opens for SYSIN the first of
the two be used. The other will be allocated and ignored.
Remark :
Generically, each DD statement must have a unique ddname except in special cases
viz concatenation. In JES2, if a step contains identical ddnames, the system allocates
devices and space and does disposition processing for both the DD statements.
However, the systen directs all references to the first DD statement with that name in
the step. In JES3, if a step contains identical ddnames, the job ABENDS during
allocation.

The SYSOUT Parameter

Print records generated by a program are not normally routed directly to a physical
printer(theoretically it is possible, but in practice it is seldom done). Instead, they are
40

written on the SPOOL pack and saved there for later viewing on a terminal or printing
(or both). This is called output spooling, and is under the control of JES2 or JES3
which later can use one of their print routines to print the dataset. These print routines
must schedule the datasets for printing, and msgclasses are used for this purpose. All
print routines (called printers or writers) are associated with one or more classes (in
all 36 classes) and each dataset to printed must also be assigned classes. The printer
routines selects datasets for printing in a very similar way as initiators selects jobs for
executions. Use S.ST option of ISPF menu to view the output dataset.
The SYSOUT parameter can assign this class, known as sysout or output class, to a
dataset. Such datasets are called sysout or output datsets.
General Syntax
SYSOUT=(class| *)

keyword parameter

Class Identifies the sysout class of the dataset from A to Z and 0 to 9.

*- Indicates that the same class used in the MSGCLASS parameter of the JOB
statement (or the installation-defined default, if MSGCLASS parameter is omitted) is
to be used.
E.g 1. sysout=a
E.g 2 //sysprint dd sysout=*
This DD statement is used for printing system messages generated by JES2 or JES3.
Each step must have SYSPRINT DD statement. Absence will cause SYSPRINT
DD STATEMENT MISSING message in the sysout.
E.g 3 //sysout dd sysout=* (or any sysout class may be assigned)
This DD statement is used when you have COBOL DISPLAY clause in your
program.

Concatenation
Concatenating Datasets
At times, program may have to read in sequence several input datasets as if they were
one. This can accomplished without physically putting the data in one datasets. This is
done by concatenating the datasets in JCL code with comparable DCB characteristics
without programming changes.
Note that only sequential and partitioned datasets can be concatenated. For sequential
datasets, the maximum number of concatenations is 255 and for PDS it is 16.
Concatenation has meaning only for sequential processing.
E.g 1. Concatenation of physical sequential files.
//dd1
//
//

dd dsn=da0001t.SATYA.group1,disp=shr
dd dsn=da0001t.SATYA.group2,disp=shr
dd dsn=da0001t.SATYA.group3,disp=shr

41

E.g 2. Concatenation of partitioned datasets.

//dd1
//
//

dd dsn=da0001t.pds1.group1,disp=shr
dd dsn=da0001t.pds2.group2,disp=shr
dd dsn=da0001t.pds3.group3,disp=shr

There are number of rules and restrictions for concatenations :

1. The first concatenation is the only one with a ddname.
2. The logical record length and the record format of concatenated datasets must be
the same. However, the blocksizes need not be.
3. The blocksize of the first concatenation must be greater than or equal to
blocksizes of all subsequent concatenation. Violation of this rule results in S00104 ABEND failure. This is true for DFP Version 2.3. For version DFP 2.4, one
can concatenate datasets in any sequence, but for the first concatenation code the
DCB parameter with the largest blocksize of all the concatenations.
E.g. Assume that in the JCL below, the first concatenation has a blocsize of 800, the
second a blocksize of 800- and the third a blocksize of 23400.
//infile
//
//

4.

dd dsn=da0001t.SATYA.group1,disp=shr,dcb=23400
dd dsn=da0001t.SATYA.group2,disp=shr
dd dsn=da0001t.SATYA.group3,disp=shr

Both sequential datasets and partitioned datasets can be concatenated, but not with
each other sequential with sequential and partitioned with partitioned only.
Member of a PDS is treated as sequential dataset and thus can be concatenated
with sequential dataset.

E.g
//in
//

5.

dd dsn=da0001t.empfile,disp=shr
dd dsn=da0001t.SATYA.data(emp),disp=shr

Disk as well as tape datasets can be concatenated but not with each other. Only
like devices should be concatenated, disk with disk and tape with tape.

DUMMY Parameter
The DUMMY parameter is a positional parameter. At times, one might want to
execute a program but suppress read or write operations in certain jobs, For example.,
not print a report. At other times, one might want to test a program without actually
processing data.
The DUMMY parameter specifies that :
No device or external storage be allocated.

No disposition processing is performed.

No input or output operations are performed for sequential access methods.

42

Remark :
1 DCB information is established. Generally used during testing process and in
procedures. Instead of using DUMMY, one may use DSN=NULLFILE. It
differs from DUMMY by virtue of its position. It is a keyword parameter.
E.g //DD1
DD DSN=NULLFILE
2

When an attempt to dummy a PDS is made will cause an S013-64 ABEND

failure.

The DCB parameter may be required while coding DUMMY. Failure to do so

may cause an S013-10 ABEND failure.

DUMMY provides a safe way to eliminate I/O activity when required.

The JOBLIB DD Statement

The JOBLIB statement identifies the program library (load library) where the
programs to be executed throughout the job resides. It must be placed between the
JOB and the first EXEC statement.
E.g :
//da0001ta job,la2719,
//joblib
dd dsn=da0001t.lib.loadlib,disp=shr
//s1
exec pgm=proga
//s2
exec pgm=progb

Expanation : PROGA (and PROGB) is expected to reside in

DA0001T.LIB.LOADLIB as a member of a library and the system searches the
directory. If not found will search certain predefined libraries and the S806-04
ABEND failure occurs.
Remark :
A JOBLIB DD statement can have several concatenations (max: 16)
E.g
//da0001ta job,la2719,
//joblib
dd dsn=da0001t.lib.loadlib,disp=shr
//
dd dsn=da0001t.lib1.loadlib,disp=shr
//
dd dsn=da0001t.prod.loadlib,disp=shr
//s1
exec pgm=proga

Explanation : All concatenations may be searched to locate a program. If, however,

the program is found in a concatenation other than the last one, other concatenations
will not be used. Note that, if a duplicate names exist in different concatenations, the
user can decide which one is to be executed by determining the sequence of the
concatenations.

The STEPLIB STATEMENT

43

The STEPLIB statement identifies the program library (load library) where the
program to be executed for the step where STEPLIB resides. It can be placed
anywhere after the EXEC statement.

E.g 1:
//da0001ta job,la2719,
//s1
exec pgm=proga
//steplib
dd dsn=da0001t.lib.loadlib,disp=shr
//s2
exec pgm=progb
//steplib
dd dsn=da0001t.lib.loadlib1,disp=shr

Explanation : Program PROGA is expected to reside in DA0001TA.LIB.LOADLIB

as a member of the library. If not found, will search certain predefined libraries and
the S806-04 ABEND failure occurs.
E.g 2:
//da0001ta job,la2719,
//joblib
dd dsn=da0001t.lib.loadlib1,disp=shr
//s1
exec pgm=proga
//s2
exec pgm=progb
//steplib
dd dsn=da0001t.lib.loadlib,disp=shr
//s3
exec pgm=progc

A STEPLIB DD statement has the effect of negating the JOBLIB DD statement for a
particular step.

STORAGE DUMP
When a step encounters an ABEND failure, it is often advantageous to request a
virtual storage dump, which can then be helpful in determining the cause of an
ABEND. To request a storage dump, one of the following three DD statements must
be included in the step :
A SYSUDUMP DD statement

A SYSMDUMP DD statement

A SYSABEND DD statement

//sysudump dd sysout=*

All virtual storage allocated to your program i.e user region of jobs address space. It
is a formatted dump. SYSUDUMP usually writes to sysout. It can, however, write to
a disk dataset, providing a way to preserve the SYSUDUMP information for later
viewing and analysis.
//sysudump dd dsn=da0001t.dumpfile,space=(trk,(0,5),rlse),
//
disp=(,delete,catlg),unit=sysda

No DCB is required.
44

Remark :
SYSUDUMP DD statement is more often used.
//sysmudump dd sysout=*

This is same as SYSUDUMP DD statement except for the fact that the dump is
nonformatted. This type of dump is very difficult to analyze unless it is saved on a
disk and then processed by the PRDUMP service aid.
SYSMDUMP is seldom used.
//sysabend dd sysout=*

When a SYSUDUMP DD statement is included in a step which ABENDs, a

formatted virtual storage dump will be provided. This dump will also include
information about the failed step, as well as most of the MVS storage-resident
information which is of no use to the average user. SYSABEND is intended for
system programmer.
Remark :
1 If neither a SYSUDUMP nor a SYSMDUMP nor a SYSABEND statement is
coded wihin a JCL of an ABENDing step, a small amount of information is
provided. This information is seldom useful in resolving the problem that caused
the ABEND failure.
2

If more than one of the above statements is included in the JCL of a step, only the
last one will be used. The previous ones will be ignored.
//s1
exec pgm=ass1
//sysabend dd sysout=*
//sysudump dd sysout=*

Note that SYSUDUMP will be in use.

45

5.

PROCEDURE

There are two types of procedures :

- Catalogue Procedures
- InStream Procedures

CATALOGUED PROCEDURE is a member of a PDS which is often refered to

as procedure library or PROCLIB.

INSTREAM PROCEDURES contained within job's input stream.

INVOKING A PROCEDURE
//PR EXEC ABC
OR
//PR EXEC PROC = ABC
RESTRICTIONS

max 255 steps

The following are not permitted to reside in a procedure :

- JOB Statement
- An EXEC statement invoking a procedure
- JOBLIB
- JOBCAT
- DD * or DATA
- // null statement
- A PEND statement

Common Rules for EXEC & DD Statement to Override for JCL Procedures

A parameter can be replaced, added or nullified

When replacing an existing parameter, the overriding parameter must be specified

in its complete format. DCB is an exception

An overriding parameter replaces the same parameter, if it exists. It is added to

the statement if it does not exist.

A syntactical JCL error inside a procedure cannot be corrected by overriding the

erroneous parameter.

To nullify an existing parameter "parameter" = must be coded

To override any parameters in an concatenation other than the first one, the
following must be coded :

46

//stepname.ddname DD
//
DD
//
.
//
.
//
DD overriding parameters
To add an entire DD statement
// stepname.ddname DD complete parameter field.

RULES FOR EXEC STATEMENT OVERRIDING

To override any parameter in a DD statement an independent DD statement must

be supplied in the following format :

The sequence of overriding DD statements must be the same as the sequence of

the corresponding overridden statements. However, parameters within a DD
statement need not be overridden in sequence.

An additional DD statement must be the last one in a step's overriding statements.

To override an EXEC parameter, " parameter.stepname=value" must be coded

when adding or replacing a parameter and "parameter.stepname=" must be coded
when nullifying a parameter.

The PGM parameter cannot be overridden

All overriding EXEC parameters must be coded in the EXEC statement that
invokes the procedure.

All overrides to EXEC parameters must be completed before overriding

parameters in a subsequent step.

47

procedure lam
//S1
//
//STEPLIB
//IN1
//IN2
//
//REP
//OUT
//
//
//

EXEC PGM=ED, PARM=(A,B,C,E)

REGION=900K, TIME = (5,30)
DD DSN=DEV.LOADLIB,DISP=SHR
DD DSN=USER1.FILE2,DISP=SHR
DD DSN=USER1.FILEX,DISP=OLD
UNIT=TAPE, VOL=SER=000101
DD SYSOUT =*,
DD DSN=USER1.PLA,DISP=(,CTLG,DELETE),
UNIT=SYSDA, VOL=SER=BS3003
SPACE=(CYL,(20.5),DCB=(BLKSIZE=4000,
LRECL=80, RECFM=FB)

Required in step S1:

a)
b)
c)
d)

PARM must be (A,B,C,D) and TIME nullified

In IN1, DSN must be USER1.FILE3
IN2 must retrieve USER1.FILEX as a cataloged dataser
In OUT, BLKSIZE must be 23440

//S2
EXEC PGM=FORM, REGION=900K
//INA
DD
DSN=USER1.PLA,DISP=SHR
//
DD
DSN=USER1.F226,DISP=SHR
//
DD
DSN=USER1.F232,DISP=SHR
//
DD
DSN=USER1.F118,DISP=SHR
//OUTA
DD
DSN=USER.F323,DISP=(,CATLG,DELETE),
//
UNIT=TAPE, VOL=SER=001110
//
DCB=BLKSIZE=32700, LRECL=100,
//
RECFM=FB)
//PRNT DD SYSOUT=*

Required in Step S2 :
a)
b)
c)
d)

COND = (0,LT) must be coded

In INA DSN in the third concatenation must be USER1.F228
In DD statement OUTA, UNIT be SYSDA
An entire DD statement :
//STEPLIB DD DSN=DEV.LOADLIB,DISP=SHR
must be coded.

//S3
//1N3
//OUT3 DD
//
//
//
//PRINT DD
//

EXEC PGM=REPO,REGION = 400K, COND=(O,LT)

DD
DSN=USER1.F333, DISP=OLD
DSN=USER1.F111,DISP=(,CRLG,DELETE),
UNIT=SYSDA, VOL=SER=DEVO12,
SPACE=(CYL,(50,15),RLSE),
DC3=(BLKSIZE=23440,LRECL=80,RECFM=FB)
SYSOUT =*

48

Required in Step S3 :
a) EVEN must be added to the COND parameter
b) In DD statement OUT3, RLSE must be removed from the SPACE parameter must
be nullified.
SOME TYPICAL EXAMPLES
Example 1:
//S1
//OUT1
//
//
//

EXEC PGM=ONE
DD
DSN=U1.S1,
DISP=(,CTLG, DELETE),
UNIT=TAPE
DCB=(BLKSIZE=32700)

Required
OUT1 must be dummied
Override
//S.OUT1

DD DUMMY

Regardless of the contents, no other parameters are needed.

SOME TYPICAL EXAMPLES
Example 2 :
//S1
//IN1
//
//

EXEC PGM=ONE
DD
DSN=U1.B1,DISP=SHR
DD
DSN=U2.B2,DISP=SHR
DD
DSN=U3.B3,DISP=SHR

Required
Second concatenation of INI must be dummy
Override
//S1.INI

DD
DD
DD

DSN=U1.B3
DUMMY

Example 3:
//S1
//CNTL

EXEC PGM=ONE
DD
DSN=U1.CNTLIB(S1), DISP=SHR

Required
DD statement CNTL must be //CNTL DD*

49

Override
//S1.CNTL

DD*

Regardless of the contents DD * will override all.

Example 4 :
//S1
//OVT4 DD
//
//
//
//

EXEC PGM = ONE

DSN=U1.D1,DISP=NEW
DISP=SYSDA,VOL=SER=TEST26,
SPACE=CTRK,(500,50)),
DCB=(BLKSIZE=23400,
LRECL=100,RECFM=FB)

Required
DCB parameter must be eliminated
Override
//S1.OUT4

DD DCB=(BLKSIZE=LRECL=RECFM)

SYMBOLIC PARAMETERS & SYMBOLIC OVERRIDES

Symbolic overrides can be used only when symbolic parameters have been coded
inside the procedure

A symbolic parameter is a name preceded by an ampersand (&)

A symbolic parameter can be coded in place of any parameter, part of a parameter

in the parameter field of an EXEC, DD or OUTPUT statement.

SYMBOLIC PARAMETER
Example 1 :
//S1 EXEC PGM=BL
//IN
DD
DSN=&H1..INFILE,DISP=SHR
//OUT DD
DSN=&HQ..OUTFILE,DISP=,CATLG,DELETE),
//
UNIT=SYSDA, DCB=(BLKSIZE=32700)

//PSK EXEC BLTX,HQ=PROD

-

First period works as delimiter

50

Example 2 :
Procedure BLTX
//S1 EXEC PGM=BL
//IN
DD
DSN=&HQINFILE,DISP=SHR
//OUT DD
DSN=&HQOUTFILE,DISP=,CATLG,DELETE
//
UNIT=SYSDA,DCB(=BLKSIZE=32700)

//PSK EXEC BLTX,HQ='PROD.'

SYMBOLIC OVERRIDING
RULES FOR SYMBOLIC OVERRIDING

An EXEC statement keyword (TIME, REGION etc.) cannot be used as a symbolic

parameter.

A symbolic override in either the EXEC or PROC statement that has no

corresponding parameter in the procedure will result in a 'SYMBOL NOT
DEFINED' JCL error.

If a symbolic and a regular override conflict, the regular override always prevails.

A symbolic parameter which is immediately followed by an alphabetic, numeric

or national character must have a period at its end.

A symbolic parameter can be coded many times in a procedure. When

substitution occurs, all the occurrences will receive the same value.

When nothing must be substituted for a symbolic parameter, "symbolic-override='

must be coded in the EXEC or PROC statement.

PROCEDURE SSP
//S1 EXEC PGM = P1, PARM = &PEL
Assume possible values that the PARM parameter can assume are ALD, BLD, CLD,
etc.
//S1 EXEC PGM=P1, PARM = &PELLD
This will not work
Procedure SSP can be coded as
//S1 EXEC PGM=P1, PARM = PEL.LD
Now if the procedure is invoked
//A EXEC SSP, PEL=F

51

Substitution results in
//S1 EXEC PGM=P1, PARM = FLD
//S1 EXEC PGM = P1, PARM = &PEL
Example 1 :
//A EXEC SSP, PEL=FLD
Substitution results in
//S1 EXEC PGM=P1, PARM=FLD
Example 2 :
//B EXEC SSP, PEL = FLD, TIME = (5, 10)
substitution results in
//S1 EXEC PGM = P1, PARM=FLD, TIME = (5,10)
PROCEDURE SWP
//ABC
//S1
//IN
//OUT
//

PROCR=800K, Q=AUX, U=TAPE

EXEC PGM=P2, REGION=&R
DD
DSN=&Q..FILEX, DISP=SHR
DD
DSN=&Q..FILEY, DISP=(,CATLG)
UNIT = &U

//A

EXEC SWP, Q=MAX

Substitution results in
//S1 EXEC PGM=P2, REGION=800K
//IN
DD
DSN=MAX.FILEX, DISP=SHR
//OUT DD
DSN=MAX.FILEY, DISP=(,CATLG),
//
UNIT =TAPE

THE PROC STATEMENT

The purpose of the PROC statement is to contain symbolic override defaults.

When a procedure is executed, the system will substitute symbolic parameters

using symbolic overrides coded in the EXEC statement.

For those symbolic overrides not found in the EXEC statement, the default
symbolic overrides in the PROC statement will be used.

52

IN-STREAM PROCEDURES

An in-stream procedures is a part of a job's input stream and exists only for the
duration of the job.

The PROC statement in an in-stream procedure is mandatory and serves two

functions a) It signals the beginning of in-stream procedure
b) It contains default symbolic overrides.

The PEND statement must be coded in an in-stream procedure to provide a

delimiter

Remark :
1) A PROC statement in a catalogued procedure is optional. The only reason it is
required is to contain default symbolic overrides.
Example :
//da0001ta
JOB la2719,SATYA,msgclass=A,
//
msglevel=(1,1,),notify=da0001t
//*
Instream prosedure
//procbr14
proc
//s1
exec pgm=iefbr14
//sysprint
dd
sysout=*
//dd1
dd
dsn=da0001t.temp,
//
disp=(old,delete)
//
pend
//*
//step1
exec proc=procbr14
//s1.dd1
dd
dsn=da0001t.temp1,
//
disp=(,catlg,delete), unit=sysda,
//
space=(trk,(2,1)),
//
dcb=(1recl=80,recfm=fb,blksize=800)

//

53

6. UTILITY
IEFBR14 UTILITY
This Utility is commonly used to delete, allocate and to uncatalog dataset
Example 1 :
//DELETE
EXEC PGM=IEFBR14
//* TO DELETE A FILE
//DD1
DD
DSN=DA0001T.EMPLOYEE,
//
DISP=(MOD,DELETE,DELETE),
//
UNIT=SYSDA, SPACE=(TRK,0)

Example 2
//CREATE
EXEC PGM=IEFBR14
//*TO ALLOCATE A NEW FILE
//DD1
DD
DSN=DA0001T.EMPLOYEE,
//
DISP=(NEW,CATLG,DELETE),
//
UNIT=SYSDA,
//
SPACE=(TRK,(2,1)),
//
DCB=(BLKSIZE=800,LRECL=80,
//
RECFM=FB,DSORG=PS)

An excerpt of a code illustrating, the deletion of a dataset, before COBRUN1 step is

executed.
//DA000ITA
//
//DELETE
//LOGFILE
//
//COBRUN1
//STEPLIB
//
//INFILE
//OUTFILE
//
//
//
//
//
//SYSOUT

JOB

LA2719,SATYA,NOTIFY=DA0001T,
MSGCLASS=X, MSGLEVEL=(1,0)
EXEC PGM=IEFBR14
DD
DSN=DA0001T.MYFILE2,
SPACE=(TRK, (0),),UNIT=SYSDA
EXEC PGM=PROG2V1,PARM='AAAA'
DD
DSN=DA00021T,PVDB2.LOADLIB,
DISP=SHR
DD
DSN=DA00021T, EMPLOYEE
DISP=OLD
DD
DSN=DA00021T.MYFILE2,
DISP=(NEW,CATLG,DELETE),
DCB=(LRECL=80, DSORG=PS,
BLKSIZE=80, RECFM=FB),
VOL=SER=BS3011,
SPACE=(TRK, (45,15))
DD
SYSOUT=*

54

IEBGENER UTILITY
Interface Exec Block gener

This utility is commonly used to copy, concatenate and to empty sequential

datasets.

************************************************************************
* USING THE IEBGENER UTILITY TO COPY DATASETS
* SYSSUTI PROVIDING THE INPUT AND SYSUT2 BEING
* THE OUTPUT
************************************************************************
//DA0001TA
//
//CPYSTEP
//SYSSUT1
//SYSUT2
//SYSIN
//SYSPRINT
//

JOB

LA2719, SATYA, NOTIFY=DA000IT,

MSGCLASS=X
EXEC PGM=IEBGENER
DD
DSN=DA000IT.INDATA3, DISP=SHR
DD
DSN=DA0001T.NEW,DISP=MOD
DD
DUMMY
DD
SYSOUT=*

************************************************************************
* USING THE IEBGENER UTILITY TO CONCATENATE DATASETS
* SYSSUT1 PROVIDING THE INPUT AND SYSUT2 BEING
* THE OUTPUT
************************************************************************
//DA0001TA JOB LA2719,SATYA,NOTIFY=DA000IT,
//
MSGCLASS=X
//CPYSTEP EXEC PGM=IEBGENER
//SYSUT1
DD
DSN=DA000IT.INDATA1,DISP=SHR
//
DD
DSN=DA000IT.INDATA3,DISP=SHR
//SYSUT2
DD
DSN=DA0001T.MYOUT,
//
DISP=(NEW, CATLG, DELETE),
//
UNIT=SYSALLDA,
//
SPACE=(TRK,(5,1),RLSE)

55

************************************************************************
* USING THE IEBGENER UTILITY TO EMPTY EXISTING DATASET
************************************************************************
//DA0001TA JOB LA2719,SATYA,NOTIFY=DA00IT,
//
MSGCLASS=X
//CPYSTEP EXEC PGM=IEBGENER
//SYSPRINT DD
SYSOUT=*
//SYSUT1
DD
DUMMY, DCB=(BLKSIZE=800,
//
LRECL=80, RECFM=FB)
//SYSUT2
DD
DSB=DA000IT.MYOUT,
//
DISP=SHR
//SYSIN
DD
DUMMY
//

56

SORT UTILITY

The utility is commonly used to sort data, copy selective data, remove duplicates,
change data throughout the file.

This is the utility provided by MVS

USAGE : It reorders the Physical Sequential dataset as per requirement on given

field(s)
: These fields are called control fields or key fields.
WORKING : It assumes that all input records are out of sequence and it puts them in
sequence you request.
Eg. Employee data is sorted in the sequence of Emp. No., Emp. Name or Salary etc.
SORT UTILITY
Syntax
Sort fields = (position, length, format, sequence) or
Sort fields = (position, length, sequence.), format = format
This syntax is used if all the fields on which the dataset to be sorted are of same type.
Position : Location of the 1st byte of the key field, in the input record
Length : Length in bytes of the key field. Sum of all key fields (their lengths) should
not exceed 4092
Format : Two characters code that identifies the format (type) of the data
Sequence :

A - Ascending
D - Descending

MERGE UTILITY

This assumes that record are in proper sequence but at different locations i.e. in
different files. It merges those files into one, in the given sequence.

Eg. : General ledger transactions for different months, in the sequence of a/c no. to
be merged in one file.
SORT UTILITY

57

SORT JCL 1
//DA001TA JOB LA2719,SATYA, NOTIFY=DA0001T.MSGCLASS=X
//*******************************************************
//*SORT ON THE EMPLOYEE NAME IN ASCENDING ORDER
//*******************************************************
//SRTSTEP EXEC PGM = SORT
//SYSIN
DD *
SORT FIELDS = (1,5,CH,A)
/*
//SORTIN
DD
DSN=DA0001T.EMPLOYEE,DISP=SHR
//SORTOUT DD
DSN=DA0001T.OUT SORT,
//
SPACE=(TRK,(3,3)), UNIT=SYSDA
//SORTWK01 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SORTWK02 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SORTWK03 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SORTWK04 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SYSPRINT DD
SYSOUT=*
//SYSOUT
DD
SYSOUT=*
//SORTMSG DD
SYSOUT=*
//

SORT JCL 2
//DA001TA JOB LA2719,SATYA, NOTIFY=DA0001T.MSGCLASS=X
//*******************************************************
//*SORTS ON ASCENDING DEPTNO & DESCENDING ENAME
//*******************************************************
//SRTSTEP EXEC
PGM=SORT
//SYSIN
DD *
SORT FIELDS = (17,2,PD,A,2,6,CH,D)
//SORTIN
DD
DSN=DA000IT.DEPT,DISP=SHR
//SORTOUT DD
DSN=DA000IT.SORTOUT2
//
DISP=NEW,CATLG,DELETE)
//
SPACE=(TRK,(3,3)),UNIT = SYSDA
//SORTWK01 DD
SPACE(TRK,(10,5)), UNIT=SYSALLA
//SORTWK02 DD
SPACE(TRK,(10,5)), UNIT=SYSALLA
//SORTWK03 DD
SPACE(TRK,(10,5)), UNIT=SYSALLA
//SORTWK04 DD
SPACE(TRK,(10,5)), UNIT=SYSALLA
//SYSPRINT DD
SYSOUT=*
//SYSOUT
DD
SYSOUT=*
//SORTMSG DD
SYSOUT=*
//

58

SORT JCL 3
TO COPY SELECTIVE DATA
a) INCLUDE COND copies data that matches the condition given for e.g. in this
case it will copy data where one character in 19th position equals 'M' or 'S'.
//DA001TA JOB LA2719,SATYA, NOTIFY=DA0001T.MSGCLASS=X
/***********************************************************************
* SORTS ON THE INPUT FILE ON JOB AND SELECTS JOB BEGINNING WITH M
OR S INTO A DATA SET
//**********************************************************************
//SRTSTEP
EXCE PGM=SORT
//SYSIN
DD *
OPTION EQUALS
SORT FIELDS = (19,6,A), FORMAT=CH
INCLUDE COND = (19,1,CH,EQ,C'M', OR, 19, 1, CH, EQ, C 'S')
/*
//SORTIN
DD
DSN=DA0001T.INDATA3,DISP=SHR
//SORTOUT DD
DSN=DA0001T.SORTOUT3,DISP=(NEW, CATLG)
//
SPACE=(TRK,(3,3)), UNIT = SYSDA,
//
DCB=(BLKSIZE=800, LRECL=80, RECFM=FB,
//
DSORG=PS)
//SORTWK01 DD
SPACE=(TRK,(10,5)), UNIT=SYSALLDA
//SORTWK02 DD
SPACE=(TRK,(10,5)), UNIT=SYSALLDA
//SORTWK03 DD
SPACE=(TRK,(10,5)), UNIT=SYSALLDA
//SORTWK04 DD
SPACE=(TRK,(10,5)), UNIT=SYSALLDA
//SYSOUT
DD
SYSOUT=*
//

59

SORT JCL 4 (Sorts on Job and selects Jobs beginning with M and Deptno beginning
with 1)
//DA001TA JOB LA2719,SATYA, NOTIFY=DA0001T.MSGCLASS=X
//********************************************************
//*SORTS ON JOB INCLUDES JOBS BEGINNING WITH M AND DEPTNO
*BEGINNING WITH 1
//********************************************************
//SRTSTEP EXEC PGM=SORT
//SYSIN
DD *
OPTION EQUALS
SORT FIELDS = (19,6,A),FORMAT=CH
INCLUDE COND=(19,1,CH,EQ,C'M',AND,51,1,CSF,EQ,1)
/*
//SORTIN
DD
DSN=DA0001T.INDATA3,DISP=SHR
//SORTOUT DD
DSN=DA0021T.SORTOUT4,DISP=NEW,CATLG),
//
SPACE=(TRK,(3,3,)), UNIT = SYSDA,
//
DCB=(BLKSIZE=800, LRECL=80, RECFM=FB,
//
DSORG=PS)
//SORTWK01 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SORTWK02 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SORTWK03 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SORTWK04 DD
SPACE=(TRK,(10,5)),UNIT=SYSALLDA
//SYSOUT
DD
SYSOUT=*
//

SORT UTILITY
SORT JCL 5 (Sorts on Job and omits Jobs beginning with M or S
OMIT COND: INCLUDE and OMIT are mutually exclusive
Records which do not satisfy the condition are sorted and copies into the output
dataset
//DA001TA JOB LA2719,SATYA, NOTIFY=DA0001T,MSGCLASS=X
//********************************************************
//*SORTS ON JOB *OMITS JOBS BEGINNING WITH M OR S
//********************************************************
//SRTSTEP
EXEC PGM=SORT
//SYSIN
DD *
OPTION EQUALS
SORT FIELDS = (19,6,A),FORMAT=CH
OMIT COND = (19,1,CH,EQ,C,'M',OR, 19,1,CH,EQ,C'S')
/*

60

APPENDIX-A
(Assignments)
1.
Write a COBOL program to display to display hard coded values. Use
Compile/Link/Execute JCL to execute your program.
2.

Your are given a sample JCL with syntax errors, you have fix it. First JEM it,
find out the errors and then debug errors one at at a time.

3.

Try out all the parameters discussed on day 1 at JOB statement. Change one
parameter at a time.
- Change Jobname
- Change Account Number
- Violation of continuation rules for paramaters.
- MSGLEVEL
- CLASS
- MSGCLASS
- PRTY
- NOTIFY
- RESTART
- SCAN
Distinguish the difference between SCAN and JEM.
Note down the observation you made in your Compile/Link/Execute JCL and
submit this to the faculty as an assignment.

4.

Display the records from the G2 group with the use of PARM parameter at the
EXEC statement. Use the EMPFILE (flat file) created during the MVS Lab
session. Read the said file and compare the department value of each record
with the value passed through PARM parameter. Note all the ABEND codes
encountered and analyse the cause.

5.

Change the existing values in the COND parameter of Compile/Link/Execute

JCL. Let there be syntax errors in your COBOL program.
Remove all the COND Parameter and submit your JCL errors.And See what
happens.

6.

Write a COBOL program that reads from the EMPFILE and write onto
another sequential file. Specify a DD statement that creates the newfile in your
Run step.

7.

Create a member by name PROC and copy the Compile-Link JCL in your JCL
PDS. Remove the JOB statement and run step. JEM it if no errors, execute any
of your COBOL program by invoking the cataloged procedure. Code the
appropriate overriding statements.

8.

Create another member by INSPROC. Try out instream procedure by making

necessary changes in the Compile/Link/Execute JCL. Code the appropriate
overriding statements.

9.

Try out symbolic parameter overrides by making changes in assignment 6.

Invoke the PROC procedure by passing the correct parameters at the EXEC
statement.
61

10.

Write a JCL to create a sequential dataset and a PDS using IEFBR14.

11.

Write a JCL for IEBGENER to copy from EMPFILE into another. Try out all
the JCLs given in the handout.

12.

Write a JCL to sort the EMPFILE in descending or ascending order of EMPNO.

62

13.
APPENDIX-B
(Bibliography/references)

Expert MVS/XA JCL

-Mani Carathanassis

MVS/JCL

-Doug Lowe

63