Pages

Friday, September 22, 2017

Mainframe Batch Processing: What is Job Control Language (JCL)


Mainframe batch processing requires a job. Jobs are created using Job Control Language (JCL). What is in a JCL? How can you use it?

THIS ARTICLE COPYRIGHTED: HTTP://WWW.CONCEPTSOLUTIONSBC.COM. IF YOU CAN READ THIS TEXT, THE POSTER STOLE MY PROPERTY

Sample JCL


Windows and *NIX systems have batch files. These are files that can be initiated using a command line interface. The batch files for Windows and *NIX systems are actually scripts that can execute a sequence of programs and other commands.

z/OS Batch Processing


z/OS also has batch processing that can execute a sequence of programs. However, control for batch processing is different from Windows and *NIX. In z/OS, batch processing is done through jobs. A job is the smallest unit of work in z/OS . Anything that executes on z/OS needs a set of job control cards written in Job Control Language (JCL). JCL is a language because it has its own syntax. A set of job control statements is also called JCL.

During the z/OS start up (IPL) process, a master JCL is read to start processing. The master JCL specifies how the system interacts with the Job Entry Subsystem.

JCL is made up of control statements that are 80 bytes long. The 80 byte limit comes from the fact that in old mainframe systems, cards were used as inputs and these cards have 80 characters per record.

Jobs are identified by a job card. The job card indicates the start of a job. It contains the name of the job. Job names have a maximum of 8 alphabetic and numeric characters. The first character should be an alphabetic charactelr. All characters should be in upper case.


  1. Valid job names: 
    1. SAMPLE, TEST01, PYUSON01
  2. Invalid job names: 
    1. SAMPLE001 - more than 8 characters
    2. 01TEST - starts with a number
    3. PyUSON01 - lower case characters
THIS ARTICLE IS COPYRIGHTED. IF YOU CAN READ THIS, THE POSTER STOLE MY WORK

Sample JCL


To understand the discussions on disk files, you may want to check my previous article on how the mainframe disk file system works. Below is a sample JCL:


  1. //JOB001 JOB (12345),CLASS=A,PRTY=1
  2. //STEP01 EXEC PGM=IEFBR14
  3. //FILE1 DD DSN=SAMPLE.DATASET,DISP=(NEW,CATLG),
  4. //     SPACE=(TRK(1,2),RLSE),UNIT=DISK,
  5. //     DCB=(LRECL=80,BLKSIZE=1600,RECFM=FB) 


Notice that all lines begin with two slashes //. This indicates that the line is a JCL statement.


  1. Line 1 contains the job card. This is always the first line of a job.
    1. The name of the job is JOB001.
    2. The literal JOB identifies the start of the job statements.
    3. The (12345) is a sample accounting information. Since there could be many users running jobs on a mainframe, the resources their jobs use can be charged back to the users through this accounting information.
    4. CLASS specifies the class of the job. The class is either alphabetic or numeric
    5. PRTY specifies the priority of the job. The priority determines where this job is in relation to other jobs within the class.
  2. Line 2 identifies the step within the job.
    1. The name of the step is STEP01.
    2. The EXEC statement identifies that this is a step
    3. PGM= identifies the program to be executed for this step. In this case, the program is IEFBR14 (yes, this is a real z/OS program).
  3. Lines 3-5 identify the file to be used within the step. You can have several files within a step.
    1. Line 3 begins the definition for the file. FILE1 is called the Data Definition Name (DDNAME). This is the name the program uses for the file. In Windows and *NIX programs, one has to specify both the physical name of the file and a handle. In z/OS, the program only needs to know the handle. The physical file is handled in the JCL. Note the comma at the end of the line. It indicates that the line has a continuation.In the example, the physical name of the file is SAMPLE.DATASET. The physical name is also known as the data set name (DSN). Its disposition (DISP) is NEW, meaning this file does not exist. The next parameter CATLG is an interesting feature of z/OS. For Windows or *NIX systems, you will need to know which folder you saved a file. In z/OS, you can save that information onto a catalog. When a file is cataloged, you do not know where the file is saved. The next time you want to use the file, you just need to specify the data set name and z/OS will look at the catalog and find the file for you.
    2. Line 4 is a continuation of line 3 because line 3 has a comma and line 4 has a space after the // characters. specifies the SPACE allocation, in this case: SPACE=(TRK,(1,2),RLSE). For the example, 1 track is first allocated for the file as specified in the first number in the space parameter. The first allocation is called the primary allocation. If the one track is not sufficient, then z/OS will allocate 2 tracks, as specified in the second number in the SPACE parameter. This is the secondary allocation. A file is allowed 16 extents, meaning 1 primary allocation and 15 secondary allocations. In this case, the maximum track that can be allocated is 1 track (primary allocation) and 15 times 2 tracks (secondary allocation); making it 31 tracks.The UNIT=DISK parameter says the file is to be saved on DISK.
    3. Line 5 shows the Data Control Block (DCB) of the file. The DCB identifies the attributes of the file. In this case, the file has a logical record length (LRECL) of 80 bytes. It is physically saved in 1600 bytes per block (BLKSIZE) and the records are Fixed Block (FB). The LRECL is the size of the record read by the program.You need one DD statement for every file your program uses. If your program uses five files, you should have five DD statements. 
This is a very simple JCL and is quite often used in z/OS. As you can see, JCL is not a programming language. It defines the environment (ie. files, programs and conditions for execution of a program).


Submitting Jobs


Unlike Windows and *NIX systems, batch jobs are not executed from the command line. They need to be submitted to an internal reader. The internal reader checks the syntax of the JCL and returns a JCL error if any control statement has the wrong syntax.

When the JCL statements are correct, the job entry subsystem puts the job on an input queue for that class. The job sits in the queue until it is initiated.

To learn more about how a Job Entry Subsystem works, please check my article What does a Job Entry Subsystem (JES) do?.

Further Reading


If you want to learn more about JCL, you may download the MVS JCL Reference manual from the IBM website.

No comments:

Post a Comment

Total Pageviews