In this course, you will
learn to identify the characteristics of both instream and cataloged procedures
and state the rules that cover coding procedures.
In this unit, you will learn the resources necessary to compile a COBOL program. You will also learn to code a complete JCL jobstream to compile a COBOL program.
After completing this unit, you should be able to:
Most JCL procedures are a result of the need to perform a task repeatedly.
One such need is compiling a program.
Throughout this course, the base example is the JCL required to compile and create an executable module for a COBOL program. It will show you how procedures work.
*Compiling the COBOL Program
The remainder of this unit addresses the resources needed by the COBOL compiler.
A sample jobstream with the necessary JCL statements and parameters is displayed.
Note: Throughout this course, examples will use data sets that are not managed by SMS. If you use SMS, your JCL may be slightly different.
*Necessary Resources for Compiling
Compiling your COBOL program will use or create the following:
1. Source Program
2. COBOL Compiler
3. Object Module
4. Work Files
5. Printed Listing
Following is an explanation of each item.
*Explaining the Necessary Pieces
1. Source program — COBOL is a high-level computer language that uses words and phrases similar to English.
2. COBOL compiler — The compiler translates the COBOL program's words and phrases into machine code — a language the computer understands.
3. Object module — The machine code version of the program is called an object module. This is usually stored on disk.
*The Work Files and Printed Listing
4. Work files — The compiler requires extra space to work in while it's translating from source to object.
5. Printed listing — The source program and any messages from the compilation are printed.
//CMPL JOB (9797,DEPTK),G.SAMSA,TIME=1
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*A Complete JCL Jobstream
Here is a very simple version of the complete JCL jobstream needed to compile a COBOL program.
The JCL at your installation is coded in more detail to reflect your standards.
//CMPL JOB (9797,DEPTK),G.SAMSA,TIME=1
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*A Simple Example
This JCL uses very basic settings. The jobstream will change and expand as you work with this procedure and set it up for more general applications.
Above, some parameters such as the SYSLIN DCB are omitted. Their default values are used instead. This keeps the procedure simple and easy to read.
//CMPL JOB (9797,DEPTK),G.SAMSA,TIME=1
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,S
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*Meeting the COBOL Compiler Requirements
Here is how this JCL reflects the COBOL compiler requirements.
In the next section, you will have a chance
In the first section of this unit, you looked at what was involved in compiling a COBOL program. You also got a quick look at the complete JCL jobstream used to accomplish this task.
This section offers you a chance to look at the jobstream in detail.
Or, if you prefer, you can just look at a quick review of the JCL, and then get on with the discussion of JCL procedures.
*The Necessary Resources
You know from the previous section that compiling a COBOL program uses or creates these resources:
*Another Name for the COBOL Compiler
The COBOL compiler is really just another program with the name IGYCRCTL:
*Naming the Source Program and Object Module
In this example, both the source program and the object module are stored in disk files with the names MYPROG and MYOBJECT:
*JCL Statement Stubs for Compiling
Here are the JCL statement stubs that are coded to compile the COBOL program.
*Reviewing the JCL Statements
Now that you know what is involved in compiling a COBOL program, it's time to write the JCL statements that will allow you to do so.
But you already know how to do that, don't you?
So let's review each statement. You can help complete some of them, and answer questions as you go. ...
You know from previous experience that JCL must be coded carefully and correctly. The operating system cannot guess what you mean — you must code precisely what you want.
To help your coding of JCL in this course, always start your statement in the first position of the input area provided. Do not space the cursor over to the right before starting the JCL statement. If you do, your answer will be incorrect.
*The Job Statement
Here's the job statement you'll use. Notice that this job is charged to account number 9797, department K. The programmer's name is G. Samsa.
//CMPL JOB (9797,DEPTK),G.SAMSA
*The EXEC Statement
The next line in the jobstream is the EXEC statement.
The purpose of this statement is to define the program to be executed, in this case the COBOL compiler. This EXEC statement defines a job step. The name of the EXEC statement is the JOB STEP name.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
*The Work Files
Now all seven work files are set up.
Although they are listed above in numerical order for convenience, please note that you can establish the work files in any order.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD
//SYSUT2 DD
:
//SYSUT7 DD
*Examining the Parameters
Before going on to the next statement in the sequence:
*Choosing a DASD Volume
//SYSUT1 DD ,SPACE=(CYL,(1,1)
Choose any DASD volume from the group of volumes labeled SYSDA.
*Setting Up a Storage Space
//SYSUT1 DD UNIT=SYSDA,
Set up primary and from the group of secondary storage spaces volumes labeled SYSDA of 1 cylinder each.
*Default Values for Parameters
Note the default values for parameters not listed. In the example data definition statement...
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
...no data set name, disposition or data control block is specified.
Therefore, the system automatically assigns the following values:
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
*The SYSPRINT DD Statement
This SYSPRINT DD statement sends the printed listing to output Class A. No special forms are requested.
For this particular example, a SYSOUT code of A prints your listing on regular paper at the standard output class.
This code is installation specific, so check for the ones that are used at your location.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
*The Data Definition Statement
Next, a DD statement with the data definition name of SYSLIN tells the compiler where to put the object module.
Here's a detailed explanation of this statement.
*Explaining the DD Statement
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
*A DD Statement for the Source Code Location
You also need a DD statement that tells the compiler where to find the source code.
The last line in the jobstream above assumes that your source program resides in a data set called MYPROG.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*JCL Is Simple for Compilation of COBOL Program
As you can see, the JCL needed to compile a COBOL program is fairly simple:
1. It involves only one JOB step.
2. You always use the same statements.
3. There are only minor variations.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*Advantage of the JCL Procedure
By using a JCL procedure, you won't have to code the same JCL every time you want to compile your program.
In this unit, you will
learn the ways to minimize redundant JCL: procedures and INCLUDE
groups. You will learn to distinguish two types of JCL procedures. You will also
learn how to use INCLUDE statements and INCLUDE groups.
In the last unit, you saw that the JCL needed to compile a COBOL program was a fairly simple jobstream of one step.
It was also decided that the JCL wouldn't change much from time to time.
*Minimizing Redundant JCL
As you may recall from the JCL: Fundamentals course, there are two ways to minimize redundant JCL:
1) Using procedures
2) Using INCLUDE groups
*Types of JCL Procedures
There are two types of JCL procedures:
Instream procedures are:
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
// EXEC COMPILE
*An Instream Procedure Example
Here is the JCL example for compiling a COBOL program written as an instream procedure.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
// EXEC COMPILE
*The New Statements
As you can see there are only two new statements added. You'll learn about these in the next unit. For now, let's see how this is executed.
*Executing JCL Statement in an Instream Procedure
JCL statements within an instream procedure are executed only when the procedure is executed.
//BKUP PROC
: These JCL statements aren't executed until
// PEND
// EXEC BKUP the procedure is called and executed with this
EXEC statement.
Cataloged procedures are:
*JCL Coding for a Cataloged Procedure
Here's how to compile the example COBOL program when you've written the JCL as a cataloged procedure:
//CMPL JOB (9797,DEPTK),G.SAMSA
As you can see, once you get the procedure stored in a library it really simplifies your JCL coding.
All the JCL statements in the procedure are stored in the library. When the procedure is called, the statements are retrieved and executed
*Instream Versus Cataloged Procedures
Instream procedures are more limited in use than cataloged procedures.
They are, however, an excellent vehicle for testing and special purpose jobs.
The JCL INCLUDE statement is similar to the INCLUDE (or COPY) statement/command found in many programming languages. It provides an easy way to include frequently used JCL statements in your jobstream. It may also be used as an alternative to some procedures, depending on your installation standards and personal preference.
The INCLUDE statement works like an EXEC PROC statement to identify the PDS or PDSE member that contains JCL statements to be included in the jobstream.
The set of JCL statements in the PDS/PDSE member is referred to as an INCLUDE group.
INCLUDE Groups Versus Procedures
There are two main differences between INCLUDE groups and procedures:
1) INCLUDE groups are more flexible, since they can represent part of a procedure. They can also be used to invoke procedures.
2) The INCLUDE statement can be placed anywhere in the jobstream (the JCL statements in the INCLUDE group will be inserted at that point).
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD DSN=&&DDOUT,DISP=(,CATLG),UNIT=SYSDA
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD SYSOUT=A
*A JCL Example
Suppose you have a job to copy and print a data set. Here's part of the JCL.
Several JCL statements are repeated in the job, and in fact are commonly used in other jobs. Let's see how the INCLUDE statement can be used here.
*The INCLUDE Statement Format
The INCLUDE statement is used within a jobstream to identify the member that contains the JCL statements to be inserted at that location in the jobstream.
The general format of the INCLUDE statement is:
//name INCLUDE MEMBER=name comments
The name field is optional; if coded, it must conform to normal JCL naming rules.
*Processing the JCL
Let's see what happens when this JCL is processed in a job. When the JCL on the left is processed, the jobstream looks like the one on the right.
As you can see, the system has replaced the INCLUDE statement with the JCL statements referenced by the INCLUDE statement.
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD DSN=&&DDOUT,...
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD SYSOUT=A
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD DSN=&&DDOUT,...
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD SYSOUT=A
*Rules for Using INCLUDE and INCLUDE Groups
There are several rules governing the use of the INCLUDE statement and INCLUDE groups:
1) INCLUDE groups can be nested (up to 15 levels).
2) The INCLUDE statement should be positioned in the jobstream where you want the INCLUDE group to be inserted.
3) The PDS or PDSE that contains the INCLUDE group must be one of the following:
*Another Rule
5) INCLUDE groups cannot contain the following JCL statements:
Three JCL statements deal with procedures specifically. They are:
After completing this unit, you should be able to:
In JCL, a procedure is defined with a statement of the following form:
// PROC symbolic parameters comments
The name must:
*Comments about a Procedure
In JCL, a procedure is defined with a statement of the following form:
//name PROC symbolic parameters
The comments are used in the same way as in other JCL statements, to document the jobstream.
*The Symbolic Parameters of a Procedure
In JCL, a procedure is defined with a statement of the following form:
//name PROC comments
The symbolic parameters are explained in another course in this series. They provide an easy-to-use method of modifying statement parameters within the procedure.
*Coding a PROC Statement
On the next screen you will code part of a PROC statement.
Remember, to help your coding of JCL in this course, always start your statement in the first position of the input area provided.
Do not space the cursor over to the right before starting the JCL statement. If you do, your answer will be incorrect.
*Using the PROC Statement
The PROC statement is required for instream procedures, but is optional for cataloged procedures.
It is a wise practice to code the PROC statement in all procedures for documentation purposes.
Instream procedures also require a PEND statement.
*Ending a JCL Procedure
The end of a JCL procedure also has its own statement:
//name PEND
which you can think of as meaning
Procedure END.
* ***
The name is optional.
Note: The PEND statement is optional in a cataloged procedure.
//COMPILE PROC
:
:
:
: JCL Statements
:
:
:
// PEND
*An Instream Procedure
Here is what you need to define the COBOL compile steps as an instream procedure.
*Instream and Cataloged Procedures
The left shows what you need to define the COBOL compile steps as an instream procedure.
The JCL statements on the right may be stored in a library to define the COBOL compile step as a cataloged procedure.
//COMPILE PROC
:
:
:
: JCL Statements
:
:
:
// PEND
//COMPILE PROC
:
:
:
: JCL Statements
:
:
:
// PEND
PROC and PEND Statements
Answer the next two questions about the PROC and PEND statements before going on.
Consider both instream and cataloged procedures when giving your answer.
The next thing you need to know is how to call or execute the procedure once you have defined it.
The statement used to execute a procedure is an EXEC statement of the following form:
//name EXEC PROC=procname
OR
//name EXEC procname
*Naming the EXEC Statement
//name EXEC PROC=procname OR //name EXEC procname
The name is an optional step name that follows the usual naming conventions: alphanumeric or national, no more than eight characters, first letter alphabetic or national.
The procname is the name of the procedure you want to call. The first part of the parameter (PROC=) is optional.
.
. (JCL statements here)
.
//S1 or //S1
.
. (additional statements here)
*Calling a JCL Procedure
The three statements shown above summarize how to define and call a JCL procedure.
This unit discusses each rule for coding an instream procedure in detail.
After completing this unit, you should be able to:
//COMPILE PROC
//STEP1 EXEC PGM=IGYCRCTL
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
// PEND
//S1 EXEC COMPILE
*A Jobstream Example
This is the example jobstream you will see during the discussion of instream and cataloged coding rules. To save space, the seven SYSUT statements will often be indicated as shown above. Now on to a discussion of the rules for coding instream procedures.
*Rules For Coding an Instream JCL Procedure
1. Instream procedures must be defined after the JOB statement and before the first EXEC statement.
2. Each instream procedure must begin with a PROC statement and end with a PEND statement.
3. Up to 15 instream procedures can be defined within a single job.
4. Each instream procedure in the job must have a unique name.
5. Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
6. Instream procedures can invoke other procedures. On the other hand, instream procedures cannot be defined within other procedures. (You cannot have a PROC-PROC-PEND-PEND sequence.)
Now look at each rule in a little more detail.
*Rule One
Instream procedures must be defined after the JOB statement and before the first EXEC statement.
Instream procedures must be placed in the proper location to be recognized.
For example:
// JOB
// EXEC PGM=IEFBR14
//DD1 DD .....
// EXEC COMPILE
*Rule Two
The only way to distinguish an instream procedure from the rest of the JCL jobstream is with the PROC and PEND statements.
*Rule Three
Up to 15 instream procedures can be defined within a single job.
You may never need to define that many all at once, but you should know there is an upper limit.
If you need more than 15 instream procedures in a single job, they must be stored in procedure libraries.
*Rule Four
Each instream procedure in the job must have a unique name.
In other words, each PROC statement must have a name that isn't used by another PROC statement somewhere else in the job.
*Rule Five
Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
Let's break this rule into two components:
A: //SYSIN DD *, //SYSIN DD DATA, instream data statements
B: //, /*, JOBLIB, JES2, JES3 statements
*Rule Five — A
Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, or instream data statements.
This restriction is easily circumvented. The SYSIN JCL and data statements can be coded after the EXEC statement for the procedure.
For example, look at the COMPILE procedure.
*Accessing the Source Data
As originally coded (on the left), the procedure can access only MYPROG for the source data. But, what if you had instream data? The SYSIN DD statement cannot be part of the procedure.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
*Don't Include SYSIN DD in the Procedure
To accommodate this situation, leave the SYSIN DD statement out of the procedure.
Code it with its data statements following the EXEC statement.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
: (COBOL program here)
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
: (COBOL program here)
*More Options to Receive Data
Then you have the freedom to have the SYSIN data come from whatever source you wish: — instream data — an existing data set such as MYPROG.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
*Instream Data Makes It Easier
And, when you have instream data you can omit the SYSIN statement entirely! The system will automatically generate one for you and assume it precedes your program source statements.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
: (COBOL program here)
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
: (COBOL program here)
*Invalid and Incorrect Cases
Case 1 is invalid because the SYSIN DD does not follow the EXEC statement.
Case 2 is incorrect since the SYSIN is within the procedure.
*Correct Cases
Cases 3 and 4 have the SYSIN located after the EXEC statement. Case 4 shows it is valid to have the SYSIN follow the EXEC even though it doesn't use instream data.
*Omitting the SYSIN DD Statement
In fact...
The SYSIN DD statement is usually left out of the COMPILE procedure.
So, now that you know the why and how of it, let's leave the SYSIN DD out. From now on, you'll see the procedure without this DD statement.
Now look at the other component of rule 5, then move on to rule 6.
*Rule Five — B
Instream procedures cannot contain //, /*, JOBLIB, JES2 or JES3 statements.
//, /*
These two statements are unnecessary. Remember, instream data is not allowed!
JOBLIB, JES2, JES3
These statements are beyond the scope of this course. They are coded after the JOB statement. They can easily be coded in the job prior to the EXEC statement for the procedure.
*Rule Six
Instream procedures can invoke other procedures. On the other hand, instream procedures cannot be defined within other procedures.
Let's look at each of these statements separately.
*Rule Six — A
Instream procedures can invoke other procedures.
What this means is that you can put EXEC PROC statements in your instream procedures to call other procedures. As a matter of fact, JCL allows up to 15 levels of nesting.
Here's an example of a nested procedure:
//COMPILE PROC
:
// PEND
In this example, procedure COMPILE invokes procedure LINKIT.
Let's look at a more complex example.
*Invoking the SETUP Procedure
Assume you have the instream procedures on the right defined in a job.
Let's see what happens if the jobstream starts by invoking the SETUP procedure:
//CMPL JOB
//SETUP PROC
//S1 EXEC COMPILE
:
//S2 EXEC PGM=SET1
:
// PEND
//COMPILE PROC
//C1 EXEC LINKIT
:
// PEND
//LINKIT PROC
//L1 EXEC PGM=LNK4
:
// PEND
*Invoking the COMPILE Procedure
The first step of the SETUP procedure invokes the COMPILE procedure.
//CMPL JOB
//SETUP PROC
:
//S2 EXEC PGM=SET1
:
// PEND
//C1 EXEC LINKIT
:
// PEND
//LINKIT PROC
//L1 EXEC PGM=LNK4
:
// PEND
*Invoking the LINKIT Procedure
The COMPILE procedure invokes the LINKIT procedure, which executes the LNK4 program.
//CMPL JOB
// EXEC SETUP
//SETUP PROC
//S1 EXEC COMPILE
:
//S2 EXEC PGM=SET1
:
// PEND
:
// PEND
:
// PEND
*Processing Step 2 of the Procedure
At this point, the system goes back and processes the second step of the SETUP procedure, which executes the SET1 program.
Now answer some questions.
//SETUP PROC
//S1 EXEC COMPILE
:
:
// PEND
//COMPILE PROC
//C1 EXEC LINKIT
:
// PEND
//LINKIT PROC
//L1 EXEC PGM=LNK4
:
// PEND
*Rule Six - B
Let's look at the second part of the nesting rule.
Instream procedures cannot be defined within other procedures.
What this means is that you can't have a PROC-PROC-PEND-PEND sequence. Let's look at an example.
*Invalid Nesting
The following example represents invalid nesting:
//COMPILE PROC
:
:
:
// PEND
This JCL is invalid because the COMPILE procedure is attempting to define the LINKIT procedure.
The way to avoid this problem is to create the COMPILE and LINKIT procedures as two separate instream procedures. Then, if you want to invoke the LINKIT procedure from within the COMPILE procedure, you won't get a JCL error.
Nesting procedures can become very complex. Refer to your JCL manuals and installation guidelines for more information.
In this unit, you will
learn each rule for coding a cataloged procedure in detail.
The rules for coding a cataloged procedure are similar to those for instream procedures.
*Rules For Coding a Catalogued JCL Procedure
1. Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
2. Cataloged procedures should be given unique names.
3. The PROC statement is needed only if the procedure has symbolic parameters.
4. The PEND statement is optional.
5. Procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
6. Cataloged procedures can invoke other procedures.
The last two rules are the same as the last two rules for instream procedures.
*Rule One
Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
Procedure libraries may be partitioned data sets (PDS) or partitioned data sets extended (PDSEs).
These are large data sets that hold many members. Look at a picture of this concept.
*Member Name
Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
*Rule Two
Cataloged procedures should be given unique names.
Remember that instream procedures must have unique names within the job.
Since cataloged procedures are stored in libraries, the rule is not quite the same.
Let's see why.
*Naming Members and Procedures
Your installation may have many partitioned data sets that contain cataloged procedures. Each PDS or PDSE must have a unique name. The members within a PDS or PDSE must also have unique names.
But across PDSs or PDSEs the member names can be duplicated. So, technically you can have procedures with the same name in several of the procedure libraries!
This gets rather confusing for everyone involved.
Let's look at some questions commonly asked.
*How Is Each Procedure Found?
The system first searches for the procedure in your instream JCL. If the procedure is defined there, this version is executed.
Next, the system looks in any private libraries you've designated by using a JCLLIB statement earlier in the job. The first member found with a matching name is brought into your jobstream. We'll look at the JCLLIB statement in a moment.
Next, the system searches the list of procedure libraries for the name of the procedure invoked. The first member found with a matching name is brought into your jobstream.
If two procedures exist with the same name in two different procedure libraries, only the first one found is executed
*Can the Sequence Be Changed?
It is possible with JCL to point to a different list of procedure libraries -- one that has the libraries concatenated in the order desired. This is done with the PROCLIB parameter on the JES2 /*JOBPARM statement or the PROC parameter on the JES3 //*MAIN statement.
Refer to your JCL manuals for more information on these JES statements.
This is usually set up by your technical department.
*The JCLLIB Statement
Another way is to set up a library search order through the JCLLIB statement.
Let's briefly look at the JCLLIB statement.
*Formatting the JCLLIB Statement
The JCLLIB statement can be used to reference procedures and INCLUDE groups in private libraries.
The format of the JCLLIB statement is:
//name JCLLIB ORDER=(library,library...)
There are several coding rules:
*An Example
The JCLLIB statement can be used to reference procedures and INCLUDE groups in private libraries.
The format of the JCLLIB statement is:
//name JCLLIB ORDER=(library,library...)
For example:
//MS1 JCLLIB ORDER=MYPROC.JCL
tells the system to search the procedure library MYPROC.JCL before searching the system procedure library.
*Why Would You Want to Change the Library Search Sequence?
Some installations have a test procedure library where new and updated procedures are placed prior to going into production. Changing the search sequence permits access to the test procedure library before the production library.
*Why Would You Want to Change the Library Search Sequence?
Some installations have a test procedure library where new and updated procedures are placed prior to going into production. Changing the search sequence permits access to the test procedure library before the production library.
So for this course...
Be aware that it is possible to have cataloged procedures with the same name in different procedure libraries.
This is dependent on your installation and thus will not be discussed further.
*Rule Three
The PROC statement is needed only if the procedure has symbolic parameters.
If symbolic parameters are not used the PROC statement is optional. It is a common practice to include the PROC statement in cataloged procedures for documentation purposes.
Note: The name on the PROC statement does not have to be the same as the member name. It can be anything or no name at all!
*Rule Four
The PEND statement is optional.
PEND statements are optional in cataloged procedures. As with the PROC statement, the PEND statement may be useful for documentation purposes.
Refer to your installation guidelines for more information.
*Accessing the Procedure Library
You are probably saying to yourself now:
"Yes, I know all the rules for coding a cataloged procedure but how do I get it in a procedure library?"
Well, the answer to that is with a utility program such as IEBUPDTE.
//UPDT JOB ....
//S1 EXEC PGM=IEBUPDTE,PARM=NEW
//SYSUT1 DD DSN=SYS1.PROCLIB,DISP=OLD
//SYSUT2 DD DSN=SYS1.PROCLIB,DISP=OLD
//SYSPRINT DD SYSOUT=A
//SYSIN DD DATA
./ ADD NAME=COMPILE,LIST=ALL,LEVEL=01
./ NUMBER NEW1=10,INCR=10
:
: procedure JCL
./ ENDUP
*The JCL for Accessing the Procedure Library
A complete explanation of the utility is beyond the scope of this course. But here is a quick review of the JCL needed.
//UPDT JOB ....
//S1 EXEC PGM=IEBUPDTE,PARM=NEW
//SYSUT1 DD DSN=SYS1.PROCLIB,DISP
//SYSUT2 DD DSN=SYS1.PROCLIB,DISP
//SYSPRINT DD SYSOUT=A
//SYSIN DD DATA
./ ADD NAME=COMPILE,LIST=ALL,LEVEL=
./ NUMBER NEW1=10,INCR=10
:
: procedure JCL
./ ENDUP
*Key Elements of IEBUPDTE Utility
Here you see the key elements of the IEBUPDTE utility.
*Using Conventions and Guidelines
Now, one other word of advice about cataloged procedures.
Cataloged procedures are stored in libraries that are shared by many users. Therefore, you must follow the naming, storing and accessing conventions set up at your installation.
Refer to your installation guidelines for the names and libraries you should use before storing your procedures.
*Procedures Available to the Public
You see now that as long as you used instream procedures you could use any name you liked. The moment you decide to make your procedure available to the public you must follow naming conventions and procedure library guidelines.
1. Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
2. Cataloged procedures should be given unique names.
3. The PROC statement is needed only if the procedure has symbolic parameters.
4. The PEND statement is optional.
5. Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
6. Cataloged procedures can invoke other procedures.
In this unit, you will learn the resources necessary to compile a COBOL program. You will also learn to code a complete JCL jobstream to compile a COBOL program.
After completing this unit, you should be able to:
- Identify the resources needed to compile a COBOL program
- Recall JCL statements studied earlier
Topic 1.1: Defining the Job
*Performing a Task RepeatedlyMost JCL procedures are a result of the need to perform a task repeatedly.
One such need is compiling a program.
Throughout this course, the base example is the JCL required to compile and create an executable module for a COBOL program. It will show you how procedures work.
*Compiling the COBOL Program
The remainder of this unit addresses the resources needed by the COBOL compiler.
A sample jobstream with the necessary JCL statements and parameters is displayed.
Note: Throughout this course, examples will use data sets that are not managed by SMS. If you use SMS, your JCL may be slightly different.
*Necessary Resources for Compiling
Compiling your COBOL program will use or create the following:
1. Source Program
2. COBOL Compiler
3. Object Module
4. Work Files
5. Printed Listing
Following is an explanation of each item.
*Explaining the Necessary Pieces
1. Source program — COBOL is a high-level computer language that uses words and phrases similar to English.
2. COBOL compiler — The compiler translates the COBOL program's words and phrases into machine code — a language the computer understands.
3. Object module — The machine code version of the program is called an object module. This is usually stored on disk.
*The Work Files and Printed Listing
4. Work files — The compiler requires extra space to work in while it's translating from source to object.
5. Printed listing — The source program and any messages from the compilation are printed.
//CMPL JOB (9797,DEPTK),G.SAMSA,TIME=1
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*A Complete JCL Jobstream
Here is a very simple version of the complete JCL jobstream needed to compile a COBOL program.
The JCL at your installation is coded in more detail to reflect your standards.
//CMPL JOB (9797,DEPTK),G.SAMSA,TIME=1
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*A Simple Example
This JCL uses very basic settings. The jobstream will change and expand as you work with this procedure and set it up for more general applications.
Above, some parameters such as the SYSLIN DCB are omitted. Their default values are used instead. This keeps the procedure simple and easy to read.
//CMPL JOB (9797,DEPTK),G.SAMSA,TIME=1
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,S
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*Meeting the COBOL Compiler Requirements
Here is how this JCL reflects the COBOL compiler requirements.
In the next section, you will have a chance
- To review in detail what each statement means
- To go on with the discussion of procedures
Topic 1.2: Review of JCL Statements
*Examining the Jobstream in DetailIn the first section of this unit, you looked at what was involved in compiling a COBOL program. You also got a quick look at the complete JCL jobstream used to accomplish this task.
This section offers you a chance to look at the jobstream in detail.
Or, if you prefer, you can just look at a quick review of the JCL, and then get on with the discussion of JCL procedures.
*The Necessary Resources
You know from the previous section that compiling a COBOL program uses or creates these resources:
| Resource |
|---|
| 1. Source program |
| 2. COBOL compiler |
| 3. Object module |
| 4. Work files |
| 5. Printed listing |
*Another Name for the COBOL Compiler
The COBOL compiler is really just another program with the name IGYCRCTL:
| Resource | Name |
|---|---|
| 1. Source program | |
| 2. COBOL compiler | IGYCRCTL |
| 3. Object module | |
| 4. Work files | |
| 5. Printed listing |
*Naming the Source Program and Object Module
In this example, both the source program and the object module are stored in disk files with the names MYPROG and MYOBJECT:
| Resource | Name |
|---|---|
| 1. Source program | MYPROG |
| 2. COBOL compiler | IGYCRCTL |
| 3. Object module | MYOBJECT |
| 4. Work files | |
| 5. Printed listing |
*JCL Statement Stubs for Compiling
Here are the JCL statement stubs that are coded to compile the COBOL program.
| Resource | Name | JCL Statement |
|---|---|---|
| 1. Source program | MYPROG | //SYSIN DD |
| 2. COBOL compiler | IGYCRCTL | //STEP1 EXEC |
| 3. Object module | MYOBJECT | //SYSLIN DD |
| 4. Work files | //SYSUT1 DD : //SYSUT7 DD | |
| 5. Printed listing | //SYSPRINT DD |
*Reviewing the JCL Statements
Now that you know what is involved in compiling a COBOL program, it's time to write the JCL statements that will allow you to do so.
But you already know how to do that, don't you?
So let's review each statement. You can help complete some of them, and answer questions as you go. ...
You know from previous experience that JCL must be coded carefully and correctly. The operating system cannot guess what you mean — you must code precisely what you want.
To help your coding of JCL in this course, always start your statement in the first position of the input area provided. Do not space the cursor over to the right before starting the JCL statement. If you do, your answer will be incorrect.
*The Job Statement
Here's the job statement you'll use. Notice that this job is charged to account number 9797, department K. The programmer's name is G. Samsa.
//CMPL JOB (9797,DEPTK),G.SAMSA
*The EXEC Statement
The next line in the jobstream is the EXEC statement.
The purpose of this statement is to define the program to be executed, in this case the COBOL compiler. This EXEC statement defines a job step. The name of the EXEC statement is the JOB STEP name.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
*The Work Files
Now all seven work files are set up.
Although they are listed above in numerical order for convenience, please note that you can establish the work files in any order.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD
//SYSUT2 DD
:
//SYSUT7 DD
*Examining the Parameters
Before going on to the next statement in the sequence:
- Review what some of the parameters in these DD statements mean, and
- Look at the default values assigned for other parameters
*Choosing a DASD Volume
//SYSUT1 DD ,SPACE=(CYL,(1,1)
Choose any DASD volume from the group of volumes labeled SYSDA.
*Setting Up a Storage Space
//SYSUT1 DD UNIT=SYSDA,
Set up primary and from the group of secondary storage spaces volumes labeled SYSDA of 1 cylinder each.
*Default Values for Parameters
Note the default values for parameters not listed. In the example data definition statement...
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
...no data set name, disposition or data control block is specified.
Therefore, the system automatically assigns the following values:
| PARAMETER | CODE | DEFAULT VALUE |
|---|---|---|
| data set name | DSN= | temporary system-assigned name |
| data set disposition | DISP= | DISP=(NEW,DELETE) |
| data control block | DCB= | none |
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
*The SYSPRINT DD Statement
This SYSPRINT DD statement sends the printed listing to output Class A. No special forms are requested.
For this particular example, a SYSOUT code of A prints your listing on regular paper at the standard output class.
This code is installation specific, so check for the ones that are used at your location.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
*The Data Definition Statement
Next, a DD statement with the data definition name of SYSLIN tells the compiler where to put the object module.
Here's a detailed explanation of this statement.
*Explaining the DD Statement
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
- SYSLIN — The compiler expects a DD statement named
SYSLIN to tell it where to store the object file.
- MYOBJECT — The name you choose for your object module.
- UNIT and SPACE — Requests one cylinder of primary disk
space on the group of disks named SYSDA.
- DISP — A new data set kept for later use.
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
*A DD Statement for the Source Code Location
You also need a DD statement that tells the compiler where to find the source code.
The last line in the jobstream above assumes that your source program resides in a data set called MYPROG.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*JCL Is Simple for Compilation of COBOL Program
As you can see, the JCL needed to compile a COBOL program is fairly simple:
1. It involves only one JOB step.
2. You always use the same statements.
3. There are only minor variations.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
*Advantage of the JCL Procedure
By using a JCL procedure, you won't have to code the same JCL every time you want to compile your program.
Topic 1.3: Unit 1 Summary
In this unit, you learned the following:- Most JCL procedures are a result of the need to perform a task repeatedly.
One such need is compiling a program.
- Compiling your COBOL program, will use or create the following: source
program, COBOL compiler, object module, work files, and printed
listing.
- The purpose of the EXEC statement is to define the program to be
executed, in this case the COBOL compiler.
- The compiler expects the work files to be defined using DD names
SYSUT1 through SYSUT7.
- The SYSPRINT DD statement sends the printed listing to
output Class A. No special forms are requested.
- A DD statement with the data definition name of SYSLIN
tells the compiler where to put the object module.
- You also need a DD statement — SYSIN — that tells the compiler where to find the source code.
Unit 2. Types of JCL Procedures
In this unit, you will
learn the ways to minimize redundant JCL: procedures and INCLUDE
groups. You will learn to distinguish two types of JCL procedures. You will also
learn how to use INCLUDE statements and INCLUDE groups.
After completing this unit, you should be able to:
- Identify types of JCL procedures
- Distinguish between instream and cataloged procedures
- Use INCLUDE statements and groups in a jobstream
Topic 2.1: Types of Procedures
*The JCL Doesn't Change MuchIn the last unit, you saw that the JCL needed to compile a COBOL program was a fairly simple jobstream of one step.
It was also decided that the JCL wouldn't change much from time to time.
*Minimizing Redundant JCL
As you may recall from the JCL: Fundamentals course, there are two ways to minimize redundant JCL:
1) Using procedures
2) Using INCLUDE groups
*Types of JCL Procedures
There are two types of JCL procedures:
- INSTREAM
- CATALOGED
Topic 2.2: Instream Procedures
*Defining Instream ProceduresInstream procedures are:
- Defined in your JCL jobstream along with the other JCL statements
- Not stored in a library for general use
- Available only to the job where defined and only for the duration of the
job
- Executed with an EXEC statement
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
// EXEC COMPILE
*An Instream Procedure Example
Here is the JCL example for compiling a COBOL program written as an instream procedure.
//CMPL JOB (9797,DEPTK),G.SAMSA
//STEP1 EXEC PGM=IGYCRCTL
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
:
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
// EXEC COMPILE
*The New Statements
As you can see there are only two new statements added. You'll learn about these in the next unit. For now, let's see how this is executed.
*Executing JCL Statement in an Instream Procedure
JCL statements within an instream procedure are executed only when the procedure is executed.
//BKUP PROC
: These JCL statements aren't executed until
// PEND
// EXEC BKUP the procedure is called and executed with this
EXEC statement.
Topic 2.3: Cataloged Procedures
*Defining Cataloged ProceduresCataloged procedures are:
- Stored in a library by member name
- Available for general use by any job accessing the procedure library in
which the procedure is stored
- Executed with an EXEC statement
*JCL Coding for a Cataloged Procedure
Here's how to compile the example COBOL program when you've written the JCL as a cataloged procedure:
//CMPL JOB (9797,DEPTK),G.SAMSA
As you can see, once you get the procedure stored in a library it really simplifies your JCL coding.
All the JCL statements in the procedure are stored in the library. When the procedure is called, the statements are retrieved and executed
*Instream Versus Cataloged Procedures
Instream procedures are more limited in use than cataloged procedures.
They are, however, an excellent vehicle for testing and special purpose jobs.
Topic 2.4: INCLUDE Statements and INCLUDE Groups
*The JCL INCLUDE StatementThe JCL INCLUDE statement is similar to the INCLUDE (or COPY) statement/command found in many programming languages. It provides an easy way to include frequently used JCL statements in your jobstream. It may also be used as an alternative to some procedures, depending on your installation standards and personal preference.
The INCLUDE statement works like an EXEC PROC statement to identify the PDS or PDSE member that contains JCL statements to be included in the jobstream.
The set of JCL statements in the PDS/PDSE member is referred to as an INCLUDE group.
INCLUDE Groups Versus Procedures
There are two main differences between INCLUDE groups and procedures:
1) INCLUDE groups are more flexible, since they can represent part of a procedure. They can also be used to invoke procedures.
2) The INCLUDE statement can be placed anywhere in the jobstream (the JCL statements in the INCLUDE group will be inserted at that point).
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD DSN=&&DDOUT,DISP=(,CATLG),UNIT=SYSDA
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD SYSOUT=A
*A JCL Example
Suppose you have a job to copy and print a data set. Here's part of the JCL.
Several JCL statements are repeated in the job, and in fact are commonly used in other jobs. Let's see how the INCLUDE statement can be used here.
*The INCLUDE Statement Format
The INCLUDE statement is used within a jobstream to identify the member that contains the JCL statements to be inserted at that location in the jobstream.
The general format of the INCLUDE statement is:
//name INCLUDE MEMBER=name comments
The name field is optional; if coded, it must conform to normal JCL naming rules.
*Processing the JCL
Let's see what happens when this JCL is processed in a job. When the JCL on the left is processed, the jobstream looks like the one on the right.
As you can see, the system has replaced the INCLUDE statement with the JCL statements referenced by the INCLUDE statement.
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD DSN=&&DDOUT,...
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD SYSOUT=A
//STEP1 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD DSN=&&DDOUT,...
//STEP2 EXEC PGM=IEBGENER
//SYSUT1 DD DSN=&&DDIN,DISP=OLD
//SYSUT2 DD SYSOUT=A
*Rules for Using INCLUDE and INCLUDE Groups
There are several rules governing the use of the INCLUDE statement and INCLUDE groups:
1) INCLUDE groups can be nested (up to 15 levels).
2) The INCLUDE statement should be positioned in the jobstream where you want the INCLUDE group to be inserted.
3) The PDS or PDSE that contains the INCLUDE group must be one of the following:
- A system procedure library
- An installation-defined procedure library
- A private library
*Another Rule
5) INCLUDE groups cannot contain the following JCL statements:
- JOB statements
- JCLLIB statements
- JES control statements
- PROC and PEND statements (but you can invoke a procedure from within an INCLUDE group)
- CNTL statements
- DD
- And DD DATA statements
Topic 2.5: Unit 2 Summary
In this unit, you learned the following:- Instream procedures are: defined in your JCL jobstream along with the other JCL statements; not stored in a library for general use; available only to the job where defined and only for the duration of the job; and executed with an EXEC statement
- Cataloged procedures are: stored in a library by member name; available for general use by any job accessing the procedure library in which the procedure is stored; and executed with an EXEC statement.
- The INCLUDE statement works like an EXEC PROC statement to identify the PDS or PDSE member that contains JCL statements to be included in the jobstream.
- The set of JCL statements in the PDS/PDSE member is referred to as an INCLUDE group.
- The general format of the INCLUDE statement
is:
Unit 3. The PROC, PEND, EXEC Statements
Three JCL statements deal with procedures specifically. They are:
- PROC
- PEND
- EXEC
After completing this unit, you should be able to:
- Code a PROC statement
- Use a PEND statement to end a JCL procedure
- Execute and call a defined procedure using the EXEC statement
Topic 3.1: The PROC Statement
*The Name of a ProcedureIn JCL, a procedure is defined with a statement of the following form:
// PROC symbolic parameters comments
The name must:
- Be alphanumeric or national
- Have no more than eight characters
- Start with an alphabetic or national character
*Comments about a Procedure
In JCL, a procedure is defined with a statement of the following form:
//name PROC symbolic parameters
The comments are used in the same way as in other JCL statements, to document the jobstream.
*The Symbolic Parameters of a Procedure
In JCL, a procedure is defined with a statement of the following form:
//name PROC comments
The symbolic parameters are explained in another course in this series. They provide an easy-to-use method of modifying statement parameters within the procedure.
*Coding a PROC Statement
On the next screen you will code part of a PROC statement.
Remember, to help your coding of JCL in this course, always start your statement in the first position of the input area provided.
Do not space the cursor over to the right before starting the JCL statement. If you do, your answer will be incorrect.
*Using the PROC Statement
The PROC statement is required for instream procedures, but is optional for cataloged procedures.
It is a wise practice to code the PROC statement in all procedures for documentation purposes.
Topic 3.2: The PEND Statement
*The PEND StatementInstream procedures also require a PEND statement.
*Ending a JCL Procedure
The end of a JCL procedure also has its own statement:
//name PEND
which you can think of as meaning
Procedure END.
* ***
The name is optional.
Note: The PEND statement is optional in a cataloged procedure.
//COMPILE PROC
:
:
:
: JCL Statements
:
:
:
// PEND
*An Instream Procedure
Here is what you need to define the COBOL compile steps as an instream procedure.
*Instream and Cataloged Procedures
The left shows what you need to define the COBOL compile steps as an instream procedure.
The JCL statements on the right may be stored in a library to define the COBOL compile step as a cataloged procedure.
//COMPILE PROC
:
:
:
: JCL Statements
:
:
:
// PEND
//COMPILE PROC
:
:
:
: JCL Statements
:
:
:
// PEND
PROC and PEND Statements
Answer the next two questions about the PROC and PEND statements before going on.
Consider both instream and cataloged procedures when giving your answer.
Topic 3.3: The EXEC Statement
*Executing a ProcedureThe next thing you need to know is how to call or execute the procedure once you have defined it.
The statement used to execute a procedure is an EXEC statement of the following form:
//name EXEC PROC=procname
OR
//name EXEC procname
*Naming the EXEC Statement
//name EXEC PROC=procname OR //name EXEC procname
The name is an optional step name that follows the usual naming conventions: alphanumeric or national, no more than eight characters, first letter alphabetic or national.
The procname is the name of the procedure you want to call. The first part of the parameter (PROC=) is optional.
.
. (JCL statements here)
.
//S1 or //S1
.
. (additional statements here)
*Calling a JCL Procedure
The three statements shown above summarize how to define and call a JCL procedure.
Topic 3.4: Unit 3 Summary
In this unit, you learned the following:- In JCL, a procedure is defined with a statement of the following
form:
//name PROC symbolic parameters comments
- The end of a JCL procedure also has its own
statement:
//name PEND
- The statement used to execute a procedure is an EXEC statement of the following form
Unit 4. Instream Procedure Rules
Procedures must follow the same guidelines as any JCL job. There are, however, some special rules to keep in mind when coding an instream procedure.This unit discusses each rule for coding an instream procedure in detail.
After completing this unit, you should be able to:
- Recall and apply the rules for coding an instream procedure
Topic 4.1: Rules for Coding Instream Procedures
//CMPL JOB (9797,DEPTK),G.SAMSA//COMPILE PROC
//STEP1 EXEC PGM=IGYCRCTL
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSN=MYOBJECT,UNIT=SYSDA,SPACE=(CYL,1),DISP=(NEW,KEEP)
//SYSIN DD DSN=MYPROG,DISP=(OLD,KEEP)
// PEND
//S1 EXEC COMPILE
*A Jobstream Example
This is the example jobstream you will see during the discussion of instream and cataloged coding rules. To save space, the seven SYSUT statements will often be indicated as shown above. Now on to a discussion of the rules for coding instream procedures.
*Rules For Coding an Instream JCL Procedure
1. Instream procedures must be defined after the JOB statement and before the first EXEC statement.
2. Each instream procedure must begin with a PROC statement and end with a PEND statement.
3. Up to 15 instream procedures can be defined within a single job.
4. Each instream procedure in the job must have a unique name.
5. Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
6. Instream procedures can invoke other procedures. On the other hand, instream procedures cannot be defined within other procedures. (You cannot have a PROC-PROC-PEND-PEND sequence.)
Now look at each rule in a little more detail.
*Rule One
Instream procedures must be defined after the JOB statement and before the first EXEC statement.
Instream procedures must be placed in the proper location to be recognized.
For example:
// JOB
// EXEC PGM=IEFBR14
//DD1 DD .....
// EXEC COMPILE
*Rule Two
The only way to distinguish an instream procedure from the rest of the JCL jobstream is with the PROC and PEND statements.
*Rule Three
Up to 15 instream procedures can be defined within a single job.
You may never need to define that many all at once, but you should know there is an upper limit.
If you need more than 15 instream procedures in a single job, they must be stored in procedure libraries.
*Rule Four
Each instream procedure in the job must have a unique name.
In other words, each PROC statement must have a name that isn't used by another PROC statement somewhere else in the job.
*Rule Five
Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
Let's break this rule into two components:
A: //SYSIN DD *, //SYSIN DD DATA, instream data statements
B: //, /*, JOBLIB, JES2, JES3 statements
*Rule Five — A
Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, or instream data statements.
This restriction is easily circumvented. The SYSIN JCL and data statements can be coded after the EXEC statement for the procedure.
For example, look at the COMPILE procedure.
*Accessing the Source Data
As originally coded (on the left), the procedure can access only MYPROG for the source data. But, what if you had instream data? The SYSIN DD statement cannot be part of the procedure.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
*Don't Include SYSIN DD in the Procedure
To accommodate this situation, leave the SYSIN DD statement out of the procedure.
Code it with its data statements following the EXEC statement.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
: (COBOL program here)
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
: (COBOL program here)
*More Options to Receive Data
Then you have the freedom to have the SYSIN data come from whatever source you wish: — instream data — an existing data set such as MYPROG.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
//S1 EXEC COMPILE
*Instream Data Makes It Easier
And, when you have instream data you can omit the SYSIN statement entirely! The system will automatically generate one for you and assume it precedes your program source statements.
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
: (COBOL program here)
//CMPL JOB ...
//COMPILE PROC
//STEP1 EXEC ...
//SYSUT1 DD ...
:
//SYSUT7 DD ...
//SYSPRINT DD ...
//SYSLIN DD ...
// PEND
// EXEC COMPILE
: (COBOL program here)
| Case
1 //COMPILE PROC : // PEND //SYSIN DD * : instream data |
Case 2
//COMPILE PROC : //SYSIN DD * : instream data // EXEC COMPILE |
*Invalid and Incorrect Cases
Case 1 is invalid because the SYSIN DD does not follow the EXEC statement.
Case 2 is incorrect since the SYSIN is within the procedure.
| Case
3 //COMPILE PROC : // PEND // EXEC COMPILE : instream data |
Case
4 //COMPILE PROC : // PEND // EXEC COMPILE |
*Correct Cases
Cases 3 and 4 have the SYSIN located after the EXEC statement. Case 4 shows it is valid to have the SYSIN follow the EXEC even though it doesn't use instream data.
*Omitting the SYSIN DD Statement
In fact...
The SYSIN DD statement is usually left out of the COMPILE procedure.
So, now that you know the why and how of it, let's leave the SYSIN DD out. From now on, you'll see the procedure without this DD statement.
Now look at the other component of rule 5, then move on to rule 6.
*Rule Five — B
Instream procedures cannot contain //, /*, JOBLIB, JES2 or JES3 statements.
//, /*
These two statements are unnecessary. Remember, instream data is not allowed!
JOBLIB, JES2, JES3
These statements are beyond the scope of this course. They are coded after the JOB statement. They can easily be coded in the job prior to the EXEC statement for the procedure.
*Rule Six
Instream procedures can invoke other procedures. On the other hand, instream procedures cannot be defined within other procedures.
Let's look at each of these statements separately.
*Rule Six — A
Instream procedures can invoke other procedures.
What this means is that you can put EXEC PROC statements in your instream procedures to call other procedures. As a matter of fact, JCL allows up to 15 levels of nesting.
Here's an example of a nested procedure:
//COMPILE PROC
:
// PEND
In this example, procedure COMPILE invokes procedure LINKIT.
Let's look at a more complex example.
*Invoking the SETUP Procedure
Assume you have the instream procedures on the right defined in a job.
Let's see what happens if the jobstream starts by invoking the SETUP procedure:
//CMPL JOB
//SETUP PROC
//S1 EXEC COMPILE
:
//S2 EXEC PGM=SET1
:
// PEND
//COMPILE PROC
//C1 EXEC LINKIT
:
// PEND
//LINKIT PROC
//L1 EXEC PGM=LNK4
:
// PEND
*Invoking the COMPILE Procedure
The first step of the SETUP procedure invokes the COMPILE procedure.
//CMPL JOB
//SETUP PROC
:
//S2 EXEC PGM=SET1
:
// PEND
//C1 EXEC LINKIT
:
// PEND
//LINKIT PROC
//L1 EXEC PGM=LNK4
:
// PEND
*Invoking the LINKIT Procedure
The COMPILE procedure invokes the LINKIT procedure, which executes the LNK4 program.
//CMPL JOB
// EXEC SETUP
//SETUP PROC
//S1 EXEC COMPILE
:
//S2 EXEC PGM=SET1
:
// PEND
:
// PEND
:
// PEND
*Processing Step 2 of the Procedure
At this point, the system goes back and processes the second step of the SETUP procedure, which executes the SET1 program.
Now answer some questions.
//SETUP PROC
//S1 EXEC COMPILE
:
:
// PEND
//COMPILE PROC
//C1 EXEC LINKIT
:
// PEND
//LINKIT PROC
//L1 EXEC PGM=LNK4
:
// PEND
*Rule Six - B
Let's look at the second part of the nesting rule.
Instream procedures cannot be defined within other procedures.
What this means is that you can't have a PROC-PROC-PEND-PEND sequence. Let's look at an example.
*Invalid Nesting
The following example represents invalid nesting:
//COMPILE PROC
:
:
:
// PEND
This JCL is invalid because the COMPILE procedure is attempting to define the LINKIT procedure.
The way to avoid this problem is to create the COMPILE and LINKIT procedures as two separate instream procedures. Then, if you want to invoke the LINKIT procedure from within the COMPILE procedure, you won't get a JCL error.
Nesting procedures can become very complex. Refer to your JCL manuals and installation guidelines for more information.
Topic 4.2: Unit 4 Summary
In this unit, you learned the following:- Instream procedures must be defined after the JOB statement and
before the first EXEC statement.
- Each instream procedure must begin with a PROC statement and end
with a PEND statement.
- Up to 15 instream procedures can be defined within a single job.
- Each instream procedure in the job must have a unique name.
- Instream procedures cannot contain //SYSIN DD *, //SYSIN DD
DATA, //, /*, instream data, JOBLIB, JES2, or
JES3 statements.
- Instream procedures can invoke other procedures. On the other hand, instream procedures cannot be defined within other procedures. (You cannot have a PROC-PROC-PEND-PEND sequence.)
Unit 5. Cataloged Procedure Rules
In this unit, you will
learn each rule for coding a cataloged procedure in detail.
After completing this unit, you should be able to:
- Recall the rules for coding a cataloged procedure
- Apply the rules when coding a cataloged procedure
Topic 5.1: Rules for Coding a Cataloged Procedure
*Coding a Cataloged ProcedureThe rules for coding a cataloged procedure are similar to those for instream procedures.
*Rules For Coding a Catalogued JCL Procedure
1. Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
2. Cataloged procedures should be given unique names.
3. The PROC statement is needed only if the procedure has symbolic parameters.
4. The PEND statement is optional.
5. Procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
6. Cataloged procedures can invoke other procedures.
The last two rules are the same as the last two rules for instream procedures.
*Rule One
Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
Procedure libraries may be partitioned data sets (PDS) or partitioned data sets extended (PDSEs).
These are large data sets that hold many members. Look at a picture of this concept.
*Member Name
Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
*Rule Two
Cataloged procedures should be given unique names.
Remember that instream procedures must have unique names within the job.
Since cataloged procedures are stored in libraries, the rule is not quite the same.
Let's see why.
*Naming Members and Procedures
Your installation may have many partitioned data sets that contain cataloged procedures. Each PDS or PDSE must have a unique name. The members within a PDS or PDSE must also have unique names.
But across PDSs or PDSEs the member names can be duplicated. So, technically you can have procedures with the same name in several of the procedure libraries!
This gets rather confusing for everyone involved.
Let's look at some questions commonly asked.
*How Is Each Procedure Found?
The system first searches for the procedure in your instream JCL. If the procedure is defined there, this version is executed.
Next, the system looks in any private libraries you've designated by using a JCLLIB statement earlier in the job. The first member found with a matching name is brought into your jobstream. We'll look at the JCLLIB statement in a moment.
Next, the system searches the list of procedure libraries for the name of the procedure invoked. The first member found with a matching name is brought into your jobstream.
If two procedures exist with the same name in two different procedure libraries, only the first one found is executed
*Can the Sequence Be Changed?
It is possible with JCL to point to a different list of procedure libraries -- one that has the libraries concatenated in the order desired. This is done with the PROCLIB parameter on the JES2 /*JOBPARM statement or the PROC parameter on the JES3 //*MAIN statement.
Refer to your JCL manuals for more information on these JES statements.
This is usually set up by your technical department.
*The JCLLIB Statement
Another way is to set up a library search order through the JCLLIB statement.
Let's briefly look at the JCLLIB statement.
*Formatting the JCLLIB Statement
The JCLLIB statement can be used to reference procedures and INCLUDE groups in private libraries.
The format of the JCLLIB statement is:
//name JCLLIB ORDER=(library,library...)
There are several coding rules:
- The name is optional.
- Library names can be enclosed in apostrophes.
- If only one library is listed, the parentheses are optional.
- You may have only one JCLLIB statement per job.
- The JCLLIB statement must precede the first EXEC statement.
*An Example
The JCLLIB statement can be used to reference procedures and INCLUDE groups in private libraries.
The format of the JCLLIB statement is:
//name JCLLIB ORDER=(library,library...)
For example:
//MS1 JCLLIB ORDER=MYPROC.JCL
tells the system to search the procedure library MYPROC.JCL before searching the system procedure library.
*Why Would You Want to Change the Library Search Sequence?
Some installations have a test procedure library where new and updated procedures are placed prior to going into production. Changing the search sequence permits access to the test procedure library before the production library.
*Why Would You Want to Change the Library Search Sequence?
Some installations have a test procedure library where new and updated procedures are placed prior to going into production. Changing the search sequence permits access to the test procedure library before the production library.
So for this course...
Be aware that it is possible to have cataloged procedures with the same name in different procedure libraries.
This is dependent on your installation and thus will not be discussed further.
*Rule Three
The PROC statement is needed only if the procedure has symbolic parameters.
If symbolic parameters are not used the PROC statement is optional. It is a common practice to include the PROC statement in cataloged procedures for documentation purposes.
Note: The name on the PROC statement does not have to be the same as the member name. It can be anything or no name at all!
*Rule Four
The PEND statement is optional.
PEND statements are optional in cataloged procedures. As with the PROC statement, the PEND statement may be useful for documentation purposes.
Refer to your installation guidelines for more information.
*Accessing the Procedure Library
You are probably saying to yourself now:
"Yes, I know all the rules for coding a cataloged procedure but how do I get it in a procedure library?"
Well, the answer to that is with a utility program such as IEBUPDTE.
//UPDT JOB ....
//S1 EXEC PGM=IEBUPDTE,PARM=NEW
//SYSUT1 DD DSN=SYS1.PROCLIB,DISP=OLD
//SYSUT2 DD DSN=SYS1.PROCLIB,DISP=OLD
//SYSPRINT DD SYSOUT=A
//SYSIN DD DATA
./ ADD NAME=COMPILE,LIST=ALL,LEVEL=01
./ NUMBER NEW1=10,INCR=10
:
: procedure JCL
./ ENDUP
*The JCL for Accessing the Procedure Library
A complete explanation of the utility is beyond the scope of this course. But here is a quick review of the JCL needed.
//UPDT JOB ....
//S1 EXEC PGM=IEBUPDTE,PARM=NEW
//SYSUT1 DD DSN=SYS1.PROCLIB,DISP
//SYSUT2 DD DSN=SYS1.PROCLIB,DISP
//SYSPRINT DD SYSOUT=A
//SYSIN DD DATA
./ ADD NAME=COMPILE,LIST=ALL,LEVEL=
./ NUMBER NEW1=10,INCR=10
:
: procedure JCL
./ ENDUP
*Key Elements of IEBUPDTE Utility
Here you see the key elements of the IEBUPDTE utility.
*Using Conventions and Guidelines
Now, one other word of advice about cataloged procedures.
Cataloged procedures are stored in libraries that are shared by many users. Therefore, you must follow the naming, storing and accessing conventions set up at your installation.
Refer to your installation guidelines for the names and libraries you should use before storing your procedures.
*Procedures Available to the Public
You see now that as long as you used instream procedures you could use any name you liked. The moment you decide to make your procedure available to the public you must follow naming conventions and procedure library guidelines.
Topic 5.2: Unit 5 Summary
In this unit, you learned the following:1. Cataloged procedures are stored in procedure libraries by member name. The member name is also the procname.
2. Cataloged procedures should be given unique names.
3. The PROC statement is needed only if the procedure has symbolic parameters.
4. The PEND statement is optional.
5. Instream procedures cannot contain //SYSIN DD *, //SYSIN DD DATA, //, /*, instream data, JOBLIB, JES2, or JES3 statements.
6. Cataloged procedures can invoke other procedures.
No comments:
Post a Comment