Mainframes 360
The one stop destination for System Z professionals

Tuesday, March 11, 2014

How to code the JOB Statement

How a job is entered into the system

In the early days of System 360-370, JCL statements, programs, data were stored on punched cards and tape media. Entering a job into the system meant placing the deck of cards on a hopper and pressing the start button, to start feeding them through a card reader. The card reader received a stream(series) of electronic signals, representing the holes in the punched card. Today, a programmer enters JCL code and data on a terminal and the resulting job stream is saved into a file on DASD. However, the job hasn't entered into the system yet, as JES2 doesn't know about it.

When the programmer issues a SUBMIT command, JES aka Job Entry Subsystem reads the input JCL stream and places it into a staging area - the input queue or JES spool. Its like a large waiting room at an airport or a bus station from where jobs leave en masse. JES then invokes an interpreter. The interpreter's job is to analyze the JCL statements and convert them into an internal representation - build a series of control blocks in the Scheduler Work Area(SWA). If there are syntax errors, the faulty JCL is flushed to the output queue. The SWA control blocks amongst other things describe all the datasets a JCL needs.

How a job is scheduled for execution

A programmer codes the job CLASS in JCL code. Jobs with similar characteristics should have the same CLASS. Typically, every installation sets up categories or job classes, for instance CLASS=A for small jobs, CLASS=G for long-running jobs, CLASS=T for tape jobs.

A special type of a program called an initiator picks up jobs for execution from JES spool. The initiator is like a nanny that selects a job from the JES spool, executes the job in its address space and returns to the JES spool for another job. Every initiator has a class list. In a hypothetical system, say there are three initiators - INIT1 A, INIT2 B,C,D, INIT3 B,C. An initiator selects jobs from only those classes which are on its class list. Every initiator can run only one program at a time. In the example, only one CLASS=A can run at a time. Two CLASS-B jobs can run at a time. The installation can control the number of initiators(JES managed).

The initiator goes through three phrases - allocation, execution and unallocation. First, it invokes allocation routines that analyze the SWA control blocks to see what resources(volumes, datasets) the job step needs and they're allocated. Next, the initiator creates a user region where the user-program can execute and loads the program into the region and transfers control to it. When the program completes, the initiator invokes the unallocation routines to release any resources.

As the program executes, it can produce output data that needs to be held in JES spool and printed later. This is called SYSOUT dataset. Three other SYSOUT datasets are produced - JES output messages, a JCL listing and a system message log that lists any messages issued by zOS as the job executed. These SYSOUT datasets are brought to the output queue in the JES spool.

Like jobs, SYSOUT datasets are each assigned an output class. Output classes usually indicate the printer or printers to which the output is sent. Sometimes, an output class MSGCLASS=H may however specify that output is not to be printed. Instead, it is held in the output queue, until it is purged.

Fig. How a job is executed on z/OS

How to code the JOB statement

The JOB statement has three basic functions. First, it identifies the job to z/OS by supplying a job name. Second, it supplies accounting information and programmer details, so that zOS knows who is responsible for the job and if necessary, must be charged for the computer resources used. Third, it supplies various limits that influence the job execution.

Of all the JCL statements, the JOB statement is the one whose format varies the most from one installation to another. You then tailor the JOB statement accordingly. The basic syntax of the JOB statement is : The JOB statement must always be the first statement in the JCL. Comments before a JOB statement too are invalid!

The job name

The name or label coded on the JOB statement from columns three to ten is the job name. Like, IBMUSERA is the job name. The zOS uses the job name to identify your job. If two or more active jobs have the same name, the job identifier(the job-id or job number) is used to distinguish them. The system assigns a unique job id to every job.

When submitting a job through TSO/ISPF, it is good to have a job-name that has the TSO userid suffixed by one or two alphanumeric characters. The examples here assume a TSO userid IBMUSER. Then, I'd code a job name like IBMUSERA or IBMUSER1. There are a couple of rules to keep in mind. Job names are strings of length 1-8 and can have alphanumeric(A-Z,0-9) characters and national symbols(@,#,$). The first character must be an alphabet or a national symbol. Some valid job names are :

The accounting information parameter

In the early days of the mainframe, programmers were billed(charged) for computer-time that they used on a mainframe. Accounting information supplies the account number to which to bill the CPU time utilized. This parameter varies from installation to installation. In the example, A123 is the account number to which the job's processing time will be billed. In the example, SHELDON COOPER is the additional accounting information. The leading comma indicates the absence of the account number. This example has both the account number and the additional account details. You can submit this JCL on the z/OS and see the output.

The labelling or routing information

The zOS prints several messages to the job log during execution. When the job output is printed, each of the "separator-pages" will be labelled with the user-specified value. This will allow the personnel to physically separate your output from the output of other jobs at the printer. At one shop, they had 100 "bins" for the print output. The label 'BIN-7 QUASAR' informs zOS print 'BIN-7 QUASAR' on each of the separator pages. The personnel operating the printer would put my output in bin# 7.

The CLASS parameter

The CLASS parameter is used to categorize the job. At a mainframe shop, the system programmers setup these categories. For instance, you might have CLASS=A for small jobs, CLASS=G for medium jobs, and CLASS=R for long-running jobs. This helps z/OS pick up jobs for execution. The below JCL shows how the CLASS parameter can be coded.

The MSGCLASS parameter

As your program runs, it can produce SYSOUT datasets. Other SYSOUT datasets containing z/OS system messages, JCL listing and JES messages are produced. The MSGCLASS parameter lets you specify an output class for your SYSOUT datasets. An installation may set up various output classes. For instance at my shop, MSGCLASS=X means that the output will be printed on a high-speed printer, MSGCLASS=H means that the output will be held in the JES spool.

The MSGLEVEL parameter

The MSGLEVEL=(stmt,msg) parameter lets you specify the what kind of JCL statements you want included in the output and which messages appear in the message log. stmt could be 0: print only the JOB statement, 1: print all the JCL statements and expanded procedure statements too or 2: print only JCL statements in the input stream, don't print statements in a PROC. msg could be 0: print only the step completion messages, supress the allocation and unallocation messages unless the job fails. A value 1 implies print all messages. If you omit the MSGLEVEL parameter, it defaults to MSGLEVEL=(1,1) that causes all JCL statements and messages to be included in the output.

The NOTIFY parameter

If you code the NOTIFY parameter on the JOB statement, you'll automatically notified when the job completes. NOTIFY parameter lets you specify a TSO user-id or the &SYSUID system symbol to be notified. If you code your user-id, you'll be notified whether or not you're submitting the job. If you code the &SYSUID system symbol, it is automatically replaced by the user-id of the submitter.

To many people who are thrown to work at a mainframe computer on their first job, they feel lost. Mainframe people seem to speak a completely different language and that doesn't make life easy. What's more, the books and manuals are incredibly hard to comprehend.

"What on earth is a Mainframe?" is an absolute beginner's guide to mainframe computers. We'll introduce you to the hardware and peripherals. We'll talk about the operating system, the software installed on a mainframe. We'll also talk about the different people who work on a mainframe. In a nutshell, we'll de-mystify the mainframe.

Readers based in India, can buy the e-book for Rs. 50 only or the print book. International readers based in the US and other countries can click here to purchase the e-book.