Sei sulla pagina 1di 46

JCL

Version: JCL/HANDOUT/0605/2.0 Date: 14-06-05

Cognizant Technology Solutions 500 Glen Pointe Center West Teaneck, NJ 07666 Ph: 201-801-0233 www.cognizant.com

JCL

TABLE OF CONTENTS
Introduction................................................................................................................................... 6 About this Module......................................................................................................................... 6 Target Audience........................................................................................................................... 6 Module Objectives........................................................................................................................ 6 Pre-requisite ................................................................................................................................. 6 Chapter 1: Overview of JCL .......................................................................................................... 7 Learning Objectives ..................................................................................................................... 7 What is JCL?................................................................................................................................ 7 Job and a Job step....................................................................................................................... 7 Sample JCL.................................................................................................................................. 7 Job Entry Subsystem ................................................................................................................... 8 How JES2 and JES3 process Jobs.............................................................................................. 8 SUMMARY ................................................................................................................................... 9 Test your Understanding ............................................................................................................ 10 Chapter 2: Structure of JCL statements .................................................................................... 11 Learning Objective ..................................................................................................................... 11 Introduction................................................................................................................................. 11 The identifier field....................................................................................................................... 11 The name field ........................................................................................................................... 11 The operation field ..................................................................................................................... 11 The parameters field .................................................................................................................. 11 The comments field.................................................................................................................... 12 How to continue JCL statements ............................................................................................... 12 SUMMARY ................................................................................................................................. 12 Test your Understanding ............................................................................................................ 12 Chapter 3: The JOB statement ................................................................................................... 13 Learning Objectives ................................................................................................................... 13 Functions of the JOB statement................................................................................................. 13 Copyright 2004, Cognizant Academy, All Rights Reserved 2

JCL

A simplified job statement .......................................................................................................... 13 Job name ................................................................................................................................... 13 Accounting Information .............................................................................................................. 13 Programmer Name .................................................................................................................... 14 User and Password.................................................................................................................... 14 Class .......................................................................................................................................... 14 Notify .......................................................................................................................................... 14 MSGCLASS and MSGLEVEL .................................................................................................... 15 Time ........................................................................................................................................... 15 Job Statement Examples ........................................................................................................... 15 SUMMARY ................................................................................................................................. 16 Chapter 4: The EXEC statement ................................................................................................. 17 Learning Objectives ................................................................................................................... 17 The EXEC statement ................................................................................................................. 17 Basic format of an EXEC statement .......................................................................................... 17 The PGM parameter .................................................................................................................. 17 The PARM parameter ................................................................................................................ 17 The COND parameter ................................................................................................................ 18 SUMMARY ................................................................................................................................. 19 Test your Understanding ............................................................................................................ 19 Chapter 5: The DD statement...................................................................................................... 20 Learning Objectives ................................................................................................................... 20 The DD statement ...................................................................................................................... 20 Three formats of the DD statement............................................................................................ 20 The DD statement for DASD data sets ...................................................................................... 21 The DISP parameter .................................................................................................................. 21 The UNIT and VOLUME parameters ......................................................................................... 23 The SPACE parameter .............................................................................................................. 23 The DCB Parameter................................................................................................................... 25

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

The DD statement for in-stream data sets ................................................................................. 26 The DATA parameter ................................................................................................................. 26 The DLM parameter ................................................................................................................... 27 The DD statement for SYSOUT data sets ................................................................................. 27 SUMMARY ................................................................................................................................. 28 Test your Understanding ............................................................................................................ 28 Chapter 6: Special JCL statements and Data sets ................................................................... 29 Learning Objectives ................................................................................................................... 29 The null statement...................................................................................................................... 29 The comment statement ............................................................................................................ 29 DUMMY data sets ...................................................................................................................... 29 Temporary data sets .................................................................................................................. 29 Concatenating data sets ............................................................................................................ 31 SUMMARY ................................................................................................................................. 33 Test your Understanding ............................................................................................................ 33 Chapter 7: JCL Procedure........................................................................................................... 34 Learning Objectives ................................................................................................................... 34 JCL Procedure ........................................................................................................................... 34 Invoking a procedure.................................................................................................................. 34 Cataloged and in-stream procedures......................................................................................... 35 Code a job that uses an in-stream procedure............................................................................ 35 Code a job that uses a cataloged procedure ............................................................................. 36 The JCLLIB statement ............................................................................................................... 36 SUMMARY ................................................................................................................................. 37 Test your Understanding ............................................................................................................ 37 Chapter 8: Modifying a Procedures statements - overrides................................................... 38 Learning Objective ..................................................................................................................... 38 Introduction................................................................................................................................. 38 Modify EXEC statement parameters.......................................................................................... 38

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

Modify DD statement parameters .............................................................................................. 38 Adding a DD statement .............................................................................................................. 39 SUMMARY ................................................................................................................................. 39 Chapter 9: Symbolic parameters ................................................................................................ 40 Learning Objective ..................................................................................................................... 40 Introduction................................................................................................................................. 40 Symbolic parameters ................................................................................................................. 40 Code symbolic parameters ........................................................................................................ 40 Specify values for symbolic parameters..................................................................................... 40 Symbolic parameter values ........................................................................................................ 41 Assign default values to symbolic parameters ........................................................................... 43 SUMMARY ................................................................................................................................. 44 Test your Understanding ............................................................................................................ 44 REFERENCES............................................................................................................................... 45 WEBSITES................................................................................................................................. 45 BOOKS....................................................................................................................................... 45 STUDENT NOTES: ....................................................................................................................... 46

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

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

Target Audience
This Module is specifically intended for Entry Level Programmer Trainees who need a basic idea of JCL.

Module Objectives
The main objective of the module is to provide knowledge on the following areas: Need of JCL in Mainframe Various JCL statements Preparing a JCL for batch application

Pre-requisite
The Module assumes that the student shall have a prior knowledge in the following areas: Programming in COBOL or any other mainframe language, Understanding of MVS operating system

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

Chapter 1: Overview of JCL


Learning Objectives
The chapter shall achieve the following objectives: Understanding Job and JES Understanding the need of a Job

What is JCL?
Job Control Language (JCL) is a means of communication between an application program and the computer's operating system. It is a set of control statements that provide the specifications necessary to process a JOB.

Job and a Job step


A Job is nothing but the execution of one or more related programs in sequence. Each program to be executed by a job is called a Job Step. To illustrate, suppose you want to process a job that executes two programs: the first updates a customer file, and the second prints a report that lists customers by name. This is a two step job because two programs are involved. The entire set of statements that provide the specifications like the name of the program, the name of the customer file, the daily transaction file, and the details about the printer form the Job Control Language. JCL statements mainly perform the following functions: Specify the input data sets (files) that must be accessed Identifies the output data set to be created or updated Allocates the resources for the programs that are to run, using this input and output data sets.

Sample JCL
//First //STEP01 //INPUT DD // //OUTPUT // // // //SYSOUT DD DD JOB EXEC SAMPLE JOB, CLASS=S PGM=REPORT DSN=CUSTOMER.FILE, DISP=SHR DSN=REPORT.FILE, DISP=(NEW,CATLG,DELETE) UNIT=SYSDA,DCB=(RECFM=FB,LRECL=80), SPACE(TRKS,(100,20),RLSE) SYSOUT=* 7

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

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

Job Entry Subsystem


To process a Job, an important component of MVS called the Job Entry Subsystem (JES) is used. In simple terms, the JES is the MVS component that keeps track of jobs that enter the system, presents them to MVS for processing, and sends their spooled output to the correct destination. There are two versions, JES2 and a later version with additional capabilities, JES3. Although you should know whether your operating system uses JES2 or JES3, it doesnt really matter in most cases. For typical jobs that dont have unusual processing requirements that depend on the unique characteristics of JES2 or JES3, both Job Entry Subsystems provide essentially the same functions: they let you enter a job into the system, they decide when your job should be processed, they pass your job to MVS for processing, and they deliver your jobs printed output to the correct destination.

How JES2 and JES3 process Jobs


