Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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
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
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
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
JCL
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.
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
JCL
You normally store the set of JCL statements for a job as a member of a partitioned data set.
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
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.
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
10
JCL
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]
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.
SUMMARY
Format of JCL statements
12
JCL
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.
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
JCL
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)
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
16
JCL
//stepname
EXEC
PGM=program-name
[,PARM=information] [,COND=([(code,operator,step)][,EVEN/ONLY])]
17
JCL
16
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
19
JCL
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.
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.
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.
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
JCL
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
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.
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
24
JCL
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
25
JCL
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.
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
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 $$.
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.
27
JCL
//REPORT
DD SYSOUT=*
SUMMARY
To describe the data sets that are used by the program, you code DD (Data Definition) statements
28
JCL
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)
31
JCL
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.
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.
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
33
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.
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.
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
37
JCL
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
Here, COND is the parameter and STP0200 is the step name of the procedure INV3000.
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
39
JCL
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.
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=*
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.
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
JCL
Example # 3 4 5 6 7
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
42
JCL
//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
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
Answers: 1). B
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
45
JCL
STUDENT NOTES:
46