Batch and Multiprogrammed Systems

Group if jobs submitted to machine together, Batch. A job was originally presented to the machine (and its human operator) in the form of a set of cards - these cards held information according to how ``punched'' out of the cardboard. The operator grouped all of the jobs into various batches with similar characteristics before running them (all the quick jobs might run, then the slower ones, etc.).

• Operator collects job, orders efficiently, runs one at a time
• Amortize setup costs over many jobs
• Keep machine busy while programmer thinks
• User must wait for results until batch collected and submitted

Result: Improved system throughput and utilization, but lost interactivity.
Since the I/O used slow mechanical devices, the CPU was often idle waiting on a card to be read or some result to be printed, etc. One way to minimize this inefficiency was to have a number of jobs available and to switch to running another one to avoid idleness.

• Mechanical I/O devices much slower than CPU
• Overlap I/O with execution by providing pool of ready jobs
• New OS Functionality evolved: Buffering, Direct Memory Access (DMA), interrupt handling

Result: Improves throughput and utilization.
In multiprogrammed systems, a number of programs were resident in memory and the CPU could choose which one to run. One way to choose is to just keep executing the current program until an I/O delay is pending - instead of just waiting, the CPU would move onto the next program ready to be run.

• Keep multiple jobs resident in memory
• OS chooses which job to run
• When job waits for I/O switch to another resident job

Result: Job scheduling policies, Memory management and protection, improves throughput and utilization, still not interactive.

Figure 1.2: Job Interleaving

Figure 1.3: Memory Layout; Simple Batch, Multi Programming