A look at IBM S/360 core memory: In the 1960s, 128 kilobytes weighed 610 pounds

I recently received a vintage core memory array, part of an IBM System/360 mainframe computer. These arrays were used in a 128-kilobyte core memory system that filled a large cabinet weighing 610 pounds.1 This article explains how core memory worked, how this core array was used in mainframes, and why core memory was so bulky.

A 64 KB core array from the IBM S/360 Model 50. There are 18 core planes stacked front-to-back. The blue cables are the sense/inhibit lines. Driver cards are plugged into the front of this array.

A 64 KB core array from the IBM S/360 Model 50. There are 18 core planes stacked front-to-back. The blue cables are the sense/inhibit lines. Driver cards are plugged into the front of this array.

The IBM System/360 was a groundbreaking family of mainframe computers announced introduced in 1964, and much of the success of System/360 was due to core memory technology. The S/360 was an extremely risky "bet-the-company" project that cost IBM over $5 billion. The project was nearly derailed as the operating system OS/360 grew out of control: it was originally targeted for 16 KB systems, but grew to require 32 KB and then 64 KB. Fortunately, IBM was able to build larger core memories at a price that customers could still afford, so the operating system was usable.2 The System/360 project ended up being a huge success and ensured IBM's dominance of the computer industry for the next two decades. (For more about the System/360, see my recent article.)

How core memory worked

Core memory was the dominant form of computer storage from the 1950s until it was replaced by semiconductor memory chips in the early 1970s. Core memory was built from tiny ferrite rings called cores, storing one bit in each core. Each core stored a bit by being magnetized either clockwise or counterclockwise. A core was magnetized by sending a pulse of current through a wire threaded through the core. The magnetization could be reversed by sending a pulse in the opposite direction. Thus, each core could store a 0 or 1.

To read the value of a core, a current pulse flipped the core to the 0 state. If the core was in the 1 state previously, the changing magnetic field created a voltage in a sense wire. But if the core was already in the 0 state, the magnetic field wouldn't change and the sense line wouldn't pick up a voltage. Thus, the value of the bit in the core could be read by resetting the core to 0 and testing the tiny voltage on the sense wire. (An important side effect was that the process of reading a core erased its value so it needed to be rewritten.)

Closeup of an IBM 360 Model 50 core plane. There are three wires through each core. The X and Y wires select one core from the grid. The green wire is the sense/inhibit line.  These cores are 30 mils in diameter (.8mm).

Closeup of an IBM 360 Model 50 core plane. There are three wires through each core. The X and Y wires select one core from the grid. The green wire is the sense/inhibit line. These cores are 30 mils in diameter (.8mm).

Using a separate wire for each core would be impractical, but in the 1950s a technique called "coincident-current" was developed that used a grid of wires to select a core. This depended on a special property of cores called hysteresis: a small current had no effect on a core, but a current above a threshold would magnetize the core. This allowed a grid of X and Y lines to select one core from the grid. By energizing one X line and one Y line each with half the necessary current, only the core where both lines crossed would get enough current to flip while the other cores were unaffected.

A Model 50 core plane is arranged as a grid of cores. The Y lines run horizontally. X and sense/inhibit lines run vertically.  The sense/inhibit lines form loops at the top and bottom. Each of the four vertical pairs of blocks has separate sense/inhibit lines.
Each core plane was about 10¾ × 6¾ × ⅛ inches.

A Model 50 core plane is arranged as a grid of cores. The Y lines run horizontally. X and sense/inhibit lines run vertically. The sense/inhibit lines form loops at the top and bottom. Each of the four vertical pairs of blocks has separate sense/inhibit lines. Each core plane was about 10¾ × 6¾ × ⅛ inches.

To store a word of memory, multiple core planes were stacked together, one plane for each bit in the word. The X and Y drive lines passed through all the core planes, selecting one bit of the word from each plane. Each plane had a separate sense line to read that bit.7 The IBM core stack below stored a 16-bit word along with two parity bits, so there were 18 core planes.

The core memory consisted of 18 core planes stacked in horizontal layers. Connections to the edge of each plane are visible at the front. The cores themselves are not visible in this assembled array.

The core memory consisted of 18 core planes stacked in horizontal layers. Connections to the edge of each plane are visible at the front. The cores themselves are not visible in this assembled array.

Writing to core memory required additional wires called the inhibit lines, one per core plane. In the write process, a current passed through the X and Y lines, flipping the selected cores (one per plane) to the 1 state, storing all 1's in the word. To write a 0 in a bit position, the plane's inhibit line was energized with half current, opposite to the X line. The currents canceled out, so the core in that plane would not flip to 1 but would remain 0. Thus, the inhibit line inhibited the core from flipping to 1.

To summarize, a typical core memory plane had four wires through each core: X and Y drive lines, a sense line, and an inhibit line. These planes were stacked to form an array, one plane for each bit in the word. By energizing an X line and a Y line, one core in each plane could be magnetized, either for reading or writing. The sense line was used to read the contents of the bit, while the inhibit line was used to write a 0 (by inhibiting the writing of a 1).

Some interesting features of the IBM core memory stack

The IBM core memory I examined was fairly advanced, so there were some enhancements to the generic core memory described above. This core memory used the same wire for sense and inhibit, so there were three wires through each core instead of four, as you can see in the earlier closeup photo. This made manufacturing simpler, but complicated the circuitry. In addition, the core plane has some unusual features to reduce the amount of noise picked up by the sense wire, making it feasible to detect the tiny voltage in the sense wire. First, each plane had four sense/inhibit wires, not one. Since a sense wire only passed through 1/4 of the plane, it picked up less noise.7 In addition, the sense wire was shifted between the top half of the plane and the bottom half, so noise induced by an X line in one half would be canceled out in the second half. The photo below shows the sense wire (green) shifting over.

This closeup of the core plane shows the X and Y wires (red) and the sense wire (green) threaded through cores. Note that the sense wire shifts over two columns in the middle of the plane to reduce noise. Building planes with this shift used a patented manufacturing technique. Wires are connected to the frame of the core plane on the right.

This closeup of the core plane shows the X and Y wires (red) and the sense wire (green) threaded through cores. Note that the sense wire shifts over two columns in the middle of the plane to reduce noise. Building planes with this shift used a patented manufacturing technique. Wires are connected to the frame of the core plane on the right.

Each core plane in this memory array was rectangular, with 130 Y drive lines and 256 X drive lines. Since there was a core at each intersection, this yielded 33,280 cores. You might notice that this isn't a power of 2; the core plane held 32,768 cores for regular storage (32K) along with 512 extra cores for I/O storage. This extra storage was called "bump" storage. It was not part of the address space but was accessed through special circuitry.3

After passing through all the planes, the drive lines reached this circuit board. The Y lines (left and right sides) were returned to the drive circuitry through the yellow cables in the center. The X lines (top and bottom) were sent back through the stack for phase reversal.

After passing through all the planes, the drive lines reached this circuit board. The Y lines (left and right sides) were returned to the drive circuitry through the yellow cables in the center. The X lines (top and bottom) were sent back through the stack for phase reversal.