The life cycle of a typical job is as follows: The job is submitted The jobs is selected for execution The job is executed The jobs output is processed The job is purged How a job is entered into the system As already mentioned, you write all the JCL statements in a DASD file. To enter, or submit, the job into the system, you issue a SUBMIT command. That causes JES2 or JES3 to read the job stream from the DASD file and copy it to a job queue, which is a part of a special DASD file called the JES spool. How a job is scheduled for execution MVS does not necessarily process jobs in the order in which you submit them. Instead, JES examines the jobs in the job queue and selects the most important jobs for execution. That way, JES can prioritize its work, giving preference to more important jobs. JES uses two characteristics to classify a jobs importance, both of which can be specified in the jobs JCL: job class and priority. Of the two, job class is more significant. If two or more jobs of the same class are waiting to execute, the JES scheduler selects the one with the higher priority. A single character, either a letter (A-Z) or a digit (0-9) represents each job class. Job classes are assigned based on the processing characteristics of the job. As an illustration, Class A jobs can execute only for 15 minutes, Class B jobs for 30 minutes, Class C jobs with unlimited time and Class T is reserved for jobs that require tape files. However, bear in mind that the Copyright 2004, Cognizant Academy, All Rights Reserved 8

JCL

above job class assignments are only an example. Each installation makes is own job class assignments, so the job classes your installation uses will certainly be different. Before we proceed, let us discuss about a special type of program called the initiator, because that knowledge will help you understand not only job scheduling, but MVS multiprogramming as well. An initiator is a program that takes care of all the job related activities - it examines the JES spool, selects an appropriate job for execution, executes the job in its address space, and returns to the JES spool for another job. The number of active initiators on a system determines the number of batch jobs that can be multiprogrammed at once. Each initiator has one or more jobs associated with it; it executes jobs only from those classes. Within a job class, initiators select jobs for execution based on their priorities, which can range from 9 to 15. Jobs with higher priority values are selected for execution before jobs with lower priority values. If two or more jobs have the same class and priority, they are executed in the order in which they were submitted. How a job is executed The first thing after an initiator does after it selects a job for execution is to invoke a program called the interpreter. The interpreters job is to examine the job information passed to it by JES and create a series of control blocks in the scheduler work area (SWA), a part of the address spaces private area. Among other things, these control blocks describe all of the data sets the job needs. After the interpreter creates the SWA control blocks, the initiator goes through three phases for each step in the job. First, it invokes allocation routines that analyze the SWA control blocks to see what resources (units, volumes, and data sets) the job step needs. If the resources are available, they are allocated so the job can process them. Next, the initiator builds a user region where the users program can execute, loads the program into the region, and transfers control to it. When the program is completed, the initiator invokes unallocation routines, which release any resources used by the job step. Input to a program need not always be got from a data set. You can also give it in the JCL itself. Input data processed in this way is called SYSIN data or in-stream data. Similarly, the users program can produce output data thats not written to any data set but stored in the JES spool; the program treats the data, called SYSOUT data, as if it was written to a printer. How a jobs output is processed Like jobs, SYSOUT will be assigned an output class that determines how the output will be handled. Most likely, an output class indicates which printer can be used to print the output. In some cases, an output class specifies that the output not be printed; instead, it is held so that you can view it from a display terminal. How a job is purged After the jobs output has been processed, the job is purged from the system. Simply put, that means that the JES spool space the job used is freed so it can be used by other jobs.

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

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

JES is the MVS component that keeps track of jobs that enter the system, presents them to MVS for processing, and sends their spooled output to the correct destination.

Test your Understanding

1). What is JCL? A. One type of Programming Language B. Operating System Component C. Interface between Operating System and Application program D. Sub System of Operating System

Answer: 1) B

Copyright 2004, Cognizant Academy, All Rights Reserved

10

JCL

Chapter 2: Structure of JCL statements


Learning Objective
The chapter shall achieve the following objective: Understanding the basic structure of JCL statement

Introduction
JCL statements are coded in 80-byte records; however, only 72 of the 80 characters are available to code JCL. The last eight columns of each record are reserved for an optional sequence number. Each JCL statement is divided into several fields, which are summarized below in Fig 2.1. Identifier [Name] [Operation] [Parameters] [Comments]

Fig 2.1 - Basic structure of a JCL statement

The identifier field


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

The name field


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

The operation field


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

The parameters field


The parameters field begins at least one position after the end of the operation field and can extend into column 71. Within the parameters field, you code one or more parameters that supply information that influences how the statement is processed. When a parameters field consists of more than one parameter, you separate the individual parameters with commas. MVS assumes that the parameters field is complete when it encounters a space so dont include a space by accident. If you need to include a space as part of a parameter value, you must enclose the parameter value in apostrophes. A parameter may be one of two types: positional or keyword. A positional parameter must occur in a specific position within the 11 Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

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

The comments field


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

How to continue JCL statements


Often, you wont be able to fit all the parameters you need to code on a single 80-character line. When that happens, youll have to continue the statement onto one or more additional lines. Follow the steps given below when you want to code continuation lines: Break the parameter field after the comma that follows a parameter or subparameter Code slashes in columns 1 and 2 of the following line Code the next parameter beginning anywhere in columns 4 through 16

SUMMARY
Format of JCL statements

Test your Understanding


1). Which of the following are Operation Fields in JCL statements? A. JOB B. EXEC C. PROGRAM D. DD 2). How many different types of Parameter Fields are there? A. 4 B. 3 C. 2 D. 1 Answer: 1) A 2) A

Copyright 2004, Cognizant Academy, All Rights Reserved

12

JCL

Chapter 3: The JOB statement


Learning Objectives
Understanding JOB statement and its various parameters.

Functions of the JOB statement


The JOB statement (or the JOB Card), which must always be the first JCL statement coded for a job, has three basic functions. First, it identifies a job to MVS and supplies a job name that MVS uses to refer to the job. Second, it supplies accounting information so that MVS can determine who is responsible for the job, and, if necessary, who should be billed for the computer resources the job uses. Third, it supplies various options (like the Class parameter we discussed before) that influence or limit how the job is processed.

A simplified job statement


//jobname JOB [accounting information] [,programmer name] [,USER=user-id] [,PASSWORD=password] [,NOTIFY=user-id] [,MSGCLASS=class] [,MSGLEVEL=(stmt,msg)] [,TIME=(mins,secs)]

Fig 3.1 - Structure of a Job statement The above Figure 3.1 shows a simplified job statement (or card). Let us discuss each of these parameters in detail.

Job name
You must always code a name on the JOB statement; the name you supply becomes the job name MVS uses to identify your job. Depending on the installation and how you use the system, there may be rules that govern how you can form job names. If you are submitting a job from TSO or ISPF, you should follow a rigid format for creating job names: your TSO userid followed by a single alphanumeric character and the job name can be a maximum of eight characters. For example, if your TSO id is TRG0001, then the job names can be TRG0001A or TRG0001B.

Accounting Information
The accounting information parameter is an installation dependent positional parameter (some dont require this at all!) that supplies information used to determine whos responsible for the Copyright 2004, Cognizant Academy, All Rights Reserved 13

JCL

job and how its billing should be handled. Usually, this parameter consists of several positional sub-parameters, the first of which is normally an account number. Examples: (MMA2AB14,206)

Programmer Name
This is again installation dependent and may or may not be required. If required, you can code upto a maximum of 20 characters. Also, you must enclose the programmer name field in apostrophes if it contains special characters or spaces. Examples: Rick, 205-BILL (This is enclosed in apostrophes because of the hyphen) Please note that accounting information and programmer name are positional parameters. So, you have to code them in the correct sequence and also replace them with a comma if you are not coding any of the two parameters. All other parameters of the job card are keyword parameters; so you need not worry about the order of sequence while writing them.

User and Password


You should have learned about RACF, which is a security manager that controls access to MVS resources. If your job processes resources that are protected by RACF, you must be authorized by RACF to use those resources. Two JOB statement parameters let you identify yourself to RACF: USER and PASSWORD. The USER parameter specifies your RACF userid, which is usually the same as your TSO user-id. Similarly, the PASSWORD parameter supplies a RACF password thats valid for the user-id you specify; it is usually the same as your TSO password. If you submit a batch job from TSO, your RACF user-id and password are automatically passed on to the batch job. So you dont have to specify USER and PASSWORD on a JOB statement submitted from TSO.

