Talk:Job Control Language

Leading "//"

I have my doubts about the leading "//" on JCL commands being a safeguard against loading the cards backwards in the card reader. If the cards were backwards, nothing would make sense, whether it started with a "//" or not.

Also if you've seen an 80-col card you'll have noticed that the top right corner is cut off diagonally. Most punches and readers physically could not accept cards in a wrong orientation. This features pre-dates IBM System/360 JCL and probably goes back to Hollerith, who in 1888 founded the company that became the main core of IBM.Philcha 16:30, 21 October 2007 (UTC)[reply]

I think it's more likely that the double slashes were simply the best available special character available for use in JCL. In normal English, the slash is not used very often, and almost never at the start of a sentence. So the double slash becomes a convenient, short, and unique identifer to the operating system that the card contains a JCL command.

Its fair to ask why JCL needs a special identifier in the first place. After all, since the cards are being read from the card reader, can't it be assumed that the cards contain JCL commands? Yes and no. A deck of cards read by a card reader will normally contain a mixture of JCL commands and data. by simply looking for the double slashes, it becomes easier to distinguish between the two.

When data is embedded in the job itself, it is referred to as instream data. The JCL command which marks the end of instream data is "/*".

one doubt..

What is the difference between Condition code COND and IF ELSE?

Answer: COND is simply the older version to formulate conditions. I have to admit: I never grasped the wretched logic of how to write this parameter, I always had to look into the manuals. IF/THEN/ELSE is an adapted form of COND and better readable.

COND always seemed backwards to me. Martin Packer 06:52, 5 October 2007 (UTC)[reply]

jcl

can we submit more than one job in a JCL if yes how?

Ans) Yes . It is possible to submit more than one jobs in a JCL. And, it's not too difficult either.....

For ex:-

//MYJOB1 JOB ,'ABC',CLASS='H',MSGCLASS='X',NOTIFY=&SYSUID
//*****************************************************
//*                  JOB1                             *
//*****************************************************
//STEP1 EXEC PGM=IEFBR14                             
//SYSOUT DD SYSOUT=*                                                    
//DD1 DD DSN=X1.Y1.Z1,DISP=(NEW,CATLG,DELETE),                            
         SPACE=(TRK,(1,1,0),RLSE)
//SYSIN DD DUMMY                                                   

//*****************************************************
//*                  JOB2                             *
//*****************************************************
//STEP2 EXEC PGM=IEFBR14                               
//SYSOUT DD SYSOUT=*                                   
//DD2 DD DSN=X2.Y2.Z2,DISP=(NEW,CATLG,DELETE),      
         SPACE=(TRK,(1,1,0),RLSE)                       
//SYSIN DD DUMMY                                           
//

That's it !!!

I'm going to give that answer a grade of "D-", because it's one job, not two. The answer is Yes, but it depends on what you are seeking to accomplish. Do you want two jobstreams submitted from one pds? or do you want a job to submit a second jobstream? do you want a job to submit/transmit a job to another JES2/JES3 node? are you running an STC, or submitting through CICS?

"/*" is not a requirement to end in-stream data. In fact, I might be using "/EOD" to end my in-stream data, especially if I'm transmitting a job with in-stream data delimited by "/*" to another node--it happens.

Amateurs.. z/OS JCL, to paraphrase an instructor, is like the controls of a 747--many options and settings, and best handled by a TRAINED professional.

one question

What's with the "THIS IS CORRECT" right there in the middle of the article? I was going to remove it but I thought I'd better check it wasn't there for some strange reason....?

Not just IBM

I know this comment borders on original research ... From my 30 years of experience in the computer industry, Job Control Language (JCL) applies to more than just IBM. It was used (and possibly still is) in a wide variety of computer systems that do batch (i.e.-offline) processing. The concepts are generally the same, with minor variations. For example, when Xerox was making their Sigma series of computers in the 1970s, their JCL started with a "$" in contrast to IBM's "//" and included commands like: $JOB (start of job), $ASSIGN (assign I/O devices), $DATA (start of data), $EOD (end of data), $EOJ (end of job). In the 1970s and 1980s, Gould/Systems Engineering Laboratories (SEL) produced several minicomputers whose JCL was almost the same as Xerox except that they started with an exclamation point "!", commonly referred to as a "bang" character. I think this article deserves at least a brief mention of these other JCL systems. I propose to wait one month (until August 8, 2007) and see what comments the Wikipedia community might have, and then add a short "Other systems" section to the end of the article; I'll try to find some verifiable sources if/when I do that. Truthanado 19:34, 8 July 2007 (UTC)[reply]

If you get some refs, we need to:

copy most of Job Control Language to another article "IBM Job Control Language" with a redirect from "IBM JCL".
re-write Job Control Language to be more general and list all the names by which job control language was known, e.g. OCL (ICL 2900), WFL (Burroughs, now part of Unisys). Philcha 23:32, 20 October 2007 (UTC)[reply]

Ahh yes, JCL. The worst thing to ever happen to computing. --64.238.49.65 21:36, 17 October 2007 (UTC)[reply]

You're a fool!

JCL has been working quite successfully for nearly 50 years now, and controlled the majority of computer jobs all that time. And it is a definite improvement over the previous methods. What have you produced that is still running successfully after 50 years?

If you had some actual, specific complaints to give, we could discuss them here. But you appear to be just a troll, jumping in with pointless criticism. T-bonham (talk) 09:01, 26 February 2008 (UTC)[reply]

I remember reading in 1980 a report that the USA's General Acounting Office estimated that the poor design of IBM OS JCL cost the US economy $1 billion / year. Philcha (talk) 17:47, 25 April 2008 (UTC)[reply]

