MW-009 · room 9 of 12 · 1960s

Submitted for Batch

You hand your work to an institution and are told to come back tomorrow.

You cannot hurry this exhibit, and you cannot see inside the queue. That is accurate.

Runs for about 28 seconds in real time. It cannot be skipped, because a wait you can skip is not a wait.

Museum label

Early computing was not interactive. A program was punched onto cards, handed to an operator, queued behind other people’s work, and run when the machine reached it. Results came back as printout, often the next day.

A single misplaced character cost a full day. This produced a discipline that is hard to imagine now: programs were checked by hand, on paper, repeatedly, because the cost of being wrong was measured in mornings.

The wait was scheduled by an institution rather than a machine. You were not waiting for computation. You were waiting for your turn.

Research dossier · MW-009-R

The wait behind the reconstruction.

Representative period
1950s–1970s
Mechanism
Institutional queue latency
Source records
3
01

Inside the machine

What was actually happening?

A batch system collects jobs and executes them with little or no interaction. Programs and data arrived as decks, tape or prepared files; operators controlled the expensive central machine.

Turnaround included every delay around computation: transport to the machine room, validation, queue position, mounting media, the run itself, printing and return. A syntax error that stopped in one second could still consume a day.

Batching was rational. Setup was expensive, machines were scarce and similar work could be grouped. The inconvenience to one programmer was part of keeping the institution's computer occupied.

02

Outside the machine

The human loop.

The queue changed programming style. Code was inspected on paper and mentally executed because feedback was not a conversational loop. A person learned to prepare questions worth spending a day to answer.

Authority was architectural. Operators could see the machine; most programmers could not. The job crossed a counter and entered a system whose internal order remained invisible.

Catalogue measurements

Three numbers to carry out of the room.

hoursone correction
A feedback cycle described by Corbató and colleagues in 1962
a full dayworst routine cycle
The paper's upper description for eliminating one error
0live dialogue
Results return after the run, not during it

Contemporary descendant

The wait did not disappear.

Batch never went away. Payroll, backups, scientific pipelines, CI builds and machine-learning jobs still wait in queues. The cards disappeared; the scheduler kept the institutional logic intact.

Open bibliography

Research notes.

The interpretation above is original. These institutional records support its technical claims and date ranges.

  1. 01
    The IBM 650

    IBM History · 2024 · museum

    Describes the operational shift from overnight card batches toward more continuous data processing.
  2. 02
    An Experimental Time-Sharing System

    MIT Computation Center · 1962 · paper

    Corbató, Daggett and Daley contrast interactive time-sharing with batch-monitor feedback loops in which correcting one program error could require hours or a full day.
  3. 03
    1961: Compatible Time-Sharing System is demonstrated

    Computer History Museum · 1961 · museum

    Places CTSS and other early general time-sharing systems in the shift from adapting a person's schedule to a batch machine toward multiple simultaneous terminal users.
Reconstruction notice

No commercial interface, logo, screenshot or recorded device audio is reproduced in this room. The apparatus compresses historical time to remain visitable; its mechanism and uncertainty are the objects being preserved.

Open the complete reference room →

Cross-reference desk

This room continues elsewhere.

The apparatus ends. Its mechanism passes into essays, archive fragments and other rooms where the same kind of delay changes scale.