Job control block

In computing job control refers to the control of multiple tasks or 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.

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

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. Unix-like systems follow this pattern.

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. 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 multitasking. More than one running program, or process, is present in the computer at any given time. If a process is unable to continue, its 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 scheduler, having the ability to interrupt and resume the execution of other processes. Typically a 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 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.

...
Wikipedia