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
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.
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 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 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.
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.
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 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.
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.
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 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)
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.
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.
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.
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.
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.
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.
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.
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 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.
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 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.
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
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
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 65 had six rollers, and a voltmeter with just a couple knobs.
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.
_console_-_Computer_History_Museum_(2007-11-10_23.06.26_by_Carlo_Nardone).jpg){kind=link}
Notes and references
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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.) ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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. ↩
-
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.) ↩
-
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." ↩
-
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). ↩
I joined IBM in late 1976 and was surprised how physically large the machines were.they consumed lots of electricity and gave out a lot of heat hence the need for water cooling.But considering their complexity they were reliable and easily fixable quickly when something went wrong.
ReplyDeleteThe company almost went bust in later years by trying to sell their own old technology and following the wrong one and so had some catching up to do. Head in the sand springs to mind. Their management systems could not keep up with the success of the PC.
I was surprised to find this 'old computer' running the UK's air traffic control system when I joined the CAA in 1989 - it used an IBM 9020D which is a triplex (3) model 65 S/360 with two model 50s as I/O 'elements' for radar data processing. It was replaced the same year by dual IBM 4381s; gone were the card reader and ounch, though we continued to use mag tape.
ReplyDeleteThanks for the trip down memory lane. My university threw a big party, complete with cake and party hats when they expanded the 360/65's memory from 256K to a whopping 512K. The 360/65 was also capable of time-sharing, via the TSO option.
ReplyDeleteWe had dozens of Selectric terminals and CRT's available across campus. Heady stuff back in the early 70's. Of course time-sharing access entailed an extra charge.
As a system programmer, I was hands on with several 360/70 consoles and control panels from 30s that I managed to stuff OS/360 HASP into up to 165s?. PCP, MFT, MVS,VM and guess what? No Viruses!
ReplyDeleteAnother wonderful blog post, Ken. Thank you!
ReplyDeleteHow might a planning project team have been able to determine the costs associated with the environmental maintenance and electrical costs that a given system would require, on top of the monthly rental amount? Because I am assuming that a business would have some idea of the workload that would be performed, would there have been a way to compare and contrast the total cost of different models given that same load?
I’m completely fascinated with trying to get my mind around how these systems were implemented and how companies could calculate their returns on the investment.
Thanks for this beautiful post.
ReplyDeleteOne of the things I remember from my MF times is that the documentation specified how many master-terminal operators, system programmers, application programmers etc you needed to run a certain work load...
Ken, while this is a fantastic resource, I feel it would add to the interest to embed videos of these consoles in operation, where possible. I know LCM+L have an operational 2030, but I was also thinking of existing YouTube videos of LCW's 2030 console, driven by a complete emulation of the 2030 hardware:
ReplyDeletehttps://www.youtube.com/watch?v=_8YXFhowc3A
and Camiel Vanderhoeven's working 2065 console emulation, which is unfinished but starts to IPL OS/360:
https://www.youtube.com/watch?v=Fm-ZMACqrK8
Cheers
Mike
Great job Ken. I was trained on the 360 Model 25 in 1976 as an IBM Customer Engineer. It was used as the front end to the 3890 check sorter. The early versions used core memory and I believe that may be the last storage technology where you can visually see 1 bit. I still have a 2K module consisting of several flat planes. There are 9 'donuts' for each the byte, the last bit serving as an error detection bit. These machines were really a lot of fun to diagnose and fix.
ReplyDeleteThank you, really very interesting blog. In these times, we were isolated behind "iron curtain", first IBM machine I was working on was 370/145.
ReplyDeleteThank you once more.
| 15. A CRT display was used for the console on
ReplyDelete| the models 85, 91 and 195. (I suspect this was
| because CRT display technology had advanced by
| the time these later systems were built.)
It had nothing to do with CRT display technology
(advanced OR cheaper). In the case of the 360/91
(and 360/95) and the 360/195 (and 370/195), the
reason for a CRT operator console was speed; the
"printer" (and Selectric typewriter ball-based)
consoles were simply too slow for the fast CPUs.
The 91 (and 95) and 195 models still had huge,
control and indicator panels, but they were not
integrated with their CRT-based operator display
consoles. The 360/85 used an integrated system
console that incorporated both the CRT console
display and the indicator and control panel, but
the indicator panel section was small [like the
CRT console] and the control panel section was
very small (smaller than the one for the 360/30)
and integrated with the chassis that housed the
CRT display.
In other words, starting with the 360/85, they
stopped building huge "blinking lights" panels
that were so popular with executives, visitors,
and media photographers. The CRTs were needed
for message display speed, regardless of cost
(or technology), and computer rooms needed the
space occupied by the 6-, 7-, and 8-foot wide
blinking lights and control panels for actually
useful equipment.
The size of the control and display panels (as
distinguished from the actual "operator console"
on which messages were typed or displayed) was
merely a reflection of the internal complexity
of the CPU. The knobs, switches and blinking
lights were of essentially no use to the actual
computer operator (other than impressing visitors
and enabling one to observe patterns indicating
that the system was operating normally -- or not).
They were mainly needed by the IBM FEs performing
maintenance and running diagnostics.
The indicator panels for the 91 (and 95) and the
195 were huge simply because there was a lot that
needed to be displayed. The Model 360/85 was more
complex; an indicator and control panel for it
that used "discrete" lights and switches would
have been unacceptably huge, so they used the
"Microfiche Indicator Viewer" (part of the "System
Control Panel") instead. The actual 360/85 operator
console (the "Main Control Panel") housed the CRT
(which displayed messages issued by the operating
system, etc.) and the knobs, buttons, and switches
actually used by the operator (such as the blue
LOAD/IPL button and the Load Unit Address dials).
This 360/85 "System Control Panel" was also used
for the System/370 Models 165 and 168 (where IBM
called it the "IBM 3066 System Console"). As far
as I was able to tell in 1971, the 3066 was only
cosmetically different from the 360/85 "console."
| The models 91 and 195 used a display based on
ReplyDelete| the IBM 2250 Graphics Display Unit. This was a
| vector display, drawing characters from line
| segments instead of pixels.
The integrated operator console on the 360/85 was
also a vector display, and was also based on the
IBM 2250, except I don't remember it having a light
pen. The System/370 Model 165 was essentially the
same machine as the 360/85, except that it used
"old" (used, returned) 360/50 core memory modules,
which caused many legal and contractual problems,
because the 370/165 was being sold as (all) "new"
and many organizations and state and federal tax
laws treated (genuine) new equipment differently.
I was a hands-on user of both the IBM 2250 display
and the 370/165 operator console.
The operator console on the 360/195 (and 370/195)
was called the "IBM 3060 Model 1 System Console."
It was also based on the IBM 2250 Graphics Display
Unit, but was, IMHO, much better (more lines could
be displayed). The IBM 3066 console used with the
various 370/165 and 370/168 models, along with the
earlier, nearly-identical twin, the 360/85 System
Control Panel, was smaller (about half as tall and
showing about half as many lines of text) than the
360/91 (and 360/95) and 360/195 (and 370/195) CRT
display consoles; the vector graphic characters
were clunkier, larger, and seemed to be drawn in
a sloppy manner (line segment ends did not always
match up nicely), and very much less clear than
the 3060 (and 2250) CRT characters. One would have
thought they would be as well rendered (or even
better, for supposedly more modern technology),
but the 3066 definitely had a low-budget look.
That said, the 3066 was FAST (which goes a long
way towards explaining the difference I suspect).
As a hardware CE in the late 60s I was called in from fixing unit-record gear to help with the installation of the first model 85 in the San Francisco Data Center, which was an all-hands-on-deck effort for the local branch office. I recall the steel frames being installed then lots of copper piping for the coolant system being plumbed into them.
ReplyDeleteI also recall how the weakest link in all of these systems was the console printer. It was a beefed-up Selectric typewriter but even with improved bearings, the Selectric mechanism was never meant to pound away printing OS messages constantly 24/7. When the console printer failed, DOS or MVS stopped and nothing could be run until it was fixed. So the CE who had Selectric training was liable to late-night callouts at any time.
The images in the article itself are blurry and upscaled (on my HiDPI screen) so I thought the originals were just unfortunately crappy. Until you talked about a 'flow diagram [of the Model 50]', which I couldn't spot, until... snap, the images are clickable! And are actually of a higher resolution.
ReplyDeleteAs almost all webpages I know don't display upscaled thumbnails or images anymore (i.e. they're HiDPI compatible), I wasn't actively paying attention to it. I don't know if it's the fault of Blogger or how you upload the images (as I don't know other Blogger sites)
Love your work. :-) I have used a lot of these systems since 1966 when I entered The Computer scene. We ordered a "40" and time on a "30" until it was delivered.
ReplyDeleteI would love similar historical record for the IBM operating systems.
In 1966, we ran BPS for Fortran as the "new" Fortran 4 would not run on BOS, and Basic Operating System (BOS), both Tape and Disk resident for accounting and managerial applications. Then BOS became TOS or DOS, then the HUGE upgrade - DOS 10! etc etc..
The planning guides for the machines gave power consumption figures - so many KVA for box 1234 and feature abcd. They also listed heat output which allowed the installtion to figure out the power requirements for both powering the machine and cooling it.
ReplyDeleteGiven those levels. the customer could get pricing on so many tons of cooling and so many A of 3 phase power, for the ACs and the electrical conditioning, switching and wiring costs.
A customer knew quite accurately what it would cost to build up the data center and then to operate the machine,
The final elements were the labor costs of operators and systems programmers, plus the maintenance monthly charges to IBM.
Thanks for a great rundown of the 360 series. It was a classic, not just of technology, but of marketing design. Alfred Sloan built GM to produce a car for customers in narrow income bands, so GM had many car brands and models within those brands. IBM segmented its market similarly, and it really shows with the 360.
ReplyDeleteI saw the 360/95 at Columbia/Lamont-Doherty's and NASA's Goddard Center back around 1970. It had a huge 4MB memory module. It was the size of an industrial AC unit with water pipes for cooling running in and out of it. I was told it was all core memory. Was it replaced with a thin film memory after my visit? Was I listening to an unreliable narrator? He went on to head computing at the NSA.
Between that memory unit and the CPU there was a much smaller unit placed in a space clearly allocated for a module commensurate with the core memory unit. I was told it was a memory cache unit using "monolithic" memory technology. I was in high school and technologies were in flux, so I never got more detail than that. Perhaps that was the thin film memory unit? I vaguely remember it as having a 16KB capacity, but this is a rather vague memory.
Kaleberg stated/asked:
ReplyDelete| I saw the 360/95 at Columbia/Lamont-Doherty's and NASA's
| Goddard Center back around 1970. It had a huge 4MB memory
| module. It was the size of an industrial AC unit with water
| pipes for cooling running in and out of it.
| I was told it was all core memory.
| Was it replaced with a thin film memory after my visit?
| Between that memory unit and the CPU there was a much smaller
| unit placed in a space clearly allocated for a module
| commensurate with the core memory unit. I was told it was a
| memory cache unit using "monolithic" memory technology.
| Perhaps that was the thin film memory unit?
Kaleberg, Your memory is excellent. To answer your questions:
The 4MB core memory unit was NOT replaced after your visit.
The 360/95 had BOTH core and thin-film memory units. Each
thin-film memory unit contained 64KB; the 360/95 had 16 thin-
film memory units totaling 1024KB (1MB) of very fast memory.
In addition, the 360/95 had 4MB of (ordinary) core memory.
Hence, a total of 5MB of "main" memory: 1MB really fast and
4MB relatively slow (but nonetheless very fast compared to
all but the 360/65 and 360/75 [and possibly the 360/85]).
This comment has been removed by a blog administrator.
ReplyDeleteMany Thanks for this great page!
ReplyDeleteI started my IBM career in 1979 at the Munich branch office. We had a /360 Mod. 91 installed at our customer 'Institute for Plasma Physics' (IPP). Your picture 'Console of the IBM System/360 Model 91' is NOT the Munich machine.
https://www.mpcdf.mpg.de/about-mpcdf/publications/bits-n-bytes?BB-View=200&BB-Doc=211
The Mod. 20 was developed by the German IBM laboratory in Boeblingen, this lab as a collection of historic IBM products, including an Mod. 20 which is still in running condition. The German Lab is still working on new generations of IBM System z mainframes.
One Mod. 20 was rescued from defunct German factory in April 2019, see the great story
https://ibms360.co.uk/?page_id=22
best regards
Norbert Ziegeler
As an ex-IBMer (40 very happy years) who started with the 1401 and 360/30 in 1970 I’d just like to point out one factual error ... we never “booted” a 360 (or 370 later) ... we I...P...L...ed or re-IPLed the system. The IPL record was placed upon Cylinder 0 Track 0 of the IPL device which the channel program read when the IPL button was pressed.
ReplyDeleteAlthough it was also possible to IPL from a deck of punch cards (typically 00C), paper tape (typically 007), or magnetic tape (typically 181), if you needed to perform some maintenance on the system disk.
The expression Boot was not used until the part of the system disk from which the system was started was contained in a Boot Sector which came about in 1981 with the IBM PC [although it’s possible that the term Boot was used in IBM office products ... a part of IBM with which I had no familiarity].
PJ, IPL stands for Initial Program Loader, and when the LOAD button was pressed the program it executed was called the "Bootstrap" program - A bootstrap was the little loop at the back of a boot to pull it on by, so a bootstrap program was a little program that got your program in and started.
ReplyDeleteOther manufacturers did not have an IPL button like IBM, and I've even had to do an IPL by actually keying the bootstrap program via front panel keys!
Usually the bootstrap program consisted of two instructions - Read 1 record from the boot device into a memory location then branch to that location. Therefore that record had to contain the "real" loader program, which would then load and execute your program.
At the University of Missouri, Rolla (now MST in Rolla), we had a 360/50. It ran a subsystem called CPS, which was a firmware extension supported timeshare system, as well as running as a 360/50 running MVT 21 and HASP.
ReplyDeleteThe CPS system included an outboard memory system called LCS (don't have a number), which had 1mb of memory, and when CPS was up, was used to support the users.
CPS could run with the MVT system active.
Our system had 512K of memory in the main box.
Two unique things about the 360/50 at UMR. It was supposedly the only non power of 2 system ever built up by IBM which could run as such. 1.5mb was not a standard for 360 memory sizes.
And supposedly, it was also the only non leased 50 at the time. IBM sold the system during the development of the 360/50 and shipped a 360/40 to the campus in 1969 or 1970 which was used for around a year till the /50 could be delivered to replace it.
Jim Stephens
| Two unique things about the 360/50 at UMR. It was supposedly the only
ReplyDelete| non power of 2 system ever built up by IBM which could run as such.
| 1.5mb was not a standard for 360 memory sizes.
Nope. There were many of those. I had one that was 256KB (fast core) + 1MB (LCS). There were others I knew of (and just in NC), including 1.5MB (512KB regular + 1MB LCS). OS/360 NIP recognized these "odd" main core storage sizes and could figure out how much was "fast" and how much was "slow" (i.e., LCS). Unmodified, all the LCS core went into "Hierarchy 1" storage.
| IBM sold the system during the development of the 360/50
That would have been around 1965 (not 1969).
| and shipped a 360/40 to the campus in 1969 or 1970
By then, there were (I suspect) hundreds of 360/50 installations. It was a very popular machine (much more flexible than a /40).
| which was used for around a year
| till the /50 could be delivered to replace it.
It is much more likely that your 1969 or 1970 date is incorrect.
There were, in fact, "many" 360/40 machines shipped to customers who wanted larger ones (including 360/75s) to use temporarily until their box could be delivered. But all of those production problems were over by 1967 and everybody that wanted a /50 or /65 or /75 had them or could get them (with the usual sort of order lead time that was expected then).
I also used CPS, and loved it for some interesting research applications. It was actually much better than TSO in OS/360 Release 20.1 and 21.x. IMHO, TSO was essentially useless except for limited applications [and this does not include text or program editing) until the OS/VS2 1.6 and SPF era arrived.
There were 2 versions of the 360/50 front panel. See http://www.quadibloc.com/comp/pan04.htm for both. Ones with smaller main storage had a very cute diagram of the CPU dataflow on the top right.
ReplyDeleteThanks for the great site-pictures!
Regards, Len
I still work with the main UK Air Traffic control system - originally written for 6 x 360-65 and now very happy on a a couple of Z-Series processors. Such elegant programming and resilience built in the architecture.
ReplyDeleteThe link http://www.quadibloc.com/comp/pan04.htm is broken or compromised (it leads to an insecure location that cause several malware detection tools to call a halt to proceeding further).
ReplyDeleteI joined LJ Hooker as a Programmer/operator on 3rd September 1965 in Sydney Australia and we got one of the first 6 that were shipped into Australia. Prior to that we were programming, in Assembler and testing on IBMs machine down at the Pagoda near the Sydney Harbour Bridge. Our science teacher from my high school the previous year was teaching us programming and begged me not to tell anyone because he was only a few pages in front of us in the reference manual. The 1311 disk drives only held 11 million characters and we had to fit programmes into 32k. We had no console typewriter so we had to dial instructions in. The following year I joined an aftermarket company and when a customer came to the front desk to enquire after a part, we had to pull the system interrupt to stop the computer, load the enquiry in on a card and check the print out from the printer.
ReplyDeleteWe found the disk drives were great for sleeping behind when we pulled the 24 hour shifts to implement systems. They threw out a lot of heat in that air conditioned room.
We definitely felt like pioneers.
We have come a long way. From hardware driven enterprises to data-driven enterprises. Companies today are much mroe flexible, have a ton of data available and software centric. Today, hardware is not a problem but speed and processing power is!
ReplyDeleteI tripped across this blog when searching for an old IBM part. Glad to see the information captured and catalogued in this very complete form. Many thanks.
ReplyDeleteI joined IBM in 1967 (it was referred to as the "Gold Rush" period) as a Field Engineer. I specialized in the Model 50, then later in the S370 155, 155DAT, and 158. Lots of fun and lots of great memories.
I worked far deeper in these systems than most IBMers. If you want to read a bit more "inside" information, pick up a copy of my life story (or at least the first 70 years) titled "From Shasta to Shanghai". It is available on Amazon.
Tim Griswold
[email protected]
A very good read Ken! It was a real treat to revisit my days as an operator of the 360/20. It was my very first mainframe experience back in 1972. I then went through several models of the System 370 line and then settled on the 4331, 4341, and finally a 4381 in the late1990’s. Thanks for the memories.
ReplyDeleteMy first exposure to the 360 line was as an operator of a 360/30 on the night shift at a bank. Later, wrote my first COBOL programs on a 360/40. A great, nicely done article!
ReplyDeleteLearned my first bit of computing on a 360/40 at the Computing Learning Center of Los Angles with a dos/vse system. Said goodnight to what was probably the last dos/vse system on 21/dec/09 at EDS with one of the last OS's still running it for Phillips.
ReplyDeleteA borrowable version of IBM's 360 and Early 370 Computers is available at
ReplyDeletehttps://archive.org/details/ibms360early370s0000pugh
Also the history of the predecessors
IBM's Early Computers
https://archive.org/details/ibmsearlycompute00bash
Excellent post Ken. We loved our "Big Iron". I started my operator career at a Texas Junior-College on a mod40, parlayed that into a gig with the State of Texas herding "jobs" through a mod50 + mod40 pair on grave-yard shift, and was tickled pink to land a position with Lockheed-Electronics operating in the five-plex of mod75RT behemoths sporting LCS (Real-Time mods included the clock [of course] and circuitry for four additional interrupts plus the necessary new machine instructions to handle those interrupts, with extensions to the PCP Kernal under OS360RT the beast ran) that NASA used for the Apollo program. We "flew" 16 & 17 and I hung around until the Apollo-Skylab program shutdown. By the early '90s, I'd completed the programmer-analyst-manager progression out to the end of my hands-on main-frame career. The last 25 years have been internet-centric but you might be surprised how often my main-frame chops have come in handy...
ReplyDeleteHey all-
ReplyDeleteI have a control panel of a model 40 in my possession, looking to find a missing button and “red emergency off”
Anyone with info please reach out!
You missed two models—the 64 and the 66. They were variations on the 60 and 62, with DAT (Dynamic Address Translation—virtual memory) added. You missed them because it was only one month later that the 60 and 64 were dropped altogether, and the 62, 66, and 70 were replaced with the 65, 67, and 75.
ReplyDeleteThere was also the 69, but that was a joke, with added op-codes such as Halt and Catch Fire, Punch Disk, and Punch Operator.
(There was also a joke about “OS/360: Multiprogramming with a Variable Number of CPUs”, but, dear God, we actually have that now!)
Back in 1976 I worked for a contractor in the basement at NASA Headquarters on the DC mall where I was a systems programmer on a Model 50 running OS/MVT. We launched payroll and radio frequency inventories, not speceships. I forget the details but we even had TSO with dialup modems (110 baud?) connected to TTY terminals. If I was a Soviet aganet I could probably have loaded spyware into the "link pack area" but I was a loyal American. Although I maintained the OS, sometimes working Sunday nites with probably nobody else in htt building escept maybe a nite watchman, I did not have security clearance. When they ran the progran for radio frequencies (I have no idea what it actuslly did) they cleared mamory and rebooted the machine. It was known among us contractors that our 2nd line manager had an open bottle whickey in his desk but that was not a problem: the first line manager kept on top of things. I seem to recall that the GS-15 who was in charge of us was mainly interested in a restaurant he owned somwehere. Times and computers have changed. No more Sunday nite work to get machine time, but I got PTSD from undocumented apis like Angular and Django.
ReplyDeleteExcellent post!
ReplyDeleteThese panels scared everyone and were IBM's trademark.
In fact, they were a testament to the state of technology, which did not allow "intelligence" to start the machine, interpret the states it was in or repair it when it broke.
This would happen with large-scale integration that allowed the existence of small processors that would do what technicians with great difficulty were required to do, which was decode hexadecimal messages and determine after difficult painstaking what was happening.
Although this was partially done for the larger models, which used CRTs instead of panels, the panels would only be eliminated in the 4300 generation, when a microprocessor began to interpret hexadecimal messages and transmit what was happening in English to the operator or CE.
Two important things happened there that would determine the future of IBM: The microprocessors that allowed this interpretation had their development outsourced and one of the companies belonged to Bill Gates, who returned to IBM and asked why they didn't make a home computer with it.
He was received with laughter and ridicule and, worse, allowed to try to do this alone, including using the small operating system developed by IBM, with all the information open and available.
The second thing that would determine what happened to IBM was a violent cost reduction in terms of memory costs and processing power, which would follow this trend until its policy of centralizing its strategy on hardware became unfeasible for IBM.
See in detail
https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4341.html
I elaborated all of this in greater detail in
https://computers19752016.wordpress.com/2016/10/30/the-missin-link-1975-2016/
I'm going to put a link on my blog site indicating this excellent post and I hope it won't be a problem.
Thank you for keeping the memory
Excellent post!
ReplyDeleteThese panels scared everyone and were IBM's trademark.
In fact, they were a testament to the state of technology, which did not allow "intelligence" to start the machine, interpret the states it was in or repair it when it broke.
This would happen with large-scale integration that allowed the existence of small processors that would do what technicians with great difficulty were required to do, which was decode hexadecimal messages and determine after difficult painstaking what was happening.
Although this was partially done for the larger models, which used CRTs instead of panels, the panels would only be eliminated in the 4300 generation, when a microprocessor began to interpret hexadecimal messages and transmit what was happening in English to the operator or CE.
Two important things happened there that would determine the future of IBM: The microprocessors that allowed this interpretation had their development outsourced and one of the companies belonged to Bill Gates, who returned to IBM and asked why they didn't make a home computer with it.
He was received with laughter and ridicule and, worse, allowed to try to do this alone, including using the small operating system developed by IBM, with all the information open and available.
The second thing that would determine what happened to IBM was a violent cost reduction in terms of memory costs and processing power, which would follow this trend until its policy of centralizing its strategy on hardware became unfeasible for IBM.
See in detail
https://www.ibm.com/ibm/history/exhibits/mainframe/mainframe_PP4341.html
I elaborated all of this in greater detail in
https://computers19752016.wordpress.com/2016/10/30/the-missin-link-1975-2016/
I'm going to put a link on my blog site indicating this excellent post and I hope it won't be a problem.
Thank you for keeping the memory
Your comment brightened my Christmas...
ReplyDeleteCurious how so far away, you were in DC and I were in Endicott NY, but everything you reported happened there in some way:
Testing the programs was a struggle because there were few prototypes and you were forced to work night shifts.
The idea that the Russians were spying was a joke... as we had to write manuals for custom engineers to use the diagnostics, we joked that it was written to deceive Russians...
And sometimes they gathered us together to scare us into not commenting on anything we did to anyone because we had signed non-disclosure commitments...
The clearances to enter where the prototypes were were difficult, even for us who were employees.
Managers didn't have a faintest idea about what we were doing and id they have a stacked bottle of whiskey I don't know, but it was what was left to them...
Eating in the early hours after we left was a problem and the places where you could eat were spread by word of mouth and the recurring topic;;
These were truly good'ol days...
Well, they were different days. I worked in the Virtual Storage Manager group 2nd floor BLdg 706 POK My first line manager [sraight not homosexual] literally came to work sometimes wering socks with machine stitched images of Mickey and Minny Mouse on them. Everything except one program was written in PL/S (similar to PL/1). I was a "gray top", i.e., my desk was real plastic top not simulated wood. Nobody wanted to touch that one assembly language program: it was beneath their exalted dignity as higher level language programmers. eagerlyI scarfed it up and rewrote the whole thing (again, in assembly language0. This was the age of "Improved programming technologies". Mickey Mouse told me they were going to have a walkthru of my code. I knew that thet meant: the fake wood tops humiliating the gray tops, e.g., me. I flatly told him I would not "be ground up" and would accept only specific criticisms of my code. He cancelled te walkthru and my very risky code shipped unreviewded which didn't happen but it did that time. Then along aome the 3033-MP which was not marketable because it was too powerful for the processors to be kept busy on only 16 meg of real memory. There was a fix, mostly in the hadware but a small part in the OS. It wa close to eyes only secrecy. Management knew I did not get on with the people in the virtual storage department but that's where they needed a patch and they needed it done right, not politically correctly. We came to an agreement which management honored: I would do it but the people in the team would have no say in what I did. It was a small fix but my patch was politically incorret (using integer devision instead of IF...THEN...ELSE). It shipped and never any APARS. My 3rd line manager once told me: "We know you can do the work your way, but what do we do with all the people who can't tell an 'L' from an 'LA'?" Times changed and I got PTSD from undocumented apis including angular and even worser: django.
ReplyDeleteStanford has some good photos of the 3 kinds of consoles on the disassembled 9020 air traffic control system. A multiprocessor that combined model 65 cpus with model 50 I/O controllers, and an impressive large console for overall status.
ReplyDeleteForgot to add
ReplyDeletehttp://infolab.stanford.edu/pub/voy/museum/pictures/display/FAA9020.html