Job control (computing): Difference between revisions

Revision as of 17:24, 16 February 2017

Latest revision as of 13:56, 2 August 2025

(28 intermediate revisions by 10 users not shown)

Line 1:

{{aboutAbout |job control in general computing|Other|Job control (disambiguation)}}

|Unix-based job control| Job control (Unix)

{{unreferenced|date=November 2008}}

|the IBM Job Control Language| Job Control Language

In [[computing]] '''job control''' refers to the control of multiple tasks or [[Job (software)|jobs]] on a [[computer system]], ensuring that they each have access to adequate resources to perform correctly, that competition for limited resources does not cause a [[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.

|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 (softwarecomputing)|jobsjob]] on a [[computer system]],execution; ensuring that theyeach eachjob havehas 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 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:

* When to run a job

* atUnder times to also indicate under whatwhich 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 ==

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]].

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]]ssystems which take on the bulk of the work of job control.

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.

==History==

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.

A more general solution is [[Computer multitasking| multitasking]]. A Morecomputer thanexecutes onemultiple runningprograms, concurrently by loading a program, orinto a [[Process (computing)|process]], isthat presentcan inbe paused when the computerprocessor attime anycan givenbetter time.be used Iffor 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. The Atsoftware firstresponsible quitefor unsophisticatedcontext andswapping relying 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 needswaits to(i.e. interactdoes withnot peripheralsuse ora other processesperipheral) would simply hog the processor resource until it completed or was halted by manual interventioninterrupted. Other Theprocesses result,would particularlythen forbe interactivestarved systemsof runningprocessor tasksresources thatand frequentlymight interactbecome withslow. theThis outsidecan world,be isresolved thatvia the[[Preemption system(computing)|preemptive]] is sluggish and slow to react inmultitasking, a timely manner.k.a. time Thisslicing, problemin is resolved by allocating a "timeslice" towhich each process, ais periodswapping ofout uninterruptedafter executionit afterhas whichhad the schedulerprocessor automaticallyfor putsa itperiod onof the sleep queuetime. Further, Processa couldprocess can be given differenta priorities,priority andthat theallows schedulerit couldto thenbe allocategiven varyingmore shares of available execution timeaccess to eachthe process onrelative theto basislower ofpriority the assigned prioritiesprocesses.

==Language==

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

===Batch-oriented features===

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 (JCLs) 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 transmissiontransition to storage in computer files on disk.

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

====BANG and other non-IBM JCLs====

These include:

Non-IBM mainframe [[batch processing|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 computing|Interactive]] systems include "[[command language]]s"&mdash;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, [[Time Sharing Option|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.

* which program(s) to run

* using which file(s) &/or device(s)<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> for input/output, and

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<ref>what Xerox Data Systems and its SDS purchase called its ''exclamation mark'' {{cite web |title=Operating systems list |url=https://sites.google.com/site/thanhphong37vn/interview-questions-guide/operating-system/operating-systems-list}}</ref><ref>the SLASH SLASH of its JCL, called ''SLANT SLANT'' by some. The remainder of this footnote is a reminder, dedicated to the first person from whom I heard SLANT SLANT, the late senior computer operator and retired Military Officer who taught many people-oriented lessons. Let this be added to his citations.</ref> that has been quieted.

* at times to also indicate under what conditions to skip a step.

===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 [[computer terminal|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 (computing)|shell]].

=== File systems and device independence ===

The ability to not have to specify part or all of the information about a file or device to be used by a given program is called ''device independence''.

==Real-time computing==

{{main article|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."<ref name=X23>{{cite book

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."<ref>{{cite book

|url=http://www.bitsavers.org/pdf/sds/sigma/16-bit/rbm/901785A_Real-Time_Batch_Monitor_Users_Guide_Jan72.pdf

|title=Xerox Real-Time Batch Monitor (RBM), Sigma 2/3 Computers, User's Guide

|publisher=Xerox Corporation |accessdate=2017-02-16}}</ref>

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.<ref name=X23/>{{rp|p.1}} In the case of the Xerox RBM (Real-time/Batch Monitor) systems,<ref>a family: Scientific Data Systems SDS Sigma 2 & 3, renamed/combined as Xerox's acquired Xerox Data Systems, Xerox 530.</ref><ref>The SDS Sigma 5, 6 & 7 became the Xerox 560</ref><ref>{{cite book

==Job control languages==

|url=https://computerarchive.org/files/mirror/www.bitsavers.org/pdf/sds/sigma/rbm/901581A_Sigma5_RBM-2_Nov69.pdf

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 (JCLs) 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 transmission to storage in computer files on disk.

|title=XOs SIGMR 5/7 REAL-TIME BATCH MONITOR (RBM-2)|accessdate=2017-02-16}}</ref> for example, two other capabilities existed:<ref name=X23/>{{rp|p.2}}

* computer operator commands ("unsolicited key-in");

* background job streams ([[#Batch processing|batch jobs]]).

== External links ==

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 [[computer terminal|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 (computing)|shell]].

* [https://www.gnu.org/software/libtoolbash/manual/libchtml_node/Job-Control-Basics.html Job Control - The GNU C LibraryBasics]

== See also ==

* [[Command language]]

* [[Job Control Language]]

* [[Job control (Unix)]]

==External linksReferences ==

{{reflist}}

*[https://www.gnu.org/software/libtool/manual/libc/Job-Control.html Job Control - The GNU C Library]

[[Category:Computing terminology]]