Professional Documents
Culture Documents
* *
* ------------------ *
* JCL QUESTIONNAIRE *
* ------------------ *
* *
***********************************************************************
JCL is not a procedural language. It is a means of communications between a program & the MVS
o/s.
The JOB Statement
KEYWORD Parameters :
CLASS : To identify characterstics like short-running, heavy resource requirement
(A-Z or 0-9)
PRTY : To assign priority ( 0-14 or 0-15 depending on JES being run at the time.
MSGCLASS : To determine the output device to which system messages & JCL messgaes are
written.
MSGLEVEL : To specify JCL & allocation messages which will be recorded on the output device
specified in MSGCLASS.
MSGLEVEL=(statements,messages)
MSGLEVEL=(,messages)
MSGLEVEL=(statements)
Temporary Data Sets can be created using && followed by 1 to 8 characters. They are deleted
after a job completion.
Syntax : DISP=(status,normal-disposition,abnormal-disposition)
//DATA DD DSN=FILE1
// DD DSN=FILE3
// DD DSN=FILE3
It is used to obtain a dump of the contents of various registers and variables in case of abnormal
termination of the job.
//SYSDUMP DD ... Comments
e.g. //SYSDUMP DD DSN=DUMPFILE, UNIT=3390,
Same as SYSDUMP statement and also listed to the output device or data set.
SYSIN is not a parameter but it is the conventional ddname assigned to input data stream.
•
//SYSIN DD * //SYSIN DD DATA
<lines of data>
/*
//SYSIN DD *,DLM=‘xx’
<lines of text>
/* * ‘INPUT’
xx
//SYSOUT DD SYSOUT=A
//SYSOUT DD SYSOUT=*
The asterisk is assigned to the SYSOUT parameter. Implying that the class is assigned to the
MSGCLASS parameter will also be used for SYSOUT. Thus SYSOUT is assigned to the CLASS
K. (??)
ANYLOCAL is used to route the output to a local device, device_name is the name of the
destination device which is physical address that was given to the device at the time the system is
generated. The name of the output device to which the output is directed to is group_name. The
name of the remote node is node_name.
This parameter is coded on the DD statement to specify whether the output is to be printed
immediately or held till further notice.
//DATA1 DD DSN=FILE1,SYSOUT=A,HOLD=YES
This parameter is coded on the DD statement and is used to limit the number of lines that are output
to the destination specified in SYSOUT. It is used to avoid printing excessive amount of data in a
print environment.
//DATA1 DD DSN=FILE1,SYSOUT=A,SYSLIM=1000
JCL Procedures : JCL statements are grouped together into procedures. No more than 255 job
steps can be coded in one procedure.
//PROC1 PROC
//STEP1 EXEC PGM=PROGRAM1
//DD1 DD DSN=FILE1,DISP=SHR
//STEP2 EXEC PGM=PROGRAM2
//DD2 DD DSN=FILE2,DISP=SHR
// PEND
Cataloged Procedures : A catalogued procedure is a set of job control statements that are grouped
together, given a name and than recorded as a member of a partitioned data set. IBM supplies a
utility program called IEBUPDTE which places cataloged procedures into partitioned data sets.
Traditionally, these procedures are placed inside a system library called SYS1.PROCLIB.
//CATALOG1 PROC
//STEP1 EXEC PGM=PROGRAM1
//DD1 DD DSN=FILE1,DISP=SHR
//STEP2 EXEC PGM=PROGRAM2
//DD2 DD DSN=FILE2,DISP=SHR
//
IN-STREAM Procedures :
Instream-procedures are similar to cataloged procedures except that they are not the members of
partitioned data sets. They are included in the inputstream of the job itself. The same in-stream
procedure can be invoked more than once within the job.
One can easily change the parameters in DD statement without actually changing the contents of
the original procedure as follows
//INSTREAM PROC
//STEP1 EXEC PGM=PROGRAM1
//DD1 DSN=FILE1,DISP=SHR
//STEP2 EXEC PGM=PROGRAM2
//DD2 DSN=FILE2,DISP=SHR
// PEND
//PROC2 PROC
//STEP1 EXEC PGM=PROGRAM2
//DD1 DD DSN=TEST.FILE1,DISP=SHR
// DD DSN=TEST.FILE2,DISP=OLD
// DD DSN=TEST.FILE3,DISP=MOD
// DD DSN=TEST.FILE4,DISP=OLD
// PEND
SYMBOLIC PARAMETERS :
These are used to override parameters on the DD statement. They can be used both in catalogued &
in-stream procedures. It provides a convenient way of assigning different parameters to commonly
used JCL procedures.
GDG’s are groups of data sets which are related to each other chronologically & functionally.
Generation can be continued until a specified limit is reached. Once this limit is reached, then the
oldest generation can be deleted.
//SYSIN DD *
ALTER gdg-name parameter, parameter, ...
/*
:: Utility Programs ::
Utility helps expediate a task.
A piece of work submitted to the operating system for processing is called a job. A job consists of
one or more steps. To describe this job to the MVS operating system, the programmer uses Job
Control Language, or JCL. The JCL tells MVS which program is to be executed at each step,
which inputs each step requires, and which output each step produces.
1. The JOB statement, which makes the beginning of a step, tells which program is to be executed
in that step, and describes certain attributes of the job.
2. The EXEC (execute) statement, which marks the beginning of a step, tells which program is to
be executed in that step, and describes certain attributes of the step.
3. The DD (data definition) statement, which identifies the inputs and outputs for each step
To illustrate how these statements work together, consider a job with just one step. The JCL for
such a job might be constructed like this:
//.....JOB..........................
//.....EXEC........................
//.....DD.............................
//.....DD.............................
//.....DD.............................
The job statement always comes first and is followed by the first(and, in this case, only) EXEC
statement, which tells which program is to be executed. The EXEC statement is followed by the
DD statements, each of which describes a different input file required by the program or an output
file produced by the program. DD statements always follow the EXEC statement for the step to
which they apply.
In a multistep job, each EXEC statement is followed by the DD statements required for that step:
//.....JOB..........................
//.....EXEC........................
//.....DD........step1............
//.....DD.............................
//.....EXEC........................
//.....DD.........step2..........
//.....DD.............................
//.....EXEC........................
//.....DD..........step3.........
//.....DD.............................
When several jobs are submitted as a group, the group of jobs is called a job stream or sometimes
an input stream.
//.....JOB..........................
//.....EXEC........................
job 1-------------- //.....DD.............................
//.....DD.............................
//.....JOB..........................
job 2-------------- //.....EXEC........................
//.....DD.............................
//.....JOB..........................
//.....EXEC........................
job 3-------------- //.....DD.............................
//.....DD.............................
//.....EXEC........................
//.....DD.............................
//.....DD.............................
There is more to JCL than the JOB, EXEC, and DD statements, but you will find that the vast
majority of the JCL you write will consist of just those three statements.
JCL CODING RULES:
JCL isn’t a true programming language, but it does have some coding rules you must obey.
One line of JCL can contain upto 80 characters, although a single statement can run to several lines.
A JCL statement has the following general format:
1. JCL statements must begin with two slashes (//) in position 1 and 2. The slashes identify the
statement as JCL.
2. Every JCL statement has a name, which begins immediately following the //. in position 3. The
name identifies the statement so that it can be referred to by other statements and by MVS itself.
The name can contain from 1 to 8 characters and include alphabetic, numeric and national (#, @, $)
characters. However the first character must be either alphabetic or national.
3. The operation field follows the name and is separated from it by one or more spaces. This field
tells whether the statement is JOB, EXEC, or DD.
4. The parameter list follows the operation field and is separated from it by one or more spaces. The
parameters contain the information about each job, step or dataset that MVS needs to know. The
parameter list can extend through position 72. When the list contains more than one parameter, the
parameters must be separated by commas. Note that there can be no spaces between parameters.
5. Comments follow the parameter list. Comments are documentation indented to clarify the JCL
for a human reader; MVS ignores then. Comments can appear anywhere after the parameter list,
but they must be separated form it by at least one space. They can continue through position 80.
EXAMPLES:
The name of this statement is PAYROLL. The statement contains four parameters:
(A68,XX34,DEV)
SATISH
CLASS=A
TIME=5
There are no comments in this job statement.
When JCL is submitted to MVS for execution, the operating system first checks the JCL for proper
syntax. When it detects errors such as the above, the JCL is rejected and must be corrected. The
rejected JCL will be accompanied by messages that will help you find and correct the errors. But of
course, it’s better not to make error in the first place.
Note : Before submitting the job we can check for syntax errors by using command JEM on the
ispf command line.
You can continue the parameter list of a JCL statement onto multiple line by following these simple
rules:
2. Begin the next line with a // in positions 1 and 2. omit the name and operation fields, and begin
the next parameter between positions 4 and 16.
Here is the JOB statement you saw above with the parameter list continued over two lines.
Some programmer like to take advantage of the ability to continue statements by placing each
parameter on a different line, like this:
PARAMETERS:
There’s little mystery to beginning each JCL statement with //, and the name and operation fields
are pretty straightforward. But parameters are another story.
The parameters are divided into to two categories: Positional parameters and Keyword parameters.
Positional parameters are identified by their position in the parameter list; that is, MVS can
tell what a positional parameter is by and where it is. Keyword parameters are identified by the
specific keywords they begin with. When a statement contains both positional and keyword
parameters, the positionals as a group must precede the keywords. Positional parameters must be
coded in a specific sequence, while keyword parameters can be coded in any order.
For example, look at this JOB statement:
//PAYROLL JOB (A68,XX34,DEV),SATISH,CLASS=A,TIME=5
In this statement, (A68,XX34,DEV) represents installation accounting information and SATISH is
the name of the programmer responsible for the job. The accounting information and programmer
name parameters are positional parameters on the JOB statement; if used, they must be the first two
parameters coded on the statement, and they must appear in that order. On the other hand
CLASS=A and TIME=5 are keyword parameters. They must follow the positional parameters, but
their order is not significant. This JOB statement could just as well have been coded as
//PAYROLL JOB (A68,XX34,DEV),SATISH,TIME=5,CLASS=A
All keyword parameters are optional; they can be coded or not as the situation requires. Some
positional parameters are optional as well, but a difficulty arises when an optional positional
parameter is omitted. Here is an example, on the JOB statement, there are two positional
parameters. MVS assumes that the first parameter on the statement is the accounting information
and the second parameter is the programmer name. On the JOB statement
MVS assumes that (A68,XX34,DEV) is the accounting information and SATISH is the
programmer’s name. If the optional accounting information parameter were omitted and the
statement written as
The comma preceding the programmer name shows that the accounting information has
deliberately been omitted, and there is no chance that MVS will interpret SATISH as accounting
information.
Every MVS job begins with a JOB statement. The JOB statement marks the beginning of a job,
names the job, and describes certain characteristics of the job to MVS so that the control program
can handle job properly.
The job name follows two slashes. MVS uses the job name to identify the job and its inputs and
outputs. When the job is submitted for execution MVS assigns a number to it that it uses internally
to identify the job’s components.
Most of the JOB statement parameters are keyword parameters. But the first two - ACCOUNTING
INFORMATION and PROGRAMMER NAME are positional. Each parameter on the JOB
statement represents a particular piece of information about your job that is communicated to MVS.
The first positional parameter on the JOB statement is the ACCOUNTING INFORMATION
parameter. It consists of information MVS uses to determine who to charge for the job.
PROGRAMMER NAME: Who is responsible for the job?
The second positional parameter on the JOB statement is called the PROGRAMMER NAME
parameter. However, it does not necessarily have to include the programmer’s name. The
PROGRAMMER NAME parameter consists up to 20 characters of identifying information relating
to the job. It is usually used to identify the programmer responsible for the job, but it could just as
well specify a room number, a department name, or almost anything else.
A Reminder
Remember that both ACCOUNTING INFORMATION and PROGRAMMER NAME are optional
parameters. If you choose to omit one or both of them, you must code a comma to indicate the
missing parameter or parameters.
The remaining parameters that can be coded on the JOB statement are keyword parameters. That
means they can be coded in any order you wish.
(The data given above is true data given by SEALAND onsite team for SEALAND TEST system)
As jobs are processed by the computing system, the control program produces a series of
messages(including the job’s JCL itself) that document the processing that has occurred. But these
system messages are not printed as they are produced. Instead they are stored in a special disk
dataset and printed at a later time.
The various output groupings are called output classes. The class to which a job’s system messages
are routed is determined by the optional MSGCLASS parameter. As with job classes, there are 36
possible output classes, each named by a single letter or digit.
The EXEC Statement
The EXEC statement marks the beginning of a job step and tells MVS which program is to be
executed in that step.
Like the JOB statement the EXEC statement begins with two slashes and a name. However
while MVS requires the job name, step names are optional.
If step name is used it must confirm to the same rules as the job name; that is, it must consist of
from 1 to 8 alphabetic, numeric or national (#, $, @) characters, and the first character must be
alphabetic or national.
A number of parameters can be coded on the EXEC statement. One of those parameters are PGM=
parameter. Though it looks like a keyword parameter it is POSITIONAL parameter that names the
program to be executed and it consists of the characters PGM= followed by the program name. For
example, if the payroll program is named PAY you might code
The DD Statement:
DD statements tell MVS about the input and output requirements of the program being executed.
Most programs require some input data and produce some output. DD statements tell MVS where
the required input should come from and where the output being produced should go to.
The ddname
Like the JOB and EXEC statements, the DD statement begins with two slashes followed by
a name. The name of the DD statement, usually called a ddname, must follow the same rules as the
other names. It must consist of from one to eight alphabetic, numeric, or national characters, the
first of which must be alphabetic or national. The DD statement provides the connection between
the actual physical data and the description of that data in the program that uses it.
Reserved ddnames
There are several words that are valid ddnames but nevertheless must be used with care
when used for this purpose. This is because DD statements with these names invoke special
facilities within MVS. That is when MVS sees a DD statement with one of these names it expects
the files associated with them to be used for certain specific purposes. Use these names only when
you want to see use the special facilities associated with them. The following are the special
DDNAMES to be avoided while coding usual dataset names....
JOBCAT
STEPCAT
SYSABEND
SYSMDUMP
SYSCKEOV
JOBLIB
STEPLIB
SYSUDUMP
SYSCHK
When a DD statement describes an input file, it must contain information that tells MVS where the
data is and how it is stored. The easiest way to deal with the input data is to include it directly in the
job stream with the JCL. Such data is therefore called in-stream data.
When you use in-stream data, the DD statement that describes it must contain a parameter
that tells MVS that the data is present in the job stream. The parameter is a positional parameter,
and it consists of a single character: the asterisk (*). When used, the * must be the first parameter
on the DD statement. Specifically, the * means that the data described by the DD statement is
included in the job stream and begins on the line that immediately follows the DD statement
containing the *.
Here is an example:
Suppose the program GR9203EP prints a list of all the people who own stock in the SEALAND
INC., The program has been written to expect a DD statement named STKHLDRS that defines the
names to be printed. The JCL for executing this program might be coded like this:
The STKHLDRS DD statement specifies in-stream data. The lines immediately following the DD
statement constitute that data. We can tell that those lines contain data rather than more JCL
because they have the following characterstics:
1. The lines immediately follow a DD * statement.
2. None of the “data lines” begins with // as JCL must.
If the DD * statement marks the beginning of in-stream data, you also need a way to indicate the
end of that data. There are three ways to accomplish this:
* The delimiter statement. This is a special JCL statement whose sole purpose is to mark the
end of in-stream data. The delimiter statement consists of the characters /* in the first two positions
of the line. Notice that the delimiter statement is the only JCL statement that does not begin with //.
Also, delimiter is usually optional.
* The next JCL statement. In the absence of a delimiter, the next JCL statement( the next
statement that begins with //) serves to terminate the in-stream data.
* The end of the job stream. If the in-stream data occupies the last lines in the job stream.
MVS will realize that the end of the job stream is also the end of instream.
If the DD * statement is the easiest JCL statement to code, the DD statement for producing
hardcopy output must be the next easiest.
The MSGCLASS parameter is used on the JOB statement to route system messages to a particular
ouptut class. You can use the SYSOUT parameter on the DD statement to route program output to
one of those same classes.
Suppose you want to test a program that produces an report, that the program has been coded to
expect a DD statement named REP1 to allocate the output file to contain the report and you want
the output report to be printed on output class A. The DD statement for having this report routed to
output class A is
//REP1 DD SYSOUT=A
SYSOUT is a keyword parameter. Thus, when it appears with other parameters, its position in the
parameter list is insignificant. Particularly speaking, however most programmers code the
SYSOUT parameter as the first one on the DD statement on which it appears.
Both MSGCLASS and SYSOUT refer to the same set of output classes. Although they are used on
different JCL statements and affect the routing of different kinds of output (system output for
MSGCLASS and program output for SYSOUT), the two parameters can work together.
Look at the parameter SYSOUT=* in the above DD statement. When a SYSOUT parameter
contains an asterisk instead of a job class, it tells MVS to route this output to the same output class
that the system output is going to. If a MSGCLASS has been coded, the class specified in that
parameter is used for the SYSOUT output as well. If no MSGCLASS is coded, SYSOUT output is
routed to the default output class along with the system output.
In other words coding SYSOUT=* is an easy way to keep program and system output
together. In addition, coding SYSOUT=* makes changing your JCL a bit easier.
DATASET NAMES:
You give a dataset a name for the same reason you give a person a name-- so that you will have
some way to refer to it. MVS has a set of rules you must follow when naming a dataset:
1. The name may contain a maximum of 44 characters.
2. The characters can be alphabetic, numeric, or national (@, #, $). Spaces cannot be used.
3. The first character must be alphabetic or national.
4. If the name contains more than eight characters, it must be divided into smaller strings with
periods so that each string is no longer than eight characters.
5. The periods must be counted in the 44 character maximum.
6. When the name is divided into strings, each string must begin with an alphabetic or national
character.
The DSN parameter:
To tell MVS the name of a dataset, you use the DSNAME keyword parameter. To specify a dataset
named CHGMAN.PROD.SOURCE, for example you would code the parameter
DSNAME=CHGMAN.PROD.SOURCE
However MVS allows you to abbreviate the DSNAME parameter to just DSN. Since the DSN
parameter is a keyword parameter you can code the above statement as
DSN=CHGMAN.PROD.SOURCE
and it can appear anywhere in the parameter listof a DD statement. However, when most
programmers use the DSN parameter, they code it as the first one. Thus, we might begin a DD
statement that specifies the creation of a tape dataset something like this:
//OUT1 DD DSN=L1234.USER.TEST.REPORT,......
After identifying the dataset by name, you might tell MVS whether the dataset in question is
existing one to be retrieved or a new one to be created. You do this with the DISP parameter. DISP
stands for disposition, and thus it tells MVS how to dispose of the dataset. DISP is a keyword
parameter, but it has three positional subparameters. The general form of the DISP parameter is
DISP=(status,normal disposition,abnormal disposition)
The first positional subparameter of DISP tells the current status of the dataset. The two options for
this subparameter are:
NEW The dataset does not yet exist but is to be created in the current job step.
OLD The dataset is already exists and is to be retrieved for use in the current job step.
The second positional subparameter of DISP tells MVS what to do with the dataset--how to
dispose of it-if the current job step ends normally. The two options for this subparameter are:
KEEP The dataset should be retained by the system for future use
DELETE The dataset is no longer needed and may be eliminated from the system.
The third positional subparameter of the DISP tells MVS how to dispose of the dataset when the
current step terminates abnormally. The options for this subparameter are identical to those for the
second subparameter--KEEP and DELETE. If the third subparameter is not coded, MVS assumes
as a default value the value of the second subparameter. Thus the parameter
By the way, all three subparameters of DISP are optional, and so is the DISP parameter itself. If the
DISP parameter is not coded on a DD statement, MVS assumes that a new dataset is to be created
and deleted in the current step; that is, if DISP is not coded, the default DISP is
DISP=(NEW,DELETE,DELETE)
If the DISP is coded but the first subparameter is omitted, MVS assumes a new dataset is to be
created. Thus ,
DISP=(,KEEP)
is identical to
DISP=(NEW,KEEP)
Note: For rest of information on this disposition parameter please refer to the quick reference in
sealand TSO session using ispf option P.Q.
Apart from above standard statements the following are the special JCL statements used in Job
Control Language....
** The JCLLIB Statement **
Syntax:
dsn1, dsn2, dsn3, etc. - the fully qualified data set name(s) of the
system or user PDS(s) containing the JCL procedures or
INCLUDE groups referenced in this job. The data set name(s)
cannot include a member name specification, and must be
cataloged in a catalog other than a catalog named by a
JOBCAT or STEPCAT statement in the same job. You cannot
name temporary data sets on a JCLLIB statement. The data
sets named must be accessible to this job (i.e., access is
permitted by the security system) and must be online to MVS
on a DASD volume.
The data sets are searched in the order that they are
specified on the JCLLIB statement; if the needed PROCs or
INCLUDE groups are not found in the named data sets, then
the installation-specified default libraries are searched.
The data sets named must be Partitioned Data Sets with an
LRECL of 80 and a RECFM of F or FB; an valid blocksize that
is a multiple of 80 may be used.
If only one data set name is specified, you can omit the
surrounding parentheses used for the ORDER parameter.
EXAMPLES:
Syntax:
Examples:
The PEND statement marks the end of an in-stream procedure (i.e., every
in-stream procedure should have a PEND statement at the end of the
statements that make up the in-stream procedure). A PEND statement can
also appear at the end of a cataloged procedure (but this is not
required).
Syntax:
Examples:
//PEND1 PEND
You can nullify a JOBLIB for a job step by adding a STEPLIB to the
step that points to SYS1.LINKLIB.
Syntax:
//JOBLIB DD DISP=SHR,DSN=program-library-name
The program search order for MVS uses the following program
libraries in the order given:
Syntax:
//STEPLIB DD DISP=SHR,DSN=program-library-name
The program search order for MVS uses the following program
libraries in the order given:
SYSOUT=class
or
SYSOUT=(class,{INTRDR}{,form name})
or
SYSOUT=(class,{writer name}{,form name})
or
SYSOUT=(,)
Subparameter Definition
class
INTRDR
form name
(,)
Indicates a null SYSOUT file; the CLASS parameter on an
OUTPUT JES statement in this job is to be used for the
SYSOUT class.
Thanks for going thru the document. Now you can start writing JCL and you can submit it
using the SUB command. ‘Let me know if you can shutdown MVS by submitting a JCL’.
I Wish you good luck.
7. Return code is issued if a job or job step exceeded the time limit
The system will issue a system code of 322 when a job or job step has exceeded the time
limit. If the time parameter was used on the JOB or EXEC statement, it may not have allowed
enough time for the job or job step to complete. If the time parameter was not used, then it is
important to check the program for possible logic loops.
9 Abend codes generated when not enough disk space is available ...
Some of the abends generated due to a lack of available disk space are:
1. B37-Disk volume out of space, cannot write output. The system gave all the primary space and
as much secondary space as it could.
2. D37-Primary disk space was exceeded and either no secondary space allocation was specified or
it was insufficient. One should increase the primary space as well as provide adequate secondary
space allocation to eliminate this error.
3. E37-There was insufficient space on the volume. One way to solve this problem is to specify
more volumes on the JCL.
Q. What is the difference between the JOBLIB and the STEPLIB statements?
A. The JOBLIB statement is placed after the JOB statement and is effective for all job steps. It
cannot be placed in a cataloged procedure. The STEPLIB statement is placed after the EXEC
statement and is effective for that job step only. Unlike the JOBLIB statement, the STEPLIB can be
placed in a cataloged procedure.
Q. Name some of the JCL statements that are not allowed in procs.?
A. Some of the JCL statements which are not allowed in procedures are:
1. JOB, Delimiter(/*), or Null statements
2. JOBLIB or JOBCAT DD statements
3. DD * or DATA statements
4. Any JES2 or JES3 control statements