Class
You learnt earlier that initiators select jobs for execution based on job classes. Normally, when you submit a job JES2/JES3 assigns a default job class that is determined by the reader that processes the job. To change the default job class to a user specified one, you use the CLASS parameter on the JOB statement. For example, the following statement will submit the job in the class B. //TRG0001Z JOB CLASS=B

Notify
If you submit a job from a TSO terminal, you can code the NOTIFY parameter on the JOB statement so that youll automatically be notified when the job completes. For example, suppose you code this JOB statement: //TRG0001Z JOB NOTIFY=TRG0001

When the job completes, a message like the one below will be sent to your TSO terminal. 15.16.16 JOB 5969 $HASP165 TRG0001Z ENDED AT MVSPS1 CN (00) 14

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

MSGCLASS and MSGLEVEL


Whenever MVS executes a job, it lists the JCL statements and various system messages. You can control these output messages with the help of two parameters, MSGCLASS and MSGLEVEL. MSGCLASS lets you specify an output class where the system messages can be directed, like a printer. Example: MSGCLASS=X. The MSGLEVEL parameter lets you specify the type of messages you want included in your output. MSGLEVEL has two positional sub-parameters: MSGLEVEL = (stmt, msg) The first, stmt, controls which JCL statements appear in the JCL statement listing. The second, msg, controls the amount of message output that appears in the message log. The default value is MSGLEVEL = (1,1). Stmt Values 0 1 2 Msg Values 0 Print step completion messages only; dont print allocation and deallocation messages unless the job fails Print all messages Table 3.1 - Different values of MSGCLASS parameter Print only the Job statement Print only JCL statements, include those that come from procedures Print only JCL statements submitted through the input stream; dont print statements from procedures

Time
The Time parameter helps you to limit the amount of time the job can use the processor. The format of the Time parameter is Time=(minutes, seconds)

Job Statement Examples


Finally, here are some examples of the JOB statement. //TRG0001A JOB MMA2AB14,PATRICK Account number MMA2AB14, programmer name PATRICK //TRG0001A // //TRG0001A JOB (MMA2AB14,206),HARRY POTTER,MSGCLASS=A, MSGLEVEL=(0,1),TIME=(10,50) JOB ,HARRY P,USER=TRG0001,PASSWORD=PASXXXX 15

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

Note the comma before the programmer name. This is because we have not coded the accounting information parameter, which is a positional parameter.

SUMMARY
The JOB statement must always be the first JCL statement coded for a job It has three basic functions It identifies a job to MVS and supplies a job name that MVS uses to refer to the job It supplies accounting information It supplies various options like the Class parameter

Copyright 2004, Cognizant Academy, All Rights Reserved

16

JCL

Chapter 4: The EXEC statement


Learning Objectives
Understanding the EXEC statement and its parameters.

The EXEC statement


An EXEC statement identifies each step in a job. As you know, each program to be executed by a job is called a Job Step.

Basic format of an EXEC statement

//stepname

EXEC

PGM=program-name

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

Fig 4.1 - Structure of the EXEC statement

The PGM parameter


In the PGM parameter, you specify the name of the program you want to execute for the job step. Actually, the name you specify is the name of a member of a partitioned data set. The member must be a load module (an executable file); that is, a module that has been compiled, link-edited and is ready to execute. Normally, the program you specify must be a member of a system load library, such as SYS1.LINKLIB. However, youll learn in due course, how to use a private library to execute a program that is written by you and that dont reside in any of the system libraries.

The PARM parameter


In the PARM parameter, you can code information that can be accessed by the program you specify in the PGM parameter. This kind of information is usually used to influence the way the program works. For example, many IBM-supplied programs, like utilities, compilers, and the linkage editor, use PARM information to set various processing options. User programs can use this facility too.

Copyright 2004, Cognizant Academy, All Rights Reserved

17

JCL

The COND parameter


When a program completes execution (normally or with an abend), it passes a value called a return code back to MVS. The return codes usually follow the conventions described below in Table 4.1: Return Code 0 4 8 12 Meaning Program ran to successful completion Program encountered a minor error but was able to recover Program encountered a problem that prevented successful execution Program encountered a problem that prevented successful execution; normally, this indicates a more serious error than return code 8 Program encountered a serious error and was not able to continue Table 4.1 Different return codes and their meanings Other return codes, especially for user-written programs, might indicate specific conditions that were encountered. Although a return code can range in value from 0 to 4095, most return codes are multiples of four between 0 and 16, according to the conventions described above. In some cases, the value of a job step's return code may affect subsequent processing. To illustrate, let us say you have two steps (or programs) in a job; the first program debits money from an account and the next program credits the same amount of money (that was debited in the first step) to another account. As you can clearly understand, the second step (credit action) can be done only if the first step (debit) is successful. Using the COND parameter, you can decide to execute a step based on the return code of the previous step(s). The COND parameter lets you specify a return code and a relational operator to determine whether to skip a particular job step. The format of the COND statement is shown in Figure 4.2

16

COND=(CODE, OPERATOR, STEPNAME)


Fig 4.2 - Format of the COND statement The "code" value can be any decimal value in the range 0 to 4095; the "operator" can be one of the following: EQ - equal LT - less than LE - less than or equal to NE - not equal to GT - greater than GE - greater than or equal to Copyright 2004, Cognizant Academy, All Rights Reserved 18

JCL

Let us see how the COND parameter works. Consider the example, //STP0200 EXEC PGM=PRINT,COND=(4,LT,STP0100) The above COND statement means that if 4 is LESS THAN the return code of STP0100, then STP0200 will not execute. Let us say, that the return code of STP0100 is 8. Since 4 is less than 8, STP0200 will not execute. On the other hand, if STP0100 returns 0 or 4, then STP0200 will execute as 4 is not less than 0 or 4. Consider another example, //stp0010 EXEC PGM=SORT, COND=(7,LT) As you can see, we have not mentioned any step name in the COND parameter. The COND parameter in the above example says to bypass STP0010 if 7 is less than the return code issued by any previous step. You can also compare the return codes of more than one previous specific step as below: COND=((8,EQ,STEP1),(12,LE,STEP2)) There are two additional sub-parameters, EVEN and ONLY, that let you specify how an abend affects job step execution. When you specify COND=EVEN, you tell MVS to execute the job step EVEN if any of the previous steps has abended (that is, ended abnormally due to a program failure). That is the step will be executed irrespective of the previous step(s) return code(s). On the contrary, COND=ONLY tells MVS to execute the job step ONLY if a previous step has abended; if an abend has not occurred, the step is not executed. EVEN is useful for steps that dont depend on the successful completion of previous steps. ONLY is useful for steps that perform recovery processing that should be invoked only in the event of an abend.

SUMMARY
An EXEC statement identifies each step in a job

Test your Understanding


1). What is COND=EVEN? A. execute this step even if any of the previous steps, terminated abnormally. B. execute this step only if any of the previous steps, terminated abnormally. C. Both D. None of the following Answer: 1) A

Copyright 2004, Cognizant Academy, All Rights Reserved

19

JCL

Chapter 5: The DD statement


Learning Objectives
The chapter shall achieve the following objective: Understanding the parameters of the DD statement

The DD statement
You should know that before a job steps program is executed, any data sets the program will process are allocated. To describe the data sets that are used by the program, you code DD (Data Definition) statements. Normally, you code one DD statement for each data set your program will process. You code the DD statements after the EXEC statement that identifies the job step.

Three formats of the DD statement


The DD statement is the most complicated of the JCL statements. The three simple formats of the DD statement are given in the figure 5.1. 1. DD statement for DASD data sets //ddname // // // // // DD DSNAME=data-set-name ,DISP=(status,normal-disp,abnormal-disp) [,UNIT=unit] [,VOL=SER=vol-ser] [,SPACE=unit,(primary,secondary,dir)] [,DCB=(option,option)]

2. DD statement for in-stream data sets //ddname // DD * [,DLM=XX]

3. DD statement for SYSOUT data sets //ddname DD SYSOUT=*

Fig 5.1 - The three different formats of the DD statement

There is one thing each of the DD statement formats have in common: each requires a ddname. The ddname is a one to eight character symbolic name that the processing program uses to refer to the file. In a COBOL program, the ddname is the name specified in the ASSIGN clause of the files SELECT statement. In an assembler language program, it is the Copyright 2004, Cognizant Academy, All Rights Reserved 20

