Introduction to JCL

The Environment
JCL (Job Control Language) is a specialized programming language used with an IBM mainframe batch computer system. It is used to instruct the operating system (MVS) as to what programs you want it to run for you and what files those programs need during their execution. JCL is not a general purpose programming language; most of the things you expect to do in a general purpose programming language (like C or Cobol) cannot be done in JCL. JCL is more of a meta-programming language since it deals with the manipulation (execution in this case) of programs rather than the manipulation of data as most programs you have experienced do.
In an interactive programming environment, like a personal computer or logging into a Unix system, you tell the operating system what program you want to run by typing its name and the program begins running. The files needed by the program are specified by name when the program opens them. These names are either known by the program implicitly (it always opens some files of the same names) or explicitly by your specifying them on the command line. During the execution of the program you see its output on the screen and can often enter data from the keyboard in response to what you see. When you are done running one program, you then give another command to run another program. The programs typically run include compilers, utility programs (like the copy command), and your own programs that you have written and compiled. While the programs are running, you are there at the computer, tending to their needs.
A batch environment is quite different. Think of it as a service provider, shared by a large number of different users, each who wants the computer to do something for them. These users may be individuals (like students doing their course assignments) or entities like a payroll department or the registrar. Programs in this environment are not run interactively. The user hands over to the computer the job they want done and when the computer gets to it the requested functions are performed and the results returned to the user. When you give the job to the computer you must tell the computer all it needs to know because it will use only that information making no attempt to check with you for any clarification or missing information.
Interactive and batch processing might be better understood by the following analogy. Think about ordering a number of items from some company out of state. One way to do this might be to call the company on the phone and talk to a customer service person (order taker). That person can walk you through the process, asking for your name and address, and what you want to order. They can make sure you tell them what color you want while you are talking to them in case you would have forgotten and they can tell you that another item is out of stock and ask if you want to wait or select something else. They can tell you the total, ask how you want to pay and say when it should arrive. This method is highly interactive.
The alternative is to fill out the order blank in the catalog and mail it to the company. Everything about your order has to be specified completely and clearly when you seal the envelope and put it in the mailbox. Then you wait (and wait) for your items to arrive. If everything was complete in the order you sent them you get what you wanted when the big box arrives. On the other hand, if you didn't say something important (like how you wanted to pay for it all) you just get back a letter informing you of the problem and telling you to send your order again (this may be like a JCL error!). If you forget to put your name and address on the form, you might not get anything back ever (like a bad JOB card). Maybe you forgot to indicate the color for an item and the company picked on for you (like giving lots of extra listing for your program compilation because you didn't put the PARM.COB2='NOXREF …' on the EXEC card). This is batch processing at its best (or worst).


Learning JCL
No one will say that learning JCL is easy. Because it must be capable of specifying everything that the computer (operating system actually) needs to possibly know about what you want it to do for you there are lots and lots of different parameters. The syntax is terse and not user-friendly. Recall that non-programmer users are not concerned with JCL, rather they hire professional programmers to set up the JCL they need for their applications. But even for programmers it can initially be bewildering. This doesn't sound very encouraging at all.
If you want to learn a spoken foreign language you don't (I hope) just get a dictionary of that language and read the dictionary from cover to cover. Doing so (if you could make it all the way through) would leave you bewildered and discouraged. JCL is a foreign language.
Learning JCL is best done on a need-to-know basis. Start out by learning only that part of JCL that you need for what you want to do. Ignore the rest, to begin with. What do you "need" to know? This may be the real problem of dealing with and learning JCL. What do you want to do? How do you go about doing it? When you can answer these questions then the JCL will not be so hard to deal with. So start there, decide what you want to do and how to do it. This is not much different than what you must do when you design and write a program.



I want to use the computer
Good! You need to prepare your order for the computer so you can send it in for processing. Your "order" is called a job which is a sequence of JCL statements. You use an editor to prepare this complete description of what you want to do. When JCL was designed 80 column cards were used to record jobs. So the terminology used to describe JCL often includes the word card. The collection of "cards" that make up a job are often referred to as a job stream.
The first kind of JCL card you need to know is the JOB card. This tells the computer who you are (who is paying the bill) and gives your job a name to refer to (the jobname). Get this card wrong and you will probably be ignored. Like all JCL cards the job card begins with slashes in the first two columns:
//MYJOB1 JOB (X27-PROF),DR.WHO
Required in all cases are a job name (1 to 8 characters beginning in column 3), the word JOB surrounded by one or more spaces on each side, accounting information (the first parameter), and the programmer's name. The details of these fields, and others that may also be required vary from installation to installation. Check for local requirements!
Great start so far, that was not too hard. The rest of the jobstream tells what we want to do (program to run) and what is needed to do it (which files are to be accessed). Think of this as being a series of steps (called job steps) to be done in sequence. When they are all done, the job is done and the results can then be returned to us.
Each job step consists of two parts, one specifying the program to run on an EXEC card, and two the files needed, each specified on a DD card. Thus there is a hierarchy:

// JOB
// EXEC
// DD
// DD
// EXEC
// DD
// DD
// DD

Of course many needed parameters have been omitted and the spacing shown would not actually be used. Rather see that there is one job card at the beginning and then multiple job steps each beginning with an exec card with (possibly) multiple dd cards for each step.

