How a batch job runs

Every program you have written in this course ran because something started it and told it where its files were. On z/OS that something is JCL, Job Control Language. A developer who can't read JCL can't test their own code, so it is part of every COBOL job interview.

JCL is not a programming language. It has no loops or variables you would recognise. It is a list of instructions to the operating system: run this program, then that one, and connect these datasets to them.

A job, its steps and their datasets

//PAYDAILY JOB (ACCT01),'PAYROLL TEAM',CLASS=A,MSGCLASS=X
//*  Daily payroll extract, then print it
//EXTRACT  EXEC PGM=PAYEXTR
//EMPIN    DD DSN=PAYROLL.EMPLOYEES,DISP=SHR
//EXTOUT   DD DSN=PAYROLL.EXTRACT.DAILY,DISP=(NEW,CATLG,DELETE)
//SYSOUT   DD SYSOUT=*
//PRINT    EXEC PGM=IEBGENER
//SYSUT1   DD DSN=PAYROLL.EXTRACT.DAILY,DISP=SHR
//SYSUT2   DD SYSOUT=*
//SYSIN    DD DUMMY

There are three statement types you will write every day:

This job has two steps. EXTRACT runs the COBOL program PAYEXTR, whose SELECT ... ASSIGN TO EMPIN now means PAYROLL.EMPLOYEES. PRINT runs IBM's copy utility IEBGENER to print the extract. Steps run in order, one after another, and a later step can read what an earlier one wrote. //* lines are comments.

The life of a job

When you submit the JCL (from ISPF, or a scheduler submits it at 02:00), it goes to JES, the Job Entry Subsystem (JES2 at most sites):

1. Input. JES reads the JCL, gives the job a number such as JOB04711 and puts it on the input queue for its CLASS.
2. Conversion. The JCL is checked for syntax. A typo here is a JCL error and nothing runs at all.
3. Execution. When an initiator serving that class is free, it picks up the job and runs the steps. Before each step, the system allocates the datasets on its DD statements; after it, it disposes of them (keeps, catalogs or deletes them).
4. Output. Everything written to SYSOUT=*, plus the job log of system messages, sits on the spool. You read it with SDSF.
5. Purge. Eventually the output is printed, archived or deleted.

Each step ends with a return code: 0 means fine, 4 is a warning, 8 and above usually mean trouble. The highest return code in the job is its MAXCC. A step that crashes doesn't get a return code; it abends (abnormal end) with a code such as S806 or U4038.

What the job log looks like

In this course, jobs run in a simulator that prints a JES-style log. The job above produced:

 JES2 JOB LOG -- PAYDAILY

  IEF237I EMPIN    ALLOCATED TO PAYROLL.EMPLOYEES
  IEF237I EXTOUT   ALLOCATED TO PAYROLL.EXTRACT.DAILY
  IEF285I   PAYROLL.EMPLOYEES              KEPT
  IEF285I   PAYROLL.EXTRACT.DAILY          CATALOGED
  IEF142I PAYDAILY EXTRACT - STEP WAS EXECUTED - COND CODE 0000
  IEF237I SYSUT1   ALLOCATED TO PAYROLL.EXTRACT.DAILY
  IEF285I   PAYROLL.EXTRACT.DAILY          KEPT
  IEF142I PAYDAILY PRINT - STEP WAS EXECUTED - COND CODE 0000

  $HASP395 PAYDAILY ENDED - MAXCC=0000

Read it top to bottom: allocation (IEF237I), disposition (IEF285I), the step's condition code (IEF142I), and the job's end ($HASP395). Real job logs are longer, but these message ids are the real ones.