Job control (computing)

In computing, job control refers to the automated control of job execution – ensuring that each job has access to adequate resources to perform correctly, that competition for limited resources does not cause a deadlock, resolving such situations where they do occur, and terminating jobs that, for any reason, are not performing as expected. Even with sophisticated automation, most systems, such as Unix-like systems, permit manual operations such as interrupting, pausing and resuming jobs and to execute them in the foreground (interactively) instead of the usual background (batch) mode for fully automated execution. Job control, a.k.a. batch processing mostly proceeds without human intervention. Job control is configured by programmers who decide details including: * When to run a job * Under which conditions to skip a step * Which files and/or devices to use for input/output * Whether a file is to be retained or deleted * The maximum amount of storage that can be used

In computing, job control refers to the automated control of job execution – ensuring that each job has access to adequate resources to perform correctly, that competition for limited resources does not cause a deadlock, resolving such situations where they do occur, and terminating jobs that, for any reason, are not performing as expected. Even with sophisticated automation, most systems, such as Unix-like systems, permit manual operations such as interrupting, pausing and resuming jobs and to execute them in the foreground (interactively) instead of the usual background (batch) mode for fully automated execution. Job control, a.k.a. batch processing mostly proceeds without human intervention. Job control is configured by programmers who decide details including: When to run a job Under which conditions to skip a step Which files and/or devices to use for input/output Whether a file is to be retained or deleted The maximum amount of storage that can be used

Language

Batch

Early computer resident monitors and operating systems were relatively primitive and were not capable of sophisticated resource allocation. Typically such allocation decisions were made by the computer operator or the user who submitted a job. Batch processing was common, and interactive computer systems rare and expensive. Job control languages developed as primitive instructions, typically punched on cards at the head of a deck containing input data, requesting resources such as memory allocation, serial numbers or names of magnetic tape spools to be made available during execution, or assignment of filenames or devices to device numbers referenced by the job. A typical example of this kind of language, still in use on mainframes, is IBM's Job Control Language (also known as JCL). Though the format of early JCLs was intended for punched card use, the format survived the transition to storage in computer files on disk.

BANG and other non-IBM JCLs

Non-IBM 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. Interactive systems include "command languages"—command files (such as PCDOS ".bat" files) can be run non-interactively, but these usually do not provide as robust an environment for running unattended jobs as JCL. On some computer systems the job control language and the interactive command language may be different. For example, TSO on z/OS systems uses CLIST or Rexx as command languages along with JCL for batch work. On other systems these may be the same. The Non-IBM JCL of what at one time was known as the BUNCH (Burroughs, Univac/Unisys, NCR, Control Data, Honeywell), except for Unisys, are part of the BANG that has been quieted.

Interactive

As time sharing systems developed, interactive job control emerged. An end-user in a time sharing system could submit a job interactively from his remote terminal (remote job entry), communicate with the operators to warn them of special requirements, and query the system as to its progress. He could assign a priority to the job, and terminate (kill) it if desired. He could also, naturally, run a job in the foreground, where he would be able to communicate directly with the executing program. During interactive execution he could interrupt the job and let it continue in the background or kill it. This development of interactive computing in a multitasking environment led to the development of the modern shell.

Real-time computing

Pre-emptive multitasking with job control assures that a system operates in a timely manner most of the time. In some environments (for instance, operating expensive or dangerous machinery), a strong design constraint of the system is the delivery of timely results in all circumstances. In such circumstances, job control is more complex and the role of scheduling is more important. Since real-time systems do event-driven scheduling for all real-time operations, "the sequence of these real-time operations is not under the immediate control of a computer operator or programmer." However, a system may have the ability to interleave real-time and other, less time-critical tasks, where the dividing line might for example be response required within one tenth of a second. In the case of the Xerox RBM (Real-time/Batch Monitor) systems, for example, two other capabilities existed: computer operator commands ("unsolicited key-in"); background job streams (batch jobs).

Text derived from https://en.wikipedia.org/w/index.php?oldid=1328415234 under CC BY-SA 4.0; modifications have been made.