Job control (computing): Difference between revisions

Revision as of 13:02, 2 August 2025

Latest revision as of 13:56, 2 August 2025

(5 intermediate revisions by the same user not shown)

Line 4:

|all job control topics |Job control (disambiguation)}}

{{More citations needed|date=August 2017}}

In [[computing]], '''job control''' refers to the automated control of multiple tasks or [[Job (computing)|jobsjob]] on a [[Computer|computer system]],execution; ensuring that they each havejob has access to adequate resources to perform correctly, that competition for limited resources does not cause a [[Deadlock (computer science)|deadlock]] where two or more jobs are unable to complete, 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 [[Job control (Unix)|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.<ref>{{cite web

Job control has developed from [[History of computing|the early days of computers]] where human [[Computer operator|operators]] were responsible for setting up, monitoring and controlling every job, to modern [[operating system]]s, which take on the bulk of the work of job control.

|url=http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zmainframe/zconc_batchproc.htm

|title=Mainframe working after hours: Batch processing}}</ref> Job control is configured by [[programmer]]s who decide details including:

Even with a highly sophisticated scheduling system, some human intervention is desirable. Modern systems permit their users to stop and resume jobs, to execute them in the foreground (with the ability to interact with the user) or in the background. [[Job control (Unix)|Unix-like systems follow this pattern]].

* When to run a job

* underUnder 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

== History ==

Job control has developed from [[History of computing| the early days of computers]] where humanwhen [[Computer operator| operators]] were responsible for setting up, monitoring and controlling every jobjobs, to modern [[operating system]]s,systems which take on the bulk of the work of job control.

It became obvious to the early computer developers that their fast machines spent most of the time idle because the single program they were executing had to wait while a slow [[peripheral]] device completed an essential operation such as reading or writing data; in modern terms, programs were [[I/O-bound]], not [[compute-bound]]. [[Data buffer|Buffering]] only provided a partial solution; eventually an output buffer would occupy all available memory or an input buffer would be emptied by the program, and the system would be forced to wait for a relatively slow device to complete an operation.

It became obvious to the earlyEarly computer developers realized that their fast machinescomputers spent most of thetheir time idle because the single program they were executingsoftware had to wait while a relatively slow [[peripheral]] device completed an essential operation such as reading or writing data; in modern terms, programs were [[I/O-bound]], not [[compute-bound]]. [[Data buffer| Buffering]] only provided a partial solution;, but eventually an output buffer would occupy all available memory or an input buffer would be emptied by the programempty, and the system would be forced tothen wait for a relatively slow device to complete anits operationtask.

A more general solution is [[Computer multitasking|multitasking]]. More than one running program, or [[Process (computing)|process]], is present in the computer at any given time. If a process is unable to continue, its [[context (computing)|context]] can be stored and the computer can start or resume the execution of another process. At first quite unsophisticated and relying on special programming techniques, multitasking soon became automated, and was usually performed by a special process called the [[Scheduling (computing)|scheduler]], having the ability to interrupt and resume the execution of other processes. Typically a [[device driver|driver]] for a peripheral device suspends execution of the current process if the device is unable to complete an operation immediately, and the scheduler places the process on its [[job queue|queue]] of sleeping jobs. When the peripheral completed the operation the process is re-awakened. Similar suspension and resumption may also apply to [[inter-process communication]], where processes have to communicate with one another in an asynchronous manner but may sometimes have to wait for a reply.

A more general solution is [[Computer multitasking| multitasking]]. MoreA thancomputer oneexecutes runningmultiple programprograms, orconcurrently by loading a program into a [[Process (computing)|process]], isthat presentcan inbe paused when the computerprocessor attime anycan givenbetter time.be Ifused for a process that is unablenot towaiting. continue,The itsprocess's [[context (computing)|context]] canis becached storedin memory and theanother computerprocess's cancontext startis orused resumeto theresume execution of anotherthat process. AtThe firstsoftware quiteresponsible unsophisticatedfor andcontext relyingswapping on special programming techniques, multitasking soon became automated, and was usually performed by a special processis called the [[Scheduling (computing)|scheduler]], havingworks thewith ability to interrupt and resume the execution of other processes. Typically aperipheral [[device driver|driver]]s for a peripheral deviceto suspendssuspend execution of the currentactive process if the device is unable to complete an operation immediately, and the scheduler places the process on its [[job queue |queue]] of sleepinginactive jobs. When the peripheral completedcompletes the operation, the process isavailable re-awakenedto be resumed by the scheduler. Similar suspension and resumption applies to any operation that may alsoinvolve applywaiting; toincluding asynchronous [[inter-process communication]], where processes have to communicate with one another in an asynchronous manner but may sometimes have to wait for a reply.

However this low-level scheduling has its drawbacks. A process that seldom needs to interact with peripherals or other processes would simply hog processor resource until it completed or was halted by manual intervention. The result, particularly for interactive systems running tasks that frequently interact with the outside world, is that the system is sluggish and slow to react in a timely manner. This problem is resolved by allocating a "timeslice" to each process, a period of uninterrupted execution after which the scheduler automatically puts it on the sleep queue. Process could be given different priorities, and the scheduler could then allocate varying shares of available execution time to each process on the basis of the assigned priorities.

However, this scheduling has drawbacks. A process that seldom waits (i.e. does not use a peripheral) would hog the processor until it completed or was interrupted. Other processes would then be starved of processor resources and might become slow. This can be resolved via [[Preemption (computing)|preemptive]] multitasking, a.k.a. time slicing, in which each process is swapping out after it has had the processor for a period of time. Further, a process can be given a priority that allows it to be given more access to the process relative to lower priority processes.

This system of [[Preemption (computing)|pre-emptive]] multitasking forms the basis of most modern job control systems.

=={{anchor}}Batch processing==

{{main article|Batch processing}}

While batch processing can run around the clock, with or without computer operators,<ref>{{cite web

|url=http://publib.boulder.ibm.com/infocenter/zos/basics/index.jsp?topic=/com.ibm.zos.zmainframe/zconc_batchproc.htm

|title=Mainframe working after hours: Batch processing}}</ref> since the computer is much faster than a person, most decision-making occurs before the job even begins to run, and requires planning by the "programmer."

==Language==

=== Batch-oriented features ===

Although a computer operator may be present, batch processing is intended to mostly operate without human intervention. Therefore, many details must be included in the submitted instructions:

* which programs to run;

* which files and/or devices to use for input/output;<ref>and many more details, such as whether the file is to be retained or deleted, the maximum of disk space to which it can grow, the name of a tape to be pre-mounted</ref>

* under which conditions to skip a step.

==Job control languages==

===Batch===

Early computer [[resident monitor]]s and [[operating system]]s 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.