IBM Advanced Computing Systems -- Denouement section

Mark Smotherman
last updated July 11, 2019

Denouement

At one point T.J. Watson [Jr.] visited and the machine was described to him. At the end he asked, "But where is the unit record equipment?" There was no answer to that. Later John Cocke described 20 parallel railroad tracks each with a train traveling 60 mph. The cars of each train were full of punched cards.

That was the bandwidth of the memory bus of ACS.

I worked (for perhaps a week) on a scheme to provide line printers scaled to the speed of the machine. Acres of printers. It was bizarre but fun.

-- Norman Hardy, personal correspondence

As the quote above indicates, the ACS-1 design was very much an out-of-the-ordinary design for IBM in the latter part of the 1960s. In his book, Data Processing Technology and Economics, Montgomery Phister, Jr., reports that as of 1968:

• Of the 26,000 IBM computer systems in use, 16,000 were S/360 models (that is, over 60%). [Fig. 1.311.2]
• Of the general-purpose systems having the largest fraction of total installed value, the IBM S/360 Model 30 was ranked first with 12% (rising to 17% in 1969). The S/360 Model 40 was ranked second with 11% (rising to almost 15% in 1970). [Figs. 2.10.4 and 2.10.5]
• Of the number of operations per second in use, the IBM S/360 Model 65 ranked first with 23%. The Univac 1108 ranked second with slightly over 14%, and the CDC 6600 ranked third with 10%. [Figs. 2.10.6 and 2.10.7]

In the midst of this environment in 1968, the ACS project experienced a dramatic change of direction. The original architecture had been designed for the perceived performance and floating-point-precision needs of customers such as the national labs, much like the CDC 6600. However, Gene Amdahl repeatedly argued for a S/360-compatible design to leverage the software investment that IBM was making in the S/360 architecture and to provide a wider customer base.

Amdahl wanted foremost to see a successful product be developed by the ACS project. He and Max Paley had been told of a rumor that "the Research Supercomputer plan was to be developed, then found that the market size was not sufficient to permit IBM to meet the government's antitrust constraints on its product announcements, then IBM could cancel the program and have the technology which was developed available for future product programs without having the technology development costs attached to these products, thus allowing a lower price to be assigned to those products!" He felt that the ACS architecture team was not orienting their design and development so as to avoid such a cancellation, and he did not want to be associated with a failed program.

Because of his strong and repeated advocacy for a S/360-compatible design, in 1967 Amdahl was frozen out of the daily activities of the ACS project. During the next year, and with help from John Earle starting in early 1968, Amdahl developed an outline of a competing design that was S/360 compatible but arguably faster and cheaper than ACS-1. In May of 1968, Amdahl's arguments won the day, and IBM.management dictated a changeover to a S/360-compatible ACS design.

The sequence of events leading to the change in the instruction set architecture for ACS includes:

• late 1964: Gene Amdahl returns to California to teach at Stanford

• January 1965: Amdahl is named an IBM Fellow

• early 1965: Amdahl is asked to work with the ACS project

• August 1965: Amdahl argues for S/360 compatibility at the Arden House planning sessions: "90-95% of Project Y machine at 5-10% more HW" (from Kolsky notes)

• January 1967: Ralph Palmer asks for an audit of ACS progress by John Backus, Robert Creasy, and Harwood Kolsky ("the Palmer committee")
  • Kolsky was a veteran of Los Alamos and the IBM Stretch project, and he was the official representative of the ACS project for DPD marketing
  • Kolsky argued that floating-point computation needs, register pressure (i.e., the need for more registers to avoid memory traffic), and the innovative branching and addressing architecture in ACS-1 argued against S/360 compatibility. Kolsky also included a tongue-in-cheek observation about the customers who would be interested in ACS:

    Actually, the machines which we are trying to supplant in the marketplace are not S/360 computers, but are really 6600's and 6800's. If we are going to try to use the program compatibility argument on these customers, then perhaps our machines should be 6600 compatible. Clearly, this is not an acceptable strategy.

• February 1967: Amdahl argues for S/360 compatibility so that a marketable product will result

• November 1967: Herb Schorr presents an ACS-1 schedule with first customer ship with OS and compiler software projected for Dec. 31, 1971; "rough estimate" of software expenses of $15M; lines of source code estimates: 75K Fortran / 29K assembly for OS and 67.5K Fortran for compilers, assembler, and library

