JCL (Job Control Language)
Whenever new mainframers referencing JCL on the “interweb” or attending an in-depth overpriced JCL course, it seems that the Job Control Language is presented as something more difficult than it really is.
I blame this difficulty with not being fluent in what I call ‘IBM’rish’. A word I just made up referring to the cryptic language IBMers and IBM manuals may use. Signs of those fluent in IBM’rish include robot dance moves and entire conversations using only acronyms.
(yes, I’ve been accused of IBM’rish)
(The great thing about JCL is that I use an old reference book: "System 370 Job Control Language", by Gary DeWard Brown, that's been passed around at work over the years. Published in 1977 and it's still relevant. For a more up to date reference try googling "z/os mvs jcl reference".)
The JCL Structure
In its rawest form JCL can be broken down to these 3 basic parts:
- JOB CARD / OR PROC NAME
- EXEC STATEMENT
- DD (Data Definition) STATEMENT
I know there’s several veterans out there that will protest in rage that JCL is not as simple as that, but let’s examine some code and decide for ourselves.
Here is a simple JCL job that uses TRSMAIN – this program will ‘TERSE’ files, which is IBM’s own compression. Think of this as ‘.ZIP’ files, but for the mainframe.
Here’s the layout:
Lines: 000001 //JOBNAME JOB ACCOUNTING_INFO,NOTIFY_USER, 000002 // CPU_TIME_LIMIT,MESSAGE_OUTPUT_CLASS, ... REGION_STORAGE_SIZE_FOR_STEPS 000003 //LABEL OUTPUT JES_OUTPUT_LOCATIONS 000004 //* COMMENT 000005 //* COMMENT 000006 //TERSE EXEC PGM=TRSMAIN,PARM=PACK ... 'PARM=PACK means compress the files' 000007 //SYSPRINT DD LOCATION ... 'This Data Definition defines where all messages from the program are sent.' 000008 //INFILE DD THE_FILE_LOCATION_AND_SHARING_DETAILS 000009 //OUTFILE DD THE_NEW_OUTPUT_FILE_LOC_AND_DETAILS ... 000013 /* 'The delimiter. The "end-of-file" statement'
Nothing too complicated. This job will compress the ‘BFCU.TOMZOS.ICAT.INSTLIB‘ library to a single file called ‘USER123.BFCU.TOMZOS.ICAT.INSTLIB.PACKED‘
Then this single file could be FTP to IBM or somewhere else.
After ‘Submit‘, or ‘SUB‘ on the command line above it’s sent to JES2 (Job Entry Subsystem) and if there’s no errors or syntax mistakes will run successfully with a RC (Return Code) = CC (Condition Code) 0000.
Here’s the unreadable output resulting from this job:
JCL PROCS and SYMBOLS
A similar job to ‘UNPACK‘ this TERSE file would be necessary.
Whoa!!! Something is different in this job!
We’ve stepped it up a notch and now we have the same basics (JOB CARD, EXEC, DD) however we’ve added some JCL symbols and a procedure (PROC).
Lines of interest: 000006 // SET HLQ='USER123' ... 000008 //UNPKSS PROC DIR=',400' ... 000011 //INFILE DD DISP=SHR,DSN=&HLQ..&NSMPIN..PACKED 000012 //OUTFILE DD DISP=(NEW,CATLG), DSN=&HLQ..&NSMPIN..UNPACKED, 000013 // UNIT=SYSDA,SPACE=(TRK,(300,300&DIR), RLSE ... 000015 // PEND ... 000017 //F01 EXEC UNPKSS,NSMPIN='BFCU.TOMZOS.ICAT.INSTLIB'
Basically the difference and flow with this job is:
- start JOB at the JOBCARD on line 000001
- EXECute procedure (PROC) UNPKSS on line 000017
- PROC UNPKSS begins on line 000008 and ends on line 000015
- PROC UNPKSS puts the &HLQ. value set on line 000006, which is ‘USER123’
- PROC also reference the PARM that was pass on line 000017, ‘NSMPIN=’BFCU.TOMZOS.ICAT.INSTLIB‘
- line 000011 is translated to: USER123.BFCU.TOMZOS.ICAT.INSTLIB.PACKED
- line 000012 is translated to: USER123.BFCU.TOMZOS.ICAT.INSTLIB.UNPACKED
You’ll notice lines 000018 to 000025 were commented out (‘//*‘). If there was a list of files that required to be UNPACKED but with different names, the comments (‘//*’) would be replace with ‘//’ and the statement would run with the PARMS passed, as would be reflected in the UNPKSS PROC.
Hopefully this gives you a taste of the power and simplicity of JCL.
Happy coding and job submitting!