The X and Y drive lines in a core array pass through all the planes in the stack. Core arrays typically used jumper wires between the core planes, requiring a large number of soldered connections. One innovation in IBM's core memory design was to weld the planes together directly. Alternating pins along the edges of the plane were bent up or down and welded to the neighboring plane, simplifying manufacturing. This structure is shown in the photo below.

Eighteen core planes were stacked to store two bytes along with two parity bits. Each plane had metal pins that were alternately bent up and down, and welded to tabs on the neighboring planes. The black and yellow wires connected the lines to the driver circuitry. The X lines are visible in this photo.

Eighteen core planes were stacked to store two bytes along with two parity bits. Each plane had metal pins that were alternately bent up and down, and welded to tabs on the neighboring planes. The black and yellow wires connected the lines to the driver circuitry. The X lines are visible in this photo.

Systems using this core memory

I'll now take a detour to describe the systems that used this core array, and then discuss the circuitry that supported the array. IBM used several different core memory systems in the S/360 line. The core array in this article was used in the Model 40, Model 50, and the FAA's IBM 9020 air traffic control system.

IBM System/360 Model 40

The Model 40 was a popular midrange computer for scientific and commercial applications and was one of IBM's most profitable computers. It typically rented for about $9,000-$17,000 per month and brought IBM over a billion dollars in revenue by 1972. To achieve better performance than the low-end models, the Model 40 used a two-byte datapath; the core memory system was designed to fetch two bytes at a time rather than one.

The IBM S/360 Model 40. Photo source unknown.

The IBM S/360 Model 40. Photo source unknown.

The IBM S/360 Model 40 was a compact system (for the time), with the computer in one frame known as the main frame. This frame held the circuit cards that make up the CPU, along with the power supplies, microcode (stored on metalized mylar sheets read by transformers), and core memory storage. (In contrast, large 360 systems might have dozens of frames.) The 128 KB core memory unit was mounted in the front right of the Model 40's frame, behind the console. The Model 40 could support an additional 128 KB of core memory, but this required a second storage frame, a five foot by two foot cabinet weighing 610 pounds.

IBM System/360 Model 50

IBM S/360 Model 50. The console was attached to the main frame, about 5 feet deep. The storage frame and power frame are the black cabinets at the back. Photo from Pinterest.

IBM S/360 Model 50. The console was attached to the main frame, about 5 feet deep. The storage frame and power frame are the black cabinets at the back. Photo from Pinterest.

The Model 50 was a powerful mid-range machine in the System/360 lineup, significantly faster than the Model 40. The Model 50 typically rented for about $18,000 - $32,000 per month. The diagram below shows how the Model 50 consisted of three frames: the CPU frame (main frame) in front with the console, a power frame holding the power supplies, and the storage frame. In the photo above, the main frame is orange and about 2.5 feet wide by 5 feet deep. The power frame is the black cabinet behind the main frame, about 5 feet wide and 2 feet deep. The storage frame is the same size, on the left behind the women. The storage frame could hold up to 256 KB; by adding a second storage frame behind it, the Model 50 could be expanded to 512 KB.

This diagram shows the three frames that made up the basic S/360 Model 50. Source: Model 50 Maintenance Manual page 138.

This diagram shows the three frames that made up the basic S/360 Model 50. Source: Model 50 Maintenance Manual page 138.

The FAA's IBM 9020 multiprocessor system

The core memory array I examined was from an air traffic control system called the IBM 9020. In the mid-1960s, the FAA realized that computerization was necessary to handle increased air traffic. From the early 1970s to the 1990s, the FAA used the IBM 9020 to track flights and integrate radar data. The 9020 was a multiprocessor system designed for reliability, consisting of up to 12 mainframes connected together, driving dozens of air traffic displays (the classic round CRT displays). The system used modified Model 65 computers to process data and used modified Model 50 computers for I/O control (essentially expensive DMA controllers).4

FAA center in Jacksonville using multiple IBM mainframes. Three Model 65s are along the left wall, while three Model 50s are towards the back. The control panel in front of the Model 50s is not a computer but a system monitoring panel. From FAA: A historical perspective, chapter 4.

FAA center in Jacksonville using multiple IBM mainframes. Three Model 65s are along the left wall, while three Model 50s are towards the back. The control panel in front of the Model 50s panel is not a computer but a system monitoring panel. From FAA: A historical perspective, chapter 4.

The complete core memory system

The stack of core planes isn't enough to implement a working memory; a lot of circuitry is required to generate the appropriate X and Y signals, amplify the sense line signals for reads, and drive the inhibit lines for writes. In this section, I explain how the stack of core memory planes was used as part of a full memory system.

Each X and Y line through the core plane required two transistor drivers, one to generate the current pulse for reading and one to generate the opposite current pulse for writing. Thus, with 128 X lines and 128 Y lines,5 a total of 512 drive transistors were required, a very large number of transistors. These were provided by 16 "driver gate" cards, each with 32 drive transistors, plugged into each core stack.10 The photo below shows the 16 driver gate boards (each with 32 transistors) plugged into the core array.

Core memory array with transistor driver boards.

Core memory array with transistor driver boards.

The photo below shows a closeup one of the transistor "driver gate" cards, with a transistor and diode for each line.6 Cards like this with discrete transistors were unusual in the IBM System/360, which for the most part used SLT modules, hybrid modules somewhat like integrated circuits.

Each core array used 16 of these driver cards for the X and Y drive lines. Each card had 32 drive transistors, as well as diodes.

Each core array used 16 of these driver cards for the X and Y drive lines. Each card had 32 drive transistors, as well as diodes.

The core array and the drive transistors generated significant heat so the assembly was cooled by a fan mounted underneath. Plastic covers over the boards directed the airflow, as well as providing protection for the boards. The photo below shows the core memory mounted on a metal frame with the fan attached.

Core memory array with the fan mounted below and plastic covers installed. The core planes are at the back and the circuit cards are at the front. This assembly is about 2 feet tall.

Core memory array with the fan mounted below and plastic covers installed. The core planes are at the back and the circuit cards are at the front. This assembly is about 2 feet tall.

The photo below shows the 128 KB unit, consisting of two core arrays (on the left), along with about 62 small circuit cards of supporting circuitry. This unit was rather bulky, almost three feet long and two feet high.8 Over half of these circuit cards were sense preamplifiers to read the weak signals from the core planes.7 Other cards decoded the address to select the right lines9, handled timing, or did other tasks. The slower Model 40 computer accessed one of the two arrays at a time, reading 16 bits (a half-word). In contrast, the Model 50 accessed both arrays in parallel, reading a full 32-bit word at once for higher performance.

128 KB core module assembly. Two core memory stacks are at the left, and the supporting circuitry is on the right. Fans (black) are at the bottom. Photo from IBM's 360 and Early 370 Systems.

128 KB core module assembly. Two core memory stacks are at the left, and the supporting circuitry is on the right. Fans (black) are at the bottom. Photo from IBM's 360 and Early 370 Systems.