JCL

name specified in the DDNAME parameter on the files DCB or ACB macro. Other programming languages have similar facilities to specify a files ddname. It is crucial at this point for you to realize that the ddname is not necessarily the actual name of the file as indicated the files label. Instead, the ddname is an intermediate name that lets a program refer to the file without using its actual data set name.

The DD statement for DASD data sets


The DSNAME parameter The DSNAME parameter supplies the data set name as it is stored in the data sets label or in the files catalog entry. It is always required for a permanent data set. Example: //INPUT DD // DSNAME=TRG0001.CUSTOMER, DISP=SHR

To refer to a member of a partitioned data set, you code a standard data set name followed by the members one-to-eight character name in parentheses. For example, consider this DSNAME parameter: DSNAME=TRG0001.TEST.COBOL (ORD1100) Here, the member named ORD1100 in a partitioned data set named TRG0001.TEST.COBOL is allocated. You can abbreviate the DSNAME parameter as DSN.

The DISP parameter


The DISP parameter describes the "disposition" or status of a data set to MVS and to tell MVS how to handle the data set after the end of the step or job. The DISP parameter has three positional sub-parameters: status, normal disposition, and abnormal disposition. Status specifies the current state of the data set, whether it needs to be created (NEW), or shared with other jobs (SHR), or given exclusive access to the job (OLD) or records appended to the data set (MOD). Normal Disposition specifies what the system should do with the data set if the job step ends normally; you can keep the file (KEEP), delete it (DELETE), catalog it (CATLG), uncatalog it (UNCATLG), or retain it for use by a subsequent job step (PASS). Abnormal Disposition specifies what to do if your program fails or abends; you specify any of the values you can specify for normal disposition except for PASS. The following Table 5.1 shows the values you code for each of the three DISP subparameters, describes each option, and explains how MVS selects default values for subparameters you omit. Status NEW The data set does not exist and should be created

Copyright 2004, Cognizant Academy, All Rights Reserved

21

JCL

Status OLD SHR MOD The data set exists and should be allocated for exclusive use The data set exists and should be allocated for shared use The data set is allocated for exclusive use and is positioned at the end of the data, so additional records may be added after the last record Table 5.1 - Values of the Status sub-parameter and their meanings Normal and abnormal disposition DELETE KEEP CATLG UNCATLG PASS The data set is deleted and also uncataloged The data set is retained The data set is retained and a catalog entry is made The data set is retained, but its catalog is removed Normal disposition only. The data set is retained for use by a later job step Table 5.2 - Values of the Normal and Abnormal sub-parameters Default Values Status Normal Disposition If omitted, MVS assumes NEW Depends on the value specified or assumed for status; if NEW, normal disposition is DELETE; if OLD, SHR, or, MOD, normal disposition is KEEP Takes on the value specified or assumed for normal disposition Table 5.3 - Default values of the Disp parameter The Table 5.2 specifies the values of the Normal and Abnormal sub-parameters and the Table 5.3 gives the default values of the Disp parameter. Table 5.4 gives the examples for the DISP parameter. DISP=SHR DISP=OLD Allocate an existing data set for shared access; normal and abnormal default to KEEP Allocate an existing data set for exclusive access; normal and abnormal disposition default to KEEP If the data set exists appends data to it; otherwise, create it. Access is exclusive; normal and abnormal disposition default to KEEP 22

Abnormal Disposition

DISP=MOD

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

DISP=(NEW,CATLG) DISP=(OLD,DELETE) DISP=(,KEEP,DELETE)

Allocate a new data set and catalogs it; abnormal disposition defaults to CATLG Allocate an existing data set and delete it; abnormal disposition defaults to DELETE Allocate a new data set and keep it if the job step ends normally, if the job step ends abnormally, delete the data set Table 5.4 - Examples for the Disp parameter

The UNIT and VOLUME parameters


The UNIT and VOLUME parameters work together to specify the location of a data set. UNIT indicates the device where the data set resides (like, DASD or tape), and VOLUME indicates the VOL-SER of the data sets volume. You specify UNIT and VOLUME when you are creating a new data set or when you are retrieving an existing uncataloged data set. For a cataloged data set, the unit and volume information is stored in the catalog, so you dont need to code it in the JCL. Examples of Unit parameter: UNIT=SYSDA to indicate that the referred data set is on DASD UNIT=TAPE to indicate that the referred data set is on a tape drive

Also, there can be other values for the UNIT parameter, which depends on the installation that you are working on. The VOLUME parameter lets you specify which volume you want to allocate for your data set. That is called a specific volume request. For a new data set, the VOLUME parameter is optional; if you omit, MVS scans the eligible volumes based on how you code the UNIT parameter to determine which volume is best to contain your file. That is called a non-specific volume request. On the VOLUME parameter, you specify a volume serial number, like this: VOLUME=SER=ABC100 Here, the volume serial number is ABC100. Usually, you abbreviate the volume parameter, like this: VOL=SER=ABC100 Note that, if you code the VOLUME parameter, you should always code the UNIT parameter too.

The SPACE parameter


For a new data set, you must code the SPACE parameter to tell MVS how much primary and secondary space to allocate to the data set. The SPACE parameter format has two positional parameters and the second positional parameter itself has three positional sub parameters. Figure 5.2 depicts the Format of the SPACE parameter. Copyright 2004, Cognizant Academy, All Rights Reserved 23

JCL

SPACE=(unit,(primary,secondary,dir)) Fig 5.2 - Format of the SPACE parameter The first parameter, unit indicates the unit of measure used for the space allocation. Most often, you will allocate space in terms of cylinders (CYL) or tracks (TRK). For example, in the space parameter SPACE=(CYL,(10,1)) The unit of allocation is cylinders. The second SPACE sub-parameter indicates how much space to allocate to the data set. It has three positional sub-parameters that specify primary, secondary, and directory space. The primary allocation indicates how many units of space to allocate for the data sets primary extent. If the file requires more space than the primary allocation, up to 15 secondary extents can be allocated, each as large as the secondary amount you specify. The third sub-parameter, directory allocation is only for partitioned data sets. It indicates how large the librarys directory should be. The directory allocation ignores the unit of measure you specify and allocates the directory instead in units called directory blocks, each of which is large enough to define 21 members. So, if you expect the library to hold 40 members, allocate two directory blocks. Here are a few more examples of the space parameter: SPACE=(CYL,(10,2)) SPACE=(TRK,(5,2)) SPACE=(CYL,(4,1,5)) Directory blocks is 5

Copyright 2004, Cognizant Academy, All Rights Reserved

24

JCL

The DCB Parameter


The DCB parameter lets you specify the file characteristics that are stored in the files Data Control Block. You code the DCB parameter only for new files. The following table 5.5 shows four commonly used DCB sub-parameters. DSORG=XX Specifies the data sets organization, as follows: PS Physical Sequential

PO Partitioned DA Direct IS RECFM=n Indexed Sequential Specifies the format of the files records, as follows F V Fixed length, unblocked Variable length, unblocked FB Fixed length, blocked VB Variable length, blocked VBS Variable length, blocked, spanned U LRECL=n BLKSIZE=n Undefined Specifies the length of the files records Specifies the length of the files records; for FB, BLKSIZE is normally a multiple of LRECL Table 5.5 - Commonly used DCB sub-parameters All the above mentioned are keyword parameters, so you can code them in any order you wish. There arent any default values for the DCB subparameters, but their values are often supplied from the processing program, rather than from the DD statement. So, when you code a DD statement to create a data set, you need to code only the DCB subparameters that arent specified in the program you are executing. Often, the program supplies all of the DCB information except block size, so youll need to specify BLKSIZE in the DD statements DCB parameter. Here are a few examples: DCB=(DSORG=PS,RECFM=F,LRECL=133) DCB=(DSORG=PO,RECFM=FB,LRECL=80,BLKSIZ E=800) DCB=BLKSIZE=3200 Sequential file with fixed-length 133-byte unblocked records Partitioned data set with fixed-length 80byte records in 800-byte blocks Block size is 3200 bytes; other information is supplied by the processing program Table 5.6 - Examples of the DCB parameter

Copyright 2004, Cognizant Academy, All Rights Reserved

25

JCL

The DD statement for in-stream data sets