And you believe everything that a government bureaucrat tells you?

That 'estimate' is absurd on its face: even if we accept the $1 billion/year, that cost is income to IBM, so it isn't lost to the economy, just moved from customers to IBM.

T-bonham (talk) 05:30, 22 July 2008 (UTC)[reply]

I did some digging on the GAO's site, the estimate appears to me to be coming from report AFMD-81-25 which says that software maintenance is costing $1.3 billion per year. I have thus removed the text from the article asserting that the poor design of OS JCL is costing $1.3 billion per year. Craig Schneiderwent (talk) 02:44, 18 August 2008 (UTC)[reply]

Rewrite in progress

I've rewritten Job Control Language to: cover IBM's DOS/360 and its descendants as well as OS/360 and its descendants; focus more on the facilities and flavour of the 2 JCLs rather than on details of some statement types and some of their options. Please comment. I'd be particulary grateful for more info on DOS/360 and its descendants, especially after 1980 - I only used DOS JCL a handful of times, and only in the late 1970s.

The rewrite does not currently take account of Truthanado's point about use of "JCL" by computer supliers other than IBM.Philcha 23:37, 20 October 2007 (UTC)[reply]

IBM PC nitpick

I don't know the correct number or I would have just corrected it, but in the section comparing the IBM PC with 360 (whose points are valid) it claims the original PC could do almost 5 MIPS. Not by a million miles! Sure the CPU clock was 4.77 MHz but the minimum instruction took two clocks to execute, most were more like 5-10, some took dozens of clocks. My recollection from the time was that the numbers being thrown around were well under 1 MIPS. Also, the 5150 came out in 1981 not 1982. —Preceding unsigned comment added by 24.62.205.183 (talk) 00:04, 26 October 2007 (UTC)[reply]

Agreed - I found a ref that quotes .33MIPS, and have changed the article.Philcha 15:18, 16 November 2007 (UTC)[reply]

Complexity

Sorry folks, but the section about "complexity " is nonsense. JCL is not interpreted, but compiled before it is really submitted, so speed is not an issue. And it's not a programming language. The GAO guy who wrote this $1 billion estimate compared apples with pears.

JCL was and is a declarative language that specifies the context in which one or more programs shall run, bareback on the naked processor. Without soft cushions like "COMMAND.COM" or UNIX SHELL. With JCL, you can put the cushions in place (TSO, CICS, DB2).

So please don't compare a COPY a.txt b.txt with a JCL for an IEBGENER. If you are a one-person company, you can call your friend, trucker Smith, to lug some timber from A to B. But if you are a clerk in a big enterprise, without a budget, and you are forced to advertise the job to all truckers who might want to do it, then you need some bureaucracy.

And don't call CLIST something that supersedes JCL. It does not. It gives you an office that does the bad part of ordering the truck (called TSO). But as an office can do more that order trucks, CLIST can do many things that JCL can't do. Because it targets other goals. And when the tasks become difficult, you must tell you office PRECISELY what you want, and then things get ugly. Try using the TSO ALLOC command from a CLIST when you need some of the more complex options...

--Rolf b (talk) 15:16, 1 August 2008 (UTC)[reply]

JCL Humor

Something I read many many moons ago, as read out loud to the tune of Camptown Races:

//SYSIN DD *
Doo dah, doo dah.

— Loadmaster (talk) 19:56, 1 April 2009 (UTC)[reply]

New Math

I think you've got a little integer math problem (i.e., programming problem) regarding the translation of the JCL conditional to pseudocode for STEP2! The original article states:

 //STEP02 EXEC PGM=PROG02,COND=(4,GT,STEP01)

means: Run STEP02 unless the number 4 is greater than STEP01's return code.

 if STEP01's return code is greater than 4 then
   run STEP02
 end if

See the problem? To be more specific, I believe these are equivalent pseudocode expressions (which is not what your pseudocode states):

 COND=(4,GT,STEP01)

 unless (4 > STEP01)

 if NOT (4 > STEP01)

 if NOT (STEP01 < 4)

 if (STEP01 >= 4)

—Preceding unsigned comment added by 68.35.184.177 (talk) 04:54, 9 April 2009 (UTC)[reply]

I noticed this too and was going to fix it, but I don't really understand what the final line of the program is doing. Why have such a condition? It seems to always run that step. Steve Checkoway (talk) 23:23, 8 March 2010 (UTC)[reply]

Functional Equivalents?

In other environments what are the steps/languages/procedures that do what JCL does? Assign a particular input file to be run by Program X; to make some choices depending on what happened from running Program X? Continue or abort?

In other environments (Windows?) how does one execute a series of programs (Program A, Program B, and Program C) where A & C are existing production programs & B is your testing version? How does one "concatenate" the various libraries so that FIRST my test library is looked at, and SECOND the production libraries are examined. Does Windows do this as JCL does? Or is there some other mechanism? What about Unix? Macintosh? AS400? DEddy (talk) 16:04, 3 April 2011 (UTC)[reply]

Lack of references

This article should be flagged for lack of references. Oogbus (talk) 18:30, 28 May 2011 (UTC)[reply]

Proposed merge from Job entry control language

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The result was merge into Job Control Language. -- EdwardH (talk) 07:59, 14 April 2014 (UTC)[reply]

I agree with the proposed merge of the Job entry control language page as a new section of this article. Shall I do it, or do one of the writers of this page prefer to maintain control of the operation? TheAMmollusc (talk) 11:27, 27 January 2012 (UTC)[reply]

I certainly agree with this merger. Since this proposal has been around since 2012, just go ahead and do it. If, for some reason you can't, let me know, I'll take care of it. Softtest123 (talk) 17:04, 7 March 2014 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.