Editing Job Control Language (section)

==Features common to DOS and OS JCL==

===Jobs, steps and procedures===
For both DOS and OS the unit of work is the [[job stream|job]]. A job consists of one or several steps, each of which is a request to run one specific program. For example, before the days of [[relational database]]s, a job to produce a printed report for management might consist of the following steps: a user-written program to select the appropriate records and copy them to a temporary file; [[Sorting algorithm|sort]] the temporary file into the required order, usually using a general-purpose utility; a user-written program to present the information in a way that is easy for the end-users to read and includes other useful information such as sub-totals; and a user-written program to format selected pages of the end-user information for display on a monitor or terminal.

In both DOS and OS JCL the first "card" must be the JOB card, which:<ref>McQuillen, ''System/360–370 Assembler Language'', pp. 380–382.</ref> 
* Identifies the job.
* Usually provides information to enable the computer services department to bill the appropriate user department.
* Defines how the job as a whole is to be run, e.g. its priority relative to other jobs in the queue.

Procedures (commonly called ''procs'') are pre-written JCL for steps or groups of steps, inserted into a job. Both JCLs allow such procedures. Procs are used for repeating steps which are used several times in one job, or in several different jobs. They save programmer time and reduce the risk of errors. To run a procedure one simply includes in the JCL file a single "card" which copies the procedure from a specified file, and inserts it into the jobstream. Also, procs can include ''parameters'' to customize the procedure for each use.

===Basic syntax===
Both DOS and OS JCL have a maximum usable line length of 80 characters, because when DOS/360 and OS/360 were first used the main method of providing new input to a computer system was 80-column [[punched card]]s.<ref>Stern and Stern, ''Structured COBOL Programming'', pp. 528–529.</ref> It later became possible to submit jobs via disk or tape files with longer record lengths, but the operating system's job submission components ignored everything after character 80.

Strictly speaking both operating system families use only 71 characters per line. Characters 73-80 are usually card sequence numbers which the system printed on the end-of-job report and are useful for identifying the locations of any errors reported by the operating system. Character 72 is usually left blank, but it can contain a nonblank character to indicate that the JCL statement is continued onto the next card.

All commands, parameter names and values have to be in capitals, except for [[UNIX System Services|USS]] filenames.

All lines except for in-stream input (see below) have to begin with a slash "<code>/</code>", and all lines which the operating system processes have to begin with two slashes <code>//</code> - always starting in the ''first column''. However, there are two exceptions: the delimiter statement and the comment statement. A delimiter statements begins with a slash and an asterisk (<code>/*</code>), and a comment statement in OS JCL begins with a pair of slashes and asterisk (<code>//*</code>) or an asterisk in DOS JCL.

Many JCL statements are too long to fit within 71 characters, but can be extended on to an indefinite number of continuation cards by:
{| class="wikitable"
|-
! OS JCL !! DOS JCL
|-
| Ending all actual JCL cards except the last at a point where the syntax requires a comma (<code>,</code>) || Ending all actual JCL cards except the last at a point where the syntax requires a comma (<code>,</code>) and a non-blank character in column 72
|-
| Starting each continuation card with <code>//</code> in column 1 and then at least 1 space || Starting each continuation card with spaces and continuing in column 15
|}

The structure of the most common types of card is:<ref>Stern and Stern, ''Structured COBOL Programming'', pp. 529, 531.</ref>
{| class="wikitable"
|-
! OS JCL !! DOS JCL
|-
|
*<code>//</code>
*Name field for this statement, following <code>//</code> with no space between.  If this statement does not have a name at least one blank immediately follows the <code>//</code>.
*Space(s)
*Statement type
*Space(s)
*Parameters, which vary depending on the statement type, separated by commas and with no space between them.
||
*<code>//</code> (spaces if this is a continuation of a previous line)
*Statement type for this statement, following <code>//</code> with a space between.  
*Space(s)
*Name of resource
*Space(s)
*Parameters, which vary depending on the statement type, separated by commas and with no space between them. Positional parameters, followed by keyword parameters.
|}

===In-stream input===
DOS and OS JCL both allow in-stream input, i.e. "cards" which are to be processed by the application program rather than the operating system. Data which is to be kept for a long time will normally be stored on disk, but before the use of [[interactive]] terminals became common the only way to create and edit such disk files was by supplying the new data on cards.