As you know already, your program can also take input from in-stream data sets. The instream data set is in the form of an 80-byte record and your program treats the data as if it was a standard sequential file. Let us consider a situation, where you have written a report program that will produce a report of a customer master file based on the customer name given to it. As you will understand, there are atleast two input files, one is the customer master file and another file containing the name(s) of the customers for whom the report will be generated. Now instead of giving the list of customers name through a sequential file, you can enter the same customers name(s) in the JCL itself, with the help of an in-stream data: Figure 5.3 gives an example for a DD statement for coding in-stream data sets. //STP0100 //CUSTMAST // //NAMELIST ROBERT ASHOK DESAI ROSALINE JAMES MATHEW /* //RPTFILE // . . . DD DSN=TRG0001.REPORT, DISP=(, CATLG, DELETE), EXEC PGM=REPORT DD DD DSN=TRG0001.CUSTOMER.MAST.FILE, * DISP=SHR

Fig 5.3 - Example of a DD statement for coding in-stream data sets The above example shows a typical way of coding in-stream data sets. A DD * statement indicates that the records that follow are data for the in-stream data set. Notice that there is not data set name in the DD statement. After the DD * statement, the data is coded. Following the data, a delimiter statement (/*) marks the end of data. Actually, the delimiter statement is optional. If you omit it, the next JCL statement (// in columns 1 and 2) would indicate the end of the in-stream data set.

The DATA parameter


What happens when you want to code JCL statements (that have // as the first two characters) as part of in-stream data? As we discussed earlier, the next JCL statement would indicate the end of the in-stream data set. This is where the DD DATA statement comes in. Simply put, if you specify DATA instead of an asterisk, you must code a delimiter statement to mark the end of your data. That way, JCL statement can be read as data. The following example shows how Copyright 2004, Cognizant Academy, All Rights Reserved 26

JCL

example shows how the DD DATA statement works. Figure 5.4 gives an example for the DATA statement. //SYSUT1 //STEP1 //DD1 /* DD DD DATA DSN=TRG0001.TEST, DISP=SHR

EXEC PGM=SAMPLE

Fig 5.4 - Example for the DD DATA statement

The DLM parameter


Consider a situation (although very rare) where you need to have /* as a part of the in-stream data. If you try to code it following the above example, it will not be possible, because, once MVS encounters /*, it decides to mark the end of data. However, you can do this with the help of the DATA, DLM (stands for Delimiter) parameter. The DLM parameter lets you to change the two-character code used to represent the delimiter statement. That is, you can set the delimiter to any two-character code other than /*. To illustrate, consider the following example as shown in Figure 5.5: //SYSIN DD DATA, DLM=$$

A0010100599CH45 A0010306324AB23/* B0123034CD/* $$ Fig 5.5 - Example for the DLM statement Here, we have set the delimiter to be $$ using the DLM parameter. So, even if MVS encounters /*, it does not treat that as the delimiter; instead it looks for $$.

The DD statement for SYSOUT data sets


You learnt earlier that JES lets a program produce SYSOUT data sets, which are collected in the JES spool space before they are actually printed. By coding the SYSOUT parameter on a DD statement, you indicate that a file is a SYSOUT data set and should be processed by the JES. The SYSOUT parameter also specifies the output class associated with the SYSOUT data set. For example, the DD statement: //REPORT DD SYSOUT=A

Specifies that the data set identified by the ddname REPORT is a JES SYSOUT file with output class A, which (depending on the installation) might be associated with any printer. If you code an asterisk instead of an output class in the SYSOUT parameter, the output class defaults to the class you specified in the MSGCLASS parameter of the JOB statement. That way, the SYSOUT data will be printed with the jobs message output.

Copyright 2004, Cognizant Academy, All Rights Reserved

27

JCL

//REPORT

DD SYSOUT=*

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

Test your Understanding


1). What does DISP=OLD denote? A. exclusive control of the dataset B. no exclusivity C. dataset can be extended D. None of the above 2). What is the function of DD DISP parameter? A. Tells the system what to do with the dataset following normal termination of the step B. Describes the status of the dataset C. Tells the system what to do with the dataset following abnormal termination of the step D. All of the above

Answer: 1). A 2). D

Copyright 2004, Cognizant Academy, All Rights Reserved

28

JCL

Chapter 6: Special JCL statements and Data sets


Learning Objectives
The chapter shall achieve the following objectives: Understanding of special JCL statements Understanding the JOBLIB and STEPLIB statements

The null statement


The null statement consists of slashes in columns 1 and 2 and no other data in the rest of the record. The purpose of a null statement is to mark the end of a job. However, it is not required as MVS, by default, processes your JCL till the last record and then terminates.

The comment statement


You can use comment statement to place comments in your job. They can be helpful to clarify a confusing JCL statement or just to identify the purpose and operation of a job. Comment statement begin with two slashes and an asterisk starting in column 1, like this: //* THIS IS A COMMENT

DUMMY data sets


A dummy data set is a data set that doesnt really exist; MVS simulates the data set. By using a dummy data set, you can execute a program that processes a file without actually having the file present. When you use a dummy file, MVS simulates all of the housekeeping tasks associated with file processing; but no data is transferred to or from the file. When a program tries to read a record from a dummy file, MVS indicates an end-of-file condition. And when a program writes a record to a dummy file, the data is discarded. To understand the value of dummy data sets, consider a report preparation program, that reads the records of a master file and produces five reports, each written to a different output data set. Sometimes, you may need to run that program to get just one of the five reports. To do that, you just specify DUMMY for the four output data sets that you dont need. There are two ways you can specify a dummy file on a DD statement: you can code the DUMMY parameter, or you can specify DSNAME=NULLFILE (or DSN=NULLFILE). //SYSIN //CUSTMAST DD DD DUMMY DSN=NULLFILE

Temporary data sets


Many jobs require data sets that exist only for the duration of the job or a job step. To illustrate, consider a report-preparation job that requires two steps. The first step sorts a master file into the sequence required by the actual report program, storing the sorted records into a new file. Then, the second step reads this sorted file, produces the report and also deletes the sorted file. Copyright 2004, Cognizant Academy, All Rights Reserved 29

JCL

To process these kind of files, MVS provides a special kind of data set, called a temporary data set, that simplifies the coding requirements for this kind of processing. Temporary data sets are always deleted at the end of a job, unless you explicitly delete them sooner by specifying DELETE in the DISP parameter. How to use a single-step temporary data set To allocate a work file - that is, a temporary data set thats created and deleted in a single job step- you can code just a bare minimum of information on the DD statement. In fact, only two DD statement parameters are absolutely required for a work file: UNIT, which should specify a DASD device type like SYSDA, and SPACE. You can code DISP=(NEW, DELETE) to indicate that the data set is created and deleted in the same job step, but thats the default. And the DSNAME parameter is NOT required since no other DD statement will have to refer to the data set. Besides these, you may also need to include a DCB parameter to supply file characteristics such as block and record size if your program does not supply those. Examples: //WORK1 DD UNIT=SYSDA,SPACE=(CYL,(10,5))

Allocate a temporary data set on a SYSDA volume using 10 cylinders of primary and 5 cylinders of secondary space. DISP=(NEW,DELETE) is assumed. //WORK2 DD UNIT=SYSDA,SPACE=(CYL,(10,5)), // DCB=BLKSIZE=3200

Allocate a temporary data set on a SYSDA volume using 10 cylinders of primary and 5 cylinders of secondary space. DISP=(NEW,DELETE) is assumed. The block size is 3200 bytes. How to use a multi-step temporary data set If your temporary data set is to be processed by more than one step of a job, there are a few other coding details you need to know. Before that, there are two terms that you need to know: pass and receive. To pass a data set means to retain it to that a subsequent job step can process it. Passing a data set is like temporarily cataloging it. MVS retains the unit and volume information for passed data sets in virtual storage, so subsequent DD statements that receive the passed data set dont have to repeat that information. To receive a temporary data set means to use a temporary data set that was previously passed. To pass and receive a temporary data set, you must assign it a data set name that follows a specific format. In particular, the name can be no longer than eight characters; compound Copyright 2004, Cognizant Academy, All Rights Reserved 30

JCL

names joined by periods are not allowed. In addition, the name must be preceded by tow ampersands. Examples: &&TEMP and &&ACCOUNT The DISP parameter controls whether a temporary data set is passed so that it can be received by a subsequent job step or deleted when the current step completes. In the job step that creates the temporary data set, the DD statement should specify DSIP=(NEW, PASS). Then, in subsequent job steps that process the data set, the DD statement should specify DISP=(OLD, PASS). That way, the data set will be received and passed on to additional job steps that need the data set. In the last job step that processes the temporary data set, you should explicitly delete the file by specifying, DISP=(OLD, DELETE). However, even if you dont explicitly delete the temporary data set, MVS deletes it automatically when the job ends. //TRG0001 //STP0100 //SYSOUT //SORTIN // //SORTWK01 //SORTWK02 //SORTWK03 //SORTOUT // //SYSIN /* //STP0200 //SYSOUT //CUSTMAST //SYSUDUMP DD EXEC DD PGM=IEFBR14 SYSOUT=* SYSOUT=* DD JOB EXEC DD DD DISP=SHR DD DD DD DD * UNIT=SYSDA,SPACE=(TRK,(1,1) UNIT=SYSDA,SPACE=(TRK,(1,1) UNIT=SYSDA,SPACE=(TRK,(1,1) DSN=&&SORTCUST, MSGCLASS=X, CLASS=A PGM=SORT SYSOUT=* DSN=TRG0002.CUSTOMER.MASTER,

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

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

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

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

Concatenating data sets


Sometimes, you want to treat two or more input data sets as if they were a single data set. To do that, you concatenate them. (The word, concatenate means to link or chain together.) Then, if the data sets are sequential input files, MVS processes the records in the concatenated data sets in the order in which you concatenate them. To concatenate files, you code the first DD statement just as you normally would. Then, you code the next DD statement directly after it, but you dont code a DD name for it. Example:

Copyright 2004, Cognizant Academy, All Rights Reserved

31

JCL

//TRANS DD DSNAME=TRG0001.TRANS.WEEK1,DISP=SHR // // DD DSNAME=TRG0001.TRANS.WEEK2,DISP=SHR DD DSNAME=TRG0001.TRANS.WEEK3,DISP=SHR

Private program libraries - JOBLIB and STEPLIB When an EXEC statement with the PGM parameter is executed, MVS searches a series of system libraries to find the program you specify. This includes, among others, the system program library, SYS1.LINKLIB Sometimes you need to execute a program that exists in your private library. To do that, you code a DD statement in your job stream to identify a private library that is searched before the system libraries are searched. You can specify your private library as a job library or as a step library. A job library applies though out the job, that is, for all programs executed in the job, whereas a step library is searched only for the step to which it applies. To specify a job library, you code a DD statement using JOBLIB as the ddname. The JOBLIB DD statement must be the first JCL statement following the JOB statement for the job; JES2 and JES3 statements can be placed between the JOB and the JOBLIB statement, but other JCL statements cant. The following example will help you understand better. //TRG0006F JOB CLASS=B,USER=TRG0006 //JOBLIB DD DSN=TRG0006.SAMPLE.LOADLIB,DISP=SHR //STEP1 . . . //STEP2 DD EXEC PGM=REPORT DD EXEC PGM=IEBGENER

When a job library is in effect, MVS searches it first to locate any programs specified in the EXEC statements. If a program is not found in the job library, the system libraries are then searched. In the above example, the load modules of the programs IEBGENER and REPORT are searched in the library TRG0006.SAMPLE.LOADLIB; if not found, MVS searches the system libraries. To specify a step library, you code a DD statement named STEPLIB after the EXEC statement for the step in which you want the step library to apply.

Copyright 2004, Cognizant Academy, All Rights Reserved

32

JCL

//TRG0006F JOB CLASS=B,USER=TRG0006 //STEP1 DD EXEC PGM=IEBGENER . . . //STEP2 DD EXEC PGM=REPORT //STEPLIB DD DSN=TRG0006.SAMPLE.LOADLIB,DISP=SHR . . . In the above example, the load module of the program IEBGENER is searched in the system libraries only (as there is no JOBLIB or STEPLIB) and REPORT is searched in the library mentioned against the STEPLIB ddname and if not found, the system libraries are searched. If you include both a JOBLIB and a STEPLIB DD statement, they step library is searched before the system libraries; the job library is ignored for the job step.

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

Test your Understanding

1). JOBLIB should be specified A. Anywhere in the JCL B. Before JOB statement C. As the first JCL statement following the JOB statement D. After STEPLIB 2). What is the function of the STEPLIB DD statement? A. Identify a library to be searched for programs named in the EXEC statement B. Identify a library containing executable job steps C. Override the system step library within a job stream D. All of the above Answer: 1). C 2). D

Copyright 2004, Cognizant Academy, All Rights Reserved

33

JCL

Chapter 7: JCL Procedure


Learning Objectives
The chapter shall achieve the following objectives: To understand the types of procedures in JCL

JCL Procedure
Simply put, a JCL Procedure is a pre-written segment of code that you can include in a job stream. By using procedures, the amount of JCL coding you have to do is reduced. To illustrate, consider the following piece of JCL. //STP0100 //SYSOUT EXEC PGM=INV3010 DD SYSOUT=*

//INVMAST DD DSN=TRG0001.INVENTRY.MASTER,DISP=SHR //INVSEL // //SELCTL //STP0200 //SYSOUT //INVMAST //INVSLST DD DD DD DD DD DD DSN=&&INVSEL,DISP=(NEW,PASS), UNIT=SYSDA,SPACE=(CYL,(20,10)) DUMMY PGM=INV3020 SYSOUT=* DSN=&&INVSEL,DISP=(OLD,DELETE) SYSOUT=*

Here, two programs are invoked: INV3010 and INV3020. Suppose that these two programs are required by many jobs throughout an application. Rather than duplicate this code in each job, you could place the code in a procedure thats invoked by each job that needs to execute the programs. That way, you reduce coding and the chance for errors.

Invoking a procedure
You invoke a procedure by specifying its name in an EXEC statement. In that respect, invoking a procedure is much like invoking a program. //STEP1 EXEC PROC=INV3000 In the above example, the procedure INV3000 is invoked. Note that PROC is a keyword and is optional. //STEP1 EXEC INV3000 An important point to realize is that even though you invoke a procedure with a single EXEC statement, the invoked procedure may contain more than one EXEC statement. In other words, by invoking a procedure, you can indirectly invoke more than one job step with a single Copyright 2004, Cognizant Academy, All Rights Reserved 34

JCL

EXEC statement. The EXEC statements within a procedure, however, must all invoke programs. You cannot invoke an in-stream procedure from another in-stream procedure.

Cataloged and in-stream procedures


There are two types of procedures: cataloged and in-stream. A cataloged procedure is stored in a partitioned data set and may be invoked by any job on the system. In contrast, the statements of an in-stream procedure appear in the job that invokes the procedure. An instream procedure is available only to the job that contains it; other jobs on the system cannot invoke it. Most JCL procedures are cataloged so that they can be invoked by any job that needs them. In-stream procedures are used mostly used for testing procedures.

Code a job that uses an in-stream procedure


Let us take the previously mentioned JCL piece as an example and see how we can code it as an in-stream procedure. An in-stream procedure consists of a PROC statement, followed the JCL for the procedure, followed by a PEND statement You place the in-stream procedure definition (that is, the PROC statement, the procedures JCL statements, and the PEND statement) near the beginning of your job stream, before any EXEC statement that refers to it. When the reader/interpreter encounters a PROC statement, it treats the statements that follow as procedure statements; they are not executed, but instead, are scanned for syntax errors and retained as a temporary procedure. When the PEND statement is encountered, the reader/interpreter returns to its normal processing, and the JCL statements that follow the in-stream procedure definition are interpreted as normal JCL. To understand, look at the code below: //TRG0001X //INV3000 //STP0100 //SYSOUT //INVMAST //INVSEL // //SELCTL //STP0200 //SYSOUT //INVMAST //INVSLST // //STEPA1 DD DD DD DD DD PEND EXEC INV3000 <-----------------Invoking the procedure INV3000 JOB PROC EXEC PGM=INV3010 DD DD DD SYSOUT=* DSN=TRG0001.INVENTRY.MASTER,DISP=SHR DSN=&&INVSEL,DISP=(NEW,PASS), UNIT=SYSDA,SPACE=(CYL,(20,10)) DUMMY PGM=INV3020,COND=(0,LT) SYSOUT=* DSN=&&INVSEL,DISP=(OLD,DELETE) SYSOUT=* USER=TRG0001X,CLASS=S,NOTIFY=TRG0001X

The first statement after the JOB statement is a PROC statement that marks the beginning of an in-stream procedure named INV3000. Similar to the job name, DD name and the step name, a PROC also requires a name. Here we have INV3000 as the in-stream procedure name. After the PROC statement are the JCL statements that make up the procedure. Then, to mark the end of the procedure, you code the PEND statement. Following the PEND statement, there is an EXEC statement, which invokes the INV3000 procedure. Copyright 2004, Cognizant Academy, All Rights Reserved 35

JCL

As discussed earlier, the EXEC statement between the PROC and PEND statements are not executed when they are first encountered in the job stream. Instead, those statements are saved as a procedure so they can be processed later. Then when STEPA1 EXEC statement is processed, the two job steps in the in-stream procedure are executed: first INV3010, then INV3020.

Code a job that uses a cataloged procedure


Suppose you want to use the above-mentioned JCL piece as a cataloged procedure, this is what you need to do. Store all the statements starting from the procedure name (INV3000) till the last statement of the last step (that is, till the statement just before the PEND statement) as a member of a partitioned data set. A cataloged procedure should never contain a PEND statement. The PEND statement is used only in an in-stream procedure to mark the end of the procedure statements. Also, the PROC statement is optional in a cataloged procedure, but it is a good practice to code it. Another point to be remembered is that the name of the member of the PDS should be same as the procedure name (here, it is INV3000.)

The JCLLIB statement


Now that we have stored the cataloged procedure in a partitioned data set, we should tell the JCL that is invoking the procedure, the location of this cataloged procedure. That is, we should give the name of the partitioned data set to MVS and ask it to look for the procedure in the PDS. This is done with the help of the JCLLIB statement. The format of the JCLLIB is given below in Figure 7.1 : //name JCLLIB ORDER=(pds-1, pds-2) Fig 7.1 - Format of the JCLLIB statement You code the JCLLIB statement after the JOB statement and before the first EXEC statement. On it, you list the data set name of your private procedure library. If you want, you can list more than one procedure library; when you do so, MVS always searches the libraries in the order in which you list them. And when listing more than one procedure library, always enclose them in parentheses. Also, note that there is a system library, SYS1.PROCLIB, which contains mostly systemoriented procedures. This library is always searched, after your job searches the libraries mentioned in the JCLLIB statement. To illustrate the use of JCLLIB statement, here are a few examples: Example 1 //XYZ Example 2 //PRCLIBR JCLLIB ORDER=(TRG0001.TESTPROC,TRG0001.PROCLIB) TRG0001.TESTPROC is searched followed by TRG0001.PROCLIB followed by the system library SYS1.PROCLIB Copyright 2004, Cognizant Academy, All Rights Reserved 36 JCLLIB ORDER=TRG0001.PROCLIB TRG0001.PROCLIB is searched followed by SYS1.PROCLIB

JCL

SUMMARY
A JCL Procedure is a pre-written segment of code that you can include in a job stream. By using procedures, the amount of JCL coding you have to do is reduced. There are two types of procedures: cataloged and in-stream A catalogued procedure is stored in a partitioned data set and may be invoked by any job on the system The statements of an in-stream procedure appear in the job that invokes the procedure

Test your Understanding


1). Which statement identifies a library from which the Cataloged procedures are to be retrieved A. JOBLIB B. STEPLIB C. PROCLIB D. JCLLIB 2). What statement marks the end of an in-stream or Catalogued procedure ? A. STREAM B. SET C. PROC D. PEND Answer: 1) B 2) D

Copyright 2004, Cognizant Academy, All Rights Reserved

37

JCL

Chapter 8: Modifying a Procedures statements Overrides


Learning Objective
The chapter shall achieve the following objectives: To modify the procedures using override

Introduction
Frankly, procedures wouldnt be very useful if they provided the same JCL statements every time you invoked them. The biggest benefit of procedures is that you can make minor adjustments to the JCL they contain to meet varying processing needs. There are several ways to do that. Right now, we will see how to code JCL statements that change or supplement the JCL statements contained in a procedure. Later, we will see how to code more generalized procedures that use symbolic parameters. There are three ways you can modify parameters of a procedure that you are invoking. First, you can modify parameters coded on EXEC statements within the procedure. Second, you can modify parameters coded on DD statements within the procedure. And third, you can add entirely new DD statements within the procedure. Note that all these modifications hold good for both in-stream as well as cataloged procedures

Modify EXEC statement parameters


To change a parameter that is coded on an EXEC statement within a procedure or to add a parameter to one of the procedures EXEC statements, you code a parameter override on the EXEC statement that invokes the procedure. The format of a parameter override is this as shown in Figure 8.1. Parameter.procstepname=value Fig 8.1 - Format of a parameter override To illustrate, consider the procedure INV3000. Let us say we want to change the COND parameter of STP0200 in the procedure to something like COND(4,LT). We do this when we invoke the procedure as: //STEP1 EXEC INV3000, COND.STP0200=(4,LT)

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

Modify DD statement parameters


You can also change DD statement parameters that are coded in a procedure or add parameters to a DD statement. To do that, you code a DD statement following the invoking EXEC statement in this format:

Copyright 2004, Cognizant Academy, All Rights Reserved

38

JCL

//procname.ddname DD parameter=value

Fig 8.2 - Format of a DD statement modification Then, the parameter values you specify are used on the DD statement in the procedure. For example, if you code the statements //STEPA EXEC INV3000 DD SYSOUT=C

//INV3010.SYSOUT

The SYSOUT class for the SYSOUT DD statement is the INV3010 step is changed to C. When you code an override DD statement, you dont have to override every parameter thats specified in the procedure DD statement. For example, if you code the override DD statement. //INV3010.INVSEL DD SPACE=(CYL,(30,10)) Only the SPACE parameter of the INVSEL data set is changed. The other parameters are used as they are coded in the procedure.

Adding a DD statement
Sometimes, youll need to add a DD statement to a procedure that you are invoking. There are two cases where thats likely. The first is when a procedure is invoked repeatedly using a different input or output file each time. In a case like this, the file may just be omitted from the procedure, so you have to code a DD statement for it each time you invoke the procedure. The second case is when a procedure requires in-stream data. In-stream data sets arent allowed within procedures, so you have to provide them in the invoking JCL. To add a DD statement to a procedure, all you do is code the DD statement following the EXEC statement that invokes the procedure. For example, suppose you have not coded the DD name, INVMAST in the procedure. Since, the program INV3010 needs the file, INVMAST for execution, let us code it in the JCL that executes the procedure INV3000. The statements would be like this: //STEPA EXEC INV3000 DD

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

SUMMARY
There are three ways in which the parameters of a procedure that is being invoked can be modified Parameters coded on EXEC statements within the procedure can be modified Parameters coded on DD statements within the procedure can be modified The new DD statements within the procedure can be added entirely

Copyright 2004, Cognizant Academy, All Rights Reserved

39

JCL

Chapter 9: Symbolic parameters


Learning Objective
The chapter shall achieve the following objective: Using Symbolic Procedures for creating procedures for generalised use

Introduction
Although the facilities for modifying procedures that we have discussed so far are flexible, they can be awkward to use. A better way to create procedures for generalized use is to provide symbolic parameters.

Symbolic parameters
Symbolic parameters are very much like program variables. You need to substitute them with values when you invoke the procedures.

Code symbolic parameters


To code a symbolic parameter in a procedure, you code an ampersand (&) followed by a oneto-seven character name. For example, &FILENAM and &SPACE are valid symbolic parameters. In a procedure, you can code the symbolic parameter anywhere you code a JCL statement parameter or sub-parameter value. For example, you could code the DD statement SYSOUT parameter like this: SYSOUT=&CLASS Here, the value to the &CLASS symbolic parameter will be assigned when the procedure is executed. We will see how to do this soon. Also, you can use the same symbolic parameter in a procedure as many times as you wish.

Specify values for symbolic parameters


When you invoke a procedure, that uses symbolic parameters, you supply values for its symbolic parameters by coding them on the EXEC statement, like this: EXEC INV3000, CLASS=A Here, the &CLASS in the procedure statement is replaced by A, the value supplied for the &CLASS symbolic parameter. Notice that you do not include the ampersand in the symbolic parameter when you code the EXEC statement that invokes the procedure. If the value you are giving the symbolic parameter contains any special characters (like commas, asterisks, and so on), you enclose the entire value in apostrophes, like this: Copyright 2004, Cognizant Academy, All Rights Reserved 40

JCL

EXEC INV3000, CLASS=(,) Here, (,) becomes the value of the &CLASS symbolic parameter. To illustrate how symbolic parameters are used, see another version of the INV3000 procedure. Here, you can see that three symbolic parameters, &CLASS, &DEPT, and &SPACE, are used to make the procedure more generalized. Procedure //INV3000 //STP0100 //SYSOUT //INVMAST //INVSEL // //SELCTL //STP0200 //SYSOUT //INVMAST //INVSLST DD DD DD DD DD PROC EXEC PGM=INV3010 DD DD DD SYSOUT=&CLASS DSN=&FRSTNODE..INVENTRY.MASTER,DISP=SHR DSN=&&INVSEL,DISP=(NEW,PASS), UNIT=SYSDA,SPACE=(CYL,(&SPACE)) DUMMY PGM=INV3020,COND=(0,LT) SYSOUT=&CLASS DSN=&&INVSEL,DISP=(OLD,DELETE) SYSOUT=*

Invoking EXEC statement //STEPA1 SPACE=5,1 EXEC INV3000, CLASS=M, DEPT=TRG0001,

Notice that there are two periods following the symbolic &FRSTNODE. You understand the reason behind this; you need to understand the rules MVS follows when it substitutes symbolic parameter values. In some situations, those rules can be confusing.

Symbolic parameter values


To illustrate how symbolic parameter values are used in a procedures JCL statements, the following table shows seven examples. In each example, assume that VAR1 and VAR2 are the two symbolic parameters and the procedure was invoked with this EXEC statement: // EXEC proc-name, VAR1=TEST, VAR2=LIST

As you would infer, the value of &VAR1 is TEST and the value of &VAR2 is LIST Example # 1 2 As coded in procedure DSNAME=&VAR1 DSNAME=A&VAR1 As interpreted by MVS DSNAME=TEST DSNAME=ATEST 41

Copyright 2004, Cognizant Academy, All Rights Reserved

JCL

Example # 3 4 5 6 7

As coded in procedure DSNAME=&VAR1(&VAR2) DSNAME=&VAR1.A DSNAME=&VAR1..A DSNAME=&VAR1&VAR2 DSNAME=&VAR1..&VAR2

As interpreted by MVS DSNAME=TEST(LIST) DSNAME=TESTA DSNAME=TEST.A DSNAME=TESTLIST DSNAME=TEST.LIST

Table 9.1 - Examples to illustrate how symbolics are interpreted by the JCL Example 1 from Table 9.1 shows a simple case; here, the value of &VAR1 symbolic parameter is used as the value for the DSNAME parameter. So, TEST is used as the data set name. Example 2 illustrates that a symbolic parameter can be mixed with other text to form the final parameter value. Here, the letter A is combined with the symbolic parameters value to form the data set name ATEST. Adding text to the end of a symbolic parameter isnt a problem either as long as the text starts with a special character, as in example 3. Here, DSNAME=&VAR1(&VAR2) becomes DSNAME=TEST(LIST). Because the left parenthesis is a special character, no special coding is needed to distinguish it from the &VAR1 symbolic parameter name. Adding text after a symbolic parameter when the text begins with a letter or digit, however, is another matter. Thats because MVS cant separate the start of the text from the end of the symbolic parameter value. If you coded this: DSNAME=&VAR1A MVS would look for the symbolic parameter &VAR1A. To solve this problem, you must use a period as a delimiter between the symbolic parameter and the text, as in example 4. When the period is encountered in a symbolic parameter name, it marks the end of the parameter name and any text that follows it is added after the symbolic parameters value. The period itself is dropped out, so it doesnt become a part of the final JCL text. In example 4, &VAR1.A becomes TESTA Unfortunately, the use of a period as a delimiter creates the need for another rule: If you want the period to appear in the final JCL statement, you have to code two periods as in example 5. The first period is a delimiter that marks the end of the symbolic parameter name. The second period becomes a part of the data set name. So, &VAR1..A becomes TEST.A. Example 6 shows that you dont need to use a period to place two symbolic parameters back to back. Thats because the ampersand itself separates the two symbolic parameters. SO dsname=&VAR1&VAR2 becomes DSNAME=TESTLIST. You can use a period if you wish, but it is not necessary. So DSNAME=&VAR1.&VAR2 has the same result as example 6. If you want the period to remain between the two symbolic parameters, you must again code two periods, as in example 7. Here, &VAR1..&VAR2 becomes TEST.LIST

Copyright 2004, Cognizant Academy, All Rights Reserved

42

JCL

Assign default values to symbolic parameters


So far, we have seen how to assign values to symbolic parameters when you invoke a procedure. For most procedures you will code, many of the symbolic parameters will have certain values that are used most of the time. For example, it is safe to assume that the &CLASS symbolic parameter in the previous example will be set to * most of the time, so that the SYSOUT data sets will have the same output class as the jobs message output. Rather than force the programmer to specify CLASS=* each time the procedure is invoked, you can provide a procedures PROC statement. Then, if the programmer doesnt code CLASS on the EXEC statement, the default value (*) will be used. The following code shows a version of the INV3000 procedure that supplies default values for the &CLASS and &SPACE parameters. Note that no default value has been supplied for &DEPT, so DEPT must always be coded on the EXEC statement that invokes the procedure. Also, note that the value for &SPACE is specified in the EXEC statement, so this overrides the default for &SPACE. Procedure //INV3000 //STP0100 //SYSOUT PROC CLASS=*,SPACE=1,1 EXEC PGM=INV3010 DD SYSOUT=&CLASS

//INVMAST DD DSN=&FRSTNODE..INVENTRY.MASTER,DISP=SHR //INVSEL // //SELCTL //STP0200 //SYSOUT //INVMAST //INVSLST DD DD DD DD DD DD DSN=&&INVSEL,DISP=(NEW,PASS), UNIT=SYSDA,SPACE=(CYL,(&SPACE)) DUMMY PGM=INV3020 SYSOUT=&CLASS DSN=&&INVSEL,DISP=(OLD,DELETE) SYSOUT=&CLASS

Invoking EXEC statement //STEPA1 Effective JCL //STP0100 //SYSOUT //INVMAST //INVSEL // //SELCTL //STP0200 //SYSOUT //INVMAST //INVSLST DD DD DD DD DD EXEC PGM=INV3010 DD DD DD SYSOUT=* DSN=TRG0001.INVENTRY.MASTER,DISP=SHR DSN=&&INVSEL,DISP=(NEW,PASS), UNIT=SYSDA,SPACE=(CYL,(10,5)) DUMMY PGM=INV3020,COND=(0,LT) SYSOUT=* DSN=&&INVSEL, DISP=(OLD,DELETE) SYSOUT=* EXEC INV3000,FRSTNODE=TRG0001,SPACE=10,5

Copyright 2004, Cognizant Academy, All Rights Reserved

43

JCL

SUMMARY
Symbolic parameters are very much like program variables When you invoke a procedure, that uses symbolic parameters, you supply values for its symbolic parameters by coding them on the EXEC statement

Test your Understanding


1). What is the prefix character for symbolic parameter? A. % B. & C. @ D. {}

Answers: 1). B

Copyright 2004, Cognizant Academy, All Rights Reserved

44

JCL

REFERENCES

WEBSITES
http://www.isc.ucsb.edu/tsg/jcl.html

BOOKS
The MVS/JCL Primer by Saba Zamier / Ranade JCL programming Bible by Gary D Brown

Copyright 2004, Cognizant Academy, All Rights Reserved

45

JCL

STUDENT NOTES:

Copyright 2004, Cognizant Academy, All Rights Reserved

46

Potrebbero piacerti anche