• December 1967: Amdahl argues to Kolsky about the advantages of a S/360-compatible design; from Kolsky's handwritten notes (pdf):
  • for benchmarks like Coronet, half of the adds can be done with 32-bit precision rather than 48-bit or 64-bit
  • the ACS minimum time to prepare-for-branch is seven cycles, which means 14 to 21 instructions between branches; yet many codes have only four instructions bewteen branches
  • you can look for branches a little early, which give most of the gain
  • for benchmarks like DTF only four of the eight branches within the inner loop can be removed and replaced with skips
  • there is no need for a three-register format; for 360 codes, only 5% of the instructions are move register-to-register
  • the 360 RX instruction format reduces the need for a large register file
  • the investment can be put into improving the 360 OS rather than writing a new one for ACS

• early 1968: repeated problems regarding John Earle's interactions with other project members lead to a decision to freeze him out of the project; he is assigned to work with Amdahl

• over a three-month period, Amdahl convinces Earle that a S/360 version of ACS will be faster than the ACS-1; Amdahl and Earle sketch out a design that has 2/3 the cycle time of ACS-1 (8 nsec vs. 12.5 nsec) and that is overall 15% faster and requires 15% less hardware; their design is designated AEC/360 (or AEC-360) for Amdahl-Earle Computer

• March 1968: Kolsky meets with Amdahl and Earle to discuss the AEC/360 design; Kolsky is asked to write a critique of the ACS project for DPD management; from Kolsky's handwritten notes (pdf):
  • the current ACS design needs 7 levels of logic per stage, thus 12.5 nsec cycle time; although a lean design could possibly cut it to 6 levels (but some engineers say 6 levels is not possible)
  • the constraints on logic depth in ACS include preshift and postnormalization in floating-point operations; too many functions, and too many registers (fan-out to selection and to function units)
  • the ACS three-register format and large number of registers only buys about 10% performance (fewer instructions)
  • hardware solutions to branch and skip are better than software solutions
  • to improve performance in ACS, prepare to branch would have to be discarded (since it cannot branch ahead more than one level) as well as the 48-bit word and extra registers - then what is the difference from the 360?
  • AEC/360 needs only 5 levels of logic per stage, possible 8 nsec cycle time
  • current ACS needs 265,000 circuits; AEC/360 would need only 90,000
  • AEC/360 would be 2.5 times faster than ACS on code with many branches and 1.4 times faster for best ACS code
  • performance/cost ratio is 4:1 in favor of AEC/360

• March 1968: a task force is set up to compare the ACS-1 and AEC/360 designs; the task force members are W.T. Comfort, Carl Conti, Robert Litwiller, and D.M. Powers (Litwiller is the ACS-1 representative)

• April 17, 1968: Conti prepares a performance comparison memo based on the task force studies of five benchmarks - Assembler F, fixed-head-file enqueuing, bucket sort, matrix eigenvalue, and Coronet II. Without a simulator for AEC/360, the AEC/360 timings were estimated by hand for short instruction sequences using Amdahl's predicted 8 nanosecond cycle time. The AEC/360 was judged five times faster than ACS-1 on instruction sequences from the assembler, twice as fast on enqueuing, and equal on the sort. ACS-1 was judged two and a half times faster than an unenhanced AEC/360 on instruction sequences from the two floating-point benchmarks when S/360 64-bit double-precision operations were used to match the 48-bit single-precision operations of the ACS-1. However, an enhanced AEC/360 using an assumption of faster floating-point funtional units and using only 32-bit single-precision operations ran slightly faster than ACS-1 on instruction sequences from the two floating-point benchmarks.

  Conti's memo states in part:

  The comparison indicates the lack of any clear superiority of the ACS architecture and machine organization over a suitable System/360 machine organization. ... ACS architecture is superior to 360 architecture for a strictly high performance processor. The superiority, however, is in the 10-20% range. This superiority is due to a very few features of the ACS. First, the provision of the full address literal in storage to register instructions. Second, the ability to do fixed point and logical operations in the floating point area. Third, the branching structure which permits separation of the three functions associated with the branch: the testing of the condition, the generation of the branch, and the actual exit. Associated with the branching structure, of course, is the ACS definition of 24 condition bits registers and the skip instruction. ... Further, it would seem that the importance of the architecture is more than nullified when one considers how dependent performance is upon the algorithm chosen to solve a problem and the quality of the code produced toward that end. It is apparent that the ACS machine organization is more sensitive than the AEC/360 machine organization to the question of code optimization."

  Conti also mentioned a "pseudo skip" feature designed at Poughkeepsie as a hardware alternative to the ACS-1 skip architecture. This is likely US 3,553,655, "Short forward conditional skip hardware." The inventors were Model 91 team members Anderson and Sparacio.

