JCL

"Juris Canonici Licentiatus" - a graduate degree in Canon Law.

Java = J = JEDR

JCL /J-C-L/ n.

1. IBM's supremely rude Job Control Language. JCL is the script language used to control the execution of programs in IBM's batch systems. JCL has a very fascist syntax, and some versions will, for example, barf if two spaces appear where it expects one. Most programmers confronted with JCL simply copy a working file (or card deck), changing the file names. Someone who actually understands and generates unique JCL is regarded with the mixed respect one gives to someone who memorizes the phone book. It is reported that hackers at IBM itself sometimes sing "Who's the breeder of the crud that mangles you and me? I-B-M, J-C-L, M-o-u-s-e" to the tune of the "Mickey Mouse Club" theme to express their opinion of the beast. 2. A comparative for any very rude software that a hacker is expected to use. "That's as bad as JCL." As with COBOL, JCL is often used as an archetype of ugliness even by those who haven't experienced it. See also IBM, fear and loathing.

A (poorly documented, naturally) shell simulating JCL syntax is available at the Retrocomputing Museum http://www.tuxedo.org/retro.

--The Jargon File version 4.3.1, ed. ESR, autonoded by rescdsk.

Disclaimer: I haven't written JCL for over 20 years now and am a bit rusty.
TLA for Job Control Language. The method of choice to talk to computers when punch cards were en vogue. Imagine a non-interactive shell script, if you like. Mainly used for IBM operation systems but often available in a similar format in all operating systems with strong batch features.

A simple example follows :

//HOGGLE01 JOB 
//  EXEC PGM=FLOBBO
//SYSIN DD *
happy application input data lives here
just punched on cards and read line by line
/*
//

So what does this do ? Start a job called HOGGLE01 (allowing the operator to do nasty things with it by name), runs a progam named FLOBBO that reads input from the standard input (SYSIN). The input is just put after the DD * statement (* is the equivalent of stdin), read by FLOBBO until it reads the EOF, which is a card with /* on it. The last card, //, is the end-of-job.

Of course, JCL allows for way more complicated things - including job nets (run job 1, depending on the result, run either job 2 or job 3), conditional execution of job steps, plus loads of more or less well-documented options, switches and parameters.

As the writeups above explain, JCL allows batch executions of programs. A job can have one or more steps, each running a program or other JCL procedure, which will run in sequential order from the first to the last.

As McSnarf mentioned above, JCL allows conditioning the running of steps according to the return codes returned by steps which have already run.
What's this good for?
Well, let's say you have a job that runs 2 steps on a file containing code. The first step compiles the code and the second step links the compiled load module with other (NCAL) procedures. In case the compilation step didn't finish validly (syntax error for example) there's not much point in running the linkage is there?

These conditions are called 'CONDS' and are written in the EXEC cards of steps you wish to add a condition to (steps with no conds will always run).
IBM's Conds follow sone twisted logic..
Instead of the normal "if true then run" logic we're used to, IBM decided to do the opposite, so steps with conditions that resolve to true are NOT executed.

The syntax is as follows:
//STEP1 EXEC PGM=SOMEPGM,COND=(<rc>,<operator>,<stepname>)
Where rc is the return code we're checking, stepname is the step we're checking the return code of and operator is one of the following:
EQ - Equal to (==)
NE - Not equal to (!=)
LT - Less than (<)
LE - Less than or equal to (<=)
GT - Greater than (>)
GE - Greater than or equal to (>=)
NG - Not greater than (<=)
NL - Not less than (>=)

(Omitting the step name parameter from the COND will make it check the return code of every step that finished running before the current step.)

Example:
//STEP3 EXEC PGM=PROGGIE,COND=(3,LE,STEP1)

Means that step 3 won't be executed if:
3 <= STEP1
Which means STEP3 will run if 3 > STEP1 ==> STEP1 < 3.
Or in other words, STEP3 will run only if STEP1 returned a return code of less than 3.
As you see, the order of the parameters is also unconveniently backwards.
Fun stuff eh?

Cond has another format which works with the EVEN and ONLY parameters:
COND=EVEN makes it so the step will run even if any of the steps above it abended, while COND=ONLY runs the step only if a previous step has failed or abended.

Eventually, IBM realised their wrong doings with conds and implemented normal if-then-else statements in JCL which make life so much easier.
A few years too late imo..