Compile and execute
What can be done in a single IDE (interactive development environment) on a personal computer such as compiling, debugging and executing a program requires separate steps in the batch environment. Typically compilation will require execution of one program (the compiler) and a second step to link and run the compiled program. The compiler always needs a number of files for its work beyond just where the source file is located; the execution step (usually called the "GO" step) likewise needs several standard files.
To show that it can indeed be a friendly language (yeah, right!), JCL has something called cataloged procedures. Really, this is going to make things much easier. For most of what you will want to do you will be able to use cataloged procedures to provide most of the JCL needed. What you will then need to do is just specify any files you are providing and to over-ride any defaults you may not want.

COB2UCG Cataloged Procedure
//COB2 EXEC PGM=IGYCRCTL,PARM='OBJECT'
//STEPLIB DD DSNAME=SYS1.COB2COMP,DISP=SHR
//SYSPRINT DD SYSOUT=A
//SYSLIN DD DSNAME=&&LOADSET,UNIT=SYSDA,DISP=(MOD,PASS),
// SPACE=(TRK,(3,3))
//SYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT5 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT6 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//GO EXEC PGM=LOADER,PARM='MAP,LET',COND=(5,LT,COB2)
//SYSLIB DD DSNAME=SYS1.COB2LIB,DISP=SHR
//STEPIB DD DSNAME=SYS1.COB2LIB,DISP=SHR
//SYSLIN DD DSNAME=*.COB2.SYSLIN,DISP=(OLD,DELETE)
//SYSLOUT DD SYSOUT=A
//SYSABOUT DD SYSOUT=A
//SYSDBOUT DD SYSOUT=A
//SYSUDUMP DD SYSOUT=A

In the above cataloged procedure there are two steps, the first called COB2 and the second GO. When we say to execute this procedure with a // EXEC COB2UCG JCL card the system goes to the cataloged procedure library to read the definition of the procedure we asked for. The system will then merge the DD cards from the procedure with any that we include after our EXEC card. The DD cards we specify may be either used to override existing DD cards in the procedure or to add new DD cards. A combination of stepname and ddname are used to determine what happens and where.
If our JCL (after the JOB card) is as follows:
// EXEC COB2UCG
//SYSIN DD *
SOURCE PROGRAM CARD IMAGES
//GO.SYSUDUMP DD DUMMY
//GO.INPUT DD DSN=E9999.PECHURA.CIS270.LAB1,DISP=SHR
//GO.REPOUT DD SYSOUT=A

Merging of the DD cards occurs as follows. Since //SYSIN doesn't have a stepname specified, it will go in the current (in this case first) step. Since SYSIN doesn't match an existing DD name in the first step, it will be added at the end of the step. The //GO.SYSUDUMP card specifies the GO step we are done doing anything in the COB2 step. Since there is a //SYSUDUMP card in the GO step, our DD card by this name will override the existing specification. Our next two cards, since they do not match ddnames defined in the GO step, will be added at the end of the existing GO step DD cards.
The merging will result in the following set of JCL statements to be used. XX appears in the first two columns of the statements from the procedure.


XXCOB2 EXEC PGM=IGYCRCTL,PARM='OBJECT'
XXSTEPLIB DD DSNAME=SYS1.COB2COMP,DISP=SHR
XXSYSPRINT DD SYSOUT=A
XXSYSLIN DD DSNAME=&&LOADSET,UNIT=SYSDA,DISP=(MOD,PASS),
XX SPACE=(TRK,(3,3))
XXSYSUT1 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
XXSYSUT2 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
XXSYSUT3 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
XXSYSUT4 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
XXSYSUT5 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
XXSYSUT6 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
XXSYSUT7 DD UNIT=SYSDA,SPACE=(CYL,(1,1))
//SYSIN DD *
COBOL SOURCE STATEMENT GO HERE
XXGO EXEC PGM=LOADER,PARM='MAP,LET',COND=(5,LT,COB2)
XXSYSLIB DD DSNAME=SYS1.COB2LIB,DISP=SHR
XXSTEPIB DD DSNAME=SYS1.COB2LIB,DISP=SHR
XXSYSLIN DD DSNAME=*.COB2.SYSLIN,DISP=(OLD,DELETE)
XXSYSLOUT DD SYSOUT=A
XXSYSABOUT DD SYSOUT=A
XXSYSDBOUT DD SYSOUT=A
X/SYSUDUMP DD SYSOUT=A
//GO.SYSUDUMP DD DUMMY
//GO.INPUT DD DSN=E9999.PECHURA.CIS270.LAB1,DISP=SHR
//GO.REPOUT DD SYSOUT=A


The COBOL Connection
JCL just provides the specification of the programs to run and the files they need. From the JCL standpoint, we are for DD names giving the specification of the file as the operands of the DD statement. In the example above, we are saying that the DD name INPUT is the file E9999.PECHURA.CIS270.LAB1. In programs written for the mainframe the name of files is never given, only the ddname that will be associated with the file through JCL.
In a COBOL program it is in the SELECT statement that we refer to ddnames.
SELECT INPUT-FILE ASSIGN TO S-INPUT
is an example in which the internal to the Cobol program file name INPUT-FILE is associated with a DD card whose ddname is INPUT.