The diagram below shows how two of these core memory units (i.e. four stacks of 18 planes) were installed in the Model 50's storage frame, providing 256 kilobytes of storage. This frame was about 5 feet by 2 feet and 6 feet tall and weighed 1150 pounds. The storage frame also held the optional "storage protect" feature, that protected memory blocks from access by other programs. Note that even though the core planes themselves were fairly compact, the entire storage frame was rather large. This diagram also illustrates why the cabinets were called frames: it was built from a frame of metal bars with side panels hung off the frame to enclose it.

The storage frame of the Model 50 held two 128-kilobyte core memory units (red and blue), along with other memory circuitry. Diagram based on the Parts Catalog.

The storage frame of the Model 50 held two 128-kilobyte core memory units (red and blue), along with other memory circuitry. Diagram based on the Parts Catalog.

Other IBM S/360 memory systems

I've described the core memory used in the Model 40 and Model 50, but high-end models used even larger core memory systems based on different core planes. The photo below shows a high-performance Model 85 system. The four cabinets in front are IBM 2365 Processor Storage; each one held 256 kilobytes of core memory and weighed over a ton. High-end systems could also use the 2385 Processor Storage holding 2 megabytes of memory in a sprawling 400 square foot unit that weighed almost 8 tons. The IBM 2361 Large Capacity Storage (LCS) also held 2 megabytes; it was slower but weighed just one ton. It used large 4-foot core planes that looked more like screen doors than typical core planes.1

IBM System/360 Model 85. The double-H cabinet in the middle is the processor. Each cabinet in the front left held 256 kilobytes of storage. Photo from IBM.

IBM System/360 Model 85. The double-H cabinet in the middle is the processor. Each cabinet in the front left held 256 kilobytes of storage. Photo from IBM.

Conclusion

Computers in the early 1950s used memory technologies such as mercury delay lines and Williams tubes that were small and slow. Core memory was much superior and it led to the rise of the computer era in the late 1950s and 1960s. As manufacturing technology improved, the price of core memory rapidly dropped, from several dollars per bit to a penny per bit. By 1970, IBM was producing over 20 billion cores per year.

However, even with its steady improvements, core memory was not able to survive the introduction of integrated circuits and semiconductor memory in the late 1960s. In 1968, IBM switched its development efforts from core memory to semiconductor memory. This led to the introduction in 1971 of the world's first commercial computer with semiconductor memory, the IBM S/370 Model 145. The capacity of integrated circuit memories grew exponentially as their price fell, as described by Moore's law. As a result, semiconductors took over the memory market from magnetic cores by the end of the 1970s. Now, thanks to DRAM memories, modern computers have memory measured in gigabytes rather than kilobytes and memory comes in a small DIMM module rather than a large cabinet.

I announce my latest blog posts on Twitter, so follow me @kenshirriff for future articles. I also have an RSS feed. I've written before about core memory in the IBM 1401 and core memory in the Apollo Guidance Computer. Thanks to Robert Garner for supplying the core array. Thanks to Gio Wiederhold and Marianne Siroker for research assistance.

More information

In the video below, Marc, Carl, and I wired up a different type of IBM core memory plane and manually read and wrote a bit. It was harder than we expected; the signal from a flipping core is very small and hard to distinguish from noise.

The book Memories That Shaped an Industry describes the history of core memory in detail, with a focus on IBM. The book IBM's 360 and early 370 systems thoroughly describes the history of the S/360. The memory system used in the System/360 Model 40 is explained in Model 40 Functional Units, page 141 onwards. See ibm-360.info for documents on the FAA's IBM 9020 system.

Notes and references

  1. The weight of additional memory depended on the computer model. For the Model 40, adding 128K to get the "H" configuration requires the addition of Frame 2, weighing 610 pounds. For the Model 50, the first 256K ("H" configuration) fit in Frame 2 (1150 pounds), while the next 256K ("I" configuration) required the addition of Frame 4, which weighed 1500 pounds. So, depending on the particular computer, 128K weighed 575, 610, or 750 pounds. For details, see the physical planning guide, which provides the dimensions and weight of the various S/360 components. 

  2. The book Memories That Shaped an Industry discusses how IBM's leadership in core memory development made the IBM System/360 possible. IBM's near-disaster in developing software for the S/360 led to the legendary book The Mythical Man-Month by Fred Brooks, who managed development of the S/360 hardware and operating system. 

  3. Each core planes used in the Model 40 and 50 computers had an extra 512 bits of "bump" storage. This extra storage held information on I/O operations (the "unit control word") without using the main storage. The computers also had "local storage", a separate small core storage used for registers. 

  4. The computers used in the IBM 9020 system were based on the S/360 Model 50 and Model 65, but had modifications to operate in a networked high-availability system. For instance, most console controls were disabled except during maintenance to avoid accidental button presses. The computers also included address translation so they could access multiple shared external storage units, allowing failover of storage. The Model 65's instruction set was extended with highly specialized instructions such as CVWL (convert weather lines) that converted weather data coordinates for the displays, as well as instructions for multiprocessing. (Details in FETOM.)

    The IBM 9020 network architecture, using Model 50 computers as I/O controllers connected to Model 65 computers, may seem pointlessly complex. It turns out that is the case. According to Brooks, IBM originally designed a reasonable FAA system with just Model 50 computers. However, the (somewhat arbitrary) design specification created by MITRE required separate processing and I/O tiers in the network, so IBM added the Model 65 computers even though they were unnecessary and made the system less reliable. 

  5. The core plane had 256 X lines and 130 Y lines, but the circuitry drove 128 X lines and 128 Y lines, so you might wonder why the numbers don't match. There are two factors here. First, a technique called "phase reversal"11 used each X line twice, in opposite directions, so the 256 physical X lines through the core plane only required 128 X drivers, reducing the amount of drive hardware required. Second, the 2 extra Y lines for bump storage were driven by separate circuitry.  

  6. An X or Y line was connected to a read gate card at one end, and a write gate card at the other end; these lines had a high-current (360 mA) pulse for 400-700 nanoseconds to flip a core. The current path through a line was as follows: the +60V supply was connected through a terminating resistor to a "terminator gate", a transistor that controlled the timing. Then through the diode on a gate card, through the cores, and through a transistor on the gate card at the other end. Finally, the current passed through a driver card to ground. (The gate card is the card full of transistors plugged directly into the array while the driver card does part of the address decoding.) The memory system is explained in Model 40 Functional Units, page 141 onwards.  

  7. One unusual feature of this core plane is that it had four separate sense/inhibit lines, each covering 1/4 of the plane. This reduced the length of each sense line and thus reduced the noise it picked up, but required four times as many amplifiers to read the sense lines. Since there were 18 planes (18 bits) in the core array, 72 sense pre-amplifiers were required for each of the two core arrays. The pre-amplifiers were differential amplifiers, amplifying the difference between the two sense line inputs. (The idea is that noise on both inputs will cancel out, yielding just the desired signal.) The outputs from all the pre-amplifiers were fed into 18 "final amplifiers" yielding the 18-bit output (2 bytes + 2 parity bits) from the array. The sense and inhibit lines were shared in this core plane, so there also 72 inhibit lines. One circuit card implemented both the sense preamp and the inhibit driver for 4 lines, so the two stacks of core planes required 36 Sense Preamp and Z [i.e. inhibit] Driver cards. 

  8. The diagram below shows the dimensions of the 128 KB core memory unit, containing two sets of core planes. Each colored block is a core array of 18 planes, corresponding to the array shown at the beginning of this article.

    The 128 KB core memory unit contained two arrays and was almost three feet long.

    The 128 KB core memory unit contained two arrays and was almost three feet long.

  9. The Model 50 core unit with two core arrays held 128 kilobytes as 32K words of 32 bits plus parity. Addressing one of 32K words required 15 address bits, decoded as follows. For X, 4 bits selected one of 16 "gate decoder lines" and 3 bits selected one of 8 "drivers". These two selections were combined in the transistor matrix to select one of the 128 X drive lines. The Y address was decoded similarly, with 7 bits selecting one of 128 Y lines. One bit controls "phase reversal", selecting the polarity of the Y drive line. Although the System/360 was byte-addressable, accessing a specific byte in a word was done by the processor, rather than by the memory system. Because the Model 40 read half-words at a time from memory, it used a slightly different decoding scheme. One address bit was used to select between the two core arrays in the unit and only one array was accessed at a time. 

  10. Each gate driver card had 32 transistors in a grid, with 8 inputs to transistor emitters and 4 inputs to transistor bases. By activating one base input and one emitter input, the corresponding transistor turned on, energizing the corresponding line. Thus, each card allowed 32 lines to be controlled by selecting one of 4 inputs, and one of 8 inputs. Each card also had 32 diodes that provided the current into the appropriate line. If a transistor was activated, the diode on the card connected to the opposite end of the line sourced the current. 

  11. One subtlety of the coincident-current design is that if the wires pass through the core in opposite directions, the currents subtract instead of add. In the diagram below, the wires pass through the left core in the same direction so the currents coincide. But in the right core, the wires pass through in opposite directions, so the currents cancel out. This is important because neighboring cores are rotated 90° to prevent magnetic coupling. In order for currents to coincide, the direction of current must be reversed in every other line. To accomplish this reversal, lines through the core stack were wired alternating bottom-to-top versus top-to-bottom.

    If currents pass through a core in the same direction, they add. This is the principle behind "coincident-current" core memory. However, if currents pass through a core in opposite directions (as on the right), the currents cancel.

    If currents pass through a core in the same direction, they add. This is the principle behind "coincident-current" core memory. However, if currents pass through a core in opposite directions (as on the right), the currents cancel.

    The "phase reversal" technique used this cancellation to cut the number of X drive lines in half for this core memory plane. The trick was to run the X lines through half of the core plane normally, and then through the other half of the core plane "backward". When an X line and a Y line are activated, two cores will receive both X and Y currents. But only one of these cores will receive the currents in the same direction and will flip; for the other core, the currents will cancel out. On the other hand, by reversing the current through the Y line, the opposite cancellation will occur and the other core will be selected. Thus, phase reversal allows the system to support twice as many cores with essentially the same driver hardware, just switching the Y current direction as needed.

    On the left, the coincident currents select a core in segment A. By reversing the direction of the Y current, a core in segment B is selected instead. With this phase reversal technique, one wire went through two X rows. Diagram based on Model 40 Functional Units page 147.

    On the left, the coincident currents select a core in segment A. By reversing the direction of the Y current, a core in segment B is selected instead. With this phase reversal technique, one wire went through two X rows. Diagram based on Model 40 Functional Units page 147.

