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)

It is hard to know now, what the JCL designers thought. Note that DD * input ends with either /* or any card starting with //, so you can't accidentally read in the rest of the JCL. Also, it is easier for human readers to separate JCL and non-JCL. The funny accident seems to be both JCL and PL/I using /*. What do IBSYS cards look like? Gah4 (talk) 00:32, 5 December 2021 (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)

The language used with VAX/VMS (and other VMS), such as in batch files, is DCL (Digital Control Language). I don't remember anyone calling it JCL. Gah4 (talk) 00:50, 30 April 2020 (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)

I believe this is left over history from the way HASP was originally grafted onto OS/360. I don't know the history quite that well, but HASP is not actually part of OS/360. The control cards, then, have to be in a place that OS/360 could ignore them. ASP was an official IBM product that could be used with OS/360 and later systems, but again looks like it was grafted on later. The JECL term only came into use years later, after all the control cards had been in use for many years. Sometime in MVS years, HASP and ASP were made part of the system, one of which is required, and renamed JES2 and JES3. The control card format didn't change much, so they still look like grafts. Gah4 (talk) 00:56, 30 April 2020 (UTC)

See also edit revert

Hello @TJRC, Am not very sure why we say that JCL is not directly related to the topcis of COBOL, DB2, CICS, and VSAM - I quite often use them in conjunction. Is there any harm in having that included for easy navigation and additional detour reference material ? Karthik Sripal (talk) 04:33, 4 December 2021 (UTC)

Many people put milk in tea but would one be an appropriate “see also” for the other. I think appropriate links here would be to other control/scripting languages. Peter Flass (talk) 13:09, 4 December 2021 (UTC)

Thank you for the response, and well - I do like the analogy there and I honestly do think milk would not be a bad choice on the tea article's see also and vice versa. Is there any place wikipedia guidelines around this that I might be violating unknowingly or Is it just purely my ignorance on the topic or preference of most am just more curious ? Karthik Sripal (talk) 13:18, 4 December 2021 (UTC)

There is some guidance at MOS:SEEALSO, but as it says there, ultimately it is an editorial judgment. Personally I think COBOL and VSAM make sense as entries, because a programmer had to be mindful of how the JCL would look when doing batch programming with either, but DB2 and CICS do not. Wasted Time R (talk) 15:01, 4 December 2021 (UTC)

Thank you @Wasted Time R appreciate you sharing the link for the guidelines on this topic.

I see that you @Wasted Time R and @Peter Flass have considerably rich edit counts, significant contributions on development of this article here, its upkeep and come with better experience and judgement on this topic - and also this is not a super significant edit anyways - I just thought it would be a good tangential articles to refer to from this article.

So.. I would probably toddle on :-)

Oh by the way - I like your user name there @Wasted Time R :-) Karthik Sripal (talk) 15:45, 4 December 2021 (UTC)

All the compiled languages use pretty much the same JCL, with a compile step, (usually) link step, and GO step. There are some language dependencies, but they are pretty small. On the other hand, VSAM has its own IDCAMS, and associated JCL. Also, VSAM is used with more than one language, so I would agree with a MOS:SEEALSO for VSAM. (Does the VSAM page describe IDCAMS and its use?) Gah4 (talk) 19:01, 4 December 2021 (UTC)

I wouldn't include VSAM, because it has no closer connection to JCL than any other file type. In fact, it has less a connection than other filetypes, given that VSAM files are the one file type I'm aware of that cannot be created with JCL, instead requiring invocation of IDCAMS. TJRC (talk) 19:56, 4 December 2021 (UTC)

Karthik Sripal, I see that you pinged me last night, but I wasn't able to get on to respond until late this morning. Others above have already addressed the point in much the same way I would, so I'll be brief.

As others have noted, there's nothing special about, for example COBOL, compared to any other computer language such as PL/1, FORTRAN, C or IBM assembler language. But I would also point out that it isn't just the lack of uniqueness of COBOL here; it's the tenuousness of any connection to the topic of JCL.

What you've basically said is that JCL is used to submit a job for execution; the program that can be executed can be a compiler; the compiler will compile your source code; and your source code is in the COBOL language. That's far too distant a reach to justify a See also entry under WP:SEEALSO. The remoteness of the connection indicates that such a link need not be "present in a comprehensive article on the topic"; and given the plethora of other computer languages that would be justified on the same basis, it's not within the "should be limited to a reasonable number" constraint, either.

Analogous reasoning applies to the other entries. TJRC (talk) 19:56, 4 December 2021 (UTC)

The point is not that small pieces of JCL are used to compile COBOL programs. Rather the point is that those compiled COBOL program binaries do not run in a vacuum. For the business-oriented batch applications that use them, there are typically lengthy, highly parameterized JCL procedures that handle the selection of input tapes or disc files, arrange them in various orders with a sort utility step, run a COBOL binary, test return codes, run other COBOL binaries, and specify the placement and nature of output files. It's that environment that ties batch COBOL and JCL together, and programmers need to be at least somewhat aware of what the JCL is going to look like when designing a COBOL program. Consequently, COBOL text books of the mainframe era would devote some space to explaining at least the rudiments of JCL; one popular one, Stern & Stern Structured COBOL Programming 3rd edition, has a whole Appendix dealing with JCL. Wasted Time R (talk) 20:22, 4 December 2021 (UTC)

But that's true of every single batch program that runs on an IBM mainframe; there's nothing special about COBOL. TJRC (talk) 20:29, 4 December 2021 (UTC)

It might be that COBOL needs some less common JCL, but not enough to need distinguishing here. It seems that IDCAMS doesn't have a page, but instead redirects to: Support_programs_for_OS/360_and_successors. Many such programs use unusual JCL, and in many cases more JCL than not. Some run with no SYSIN, or sometimes only one line of SYSIN. Note that no files are created by JCL alone. They at least require IEFBR14, which does nothing other than to let the JCL do what it does. Gah4 (talk) 20:56, 4 December 2021 (UTC)

As far as I am aware, COBOL needs no other special JCL than any other compiler, apart from specifying the correct program name to execute. In fact, Fortran would be a better candidate here, because at least in that case the file numbers used in Fortran programs map to particular DD statements. (I am not advocating for Fortran or any other computer language to be included here.)

With respect to the file creation: it isn't JCL, per se, that creates the file, but it is the processing of the JCL by the job entry system at execution time that creates the file. The named program (such as IEFBR14) has nothing to do with it. You can even specify a non-existent program that can't be run; you'll get an ABEND (806? I don't recall), but if I remember my syntax right, unless you include a third DISP parameter specifying that the file be deleted in the event of an abnormal ending, it will be created.

VSAM files are an exception in that they cannot be created by JCL as above, and instead require using a particular utility, so the connection to JCL is even more remote than other types of file. TJRC (talk) 21:24, 4 December 2021 (UTC)

Compiled languages normally need minimal JCL. An EXEC of a cataloged procedure might be enough. (Some systems, I might be remembering ASP, will add a SYSIN DD * card if there is non-JCL where it isn't expected.) Reading or writing unusual format data sets usually requires knowing a little more JCL. But for the programs in Support_programs_for_OS/360_and_successors, you normally need to know (or look up) more JCL. IEBGENER is often run with only JCL, along with some others. Just because a utility needs a control card or two, doesn't mean that using it isn't mostly programming in JCL. As for DISP, I hadn't thought about this one for a while. From this z/OS JCL manual, yes, if there is no third parameter to DISP, the second is used on abend. Though it might depend on the cause of the abend. Gah4 (talk) 00:46, 5 December 2021 (UTC)

ECL

Does anyone know about ECL (Easy Control Language)? It seems it was meant as an easier to use form of JCL, which was converted early in the parsing into JCL. Statements started with ///, to distinguish them. There seems to be only reference for it, though. Gah4 (talk) 03:51, 5 December 2021 (UTC)

References