)
Figure A.1 Evolution of the AS/400
| Table of Contents |
With the rebirth of the System/38 as the AS/400 in 1988, I began to write a book about the history, the people, and the development of these two systems. I sprinkled a few historical excerpts from that work throughout the first edition of Inside the AS/400. The response to those historical sections was so good I have included an expanded version in this appendix of the second edition. As the unofficial resident historian for the AS/400, I feel it is my responsibility to tell the AS/400 story whenever I can. I don’t pretend to be a professional, unbiased historian; I will leave that role to others. I can, however, tell the AS/400 story as I personally experienced it. My story begins a long time ago on a beautiful summer day in 1962 in a land far, far away.1
1“The first law of storytelling is,” according to Mrs. Humphrey Ward (1851–1920), that “every man is bound to leave a story better than he found it.”
I vividly remember the first day I drove into Rochester and saw the complex of blue IBM buildings. Having previously seen pictures of the IBM site, I fully expected to see a giant blue industrial blight on the horizon. To my surprise, the blue buildings blended nicely with the surrounding farmland and with the many shades of green that make up the Minnesota summer landscape.
The IBM complex consisted of interconnected two-story buildings laid out in a checkerboard pattern around open courtyards. As I got closer, I could see the outer surface of each building was made from two-toned blue aluminum panels and tinted glass, separated every four feet by two-story-high aluminum I-beams. The morning sun shining on the I-beams gave the appearance of vertical silver bars against a blue background, or a giant blue cage. It was obvious why the local population had taken to calling the IBM site “the blue zoo.”
At the time I first went to Rochester, my father was managing an automotive parts distribution center for General Motors Corporation. Dad had several IBM card machines that his office staff used to process the parts orders from auto dealers in a multistate area. If one of the IBM machines broke down, Ferd Anderholm, the IBM customer engineer for that region, would come out to do the repairs. Ferd had moved to Rochester a year before I got there, when the new development lab opened, and he had become the manager of a new medical development area, working on joint projects with the Mayo Clinic. He managed one of the two development areas in the new laboratory, and I was looking forward to working for him that summer.
But when I arrived at the IBM site, I received some bad news. The other summer hire who had arrived a week earlier had taken the medical development job, so I would be working on the development of a banking terminal. This was not a good start, and it was too late to go somewhere else. I had already turned down other summer job offers. Besides, I needed the money and still believed that having IBM on my resume would look good to future employers, so I took the job. After all, I wasn’t going to work here forever.
It was then that I met Harry Tashjian, the manager of the bank terminal project. Harry must have heard I was disappointed about not getting the medical job because he spent a great deal of time with me that summer talking about Rochester’s future. He was convinced computers were a big part of that future, and Rochester would need people with intimate knowledge of computer design. He convinced me, and soon I began to think differently about computers.
I returned to school with a newly discovered interest in these electronic marvels. Most of my studies after that summer focused on digital computer design. The following year, when I graduated and it was time to find a permanent job, I could not resist the draw of this dynamic laboratory in Rochester. I signed on as an IBM employee working in Harry Tashjian’s area.
Before long, I found myself back in school pursuing a doctorate degree. Rochester needed people who understood computer architectures. Most of us were engineers with little experience in the software arena, and my previous training was in electrical engineering. So at Iowa State University, my studies concentrated on computer architecture and operating-system design.
ENIAC ( Electronic Numerical Integrator and Calculator) is generally regarded as the first commercially available electronic digital computer. J. Prespert Eckert and John W. Mauchly built this machine at the University of Pennsylvania. ENIAC was funded by the U.S. Army and became operational during World War II, but it was not publicly disclosed until 1946.
The invention of the first electronic digital computer, however, was for years surrounded by controversy. Originally, it was believed that Eckert and Mauchly invented today’s computer. In 1947, they applied for a patent on electronic computers. A memory system patent for ENIAC was issued in 1953, but it wasn’t until 1964 that the general ENIAC patent was issued. By this time, a Minnesota-based company, Sperry-Rand Univac, owned the patent. Eckert and Mauchly had earlier sold their company to Remington Rand, which later merged with Sperry Corporation.
By the middle 1960s, various companies were building and selling computers. Several of these companies had not paid for the right to use the ENIAC patents, so Sperry-Rand decided to sue one of them for patent infringement — winning that suit would bring the rest in line. Sperry selected another Minnesota company, Honeywell, and filed a lawsuit in the Federal District Court in Saint Paul, Minnesota, seeking $250 million in royalties.
Rumors and allegations had circulated for years that John Atanasoff, a professor of physics at Iowa State College beginning in the 1930s, was the inventor of the computer. At the trial, the truth would finally come out.
Iowa State University, originally Iowa State College, in Ames, Iowa, has a rich history in computers. John Atanasoff and Clifford Berry, a graduate student, designed and built a prototype of the digital computer we all use today. The Atanasoff-Berry machine was designed to automate the solution of linear simultaneous equations, which are used extensively in the physical sciences. As such, they were building a special-purpose computer.
Mauchly visited Atanasoff at Iowa State in 1941. Atanasoff had been working on his computer since 1938, and he shared the details of his work with Mauchly. Mauchly returned to the University of Pennsylvania, but he kept in touch with Atanasoff. In 1942, Mauchly wrote his first proposal to build an electronic computer. He later teamed with Eckert and they built ENIAC, which incorporated all of Atanasoff’s ideas. Work on the Atanasoff-Berry computer was interrupted in 1942 by the war, and it was never completed. No patents were filed after the first working model had been built because of an argument between Atanasoff and the university over who owned the patent rights.
On October 19, 1973, after a six-year legal battle, Federal District Court Judge Earl R. Larson issued his landmark decision ruling that “Eckert and Mauchly did not themselves first invent the automatic electronic digital computer but instead derived that subject matter from one Dr. John Vincent Atanasoff.” The ENIAC patent was invalidated, and the true inventor of the electronic digital computer we use today was recognized. ENIAC, however, does still hold the distinction of being the first general-purpose machine.
I have always felt a great affinity for John Atanasoff. In addition to designing computing machines, he loved to drive fast cars. He tells the story of one particularly frustrating day in the winter of 1937–38. Nothing was going right for his computer design. That evening, he took a high-speed drive across the state of Iowa. The temperature was 20 degrees Fahrenheit below zero, but there was no snow on the ground. The road was dry as he drove through the dark countryside, often at 80 or 90 miles per hour, with no particular destination in mind. He would later recall, “I made myself drive hard so I would be forced to give all my attention to driving and couldn’t think about that damn computer.” When he finally stopped 200 miles later at a roadhouse to rest and to rethink the day’s work, all the ideas for the electronic digital computer came to him. I can relate to that.
Dr. Robert M. Stewart, Jr., a professor of electrical engineering and computer science at Iowa State when I arrived in 1966, was nationally recognized as an academic and research leader in computer systems. An interesting irony is that in 1948 when Bob Stewart was a graduate student at Iowa State, the head of the physics department instructed him to dismantle the original Atanasoff-Berry computer to make room for an office and laboratory in the basement of the physics building. In the July 1984 issue of Annals of the History of Computing he wrote, “I had no idea what the equipment might be used for and whether or not it might be functional.” He said, “Atanasoff’s machine was dismantled,” and “the usable parts were returned to stock; the balance of the machine went to the loading dock to be hauled off with other trash.” Thus, the world’s first electronic digital computer was lost forever.
By the late 1960s, Bob had several advanced research projects under his direction at Iowa State. His work matched exactly what I wanted to study, and after some discussions, he agreed to be my major professor. One project that fascinated me was the Symbol computer project.
As early as 1964, a small group of engineers at Fairchild Semiconductor’s research facility in Palo Alto, California, believed that the future of integrated circuit technology was in using hardware to do traditional software functions. Rex Rice, one of the Fairchild engineers, conceived and led the Symbol research project. The goal of the Symbol project was to show that a general-purpose programming language and a large portion of a timeshared operating system could be built directly in hardware, resulting in great improvements in performance. (Timesharing was a technique used to share the resources of a computer among multiple users. Today we simply call it a multiuser system.) Some of those software functions implemented in the hardware were the compiler, the timesharing supervisor, and the virtual memory manager.
Gordon Moore and Robert Noyce at Fairchild enthusiastically supported the Symbol project as a way to exploit hardware technology. The first useful solid-state semiconductor electrical device, the transistor, was invented at Bell Labs in 1948. In 1959, Noyce at Fairchild and Jack Kilby at Texas Instruments independently invented the integrated circuit, a single piece of silicon with two or more solid-state devices embedded in it (the devices are connected on the silicon chip with wires made from thin layers of metal). As more devices were put onto a single chip, the question of how to use all these devices was the subject of much discussion. Moore and Noyce thought Symbol might provide one answer.
The evaluation and testing of this new system were to be done at Iowa State. I wanted to work on the project, but Fairchild saw the possibility of the Symbol computer someday becoming a competitor for IBM. Because I still officially worked for IBM (I’d only taken a leave of absence to return to school), I was not allowed to become involved. Little did I realize then the impact the Symbol project would have on the future of the IBM Rochester Development Laboratory: Symbol would provide the inspiration for the revolutionary architecture of the System/38 and the AS/400.
Symbol suffered from many complexities and performance problems. Many early design decisions were made in the interest of expediency, to get the first hardware running and to gain experience. A second, commercially viable design was anticipated that would correct many of the problems. When the fabrication of the initial system was completed and the evaluation was to begin, the semiconductor industry was in a recession. Before the machine was operational, Fairchild decided to discontinue the project.
Iowa State acquired the original hardware in 1971 with a grant from the National Science Foundation to bring the machine to full operation. The university wanted to ensure that the unique ideas of the architecture could be more fully documented and evaluated.
Symbol provided many lessons in designing complex computer systems. It was also a top-down design. The goals of the machine from a programmer’s perspective were defined before a chunk of hardware could be thrown together. The HLL interface isolated the programmer from much of the underlying complexities and eliminated the need for the programmer to worry about things such as memory management. It also provided a platform that simplified and improved the productivity for writing programs. These ideas fit the IBM Rochester paradigm for computer designs so well, it is no wonder that many of the ideas found their way into future Rochester systems.
“One of the most radical computer architectures of the last decade was the Symbol computer system, unveiled in 1971,” wrote David R. Ditzel in the July 1981 issue of Computer magazine. Ditzel was reflecting on his work evaluating this remarkable machine. He and a handful of dedicated students at Iowa State had spent four years on the Symbol project after Iowa State took over the project in 1971, probing the inner workings of Symbol under the direction of Bob Stewart and Roy Zingg, another professor.
Meanwhile, Moore and Noyce left Fairchild and founded Intel Corporation, where they could exploit integrated-circuit technologies. In 1971, Intel pioneered the microprocessor, a complete processor built on a single silicon chip. Ten years later, in 1981, Intel introduced a microprocessor they called the iAPX 432, which incorporated several high-level ideas that had their roots in Symbol. Many people who looked closely at the architecture of the iAPX 432 noted how strikingly similar it was to the architecture of the IBM System/38 that had been announced only three years earlier. Few realized that the two architectures had evolved independently from the ideas championed by Symbol. The Intel iAPX 432 was not a commercial success primarily because the design of certain basic functions, such as one program calling another, caused excessive performance overhead whenever they were used.
Because I was unable to work on any part of the Symbol project while I was at Iowa State, I had to find some other area for my research. The subject of virtual memory had always appealed to me; but I was perplexed at how the major computer vendors, including IBM, had taken this simple, elegant idea and twisted it into an overly complex structure.
Because of my Rochester background and my knowledge of IBM Rochester’s intent to build computer systems that were affordable for small businesses, I didn’t believe timesharing systems had a strong future. Besides, any business that had its own computer system would want to share data and programs among users of the system. A timesharing system had the opposite goal of not sharing anything because the users had no relationship to one another. Any sharing had to be done outside of the virtual memory. Operating system programs that managed shared files had to be created to allow sharing among users. As a result, the virtual memory included only a portion of the data and programs on the disk; the file system had to manage the rest of the disk space. This was definitely not what the original inventors of virtual memory had intended.
If the desire to share information among users was the primary goal, and if we changed the design of the virtual memory to accommodate this sharing, we could at last fulfill the original promise of virtual memory. If we put all data and programs into a single large virtual memory, and if we used other techniques for protection, any program or data in the system could be addressed directly from a program without any need to deal with a file system. This design would significantly reduce system overhead and greatly enhance sharing among users. The System/38 and the AS/400 would ultimately use this new design for virtual memory. In honor of the original inventors of virtual memory, we called this new design “single-level store.”
Rochester didn’t always build computers. Started in 1956 as a manufacturing facility, Rochester initially built punch-card machines, including the IBM 077 Numeric Collator. The 077 could read two decks of 80-column IBM punched cards and mechanically collate them. This machine used relays and vacuum-tube electronics to control the operations. In 1961, IBM established a development laboratory in Rochester. The initial assignment for the new laboratory was to develop the site’s first solid-state (transistorized) product, the IBM 188 Collator.
By the mid-1960s, some people in Rochester believed a huge market opportunity existed for a small, special-purpose business computer. IBM didn’t share this belief; it had just announced the System/360 line of computers. The philosophy behind the System/360 was that a single line of compatible computer systems, where a customer could move effortlessly from one model to another, provided the answer for all customers. The problem IBM had with its special-purpose computers of the 1950s was their incompatible architectures. Customers who outgrew one architecture would have great difficulty moving to another. The System/360 line of mainframe computers was IBM’s answer to this problem.
The last thing IBM needed was another incompatible line of computer systems, especially one that might end up competing with the mainframes. So the group at Rochester didn’t bother to tell the corporation they were building a new computer. Instead, they declared they were building a new unit-record machine.2
2As any child knows, it is easier to ask forgiveness than to get permission.
The punch-card machines that businesses used in the 1950s had been called unit-record machines. A punched card represented a single, or unit, record to be processed by the machine, so the name was applied to any machine that processed punched cards. The organization in Rochester that was to design the System/3 was appropriately called Advanced Unit Record Systems (AURS).
The new machine would use a new, smaller, 96-column card in place of the standard 80-column IBM card. Card readers, punches, collators, and sorters are mechanical devices. The cost of such mechanical devices is directly related to the amount of metal used to build them. If you reduce their size, you reduce their cost. So a smaller card meant we could reduce the size of the devices and hence their cost.
The small card was the brainchild of Larry Wilson, an IBM Fellow. Wilson was in San Jose, California, trying to sell his ideas for a small card, but he was not getting much interest. Most executives in IBM believed the days of punched cards were over, and they could see no use for a new small card. But when Tashjian heard about Wilson’s work, he invited him to bring his small cards and his card equipment to Rochester and work with the AURS team. Wilson accepted, and the 96-column card became the Rochester standard.
The processor design in the System/3 was extremely simple, with an instruction set oriented for commercial processing. Most of the 28 instructions operated on data in memory. The System/3 supported only decimal, binary, and character data types, and the processor operated on one byte of data at a time. To build the entire processor required only 3,000 circuits (by comparison, today’s PCs have millions of circuits).
Customers needed some way to program applications on the new system unit. The earlier unit-record machines had used wire plugboards, rectangular shaped boards with hundreds of small holes on the surface. To program an application, you connected pairs of these holes with wires that had small plugs on each end. These boards, housed in a rugged metal frame with carrying handles, looked like an old-fashioned telephone switchboard. The connections on a board told the unit-record machine what card columns to use and what operations to perform on the data in those columns. Typically, a single board represented a single application, such as a payroll program. To run a different application, an operator opened a door in the side of the machine, removed the old application board, and inserted the new board. Most machine rooms had metal shelving to hold plugboards for the assorted applications a business required.
Rochester’s new unit-record system needed a way to do programming similar to what the plugboards provided. A few years earlier, IBM had introduced a software product called Report Program Generator (RPG) for the 1401 computer, to simulate plugboard wiring. Created for the application programmer who knew how to wire plugboards, RPG incorporated much of the structure and terminology from the unit-record machine era. RPG also was implemented later on the lowest model of the System/360. RPG was not terribly successful on either the 1401 or the System/360; but because computer hardware was still too expensive to replace most unit-record machines, RPG was recognized as an easy way to program a business application.
One reason an application was so easy to program in RPG was that RPG was a non-procedural language. Most other programming languages were procedural, which meant the programmer had to direct the flow of the program. A simple way to understand the difference between these two types of languages is to imagine you have just landed at the Rochester airport and you need to take a taxi to a hotel in downtown Rochester. You get into the taxi and have two choices for how to get to your hotel.
You could give directions to the taxi driver. “Drive to the airport exit, turn right, and proceed a quarter of a mile until you cross the highway overpass. Turn left and go eight miles through six stoplights, then turn right into my hotel.” This represents a procedural approach, where you direct the “flow” of the taxi. A non-procedural approach would be simply to give the taxi driver the name of the hotel, sit back, relax, and enjoy the ride.
RPG allowed the programmer to sit back, relax, and not worry about the characteristics of the system or the flow of the program. The programmer could focus on the file and record definitions, and on the operations on those records needed to run the business — the same level of knowledge needed to wire a plugboard. The original RPG was designed for 80-column cards, so Rochester had to create a new version for the 96-column cards. Appropriately, they named this new version RPG II.
Critics claimed RPG was not a real programming language, but that was just fine with Rochester. For years, Rochester perpetuated the myth that RPG wasn’t a real programming language. After all, only highly paid programmers used real programming languages, and if customers had to go out and hire an expensive programmer for their business, they might not be able to afford a computer. On the other hand, small business owners, accountants, clerks, and secretaries could wire plugboards or program in RPG. Besides, Rochester wanted to sell the new machine as a programmerless system. A tactic we often used to sell to a new customer was to sit the owner and employees of a small business down and let them “program” a simple application for their business. Within an hour, they would see their application running on the system. This approach was usually all it took to convince them that this was truly a programmerless machine, and not something to be afraid of.
In June 1969, IBM announced the System/3.3 The original announcement was for a card-only system similar to the unit-record machines that the System/3 was aimed at replacing. The new machine was a batch machine, which meant one job at a time could be read into the machine and processed. Input data was supplied on the punched cards and the output could be either printed or punched into cards. The announcement material stated this configuration “provides most of the functions a punched-card accounting installation can perform.” Enhancements to the System/3 and new model announcements quickly followed. IBM announced a disk-based system shortly thereafter, and soon terminals could be connected. Rochester was in the computer business.
3Before its announcement, the System/3 had the code name the 3.7 System. Over the years, many people have wondered what this code name meant. Some people believe it represented a ratio of size or capacity differences between the small 96-column card and the larger 80-column card. Yet no calculation seems to yield the 3.7 number. The story I prefer relates to Larry Wilson’s car, which was a Jaguar. We didn’t see many of those great-looking cars in the 1960s, because they tended not to start very well during our cold Minnesota winters. And even if they did start, they usually couldn’t go anywhere. A heavy engine in front combined with a light rear end made them nearly useless on snow and ice. Wilson had the number 3.7 on the back of his Jaguar, presumably for the displacement in liters of his 3781cc in-line, six-cylinder engine.
As expected, the System/3 was extremely successful. The combination of a nearly programmerless environment and low cost made this system very attractive to many small businesses that previously could not afford a computer. This was totally new business for IBM, and approximately 25,000 machines would ultimately be delivered to customers.
I returned to Rochester late in 1968 with a new degree and a new vision of computer system design. I arrived in time for the System/3 announcement, but I never did work on the System/3 or any of its follow-ons. Instead, I worked on an advanced computer design that incorporated an HLL interface, similar to the concepts in Symbol. Symbol used a unique language, the Symbol Programming Language (SPL). All applications had to be written in this special language. I never felt it was very practical to require people to program in a new language just to use their computer, so I quickly dismissed languages such as SPL. I must admit that a few years later we looked at using A Programming Language (APL) , an IBM-developed language that many engineers loved because of its elegance and simplicity. APL was designed to be interpreted; but it was not clear how this language could fit into a commercial system, and the idea didn’t last too long.
To demonstrate the concepts of an HLL machine, we needed to build a prototype. The major language for Rochester systems was RPG, so we decided to build a computer that directly implemented RPG. Actually, a subset of RPG lent itself to direct interpretation; this subset never became a product, but we thought it might be useful as an entry-level system. We code-named the machine Linus, after the little brother of Charlie Brown in the Peanuts comic strip. Somehow this exemplified what we were trying to accomplish with this little brother of the System/3.
We decided that using hardware to directly interpret this RPG-like language was not practical. Instead we decided to write a microcoded interpreter. Dick Kiscaden, a newly hired engineer, wrote the microcode. Dick would later become one of the leaders in the laboratory to take the AS/400 into application areas such as client/server and network computing.
Linus taught us several things. First, direct interpretation of an HLL would not give sufficient performance for a general-purpose system. We should instead compile the high-level form of a program to some internal form before executing the program. Second, Linus taught us not to use a language such as RPG. We needed to have much of our operating-system code above the high-level interface, and we needed a language that would support operating-system programming. For the next few years, we experimented with several HLLs, including APL, before we decided on the far more flexible interface that is today’s Machine Interface (MI).
During this same period of time, I continued to hone my ideas for the implementation of a large shared memory. The address translation process was the most perplexing. Translation schemes for virtual memories of the day would not scale for the very large address we needed for a single-level store. For a while, I looked at an associative memory technology called functional memory that IBM Research was developing, but I concluded this technology would be too expensive to use in a Rochester system.
In December 1969, my manager called me in and told me that Harry Tashjian wanted to see my proposal for a new system architecture. The System/3 had just been announced, and shortly after the first of the year I was to show my design for the architecture of its successor to laboratory management.
On January 8, 1970, just three days before the Minnesota Vikings played in their first Super Bowl, the overnight low temperature had plunged to minus 22 degrees Fahrenheit and the Rochester Post Bulletin reported there was no relief in sight from the Arctic cold. That date was also the first time IBM Rochester management saw the proposal for the computer architecture that would carry them for at least the next 30 years. My proposal described an architecture with a high-level machine interface and single-level store. The driving motivation behind this radical architecture was the protection of the customer’s investment and the delivery of a computer system with long life and adaptability to changing technological trends.
Harry Tashjian approved the proposal, and by June 1970, we had an organization of nine people in place to begin the development of the new computer system. We called the new group the Advanced Systems organization, and Harry appointed Ray Klotz as our manager. I continued to have responsibility for the architecture design.
Our original goal was to announce the new system in 1975. This system was to replace the System/3, which by then would be six years old. As it turned out, a recession occurred in the United States during the early 1970s, and IBM stopped hiring new engineers and programmers. We could not fully staff this project until about 1974. Because of the startup delay, Rochester continued to enhance the System/3 product with the addition of the System/32 in 1975 and the System/34 in 1977.
I spent most of 1970 and 1971 working on the details of this new architecture and trying to sell its radical concepts to the System/3 engineers and programmers. We were making progress on the hardware side, but little was evident on the software side.
The announcement of the System/370 in June 1970 did not receive overwhelming enthusiasm. Many industry observers saw the System/370 as a System/360 on steroids. The announcement also coincided with the business recession that kept us from staffing the Advanced Systems project in Rochester. As a result, orders for the System/370 machines failed to meet expectations. And the cost of these machines had dropped so much that IBM would have to find many new customers just to maintain sales revenue each year.
In December 1970, the IBM Corporate Technical Committee suggested establishing a task force to set the goals for a totally new family of computer systems they were already calling FS for Future Systems, whose goal was to reduce the cost of developing application programs. Companies were spending twice as much on programmers and support personnel as they were on hardware. If FS could reduce the number of people required, IBM could get a higher percentage of the money that customers spent.
The proposed task force was established in August of 1971 under the leadership of John R. Opel. Opel, who would later go on to become president and then chief executive officer in IBM, was in charge of corporate finance and planning at the time. The Opel task force looked at different proposals before the group decided on one the Research Division had suggested. The belief was that a new system could be ready in less than four years, so the task force recommended proceeding.
In the fall of 1971, the Opel task force had finished its work and an architecture task force was formed to define the details of the FS architecture. This undertaking would determine IBM’s product direction for many years to come and also influence our architecture work in Rochester. Architects from all over IBM were called in to participate in the definition of the new architecture. Because Rochester was being considered to build the entry model for the FS line, I had the opportunity to travel to Poughkeepsie, New York, to participate in the architecture task force.
The definition of a new hardware and software architecture was such a massive undertaking that we quickly split into three separate task forces to define the various levels of the system. I was assigned to the New Machine Interface (NMI) task force that was to define the lowest level of the architecture. The two higher levels dealt with the external interface to the operating system and the application development interface. Even within the NMI task force, we occasionally split into smaller groups. I was one of four people on the addressing subgroup with the mission to define the virtual addressing structure for FS.
I still marvel at the talent that came together to define this new architecture. Many of the participants would go on to fill technical leadership roles within IBM. The head of the overall FS architecture task force was George Radin from Research. George would later lead the effort in Research to develop the first RISC processor. Pete Schneider was the head of the NMI task force. He would later become the vice president of development for all of IBM. John Cocke, the father of RISC processors, was on the addressing subgroup with me, as was Bob Tomasulo. Bob is well known in the industry for creating a technique to allow pipelined processors to do out-of-order execution of instructions. Nearly every major high-performance RISC processor today uses the Tomasulo Algorithm.
Perhaps it was this abundance of talent that led to the eventual downfall of FS. From the beginning, that there was no universal agreement on the FS system was clear. Participants from Poughkeepsie and many from Research wanted to ensure that FS would be totally compatible with the System/370 mainframes; they wanted to make the NMI look like an extension of the System/370 instruction set.
The hardware developers in various parts of IBM had already started to build new processors. They argued they could not wait for a new architecture to be defined before starting their design work, so they decided to build new versions of the System/370 processors and they assumed FS would be just an extension. In the early days of FS, the processors were named after birds of prey, with names such as Eagle and Hawk. Later, when the FS name was changed to Grad (short for graduate), all systems used names from academia. For example, the hardware technology was called Purdue, and one of the systems was named Michigan after the University of Michigan.
Another group of participants on the FS architecture task force led by members from Endicott, New York, wanted a more radical design. They wanted NMI to look like a high-level machine interface. Naturally, I sided with the Endicott contingent. Shortly after taking this position, I was thrown off the FS architecture task force.
Actually, all Rochester involvement in the FS architecture definition was stopped. By this time, a few other individuals from Rochester had joined me in Poughkeepsie to participate in the various task forces. We were all told to leave. The reason given was the task force leaders did not want the smallest system to unduly influence the design of the FS architecture in a way that might have an impact on the large systems. They would continue with the FS architecture definition, and we could use it in the future if it made sense to do so for our small systems.
Most of us believed the real reason was a concern that we might be split off from IBM. We were part of the General Systems Division (GSD) in IBM. GSD had been established in October of 1969 with its headquarters in Atlanta, Georgia, and two development laboratories — one in Rochester and one in Boca Raton, Florida. GSD also had its own sales and service people. Rumors were that IBM had offered to split off GSD to settle the U.S. government’s antitrust suit against IBM. The government attorneys had asked the court to split IBM into seven separate companies (if IBM actually did offer to split off GSD, the government attorneys did not accept the offer). Years later, when the antitrust suit was not as much of a threat, GSD was brought back into the IBM fold.
I returned to Rochester after my FS experience convinced that a high-level machine interface and a single-level store were the right directions to pursue. While I was in the addressing subgroup, I shared my ideas on single-level store. Another proposal from Research also was being called single-level store. I believed the Research proposal was far too complicated and didn’t provide a good protection mechanism for the addresses (we would later add tags to our addresses). The four of us on the addressing subgroup defined the addressing structure for FS, but it was still too complex to use in a Rochester system. I did, however, discover a technique that would let us efficiently translate a large virtual address, and I immediately began to define a version that would fit our single-level store.
One other idea we took from FS was the use of objects. Until that time, our proposed high-level instruction set addressed traditional types of data. The FS proposal to address objects provided a greater level of technology independence, and we blatantly stole the idea.
In addition to stealing a few good ideas from FS, we stole much of their terminology, including machine interface. IBM lawyers working on FS had determined that certain terms should be used when parts of the system were described. For example, code under the machine interface should be called microcode instead of software. Hence, we ended up with the meaningless names of vertical and horizontal microcode to describe some of our operating system code under the MI.
Meanwhile, back in Poughkeepsie, the group from Endicott who advocated a high-level interface finally won the argument and a new FS Machine (FSM) was defined. The argument polarized many of the participants, and disagreements were ongoing. This situation, coupled with the overly complex design and the difficulties of managing a project the size of FS across multiple laboratories in multiple countries, caused the FS project to fall behind schedule. By the fall of 1974, the system was still nearly four years away from announcement. In February of 1975, IBM mercifully killed the project. The System/370 mainframe architecture would have to carry IBM for many years to come.
To this day, some people believe IBM transferred the FS project to Rochester. This is not true. When we began to staff up the System/38 development in 1974, we hired several people from the failed FS project, who recognized similarities in concepts, including some of the ideas and terminology we had taken from FS. But for the most part, the corporation never knew what we were building. A few years later when IBM Corporate did find out, we had one of the biggest technical audits Rochester has ever seen. Space in which to hold the audit was hard to find, so management cleared out part of an unfinished manufacturing building so that they could bring in tables and chairs. The stark setting looked like the perfect place for an inquisition. After a couple weeks of intense questioning on our design, the audit team concluded that we had succeeded where FS had failed. They also found that we small-system folks had designed an architecture that was in many ways even bigger than either the FS architecture or the mainframe architecture. Isn’t that a surprise?
At about the same time as the FS architecture work started, another architecture proposal surfaced in GSD. A programming manager from Boca Raton, Glenn Henry, proposed this new architecture, called the GSD Entry architecture. Glenn proposed that Boca Raton should build a new entry system for the division, and his management seemed to back the idea. I remember the first time I saw Glenn. He had come to Rochester to present his architecture, and all I could think was “Who is this wild man?” He introduced himself to me as one of the world’s greatest authorities on virtual memory. I simply smiled to myself; there was nothing shy or reserved about Glenn. Although I was not too impressed with his architecture, I was very impressed with the man.
Later, at a meeting in Atlanta at GSD headquarters, Harry Tashjian listened attentively to Glenn present his ideas for a new entry system. Harry asked, “Is this a commercial system?” Glenn responded that it was. Harry then asked when Glenn was moving to Rochester to build the system. The agreement in GSD was that Rochester built all commercial systems. If Glenn wanted to build the GSD Entry, he had to do it in Rochester.
In January 1972, Glenn moved to Rochester and took over the programming management for what would become the System/32. He also was given programming management responsibility for the System/38, but he pretty much ignored that for the next couple years while he concentrated on the System/32. Ray Klotz held on to management of the System/38 engineering activities, which by then were well underway.
One of the first things Glenn did when he arrived in Rochester was to form a task force to define the GSD Entry system. My FS work was tapering off, so I joined Glenn’s task force. There, for the first time, I had the opportunity to work directly with two other members of the task force, Dick Bains and Roy Hoffman. I knew both of them, but I had never worked with either of them on a project. We quickly discovered our common interests in computer architecture design.
Before he came to IBM, Dick had extensive experience with Burroughs architecture. In the 1960s, Burroughs developed some leading-edge architectures with a focus on a high-level machine architecture. Dick, who had a strong programming-language and compiler background, had some very definite ideas about HLL machines. He also was very familiar with the FS work.
Roy had been working in the Optical Character Recognition (OCR) area in the Rochester laboratory. A small group of people there put together a proposal for a new system, called System/Q, which was another HLL system. System/Q never got off the ground because the OCR group did not have any responsibilities for systems, but the proposed system did incorporate many good ideas.
The three of us spent most of our time that spring talking about high-level machine designs and devoted little time to Glenn’s task force work. When the task force ended (the GSD Entry would become the System/32), we knew we could finish the design for the System/38 architecture if we worked together. That summer, we met every day to hammer out the details of the new architecture. By the end of the summer, we had the System/38 architecture defined. Twenty-five years later, the architectural concepts we envisioned that summer in 1972 are still present in every AS/400 system. Some details have changed over the years, but none of the concepts have.
I continued to work in the engineering organization, where I took on the responsibility for the internal architecture of the system. Part of my job was to define the Internal Microprogrammed Interface (IMPI) architecture used in all System/38s and in all Complex Instruction Set Computer (CISC) AS/400s. Dick and Roy went to work in Glenn’s programming organization. Roy concentrated on various operating-system functions, later joining Ray’s organization to work on the definition of functions implemented in the horizontal microcode. Dick worked on the early MI definition details as well as compiler and translator issues. Over the next five years, we three continued to meet regularly to iron out details of the architecture.
That Glenn and Ray each owned a part of the architecture definition for the system created some interesting confrontations. I remember one time Glenn called me to argue his case on some particular issue in which he and Ray disagreed; I ended up siding with Glenn. Unknown to me, that night in the parking lot Glenn accosted Ray, shouting at him that even I agreed with Glenn’s proposal. The next morning I received one of many stern lectures from Ray about my being disloyal and siding with programming.
But on another occasion, Dick, Glenn’s representative on one of our architecture committees, sided with the engineers. Glenn was furious and removed Dick as his representative on the committee. At the next meeting, however, Dick was there. “What are you doing here?” growled Glenn. “I am here as Ray’s representative,” responded Dick. Ray, hearing that Glenn had removed Dick from the committee, had appointed Dick to represent engineering.
We were growing in the engineering group, and we added people to define the architecture for other parts of the system, such as I/O. Ray Klotz hired a new manager, Keith Slack, for his architecture department. Keith also had transferred to Rochester from Boca Raton with Glenn. Keith was a good advocate for our ideas on architecture. He could go toe-to-toe with either Ray or Glenn in any argument, and occasionally he even came out on top. He did, however, complain loudly that he had a group of totally unmanageable rebels working for him. He was right; standard IBM management techniques did not work on this group. Keith remained in Rochester until after the System/38 was announced. Years later, he returned as the director for AS/400 hardware development.
No matter what kind of daily conflicts we may have had, the whole Advanced System organization worked well together, and it was a fun group in which to work. Some of that was a result of the isolation we had from the rest of the laboratory. By being totally independent of the System/3 development organization, we were free to invent a radically new system. After the announcement of the System/38 in 1978, many people wondered how two such totally different system designs could come out of the same development location. The explanation was two separate development organizations that had little contact with one another. We were even housed in separate buildings across town from each other.
The engineering organization was well established in 1973 with new processor and I/O hardware already under development. The programming area was just beginning to staff up. A big problem we had at the time was where to put all the new people we were bringing into Rochester. The System/3 development organization had grown to the point that the development laboratory buildings were just about full, and to construct a new laboratory building would take a long time.
The proposal for new laboratory buildings would first have to be sold to the IBM Real Estate Division. That group would study the proposal to determine whether such a building was really needed. They would look at the impact of a new building on the community, consider whether it would fit aesthetically with other IBM buildings, determine how to pay for it, and on and on — the bureaucracy would take years. And when the decision to build was finally made, the actual construction would take a couple more years. At best, our new buildings would be ready for occupancy in 1977 or 1978.
Rochester’s winters are harsh, so we quickly dismissed the idea of pitching some tents in the parking lot until our new buildings were ready. We did, however, consider doing something similar. IBM had a collection of portable, modular buildings that we could use until permanent buildings were erected. These modular buildings were large trailers that could be towed to a site and then bolted together to form temporary buildings — but these temporary buildings had a habit of becoming permanent (one IBM Rochester south parking lot has had “the trailers” in place for more than 20 years). We concluded that trailers would not be big enough to hold the System/38 development organization, so we needed an alternative.
Rochester has had a history of outgrowing the space available for our development organizations. Since it was founded in 1961, much of the development laboratory has been located off-site. IBM would lease a building somewhere in Rochester for use as a development facility. Eventually, a new building would be added at the main site, and the people would move back. The growth in Rochester, however, has been so great that we have almost always had off-site, leased facilities.
We ultimately found our new building for the System/38 development group across town in the former Wells Department Store. Discount department stores “took off” during the 1960s. Kmarts and Wal-Marts sprang up in many towns across middle America. Others tried to copy the success of these organizations, including a chain of stores in Minnesota called Wells Department Stores. The Rochester store, along with other stores across the state, was built in the early 1970s. The parent company of Wells overextended itself and went out of business, so the two-year-old department store in Rochester was forced to close.
The building was not desirable for a development laboratory, but it was big and it was available, so in 1974 we moved in. Originally, IBM had leased half the building as a storage warehouse. We decided to lease the other half, remodel it for offices and laboratories, and move the engineering group into it. Eventually, we would remodel the warehouse half of the building and move in the programming group. For the next four years, we would all call this home. Some of our programming groups stayed even longer.
Discount department stores then and now all seem to be built using the same pattern. Located at the back of a large parking lot, this department store was housed in a one-story, cement block building. There were no windows other than at the entrance and a few along the top front of the building. The inside of this giant warehouse had a ceiling open to the metal struts that held the roof on the building.
Because IBM was only leasing the building, the remodeling effort was a classic example of temporary design. Eight-foot-high partitions were erected as office walls. An 18-foot-high ceiling meant that the offices were open and very noisy. You could easily overhear conversations several offices away. Only the hallways and a few conference rooms were covered.
The heating and cooling system for the building was designed for a large, open, warehouse-like store. Putting up partitions totally disrupted the building’s airflow. To solve the problem, large fans were placed on top of the covered hallways to move more air. The fans were so loud that any conversations were drowned out, ensuring total privacy. If you were unfortunate enough to be too close to one of these fans, you also discovered that you couldn’t keep papers on your desk — they all blew away.
With hundreds of offices created using these partitions, the view from the top was that of a maze. Because there were no windows, it was very difficult to locate someone’s office: One hallway looked like another as we wandered from place to place. We fully expected some day to have the roof open and a giant look down on us to see how the rats were doing in their maze.
In the early days, to identify the location of an office in the building, we used the names of the department locations in the old Wells store. A performance group was in the toy department and an I/O group was in automotive. As it turned out, the architecture group was in ladies’ lingerie. But these original locations were quickly forgotten as new people, who had never been in the Wells store, moved in and IBM numbered all the offices. IBM liked to number all leased buildings and arbitrarily called the former department store building 648; but many of us affectionately called this one-story, cement block, former department store the single-level store.
The Wells building was not an ideal physical facility, but it did contribute greatly to the System/38’s success. The entire development organization was housed in this building, isolated from the rest of IBM. We were our own computer company, and we built our own computer. Most of us are convinced that never would have happened if we had been located at the main site with the System/3 developers.
Shortly after the announcement of the System/38 in 1978, it became clear to most of us that this new system would not replace the System/3 family as we had originally envisioned. The System/3 family had not stood still over the years. It had developed a loyal following who were not anxious to move to a new platform.
In 1975, IBM had introduced Glenn Henry’s GSD Entry system as a low-end System/3 for a small business office. With its desk-like packaging, many of us affectionately called it “the bionic desk.” Originally, IBM was going to call this new computer the System/3 Model 2, but then changed its name to the System/32 before the announcement. The System/34 appeared in 1977 and combined the best of both the System/3 and the System/32. By the time the first deliveries of the System/38 were made in 1980, the System/34 line was firmly entrenched. Plans also were in place to build a new technology implementation of the System/34, which would become the System/36.
Rochester would maintain these two separate development organizations until the System/36 and the System/38 groups merged to build the AS/400. This merger would have been very difficult if it weren’t for another development project in IBM called Fort Knox.
In the early 1980s, IBM management decided it had too many “midrange” systems. At the time, five separate IBM systems were competing for the same customers: System/36, System/38, Series/1, 8100 System, and the low end of the System/370. IBM decided in 1982 to converge all five systems into one. The project, called Fort Knox, was motivated not so much by a desire to produce a better system for customers as it was to reduce IBM development expenses. The fundamental idea of convergence was simple enough, but implementing the idea proved to be more of a challenge.
Not only were the five systems developed in different locations, but they also belonged to different divisions within IBM. To fix this situation, IBM decided to put all the locations and their systems into a single division. Rather than create a new division, IBM decided to put all the systems into the Systems Products Division (SPD).
IBM’s Research Division convinced SPD management that a totally new system could be built to run all the existing operating systems, plus some new ones. The new processor they proposed to accomplish this feat was called Iliad. Iliad was a version of the original 801 processor, and it was to be IBM’s first RISC processor. George Radin became the SPD Director of Architecture, and all architecture decisions were made at headquarters.
With the processor decision made, the developers in Boca Raton started a campaign to use the Series/1 I/O bus for the new Fort Knox system. The Series/1 was a very good device controller, and its I/O bus design was one of the best. With a few modifications for anticipated future growth requirements, the Series/1 I/O bus was used in the Fort Knox systems. This bus was renamed the SPD bus, and it is still used in some AS/400 models.
For Iliad’s software, each location was to port its existing operating system to run on the Iliad processor. In this way, any customer could move all its applications to the Fort Knox system. Where needed, special assist hardware could be built alongside the processor to support unique features of the existing operating systems. Meanwhile, a new native operating system for Iliad was also to be built. To get Rochester to buy into the whole convergence idea, IBM gave Rochester the responsibility to develop the new operating system.
As the various designers began to port their operating systems to the new Iliad processor, they began to identify changes to the Iliad design that were needed to support each operating system. IBM Research, which owned the Iliad design, steadfastly refused to make any changes to its processor architecture. Unable to get changes into the base processor, system designers began to add more function to the assist hardware. The special assist hardware grew and grew to accommodate the unique characteristics of the existing operating systems.
Before long, the assist hardware for each system took on a life of its own, to the point that each became a full-fledged processor. We called them co-processors, but they clearly had the ability to stand alone without the Iliad processor. Rochester developed a System/36 and a System/38 co-processor while Endicott developed a System/370 co-processor.
Finally, the Fort Knox system structure had to be redefined. Instead of multiple operating systems somehow running on the same processor, only the new native operating system would run on the Iliad processor. If one or more of the existing operating systems had to be included to run customer applications, each operating system would run on its own co-processor.
By 1985, it was clear that Fort Knox was in trouble. After spending hundreds of millions of dollars, IBM cancelled the whole fiasco. For a brief period, many at IBM thought the 9370 could be the organization’s only midrange product. When IBM announced that system in 1987, it also placed some very unrealistic expectations upon it. The 9370 was a successful product in its own right, but it was not going to single-handedly take back the midrange market IBM had lost in the preceding five years while it wasted time on Fort Knox.
That the Endicott-developed models of the 9370 systems each contained a RISC processor is somewhat ironic. The operating system and the applications ran on the System/370 co-processor, while the Iliad processor was relegated to the role of a service processor. Because the Iliad processor in those systems did not play a significant role, the fact that it was a RISC design was never advertised.
In 1982, I was offered the opportunity to manage an architecture group in Rochester working on Fort Knox. I thought the whole idea of Fort Knox was stupid, so I committed the unpardonable sin — I laughed. Of course, I was immediately banished from any work on Fort Knox. For a while, I worked for Carl Gebhardt, who became the director for strategy for the laboratory. Later, I managed an advanced technology group. As it turned out, several of the top technical leaders in Rochester criticized Fort Knox and were also banished. Many of us joined forces working in the advanced technology area.
Tony Mondello was our laboratory director during the Fort Knox period. Tony had come to Rochester to become the system manager for the System/38. His background was mainframes, but when he saw the System/38 he became not only a convert, but also one of the best spokespersons the system ever had. When he became our laboratory director, Tony kept the Fort Knox project in a separate organization, maintaining separate System/36 and System/38 organizations. He also formed the advanced technology organization that reported directly to him.
In most respects, the advanced technology organization was a sanctioned skunkworks. We even located in a different building, separate from the laboratory, so no one quite knew what we were doing. We all knew it was only a matter of time before Fort Knox blew away, and we needed a group of dedicated people to work on new technologies for our existing systems when Fort Knox failed.
We had no trouble attracting good people to this organization, including Dick Bains and Roy Hoffman from the System/38 and Dick Mustain from the System/36. We were a group of nonbelievers when it came to Fort Knox, so this was an opportunity to show what our existing systems could accomplish. As a result, we had several leading-edge technology projects underway. Many of the advanced technologies that later appeared in the AS/400 came from this group: image, neural networks, telephony, and fax technologies. Others will appear in the future.
As it became clear that Fort Knox was not going to survive, a group started another underground project in the laboratory, code named Silverlake. Participants from the System/38, System/36, and advanced technology organizations got together to design and prototype a new system. They secretly produced some new code that allowed System/36 applications to run on a System/38. Because this project was not sanctioned in the laboratory, many people came in very early in the morning or stayed very late at night to work on it. One individual who coordinated this whole effort was Peter Hansen. Pete always has had the ability to get things done quickly, whether or not they are sanctioned.
H. Mitchell Watson, president of the SPD Division during the Fort Knox era (and no relation to the founder of IBM), refused to listen to any proposal to merge the System/36 and System/38 into a new product. Late in 1985, Steve Schwartz replaced Watson. And Steve did more than listen to the proposal in December 1985; he authorized the project to proceed. The Silverlake project had begun.
In March 1986, Steve brought in Tom Furey as the new laboratory director. Tom and Steve had worked together before, and they knew they had to streamline the organization to create this new system. In the summer of 1986, Tom restructured the laboratory to get all our people working together on the project, eliminating all the separate product-focused organizations and creating one programming and one engineering organization. Our advanced technology group also was refocused to bring our new technologies to Silverlake. Shortly after this, I went to work directly for Tom as his technical assistant.
The merger of the System/36 and System/38 groups was not easy, because each group had strong emotional ties to their own architecture and their own customers. The System/36 group could not understand how a big, memory-hungry architecture such as the System/38 could ever satisfy the needs of their small customers. They pointed to the fact that the System/38 took megabytes of memory, while the System/36 required only a few hundred kilobytes of memory. With the decision to use the System/38 architecture for the new AS/400, the System/36 group argued that Rochester would not be able to build low-cost machines to attract the System/36 customer base.
The System/36 people were right. Those working on the project underestimated the hardware resources to support the System/36 Environment on the AS/400, just as they did the effort required for a System/36 customer to move to the AS/400. IBM ended up giving an extra 4 MB of memory to many customers just to make the System/36 Environment perform at a reasonable level. These early versions of the System/36 Environment gave the AS/400 a bad name among many System/36 customers, and most refused to move to the new platform as Rochester had hoped they would.
Less than a third of the more than 300,000 System/36 systems sold worldwide moved to any other platform in the first six years of the AS/400. The announcement of the Advanced 36 in October of 1994 was an admission that the AS/400 was not for every System/36 customer, even though the Advanced 36 employed the same hardware technology being designed for the AS/400. In fact, the System/36 still is a perfectly viable computer for many businesses. The new Advanced 36 preserves the operating system and applications that these customers have used since 1983.
The System/38 organization, on the other hand, looked down on the System/36. It was old and unsophisticated. In their minds, the architecture of the System/38 was the only one that could take Rochester into the future. Besides, the price of technology had come down to the point where large memory sizes were beginning to appear even in PCs. Rochester systems soon would support gigabytes of main memory, so the System/38 architecture was not too big.
We all understood that we had no choice but to work together if we had any hope of getting a new system out the door in near-record time. Fortunately, people from the two organizations were able to work together. The closer they worked, the more alike they found the systems to be. They also found that various features of the two systems complemented each other. For example, the System/36 had a better user interface, while the System/38 had a better application development environment. The System/36 used separate intelligent processors to perform I/O operations, which worked better than the System/38’s I/O channel. They were thus able to add the best features from each system to the AS/400.
The amount of effort the Rochester development community expended over those next couple of years is hard to fathom. People worked around the clock. Over one long holiday weekend, Tom ordered all doors to the laboratory locked so people would be forced to go home and recharge. Corporate personnel were very concerned about the well being of our employees working so many hours, even though our morale was extremely high. They didn’t understand this was our system we were building.
On June 24, 1988, just 26 months after we were given the green light to build the new system, we proudly announced Silverlake as the AS/400. The instant success of this system is a testament to the Rochester people who built it. Figure A.1 shows the Rochester system family and how the AS/400 evolved to the AS/400e series in 1997.
Figure A.1 Evolution of the AS/400
The development work didn’t stop with the announcement of the AS/400 in 1988. Today’s AS/400e series models have been under development since the early 1990s and are a far cry from those early systems. The beauty of the AS/400 is its ability to seamlessly incorporate new technologies, both hardware and software. The system can literally re-invent itself every couple years — evidenced by its capability to move from a traditional interactive and batch-based system to the world of client/server and network computing. When you consider that such movement has had no impact upon any current applications, the system appears to be extremely versatile. This characteristic also keeps the AS/400 perpetually youthful; it does not age, as conventional system designs do.
We continue to add new hardware and software technologies to meet our customers’ needs. We create some of those technologies in Rochester; some come from other sources. Many new technologies also come from other IBM laboratories. Most of these shared-technology efforts have been successful, although not all. Here are two examples of such projects, one successful and one not.
When I received the call in early 1991 to lead the effort in Rochester to evaluate the use of a common processor technology within the AS/400, I was a bit skeptical. I had no doubt the goal was achievable technically. The architecture was designed to accommodate new hardware, but I wasn’t sure how to sell the idea to our development organizations. Common hardware technologies, à la Fort Knox, had left a bad taste in our mouths.
I recall meeting with Keith Slack, who had returned to Rochester after the announcement of the AS/400 to become the director of hardware development. Before this meeting, he and I had talked a number of times about our earlier comebacks to IBM President Jack Kuehler when the topic of using common hardware for the AS/400 came up. But this time was different: Jack wanted us to tell him what it would take to make that happen. If we gave him an answer that was anywhere close to acceptable from a cost and time standpoint, we would be using PowerPC.
I told Keith that if I took the job, I was going to make the use of common hardware happen. Because I had defined the original IMPI architecture that we still used in the AS/400, many people in the laboratory believed I would never abandon that in favor of someone else’s architecture. But they were wrong; it was time for a change. Keith understood and supported that position. Convincing others in the engineering organization would take a bit more work.
I’ve covered much of the story behind the move to PowerPC and the people who made it happen in Chapter 2. One additional story I will relate here is a meeting I had with the engineering management team that worked for Keith. It wasn’t so much a meeting as it was a shouting match. The manager of our processor area was yelling at me, saying I was selling out the Rochester hardware designers. He also accused me of greatly overstating the performance our machines could achieve if we built a common PowerPC processor. He had a study to show that the fastest processor Rochester could build would have a 14-nanosecond cycle time, and that wouldn’t be good enough. “We’ll never build another processor in Rochester!” he shouted.
I argued that he had extremely talented people working for him and that they could build industry-leading processors if given a chance. For the record, the first Rochester processor (Muskie) had a cycle time of 6.5 nanoseconds and later versions took that time down to 5.5 nanoseconds. Leading-edge processor designs are the norm in Rochester. In the next few years, these same designers will deliver processors in the 2-nanosecond range.
Today, whenever I mention that meeting to any of our engineering managers, they just smile and nod their heads. When we believe something is the right thing to do, we make it happen. Likewise, projects we don’t believe in are not successful. An example of this was a project called Workplace.
Within IBM, a project began in 1993 to use common software components, including a microkernel, across IBM’s major operating systems. IBM announced that the three operating systems that would use the PowerPC processors (OS/2, AIX, and OS/400) would share all these technologies. The mainframe operating system (MVS) would share some technologies, but not the microkernel.
The project, called Workplace, was to provide a very efficient way for IBM to share software technologies across its operating systems. Unfortunately, much of the industry and perhaps even many parts of IBM greatly misunderstood Workplace. Some people thought this project was IBM’s attempt to converge the three operating systems into a single new operating system called Workplace OS. To them, Workplace looked like a reincarnation of Fort Knox, and they questioned why it would work now when it had failed in the past.
Others in the industry focused on the possibility of running multiple operating systems on the same hardware. They envisioned a system concurrently running OS/400, AIX, and OS/2 personalities. Many of them wondered how a customer would deal with this multiple-headed monster, and the subject of dominant personalities was a topic of many conversations.
The original intention of Workplace, however, was to allow sharing of common software technologies and components across IBM’s operating systems. A new operating system component could be written once and then would be available for use in any of the operating systems. Each operating system would continue to maintain its unique design point and would select only those components that made sense for that design point. For example, a single-user OS/2 operating system has very different requirements from multiuser operating systems, such as OS/400 and AIX. All components could not be shared, but many could; and that was the value of Workplace.
To accomplish this sharing of software technologies, IBM announced a new organization in mid-1994. The new organization became a part of the Personal Software Products (PSP) division in Austin, Texas, which was responsible for OS/2 development. Managing this new organization in Austin was Dave Schleicher, who before this had been our laboratory director after Tom Furey left. Some of our development programmers from Rochester transferred to Austin with Dave to work with other programmers from Austin and Boca Raton. Still other Rochester programmers were assigned to work in this new PSP organization under Dave, but they stayed in Rochester; this group called themselves PSP North.
The early work on the IBM microkernel was to support the 32-bit, single-user OS/2 client operating system. This original microkernel would support neither OS/400 nor AIX environments without significant enhancements. The PSP North group was given responsibility to extend the microkernel to a full 64-bit implementation, so that it could be used for something other than a client operating system.
There was absolutely no way to have a 64-bit, multiuser microkernel ready for the announcement of the RISC-based AS/400s. We had been working on SLIC for two years, and we knew that if we even tried to switch to a microkernel base at this late date we would drastically delay the project. We had already incorporated some of the same technologies used in a microkernel, such as a message-based dispatcher, so we knew we had a chance to add more later.
We intended to put the 64-bit, multiuser microkernel into the AS/400 as soon as the microkernel became available. We thought about how to do this and quickly decided the best way was to put the microkernel alongside SLIC. Rather than attempt to put one kernel on top of another, we would have two kernels linked together running on the same hardware. The PSP North group began to develop the hooks needed for the two operating-system kernels to coexist and to share many of the same functions. For example, they were able to share a single dispatching function that could dispatch work on either the SLIC or the microkernel side.
The original vision for Workplace changed significantly late in 1994 because of the project’s overall expense and IBM management’s unwillingness to fund the total project. OS/2 continued to receive funding to use the microkernel for its new PowerPC implementation, but AIX opted out because of the expense involved to move to a new microkernel base. Schleicher’s PSP organization proposed putting OS/2 alongside OS/400 on the same PowerPC hardware and doing all new application development on the OS/2 side. They called their project Harmony and believed AS/400 customers over time would migrate all applications to OS/2. When the proposed application migration was completed, OS/400 would simply go away.
Sharing some software technologies and components across operating-system platforms is a good idea, but such sharing will be successful only if there is a benefit to all platforms involved. The idea of migrating AS/400 customers to OS/2 was so ridiculous to most of us that Rochester withdrew support for Workplace, and the entire project died shortly thereafter. Besides, we already had an application engine, called the integrated PC server, to run the OS/2 applications our customers needed.
The AS/400e series announced in 1997 marked the beginning of the family of systems that will take us through to the end of the decade. During the past couple years, many people inside and outside of IBM have suggested changing the AS/400 name. After all, they argue, the new systems are nothing like the original AS/400. The PowerPC RISC processors, the emphasis on e-business, and network computing clearly show this is not your father’s AS/400. A new name would create much more interest in this “new” system.
Naming new computer systems has always been a problem for Rochester. Our code names are often memorable, but the announced product usually takes on a very boring name. Silverlake, the great code name in the early days of the AS/400’s development, never became official. Silverlake was named after a small body of water in the middle of Rochester called Silver Lake.4 We modified the name slightly to make it into a single word. In 1987, the code name changed to Olympic, but not too many people remember that name.
4Silver Lake is not really a lake. Rather, it is a wide spot in the Zumbro River created by the dam for the municipal power plant. Silver Lake’s only notable characteristic is the thousands of Canada geese that spend the winter in Rochester. The power plant heats the water in Silver Lake, so it doesn’t freeze over. This makes it possible for the geese to stay rather than fly further south. Visitors to Rochester who know Silverlake was the name used for the AS/400 often go to visit the lake. They usually come away disappointed, because Silver Lake is a most unimpressive body of water. What they don’t realize is that Olmsted County, which contains the city of Rochester, is the only county in the state of Minnesota, “the land of 10,000 lakes,” with no natural lakes. Except for a few other wide spots in the river, Silver Lake is all we have.
When we began to work on the next generation of the AS/400, we needed a new code name. This time we selected a larger body of water and chose the name Superior, after the Great Lake that borders the northeastern part of Minnesota. Many of us were sure that when we announced Superior, we would also change the AS/400 name.
A common belief in the computer industry is that the life of any computer system is about six years. Since the 1950s, with only a few exceptions, manufacturers have replaced their systems about every six years. Even those systems that did not radically change usually were renamed to give the perception of a new system. Some systems have lasted a little longer and some a little shorter, but six years is a good average. The feeling in the industry is that because technology moves so fast, a six-year-old system is no longer modern, which is probably true for technology-dependent systems.
In 1993, many computer industry pundits were predicting the demise of the AS/400. It would be six years old in 1994. Many speculated that the “AS/500” was right around the corner. It seemed logical that we should change the name — we had done so in the past.
In 1988, we could have called the AS/400 a System/38. It was, after all, a repackaged System/38 with lots of new functions. Many System/38 customers called the AS/400 a System/38 with about three releases’ worth of functionality added. We elected to rename the system for three main reasons. First, we wanted it to appeal to System/36 customers, and keeping the System/38 name would not have accomplished this goal. Second, a new name means more publicity in the news media. Another release of an existing system does not generate nearly the level of excitement in the press that a new system does. Finally, we changed the name because many in our management chain didn’t know the system was a System/38. They believed we had created a totally new system in only 26 months. The Silverlake project was a marvelous accomplishment for Rochester, but we didn’t start with a clean sheet of paper, as some people still believe. We took a System/38, repackaged the hardware, and added lots of new functions.
The odds-on favorite name for our 1988 system was Silverlake. Most of the outside world already knew this code name. Besides, it would have been a refreshing change for IBM. Since the early days of computers, IBM had insisted on using numbers to name its computer systems. The System/360 announcement in 1964 changed that naming convention slightly with the addition of the word “System” and a forward slash (/), but the approach was still fairly unimaginative. We were tired of building computers that all had the System/3X name, and we wanted a change.
Before we could select a name, IBM decided on a new naming convention. Because of a project called the System Application Architecture (SAA), many within the organization desired to have similar names across IBM products. SAA was IBM’s attempt to have common application software run on all its major systems. Similar system names would enhance this image of commonality. In a bold move, the decision was made to add a descriptive name before the word System. It was also decided to standardize on the number of digits each system could use.
IBM’s mainframe organization quickly picked the name Enterprise System/9000 (ES/9000) for its line of computers. The personal computer division selected Personal System/2 for the name of the new system it announced in April 1987. In Rochester, we debated between two names. Some of us wanted to use the name Advanced for our first name, arguing that it described the kind of systems we built. Others wanted the name Application to emphasize all the new application software that was being developed for our system. An executive finally picked the latter name. We would eventually use the other name when we introduced the Advanced Series.
We then needed to select a number. Coming from a System/36 and a System/38, we briefly considered 37 and 39, but quickly decided on 40. Our system was to be the Application System/40. But before we got too comfortable with this number, the Personal Systems organization asked for all one- and two-digit numbers. They claimed that with only one digit, they could announce only nine different systems; no one would buy a PS/0, they argued. We gave in and added another zero to our name.
Steve Schwartz was the president of our division at the time of the AS/400 announcement. He was concerned that at the announcement a reporter would ask why we chose the number 400. He didn’t want to acknowledge we added another zero to pacify the Personal Systems people. Someone discovered that by coincidence the B60, which was the top model announced in June 1988, could support 400 concurrent users. So if asked, Schwartz decided he would cite this as the reason for the name. We were working on systems that would support thousands of users, so most of us didn’t think the press would believe such a flimsy explanation. But we were wrong — they bought it.
With Superior, we had the chance to rename the AS/400. Many names were proposed. An AS/400 customer from Iceland came up with the name that I liked the best. He suggested “PowerStorm” to recognize the new PowerPC technology. Unfortunately, Digital used the name PowerStorm for a graphics processor. No matter what names were suggested, the AS/400 name did not change. Studies showed that worldwide the AS/400 name was one of the most recognized names in computers. Because brand recognition is not something easily achieved, we did not change the name.
On May 3, 1994, we kept the AS/400 name and proudly announced Superior as the AS/400 Advanced Series. This was a bigger announcement than previous ones, because this system had more features and functions than we had back in 1988 for the original AS/400. Visually, this series of computers was very distinctive in its new black packaging.
The AS/400e series was announced on August 19, 1997. Before the announcement, we again debated whether to change the AS/400 name. We wanted to emphasize the AS/400’s role as a network server with a radically new name. However, none of the proposed new names were acceptable to IBM management or customers, so the AS/400 name continued. The new series name, however, emphasizes the AS/400’s focus on e-business. Color accents on the new black boxes are also used to further distinguish the e-systems and e-servers from their predecessors.
If history is any indication, around the year 2000, we again will launch a brand new system designed to take our customers into the future. We also, no doubt, will debate whether to rename the system. Even if we don’t change the name, I hope we at least decide to totally change the color of the covers! My vote is for red.
| Table of Contents |
){kind=link}