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.
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.
Therefore, many details must be included in the submitted instructions: Early computer resident monitors and operating systems were relatively primitive and were not capable of sophisticated resource allocation.
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.
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.
For example, TSO on z/OS systems uses CLIST or Rexx as command languages along with JCL for batch work.
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[3][4] that has been quieted.
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.
"[5] 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.