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:

Job control has developed from the early days of computers when operators were responsible for setting up, monitoring and controlling jobs, to modern systems which take on the bulk of the work.

Early computer developers realized that computers spent most of their time idle because the software had to wait while a relatively slow peripheral completed an operation such as reading or writing data. Buffering provided a partial solution, but eventually an output buffer would occupy all available memory or an input buffer would be empty, and the system would then wait for a relatively slow device to complete its task.

A more general solution is multitasking. A computer executes multiple programs, concurrently by loading a program into a process that can be paused when the processor time can better be used for a process that is not waiting. The process's context is cached in memory and another process's context is used to resume execution of that process. The software responsible for context swapping is called the scheduler works with peripheral device drivers to suspend execution of the active process if the device is unable to complete an operation immediately, and the scheduler places the process on its queue of inactive jobs. When the peripheral completes the operation, the process available to be resumed by the scheduler. Similar suspension and resumption applies to any operation that may involve waiting, including asynchronous inter-process communication.

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

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.

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.