DOS and OS JCL have different ways of signaling the start of in-stream input, but both end in-stream input with <code>/*</code> at column 1 of the card following the last in-stream data card. This makes the operating system resume processing JCL in the card following the <code>/*</code> card.<ref>Stern and Stern, ''Structured COBOL Programming'', pp. 529, 537.</ref>

*OS JCL: DD statements can be used to describe in-stream data, as well as data sets. A DD statement dealing with in-stream data has an asterisk (*) following the DD identifier, e.g. <code>//SYSIN DD *</code>. JCL statements can be included as part of in-stream data by using the DD DATA statements.
:An operand named '''DLM''' allowed specifying a delimiter (default is "/*"). Specifying an alternate delimiter allows JCL to be read as data, for example to copy procedures to a library member or to submit a job to the ''internal reader''.
:*An example,<ref>modeled on https://www.ibm.com/support/knowledgecenter/SSLTBW_2.2.0/com.ibm.zos.v2r2.hasc300/has2z1_Submitting_to_the_internal_reader_from_jobs_or_tasks.htm, using knowledge dating back to when Green Cards came from IBM, and Manix worked for a company owning an IBM card sorter</ref> which submits a job to the ''Internal Reader'' ('''INTRDR''') and then deletes two files is:
<syntaxhighlight lang="jcl" highlight="8,12,13">
//SUBM     EXEC PGM=IEBGENER
//SYSPRINT DD   SYSOUT=Z
//SYSUT2   DD   SYSOUT=(A,INTRDR)
//SYSIN    DD   DUMMY
//SYSUT1   DD   DATA,DLM=ZZ
//RUNLATR  JOB  ACCT,MANIX,CLASS=A.TYPRUN=HOLD
//* ^ a JOB to run later
//CPUHOG   EXEC PGM=PICALC1K
//OUTPUT   DD   DSN=PICALC.1000DGTS,SPACE=(TRK,1),DISP=(,KEEP)
ZZ
//* ^ as specified by DLM=ZZ
//DROPOLDR EXEC PGM=IEFBR14
//DELETE4  DD   DSN=PICALC.4DGTS,DISP=(OLD,DELETE)
//DELETE5  DD   DSN=PICALC.5DGTS,DISP=(OLD,DELETE)
</syntaxhighlight>
::# The program called PICALC1K will await (TYPRUN=HOLD) being released manually
::# The program called [[IEFBR14]] will run NOW and upon completion, the two existing files, PICALC.4DGTS and PICALC.5DGTS will be deleted.

*DOS JCL: Simply enter the in-stream data after the EXEC card for the program.

==={{anchor}}Complexity===
[[Fred Brooks]], who supervised the OS/360 project in which JCL was created, called it "the worst computer programming language ever devised by anybody, anywhere" in [[The Design of Design]], where he used it as the example in the chapter "How Expert Designers Go Wrong".<ref>{{Cite book |title=The Design Of Design |last=Brooks |first=Frederick P. |date=2010 |publisher=[[Addison-Wesley]] |isbn=978-0-201-36298-5 |pages=167-173}}</ref> He attributed this to the failure of the designers to realize that JCL is, in fact, a programming language.

Much of the complexity of OS JCL, in particular, derives from the large number of options for specifying [[Data set (IBM mainframe)|dataset]] information.  While files on [[Unix]]-like operating systems are abstracted into ordered streams of bytes, with the task of reading and writing structured data belonging exclusively with user-level programs (which, ultimately, ingest and emit such streams), and the practical details of data storage and access handled in large part by the operating system without the knowledge of user programs; datasets on OS/360 and its successors expose their file types and sizes, record types and lengths, block sizes, device-specific information like [[Magnetic tape data storage|magnetic tape]] density, and label information.  Although there are system defaults for many options, there is still a lot to be specified by the programmer, through a combination of JCL and information coded in the program.  The more information coded in the program, the less flexible it is, since information in the program overrides anything in the JCL; thus, most information is usually supplied through JCL.
 
For example, to [[File copying|copy a file]] on [[Unix]] operating system, the user would enter a command like:
 cp oldFile newFile

The following example, using JCL, might be used to copy a file on OS/360:
<syntaxhighlight lang="jcl" highlight="3">
//IS198CPY JOB (IS198T30500),'COPY JOB',CLASS=L,MSGCLASS=X
//COPY01   EXEC PGM=IEBGENER
//SYSPRINT DD SYSOUT=*
//SYSUT1   DD DSN=OLDFILE,DISP=SHR
//SYSUT2   DD DSN=NEWFILE,
//            DISP=(NEW,CATLG,DELETE),
//            SPACE=(CYL,(40,5),RLSE),
//            DCB=(LRECL=115,BLKSIZE=1150)
//SYSIN  DD DUMMY
</syntaxhighlight>

A second explanation for the complexity of JCL is the different expectations for running a job from those found in a [[IBM PC|PC]] or Unix-like environment.
*Low-end System/360 CPUs were less powerful and more expensive than the mid-1980s PCs for which MS-DOS was designed. OS/360 was intended for systems with a minimum memory size of 32&nbsp;KB and DOS/360 for systems with a minimum of 16&nbsp;KB. A [[IBM 2030|360/30]] CPU&mdash;low-end when System/360 was announced in 1964&mdash;processed 1.8K to 34.5K instructions per second.<ref>{{Cite web|url=http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2030.html|archive-url=https://web.archive.org/web/20041217213638/http://www-03.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP2030.html|url-status=dead|archive-date=December 17, 2004|title=IBM Archives: System/360 Model 30|date=2003-01-23|website=www-03.ibm.com|language=en-US|access-date=2016-04-25}}</ref> The first IBM PC in 1981 had 16&nbsp;KB or 64&nbsp;KB of memory and would process about 330K instructions per second.<ref name="vintageComputerIBMPC">{{Cite web |url=http://www.vintage-computer.com/ibm_pc.shtml |title=IBM PC |access-date=2007-10-21 |archive-date=2006-07-05 |archive-url=https://web.archive.org/web/20060705211337/http://www.vintage-computer.com/ibm_pc.shtml |url-status=dead }}</ref><ref name="iathVirginiaEduPCs">[http://www3.iath.virginia.edu/elab/hfl0108.html IBM-compatible computers] History of PCs {{webarchive |url=https://web.archive.org/web/20070814010809/http://www3.iath.virginia.edu/elab/hfl0108.html |date=August 14, 2007 }}</ref> As a result, JCL had to be easy for the ''computer'' to process, and ease of use by programmers was a much lower priority. In this era, programmers were much cheaper than computers.
*JCL was designed for [[batch processing]]. As such, it has to tell the operating system everything, including what to do depending on the result of a step. For example, <code>DISP=(NEW,CATLG,DELETE)</code> means "if the program runs successfully, create a new file and catalog it; otherwise delete the new file."  Programs run on a PC frequently depend on the user to clean up after processing problems.
*System/360 machines were designed to be shared by all the users in an organization. So the <code>JOB</code> card tells the operating system how to bill the user's account (<code>IS198T30500</code>), what predefined amount of storage and other resources may be allocated (<code>CLASS=L</code>), and several other things. <code>{{nowrap|1=//SYSPRINT DD SYSOUT=*}}</code> tells the computer to print the program's report on the default [[printer (computing)|printer]] which is loaded with ordinary paper, not on some other printer which might be loaded with blank checks. <code>DISP=SHR</code> tells the operating system that other programs can read <code>OLDFILE </code>[[multiprogramming|at the same time]].

Later versions of the DOS/360 and OS/360 operating systems retain most features of the original JCL&mdash;although some simplification has been made, to avoid forcing customers to rewrite all their JCL files.{{Citation needed|date=October 2012}} Many users save as a ''procedure'' any set of JCL statements which is likely to be used more than once or twice.<ref>{{cite book |last1=Brown |first1=Gary DeWard |title=zOS JCL |date=2002 |publisher=John Wiley & Sons |isbn=0471-236357 |page=248 |edition=fifth |url=https://books.google.com/books?id=K8kMJa8arlIC&pg=PA248}}</ref>

The syntax of OS JCL is similar to the syntax of [[Macro instruction|macros]] in System/360 [[assembly language]], and would therefore have been familiar to programmers at a time when many programs were coded in assembly language.