Introduction

The JOB statement is the very first line of any batch job, defining the job’s name, accounting information, and default controls for how the entire job is processed. It tells the system who “owns” the work, where to charge CPU and I/O costs, and which default settings (class, message routing, time limits) to apply.

Immediately following the JOB statement, each EXEC statement marks the start of a discrete step—calling a program or procedure, passing any needed parameters, and setting step-specific controls such as TIME or REGION.

Together, the JOB and EXEC statements form the skeleton of every JCL script: JOB sets the global context, and EXEC breaks the work into manageable, independently controlled units.

Correct use of JOB and EXEC parameters ensures that your work runs in the right environment, uses appropriate resources, and provides the level of logging and control you need. By mastering these two statements, you gain precise control over batch processing behavior, making your jobs predictable, efficient, and easy to maintain.

IBM Docs - Learn How to create and Submit JCL.

Here are the detail about each parameter coded in JOB and Exec:

• IBM Docs - JOB Statement
• IBM Docs - EXEC Statement

Positional vs. Keyword Parameters

JCL parameters look similar but behave very differently depending on position. A misplaced comma or missing keyword can change meaning—or cause errors.

• Positional parameters come first (inside parentheses) and have a fixed order.
  • e.g. on //MYJOB JOB (ACCT123),'Desc'… the (ACCT123) is positional.
  • You cannot mix order: (ACCT123,'DEPT') ≠ ('DEPT',ACCT123).
• Keyword parameters follow, each as NAME=value and in any order.
  • e.g. CLASS=A,MSGCLASS=X,NOTIFY=&SYSUID
• Common mistakes:
  • Omitting parentheses around positional list: JOB ACCT123,… is invalid.
  • Writing MSGLEVEL=1,1 instead of MSGLEVEL=(1,1).
  • Putting a keyword too early (before all positional): system will treat it as a bad positional value.
• Tip: Always code all your positional values together in one (…), then a comma, then all keywords.

MSGLEVEL: Parentheses, Sub-options & Common Mistakes

MSGLEVEL has two parts—what JCL you see vs. what messages you see—and both must be in (…).

• Syntax: MSGLEVEL=(statements,messages)
  • statements (first position):
    • 0 = only JOB statement + initial comments
    • 1 = all JCL (including procedures) after symbol substitution
    • 2 = only JCL & JES control
  • messages (second position):
    • 0 = only JCL messages; other messages only on failure
    • 1 = all messages (JCL, JES, operator, SMS)
• Examples:
  • MSGLEVEL=(1,1) → full JCL + all messages
  • MSGLEVEL=(2,0) → only control statements; only JCL messages unless failure
  • MSGLEVEL=1 → shorthand for (1,0)
  • MSGLEVEL=(,1) → use default statements, but show all messages
• Common mistakes:
  • Missing parentheses: MSGLEVEL=1,1 → syntax error
  • Dropping comma: MSGLEVEL=(11) → interpreted as statements=11 (invalid)
• Tip: If you only need one sub-option, you can omit the other but keep the comma:
  • To show all messages but default JCL: MSGLEVEL=(,1)

TYPRUN: SCAN vs. HOLD vs. “I Thought It’d Run…”

TYPRUN modes do not execute your code—they just queue it differently. SCAN does not run programs!

• TYPRUN=SCAN
  • Performs JCL syntax check only.
  • No program execution, no data allocation—just parser.
• TYPRUN=HOLD
  • Submits the job but places it in “hold” status.
  • An operator (or /*HOLD override) must release it.
• Common mistaken belief: TYPRUN=SCAN will “run it lightly” or “test it.” It never runs any step!
• Tip: If you need to test a job without full run, use SCAN—but remember nothing actually executes.

TIME Limits: JOB-level vs. STEP-level Interactions

JOB TIME and EXEC TIME are independent. Exceeding either limit will abend—even if the other has headroom.

• JOB TIME = total elapsed time for all steps.
• EXEC TIME = time per step.
• Syntax examples
  • //MYJOB JOB …,TIME=60 → total 60 minutes for entire job
  • //STEP1 EXEC PGM=…,TIME=(0,30) → 30 seconds for STEP1 only
• What actually happens:
  1. Job starts: JOB TIME countdown begins.
  2. Enter STEP1: STEP1 TIME countdown begins.
  3. STEP1 ends (if both limits not exceeded).
  4. Move to STEP2: new STEP2 countdown, but JOB TIME continuing.
• Common pitfall:
  • You set STEP times generously but overlook JOB TIME.
  • Example: JOB TIME=25s, two steps each TIME=20s. Step1 (15s) OK; Step2 starts, but 25s total exceeded → S322 abend.
• Tip: If your site’s default (usually 24 hrs) suffices, omit JOB TIME. Otherwise, plan both step durations and job total together.