[1] The purpose of JCL is to say which programs to run, using which files or devices[2] for input or output, and at times to also indicate under what conditions to skip a step.
[3] The VM operating system does not have JCL as such; the CP and CMS components each have command languages.
[8] JCL was developed as a means of ensuring that all required resources are available before a job is scheduled to run.
For example, many systems, such as Linux allow identification of required datasets to be specified on the command line, and therefore subject to substitution by the shell, or generated by the program at run-time.
For example, before the days of relational databases, 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; 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.
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 cards.
Much of the complexity of OS JCL, in particular, derives from the large number of options for specifying 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 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.
For example, to copy a file on Unix operating system, the user would enter a command like: The following example, using JCL, might be used to copy a file on OS/360: A second explanation for the complexity of JCL is the different expectations for running a job from those found in a PC or Unix-like environment.
Later versions of the DOS/360 and OS/360 operating systems retain most features of the original JCL—although some simplification has been made, to avoid forcing customers to rewrite all their JCL files.
DOS JCL parameters are positional, which makes them harder to read and write, but easier for the system to parse.
This statement links a program's internal description of a dataset to the data on external devices: disks, tapes, cards, printers, etc.
The DD may provide information such as a device type (e.g. '181','2400-5','TAPE'), a volume serial number for tapes or disks, and the description of the data file, called the DCB subparameter after the Data Control Block (DCB) in the program used to identify the file.
From the very beginning, the JCL for the OS family of operating systems offered a high degree of device independence.
Even for new files which were to be kept after the end of the job one could specify the device type in generic terms, e.g., UNIT=DISK, UNIT=TAPE, or UNIT=SYSSQ (tape or disk).
For example: OS JCL procedures were parameterized from the start, making them rather like macros or even simple subroutines and thus increasing their reusability in a wide range of situations.
The PROC statement, in addition to giving the procedure a name, allows the programmer to specify default values for each parameter.
In early versions of the OS (certainly before OS/360 R21.8) the block length must be in decreasing order, or the user must inspect each instance and append to the named DD statement the maximum block length found, as in, for example, In later versions of the OS (certainly after OS/MVS R3.7 with the appropriate "selectable units") the OS itself, during allocation, would inspect each instance in a concatenation and would substitute the maximum block length which was found.
A usual fallback was to simply determine the maximum possible block length on the device, and specify that on the named DD statement, as in, for example, The purpose of this fallback was to ensure that the access method would allocate an input buffer set which was large enough to accommodate any and all of the specified datasets.
For example: means: This translates to the following pseudocode: Note that by reading the steps containing COND statements backwards, one can understand them fairly easily.
The utilities can be grouped into three sets: OS JCL is undeniably complex[31] and has been described as "user hostile".
[32][33] As one instructional book on JCL asked, "Why do even sophisticated programmers hesitate when it comes to Job Control Language?
As one Fortran IV textbook said when listing possible error messages from the WATFOR compiler: "Have you been so foolish as to try to write your own 'DD' system control cards?
"[35] Nevertheless, some books that went into JCL in detail emphasized that once it was learned to an at least somewhat proficient degree, one gained freedom from installation-wide defaults and much better control over how an IBM system processed your workload.
Example: Other mainframe batch systems had some form of job control language, whether called that or not; their syntax was completely different from IBM versions, but they usually provided similar capabilities.
For example, TSO on z/OS systems uses CLIST or Rexx as command languages along with JCL for batch work.