MainframeMaster

JCL Tutorial

JOB Statement Parameters

Progress0 of 0 lessons

Introduction

The JOB statement, the first statement in a JCL stream, identifies the job to the operating system. Besides the mandatory jobname, accounting information, and programmer name fields, it accepts numerous optional parameters that control the job's execution environment and behavior.

This tutorial covers some of the most commonly used JOB statement parameters.

jcl
1
//jobname JOB (acct),'programmer',CLASS=...,MSGCLASS=...,NOTIFY=...,...

CLASS=jobclass

Assigns the job to a specific job class (A-Z, 0-9). Job classes are defined by the installation to manage resource allocation and job scheduling priorities. Different classes might have different limits on CPU time, memory, or concurrent executions.

jcl
1
//PAYROLL JOB ...,CLASS=P,... // Production job class
jcl
1
//TESTJOB JOB ...,CLASS=T,... // Test job class

MSGCLASS=outputclass

Specifies the output class for job log messages (JESMSGLG, JESJCL, JESYSMSG). Output classes route messages to specific output devices or hold queues.

jcl
1
//MYJOB JOB ...,MSGCLASS=X,... // Route job log to class X
jcl
1
//BATCH JOB ...,MSGCLASS=H,... // Hold job log output

MSGLEVEL=(statements,messages)

Controls which JCL statements and system messages are printed in the job log.

  • statements: 0 (JOB statement only), 1 (all JCL, including procs), 2 (JOB statement and proc JCL only).
  • messages: 0 (allocation/termination messages only if job fails), 1 (all allocation/termination messages).
jcl
1
//DEBUG JOB ...,MSGLEVEL=(1,1),... // Print all JCL and messages
jcl
1
//PRODJOB JOB ...,MSGLEVEL=(0,0),... // Print minimal messages

NOTIFY=userid | &SYSUID

Specifies the user ID to receive notification messages upon job completion (or failure). Using the symbolic parameter &SYSUID sends the notification to the user who submitted the job.

jcl
1
//REPORT JOB ...,NOTIFY=&SYSUID,... // Notify submitting user
jcl
1
//ALERT JOB ...,NOTIFY=OPER1,... // Notify operator OPER1

COND=(condition) | ((condition),(condition),...)

Specifies conditions under which the entire job should NOT run, based on the return codes of previous jobs (if part of a job group) or potentially steps within the same job (less common on JOB statement). See separate COND parameter tutorial for details.

jcl
1
//STEP2 JOB ...,COND=(4,LT),... // Don't run if any prior step RC > 4

TIME=(minutes,seconds) | NOLIMIT | 1440

Specifies the maximum CPU time the job is allowed to consume. Exceeding this limit causes a S322 abend.

  • (minutes,seconds): Specific time limit (e.g., TIME=(5,30) for 5 min 30 sec).
  • NOLIMIT: No CPU time limit (requires specific authorization).
  • 1440: Equivalent to NOLIMIT (historical value).
jcl
1
//COMPUTE JOB ...,TIME=10,... // Limit to 10 minutes CPU time
jcl
1
//LONGJOB JOB ...,TIME=NOLIMIT,... // No CPU time limit

REGION=valueK | valueM | 0K | 0M

Specifies the amount of virtual storage (memory) the job requires. Can be specified in Kilobytes (K) or Megabytes (M). REGION=0K or REGION=0M typically requests all available storage below and above the 16MB line, respectively (subject to installation limits).

jcl
1
//BIGMEM JOB ...,REGION=64M,... // Request 64 Megabytes
jcl
1
//GETALL JOB ...,REGION=0M,... // Request maximum available memory

TYPRUN=SCAN | HOLD | JCLHOLD | COPY

Controls special job processing:

  • SCAN: Checks JCL syntax without executing the job.
  • HOLD: Places the job on the input queue in HOLD status, requiring operator release.
  • JCLHOLD: Similar to HOLD, but specific to JES2, holding before JCL conversion.
  • COPY: Copies the JCL input stream to a SYSOUT dataset without execution.
jcl
1
//CHECK JOB ...,TYPRUN=SCAN,... // Scan JCL for errors
jcl
1
//WAIT JOB ...,TYPRUN=HOLD,... // Hold job until released

USER=userid

Specifies the user ID under which the job should run for security validation (e.g., RACF checks). Often required in secure environments.

jcl
1
//SECURE JOB ...,USER=PAYROLL,...

PASSWORD=password | (read-password,write-password)

Specifies the password associated with the USER ID. Obsolete in modern systems using security managers like RACF. **Avoid using PASSWORD.**

jcl
1
//OLDJOB JOB ...,USER=LEGACY,PASSWORD=OLDPASS,... // Avoid this!

RESTART=stepname | stepname.procstepname | *

Requests an automatic restart of the job from a specific step if the job fails and is resubmitted. Useful for multi-step jobs.

  • stepname: Restart from this step in the job.
  • stepname.procstepname: Restart from a specific step within a procedure.
  • *: Restart from the beginning of the job (useful mainly for checkpoint restarts).
jcl
1
//UPDATE JOB ...,RESTART=STEP030,... // Restart from STEP030 if job fails
jcl
1
//PROCRUN JOB ...,RESTART=STEP010.PSTEP2,... // Restart from PSTEP2 within STEP010

Parameter Order and Defaults

Positional parameters (jobname, accounting, programmer name) must appear first and in order. Keyword parameters (CLASS, MSGCLASS, etc.) can appear in any order after the positional parameters.

If a parameter is omitted, the system uses installation-defined defaults. These defaults are set by system programmers in JES parameters or system exits.

JOB Parameter Exercises

Exercise 1: Basic Job Setup

Write a JOB statement for a job named `MYTEST`, with accounting info `(ACCT123)`, programmer name `'Test User'`, assigned to test class `T`, with message class `X`, notifying your user ID upon completion, and requesting maximum memory.

Exercise 2: Syntax Check

Modify the JOB statement from Exercise 1 to only perform a syntax scan (TYPRUN=SCAN) and print all JCL statements and allocation messages (MSGLEVEL).

Frequently Asked Questions

Can I override JOB parameters on the EXEC statement?

Some parameters like REGION and TIME can be coded on both JOB and EXEC statements. If specified on both, the EXEC statement value overrides the JOB statement value *for that specific step only*.

What determines the default CLASS or MSGCLASS if I don't code them?

Installation defaults set in the JES parameters (JES2 or JES3) determine the default job class and message class if they are not specified on the JOB statement.

Is REGION=0M always the best choice for memory?

Not necessarily. While REGION=0M requests the maximum available memory (subject to limits), it might lead to inefficient memory usage if the job doesn't actually need that much. It can also prevent other jobs from running if it hogs too much memory. It's often better to estimate the required region size or use installation standards.

Test Your Knowledge

1. Which parameter assigns a job to a scheduling category?

  • MSGCLASS
  • CLASS
  • REGION
  • TYPRUN

2. What does MSGLEVEL=(1,1) typically achieve?

  • Print only the JOB statement and error messages
  • Print no JCL or messages
  • Print all JCL statements and all allocation/termination messages
  • Print only allocation messages

3. Which TYPRUN value checks JCL syntax without running the job?

  • HOLD
  • COPY
  • JCLHOLD
  • SCAN

4. What does NOTIFY=&SYSUID do?

  • Sends a notification to the system operator
  • Sends a notification to the user ID specified in the USER parameter
  • Sends a notification to the user ID that submitted the job
  • Disables all notifications

5. Which parameter limits the total CPU time a job can use?

  • REGION
  • CLASS
  • TIME
  • COND