Iconic consoles of the IBM System/360 mainframes, 55 years old

The IBM System/360 was a groundbreaking family of mainframe computers announced on April 7, 1964. Designing the System/360 was an extremely risky "bet-the-company" project for IBM, costing over $5 billion. Although the project ran into severe problems, especially with the software, it was a huge success, one of the top three business accomplishments of all time. System/360 set the direction of the computer industry for decades and popularized features such as the byte, 32-bit words, microcode, and standardized interfaces. The S/360 architecture was so successful that it is still supported by IBM's latest z/Architecture mainframes, 55 years later.

Prior to the System/360, IBM (like most computer manufacturers) produced multiple computers with entirely incompatible architectures. The System/360, on the other hand, was a complete line of computers sharing a single architecture. The fastest model in the original lineup was 50 times as powerful as the slowest,1 but they could all run the same software.2 The general-purpose System/360 handled business and scientific applications and its name symbolized "360 degrees to cover the entire circle of possible uses."34

Large computer room with an IBM System/360 Model 85. The CPU, the double-H unit in the center, weighed over 7 tons.
Cabinets in front are core memory storage, holding 256 kilobytes each.
Cabinets on the right are I/O channels, connected to I/O devices at the back:
tape drives, printers, disk drives, and card readers. Photo from IBM.

Large computer room with an IBM System/360 Model 85. The CPU, the double-H unit in the center, weighed over 7 tons. Cabinets in front are core memory storage, holding 256 kilobytes each. Cabinets on the right are I/O channels, connected to I/O devices at the back: tape drives, printers, disk drives, and card readers. Photo from IBM.

Although the S/360 models shared a common architecture, internally they were completely different to support the wide range of cost and performance levels. Low-end models used simple hardware and an 8-bit datapath while advanced models used features such as wide datapaths, fast semiconductor registers, out-of-order instruction execution, and caches. These differences were reflected in the distinctive front panels of these computers, covered with lights and switches.

This article describes the various S/360 models and how to identify them from the front panels. I'll start with the Model 30, a popular low-end system, and then go through the remaining models in order. Conveniently IBM assigned model numbers rationally, with the size and performance increasing with the model number, from the stripped-down but popular Model 20 to the high-performance Model 195.

IBM System/360 Model 30

The photo below shows a Model 30, one of the lower-end S/360 machines, with 8 to 64 kilobytes of magnetic core memory. The CPU cabinet was 5 feet high, 2'6" wide and 5'8" deep and weighed 1700 pounds, enormous by modern standards but a smaller computer for the time. System/360 computers were built from fingernail-sized modules called Solid Logic Technology (SLT) that contained a few transistors and resistors, not as dense as integrated circuits. Although the Model 30 was the least powerful model when the System/360 line was announced, it was very popular and profitable, renting for $8,000 a month and bringing IBM over a billion dollars in revenue by 1972.

IBM S/360 Model 30 on display at the Computer History Museum.

IBM S/360 Model 30 on display at the Computer History Museum.

You might wonder why these computers had such complex consoles.5 There were three main uses for the console.6 The first use was basic "operator control" tasks such as turning the system on, booting it, or powering it off, using the controls shown below. These controls were consistent across the S/360 line and were usually the only controls the operator needed. The three hexadecimal dials selected the I/O unit that held the boot software.7 Once the system had booted, the operator generally typed commands into the system rather than using the console.

The "operator control" section of the control panel was used for basic tasks such as booting the system (called Initial Program Load or IPL). The buttons provided "Power On", "Power Off", "Interrupt", and "Load", while the lights indicated if the system was running.

The "operator control" section of the control panel was used for basic tasks such as booting the system (called Initial Program Load or IPL). The buttons provided "Power On", "Power Off", "Interrupt", and "Load", while the lights indicated if the system was running.

