![]() | This page is not a forum for general discussion about Job Control Language. Any such comments may be removed or refactored. Please limit discussion to improvement of this article. You may wish to ask factual questions about Job Control Language at the Reference desk. |
![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
![]() | The contents of the Job entry control language page were merged into Job Control Language on 14 April 2014. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
|
|
This page has archives. Sections older than 365 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
I have my doubts about the leading "https://" 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 "https://" 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)
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)
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)
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)
DISP
parameter specifying that the file be deleted in the event of an abnormal ending, it will be created.Does anyone know about ECL (Easy Control Language)? [1] 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
![]() | This page is not a forum for general discussion about Job Control Language. Any such comments may be removed or refactored. Please limit discussion to improvement of this article. You may wish to ask factual questions about Job Control Language at the Reference desk. |
![]() | This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
![]() | The contents of the Job entry control language page were merged into Job Control Language on 14 April 2014. For the contribution history and old versions of the redirected page, please see its history; for the discussion at that location, see its talk page. |
|
|
This page has archives. Sections older than 365 days may be automatically archived by Lowercase sigmabot III when more than 4 sections are present. |
I have my doubts about the leading "https://" 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 "https://" 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)
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)
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)
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)
DISP
parameter specifying that the file be deleted in the event of an abnormal ending, it will be created.Does anyone know about ECL (Easy Control Language)? [1] 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