JCL: Fundamentals of Jobstreams: Text-only Version

JCL: Fundamentals of Jobstreams

Unit 1. JCL Overview

[Skip Unit 1's navigation links]
1. JCL Overview
       1.1 What Is JCL?
       1.2 Introduction to Jobstreams
       1.3 Statement Format
       1.4 JCL vs. Programs
       1.5 Unit 1 Summary

This course introduces IBM's Job Control Language, commonly referred to as JCL. If you are a new user, JCL probably looks very complex. In fact, writing your program may look simple next to coding the JCL needed to run your job.
Well, worry no more. This course will end the mystery of coding JCL. It presents the concepts, coding rules and statements you need to run your programs.
This unit is a basic introduction to JCL. You'll learn what statements do and how they are coded. You'll look at the general structure of a JCL statement. The unit also describes JCL's relationship to the operating system and contrasts JCL to application programs.

After completing this unit, you should be able to:

Define basic terminology
Explain the construction of a typical jobstream
Describe the format of a JCL statement
Distinguish between the functions of JCL and programs

Topic 1.1: What Is JCL?

*The Language of Work
Whether you are a programmer, operator, manager, or end user, Job Control Language, called JCL, is the language that you need to do your work on the computer.
By submitting a job or requesting that one be submitted for processing, you are requesting work from the operating system. You must state who you are, what you want, who to charge it to, and so on.
You do this with JCL.
Let's start now by defining basic terms.

*Jobs and Jobstreams
A job is a unit of work performed by the computer system. Typically, a job is a specific processing task or group of related processing tasks.
Jobs are submitted to the computer system for processing via JCL (Job Control Language).
You refer to a series of JCL statements as a jobstream or input stream.

*The Operating System
The operating system (OS) supervises all jobs submitted to the computer system for processing. Two operating system components are:

**Examine the following table**
Component	Description
BCP Base Control Program	BCP controls the job's execution. It is not the focus of this course.
JES Job Entry Subsystem	JES reads your job, interprets the JCL, prints the output and purges the job. JES also performs housekeeping functions for the spool space and the job queues.

As you proceed through the JCL series, you'll learn JCL options that communicate with JES.

Topic 1.2: Introduction to Jobstreams

*Basic Statements
A jobstream is constructed with the job control statements needed to define your job, your program and the resources required.
Data sets and printers are examples of resources you might need.
Three basic JCL statements provide these services. The following pages show a typical jobstream.

*Identifying the Job
The job identifier defines

Jobname
Submitter
Accounting information
Other variables that affect the entire job such as maximum time and priority

*Executing and Defining
Each program executed by the job is named.
Each file accessed by the program is associated with a physical data set definition:

Name
Location (disk, tape, printer)
Characteristics (size, organization)

Note: The terms data sets and files are used interchangeably.

*Start with JOB
Each JCL statement has a unique identifier: JOB, EXEC and DD are the most common.
The placement of the JCL statements is important.
A job must start with a JOB statement and...

EXEC and DD
... be followed by its job steps.
Each job step must start with an EXEC and be followed by its DD statements.
The DD statements may be in any order following the EXEC statement.

*Job Steps
Each executed program begins another job step.
And each data set needed in that step must be defined in a DD statement following the EXEC statement.

Topic 1.3: Statement Format

*JCL Format
Now that you have an idea of what JCL is and what it is used for, take a look at its general format.
//name operation operands comments

*Identifying JCL
//
The operating system identifies JCL as JCL (not data or a program) by the // in positions 1 and 2 of the statement.
These positions are the first two character positions starting the line of JCL you're coding.

*What's in a Name?
//name
The name field is in some cases optional, but more frequently is required. The name field is used either:

To assign a name to a job or a job step or
As the name the program has associated with a particular file

This will become clearer as you proceed, as will the cases when you may omit the name field.

*The Operation
//name operation
The operation field defines the type of statement. Common statement types include:
// JOB statement to identify a job
// EXEC statements to request a program
// DD statements to define a data set
// statement to end a job (called a null statement)
Several other statement types exist. Some are covered in this course. Others are covered in subsequent courses.

*Operands
//name operation operands
The operands are parameters coded to define the services required by the program. Operands describe, for example:

Run-time of the program
Location of the program
Name of the data set
Device the data set is located on

*Comments
//name operation operands comments
You may enter any type of comment desired.

JCL must be coded carefully and correctly. The operating system cannot guess what you mean. You must code precisely what you want.

Topic 1.4: JCL vs. Programs

*JCL
So far you have learned that JCL requests a program to be executed and defines the resources the program needs.
It is just another programming language that can be thought of as a control language.
This section explores how JCL differs from a program.

*Programs
First, let's look at what programs are.
A program is a set of instructions in a computer-readable language that controls what a computer does, step by step. Programs are usually written in a high-level language – one with instructions more like readable English.
COBOL, for example, is such a language. These programs are restructured by a compiler to a language format executable by the computer.

*Comparing the Two
Compare that to JCL.
JCL is written as a series of statements that tell a computer what program to execute and what resources will be needed.
The JCL is submitted to the computer just as it was coded. The operating system interprets what was coded for its use.

*Sample Program
In this section you'll walk through these steps for a program that updates a payroll master file.

Get a record from a transaction file
Get the associated master file record
Determine the type of transaction
Update the master file appropriately
Print a report

*The Role of JCL
To execute the payroll program, JCL must define the following:

Job identifier – jobname, accounting info...
Program to be executed
Location and characteristics of the payroll master file – tape, disk, volume serial number...
Location and characteristics of the transaction file
Selection of a printer for the report – special forms, number of report copies...

*Examining the Differences
You'll continue your examination of the differences between a program and JCL by looking at what's involved in running the program to update the payroll master file.
You'll see the roles of the program and the JCL statements in this process. Now let's go on.

**Examine the following table**
Payroll Update Program	JCL Statements
	`JOB IDENTIFICATION` Every job submitted to the computer must carry identification with it – a name, owner and job accounting information. This identification is done on the `JOB` statement. It must be the first statement in the jobstream.

**Examine the following table**
Payroll Update Program	JCL Statements
	`JOB IDENTIFICATION` `SELECT PROGRAM` The next function of a job is to request that a program be fetched and executed. This is done with the `EXEC` statement, which defines a job step.

**Examine the following table**
Payroll Update Program	JCL Statements
`GET TRANSACTION RECORD` `GET MASTER RECORD` A program requests a record from a data set.	`JOB IDENTIFICATION` `SELECT PROGRAM` `TAPE 007659` `DISK PAY001` The JCL points to the physical location of the data set. `DD` statements do this. They must follow the `EXEC` for the program. They can be listed in any order.

**Examine the following table**
Payroll Update Program	JCL Statements
`GET TRANSACTION RECORD` `GET MASTER RECORD` `PERFORM CALCULATIONS` The program performs the necessary processing on the data retrieved.	`JOB IDENTIFICATION` `SELECT PROGRAM` `TAPE 007659` `DISK PAY001`

**Examine the following table**
Payroll Update Program	JCL Statements
`GET TRANSACTION RECORD` `GET MASTER RECORD` `PERFORM CALCULATIONS` `PRINT REPORT` The report requested by the program is directed ...	`JOB IDENTIFICATION` `SELECT PROGRAM` `TAPE 007659` `DISK PAY001` `PRINTER / FORM 120 / 5 COPIES` ... via the JCL `DD` statement to the appropriate printer.

*JCL Is in Control
JCL performs a necessary system requirement.
It allows any number of data sets to be accessed or created by one program.
The program is written with a logical view of what the data looks like. JCL assigns the physical characteristics such as name, location, and size.
This way, the same program can access the data set stored on disk for regular daily processing or stored on a backup tape for a recovery procedure.

Topic 1.5: Unit 1 Summary

In this unit you learned the following:

Job Control Language, called JCL, is the language that you need to do your work on the computer.
A job is a unit of work performed by the computer system.
You refer to a series of JCL statements as a jobstream or input stream.
A jobstream is constructed with the job control statements needed to define your job, your program, and the resources required.
A job must start with a JOB statement and be followed by its job steps. Each job step must start with an EXEC and be followed by its DD statements. The DD statements may be in any order following the EXEC statement.
Each program execution within a job is called a job step.
This is the format of a generic JCL statement:

//name operation operands comments
The operation field defines the type of statement. Common statement types include

// JOB statement to identify a job
// EXEC statements to request a program
// DD statements to define a data set
// statement to end a job (called a null statement)
A program is a set of instructions in a computer-readable language that controls what a computer does, step by step. The role of a program includes getting records, performing calculations, and printing reports.
JCL is written as a series of statements that tell a computer what program to execute and what resources will be needed. The role of JCL includes identifying the job, selecting the program, pointing to the files or storage devices to read and/or write records, and writing reports.
JCL performs a necessary system requirement. It allows any number of data sets to be accessed or created by one program.

Unit 2. JCL Statements and Procedures

[Skip Unit 2's navigation links]
2. JCL Statements and Procedures
       2.1 JCL Statements
       2.2 JCL Procedures
       2.3 Unit 2 Summary

This unit introduces you to JCL jobstreams. You'll look at each principal type of JCL statement to see what functions it performs. Then you'll look at what procedures are and how they are used to streamline job processing in JCL.

After completing this unit, you should be able to:

Describe the function and format of basic JCL statements
Code basic statements and use them to construct a simple jobstream
Explain how procedures are stored and retrieved

Topic 2.1: JCL Statements

*The Basic Statements
Earlier you learned the steps of the payroll program that update a payroll master file.

Get a record from a transaction file
Get the associated master file record
Determine the type of transaction
Update the master file appropriately
Print a report

We'll focus on the four basic JCL statements: JOB, EXEC, DD and null. There are others, but let's start with the basic building blocks of JCL.

*The JOB Statement
The JCL statements that run the payroll program and identify the required resources are very simple.
First, introduce the job to the system:
//PAYUPD JOB (789,ACT-7),HRD,CLASS=1,TIME=30

**Examine the following table**
Field	Description
`//PAYUPD`	Jobname
`JOB`	Type of statement
`(789,ACT-7),`	Accounting information
`HRD,`	Owner
`CLASS=1,TIME=30`	Priority and run-time

This is the JOB statement. It must always be the first statement in your jobstream.

*Job Numbers
The jobname is only part of the way your job is identified to the system.
When a job is submitted to the system, it is also assigned a number so that it can be further identified. This way, jobs with the same jobname can be uniquely identified.
However, jobs with the same jobname cannot execute simultaneously.
If several jobs with the same name are submitted, they execute sequentially even if the operating system could be processing additional jobs. The operating system will assign a hold status to the jobs waiting to run because of this name conflict.

*Executing a Program
Here's the payroll jobstream so far:
//PAYUPD  JOB  (789,ACT-7),HRD,CLASS=1,TIME=30
Next, select the program to be executed:
//STEP1   EXEC PGM=PAY012

*The EXEC Statement
//STEP1   EXEC PGM=PAY012

**Examine the following table**
Field	Description
`//STEP1`	Step name
`EXEC`	Type of statement
`PGM=PAY012`	Program to be executed

This is the EXEC statement. You may have as many as necessary in the jobstream. Each EXEC statement starts a new job step.

*Defining the File
Here is the payroll jobstream so far:
//PAYUPD  JOB  (789,ACT-7),HRD,CLASS=1,TIME=30
//STEP1   EXEC PGM=PAY012
Next, define each file accessed. Here is the master file:
//MASTER  DD   DSN=PAY.MASTER,DISP=OLD

*The DD Statement
//MASTER  DD   DSN=PAY.MASTER,DISP=OLD

**Examine the following table**
Field	Description
`//MASTER`	A name defined within the program. This name — the `ddname` — is the link between the program and the JCL.
`DD`	Type of statement.
`DSN=PAY.MASTER,`	Name of data set. This name — the `dsname` — is the name given to the data set when it is created on tape or disk.
`DISP=OLD`	This data set exists and is cataloged. A catalog is a list of data sets maintained by the system that contains their location and attributes.

This is the DD (Data Definition) statement. One must be present for each file the program accesses. They may be coded in any order.

    //PAYUPD  JOB  (789,ACT-7),HRD,CLASS=1,TIME=30
    //STEP1   EXEC PGM=PAY012
    //MASTER  DD   DSN=PAY.PAY001,DISP=OLD
    //TRANS   DD   DSN=PAY.TRANS,DISP=OLD
    //REPORT  DD   SYSOUT=A

*More DD Statements
The complete jobstream must contain a DD statement for each data set accessed. The one for the payroll program might look like this.

    //PAYUPD  JOB  (789,ACT-7),HRD,CLASS=1,TIME=30
    //STEP1   EXEC PGM=PAY012
    //MASTER  DD   DSN=PAY.PAY001,DISP=OLD
    //TRANS   DD   DSN=PAY.TRANS,DISP=OLD
    //REPORT  DD   SYSOUT=A

*The Null Statement
Lastly, end the jobstream with the null statement. If you do not code this statement, the system supplies it for you.

*Delimiters
Many times you will see this statement in a jobstream in positions 1 and 2:
/*
It is called a delimiter.
The delimiter marks the end of any data placed directly into the jobstream. This type of data is called instream data. The /* tells the system that the incoming data is complete. You'll see more about instream data later.

Topic 2.2: JCL Procedures

*Reusing JCL Statements
You have seen what the principal types of JCL statements are and how they are put together to run a job. Often you want to use the same JCL statements in many jobs. The JCL option available to accommodate this is a procedure.
This section briefly discusses this topic. A later course in the JCL series provides more depth.
Let's look now at what procedures are and how they are used to streamline job processing in JCL.

*Subroutines
When a part of a program's code performs some specific function, that part of the program is known as a subroutine. Programs may also call other programs that perform general or frequently used subroutines.
JCL uses procedures to accomplish much the same purpose. JCL procedures provide a way to store and retrieve frequently used sets of JCL statements.
Your System group provides procedures for you to use to access systems like SAS, FOCUS, ORACLE, or compilers like COBOL, or your own in-house systems.

*Storing Procedures
A JCL procedure is a series of JCL statements that are stored in a procedure library and given a unique name. A procedure library contains JCL procedures that are stored and accessed by name. A procedure library is often referred to as a PROC LIB.
Let's look at how procedures are stored.


                                                  +——————————————————+
    //STEP1   EXEC PGM=PAY001               |     +——————————————————+
    //TRANS   DD   DSN=PAY.TRANS,DISP=OLD   |<——> |        |
    //MASTER  DD   DSN=PAY.MASTER,DISP=OLD  |     +——————————————————+
    //PRINT   DD   SYSOUT=A                 |     |                  |
                                                  +——————————————————+
*The Procedure Library
JCL statements to perform a task are written and stored in a procedure library. The procedure, consisting of the JCL statements, becomes a member of the procedure library. The name of the member in the example is PAY. The JCL code shown is the contents of this member.

*Retrieving Stored Procedures
After procedures are stored, you can retrieve them by name.
Procedures are invoked using the EXEC statement. The EXEC statement causes a series of JCL statements (a library member) to be retrieved from the library. In effect, the JCL statements replace the EXEC statement. The procedure is brought into the jobstream (instream) with the rest of the job's JCL statements.
Let's look at how this is done.

     //PAYJOB  JOB
     //PAY01   EXEC PROC=PAY

*Executing a Procedure
To invoke the procedure, you code an EXEC statement requesting the procedure by name, as in the example.
Notice the EXEC statement is requesting a PROC (procedure) rather than a PGM (program).

     //PAYJOB  JOB


*With or Without PROC
A procedure may also be requested without coding the PROC=. The system defaults to a procedure when PGM= and PROC= are not coded.
//PAY01  EXEC PAY is identical to the EXEC statement above.

    //PAYJOB  JOB
    //PAY01   EXEC PROC=PAY                       +——————————————————+
                   |     +——————————————————+
       |<——— |        |
      |     +——————————————————+
                     |     |                  |
                                                  +——————————————————+
*How It Works
The operating system looks in the procedure library for the requested member and places all its statements instream.
The four statements of the procedure are brought in and listed just as if they were coded there. They are placed immediately after the EXEC statement that calls them.

*Using Procedures
There are many considerations about procedures. Some that you'll encounter later in this course show you

How to append statements to a procedure during your job's execution. For example in a procedure that copies files, the DD statement for the file to be copied is omitted. You append one when you use the procedure.
How to substitute a value for a symbolic parameter. These parameters are coded in procedures as symbols that can be assigned different values each time the procedure is run. For example a procedure that copies files might use a symbolic parameter for the name of the data set to be copied.

*For More Information
Other considerations are beyond the scope of this course, e.g. how to modify the statements for your job only, or how to search though several PROC libraries to find the procedure.
If you find that you need this information, consult your IBM manual.

*The INCLUDE Group
Another way to handle a series of JCL statements is called an INCLUDE group.
INCLUDE groups give you more flexibility in coding JCL statements. They allow you to place a group of statements into your JCL code without cataloging them in a procedure library or coding them directly into the jobstream.
Refer to your IBM manual for more information on INCLUDE groups.

Topic 2.3: Unit 2 Summary

In this unit you learned the following:

The JOB statement is the first JCL statement in a jobstream. It defines the job to the system.
The EXEC statement is the first JCL statement in a job step. It defines the program to be executed. Any number of EXEC statements can occur in a jobstream.
The Data Definition (DD) statement defines the data set to be used in the program.
The null statement is the last statement in the JCL jobstream. This statement consists of slashes (//) in the first two positions.
The delimiter statement /* marks the end of instream data in the jobstream.
JCL procedures provide a way to store and retrieve frequently used sets of JCL statements.
The system stores procedures in a procedure library. Each procedure is a member of the library.
You invoke a JCL procedure by name using the EXEC statement. The system retrieves a series of JCL statements (a library member) from the library.
If you omit the PGM= and PROC= parameters from an EXEC statement, the system assumes that a PROC is to be executed.

Unit 3. General Syntax Rules

[Skip Unit 3's navigation links]
3. General Syntax Rules
       3.1 Continuing Statements
       3.2 Rules for Fields
       3.3 Parameter Syntax
       3.4 Unit 3 Summary

You have looked at JCL statements and procedures. Now, you need to understand several rules for coding them. The way the code is arranged in a statement, like the way phrases and sentences are put together in everyday spoken language, is known as syntax.
This unit presents most of the syntax rules. Typically, the first few rules will be all you need as you learn the fundamentals of JCL coding.

After completing this unit, you should be able to:

Recall the general syntax rules for coding JCL
Continue statements on multiple lines
Demonstrate proper use of the name, operation, and comments fields, as well as comment statements
Recognize positional and keyword parameters
Correct syntax errors in JCL code

*Keeping It Simple
You can use as many input lines as necessary to code your JCL statements, but you'll want to avoid long or unwieldy statements. The primary rule is KEEP IT SIMPLE!
Code your JCL statements so that they are structured and easy to read. This makes everyone's job easier.
Let's examine in detail the rules for coding JCL statements.

//name operation parameter1,parameter2,... comments
1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

*Reviewing the Format
Here you see the general format of a JCL statement. JCL statements are composed of these fields:

**Examine the following table**
Field	Description
`Name`	This is any valid name you assign.
`Operation`	This includes `JOB`, `EXEC`, `DD` and other operations.
`Operands`	Each operation can have several parameters.
`Comments`	Comments may be entered on any JCL statement. An entire line or lines of JCL can be comments.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //STEP1  EXEC  PGM=PAY012
    ||                |
    ||                |
    // begins a       JCL information ends
    JCL statement.    before position 72.
*Rules 1 and 2
Consider the first two syntax rules:

JCL statements begin with a // in positions 1 and 2.
Positions 3-71 may contain JCL information.

Now, look at a few statements and try to apply these rules.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //DDIN  DD  DSN=MASTER,DISP=(OLD,CATLG)               PAYROLL MASTER

*The Next Two Rules
The next two rules deal with the name field (DDIN), the operation field (DD), and parameters (MASTER, OLD, CATLG) of the operands field.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //DDIN  DD  DSN=MASTER,DISP=(OLD,CATLG)               PAYROLL MASTER
*Rule 3
Fields are separated by one or more blank spaces. Remember the primary rule? Keep it simple!
Here's a place you can apply it: use several spaces to separate and distinguish fields. This makes the statement easier to read.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //DDIN  DD  DSN=MASTER,DISP=(OLD,CATLG)               PAYROLL MASTER

*Rule 4
Parameters are separated by commas. The parameters field is composed of one or more parameters.
You may not use blank spaces between parameters. The parameters field, therefore, looks like this:
parameter1,parameter2,parameter3,......

Topic 3.1: Continuing Statements

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //TAPEIN  DD  DSN=CUSTFILE,DISP=OLD,
    //            UNIT=TAPE,VOL=SER=008908

*Breaking Up Your Code
The next item on the agenda for statement syntax is how to continue JCL statements. Not all the parameters for a JCL statement need to be coded on the same line. In fact, it is desirable to use several lines for one operation so that your JCL is easy to read.
Only the comment (//*), delimiter (/*) and null (//) statements may not be continued.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //TAPEIN  DD  DSN=CUSTFILE,DISP=OLD,
    //            UNIT=TAPE,VOL=SER=008908

*The Rules for Continuing
These are the rules for continuing a JCL statement:

Stop coding the parameters before position 72.
Interrupt the field at a parameter or subparameter.
Include the separating comma. (In the example, note the comma after OLD.)
Code a // in positions 1 and 2 of the next statement. Code a space in position 3. Continue coding the interrupted field in or before position 16. (In the example, note that UNIT starts in position 15).
To continue a comments field, there are special rules. You must also code a non-blank character in position 72.

Topic 3.2: Rules for Fields

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //  EXEC  PGM=PAY012

*The name Field
Let's now look at the rules specific to each field.
The name field is the statement identifier. Other JCL statements can refer to the information contained on this statement by using the name.
The name field must start in position 3. There are no spaces between the // and the name.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //  EXEC  PGM=PAY012

*Valid Characters
The name field can be made up of 1-8 alphanumeric (A-Z, 0-9) and national (@ # $) characters.
The first character of the name field must be alphabetic or national.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //STEP1    PGM=PAY012

*The operation Field
Next, the operation field defines the type of JCL statement.
This field must start at or before position 16. Remember, the operation is a field and must be separated from the preceding and following fields by one or more spaces.
JOB, EXEC, and DD are examples of the contents of operation fields.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //STEP1  EXEC  PGM=PAY012                     STEP TO BACKUP MASTER FILE


*The comments Field
Let's save the parameters field for last and look at the comments field.
The comments field is optional. It may contain any information that you care to put there.
This is the only field that can be coded past position 71.

*The Comment Statement
Another way to include a comment in JCL is with the comment statement.
//*    COMMENTS
1...+....1....+....2....+....3....+....4
The asterisk (*) in position 3 indicates the statement contains only comments.
By using a series of comment statements, you can create a block to make your comments stand out.
//********************************************
//*                                          *
//*            COMMENTS                      *
//*                                          * //********************************************

Topic 3.3: Parameter Syntax

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //MYJOB  JOB  ACCT#24,MYNAME,CLASS=A,TIME=10


*The Parameters Field
Now it's time to look at the syntax for parameters. The parameters field is composed of parameters.
As you know from a previous rule, each of the parameters must be separated by a comma. However, the parameters field itself must be separated from the operation field and the comments field, if any, by one or more spaces.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //MYJOB  JOB  ACCT#24,MYNAME,CLASS=A,TIME=10


         accounting information,programmer's name
*Positional Parameters
There are two types of parameters — positional and keyword — and several rules defining how to code them.
A positional parameter is recognized by the position it holds within the parameters field. It must be coded in the proper sequence to be recognized.
The only identifying factor of positional parameters is their position. The positional parameters in the example give the accounting information and the programmer's name.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //MYJOB  JOB  ACCT#24,MYNAME,CLASS=A,TIME=10


*Keyword Parameters
A keyword parameter is identified by the keyword followed by an equals sign (=) and the variable information.
They may be coded in any sequence as long as they follow the positional parameters and are separated by commas.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //DDIN  DD  DSN=OLD.MASTER,DISP=(OLD,DELETE)


*Subparameters
A parameter may be composed of subparameters. Subparameters follow the same syntax rules as parameters and must be enclosed in parentheses.
The next few pages describe the rules for coding subparameters. Because some of the rules involve options that you are not yet familiar with, you will not be questioned on the material. Just take a look at the statements to become familiar with the formats. You will often see statements coded this way.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //SYSUT2  DD  DSN=MASTER,DISP=OLD,LABEL=(,SL),VOL=(RETAIN,SER=041765),
    //            UNIT=TAPE,DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)


*Separating Subparameters with Commas
Let's summarize the rules for subparameters.
1. Subparameters are separated by commas.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //SYSUT2  DD  DSN=MASTER,DISP=OLD,LABEL=(,SL),VOL=(RETAIN,SER=041765),
    //            UNIT=TAPE,DCB=(RECFM=FB,LRECL=80,BLKSZE=800)

                                                      RETAIN is positional
                                                      SER= is keyword
*Ordering the Subparameters
2. Positional subparameters must precede keyword subparameters.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //SYSUT2  DD  DSN=MASTER,DISP=OLD,LABEL=(,SL),VOL=(RETAIN,SER=041765),
    //            UNIT=TAPE,DCB=(RECFM=FB,LRECL=80,BLKSIZE=800)


*Using Parentheses
3. A list of subparameters must be enclosed in parentheses unless you include only one subparameter.
For example: DCB=BLKSIZE=800 does not need parentheses.

    //name    operation    parameter1,parameter2,...      comments
    1...+....1....+....2....+....3....+....4....+....5....+....6....+....7..

    //SYSUT2  DD  DSN=MASTER,DISP=OLD,LABEL=(,SL),VOL=(RETAIN,SER=041765),
    //            UNIT=TAPE,DCB=(RECFM=FB,LREL=80,BLKSIZE=800)


                                        LABEL=(1,SL)
                                    includes the default
*Omitting Defaults
4. If a subparameter is a default value, you can omit it, but you must include a comma to mark its place.

Topic 3.4: Unit 3 Summary

In this unit you learned the following:

JCL statements begin with a // in positions 1 and 2.
Positions 3-71 may contain JCL information.
Fields are separated by one or more spaces.
Parameters are separated by commas.
JCL statements may be continued.
The name field is the statement identifier.
The operation field defines the type of JCL statement.
Comments may continue past position 71. This field is optional.
The operands field is composed of parameters.
There are two types of parameters — positional and keyword.
A parameter may be composed of subparameters. Subparameters follow the same syntax rules as parameters. They must be enclosed in parentheses when more than one subparameter is specified.

Unit 4. Building Jobstreams

[Skip Unit 4's navigation links]
4. Building Jobstreams
       4.1 Diagramming the System Flow
       4.2 Outlining the Jobstream
       4.3 Unit 4 Summary

So far you've learned about the primary JCL statements used in jobstreams and the proper syntax rules for coding JCL statements.
Many programmers feel overwhelmed at this point; there seem to be so many rules and parameters that they don't know where to start! However, learning to build a JCL jobstream isn't that difficult. In fact, it's fairly straightforward if you approach it step by step.
In this unit you'll learn the steps to get your JCL jobstream started. You'll design a system flow diagram and begin coding the basic statements that will make up your jobstream.

After completing this unit, you should be able to:

Describe the steps to take before you begin coding JCL
Create a system flow diagram
Outline an entire jobstream

Topic 4.1: Diagramming the System Flow

*Programs and Utilities
First, let's recall what a program is and define a utility.
A program is a set of instructions in a computer-readable language that control what a computer does, step by step.
A utility is a program that performs a commonly needed task, such as printing or copying data sets. Some come with the operating system and some can be bought from vendors.

*Step by Step
Printing a data set is exactly the problem you will solve. You'll

Select the program or utility to use
Define its requirements
Diagram the job requirements
Build the jobstream

Since choosing the program or utility is first on your list, let's choose one and see what comes next.

*Selecting a Utility
IBM supplies many utilities with their operating systems. One, in particular, is very easy to use and performs functions such as copying and printing data sets.
You will use this one for printing a data set. It is called IEBGENER. You can find complete information about it in the Utilities Reference Manual.
Don't get worried by the name. All IBM utilities start with unusual prefixes to distinguish them from programs written in-house.
Now that you've selected IEBGENER, the next step is to learn a few things about it before you write the JCL.

*Defining Requirements
Here's what you need to learn about IEBGENER:

Input/output files that it uses
ddnames that it expects
Control parameters that it needs to run

This table shows what IEBGENER needs to run.

**Examine the following table**
Data Sets Files	`ddname`
Input	`SYSUT1`
Output	`SYSUT2`
Messages	`SYSPRINT`
Parameters	`SYSIN`

*Files and ddnames
Take a moment to understand how files and ddnames are associated.
When the program accesses a file, the program refers to the file by its file name. The file name that the program uses must be associated with the ddname of a DD statement following the EXEC statement in the JCL. Therefore, the ddname is the link or bond between the JCL and the program.
The DD statement specifies the exact location of the file, such as the tape number, the disk name or the specific printer.
In the example below, MASTER will be linked within PAY012 with the file name the program uses to access PAY.MASTER.
//STEP1 EXEC PGM=PAY012
//MASTER DD DSN=PAY.MASTER,DISP=OLD

*Where ddnames Come From
ddnames are arbitrary names selected by the author of the program.
Usually, they must follow standards set by the installation. And you'll notice that all IBM utilities use similar ddnames for similar functions.
But, the important idea is that they are already defined.

*Reviewing the Requirements
Let's review the table of what IEBGENER needs to run.

**Examine the following table**
Data Sets Files	`ddname`
Input	`SYSUT1`
Output	`SYSUT2`
Messages	`SYSPRINT`
Parameters	`SYSIN`

Now, let's get down to the business of coding the jobstream for the sample problem. Remember, you need to print a data set.
For your reference, the following question screens display this table showing the IEBGENER specifications.

*The System Flow Diagram
Now you can see what the job requires. From here you can start writing the JCL.

Topic 4.2: Outlining the Jobstream

*Coding the Stubs
The first step in actually coding JCL is to outline the entire jobstream.
Make an outline by coding stubs for each JCL statement:

The JOB and end-of-job statements
An EXEC statement for each step
DD statements for each input or output file

A stub is a skeleton or incomplete statement, omitting information to be filled in later. Here are sample stubs for the JOB, EXEC and DD statements.
//jobname   JOB
//stepname  EXEC
//ddname    DD

*Naming Rules
Before you can code these stubs, you must remember the rules for coding JOB, STEP and DD names:

The name field must start in position 3. There are no spaces between the // and the name.
The name field can be made up of 1-8 alphanumeric (A-Z, 0-9) and national (@ # $) characters.
The first character of the name field must be alphabetic or national.
The name field must be followed by at least one blank space.

*Step Names
The step name:

Is optional.
May be a mnemonic describing what the step is doing or what sequence it is in the job.
Should be coded since it is used many times for referencing, parameter substitutions, overriding information and restarting jobs.

*The Finished Outline
You now have stubs for all the JCL statements needed to run this job.
//PRINTIT  JOB
//STEP1    EXEC
//SYSUT1   DD
//SYSUT2   DD
//SYSPRINT DD
//SYSIN    DD
//
The next step is to fill in the necessary parameters, as you will see in the next unit.

Topic 4.3: Unit 4 Summary

In this unit you learned the initial steps for writing a simple jobstream:

Define the problem.
Determine the program or utility to use. The program needed may be one of the utilities provided with the operating system.
Review the program documentation to learn the requirements of the utility or program.
The file name that the program uses must be associated with the ddname of a DD statement following the EXEC statement in the JCL. Therefore, the ddname is the link or bond between the JCL and the program.
Before coding the jobstream, draw a system flow diagram to graphically represent what is happening. A program box, plus all input and output data sets, should be included in this diagram.
Outline the entire jobstream by coding stubs for each JCL statement, including the JOB and end-of-job statements, an EXEC statement for each step, and DD statements for each input or output file. A stub is a skeleton or incomplete statement, omitting information to be filled in later.

Unit 5. Adding Jobstream Details

[Skip Unit 5's navigation links]
5. Adding Jobstream Details
       5.1 The JOB Statement
       5.2 Keyword Parameters
       5.3 Unit 5 Summary

In the jobstream you have been coding, you still need to give the computer system some instructions about your job and about the input and output data for your processing task. You do this by assigning the appropriate values or choices in JOB, EXEC and DD statement parameters.
In this unit, you will learn about the JOB statement parameters and add the necessary parameters to the jobstream that you are building.

After completing this unit, you should be able to:

Identify parameters commonly used in the JOB statement
Add positional parameters to the JOB statement
Code keyword parameters for the JOB statement

Topic 5.1: The JOB Statement

*Reviewing the Statement
//jobname JOB accounting information,programmer's name,keyword parameters
Here's a brief description of the JOB statement shown above.

**Examine the following table**
Portion	Description
`jobname`	A unique name to identify your job to the operating system
`JOB`	The type of statement
`accounting information`	Account number and other accounting information
`programmer's name`	Name of the person or group submitting the job
`keyword parameters`	Other parameters such as the job class and the maximum run time

*The Positional Parameters
For any job, you usually need to specify the job accounting information and programmer's name. However, they are optional and can vary with each installation.
The accounting information and programmer's name are positional parameters that identify the job submitter.
Positional parameters must be coded in the proper location to be recognized. Only their value is coded on the statement.
Let's look at these parameters and then code them on the JOB statement for your run.

*Accounting Information
//jobname JOB ,programmer's name,keyword parameters
(<account number><,accounting information>...)
The accounting information parameter is used to charge the submitter or submitter's department for the resources that the job used. Your installation defines the acceptable values.

account number ties the resources used to the appropriate account.
Additional accounting information is optional, but may be required by your installation.

*Some Examples
//jobname JOB ,programmer's name,keyword parameters
(<account number><,accounting information>...)
Here are some examples of JOB statements with valid accounting information parameters.
This JOB statement contains both accounting parameters, so you need to enclose the parameters in parentheses.
//JOBX JOB (27-566,SYSTEMS)
This JOB statement contains the account number only, so no parentheses are needed.
//JOBX JOB B175

*The Programmer's Name
//jobname JOB accounting information,,keyword parameters
The programmer's name parameter identifies the job submitter.
This parameter is usually the name of the person who submitted the job, although it may be a group or department code.

*Rules
//jobname JOB accounting information,,keyword parameters
Let's look at rules and examples for coding the programmer's name.

If coded, the name must follow the accounting information parameter and precede all keyword parameters.
//PRINTIT JOB 0103467,SMITH,TIME=1
If the parameter is omitted, you don't have to code a placeholding comma.
//PRINTIT JOB 0103467,TIME=1
The programmer's name must be 20 characters or less. If special characters (except periods and hyphens) are included, the name must be enclosed in apostrophes.
//UPDATE JOB (D100,HR),L.SMITH
//UPDATE JOB (D100,HR),'DEPT/7'

Topic 5.2: Keyword Parameters

*Keywords with =
The rest of the JOB statement contains keyword parameters.
Remember that these parameters can occur in any sequence as long as they follow the positional parameters.
These parameters are identified by their keyword. The desired value follows the equals sign.

*The CLASS Parameter
CLASS=jobclass
CLASS designates the class that the job will execute in. Most installations assign a default job class if the CLASS parameter is omitted. The possibilities for job class are a one position code from A-Z or 0-9.
CLASS=0
CLASS=X
When your job is submitted, it is placed in an input queue where it waits to be executed. Queues can be thought of as waiting lines for jobs. Each job class has its own input queue.

*The TIME Parameter
TIME=(<minutes><,seconds>)
TIME indicates the total amount of CPU time a job may use. It is much shorter than the clock time.
TIME=10           (10 minutes)
TIME=(,30)     (30 seconds)
To specify the time, you'll need to develop a sense of job processing time requirements from experience. You can also refer to the standards and guidelines at your installation that deal with specifying CPU time.

*Details of TIME
TIME=(<minutes><,seconds>)
If the job exceeds the CPU time limit, it is generally terminated. If it takes less CPU time than specified, it merely runs to completion.
You may also code the TIME parameter on the EXEC statement. In that case, the time limit applies to a job step.
If no TIME parameter is specified, the default established at your installation is in effect.
Often the CLASS and TIME parameters are associated. For example short jobs are automatically placed in one CLASS, tape jobs in another, and so on.


   //STEP1    EXEC
   //SYSUT1   DD
   //SYSUT2   DD
   //SYSPRINT DD
   //SYSIN    DD
   //
*Completed JOB Statement
Your JOB statement does not need any other parameters for this run.
Before we move on, let's briefly review a few other important parameters for the JOB statement.

*The MSGCLASS Parameter
MSGCLASS=output-class
The MSGCLASS parameter assigns the system's job log — a record of information about your job — to an output-class. Messages relating to your job are routed to the designated output-class. The possibilities for output-class are a one-position code from A-Z or 0-9.
MSGCLASS=A
MSGCLASS=9
This parameter also has a default value if not coded. Your installation may modify this to any valid class. The system supplied default is MSGCLASS=A.

*The MSGLEVEL Parameter
MSGLEVEL=(<statements><,messages>)
The MSGLEVEL parameter is used to control the amount and type of job control statements and system messages that print. You'll see some applications for this parameter in the review of JCL output in a later course.
MSGLEVEL=(0,0)  print the JOB statement only, print no allocation/termination messages
MSGLEVEL=(1,1)  print all JCL statements, print all allocation/termination messages
As with most of the JOB parameters, the default values are defined by your installation.

MSGLEVEL Values
The MSGLEVEL subparameters may have the following values:

**Examine the following table**
	Value	Definition
`statements`	0 1 2	Print the `JOB` statement only. Print all JCL statements. - instream - expanded cataloged procedures - symbolic parameter substitutions Print instream JCL statements only.
`messages`	0 1	Print no allocation/termination messages unless the job abnormally ends. Print all allocation/termination messages.

*The NOTIFY Parameter
NOTIFY=userid
The NOTIFY parameter tells the system to send a message to your TSO userid or another TSO userid when the job is completed. The userid must be a valid TSO userid.
NOTIFY=RSMITH NOTIFY=DEPT18
If you are not logged on when the message is sent, the system saves the message until you do log on.

*The TYPRUN Parameter
TYPRUN=run-option
The TYPRUN parameter controls special processing for the job. Three of the run options you can control with the TYPRUN parameter are

SCAN the JCL for syntax errors only. Do not run the job. Note that JES2 is covered later in this JCL series.
COPY the JCL to print (JES2 only). Do not run the job. Note that JES2 is covered later in this JCL series.
HOLD the job until the operator releases it. Then run the job.

*The JOB Is Critical
Since your JOB statement identifies the job to the operating system, it is very critical. Each parameter must be coded properly.
If the JOB statement is coded incorrectly the rest of the JCL statements are not processed and the job is flushed.

Term: A job that is flushed is immediately purged from the system.

*Additional Parameters
You've looked at the parameters that you are most likely to use on the JOB statement. However, there are others, and you may wish to know something about one or more of them.

**Examine the following table**
Parameter	Description
`ADDRSPC`	Indicates if a job is pageable or nonpageable
`COND`	Sets the criteria for execution for job steps
`PERFORM`	Assigns a performance group to a job
`PRTY`	Designates a job's selection priority
`RD`	Defines restart and checkpoint processing
`REGION`	Specifies the amount of storage the job needs
`RESTART`	Indicates job restart method
`GROUP`	Associates a user with a RACF group
`PASSWORD`	Specifies/changes the current RACF password
`SECLABEL`	Specifies the job's RACF security level
`USER`	Specifies the RACF `userid`
`BYTES`	States the job's maximum amount of printed output & action
`CARDS`	States the job's maximum for punched card output & action
`LINES`	States the job's maximum amount of printed output & action
`PAGES`	States the job's maximum amount of printed output & action

ADDRSPC can be set to VIRT for jobs that can run in virtual storage. These jobs can be paged by the system. If you do not want the system to page a job, set ADDRSPC to REAL. The system must place the job in central or real storage. Refer to your IBM manuals for information on job paging.

COND specifies the criteria that the return code is tested against for each job step. The system assumes that each step coded is to be processed unless the specified criteria are met. Since this parameter is hard to understand, you can use the IF/THEN/ELSE construct instead.

PERFORM sets a job's performance group. This determines a job's performance criteria — how quickly it is given CPU resources. Your installation defines the characteristics of each performance group and controls their use.

PRTY assigns a selection priority to a job. Jobs are selected within each class by priority. The higher a job's priority, the sooner it gets selected. The use of this parameter is usually controlled.

RD indicates if automatic job restart is to be performed by the operator for applications with checkpointing if the job fails. It also controls the execution or suppression of the CHKPT macro instruction and the DD statement CHKPT parameter.

REGION specifies the maximum amount of virtual storage in either kilobytes (K) or megabytes (M) that a job requires. If this parameter is omitted, an installation default is assigned.

RESTART indicates that a job is to be restarted at a job step, a procedure step, or a checkpoint within a job step.

GROUP associates a user with a RACF group.

PASSWORD specifies and changes (optional) the current RACF password.

SECLABEL specifies the security level for your job. The value of this parameter is a security label name that determines your security level.

USER specifies the RACF userid.

BYTES specifies the maximum amount of output the job's SYSOUT data sets may print and the action the system takes if the amount is exceeded. The amount is specified in thousands of bytes.

CARDS specifies the maximum amount of punched card output for a job's SYSOUT data sets and the action the system takes if the amount is exceeded. The amount is specified in number of cards.

LINES specifies the maximum amount of output the job's SYSOUT data sets may print and the action the system takes if the amount is exceeded. The amount is specified in thousands of lines.

PAGES specifies the maximum amount of output the job's SYSOUT data sets may print and the action the system takes if the amount is exceeded. The amount is specified in number of pages.

Topic 5.3: Unit 5 Summary

In this unit you learned the following:

The format of the JOB statement is
//jobname JOB accounting information,programmer's name,keyword parameters
The accounting information parameter is used to charge the submitter or submitter's department for the resources that the job used. Your installation defines the acceptable values.
The programmer's name parameter identifies the job submitter. This parameter is usually the name of the person who submitted the job, although it may be a group or department code.
CLASS designates the class that the job will execute in. Most installations assign a default job class if the CLASS parameter is omitted.
TIME indicates the total amount of CPU time a job may use. It is much shorter than the clock time.
The MSGCLASS parameter assigns the system's job log — a record of information about your job — to an output class.
The MSGLEVEL parameter is used to control the amount and type of job control statements and system messages that print.
The NOTIFY parameter tells the system to send a message to your TSO userid or another TSO userid when the job is completed.
The TYPRUN parameter controls special processing for the job.

Unit 6. Additional Statement Parameters

[Skip Unit 6's navigation links]
6. Additional Statement Parameters
       6.1 The EXEC statement
       6.2 The DD Statement
       6.3 Unit 6 Summary

Your basic jobstream is established, the stubs are coded, and your JOB statement is complete.
In this unit, you will learn about the EXEC statement parameters and see if any need to be added to your jobstream.
You will also learn about the parameters used for DD statements that deal with instream data sets, messages, and reports.

After completing this unit, you should be able to:

Add PROC or PGM parameters to EXEC statements
List other parameters that can be used on the EXEC statement
Use the *, DATA, and DUMMY positional parameters to define input in the DD statement
Code the SYSOUT keyword parameter to define output in the DD statement

Topic 6.1: The EXEC statement

*Reviewing the Statement
The program uses the EXEC statement to provide information about job steps.
//stepname EXEC parameters comments
The EXEC statement format is shown above. Here's what each field means.

**Examine the following table**
Portion	Description
`stepname`	Name of the job step
`EXEC`	The type of statement
`parameters`	List of parameters and their values or subparameters
`comments`	Any comments you choose to add

*The Positional Parameters
The EXEC statement has two positional parameters that must be coded before any of the keyword parameters. (These positional parameters cannot be used at the same time.)

PGM: the program to be executed in the step
PROC: the procedure to be called, or procedure name, a shortened form of PROC=procedure name

*The PGM Parameter
PGM=program name
The PGM parameter designates the name of the program to be executed in this step.
PGM=CUST01
If you code the PGM parameter, do not code the PROC parameter on the same EXEC statement.
If the program specified in the PGM parameter can't be located, the step abnormally ends.

*The PROC Parameter
PROC=procedure name
or
procedure name
The PROC parameter designates the procedure to be executed in this job step. Notice that the PROC parameter has a short form or default which is the same as the PROC parameter with "PROC=" omitted.
EXEC PROC=LINK is the same as EXEC LINK
If you code the PROC parameter, do not code the PGM parameter on the same EXEC statement.

   //PRINTIT  JOB  0078963,TEST,TIME=(,45)

   //SYSUT1   DD
   //SYSUT2   DD
   //SYSPRINT DD
   //SYSIN    DD
   //
*Completed EXEC Statement
Although your EXEC statement does not require any additional parameters, let's briefly review the PARM parameter and then see what other parameters are available.

*The PARM Parameter
PARM=information
The PARM parameter allows a program to receive input. The format, type, and content of the information are defined by the program.
PARM=ANNUAL is an example of the PARM parameter with a single subparameter.
Many utilities, compilers, linkage editors, as well as application programs use the PARM field to change the options in effect or signal special processing. One example is to indicate year-end processing.

*Same Keyword Parameters
Many of the keyword parameters from the JOB statement are also available on the EXEC statement. They include:

**Examine the following table**
`ADDRSPC`	`RD`
`COND`	`REGION`
`PERFORM`	`TIME`

These parameters set specifications and limits as follows:

on the JOB statement for the entire job
on the EXEC statement for the job step

*Additional EXEC Parameters

**Examine the following table**
Parameter	Description
`ACCT`	Specifies the accounting information
`ADDRSPC`	Indicates the type of storage the job needs
`COND`	Sets the criteria to bypass or execute this step
`DYNAMNBR`	Holds the number of data set allocations for reuse
`PERFORM`	Assigns a performance group to a job step
`RD`	Defines step restart and checkpoint processing
`REGION`	Specifies the amount of storage the step needs
`TIME`	Specifies the maximum CPU time the step may use

ACCT is like the accounting field on the JOB statement except that it is a keyword parameter rather than positional. It allows you to specify the accounting information for the step only.

ADDRSPC can be set to VIRT for steps that can run in virtual storage. These steps can be paged by the system. If you do not want the system to page a job step, set ADDRSPC to REAL. The system must place the job in central or real storage.

COND specifies the criteria that the return code is tested against for this job step. The system assumes that the step coded is to be processed unless the specified criteria are met. Since this parameter is hard to understand, you can use the IF/THEN/ELSE construct instead.

DYNAMNBR specifies the number (1-3273) of data set allocations that the system can hold for reuse.

PERFORM sets a job step's performance group. This determines a step's performance criteria — how quickly it is given CPU resources. Your installation defines the characteristics of each performance group and controls their use.

RD indicates if automatic step restart is to be performed by the operator if the step fails. It also controls the execution or suppression of the CHKPT macro instruction and the DD statement CHKPT parameter.

REGION specifies the amount of storage in either kilobytes (K) or megabytes (M) that a step requires. If this parameter is omitted, an installation default is assigned.

TIME is specified for the step in the same manner as for the job. You may specify the maximum time in minutes and/or seconds. If the step exceeds the time specified, the job abends — even if there is more time for the entire job.

Topic 6.2: The DD Statement

*The Jobstream So Far
Your basic jobstream is established, the stubs are coded and your JOB and EXEC statements are complete. It is now time to move on to the DD statements.
Here is the sample jobstream as you have coded it so far. The DD statements can be placed in any order as long as they follow the EXEC statement.
//PRINTIT  JOB  0078963,TEST,TIME=(,45)
//STEP1    EXEC PGM=IEBGENER
//SYSUT1   DD
//SYSUT2   DD
//SYSPRINT DD
//SYSIN    DD
//
*Reviewing the Statement
//ddname   DD   parameters   comments
The format of the DD (Data Definition) statement is shown here. The statement has these fields:

**Examine the following table**
Portion	Description
`ddname`	The data definition name
`DD`	The type of statement
`parameters`	List of parameters on the `DD` statement
`comments`	Any comments you care to include

*The Positional Parameters
Let's look at what positional parameters you might use to complete the SYSIN DD statement. The SYSIN DD statement contains control parameters for the IEBGENER program. You can code these directly in your JCL as an instream data set.
Two positional parameters on the DD statement that are discussed here allow you to begin an instream data set.

* for instream data that doesn't contain JCL
DATA for instream data that contains JCL

Another positional parameter that you will see can be used when you do not require a data set for a particular run. For example, when your run of IEBGENER does not require any control parameters.

DUMMY for when a data set is not accessed

*The * Parameter
The * parameter specifies that data for a processing program immediately follows the DD statement.
This parameter provides one method for reading instream data sets. It reads data without // or /* in positions 1 and 2.
The following JCL statements use the * parameter:
//STEP1      EXEC  PGM=READDATA
//MYDATA  DD    *
instream data that doesn't contain JCL
/*
The system reads the statements following a //ddname DD * statement as instream data until another JCL statement (//) or a delimiter (/*) statement is encountered.

*The DATA Parameter
If you need to include JCL statements as part of your instream data set you must use the DATA parameter and end the input with a /* delimiter.
The following JCL statements use the DATA parameter:
//STEP1       EXEC  PGM=READDATA
//MYDATA  DD      DATA
instream data that contains JCL
//RPT           DD     SYSOUT=A
/*
The system reads the statements following a //ddname DATA statement as instream data, including other JCL statements (//), until a delimiter (/*) statement is encountered.

*The DUMMY Parameter
Sometimes a data set will not be used for a particular run of a jobstream. For example, your run of the IEBGENER program does not require any control parameters. In this case, use the DUMMY parameter.
The DUMMY parameter specifies that

No device or external storage space is allocated.
No disposition processing is performed.
No input or output operations are performed for the data set if it is sequential.

However, if your program requires DCB (Data Control Block) information you must code a DCB parameter. You don't have to worry about this now, as it is not required. You'll see the DCB parameter later.

*One Keyword Parameter
Now, review one keyword parameter that you need to define your output print data sets — SYSUT2 and SYSPRINT.
SYSOUT assigns the data set to an output class.
Many other keyword parameters are available for the DD statement. You will cover the more commonly used ones in a later course.

*The SYSOUT Parameter
SYSOUT=class
The SYSOUT parameter directs printed output to the appropriate print class, form, or special program for output. The class specifies the output queue that the output is placed in until it is selected by a printer. Class is a one position, alphanumeric character that can have the values A-Z, 0-9, or *.
//PRINTFIL DD SYSOUT=A
Find out the valid classes at your installation. Using invalid class assignments can result in

Your print job not being selected for print
Your print job printing at the wrong location
Operator problems

   //PRINTIT  JOB  0078963,TEST,TIME=(,45)
   //STEP1    EXEC PGM=IEBGENER

   //SYSUT2   DD   SYSOUT=A
   //SYSPRINT DD   SYSOUT=A
   //SYSIN    DD   DUMMY
   //
*Other DD Parameters
Most of the coding is done. You just have one statement to go — the SYSUT1 DD statement. This is the statement that accesses your input data set.
Let's look briefly at the other parameters that the DD statement has. The parameters are separated into four categories — frequently used, infrequently used, controlling output, and used by SMS (Storage Management Subsystem).

*Frequently Used Parameters
The following list of parameters are ones that you will see and/or code frequently in JCL.

**Examine the following table**
Parameter	Description
`DCB`	Completes the data control block for the data set
`EXPDT`	Specifies the expiration date
`LABEL`	Gives information about the data set label
`LRECL`	Indicates the logical record length
`RECFM`	Specifies the format and characteristics of records
`RETPD`	Specifies the data set retention period
`SPACE`	Requests space for a new data set on DASD (disk)
`UNIT`	Requests a device for the data set
`VOLUME`	Identifies the volume(s) where the data set resides
`DISP`	Describes the status of the data set
`DSNAME`	Identifies the data set name
`BLKSIZE`	Specifies the length of a block

The DCB parameter contains many subparameters such as BLKSIZE (block size), LRECL (logical record length), and RECFM (record format). These specify the data set attributes contained in the data control block.

Use EXPDT to specify the date when the data set can be deleted or written over by another data set.

LABEL is used for both tape and disk data sets. It can specify the data set sequence number, type of label, password, if the data set is opened for input or output, and the expiration date or retention period.

Code LRECL to specify the length of the records in a new data set.

RECFM specifies if the records in a new data set have fixed, variable, or undefined length; if they are blocked; and other less frequently used characteristics such as containing machine code control characters.

Use RETPD to specify the number of days a data set is kept before it can be deleted or written over by another data set.

The SPACE parameter specifies the amount of space in tracks, cylinders, blocks or average record length required for a data set on a direct access storage device (DASD). Both a primary and secondary allocation can be specified.

The UNIT parameter can request a device specifically by number, by its generic name, or by a group name. It can also tell the system how many devices to allocate to the data set and whether the volume should be mounted when the data set is allocated or deferred until it is opened.

The VOLUME parameter specifies the volume serial number, if it is a private volume, whether it should be retained after the data set is closed for further processing, the volume sequence number of a multi-volume data set, and the maximum number of volumes an output data set requires.

DISP assigns a status of NEW, OLD, MOD, or SHR. It also tells the system what to do with the data set if the step ends normally or abnormally.

DSNAME gives a name for the system to assign to a new data set or to use to locate an existing data set.

BLKSIZE specifies the maximum length for a block in bytes.

*Infrequently Used Parameters
This list contains parameters that you may come across infrequently, if at all.

**Examine the following table**
Parameter	Description
`AMP`	Completes the access method control block for VSAM data sets
`ACCODE`	Specifies or changes the accessibility code
`CHKPT`	Writes a checkpoint at each end-of-volume except the last
`CNTL`	References a previous `CNTL/ENDCNTL` group
`DDNAME`	Postpones data set definition until later in the job step
`DLM`	Specifies a special delimiter for instream data
`DSID`	Identifies 3540 diskette data sets
`FREE`	Specifies when data set resources are closed
`HOLD`	Holds a `SYSOUT` data set until it is released
`KEYLEN`	Specifies the key length of a new data set
`DYNAM`	Increases dynamically-controlled resources held for reuse
`PROTECT`	Requests RACF protection for a data set
`QNAME`	Designates a data set containing TCAM messages
`SUBSYS`	Specifies the subsystem to process the data set
`TERM`	Indicates a TSO user data set

The AMP parameter contains many subparameters such as CROPS (checkpoint/restart) and RECFM (record format). These specify the information contained in the access method control block for VSAM data sets.

The ACCODE parameter specifies or changes the accessibility code for ISO/ANSI/FIPS Version 3 tape output data sets only. The code is written to tape. If the code is authorized, the job can use the data set. If not, the job is abnormally terminated.

The CHKPT parameter requests that a checkpoint be written when an end-of-volume condition is reached for either input or output multi-volume data sets. A checkpoint is not written for the last end-of-volume condition.

The CNTL statement references a CNTL/ENDCNTL group defined earlier in the jobstream. The system executes the program control statements contained within the group.

The DDNAME parameter is placed on a DD statement in either a job step or procedure step to reference a data set defined later in the job set. This parameter also lets you do a backward reference to a DD statement defined earlier.

Use the DLM parameter when you want to end your instream data other than with the standard /* or // delimiters.

The DSID parameter specifies the ID of an input or output data set on a 3540 diskette.

The FREE parameter specifies if a data set's resources are to be freed when the data set is closed or at the end of the step.

The HOLD parameter holds a SYSOUT data set. A TSO user can then retrieve the data set and view its contents at the terminal. The data set is held until it is released by the system operator.

KEYLEN specifies the number of bytes used for a key in a new data set.

DYNAM provides compatibility with older systems. It increases the control value by one.

Use PROTECT to request RACF protection for a disk data set, a tape data set or a tape volume if RACF is active.

TCAM is a telecommunications access method. Use QNAME to tell the system that the DD statement defines a data set that contains TCAM messages.

The SUBSYS parameter identifies the subsystem you want to process the data set. You can also specify parameters passed to the subsystem.

The TERM parameter specifies that the data set is either coming from or going to a TSO user's terminal.

*Output Parameters
This list of parameters controls output.

**Examine the following table**
Parameter	Description
`BURST`	Directs the output to the proper stacker on a 3800
`CHARS`	Names a character-arrangement table for a 3800
`COPIES`	Specifies the number of copies of the data set to print
`DEST`	Specifies a `SYSOUT` data set's output destination
`FCB`	Defines the forms control used in printing
`FLASH`	Specifies the forms overlay used
`MODIFY`	Specifies the copy-modification module used while printing
`OUTLIM`	Limits records written to the `SYSOUT` data set
`OUTPUT`	Links an `OUTPUT` JCL statement with a `SYSOUT` data set
`UCS`	Specifies the character set used in printing
`SPIN`	Specifies when `SYSOUT` output can print

Use the BURST parameter to direct the output to a stacker on the 3800 printer. You can burst the output into separate sheets or keep it in continuous fanfold style.

The SYSOUT data set can use one or more character-arrangement tables to translate output when printing to a 3800. The CHARS parameter can also request a high-density dump.

The COPIES parameter specifies the number of copies of a data set that are printed. If you are using a 3800 printer you can also specify how many copies of each page are to print before the next page is printed.

The DEST parameter specifies the local or remote device or node where the sysout data set is sent.

FCB specifies the carriage control tape for 1403 printers, the data protection image for 3525 card punch, or the forms control buffer for most other printers. The FCB image specifies the lines per inch and page size used in printing.

On a 3800 printer the FLASH parameter specifies the name of the form to be overlaid while printing. You can also specify the number of copies to print.

The MODIFY parameter is used on the 3800 printer to name the copy-modification module that is used to orchestrate printing. The module can specify legends, column headings, where and on which copies the data is printed.

The OUTLIM parameter specifies the number of records written to a spooled data set.

The OUTPUT parameter references an OUTPUT JCL statement that contains output processing parameters for the data set. The data set is processed with options from this DD and the OUTPUT JCL statement.

The UCS parameter specifies the universal character set image, print train for impact printer, or character-arrangement table for 3800 printers used for printing SYSOUT data sets.

SPIN specifies whether the output from SYSOUT data sets can print immediately upon unallocation or must wait until the end of the job.

*Storage Management Subsystem
In a later course you will get a brief introduction to a facility called SMS, or the Storage Management Subsystem. Data sets managed by this facility are much easier to allocate. Let's look at some Storage Management Subsystem parameters.
Be careful if you use them. SMS parameters are installation-dependent and must be defined correctly or they will be ignored in your JCL.

*SMS Parameters
Here are the parameters used by SMS.

**Examine the following table**
Parameter	Description
`DATACLAS`	Identifies the data class for the data set
`STORCLAS`	Indicates the storage class for the data set
`MGMTCLAS`	Specifies the management class for the data set
`AVGREC`	Requests the space allocation for the data set in records
`DSNTYPE`	Specifies the data set as a PDS, PDSE, HFS or FIFO
`KEYOFF`	Specifies the key offset for a new VSAM data set
`LIKE`	Specifies the attributes from a model data set
`RECORG`	Specifies how a VSAM data set's records are organized
`REFDD`	Specifies the attributes from a `DD`-defined data set
`SECMODEL`	Specifies the RACF profile

DATACLAS specifies the data class for the data set. The data class is defined by the storage administrator.

STORCLAS specifies the storage class for the data set. The storage class is defined by the storage administrator.

MGMTCLAS specifies the management class for the data set. The management class is defined by the storage administrator.

When you define a new data set you can request that the space allocated be calculated by the number of records you anticipate creating. AVGREC overrides the space defined by the data set's data class.

The DSNTYPE parameter specifies the data set type or overrides the data class DSNTYPE. It can specify either a PDS, PDSE, HFS or FIFO. A PDSE is similar to a PDS but contains only data. An HFS is similar to a PDSE and is used by OpenMVS. The FIFO is where data is written on a first-in- first-out basis and is also called a named pipe.

KEYOFF is used to override the Relative Key Position (RKP) of a VSAM key-sequenced data set. Using KEYOFF, the first byte of a VSAM logical record is position zero.

The LIKE parameter copies the attributes for a new data set from a model data set. This data set must exist and be cataloged. The copied attributes can be overridden on your JCL.

RECORG specifies the record organization in a VSAM data set. This parameter can override the record organization defined by a data class.

The REFDD parameter copies the attributes for a new data set from a data set defined on a prior DD statement in the jobstream. These attributes override any defined by the data set's data class. These attributes can also be overridden on your JCL.

SECMODEL copies an existing RACF profile for a new data set when there is no default profile or when you want to change the default profile.

Topic 6.3: Unit 6 Summary

In this unit you learned the following:

The format of the EXEC statement is
//stepname EXEC parameters comments
The PGM parameter designates the name of the program to be executed in this step.
The PROC parameter designates the procedure to be executed in this job step. The PROC parameter has a short form, or default, which is the same as the PROC parameter with "PROC=" omitted.
The PARM parameter allows a program to receive input. The format, type, and content of the information are defined by the program.
Many of the keyword parameters from the JOB statement are also available on the EXEC statement. These parameters set specifications and limits as follows:

on the JOB statement for the entire job
on the EXEC statement for the job step
The format of the DD statement is
//ddname DD parameters comments
The * parameter specifies that data for a processing program immediately follows the DD statement. The system reads the statements following a //ddname DD * statement as instream data until another JCL statement (//) or a delimiter (/*) statement is encountered.
If you need to include JCL statements as part of your instream data you must use the DATA parameter. The system reads the statements following a //ddname DATA statement as instream data, including other JCL statements (//), until a delimiter (/*) statement is encountered.
Sometimes a data set will not be used for a particular run of a jobstream. In this case, use the DUMMY parameter.
The SYSOUT parameter directs printed output to the appropriate print class, form or special program for output. The class specifies the output queue that the output is placed in until it is selected by a printer.