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.

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 "/*". — Preceding unsigned comment added by 70.21.54.110 (talk) 23:10, 28 March 2005 (UTC)

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)

More or less as an aside, "//" is used to begin a comment in the C++ programming language. "/*" begins a comment in the C programming language. JHobson3 (talk) 12:13, 9 March 2016 (UTC)

Most job control cards begin with a special character or two. XDS job control uses “!” (bang). I forget what Univac uses. Don’t know the rationale, except that the interpreter knows to stop reading when it it hita a card that starts with something else, and then if a job that gets flushed it’s simple to read until another JCL card is found. Systems with mainly interactive orientation don’t have this problem. Peter Flass (talk) 22:47, 14 June 2019 (UTC)

While the usual delimiter for instream data (following a DD *) is /*, // will also terminate it. The prevents accidentally reading the rest of the JCL if one gets the terminator wrong. DD DATA is used in the somewhat rare case one needs to read data starting with //, most commonly JCL itself. Also, it makes it a little easier for human readers to separate JCL from data. I believe DLM= came somewhat later. Gah4 (talk) 00:47, 30 April 2020 (UTC)

As well as I know it, the development of PL/I, using /* as a comment opener, was done in parallel with the development of JCL. You can't start a PL/I comment in column 1, if used as inline data. It seems that one of the features C inherited from PL/I is the comment delimiter. Gah4 (talk) 00:47, 30 April 2020 (UTC)

Difference between COND and IF ELSE

What is the difference between Condition code COND and IF ELSE? — Preceding unsigned comment added by 194.73.114.230 (talk) 02:08, 10 November 2005 (UTC)

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. — Preceding unsigned comment added by 195.49.224.20 (talk) 08:21, 3 April 2006 (UTC)

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

As MartinPacker says COND is backwards. The IF ELSE is like program logic, which is, if a condition is true, process the statements following the conditional statement. If the condition is false you bypass the statements following the conditional. With COND, if the condition specified is false the Step is executed, if true, you bypass the Step. — Preceding unsigned comment added by GrendelKhaaaan (talk • contribs) 15:35, 14 June 2019 (UTC)

JCL is an unofficial generic term

Everybody called the batch control language JCL. IBM may have copyrighted "JCL". Every mainframe system I worked on had a batch control language. We discussed the JCL used on many systems. Borrows had the best in that they used an illegal punch code in column 1. The cutoff corner of a card had no significance to the card reader. At least on all card readers I have used. We commonly reversed JCL cards so jobs could be easily stacked and seperated. I wrote a batch system for a Honeywell H200 that had all rows of the first column punched. JCL cards had to be read in column binary mode and translated to characters. This was used to run student jobs at Cerritos collage. As a lot of student jobs would fail to terminate, continuing to read cards till the hopper emptied. The illegal punch stopped the reader on an illegal punch code.

I would also note that indirect command line files were not commonly called JCL.

On the DEC-System-10 the interactive user command language was not the same as BCL, the Batch Control Language.

And we commonly used JCL when referring to batch jobs on DEC. Maybe because installations that ran batch jobs on DEC-10s also had IBM mainframes. Or had worked on IBM equipment.

I can not find any references for this. I started collage when they had an IBM 1401 system that was replaced by the Honeywell H200. The H200 was later replaced by a DEC-System-10. Steamerandy (talk) 02:55, 22 October 2015 (UTC)

JCL and HatNotes

• The 360 has gone around the world, jumped up as 370 and 390 (with some publications proclaiming some 1980 IBM intros as "380"), and gone from "A" as in Autocoder (1401) to "Z" as in almost off the alphabet list
• The JCL of the BUNCH companies (Burroughs,Univac/Unisys,NCR,Control Data,Honeywell) have gone ABEND, except for Unisys.
• The JCL word, to most people, means IBM, and even decades ago, when an exclamation mark was called BANG in at least one JCL, Slash Slash is what was happening to most competing vendors.

Isn't it a pitty to have HatNotes on the unified article that combines DOS, OS (// JCL) and JECL? Pi314m (talk) 08:39, 14 February 2017 (UTC)

grammatical relationship between "JES extensions" and "Job Entry Control Language (JECL)"

Abstracting from the meanings of the two nouns (which could just be "x" and "y") in the phrase: "the other for the lineage from OS/360 to z/OS, the latter now including JES extensions, Job Entry Control Language (JECL)."

there is something wrong with the grammatical linking between "JES extensions" and "Job Entry Control Language". Since the conjunction "and" was left out and since "Job Entry Control Language" is used without an article (implying that it is a proper name, which seems right), it would be read as if JECL were an appositive (or restatement/synonym of) "JES extensions". As if "JES extensions" are also sometimes called "Job Entry Control Language". But that's not right. They're not synonyms. Another question that is raised here is: does JCL include both the JES extensions and Job Entry Control Language?

Given the actual meanings of the terms and what their relationship to each other is, I would suggest that the original author meant to write either of the following (essentially the same meaning, with slight difference in nuance): 1) "the other for the lineage from OS/360 to z/OS, the latter now including JES extensions and Job Entry Control Language, which controls those extensions." or 2) "the other for the lineage from OS/360 to z/OS, the latter now including JES extensions and the Job Entry Control Language associated with them."

I would like someone with more technical expertise to confirm that at least one of these is 1) technically accurate and 2) likely matches the author's original intent. If it is not the case that both of those conditions are met, then I would hope that expert could suggest an alternative rewrite, one that clears up the ambiguity pointed out above, because, in its current form, it is (either intentionally or accidentally) obfuscating the relationship between the two components. — Preceding unsigned comment added by Cygnusaurus (talk • contribs) 01:24, 23 August 2019 (UTC)