02 — The Mainframe Era: IBM, System/360, and the Birth of Modern OS Concepts
Technical Overview
The mainframe era, spanning roughly 1952 through the mid-1970s, established the foundational concepts of operating systems as we understand them today. Batch processing, spooling, multiprogramming, virtual memory, time-sharing, job control languages, memory protection — all of these were invented or refined during this period, driven primarily by the economics of expensive hardware that needed to be kept busy. IBM's System/360, announced in 1964, was perhaps the single most consequential product announcement in computing history: a compatible family of computers sharing a common instruction set architecture, establishing a model the industry still follows. This file traces the arc from early batch systems through IBM's dominance and the regulatory response that reshaped the industry.
Prerequisites
- Understanding of what a CPU, memory, and I/O devices are
- Basic familiarity with the concept of a program and execution
- Awareness that early computers were enormously expensive (millions of 1960s dollars)
Historical Context: Why Mainframes Mattered
In 1960, a large computer cost between $1 million and $10 million — perhaps $10–100 million in 2024 dollars. An organization that owned such a machine needed to extract maximum value from it. The machine should never sit idle. Every minute of idle CPU time was money evaporating. This economic pressure drove every OS innovation of the era: how do you keep a $5 million machine productive 24 hours a day?
The answer evolved through several stages:
- Open shop (1950s): Programmers ran their own jobs directly. Idle machine time while programmers debugged at the console was wasteful.
- Closed shop / batch processing: Professional operators managed job streams. Programmers submitted card decks; operators loaded and ran them in sequence.
- Spooling: Overlap slow I/O (card reading, printing) with CPU computation.
- Multiprogramming: Keep multiple jobs in memory; switch CPU to another job when one is waiting for I/O.
- Time-sharing: Give each user the illusion of their own interactive machine.
IBM System/360: The Revolutionary Architecture (1964)
Background
In the early 1960s, IBM had a fragmented product line. The IBM 701, 702, 704, 709, 7090, 7094, 1401, 1410, 7080 were incompatible with each other — different instruction sets, different word sizes, different I/O interfaces. A program written for the 704 could not run on the 7090. A business customer who outgrew their 1401 could not simply upgrade; they had to rewrite all their software.
IBM's solution was internally named Project Y and externally announced as System/360 on April 7, 1964 — a bet-the-company decision that IBM chairman Thomas Watson Jr. called "the most important product announcement in the company's history." He was right.
The System/360 Innovations
1. Compatible Family Architecture
System/360 was not a single computer but a family — Models 30, 40, 50, 60, 62, 65, 67, 70, 75, 85, 91, 195. The smallest model (30) cost ~$133,000; the largest (91) cost ~$5.5 million. All ran the same instruction set. A program written for the Model 30 would run on the Model 91 — faster, but correctly. This concept (ISA compatibility across a performance range) is now universal: Intel x86 chips from the 8086 to the current Xeon run the same instruction set.
2. The 8-Bit Byte
The System/360 standardized on the 8-bit byte as the fundamental data unit. Earlier computers used 6-bit characters, 12-bit words, or other sizes. The 8-bit byte, which can represent 256 values (enough for upper/lower case letters, digits, punctuation, and control codes), became the universal standard. Every byte in every computer today traces this decision to 1964.
3. Microprogramming
Each Model in the System/360 family implemented the same ISA but using different underlying hardware. The translation between System/360 instructions and the actual hardware operations was accomplished via microprogramming (a concept from Maurice Wilkes): a small, fast read-only memory (the control store) held sequences of micro-operations that implemented each machine instruction. Different hardware could execute the same ISA by having different microcode. This enabled the family concept at manageable hardware cost.
4. Memory Protection Hardware
The System/360 added hardware memory protection keys: each 2KB block of memory had a 4-bit protection key. The CPU had a current key. An access to a block was permitted only if the keys matched (or the program was in supervisor mode). This hardware primitive made it possible to have an OS that protected itself from user programs — essential for multiprogramming.
5. OS/360
IBM shipped OS/360 to run the System/360 family. It was the most complex software project yet attempted. Fred Brooks managed the OS/360 development and documented his experience in The Mythical Man-Month (1975), which introduced Brooks's Law: "adding manpower to a late software project makes it later." OS/360 was famously late and buggy on delivery — but it worked, and it introduced concepts that persist today.
System/360 Architecture Diagram
System/360 Address Space (24-bit = 16MB max)
+------------------------------------------+
| 0x000000 |
| PSW (Program Status Word) at 0x000000 | <- Supervisor area
| Interrupt vectors |
| I/O Channel programs |
+------------------------------------------+
| OS/360 nucleus (supervisor) | <- Protected (key 0)
| - Job scheduler |
| - I/O supervisor |
| - Memory management |
+------------------------------------------+
| User partition A (key 1) |
| Job 1 executing here |
+------------------------------------------+
| User partition B (key 2) |
| Job 2 waiting for tape I/O |
+------------------------------------------+
| User partition C (key 3) |
| Job 3 just loaded |
+------------------------------------------+
| 0xFFFFFF |
+------------------------------------------+
Memory Protection Key mechanism:
CPU current key === Block key --> ACCESS OK
CPU current key =/= Block key --> PROTECTION FAULT
CPU in supervisor mode (key 0) --> ACCESS OK always
System/360 General Register Architecture
16 x 32-bit General Purpose Registers: R0-R15
4 x 64-bit Floating Point Registers
Instruction Formats (all 16 or 32 or 48 bits wide):
RR format: [opcode 8][R1 4][R2 4]
RX format: [opcode 8][R1 4][X2 4][B2 4][D2 12]
SS format: [opcode 8][L1 4][L2 4][B1 4][D1 12][B2 4][D2 12]
Memory addressing: base register + displacement
(R12 or R13 conventionally used as base register)
OS/360 and Mainframe OS Concepts
Batch Processing and Job Control Language (JCL)
OS/360 introduced Job Control Language — a formal notation for describing jobs to the operating system. A job was a unit of work with input datasets, output datasets, step sequences, and resource requests. JCL survived and is still used on IBM z/OS mainframes today:
//MYJOB JOB (ACCT),'MY NAME',CLASS=A,MSGCLASS=X
//STEP1 EXEC PGM=IEFBR14
//INDD DD DSN=MY.INPUT.DATASET,DISP=SHR
//OUTDD DD DSN=MY.OUTPUT.DATASET,DISP=(NEW,CATLG),
// SPACE=(CYL,(10,5),RLSE),
// DCB=(RECFM=FB,LRECL=80,BLKSIZE=8000)
JCL is notoriously complex — every field has specific column positions, every comma matters, and a missing parameter can abort a job silently. It was designed for batch submission, not human readability, and it shows.
Spooling
SPOOL: Simultaneous Peripheral Operations On-Line. The fundamental insight: I/O devices (card readers, line printers, tape drives) are orders of magnitude slower than the CPU. If the CPU waits for a card reader to load the next deck or a printer to finish printing, most CPU time is wasted.
Spooling decouples these:
Card Reader --> Disk (input spool) --> CPU processes jobs --> Disk (output spool) --> Printer
Slow I/O Fast I/O CPU runs at Fast I/O Slow I/O
(~1000 cpm) (millions/sec) full speed (millions/sec) (~1200 lpm)
A separate program (the reader and writer tasks) handled reading cards to disk and printing from disk, running concurrently with the main job stream. The CPU saw a fast stream of pre-loaded jobs; the actual physical devices ran at their own pace.
Multiprogramming: OS/MFT and OS/MVT
OS/MFT (Multiprogramming with a Fixed number of Tasks): Memory was divided into fixed partitions, each holding one job. While Job A waited for I/O, the CPU ran Job B. Simple but wasteful if job sizes didn't match partition sizes.
OS/MVT (Multiprogramming with a Variable number of Tasks): Partitions were dynamically sized to fit each job. More efficient memory use, but introduced fragmentation problems — over time, memory filled with small unusable gaps between jobs. MVT needed memory compaction (moving jobs around in memory) to consolidate free space, which required hardware relocation support.
OS/MFT Memory Layout (Fixed partitions):
+------------------+
| OS nucleus | Fixed size, always present
+------------------+
| Partition 1 | Fixed 200KB - Job A (running)
| Job A (200KB) |
+------------------+
| Partition 2 | Fixed 300KB - Job B (waiting for tape)
| Job B (280KB) |
| (20KB wasted) | <-- internal fragmentation
+------------------+
| Partition 3 | Fixed 400KB - empty, waiting for job
| (empty) | <-- idle partition
+------------------+
OS/MVT Memory Layout (Variable partitions):
+------------------+
| OS nucleus |
+------------------+
| Job A (200KB) | Exact fit
+------------------+
| Job B (340KB) | Exact fit
+------------------+
| Hole (60KB) | External fragmentation - too small for next job
+------------------+
| Job C (380KB) | Exact fit
+------------------+
Time-Sharing Origins
John McCarthy's Proposal (1959)
John McCarthy, at MIT in 1959, wrote a memo proposing that computers could be shared interactively among many users simultaneously, each getting a small time slice, each having the illusion of their own computer. This was a radical departure from batch thinking — instead of waiting hours for your deck of cards to be processed, you would type a command and get a response in seconds.
CTSS: Compatible Time-Sharing System (MIT, 1961)
CTSS was implemented on a modified IBM 7094 at MIT's Computation Center. It supported up to 30 simultaneous users, each with a terminal (teletype). Time slices were approximately 200ms. CTSS introduced:
- Interactive command-line interface — users typed commands and saw responses
- User authentication — password-protected accounts
- File system with per-user directories — each user had their own file space
- Mail — an early electronic mail system (1965, on CTSS)
CTSS was a technical success but ran on specialized hardware with custom memory modifications. Its lessons fed directly into Multics.
Multics: The Most Ambitious OS Ever Attempted (1969)
Multics (Multiplexed Information and Computing Service) was a joint project of MIT, Bell Labs, and GE, targeting the GE-645 computer. Its ambitions were staggering:
- Rings of protection: Concentric privilege rings (ring 0 most privileged, ring 7 least). System calls crossed rings via controlled gates. Hardware enforced ring transitions. This concept is directly realized in x86 rings 0–3 (though modern x86 only uses rings 0 and 3 in practice).
- Segments: Memory was divided into named segments; addressing was by segment name + offset. The hardware translated segment names to physical addresses.
- Hierarchical filesystem: Files organized in a directory tree (radical at the time — most systems had flat namespaces).
- Single-level store: Files were memory-mapped; persistent storage and RAM were a single unified address space. No explicit "open file and read it" — you just accessed memory addresses that happened to be backed by disk.
- Dynamic linking: Libraries loaded on demand at runtime.
Multics was called a failure because it was late, over budget, and ran on expensive hardware few could afford. But "failure" is misleading: Multics ran until 2000 at a Canadian defense research lab. Its concepts directly shaped Unix — Ken Thompson and Dennis Ritchie worked on Multics at Bell Labs, absorbed its ideas, and built a simpler system (initially called "Unics," a pun on Multics) when Bell Labs withdrew from the project.
Multics Ring Protection Model:
ring 0 (kernel, most privileged)
+--+------+--+
/ | MCP | \
/ +------+ \
/ ring 1 (OS) \
/ +----------------+ \
/ | File system | \
/ | I/O subsystem | \
/ +----------------+ \
| ring 2 (trusted libs) |
| +----------------------+ |
| | runtime libraries | |
| | system utilities | |
| +----------------------+ |
| ring 3..7 (user code) |
| +---------+ +---------+ |
| | User A | | User B | |
| | program | | program | |
| +---------+ +---------+ |
\ /
+-------------------------+
Crossing inward: requires hardware gate (controlled)
Crossing outward: returns from system call
IBM 370 and Virtual Memory (1972)
The IBM System/370, announced in 1970, added hardware virtual memory support. The IBM 370/158 and 168 introduced dynamic address translation (DAT): the hardware automatically translated 24-bit virtual addresses to physical addresses using a two-level page table, with a Translation Lookaside Buffer (TLB) for performance.
Before virtual memory, a program had to fit in physical memory. With virtual memory: - Programs could be larger than physical RAM (pages swapped to disk as needed) - Each program ran in its own address space (isolation) - Memory sharing was possible (map same physical page into multiple address spaces) - Physical memory layout was hidden from programs (relocation became trivial)
MVS (Multiple Virtual Storage), released in 1974, gave every batch job its own 16MB virtual address space — revolutionary when most physical memory was 2–8MB. A job's virtual address space could exceed physical memory by orders of magnitude.
IBM's Dominance and the Antitrust Suit (1969)
By the late 1960s, IBM had approximately 70% of the global computer market. Competitors existed — Burroughs, Univac, NCR, Control Data, Honeywell, GE, RCA — often called "the BUNCH" — but IBM's revenue exceeded all of them combined. IBM hardware, software, services, and maintenance were bundled: if you bought an IBM computer, you bought IBM's software and IBM's service contract.
On January 17, 1969 (the final day of the Johnson administration), the US Department of Justice filed antitrust suit against IBM: United States v. IBM. The complaint alleged IBM had monopolized the general-purpose digital computer market.
The Unbundling Decision: IBM did not wait for the lawsuit's outcome. In June 1969, IBM announced it would "unbundle" its software and services — charging separately for software that had previously been included with hardware. This single decision created the commercial software industry. Before 1969, software had no stand-alone economic value (it was perceived as a "free" service that came with hardware). After 1969, software was a product with a price — and companies like Microsoft were possible.
The DOJ suit dragged on for 13 years, generating 66 million pages of documents, before the Reagan administration dropped it in 1982 as "without merit." IBM's behavior had already changed the industry regardless.
Production Relevance
IBM mainframes are not historical artifacts. As of 2024: - The IBM z16 mainframe runs more than 70% of global financial transaction data - Every ATM transaction, most airline reservations, and much insurance processing runs on or through z/OS (MVS's direct descendant) - z/OS runs JCL written in the 1970s alongside modern Java applications — the compatibility story that began with System/360 is unbroken
The OS concepts invented in this era are everywhere: - Memory protection (kernel vs user mode) is in every CPU - Virtual memory is universal - Job scheduling concepts are in every OS scheduler - Spooling concepts live in printer queues and message queues - Multiprogramming is what we now call multitasking
Key Figures
| Person | Role |
|---|---|
| Thomas J. Watson Jr. | IBM chairman who approved the System/360 bet |
| Gene Amdahl | Chief architect of System/360 (later founded Amdahl Corporation) |
| Fred Brooks | OS/360 project manager; wrote The Mythical Man-Month |
| John McCarthy | Time-sharing concept (1959), later invented Lisp and AI term |
| Fernando Corbató | CTSS and Multics designer; Turing Award 1990 |
| Jack Dennis | MIT, early virtual memory and paging concepts |
Lessons Learned
-
ISA compatibility is enormously valuable. The System/360's compatibility promise — your software investment is protected — drove customer lock-in that persists 60 years later. Intel's x86 compatibility and ARM's backward compatibility reflect the same economics.
-
OS complexity was underestimated from the beginning. OS/360 was the first major demonstration that software projects don't scale linearly with team size. Brooks's observations remain accurate.
-
Monopoly accelerates standardization but retards innovation. IBM's dominance standardized the industry around 8-bit bytes and compatible families, but also meant no competition on pricing and service quality — exactly what the antitrust suit targeted.
-
Unbundling created an industry. The decision to charge separately for software — forced by antitrust pressure — created the entire commercial software market. The lesson: economic model changes can be more transformative than technology changes.
-
Multics "failed" forward. The most ambitious OS project of its era missed its goals but seeded Unix, which seeded Linux and macOS and Android. Grand ambitious failures in systems often matter more in the long run than conservative successes.
Exercises
- Write a simple multiprogramming simulator in Python: have three "jobs" with random CPU bursts and I/O waits. Show CPU utilization with and without multiprogramming.
- Research IBM's JCL and write a sample JCL job that reads an input file, runs a program, and writes output. (IBM provides a free z/OS trial.)
- Draw a Multics ring diagram and map it to the x86 privilege ring model (rings 0-3). Where does the OS live in each? Where does user code live?
- Calculate: if a System/360 Model 30 had 64KB of RAM and OS/360 nucleus needed 32KB, how many simultaneous jobs could run using OS/MFT with 8KB partitions?
- Research the IBM 360/67 (the time-sharing model). How did its virtual memory support differ from the standard System/360?
References
- Brooks, F.P. Jr. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.
- Bashe, C.J. et al. (1986). IBM's Early Computers. MIT Press.
- Corbató, F.J. et al. (1962). "An Experimental Time-Sharing System." AFIPS Spring Joint Computer Conference.
- Organick, E.I. (1972). The Multics System: An Examination of its Structure. MIT Press.
- Pugh, E.W. (1995). Building IBM: Shaping an Industry and Its Technology. MIT Press.
- Fisher, F.M., McKie, J.W., Mancke, R.B. (1983). IBM and the U.S. Data Processing Industry. Praeger.
- Denning, P.J. (1970). "Virtual Memory." ACM Computing Surveys.