The second console function was "operator intervention": program debugging tasks such as examining and modifying memory or registers and setting breakpoints. The Model 30 console controls below were used for operator intervention. To display memory contents, the operator selected an address with the four hexadecimal dials on the left and pushed the Display button, displaying data on the lights above the dials. To modify memory, the operator entered a byte using the two hex dials on the far right and pushed the Store button. (Although the Model 30 had a 32-bit architecture, it operated on one byte at a time, trading off speed for lower cost.) The Address Compare knob in the upper right set a breakpoint.

The lower part of the Model 30 console was used for operator intervention. Note the binary-to-hexadecimal conversion chart below the hexadecimal dials.

The lower part of the Model 30 console was used for operator intervention. Note the binary-to-hexadecimal conversion chart below the hexadecimal dials.

The third console function was supporting system maintenance and repair performed by an IBM customer engineer. The customer engineering displays took up most of the console and provided detailed access to the computer's complex internal state. On the Model 30 console above, the larger middle knob (Display Store Selection) selected any of the internal registers for display or modification. The rows of lights below showed the microcode instruction being executed from "read only storage" and operations on the I/O channel.

Closeup of the IBM S/360 Model 30 console showing indicators for the microcode (read only storage) and I/O channel. These registers were used internally and were not visible to the programmer.

Closeup of the IBM S/360 Model 30 console showing indicators for the microcode (read only storage) and I/O channel. These registers were used internally and were not visible to the programmer.

The consoles also included odometer-style usage meters, below the Emergency Power Off knob.10 The standard IBM rental price covered a 40-hour week and a customer would be billed extra for excess usage. However, customers were not charged for computer time during maintenance. When repairing the system, the customer engineer turned the keyswitch, causing time to be recorded on the lower service meter instead of the customer usage meter.

The Emergency Power Off knob shut down the entire system. Below it were the usage meters. The keyswitch selected the maintenance meter, so customers would not be charged for computer operation during maintenance.

The Emergency Power Off knob shut down the entire system. Below it were the usage meters. The keyswitch selected the maintenance meter, so customers would not be charged for computer operation during maintenance.

IBM System/360 Model 20

Moving now to the bottom of the S/360 line, the Model 20 was intended for business applications.9 Its storage was limited, just 4K to 32K bytes of core storage, and it was extremely slow even by 1960s standards, performing about 5700 additions per second. This slow CPU was enough to generate business reports from punch cards since the card reader only read 8 cards per second. To reduce its price, the Model 20 implemented a subset of the S/360 instructions and used half-sized registers,8 making it incompatible with the rest of the S/360 line. Despite its limitations, the Model 20 was the most popular S/360 model due to its low price, with more than 7,400 Model 20s in operation by the end of 1970. The monthly rental price of the Model 20 started at $1280 with the purchase price starting at $62,710.

The low-end IBM System/360 Model 20 computer. The computer and its console were smaller than other systems in the S/360 line. Photo by Waelder, CC BY-SA 2.5.

The low-end IBM System/360 Model 20 computer. The computer and its console were smaller than other systems in the S/360 line. Photo by Waelder, CC BY-SA 2.5.

The Model 20's small console (above) allowed the operator to turn the computer on and off, load a program, and so forth. A few rows of lights showed the contents of the computer's registers and hexadecimal dials loaded a byte (left two dials) into a memory address (next four dials). Another dial let the operator debug a program by modifying memory, setting a breakpoint, or single-stepping through a program. The Emergency Power Off knob and usage meters are at the far right.

The Model 20 hid a separate control panel for customer engineers behind a cover (below). This panel provided additional controls and lights for diagnostics and access to the microcode. Because the Model 20 was simpler internally than the Model 30, not as much information needed to be displayed to the customer engineer.

Customer engineering control panel for the IBM S/360 Model 20. Photo by Ben Franske, CC BY-SA 2.5.

Customer engineering control panel for the IBM S/360 Model 20. Photo by Ben Franske, CC BY-SA 2.5.

IBM System/360 Model 22

The Model 22 was a cut-down version of the Model 30 at 1/3 the price, providing about 5 times the performance of the Model 20. It was the last S/360 computer introduced, announced in 1971. IBM said the Model 22 "combined intermediate-scale data processing capability with small-system economy."

A base Model 22 CPU rented for $850 a month (less than the Model 25 or most Model 20s) with a purchase price of $32,000 to $44,000. A typical configuration with three disk drives, line printer and card reader cost considerably more, renting for about $5,600 or purchased for $246,000. The processing unit weighed 1500 pounds and was about the size of two refrigerators.11 Unlike the Model 20, the Model 22 was compatible with the rest of the S/360 line.

IBM System/360 Model 22. Photo from IBM.

IBM System/360 Model 22. Photo from IBM.

The Model 22's console was very similar to the Model 30's, since the Model 22 was derived from the Model 30. The Model 22 had fewer rows of lights, though, and the bulbs projected from the console in individual holders, rather than being hidden behind the Model 30's flat overlay. Because of its late introduction date, the Model 22 used semiconductor memory rather than magnetic core memory.

IBM System/360 Model 25

The Model 25 was another low-end system, designed to be less expensive than the Model 30 but without the incompatibility of the Model 20. A typical Model 25 rented for $5,330 a month with a purchase price of $253,000. It was introduced in 1968, late in the S/360 line but before the Model 22.

It was a compact system, packaging I/O controllers in the main cabinet (unlike other S/360 systems). Unlike other low-end systems, it had a two-byte datapath for higher performance. One of the Model 25's features was a smaller easy-to-use console; on the Model 25, many operations used the console typewriter rather than the control panel. In the picture below, note the squat control panel, about 2/3 the height of the black computer cabinet behind it. The control panel reused dials for multiple functions (such as address and data), making it more compact than the Model 30 panel.

IBM System/360 Model 25. Photo from IBM.

IBM System/360 Model 25. Photo from IBM.

IBM System/360 Model 40

The Model 40 was a popular midrange model, more powerful than the Model 30. It typically rented for about $9,000-$17,000 per month and brought IBM over a billion dollars in revenue by 1972. For improved performance, the Model 40 used a two-byte datapath (unlike the Model 30, which handled data one byte at a time)

IBM System/360 Model 40. Photo by Daderot.

IBM System/360 Model 40. Photo by Daderot.

In the photo above, you can see that the Model 40 console is considerably more complex than the Model 30 console, reflecting the increased internal complexity of the system. Like the other models, it had three hex dials in the lower right to boot the system. But instead of hex dials for address and data entry, the Model 40 had rows of toggle switches: one for the address and one for the data.

To keep the number of lights manageable, the Model 40 used two "rollers" that allowed each row of lights to display eight different functions. Each roller had an 8-position knob on the right side of the console, allowing a particular register or display to be selected. The knob physically rotated the legend above the lights to show the meaning of each light for the selected function.

Multi-function rollers on the S/360 Model 40 allowed more data to be displayed on the console.

Multi-function rollers on the S/360 Model 40 allowed more data to be displayed on the console.

IBM System/360 Model 44

