JCL (Job Control Language)

JCL_book

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:

  1. JOB CARD / OR PROC NAME
  2. EXEC STATEMENT
  3. 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.

JCL1
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:

new_packed_dataset

JCL PROCS and SYMBOLS

A similar job to ‘UNPACK‘ this TERSE file would be necessary.

JCL2_unpack

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:

  1. start JOB at the JOBCARD on line 000001
  2. EXECute procedure (PROC) UNPKSS on line 000017
  3. PROC UNPKSS begins on line 000008 and ends on line 000015
  4. PROC UNPKSS puts the &HLQ. value set on line 000006, which is ‘USER123’
  5. PROC also reference the PARM that was pass on line 000017, ‘NSMPIN=’BFCU.TOMZOS.ICAT.INSTLIB
  6. line 000011 is translated to:  USER123.BFCU.TOMZOS.ICAT.INSTLIB.PACKED
  7. 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!

As one of the fairly new members into the mainframe family, I originally had some hiccups understanding the basics of mainframes. And by basics, I mean the absolute basics. I wish there was someone who could tell me a story of how it all happened from start to present in the mainframe world. A dear friend and a mainframe enthusiast suggested I read a book and the book clearly solved the purpose.Hence, here is a top ten list of the coolest z/OS facts.

1.      z/OS is an awesome multitasker


Back in the days, when z/OS was developed, computers were extremely expensive. Hence the developers built z/OS in such a way that different people could use z/OS to run multiple tasks at the same time. Every task that runs on z/OS runs in an address space and each task thinks that it’s the only one running. However, behind the screen, z/OS shares resources like memory and CPU across all tasks and there could be numerous tasks running at the same time sharing these resources.

2.      z/OS handles large workloads


It sounds quite obvious that z/OS can handle large workloads. But there must be a way to decide what tasks to run first and what can wait. In other words, how do we prioritize? z/OS uses a feature called WorkLoad Manager which helps in prioritizing system, production and non-production tasks. This helps z/OS in handling large workloads making 100% use of the CPU.

3.     It’s unbelievably hard to crash z/OS


Everyone expects z/OS to keep running and running and running. So anytime when a task crashes, we can not let that crash any other part of the system. Now remember we mentioned that every task runs in its own address space. So IBM has invested a lot of time and money in making sure that when a task crashes in one address space, it does not interfere with the normal functionality of the entire system, in other words making it robust and also clean up completely where the crash occurred so we can be up and running like new. But z/OS records any crash that occurs due to a hardware or software failure, so we can get into investigation later.

4.      z/OS has the best recording


z/OS comes with its own inbuilt scribe and we call it the System Management Facility(SMF). SMF records quite a lot of information like when was the system started, what task is currently running, when was a file created, when was it last edited, who deleted it, etc,. Security audits, capacity planning and performance monitoring are some of the uses of all this information that is recorded using SMF. IBM can proudly claim that z/OS has the most extensive recording of any operating systems.

5.     You need a job entry subsystem for z/OS


z/OS can run a series of jobs at the same time without any human intervention and they are called batch jobs. Users use a language called Job Control Language (JCL) to specify instructions for a specific job or a batch job to run. Once z/OS receives instructions from a user in the form of JCL, the role of a Job Entry Subsystem (JES) is to convert the JCL instructions into machine readable form and then queues them for processing, create address spaces, make sure all the input files for the job are ready, specify where the output has to be written and any other information required to run that job. Overall, JES acts like a manager, making sure, everyone has their resources to do their job and everyone does their job diligently.

  6.      How different are z/OS files?

                   We all know about files on windows. They store our data and we can access our files through an application like notepad. In z/OS, the concept of files is quite different. In the first place, they are not even called files. They are called Datasets. Each dataset is made up of records. When you create a new dataset, you need to specify the length of each record. Some other basic information that you need to specify are where the dataset should be stored and how big of a dataset it is. We will discuss about creating datasets and all the information you need to know to create a dataset in a later post. Hang in there!

               7.      How do you talk to the Mainframes?

 

How do we interact with such humongous mainframe computers and z/OS? We have to use an application called TSO/E( Time Sharing Option Extended) to talk to the z Systems. TSO/E is very hard to use. So z/OS comes with ISPF (Interactive System Productivity Facility). ISPF gives an interactive and easier way to communicate by providing lot of inbuilt functionalities

8.     You get UNIX with z/OS

When we say, you get UNIX with z/OS, that’s really an eye wash. What you really get is a POSIX compliant UNIX Shell called UNIX Systems services (USS). Posix compliant means that we meet all requirements to call it UNIX, but it’s actually not UNIX. 

9.      z/OS has a console

In your mainframe server room, you will have operators who would monitor your system on a regular basis to make sure if the system is running without any interruptions. The way they do it is, by monitoring the console with the system news feed to see what is going on in the system, if there are any alert messages or if there is any problem that they need to be aware of. The main z/OS console is directly plugged into the mainframe, so that even if there are network issues, the console will continue to work.

10.     z/OS isn’t enough

Once we successfully setup z/OS, we now have a basic operating system. But the real functionality of a mainframe is not exhibited unless we equip our system with applications that run on z/OS for security management, performance, database management, printing, etc,.  Apart from IBM, there are also other vendors in the market who sell applications that run on z/OS to make it more efficient.

If you need more of this, I suggest reading What On Earth is a Mainframe?
The book is a very easy read with topics ranging from fundamentals of mainframe hardware to application development on z/OS.
Posted in JCL.