• April 26, 1968: Kolsky independently prepares a memo in which he advises DPD management that while the scientific community desired a nonstandard 48-bit and 96-bit floating-point format, such a machine would only sell three or four copies; however, just as Stretch technology had propelled the 709 to the very successful 7090, he saw the same opportunity to use ACS-1 technology to propel the S/360 to the next level of performance; he felt that a S/360 compatible machine using the circuits, fixed-head disks, and compiler optimization developed by ACS would sell many copies; he also notes that DPD should not be concerned if a few non-S/360 machines were built for scientific purposes, but if the goal were to build and market a large number of them, then DPD would be very concerned

• May 1968: Vincent Learson flies to California ostensibly to directly hear arguments pro and con for S/360 compatibility; however, after a short time at the Saturday meeting, he firmly states that S/360 compatibility was now a project goal (Amdahl's recollection includes Bob Evans being present)

The decision to pursue S/360 compatibility caught most of the ACS team members off guard. Based on the mandate given at the founding of the laboratory, most project members felt that IBM management would never hinder their efforts at building the world's fastest supercomputer by requiring S/360 compatibility. However, several of the more senior members had noticed that they were giving more and more presentations during early 1968 and knew that a change in direction was being considered for ACS at company headquarters in New York.

The decision to switch ACS to the S/360 architecture seemed to ignore the architectural benefits sought and obtained by the design team; so, several original project members quit and went back to New York to the Research Division, including Phil Dauber and Herb Schorr. John Cocke decided to take a sabbatical at the Courant Institute of Mathematical Sciences at New York University. (While there he worked on a well-known compiler textbook with Jacob Schwartz; the textbook was made available in draft form but never formally published.)

Because of the architectural incompatibility, Amdahl's design, now termed the ACS/360, had to discard the innovative branching and instruction skipping schemes. The new design provided a strongly-ordered memory model as well as precise interrupts.

To achieve a profit for the ACS program, Amdahl asked IBM management to approve three ACS/360 models: the high-performance design, a 1/3 performance version, and a 1/9 performance version. He felt that these performance goals would be a good fit with the System 360 marketing plans. He remembers that IBM Corporate Marketing evaluated the targets and reported: "1) the supercomputer alone was a loss leader! 2) the supercomputer plus the 1/3 performance computer was break-even! And 3) the supercomputer plus both the 1/3 performance computer and the 1/9 performance computer was normal profit -- 30% pre-tax!" He remembers meeting with "the Divisional President and Vice President who worked on me for over an hour to get me to modify the multipliers of my 3 computers (which would increase their cost without increasing their market acceptance nearly as much)." Amdahl countered with a recommendation to shut down ACS. In May 1969, IBM management cancelled ACS.

Additional possible factors in the compatibility and cancellation decisions:

• Schorr had estimated in 1967 that ACS software would require a $15M investment, but IBM had seen schedule delays and cost overruns on both OS/360 and TSS software during 1966 and 1967.

• George Kennard, President of IBM SDD during the 1960s, noted that Paley's relationship with Bertram had soured over time and that Paley openly sided with Amdahl prior to the shootout.

• ACS circuit design problems and company bureauracy slowed the development process (e.g., one project member recalled a six-month delay while engineers in Fishkill argued over how best to package and attach to a board the 400-pin multichip carriers that ACS wanted).

• East-coast/West-coast competitive tensions within the company, including:
  • the performance achievements of the cache-based S/360 Model 85 and the company's emphasis on NS (Next System, or sometimes New Series; later renamed as S/370) being designed in Poughkeepsie
  • alleged Poughkeepsie mindset of allowing demonstration design projects in Research and ASDD to goad Poughkeepsie engineers on to better things, but working to kill outside projects whenever they got "too serious"

• The various S/360 models were selling well, and a Model 95 had been accepted at Goddard Space Flight Center in January 1968. IBM described the Model 95 as "the fastest, most powerful computer now in user operation." Thus, Watson's concern about the prestige of S/360 might have been put to rest. He also dropped the emphasis on competing in the high-performance scientific market.
  • IBM canceled the Model 90 series in July 1968; the Model 95 press release reads in part:

    The Model 90 series was initiated by IBM as a program to advance the state of computer art and to serve a limited number of sophisticated data processing users. With its program objectives met and all deliveries now scheduled over the next 12 months, IBM has stopped accepting orders for these computers.

  • CDC sued IBM for antitrust violations in December 1968, in part due to concerns with IBM's marketing of the Model 90 series.
  • in his autobiography, Father, Son, & Co., Tom Watson, Jr., writes about the Model 90 series in competition with CDC and his decision to cancel their sales (Bantam Books, 1990, page 384)

    Finally my business sense overcame my pride and I belatedly figured out that we couldn't compete with Control Data for the same reason that General Motors can't compete with Ferrari in building two-hundred-mile-an-hour sports cars. Supercomputers had become so highly specialized that even if we came up with a design equal to theirs, it would never fit in with the rest of our product line, our style of selling, our volume and profit targets, and so on.

    He goes on to say that his "temper was partly to blame for IBM's erratic behavior in the supercomputer market".
  • However, for an analysis of the market-signaling role played by the Model 90 series, see Russell W. Pittman, "Predatory investment: U.S. vs. IBM," International Journal of Industrial Organization, vol. 2, no. 4, 1984, pp. 341-365; note that ACS-1 would have played a similar, if not even a more significant, role.

• economics in general and especially for the IBM high-end, including:
  • Oct. 1966 3-by-3 decision on rental vs. buying; "activities of computer lessors had forced IBM to plan in 1968 to introduce budget cuts in 1970" [Fishman, p. 142]
  • a slowdown in the national economy and reduced growth in IBM finances in 1969

    Year	Employees	Revenue	(% change)	Net Earnings	(% change)
    1964	149,834	$3.23B	(+13%)	$431M	(+18%)
    1965	172,445	$3.75B	(+11%)	$477M	(+11%)
    1966	198,186	$4.24B	(+19%)	$526M	(+10%)
    1967	221,866	$5.34B	(+26%)	$651M	(+24%)
    1968	241,974	$6.88B	(+29%)	$871M	(+34%)
    1969	258,662	$7.19B	(+5%)	$934M	(+7%)
    1970	269,291	$7.5B	(+4%)	$1.01B	(+8%)

    [source: IBM Archives timeline web pages]
  • the profit/loss experience for the S/360 Models 75 and 85
  • corporate finance projections of the money needed for ACS/360 (based on cost returns for machines such as the 701, 650, and Stretch, the projections indicated that supercomputers were too expensive for the company)

After the cancellation a large number of ACS engineers wanted to stay in California. Several chose to work on disk drive systems at the IBM San Jose facility, including Mooney. Robelen and Galtieri left IBM to form MASCOR (Multi Access Systems Corp.), and Beebe, Buelow, Clements, Tobias, Zasio, and others left IBM to join MASCOR. Amdahl resigned in September of 1970 and formed his own company shortly thereafter. Many of the former ACS engineers at MASCOR joined Amdahl after MASCOR closed, due to MASCOR being unable to obtain the necessary additional venture capital to stay afloat.

The S/360 Model 195 was announced in August 1969 after the ACS cancellation, and a vector processing task force was started in Poughkeepsie that same month.

Excerpt from Gene Amdahl interview in April-June 1997, IEEE Design and Test of Computers, p. 7 and p. 13:

Amdahl: ... While I was [in California], IBM decided to set up the Advanced Computer Systems Laboratory to develop a very high-end machine. I had been named an IBM Fellow ..., and an IBM Fellow was entitled to work on whatever he wanted to, provided he did not impact the product line.

I went to work on this Advanced Computer Systems project, and I concluded after three or four months that it would be a much more manageable project if the machine were made compatible with System/360 instead of being an entirely different architecture. This did not endear me to the manager of the project, so I got sort of sent to Coventry. Anyone on that project who was seen talking to me - or me talking to them - got called out to a meeting.

D&T: So in a sense you were excommunicated?

Amdahl: That's right. They also had a very bright logic designer who had designed the most significant parts of the system they were working on, but who was virtually unmanageable. So they decided to get rid of him, and they gave him to me to work with. I told him what I wanted him to design in the 360 area, and lo and behold, we were able to get slightly higher performance at about 75% of the cost. And we wouldn't need to write a new operating system.

D&T: What happened?

Amdahl: We ended up having a shoot-out. The two of us who did the 360-compatible version won. We established that in fact we could achieve more performance at lower cost.

D&T: So you basically got a new architecture through this 360-compatible machine?

Amdahl: Yes, but the company decided not to build it because it would have destroyed the pricing structures. In the first place, it would have forced them to make higher-end machines. But with IBM's pricing structure, the market disappeared by the time performance got to a certain level. Any machine above that in performance or price could only lose money.

... I've always aimed to create a product that was useful to a great many people. So I didn't want to continue working on high-end machines at IBM when their pricing policy made that virtually impossible. ...

Excerpt from Gene Amdahl interview in July 2007, IEEE SSCS E-News:

(Q) Was IBM still planning ways to use your design talent?

(A) ... [discussing events of 1965] ... A few months later I was asked to consider attaching my Fellow activities to a new lab IBM was starting called Advanced Computer Systems, ACS, which would be designing a super computer, hopefully to serve the Livermore and Los Alamos labs. The project would be developing a computer proposed by a group from IBM research. I knew quite a bit about it and liked much, but not all, of the plan. I agreed to do it, but being a Fellow, I did not report to their management. For a few weeks I tried to make some changes in areas I didn't like, but to no avail. I recognized that with the requirement to develop the computer design, the technology and the total software support, that there was no way they could possibly find a big enough market to meet IBM's antitrust requirements of profitability. I didn't want to be associated with a loss-leading project, like had happened to STRETCH in the 1960s, so I thought about the problem and came up with a different approach - design the computer to be System 360 compatible and at the highest speed we could achieve. This would eliminate all of the software development cost. To make it profitable we could design one or two smaller machines with the performance spacing of the existing 360 product line, thus sharing the technology development costs over a much larger market and maybe meeting the profitability requirements.

(Q) How did you fare in the design challenge and the consequences?

(A) I presented my alternative to the project managers only to have it rejected out of hand, for they were wedded to the architecture they had developed. I was pondering how to separate myself from the impending loss leader when their top logic designer got into some trouble. The managers considered him unmanageable, but couldn't fire him so they found the solution, transfer him to me! I was delighted for he was responsible for the design of the most performance determining part of their computer. I knew that if he did the design of that part of the 360 alternative, there could be no charges of faulty design. It took a bit over two weeks to describe enough of my performance approaches before he recognized that it was really feasible to compete with the other design. He then went into it wholeheartedly and actually was able to achieve a slightly higher performance and a somewhat smaller cost. Bob Evans came out to ACS with about five technical people and they held a shoot-out. We won and I was made the lab manager. The first thing I did was have the two smaller computers costed. I then submitted the three system plan to corporate pricing. The single highest speed computer was a loss leader. The second smaller computer added made a break-even program. Adding the third even smaller computer came out with normal profit! IBM management decided not to do it, for it would advance the computing capability too fast for the company to control the growth of the computer marketplace, thus reducing their profit potential. I then recommended that the ACS lab be closed, and it was.

See also:

• "Attacking on the flank," IEEE Computer, March 1973, pp. 37-39.
• Bro Uttal, "Gene Amdahl takes aim at IBM," Fortune, September 1977, p. 106+.
• Gene Amdahl, "The early chapters of the PCM story," Datamation, February 1979, pp. 112-116.
• William Aspray, "Gene Amdahl Oral History," September 24, 2000, San Jose, California.

Innovations in ACS/360

• carried over from ACS-1 design
  • backup registers
  • 8 prefetch sequence control registers
  • multiple issue
  • precise interrupts
  • fixed head disks
  • SIOF (start I/O fast release)
• new to ACS/360 design
  • memory consistency
  • two one-bit path flags (C1 and C2) were added to each decoded instruction so that the machine could fetch past up to two conditional branches (see the Hasbrouck patent)

The ACS/360 design was based on this overall structure:

• I-unit (instruction unit), with ten 64-bit instruction buffers
• S-unit (storage unit), with a six-deep instruction stack and two effective address adders
• G-unit (general purpose arithmetic unit), with a four-deep instruction stack and 20 32-bit registers, and which can start up to one instruction per cycle
• F-unit (floating-point arithmetic unit), with a six-deep instruction stack and 12 64-bit registers, and which can start up to one instruction per cycle

Sidebar: Multithreading

In summer 1968, Ed Sussenguth investigated making the ACS/360 into a multithreaded design by adding a second instruction counter and a second set of registers to the simulator. Instructions were tagged with an additional "red/blue" bit to designate the instruction stream and register set; and, as was expected, the utilization of the functional units increased since more independent instructions were available.

IBM patents and disclosures on multithreading include:

• US Patent 3,728,692, J.W. Fennel, Jr., "Instruction selection in a two-program counter instruction unit," filed August 1971, and issued April 1973.
• US Patent 3,771,138, J.O. Celtruda, et al., "Apparatus and method for serializing instructions from two independent instruction streams," filed August 1971, and issued November 1973. [Note that John Earle is one of the inventors listed on the '138.]
• "Multiple instruction stream uniprocessor," IBM Technical Disclosure Bulletin, January 1976, 2pp. [for S/370]

Sidebar: ES/9000 high-end processors

The ACS/360 structure appears to have influenced the design of the IBM ES/9000 high-end ("520-based") processors some twenty-odd years later. The ES/9000 high-end processors were structured as:

• I-decoding
  • 128 KB I-cache
  • 4 K entry BHT; presence of branch in BHT indicates predict-taken
  • five 64-bit instruction buffers
  • ability to decode up to two instructions per cycle (e.g., a branch can be decoded in parallel with preceding instruction but not with following instruction)
  • instructions tagged with two predicted-branch-path bits
• ACE, with three effective address adders
  • I-ACE with two-entry queue; can execute LA instructions on its own
  • D-ACE with four-entry queue
  • SXE-ACE
• BXE, for controlling branch prediction and resolution
  • can execute BC instuctions on its own
• GXE, for executing fixed-point instructions
  • six-deep instruction queue, which can start up to two instructions per cycle in certain cases (e.g., one instruction has a general register result and the other has a storage result)
• FXE, for executing floating-point instructions
  • six-deep instruction queue, which can start up to one instruction per cycle
• SXE, for executing the storage-to-storage, decimal, and system control instructions
• register renaming
  • 32 32-bit physical fixed-point registers (for 16 architected registers)
  • 16 64-bit physical floating-point registers (for 4 architected registers)
  • two backup register assignment lists kept, one per predicted branch path (i.e., provides branch misprediction recovery)
  • ability to complete (i.e., retire) up to two instructions per cycle
  • synchronous interrupts recognized when instruction completes
  • a dependent load has to wait until the memory-value-producing store completes

For more information on the high-end ES/9000 processors, see J.S. Liptay, "Design of the IBM Enterprise System/9000 high-end processor," IBM Journal of Research and Development, vol. 36, no. 4, 1992, pp. 713-731.

ES/9000 water-cooled TCM photo from R.C. Chu, "Exploring Innovative Cooling Solutions for IBM's Super Computing Systems: A Collaborative Trail Blazing Experience", July 2010

For information on the packaging of the ES/9000 high-end processors in water-cooled (type 9021) thermal conduction modules, see:

• E.E. Davidson, P.W. Hardin, G.A. Katopis, M.G. Nealon, and L.L. Wu, "The design of ES/9000 module," Proc. 41st Electronic Components & Technology Conference, Atlanta, May 1991, pp. 50-54.
• R.R. Tummala, H.R. Potts, and S. Ahmed, "Packaging technology for IBM's latest mainframe computers (S/390/ES9000)," Proc. 41st Electronic Components & Technology Conference, Atlanta, May 1991, pp. 682-688.
• P. Hardin, G. Melvin, and M. Nealon, "The ES/9000 glass ceramic thermal conduction module, design for manufacturability," Proc. 11th IEEE/CHMT International Electronics Manufacturing Technology Symposium, San Francisco, Sept. 1991, pp. 351-355.
• D.J. Delia, et al., "System cooling design for the water-cooled IBM Enterprise System/9000 processors," IBM Journal of Research and Development, vol. 36, no. 4, 1992, pp. 791-803.
• E.E. Davidson, P.W. Hardin, G.A. Katopis, M.G. Nealon, and L.L. Wu, "Physical and electrical design features of the IBM Enterprise System/9000 circuit module," IBM Journal of Research and Development, vol. 36, no. 5, 1992, pp. 877-888.
• P.J. Brofman, S.K. Ray, and K.F. Beckham, "Electrical connections to the thermal conduction modules of the IBM Enterprise System/9000 water-cooled processors," IBM Journal of Research and Development, vol. 36, no. 5, 1992, pp. 921-933.

Navigation within IBM ACS pages:

Back to first ACS page

Next section: ACS Legacy