IBM's competitors in the scientific computing market offered cheaper but faster systems designed specifically for numerical computing. IBM created the Model 44 to address this gap, giving it faster floating point and data acquisition instructions while dropping business-oriented instructions (decimal arithmetic and variable field length instructions).3 These changes made the Model 44 somewhat incompatible with the rest of the S/360 line, but it was 30 to 60 percent faster than the more-expensive Model 50 on suitable workloads. Despite the improved performance, the Model 44 met with limited customer success.

IBM System/360 Model 44 control panel.

IBM System/360 Model 44 control panel.

The Model 44's console was superficially similar to the Model 40's, with toggle switches and two roller knobs, but on the Model 44, one of the rollers changed the function of the toggle switches. The two models were entirely different internally; for higher performance, the Model 44 used a hard-wired control system instead of microcode. It also used a four-byte datapath, moving data twice as fast as the Model 40, so it has had twice as many lights and switches in each row on the console (32 data bits + 4 parity bits).12

One unusual feature of the Model 44's console was a rotary knob (bottom knob on the left) to select floating point precision; reducing the precision increased speed. Another feature unique to the Model 44 was a disk drive built into the side of the computer. The removable disk cartridge held about 1 megabyte of data. The buttons in the lower left of the console controlled the disk drive.

The Model 44 had a disk drive or two in the side of the computer that used a removable IBM 2315 Disk Cartridge. Photo from Model 44 Functional Characteristics.

The Model 44 had a disk drive or two in the side of the computer that used a removable IBM 2315 Disk Cartridge. Photo from Model 44 Functional Characteristics.

IBM System/360 Model 50

The Model 50 had significantly higher performance than the Model 40, partly because it used a four-byte datapath for higher performance. Physically, the Model 50 was considerably larger than the lower models: the CPU with 512 KB of memory was 5 large frames weighing over 3 tons. The Model 50 typically rented for about $18,000 - $32,000 per month. It could be expanded with 8 more megabytes externally; each IBM 2361 "Large Capacity Storage" unit held 2 megabytes of core memory and weighed a ton.

IBM System/360 Model 50 control panel. The dataflow diagram in the upper right illustrates the system's internal design. Photo by Sandstein, CC BY-SA 3.0

IBM System/360 Model 50 control panel. The dataflow diagram in the upper right illustrates the system's internal design. Photo by Sandstein, CC BY-SA 3.0

The Model 50's console was more complex than the Model 40 or Model 44. Like the Model 44, the toggle switches and lights are 32 bits + parity because of the 4-byte datapath. The Model 50 used four roller knobs to support multiple functions on each row of lights. The voltmeter and voltage control knobs in the upper left were used by an IBM customer engineer for "marginal checking". By raising and lowering the voltage levels about 5% and checking for failures, borderline components could be detected and replaced before they caused problems.

Control panel of the IBM System/360 Model 50. This panel has marginal check controls for auxiliary storage in the upper right, replacing the dataflow diagram.

Control panel of the IBM System/360 Model 50. This panel has marginal check controls for auxiliary storage in the upper right, replacing the dataflow diagram.

IBM System/360 Models 60, 62, 65 and 67

The models in the 60 series were very similar, designed for large scale business and scientific computation. Models 60 and 62 were announced at the S/360 launch, but they were never shipped. Competitors announced faster machines so IBM improved the core memory to create the Model 65; it had fast .75μs memory, obsoleting the Model 60 (2μs) and Model 62 (1μs) before they shipped. The Model 65 typically rented for $50,000 a month.

IBM System/360 Model 60 with peripherals. Photo from  IBM 360 System Summary page 10.

IBM System/360 Model 60 with peripherals. Photo from IBM 360 System Summary page 10.

The Model 65's console had much in common with the Model 50, although it had 6 rollers instead of 4 to display more information. The Model 60 and higher models used an eight-byte datapath and storage interleaving for highest memory performance.13 To support the wide datapath, the console had two rows of toggle switches for data, as well as more address toggle switches to support the larger address range. Each roller controlled 36 lights (4 bytes + parity), so the 64-bit registers were split across two rows of lights.

IBM System/360 Model 65. From Michael J. Ross.

IBM System/360 Model 65. From Michael J. Ross.

The Model 67 was announced in 1965 and shipped in 1966 to support the demand for time-sharing systems, computers that could support numerous users at the same time. (Most computers back then were "batch" systems, running a single program at a time.) The Model 67 was essentially a Model 65 with the addition of virtual memory, called Dynamic Address Translation. It supported "on-line" computing with remote users, time-sharing, and multiple concurrent users. Unfortunately, due to delays in releasing the operating system the Model 67 was not a large success, with only 52 installations by the end of 1970.

The 60-series models were physically large, especially with multiple memory units attached. They could also be configured as a two-processor "duplex" multiprocessor, weighing over four tons and occupying about 400 square feet; note the two consoles in the photo below.

IBM System/360 Model 67, duplex system. From IBM System/360 System Summary page 6-13

IBM System/360 Model 67, duplex system. From IBM System/360 System Summary page 6-13

IBM System/360 Models 70 and 75

The high-end Model 70 was announced in April 1964, but as with the Model 60, improvements in memory speed caused the Model 70 to be replaced by the faster Model 75 before it shipped. The Model 75's console was much larger than the lower models with a remarkable number of lights, for two reasons.14 First, the Model 75's internal architecture was complex, with multiple data paths and internal registers to improve performance, resulting in more data to display. Second, instead of using rollers to display different functions, the Model 75 displayed everything at once on its vast array of lights.

IBM System/360 Model 75. This version has 1 megabyte of storage in four 2365 Processor Storage units, four of the "fins" off the central spine. From Model 75 Functional Characteristics page 4.

IBM System/360 Model 75. This version has 1 megabyte of storage in four 2365 Processor Storage units, four of the "fins" off the central spine. From Model 75 Functional Characteristics page 4.

I'll point out some of the highlights of the console. The standard operator dials to boot the system were in the lower right (section N), next to the usage meters (P). To examine and modify memory, the operator used the address switches (R), 64 data switches (M), and lights (M). Most of the other sections were for customer engineers. The voltmeter (K) was used for marginal checking. Other sections included bus control (A), high-speed storage (B), variable field length instructions (C), instruction controls (E), and registers (F, L).

The IBM S/360 Model 75 had a very large console. Diagram from Model 75 Functional Characteristics page 14.

The IBM S/360 Model 75 had a very large console. Diagram from Model 75 Functional Characteristics page 14.

The Model 75 had a monthly rental price of $50,000 to $80,000 and a purchase price from $2.2 million to $3.5 million. IBM considered the Model 75 a 1-MIPS computer, executing about 1 Million Instructions Per Second. (This would put its performance a bit below an Intel 80286, or about 1/10,000 the performance of a modern Intel Core I7.)

IBM System/360 Model 85

The high-end Model 85 was a later model in the S/360 line, introduced in 1968. Its massive processing unit consisted of a dozen frames and weighed about 7 tons, as shown in the photo at the beginning of the article. A key innovation of the Model 85 was the memory cache to speed up memory accesses. While caches are ubiquitous in modern computers, the Model 85 was the first commercial computer with a main-memory cache. The Model 85 was also IBM's first computer to use integrated circuits (which IBM called Monolithic System Technology or MST). Unfortunately, the Model 85 was not a success with customers; its price was relatively high at a time when the data processing industry was going through a slowdown. As a result, only about 30 Model 85 systems were ever built.

