Mainframe Era
On 7 April 1964, IBM announced the System/360. The announcement did not describe a computer. It described a family of computers that shared one instruction set, one set of data formats, one input-output interface, and one body of software, spanning a performance range in which the largest machine outran the smallest by more than an order of magnitude. Nothing quite like it had been offered before, and the idea behind it, that a computer architecture is a specification separable from the hardware that implements it, turned out to be the most durable engineering idea of the period. The instruction set announced that day is still executing, under the name z/Architecture, more than sixty years later.
This article covers the System/360 generation and the industry structure it created: what was genuinely new in the architecture, the hybrid circuit technology IBM built to implement it, the cost and risk of the program, the operating system that became the founding case study of software project management, the System/370 successor with its virtual memory and virtual machines, the competitors who tried to live beside IBM, the plug-compatible manufacturers and leasing companies who lived off it, and the antitrust litigation that shaped the whole period.
Two boundaries are worth stating at the outset. The first-generation commercial machines that preceded this era, from the UNIVAC I of 1951 through the IBM 701, the 650, and the transistorized 7090 and 1401, belong to Computer Industry Origins, which treats how computing became a commercial industry at all. The smaller, cheaper, interactive machines that grew up beside the mainframe and eventually undermined it belong to the Minicomputer Era. This article sits between them, and concerns the machines at the center of the data processing department: what made them coherent, what made them expensive, and why the architecture outlived every company that tried to compete with it.
The Problem: An Incoherent Product Line
By the early 1960s, IBM had a commercial problem disguised as an engineering problem. The company sold several substantially incompatible computer lines at once. The 1401 and its relatives were character-oriented decimal machines aimed at business data processing, with variable-length fields and a fast chain printer. The 7090 and 7094 were 36-bit binary machines aimed at science and engineering. The 7070 and 7080 families occupied the middle, and the small 1620 sat below them. A program written for one line would not run on another. Neither would the peripherals, the tape formats, the training, or the operating conventions.
The cost of that fragmentation fell on both sides of the sale. IBM funded separate development teams, compiler efforts, peripheral engineering, and field support for each line. Customers paid the larger price: an installation that outgrew a 1401 could not simply move to a bigger machine, because moving meant rewriting the application programs, retraining the staff, and reworking the file formats. Growth was therefore an occasion to reconsider the vendor, which is precisely what a vendor with a large installed base does not want.
Competitors understood this. Honeywell announced the H-200 in 1963 with a translation program called Liberator, which converted IBM 1401 programs to run on Honeywell hardware. The proposition was blunt: since a customer leaving the 1401 must convert software anyway, the conversion may as well be to a cheaper machine. The threat to IBM's most successful product was direct, and it sharpened an internal argument that had been running for some time.
That argument was settled by a task group whose acronym, SPREAD, has since become part of the industry's founding literature. Its report at the end of 1961 recommended that IBM abandon its separate lines and build one compatible family covering the whole range, from small commercial installations to large scientific ones. The recommendation was radical in a specific way. It meant that IBM would obsolete every product it currently sold, simultaneously, and stake the company on a design that did not yet exist. Gene Amdahl became the chief architect of the resulting machine, working with Gerrit Blaauw and Frederick Brooks, and the three published the architectural description in the IBM Journal of Research and Development in April 1964, the month of the announcement.
What Was Announced in April 1964
The announcement covered six processor models and roughly forty peripheral devices. The processors were designated Models 30, 40, 50, 60, 62, and 70; the three largest were superseded by the Models 65 and 75 before they shipped, which is why the delivered range is usually remembered as 30 through 75. Later members extended the family in both directions: the Model 20 below, a reduced subset that was not fully compatible; the Model 44 for scientific work, also only partly compatible; the Model 67 with address translation hardware; and the very large Models 91, 95, and 195 at the top.
The name encoded the claim. The full circle of 360 degrees stood for all-around coverage: commercial and scientific work on one machine, where each had previously required its own architecture. The System/360 unified them by supporting binary integer arithmetic, packed decimal arithmetic, and hexadecimal floating point in a single instruction set, so a payroll program and a differential equation solver could run on the same processor without either being handicapped.
Compatibility was defined precisely, and the precision mattered. A program written in the problem state, using only the non-privileged instructions and the standard input-output interfaces, would produce identical results on any model in the family, subject to having enough main storage and the necessary devices. Programs that used privileged instructions, depended on timing, or exploited undocumented behavior were not covered, and the architects said so. This was the first time a manufacturer had drawn a formal line between the behavior a customer could rely on and the implementation details that were free to change.
Architecture Separated from Implementation
The intellectual core of the System/360 is a distinction that engineers now take for granted and that the project made explicit. The architecture is what the programmer sees: the instruction set, the registers, the data formats, the addressing rules, the interrupt structure, and the input-output interface. The implementation is how a particular machine achieves that behavior: how wide the internal data paths are, how many cycles an instruction takes, whether control is hardwired or interpreted, how memory is banked. The System/360 team used the word architecture in this sense and gave it the currency it has today. The general subject is treated in Instruction Set Architecture.
Separating the two allowed one specification to be realized by machines with almost nothing in common physically. A Model 30 moved data eight bits at a time internally; a Model 75 moved it in much wider units and overlapped operations. Both executed the same ADD instruction on the same operands and produced the same result and the same condition code. The customer bought a position on a price and performance curve rather than a distinct machine, and could move along that curve without touching the software.
The technique that made the small and middle models economic was microprogramming. Maurice Wilkes had proposed in 1951 that a processor's control logic be built as a small stored program rather than as a fixed network of gates, with each machine instruction interpreted by a sequence of simpler control words. IBM adopted the idea at scale. Most System/360 models held their control words in read-only storage, and the instruction set the customer saw was produced by interpretation rather than by dedicated hardware. Only the Model 44 and the largest and most expensive machines, among them the Models 75, 91, 95, and 195, used hardwired control, where the cost of custom logic was justified by the performance it bought.
Microprogrammed control had a second use that eased the transition IBM was asking its customers to make. Load a different set of control words, add modest hardware assistance, and a System/360 could interpret the instruction set of an older machine. IBM shipped emulators that ran IBM 1401 programs on the Model 30 and 7000-series programs on larger models, in several cases faster than the original hardware had run them. A customer could therefore move to the new family and keep the old workload running unchanged while the conversion proceeded on its own schedule. Emulation converted a wrenching migration into a gradual one, and it is one of the reasons the family succeeded commercially rather than merely technically.
The freedom this granted implementers is best illustrated at the top of the range. The Model 91 executed instructions out of program order to keep its floating-point units busy. Robert Tomasulo published the algorithm in the IBM Journal of Research and Development in January 1967, describing reservation stations and implicit register renaming that resolved data hazards dynamically. The programmer saw the same architecture as on a Model 30, while the machine underneath did something the architecture never mentioned. The technique, unchanged in principle, is in every high-performance processor built today.
The Byte, the Word, and EBCDIC
Several conventions that now look like facts of nature were choices made for the System/360. The most consequential was the eight-bit byte as the addressable unit of memory. Earlier machines had used six-bit characters, or addressed words rather than characters, or supported variable-length fields with explicit delimiters. The System/360 made memory a linear array of eight-bit bytes, each individually addressable, with halfwords, words, and doublewords defined as aligned groups of two, four, and eight bytes. Six bits held enough codes for uppercase letters, digits, and a modest set of symbols; eight bits held enough for upper and lower case together, plus control codes and room for expansion, and divided evenly into two hexadecimal digits and two packed decimal digits. There was internal pressure during development to save money by making the byte four or six bits wide. The eight-bit choice survived, and effectively every architecture since has followed it.
Addresses were twenty-four bits, giving sixteen megabytes of directly addressable storage. In 1964 that ceiling was extravagant, since typical machines held tens or hundreds of kilobytes of magnetic core. It nonetheless became the family's most persistent constraint, and lifting it consumed a great deal of engineering effort two decades later. The address space is the one architectural decision that ages fastest.
Character encoding went the other way. The American Standard Code for Information Interchange had been published in 1963, and IBM participated in its development, but the company's own punched-card equipment used a decimal card code whose collating and zone structure did not map cleanly onto the new standard. IBM extended its card-derived code to eight bits and called the result the Extended Binary Coded Decimal Interchange Code, or EBCDIC. The architecture hedged: a mode bit in the program status word selected an alternative eight-bit ASCII interpretation for the decimal instructions and the editing functions. The operating systems and utilities never supported it, the hedge went unused, and when System/370 arrived the same bit was redefined to select the new extended control mode. EBCDIC therefore survived, and remains the native encoding of the platform, which is why moving data between mainframe and non-mainframe systems still requires a translation step.
Standard Input-Output: Channels and the Interface
A compatible processor family is of limited use if each model needs different peripherals, so the System/360 standardized the connection between processors and devices. Input and output were handled by channels, which are specialized processors that execute their own programs. The central processor issued a START I/O instruction naming a device and a channel program, and then returned to other work. The channel fetched channel command words from memory, moved data between the device and main storage without further processor involvement, and raised an interrupt when the operation finished or failed. Two channel types covered the range of device speeds: byte-multiplexer channels interleaved data from many slow devices such as card readers, printers, and terminals, while selector channels dedicated their full bandwidth to one fast device at a time, typically a disk or tape drive. Block multiplexer channels were added later to give fast devices the ability to disconnect during mechanical delays. The architectural ideas are examined further in Input/Output Systems.
Between the channel and the device sat a control unit, and between the channel and the control unit sat a defined electrical and logical interface, carried on the pair of cables that everyone in the field called bus and tag. Because that interface was specified rather than model-specific, a tape drive attached to a small machine attached equally to a large one. IBM gained an enormous simplification of its own product line: peripherals were engineered once for the whole family.
Storage devices developed rapidly within this framework. The 2311 disk drive, with a removable pack holding on the order of seven megabytes, and the larger 2314 that followed, gave installations direct-access storage in quantity, and removability meant capacity could be extended from a shelf of packs. Software conventions followed: catalogued data sets, access methods that hid physical record layout from the application, and job control statements that bound program names to device addresses at run time rather than at compile time. That indirection is why a program moved between installations with different equipment without being recompiled.
The standard interface also had a consequence IBM did not intend. A specification precise enough for IBM's own peripheral divisions to build against was precise enough for anyone else to build against. Within a few years, independent manufacturers were attaching their own tape and disk drives to IBM channels, and the plug-compatible industry was born out of a decision made for internal engineering economy.
Solid Logic Technology
The System/360 is often described as a third-generation machine, meaning one built from integrated circuits. That description is not quite right, and the reason it is not quite right is instructive.
IBM implemented the family with a proprietary hybrid technology called Solid Logic Technology. An SLT module was a small square ceramic substrate, roughly half an inch on a side, on which resistors were screen-printed as thick-film conductive paste and fired, and to which individually packaged silicon transistors and diodes were then soldered. The semiconductor devices were tiny glass-encapsulated chips attached face down with solder balls, an early production use of the flip-chip technique that IBM developed for the purpose. Several modules mounted on a small printed circuit card formed a logic function; cards plugged into boards, and boards into gates and frames.
SLT was therefore neither discrete construction nor monolithic integration. Each transistor was a separate die, but the interconnection, the passive components, and the packaging were manufactured collectively. The intermediate position was deliberate. When the technology decision had to be made, around 1961 and 1962, monolithic integrated circuits were laboratory-grade products: yields were low, functions were limited to a few gates, prices restricted them to military and aerospace programs, and no supplier could promise the volumes IBM would need. The state of the art at that moment is described in Integrated Circuit Breakthrough. Betting the largest program in the company's history on an immature outside supply chain was not an acceptable risk.
Hybrid modules solved several problems at once. Yields were high because each component was tested before assembly and a failed device cost only that device rather than the whole substrate. Speed was competitive with what monolithic parts of the period could deliver. Packaging density was far better than discrete construction on printed circuit boards. Most important, IBM controlled the entire process. The company built a plant at East Fishkill in New York's Hudson Valley specifically to make SLT modules, and by the middle of the decade production ran into the tens of millions of modules a year, a scale no merchant semiconductor supplier of the time could have matched on demand.
The conservatism was confined to logic. Main storage remained magnetic core throughout the System/360 generation, as it had been since the mid-1950s, because semiconductor memory was not yet competitive on cost per bit; the technologies that eventually displaced it are surveyed in Memory Devices. Monolithic circuits arrived with the successor family. The System/370 used monolithic integrated circuits for logic from the start, and the Model 145, announced on 23 September 1970, was the first IBM machine whose main storage was semiconductor rather than core. The lesson of SLT is not that IBM misjudged integrated circuits. It is that a company committing five billion dollars to a single program chooses the technology it can guarantee, and pays for the guarantee.
The Cost and the Risk
The scale of the commitment is what makes the System/360 a business story as much as an engineering one. Fortune examined the program in September 1966 in an article by T. A. Wise titled "I.B.M.'s $5,000,000,000 Gamble," and the figure has stuck. Against an internal estimate of roughly $675 million made in 1962, the program as delivered cost about five billion dollars, of which the great majority went to new plant and to purchased and rented capital equipment. The company built new factories, among them East Fishkill, and added tens of thousands of employees during the ramp.
Software was the largest proportional overrun. The programming effort had been estimated in the range of thirty to forty million dollars and finished closer to five hundred million. That miss, more than an order of magnitude, is the origin of the software engineering literature discussed below, and it was not the result of incompetence. It was the result of estimating an unprecedented artifact by analogy with much smaller ones.
The risk was concentrated rather than spread. IBM announced the obsolescence of its entire product line on one day, before the replacement could be built in quantity, and asked customers to wait. Orders ran ahead of production, deliveries slipped, core memory was short, and the first operating system releases were late and limited. Had a competitor been positioned to absorb the resulting frustration the outcome might have differed, but building a comparable family required comparable capital, and the announcement had just demonstrated how much capital that was.
The payoff was an installed base that behaved like an annuity. Once a customer's programs, procedures, file layouts, and staff skills were bound to the architecture, the cost of leaving was measured in years of work rather than in the price difference between machines. Compatibility had converted a hardware business into a platform business.
OS/360 and the Discovery of Software Engineering
The operating system was intended to complete the unification. One control program would serve the whole family, providing job scheduling, device independence, multiprogramming, and a common set of access methods, so that the software environment would be as uniform as the instruction set. The plan was sound and the execution was extraordinarily difficult.
OS/360 was late, and it grew. At its peak the project employed roughly a thousand programmers, and Frederick Brooks, who managed it, later reported that more than five thousand programmer-years went into its design, construction, and documentation between 1963 and 1966. The single system splintered into several configurations to fit machines of different sizes: a primary control program for small memories, then Multiprogramming with a Fixed number of Tasks, and finally Multiprogramming with a Variable number of Tasks for the largest machines. Smaller installations ran DOS/360 instead, a separate and simpler system that was supposed to be temporary and that outlived many of the people who called it that. MFT, likewise announced as an interim step, remained in service for years because MVT was initially unreliable.
Brooks turned the experience into The Mythical Man-Month, published in 1975, which remains the most widely read book about software project management. Its central observation, now called Brooks's Law, is that adding programmers to a late software project makes it later, because the cost of training the new people and of the additional communication paths among all of them exceeds the work they contribute. The book also argued for conceptual integrity as the primary quality of a design, for the value of a small architecture team separate from the implementers, and against the assumption that effort and schedule are interchangeable. Every one of those arguments was drawn from watching OS/360 in trouble.
The difficulty was not IBM's alone, and the industry said so publicly. A conference sponsored by the NATO Science Committee met at Garmisch in October 1968 and adopted the phrase software engineering as a provocation, choosing a term that implied an established discipline precisely because no such discipline existed. The report named the software crisis and treated large system software as a problem of engineering management rather than of programming talent. Configuration management, formal release discipline, regression testing, and written interface specifications became normal practice in the years that followed, and the mainframe projects of the 1960s are where the need for them was first demonstrated at a scale nobody could ignore.
It is worth being precise about what failed. OS/360 shipped, ran the world's largest data processing installations for years, and its direct descendants are still supported. It was not a failure. It was a project whose cost and schedule were wrong by an order of magnitude, and the discipline that grew out of that error is the reason the error is instructive rather than merely embarrassing.
System/370, Virtual Memory, and Virtual Machines
IBM announced the System/370 on 30 June 1970, with the Models 155 and 165. The new family kept the System/360 architecture and extended it: thirteen new instructions, including long move and compare operations that removed the older two-hundred-fifty-six-byte limit on a single operation, additional floating-point support, and a higher-resolution time-of-day clock. Logic was monolithic rather than hybrid, and semiconductor main storage arrived with the Model 145 later that year. Existing System/360 programs continued to run.
The conspicuous omission from the 1970 announcement was virtual memory, and the omission was contentious inside IBM. Address translation had already been proved within the family: the System/360 Model 67, announced in 1965, carried dynamic address translation hardware and was intended for time-sharing. IBM corrected course on 2 August 1972 with the announcement usually called System/370 Advanced Function, which added dynamic address translation across the line together with a new set of operating systems, DOS/VS, OS/VS1, and OS/VS2. Machines already installed were not stranded; IBM offered field upgrades that added the translation hardware to Models 155 and 165.
Virtual memory changed the economics of the platform. A programmer no longer had to fit a program into the physical storage available, nor build overlay structures by hand. The operating system mapped a large virtual address space onto a smaller real one, moving pages between core and disk as demand required. OS/VS2 appeared first as Single Virtual Storage, giving all work one shared address space, and then in 1974 as Multiple Virtual Storage, which gave each address space its own translation tables. MVS was the more consequential design, because separate address spaces isolate work from work, and its lineage runs unbroken through MVS/XA and OS/390 to today's z/OS.
The Virtual Machine
The second idea was stranger and, in the long run, more influential. Instead of virtualizing memory alone, virtualize the entire machine. IBM's Cambridge Scientific Center, working alongside MIT, built CP-40 on a modified System/360 Model 40 and put it into production use at the center in early 1967. The control program did not divide the computer into partitions or time slices in the conventional sense. It gave each user a complete simulated System/360, with its own storage, its own devices, and its own operating system, all multiplexed onto one physical machine. A lightweight single-user system called CMS ran inside those virtual machines and supplied the interactive environment.
CP-40 was reimplemented for the Model 67 as CP-67, distributed through IBM's Type-III library in 1968, and it worked well enough to support on the order of sixty simultaneous interactive users on one machine. That is notable partly because IBM's official time-sharing system for the Model 67, TSS/360, did not succeed; the unofficial project from a research center did. When virtual storage came to System/370 in 1972, IBM announced VM/370 as a supported product, and the virtual machine became a permanent part of the platform.
Every argument made for virtualization today was made for CP-67 first: run several operating systems at once, test a new release without a second computer, isolate one workload's failures from another's, consolidate underused machines, and give each user an apparently private environment. Server virtualization and the cloud platforms built on it rediscovered a technique that had been in production on mainframes for three decades. That longer arc is traced in Batch to Time-Sharing to Personal to Cloud.
The Competitive Landscape: Seven Dwarfs and the BUNCH
Industry observers of the 1960s spoke of "IBM and the Seven Dwarfs": Burroughs, UNIVAC, NCR, Control Data, Honeywell, RCA, and General Electric. The label was condescending but statistically fair, since IBM's share of the general-purpose computer market dwarfed any individual competitor. What it obscured is that the seven were not attempting the same thing. Each competed on a different axis, and the axes are worth separating.
Control Data and Scientific Throughput
Control Data Corporation, founded in 1957 by a group from Engineering Research Associates under William Norris, competed on raw computational speed and nothing else. Seymour Cray joined in 1958 and designed the transistorized 1604, delivered from 1959. The CDC 6600, introduced in 1963, was the decisive machine: a load-store processor with multiple functional units, a scoreboard to dispatch instructions to them, and ten peripheral processors handling all input and output so that the central processor did nothing but compute. It outran its competition by roughly a factor of ten, sold more than a hundred units at around eight million dollars each, and made Control Data the supplier to weapons laboratories, weather services, and university computing centers.
IBM's response is one of the better-documented episodes in the industry's history. Thomas Watson Jr. circulated a memorandum asking how a company of Control Data's size had produced the world's fastest computer, and IBM announced a Model 92 that competed on paper with the 6600 but was not built as announced. Control Data sued in December 1968, alleging that the announcement of machines IBM could not deliver had been made to freeze customers in place. The case settled in January 1973 on terms valued at roughly eighty million dollars, the centerpiece being IBM's transfer of its Service Bureau Corporation to Control Data. The settlement had a side effect that mattered later: Control Data had built a computerized index of the millions of documents produced in discovery, and the index was destroyed as part of the agreement, which complicated the work of every subsequent plaintiff, including the government. Cray left Control Data in 1972 to found Cray Research, having concluded that the company could not fund both a redesigned 8600 and the STAR-100.
Burroughs and the Stack Machine
Burroughs competed on architecture, and took the opposite position from IBM on almost every question. The B5000, designed by a team under Robert Barton and delivered from 1961, was a stack machine with no programmer-visible general registers. Operands were pushed and popped; expressions evaluated naturally in postfix order; and the hardware was shaped around the requirements of a compiler rather than of an assembly language programmer. There was no assembler. The operating system, the Master Control Program, and the system utilities were written in an extended ALGOL called ESPOL. Memory was described by descriptors, and each word carried tag bits identifying whether it held data or control information, so that hardware could prevent a program from forging a pointer or corrupting the stack.
These were serious ideas, and several of them, hardware-enforced type and bounds checking above all, are being rediscovered under other names. Burroughs never approached IBM's volume, but the architecture proved durable: its descendants run today as the Unisys ClearPath MCP line.
UNIVAC, Honeywell, NCR, and RCA
UNIVAC, by then a division of Sperry Rand, competed principally on an installed base that predated IBM's entry into commercial computing, and on the 1100 series that grew out of its scientific machines. Its 36-bit architecture, like Burroughs's, survives in the Unisys ClearPath family. Honeywell competed on price and on aggressive conversion, first with the H-200 and Liberator against the 1401, and then by acquisition: General Electric sold its computer business to Honeywell in 1970, which brought with it the 600-series machines and the Multics project, whose influence on operating system design far exceeded its commercial success. NCR competed on vertical markets rather than on general-purpose computing, selling into retail and banking where its accounting-machine business already reached the customer.
RCA made the most interesting bet and lost it fastest. The Spectra 70, announced in April 1965, deliberately implemented the System/360 non-privileged instruction set and used EBCDIC, so that customer application programs would run on RCA hardware. The Model 70/45 was among the first commercial computers built with monolithic integrated circuits, so RCA was ahead of IBM on device technology while copying IBM's architecture. The strategy failed anyway, because the operating systems differed enough that programs did not simply transfer, and because RCA lacked the sales and service organization the market expected. RCA sold the computer division to Sperry Rand in 1971 and took a large write-down. The trajectories of these firms are placed in a wider corporate context in Corporate Giants and Their Evolution.
With General Electric and RCA gone, the survivors were renamed by the same habit of mind that produced the earlier label: Burroughs, UNIVAC, NCR, Control Data, and Honeywell became the BUNCH. The acronym describes a defensive posture. None of the five could match IBM's development spending or field organization, and each retreated toward the segment it could hold.
Plug-Compatible Manufacturers, Amdahl, and the Lessors
A second class of competitor took the opposite approach to RCA's. Rather than compete with the System/360 architecture, they joined it, and sold pieces that attached to it.
Peripherals came first, because the channel interface was a published specification. Telex began selling tape drives that attached to IBM channels in 1965, Memorex followed with disk drives in 1968, and Storage Technology, Itel, and Control Data itself joined. The proposition was arithmetic: IBM priced peripherals to contribute a large share of system margin, so a competitor with a comparable drive could undercut that price substantially and still profit. Customers kept their processor, their software, and their procedures, and changed only the box at the end of the cable.
Processors followed, and the central figure is Gene Amdahl. Having been chief architect of the System/360, he left IBM and founded Amdahl Corporation on 19 October 1970 to build machines that ran IBM software without IBM hardware. Funding was difficult until Fujitsu invested, with Nixdorf matching; Fujitsu's stake grew and it eventually acquired the company outright. The first Amdahl 470V/6 was delivered in June 1975 to the NASA Goddard Space Flight Center. Its advantage was engineering, not merely price: large-scale integration in emitter-coupled logic with air-cooled packaging, where IBM's comparable machines required chilled water, reportedly giving roughly twice the speed of a System/370 Model 168 at a similar price and in far less floor space. Hitachi and Fujitsu built compatible processors sold in the United States and Europe under other names. By late 1981 there were eight plug-compatible manufacturers offering thirty-six IBM-compatible models between them.
The third group never built anything. Independent leasing companies existed because of a legal fact discussed in the next section: IBM was obliged to sell its machines and not only to rent them. A lessor could therefore buy a System/360 outright, lease it to an end user at a monthly rate below IBM's own rental, and still profit, provided the machine remained in service long enough. The bet was on residual value, and the risk was technological. Every new IBM announcement threatened to strip the value from an inventory of installed machines, and the System/370 announcement of 1970 did exactly that to lessors holding System/360 equipment. IBM's own responses, including long-term lease plans at discounted rates, were attacked by the lessors as an attempt to squeeze them out. Greyhound Computer Corporation, a subsidiary of the bus company and one of the larger lessors, alleged that IBM restricted outright sales in order to monopolize the leasing business; the case came to trial in 1972 and was settled out of court on 27 January 1981, with Greyhound receiving $17.7 million.
Telex went furthest and fared worst. It won a district court judgment in 1973 that, after adjustment and trebling under the antitrust laws, came to $259.5 million, while IBM prevailed on a counterclaim over trade secrets. The Tenth Circuit reversed the antitrust judgment in 1975 and the Supreme Court declined to hear the appeal. The reversal, together with the government's eventual retreat, marks the point at which the courts stopped treating IBM's pricing responses to competitors as presumptively unlawful.
The Antitrust Decades
No account of the mainframe era is complete without the litigation, because several features of the industry exist only as a consequence of it.
The 1956 Consent Decree
IBM entered a consent decree with the United States Department of Justice in 1956, resolving a case concerned with its dominance of punched-card tabulating equipment and its extension into electronic data processing. Two provisions shaped what followed. IBM was required to offer its machines for sale, not only for rental, on terms not designed to make purchase unattractive, and to service machines it had sold. And IBM's service bureau operations were separated into a distinct subsidiary, the Service Bureau Corporation, which is the entity that later changed hands in the Control Data settlement. The requirement to sell created the used-equipment market and the leasing industry, neither of which could have existed under a rental-only regime.
Unbundling, 1969
Until 1969, one IBM price covered the hardware, the operating system, the application programs, the systems engineering help, the customer training, and the maintenance. Software had no separate price because it had no separate existence as a product. That practice was under attack from two directions: competitors who argued that free software from the dominant hardware vendor foreclosed any independent software business, and the Justice Department, whose case was then in preparation.
On 23 June 1969, IBM announced that it would price several of these elements separately, effective at the start of 1970. Systems engineering services would be charged by the hour, customer education by the student or the course, field engineering maintenance by the month, and seventeen software offerings would carry their own prices. IBM drew a distinction that has persisted in one form or another ever since, between system control programming, which remained bundled with the machine, and program products, which were licensed and paid for separately.
The consequences exceeded anything the decision was meant to accomplish. Once the dominant vendor charged for software, software had a market price, and a market price is what an independent supplier needs in order to exist. An independent software company no longer had to persuade a customer to pay for something the hardware vendor supplied at no visible cost; it had only to be better or cheaper than a priced product. The independent software industry dates from this announcement more precisely than from any technical development, and every packaged-software business since has operated in the market it opened.
The Case That Was Dropped
On 17 January 1969, three days before the end of the Johnson administration, the Justice Department filed a complaint alleging that IBM had monopolized the market for general-purpose electronic digital computers in violation of Section 2 of the Sherman Act. The allegations included the announcement of machines that did not exist in order to discourage customers from buying elsewhere, the bundling of software and services, and selective pricing against competitors.
The case consumed thirteen years. Trial before Judge David Edelstein in the Southern District of New York began in 1975 and the government's presentation alone ran for years. Contemporary accounts describe more than three hundred lawyers involved, some two thousand five hundred depositions taken, and on the order of sixty-six million pages of documents produced. On 8 January 1982, Assistant Attorney General William F. Baxter dismissed the case by stipulation, declaring it "without merit." A parallel European Commission proceeding ended in 1984 with IBM giving undertakings to disclose interface information for its System/370 products in advance of shipment, which preserved the plug-compatible industry in Europe by other means.
Assessments of the case remain contested. One reading holds that thirteen years of litigation accomplished nothing and cost enormously. Another holds that the suit disciplined IBM's conduct throughout the 1970s, that unbundling itself was a response to it, and that a company under continuous antitrust scrutiny is a company that hesitates before crushing a small competitor, which may explain why the personal computer business of the early 1980s was allowed to develop as it did. Both readings are defensible, and the honest conclusion is that the counterfactual is unknowable. What is certain is that the litigation environment is why the software industry was unbundled from hardware, why interface specifications were published, and why an entire industry of compatible suppliers was able to attach to a dominant vendor's platform.
What Survived
The mainframe's share of computing collapsed. Minicomputers took the departmental workloads in the 1970s, workstations and personal computers took the individual ones in the 1980s, and client-server architectures took much of what remained in the 1990s. Predictions of the mainframe's death were a recurring feature of the trade press for thirty years.
The architecture, however, did not die. It was extended instead. System/370 Extended Architecture, available from early 1983, raised the address space from twenty-four bits to thirty-one and redesigned the input-output architecture around a channel subsystem. Enterprise Systems Architecture followed later in the decade, and System/390 with ESA/390 was announced on 5 September 1990. In late 2000, IBM introduced the z900 and with it z/Architecture, a sixty-four-bit design that supports twenty-four-bit, thirty-one-bit, and sixty-four-bit addressing modes concurrently. Application programs written in the problem state for earlier members of the line continue to run.
That is the point worth ending on. The implementations changed completely and repeatedly: hybrid modules to monolithic integrated circuits to bipolar large-scale integration to CMOS, water cooling to air cooling, discrete processors to multi-core chips, core storage to dynamic RAM. Every physical thing about the machine announced in 1964 has been replaced several times. What did not change was the contract between the architecture and the programs written against it, and that contract is what the customers actually bought.
The principle has been confirmed repeatedly since. The x86 instruction set survived the move from sixteen bits to thirty-two to sixty-four and outlived technically superior rivals because software would not move. The IBM PC's own accidentally open architecture created a compatible industry by the same mechanism the System/360 channel interface had created twenty years earlier, as described in Personal Computer Revolution. In each case the durable asset was the specification, not the silicon.
Conclusion
The System/360 generation is remembered for a machine, but its lasting contribution is a set of separations. Architecture was separated from implementation, so that one specification could be realized across a price range and across decades of unrelated hardware. Peripherals were separated from processors by a published interface, so that devices could be engineered once and, unintentionally, so that others could attach their own. Software was separated from hardware by the unbundling of 1969, under antitrust pressure, which gave software a price and therefore an industry. The virtual machine separated the operating system from the physical computer, an idea the rest of computing took thirty years to adopt.
The costs were real. The program cost about five billion dollars against an estimate of six hundred seventy-five million. OS/360 overran its software budget by more than a factor of ten and taught the industry, through Brooks's account of it, that programmers are not interchangeable units of schedule. Thirteen years of antitrust litigation ended in dismissal, having reshaped the industry through the settlements and policy changes it prompted rather than through any judgment.
The competitors are instructive precisely because they were not foolish. Control Data built genuinely faster machines and could not build a full product line around them. Burroughs designed a more elegant architecture and could not reach the volume that would have made it a standard. RCA copied the architecture and discovered that the architecture was not the whole product. Honeywell bought market share and could not convert it into a position. What IBM held was not a technical lead but the accumulated investment of thousands of customers in software and procedures bound to one specification, and that is a lead which no amount of engineering excellence, by itself, dislodges.
Sixty years on, the specification is still being executed. Every physical component has been replaced many times, and the industry it dominated no longer exists in recognizable form. The compatibility contract outlasted all of it, which is the most useful thing the mainframe era has to teach anyone designing a platform today.