Learning about JCL (SYSIN) jobs

BARR/SPOOL

SYSIN jobs can only be routed to NJE or RJE devices. A SYSIN job can be thought of as a batch process. It is important to realize that jobs consist not only of raw data, but also of JCL Acronym for Job Control Language. A command language used in IBM OS/360 mainframe systems. statements and other programming language statements. These statements tell JES Acronym for Job Entry Subsystems of the IBM MVS operating system. These subsystems are used for entering jobs into the MVS operating system and dispensing the output from the jobs. how to handle the job when it gets to the mainframe.

When SYSIN jobs are added to the Spool Window, they appear shaded in a light blue background.

• Introduction

• Sample job

• Embedded commands

What do you want to do?

• Send files (JCL SYSIN) to the RJE host

• Send files (JCL SYSIN) to the NJE host

• Send JCL files with an embedded command

See also:

• Choosing ports and device drivers

Introduction

JCL consists of statements that direct the computer system in the handling of programs submitted for processing. JCL specifies work to be completed, methods to be used, and resources to be allocated (including input and output requirements).

A typical JCL statement consists of slashes (//) in columns one and two followed by four fields: name, operation, operands, and comments.

All letters in JCL statements must be uppercase letters.

A JCL statement takes the following form:

Name – Identifies a JCL statement, giving it a name, and thus allowing other statements to refer to it. The name in this field consists of 1-8 alphanumeric (A-Z, 0-9) or national (@, #, $) characters. The first character must be alphabetic or national. The name field begins in column 3 and is followed by one or more spaces to separate it from the operation field.

Operation – Specifies the type of the JCL statement (JOB, EXEC, DD). The operation field is preceded and followed by one or more spaces.

Operands – Contains parameters that may be assigned different values according to job requirements. Parameters in this field must be separated by commas and must not contain intervening spaces. The operand field must be preceded by one or more spaces.

Comments – Documents the JCL and contains any information. Comments must be preceded by one or more spaces.

With the exception of the JCL comment statement, no JCL statements may extend beyond column 71. Statements can be continued on subsequent lines by following these steps:

1. End the statement after a comma (that is, at the end of a parameter) before column 72.

2. Place slashes in the first two columns of the second line.

3. Skip at least one space after the slashes.

4. Continue with the statement at any position before column 16.

For example, the following two lines of JCL represent one JOB statement that has been continued on a second line:

Sample job

The following is a sample JCL job.

JCL is highly column-oriented, so spacing is important. Any terms that fall into the first column are user-defined terms and will only be recognized as such. Keywords such as EXEC (execute) and JOB never appear in the first column, because they will be treated as user-defined terms and not be recognized by the system.

Line 1 (JOB statement)

The JOB statement, the first statement of any job, is processed first. It introduces new jobs to the system, provides information for checking user authorization, and defines the characteristics of resources to be used. The first word to appear in the first column is the job name (CHECKS). The keyword JOB, which denotes that this is the JOB statement, always follows the job name. There must be only one JOB statement in each batch job. Two slashes (//) must appear in the first two columns of the JOB statement and must be in columns 1 and 2. MSGCLASS specifies the output class to which output from the job is to be written. In this case, A indicates output is to be written to the printer.

Lines 2-4 (Comments)

After the JOB statement, it is not uncommon for the JCL programmer to include comments. The comment statement specifies comments to be included in the output listing.

The comment statement must begin with a slash in the first column, a slash in the second column, and an asterisk in column three (//*). Comments can be entered beginning in column four (a blank comment statement can be coded simply as //*).

A comment statement cannot be continued as other JCL statements. If all comments cannot be coded on one line, additional comment statements must be used.

Lines 5-10 (Programming language statements)

The programming language statements denote two important pieces of information:

• Which program will execute to process the data

• What input and output variables the program will need to execute

Line 5

The EXEC statement denotes which program will be executed to process the data. If there is only one process taking place, then the step number can be omitted and just the EXEC statement can be used, as shown in the sample job. If there are a number of Job Steps (programs that will execute), numbered Step Cards will be used (for example, //STEP1 EXEC SCRIPT).

Line 6

The DD statements describe the location and characteristics of files being input to and output from the job. Each input and output file must be described by a DD statement.

On line 6, there is a SYSPRINT designation. This refers to the log file JES outputs every time a job is run. Depending on the class assignment here, you can receive, hold, or discard the log file generated by JES. In the example, the JES log will be routed to a dummy class and then purged by the host.

Class conventions are explained in the following table.

These are just class conventions. Host programmers can customize their classes to designate anything they want.

Line 7

The DUMMY designation indicates that no input/output devices are to be assigned to the file and no input/output operations are to be performed.

Line 8

The SYSUT2 statement assigns an output class, program, and form to an output data set. In the example, the output class is S, the program is not specified, and the form is CHKS. A program usually isn't specified and is defined by another source such as JES. The statement is also used to set the number of copies and route the data set to a specific destination.

Line 9

The DEST statement tells JES where to route the output generated for this job. The output can be printed or stored on tape or disk. In the example above, the destination is a XEROX printer (BAR1TN06,XEROX). If there is no DEST specification, the job returns to the remote.

The DEST statement is not needed for BARR/RJE.

Line 10

DD * always denotes that the information following the statement will be read in as data. This means that DD * is always an input variable.

Lines 11-15 (Data)

The lines immediately following the DD * statement and immediately preceding the /* statement indicate that data is present. Data can appear on these lines or an embedded command can be used.

Line 16

Before another Job Step can begin, JES will look for a matching /* statement in columns 1 and 2, which indicates the end of the data in the job stream.

Embedded commands

Sending jobs to the host can be simplified by reusing commonly used JCLs, and separating the data files from the JCLs. You can embed send commands in the JCL. The embedded send files command is the double number sign (##). The Barr software treats the text specified after the ## as if you submitted another file to the spool. You can specify more than one ## statement on a single line (separated by a single space) or on multiple lines; however, the JCL file cannot include any other data. If any of the included files are missing, then no data will be sent.

See the Sending JCL files with an embedded command topic for more information.

In the following example, we have used the ## statement in the CHECKS.JCL to include the data file CHECKS.DAT.

CHECKS.JCL

CHECKS.DAT