The Model 85 used a radically different approach for the console.15 The control panel of lights and switches was small compared to other S/360 systems. Instead, a CRT display and keyboard were used for many operator functions, visible in front of the operator below. To the left of the operator, an "indicator viewer" replaced most of the panel lights. The indicator viewer combined 240 lights with a microfiche projector that displayed the appropriate labels for ten different configurations, a more advanced version of the rollers that provided the equivalent of 2400 individual lights. The system also included a microfiche document viewer (far left of photo), replacing binders of maintenance documentation with compact microfiche cards.

Console for the IBM System/360 Model 85 at NSA (source).

Console for the IBM System/360 Model 85 at NSA (source).

IBM System/360 Models 90, 91, 92 and 95

The Model 90 was just a footnote in the original S/360 announcement, a conceptual "super computer". The improved Model 92 was announced a few months later but then scaled back to create the Model 91. The Model 91 was intended to compete with the CDC 6600 supercomputer (designed by Cray), but ended up shipping in 1967, about two years after the CDC 6600.16 As a result, the Model 91 was rather unsuccessful with only 15 to 20 Model 91's produced, despite cuts to the $6,000,000 price tag. In comparison, CDC built more than 200 computers in the 6000 series.

The Model 91 was architecturally advanced; it was highly pipelined with out-of-order execution and multiple functional units. Reflecting its complex architecture, the Model 91 had a massive control panel filled with lights and switches. The lower part of the main panel had the "operator intervention" functions, including toggle switches for a 24-bit address and 8 bytes of data. The remainder of the lights showed detailed system status for IBM customer engineers. The basic operator controls (power, boot) were not on the main panel, but on a small panel below and to the right of the main console. (It is visible in the photo below, just to the left of the operator's head.) The operator also used the CRT for many tasks.15

Console of the IBM System/360 Model 91. The very large computer itself is not visible in this photo. Photo source unknown.

Console of the IBM System/360 Model 91. The very large computer itself is not visible in this photo. Photo source unknown.

The Model 91 was a room-filling system as the central processor consisted of seven stand-alone units: the CPU itself, three power supplies (not counting the motor-generator set), a power distribution unit, a coolant distribution unit, and a system console. In addition, an installation had the usual storage control unit, I/O channel boxes, and I/O devices. The Model 91 was the first IBM system to use semiconductor memory, in its small "storage protect" memory but not the main memory.

As for the Model 95, IBM started researching thin-film storage as a replacement for core memory in 1951. After years of difficulty, in 1968 IBM shipped thin-film memory in the Model 95 (which was otherwise the same as the Model 91). Although this was the fastest megabyte memory for many years, IBM sold just two Model 95 computers (to NASA) and then abandoned thin-film memory.

IBM System/360 Model 195

The Model 195 was "designed for ultrahigh-speed, large-scale computer applications." It was a reimplementation of the Model 91 using integrated circuits (called "monolithic circuitry", still in IBM's SLT-style packages), and also included a 32K byte memory cache. It rented for $165,000 to $275,000 a month, with purchase prices from $7 million to $12.5 million. The Model 195's performance was comparable to the CDC 7600 supercomputer, but as with the Model 91, the Model 195 was delivered about two years later than the comparable CDC machine, limiting sales.

The Model 195's console (below) was very similar to the Model 95's. As with the Model 91, the Model 195 used a CRT15 for many operator tasks and had a separate small operator console (not shown). 17

Console for the IBM System/360 Model 195.
This console has the dark color scheme used for S/370 consoles even though it was an S/360 system.
With approximately 2000 light bulbs, the console has complex wiring, visible below the console.
Photo from Science Museum Group.

Console for the IBM System/360 Model 195. This console has the dark color scheme used for S/370 consoles even though it was an S/360 system. With approximately 2000 light bulbs, the console has complex wiring, visible below the console. Photo from Science Museum Group.

Identification at a glance

It can be hard to distinguish the consoles of the common Models 30, 40, 50 and 65. The diagram below shows the main features that separate these consoles, helping to identify them in photographs. The Model 30 had a flat silkscreened panel without individual indicators and toggle switches. It can also be distinguished by the 9 dials at the bottom, and the group of four dials on the right. The Model 40 had two rollers, and the group of four dials on the left. The Model 50 had four rollers, and a voltmeter next to a dozen knobs. The Model 60 had six rollers, and a voltmeter with just a couple knobs.

Common IBM System/360 consoles, with distinguishing features identified. The number of roller knobs on the right (0, 2, 4, or 6) provides a convenient way to tell the models apart.

Common IBM System/360 consoles, with distinguishing features identified. The number of roller knobs on the right (0, 2, 4, or 6) provides a convenient way to tell the models apart.

Conclusion

By modern standards the System/360 computers were unimpressive: the Model 20 was much slower and had less memory than the VIC-20 home computer (1980), while at the top of the line, the Model 195 was comparable to a Macintosh IIFX (1990), with about 1/1000 the compute power of an iPhone X. On the other hand, these mainframes could handle a room full of I/O devices and dozens of simultaneous users. Even with their low performance, they were running large companies, planning the mission to the Moon, and managing the nation's air traffic control.

Mainframe computers aren't thought about much nowadays, but they are still used more than you might expect; 92 of the top 100 banks use mainframes, for instance. Mainframe sales are still a billion-dollar market, and IBM continues to release new mainframes in its Z series. Although these are modern 64-bit processors, amazingly they are still backward-compatible with the System/360 and customers can still run their 1964 programs. Thus, the S/360 architecture lives on, 55 years later, making it probably the longest-lasting computer architecture.

I announce my latest blog posts on Twitter, so follow me @kenshirriff for future articles. I also have an RSS feed.

More information

The book IBM's 360 and Early 370 Systems describes the history of the S/360 in great detail. IBM lists data on each model, including dates, data flow width, cycle time, storage, and microcode size. Another list with model details is here. Diagrams of S/360 consoles are at quadibloc. The article System/360 and Beyond has lots of info. A list of 360 models and brief descriptions is here.

Here are some links for each specific model:

Model 20: Functional Characteristics manual, Field Engineering manuals, Wikipedia.
Model 22: Wikipedia, IBM.
Model 25: Functional Characteristics manual, Wikipedia, Field Engineering manuals.
Model 30: Functional Characteristics manual, Wikipedia, Field Engineering manuals, photos here, here, here, here, here.
Model 40: Functional Characteristics manual, Field Engineering manuals, Wikipedia. Other photos here (from IBM System/360 System Summary page 6-7), here, here. The photo here apparently shows a prototype console with a roller.
Model 44: Functional Characteristics manual, Wikipedia, brochure. The photo here shows an earlier prototype with a different console. Some interesting notes are here.
Model 50: Functional Characteristics manual, Field Engineering manuals, Wikipedia, photos here and here, CuriousMarc video.
Model 65: Functional Characteristics manual, Field Engineering manuals, Wikipedia, photo here.
Model 67: Functional Characteristics manual, Wikipedia, photos here, here.
Model 75: Functional Characteristics manual, Field Engineering manuals (console diagram), Wikipedia.
Model 85: Functional Characteristics manual (console diagram, page 20), Wikipedia.
Model 91: Functional Characteristics manual, Wikipedia. Other photos here, here here here and here.
Model 92: IBM info with photo.
Model 195: Functional Characteristics and Wikipedia, photo here.

Notes and references

  1. Many sources give the eventual performance range of the S/360 range as 200 to 1. However, if you include the extremely slow Model 20, the performance ratio is about 3000 to 1. between the powerful Model 195 and the Model 20. Based on several sources, the Model 20 had the dismal performance of 2 to 5.7 KIPS (thousand instructions per second), while the Model 195 was about 10 to 17.3 MIPS (million instructions per second). The Model 20 started at 4K of storage, while the Model 195 went up to 8 megabytes, a 2000:1 ratio.

    To compare with microprocessor systems, a 6502 performed about 430 KIPS. People claim the iPhone X does 600 billion instructions per second, but those are "neural processor" instructions, so not really comparable; based on benchmarks, about 15 billion instructions per second seems more realistic. 

  2. The System/360 architecture is described in detail in the Principles of Operation. However, the System/360 didn't completely meet the goal of a compatible architecture. IBM split out the business and scientific markets on the low-end machines by marketing subsets of the instruction set. The basic instructions were provided in the "standard" instruction set. On top of this, decimal instructions (for business) were in the "commercial" instruction set and floating point was in the "scientific" instruction set. The "universal" instruction set provided all these instructions plus storage protection (i.e. memory protection between programs). Additionally, cost-cutting on the low-end Model 20 made it incompatible with the S/360 architecture, and the Model 44 was somewhat incompatible to improve performance on scientific applications. 

  3. The IBM System/4 Pi family contained several incompatible models. The high-performance Model EP (Extended Performance) was based on the S/360 Model 44's (somewhat incompatible) instruction set, while other 4 Pi models were entirely incompatible with the S/360 line. 

  4. In 1970, IBM introduced the System/370, with "370" representing the 360 for the 1970s. Similarly, IBM introduced the System/390 in 1990. The initial IBM 370 model numbers generally added 105 to the corresponding S/360 model numbers. For example, the S/370 Models 135, 145, 155, 165 were based on the S/360 Models 30, 40, 50 and 65. The S/370 Model 195 was very similar to the S/360 Model 195.  

  5. Most S/360 models had console lights in round sockets that project from the panel. In contrast, the console lights on the Model 30 were hidden behind a flat silkscreened overlay. This is probably because the Model 30 was designed at IBM's Endicott site, the same site that built the low-end IBM 1401 computer with a similar silkscreened console. Different S/360 models were designed at different IBM sites, and the characteristics of the computer often depended on which site designed the computer.  

  6. The features of the system control panel were carefully defined in the System/360 Principles of Operation pages 117-121, providing a consistent operator experience across the S/360 line. (The customer engineering part of the panel, on the other hand, was not specified and wildly different across the product line.) 

  7. An I/O unit was selected for booting with the three hex dials. The first knob selected the I/O channel, while the next two selected a subchannel on that I/O channel. These unit addresses were somewhat standardized; for instance, a disk drive was typically 190 or 191 while tape drives were 180 through 187 or 280 through 287 if they were on channel 1 or 2 respectively. 

  8. The Model 20 was designed at IBM's Böblingen, Germany site. The Model 20 was radically different in appearance from the other S/360 machines. It also had a different, incompatible architecture. These characteristics are likely a consequence of the Model 20 being designed at a remote IBM site. Regardless, the Model 20 was very popular with customers. 

  9. Although the Model 20 Functional Characteristics manual says that it supported time sharing, this is not timesharing in the normal sense. Instead, it refers to overlapping I/O with processing, essentially DMA. 

  10. While the Emergency Power Off button looks dramatic and was rumored to trigger a guillotine blade through the power cable, its implementation was more mundane. It de-energized a power supply relay, cutting off the system power. Behind the console, a tab popped out of the button when pulled, so the EPO button couldn't be pushed back in until a customer engineer opened the console and pushed the tab back in. 

  11. For exact dimensions of the System/360 units, see the System/360 Installation Manual. While the CPU for a low-end 360 system was reasonably compact, you could easily fill a room once you add a card reader, line printer, a bunch of tape drives, disk storage, I/O channels, and other peripherals. The computers generally consisted of one or more cabinets (called "frames" because they were constructed from a metal frame), about 30"×60". (To make installation easier, the frames were sized to fit through doorways and in freight elevators.) The "main frame" was the CPU, with other frames for power, I/O, memory and other functions. 

  12. The Model 44 was developed by IBM's Data Systems Division in Poughkeepsie, NY in partnership with IBM's Hursley UK site. Since Hursley designed the Model 40 and Poughkeepsie designed the Model 50 and larger systems, this may explain why the Model 44 is similar to the Model 40 in some ways, but closer to the larger systems in other ways, such as the use of a two-byte datapath and hardwired control instead of microcode. 

  13. One of the challenges of the 360 line was that the original models differed in performance by a factor of 50, while raw core memory speeds only differed by a factor of 3.3 (See IBM's 360 and Early 370 Systems page 194.) Several techniques were used to get memory performance to scale with processor performance. First was transferring multiple bytes at a time in larger systems. Second was slowing low-end processors by, for example, using the same core memory for register storage. The third technique was interleaving, splitting the memory into 2 to 8 separate modules and prefetching. With prefetching, as long as accesses were sequential, data would be ready when needed. 

  14. The Model 75 and larger systems abandoned the use of microcode, using a hardwired control that could handle the higher speed. This may be connected with the drastic jump in console complexity between the Model 65 and the Model 75. 

  15. A CRT display was used for the console on the models 85, 91 and 195. (I suspect this was because CRT display technology had advanced by the time these later systems were built.) The models 91 and 195 used a display based on the IBM 2250 Graphics Display Unit. This was a vector display, drawing characters from line segments instead of pixels. The 2250 display was expensive, costing $40,134 and up (in 1970 dollars), which explains why only the high-end mainframes used a CRT (source, page 20). This display supported a light pen, allowing items on the screen to be selected, somewhat like a mouse. The Model 85, on the other hand, used a CRT display built into the console.

    Some of the later IBM System/370 computers (such as the Models 135, 165 and 168) used a console similar to the S/360 Model 85. This was called the 3066 System Console. (A Guide to the IBM System/370 Model 165 page 20.) 

  16. CDC's announcement of the 6600 supercomputer in 1963 triggered the famous janitor memo from IBM's president, Watson, Jr. He asked how the 6600 beat out IBM when the 6600 was designed by a team of just 34 people "including the janitor" compared to IBM's vast development team. Cray's supposed response was, "It seems Mr. Watson has answered his own question." 

  17. The Model 195 had a strange position straddling the S/360 and S/370 product lines. A System/370 version of the Model 195 was announced in 1971, updating the 195 to support the 370 architecture's expanded instruction set, but lacking some features of the rest of the 370 line. Some sources give the S/360 Model 195 the part number 2195 (S/360 part numbers were 2xxx) while other sources give it the part number 3195 (S/370 part numbers were 3xxx).