| Table of Contents |
IBM’s AS/400 is one of the most interesting and effective commercial computer architectures ever introduced. Long before “object-oriented” had become a familiar concept, the AS/400’s high-level machine interface (introduced by the System/38, the AS/400’s predecessor), presented the application developer with a set of objects, such as queues, indexes, and database files, that could be used as application building blocks. These objects provide a great degree of system functionality in a highly consistent and easily used form. The uniform object interface hides details from the AS/400 programmer so he or she can ignore the often complex control blocks and system routines that comprise the operating system internals. Further, the operating system can limit access of objects to well-defined operations, thus providing additional runtime application protection.
AS/400 objects are implemented with a layer of software over the hardware; this layer lets IBM make substantial changes to the hardware with relatively low impact on applications. For the most part, new hardware can be introduced with only an update of the internal code IBM provides, because the object interfaces, which are used by applications, remain the same. And therein lies another benefit of AS/400 objects — they let applications take advantage of major hardware advances without the need for the programmer to modify the application code. All the implementation details of system objects used by applications are “hidden” in this layer of software.
Programmers become spoiled by the AS/400’s architecture — where else will you find such a rational approach to system function? But by nature, programmers ultimately want to know how things work, and AS/400 programmers are no exception. At every conference or user group I attend, I find a group of AS/400 programmers sharing lore about what goes on internally when you activate a program object, override a file open, or perform some other operation on a system object. This pursuit of what goes on under the covers of the AS/400 isn’t merely to satisfy intellectual curiosity; in many cases, a deeper understanding of the AS/400 architecture lets a programmer write more functional or faster code. But as any experienced programmer knows, you can’t learn everything from the manuals; and this is especially true for the AS/400, because the manuals expressly avoid details about internal structure or operations.
Consequently, despite widespread appreciation for how the AS/400 hides details under its high-level machine interface, many of us have long wanted a book such as Inside the AS/400. This book provides clear — and thorough — explanations of all the AS/400 architecture’s important components. Any AS/400 programmer will find Inside the AS/400 essential to his or her technical understanding of the AS/400.
Of course, my curiosity about the AS/400 isn’t limited just to its current technical underpinnings — and I suspect the same is true for other AS/400 developers. I’m intrigued by the technical and business processes that gave birth to such an advanced system — and I’m curious about the individuals who have been involved behind the scenes. I also have a vested interest in knowing where the AS/400 is headed for the future.
Fortunately, Frank Soltis is just the person to give the real “inside” stories for all three AS/400 areas: its technology, its history, and IBM’s future plans. Frank has been one of the central figures in these stories since the first day the System/38 was conceived, and he has played key roles in the evolution of the AS/400 architecture. His experience has spanned several major eras in IBM organization and technology, and his responsibilities have included hardware, software, and business domains. Frank also combines an academic career teaching computer science with his responsibilities as an engineer and system architect. Leaven all this talent and experience with a bit of Minnesotan humor, and you have the perfect guy to make topics like “tagged memory” and “task dispatching queues” an interesting read.
With the explosion of the Internet, Web sites, the Java programming language, and distributed computing, it’s even more exciting to learn what’s in store for the AS/400 as a “best-of-breed” server. In this Second Edition, Frank explains how the AS/400’s new RISC architecture and major enhancements to OS/400 and the System Licensed Internal Code (SLIC) put the AS/400 in a great position to offer additional capabilities, as well as improved price/performance, across the entire range of systems — from entry level to powerful clusters handling millions of transactions per hour. I know of no one else who could lay out the evolving architectural road map for the AS/400 as well as Frank.
When I first met Frank in 1985, he didn’t strike me as the traditional IBMer — but then again, I’d just been introduced to the System/38 after years working with IBM mainframes, and the System/38 itself seemed refreshingly different, too. Frank spent hours filling me in on technical details of the System/38 architecture, as well as much of the personal side of System/38 history. Frank explained technical concepts so clearly — and was such an entertaining story teller as well — that I encouraged him to write a book about the System/38. Only later did I learn that, as far as IBM headquarters was concerned, the future of the System/38 was up in the air at that time. Understandably, Frank waited to tell the story until he was assured it would have a happy ending. With the great success the AS/400 has experienced, and with its ever-widening use and key strategic role for IBM, there’s no better time for Frank to share his insight and stories with us all. This is truly the best guided tour of the AS/400 around.
Paul Conte
President, Picante Software, Inc.
We in the computer industry often point with great pride to how much we’ve accomplished over a relatively short span of years. At times, we even boast about how we deliver new technologies faster than any other industry. While we do develop and deliver new hardware and software at an astonishingly fast pace, we often are simply recycling some very old ideas.
As Harry S. Truman, a former president of the United States, once said, “There is nothing new in the world except the history you do not know.” To fully understand any computer system, you need to understand its history and the background and experiences of the people who created it. This is especially true for a system such as the AS/400, which doesn’t seem to fit the traditional computer mold.
The development location and the previous products from that location heavily influence the design of a particular computer system. If a development group has had success with a particular product, it will re-invent it during the next development cycle. Rather than build a new system, the group generally builds a better model of a current system. This is why radical new ideas usually come from outside that group.
Consider the designs computer companies located on the East Coast of the United States have created over the years. They obtained many of their ideas from research done at universities such as Massachusetts Institute of Technology (MIT). During the 1960s, MIT engineers and computer scientists worked on a Department of Defense project called MULTICS. IBM and other computer companies hired graduates from these universities to design their new operating systems. The designers’ common experiences led them to build systems that were very similar. IBM’s MVS mainframe operating system, Digital Equipment Corporation’s VMS operating system, and all the Unix operating systems have common roots in the various eastern universities.
Even a fairly new operating system, Microsoft’s Windows NT, is deeply rooted in this same past. The design team who created Windows NT previously worked on Digital’s VMS operating system. Because they knew it well, these former Digital employees borrowed heavily from VMS when they designed Windows NT. It is no coincidence that when you add one letter in the alphabet to VMS, you get WNT.
The AS/400’s history is very different. A little more than a year ago, I was in Buenos Aires, Argentina, speaking to an AS/400 user group. After the session, a young reporter from La Nacion, the daily newspaper, stopped by to interview me. His first question was, “In one sentence, tell me why the AS/400 is such an innovative system.” Not wanting to make my answer too long, I simply responded, “Because none of us involved graduated from MIT.”
The reporter, intrigued with my answer, asked me to elaborate. I explained that my intent was not to demean MIT. Rather, I wanted to convey that the original AS/400 developers, who had graduated primarily from Midwestern universities, had very different experiences to draw upon compared to someone who had graduated from a school such as MIT. And because it has always been difficult to get anyone to move from the East Coast to a small community of 70,000 people in southeastern Minnesota, Rochester hired almost no graduates from the East Coast schools. As a result, the creators of the AS/400 (whose design also dates back to the 1960s) did not have strong ties to the same computer designs that other companies used.
The following sections of this preface provide a brief historical overview of the events leading up to today’s AS/400e series, along with my observations about the leaders who brought this remarkable system to the world and worked to make it successful. If you want a more complete history of the AS/400, you can find it in the Appendix — even information about where most of the design originated.
In the 1850s, a group of New England farmers settled in Rochester, Minnesota. Rochester probably still would be a sleepy little farming town if a tornado hadn’t swept through in 1883, injuring and killing many residents. A physician, William Worall Mayo, was visiting a friend in the area at the time and treated the injured. He stayed on and was joined by his two sons, William in 1883, and Charles in 1888. Their decision in 1889 to establish a private group medical practice, which they called the Mayo Clinic, transformed Rochester into the international medical center it is today. With one physician for every 70 people, its clean environment, exceptional school system, and low crime rate, Rochester rates year after year as one of the top two or three places in the country to make a home, according to Money magazine.
Rochester is also home to the AS/400. In 1956 IBM announced it would establish a major new facility in Rochester. Until that time, IBM was a New York-based company with several manufacturing and development sites in various cities throughout the state. Thomas J. Watson, Sr., IBM’s founder, lived most of his life in New York and preferred to build new sites there. The decision to establish sites outside the state indicated IBM’s desire to change its image as a regional company.
I first saw Rochester in 1962, just one year after the development laboratory opened. I was still a university student and IBM offered me a summer job in Rochester. At the time, I had no interest in computers and even less interest in living in a small prairie town in southern Minnesota. The lure of the aerospace industry in California tempted me. However, I knew the project manager in Rochester who headed a joint medical project with the Mayo Clinic and thought it might be fun to work for him during the summer.
I arrived to find another summer hire had already taken the medical development job. I would be working on the development of a banking terminal. I was very disappointed but accepted the job for the same reason countless other people accept jobs they don’t want: I needed the money.
The manager of the bank terminal project must have heard I was unhappy about not getting the medical job. He spent a great deal of time with me that summer talking about the role computers would play in Rochester’s future. He managed to convince me that engineers who had intimate knowledge of computer hardware and software design would lead Rochester into the computer era. I returned to school at the end of the summer with a new interest in digital computer system design.
After graduation the following year, I returned to Rochester to work for the same project manager. During the next couple of years, I worked on a variety of projects as Rochester began to move into the computer business. Before long, I was encouraged to return to school to study computer architecture (I was one of a number of engineers with little experience in operating-system software). At Iowa State University, I studied computer architecture and operating-system design.
I returned to Rochester late in 1968 with a doctorate degree and some very definite ideas about how to design a new computer system. I arrived in time for the announcement of Rochester’s first computer in June 1969, the IBM System/3. The System/3 was a special-purpose product that looked more like an accounting machine than a computer. I didn’t realize it at the time, but the group at Rochester had managed to get into the computer business by telling IBM it was building an accounting machine. That didn’t seem to matter much, because the System/3 went on to be the first in a line of successful products that would change commercial computing forever. During 1969, I worked on an advanced computer design that incorporated many of the ideas I had studied at the university. I honed many of my ideas for a new computer design during that year. In late 1969, I was given a new job assignment — to design the architecture for the successor to the System/3.
On a bitterly cold Thursday, January 8, 1970,1 I presented a proposal to Rochester management for a revolutionary new computer architecture. A high-level machine interface was a fundamental part of that proposal. The addressing structure, called single-level store, had evolved during the preceding year from my Ph.D. dissertation work. The driving motivation behind the architecture was to protect the customer’s investment in application software by delivering a computer system that was independent of the underlying hardware technologies. This system was very different from a System/3, but it did contain most of the System/3 functions. This capability to have a “System/3 environment” would prove to be valuable years later when we needed to merge the two product lines.
1A wonderful trivia question is to ask, “Who are two famous celebrities born on January 8th?”. The answer is Elvis and the AS/400. Elvis Presley was born in Tupelo, Mississippi, on January 8, 1935, and the AS/400 was born in Rochester, Minnesota, on January 8, 1970.
Though many ideas behind the new architecture were truly radical, Rochester’s management was willing to accept the proposal and to form a special group in the development laboratory to pursue the new system. Within six months, an organization of nine people formed to make the proposal a reality. My role was to be the architect for this new system. Little did I realize then that I would continue in this role for more than a quarter of a century.
The Advanced Systems organization formed to create the new system stayed separate from the System/3 development effort (the System/3 family continued to grow with the addition of the System/32 in 1975 and the System/34 in 1977). Staffing for the new system did not start in earnest until the middle of the 1970s. Soon, hundreds and then thousands of people throughout IBM joined the team. On October 24, 1978, we announced the new system. We called it the System/38.
The System/38 was immediately heralded as an advanced-architecture computer. It was easily the most innovative design IBM had announced in many years. Few people either inside or outside IBM fully understood this new system. A cult-like following quickly formed among those customers who did understand its power and potential. User-group meetings often took on the appearance of a religious rally.
The System/38, however, never did replace the System/3 family in the way we originally envisioned. It was a new system that did not attract many of our installed customers. The first shipments of the System/38 were delayed until July of 1980 because we said it had performance problems. Actually, the system wouldn’t run for any extended period of time before crashing — the ultimate performance problem. This delay scared off some of our existing customers. Also, customers of the smaller System/32 and System/34 found the new system to be too large and too expensive. In May of 1983, the last variant of the System/3, the System/36, was announced to satisfy these customers’ needs. Rochester would continue to have two distinct lines of computers.
In the early 1980s, IBM decided to create a new converged system it called Fort Knox. The intent was to replace five incompatible IBM product lines, including the two from Rochester, with Fort Knox. Customers who owned any of the five machines would be able to move their applications to this single system. The development of Fort Knox started with major investments in four different IBM laboratories.
By 1985, it was clear that Fort Knox was in trouble. Many of us in Rochester believed it was doomed from the beginning because it was trying to solve an IBM problem rather than a customer problem. Others in IBM saw it as technically too big an undertaking: There was no way to converge five separate systems into one. Still others thought it was impossible to manage the project across the four laboratories. For all these reasons, Fort Knox failed; and IBM terminated the project.
Fort Knox had siphoned off most of the development resources that would otherwise have been put into the System/36 and the System/38, making it difficult for either system to remain competitive. Further, IBM had gone so far as to declare the System/38 “nonstrategic” and had discouraged customers from buying this system.
Late in 1985, a small group of developers in Rochester demonstrated that software for the System/36 could run as an environment on the System/38. The cost of hardware technologies had come down so that we now could build small models of the System/38, which meant we could cover the entire Rochester product range. The proposal to combine the two systems into a single machine based on the System/38 quickly followed. We named this new machine Silverlake and convinced IBM management we could build it.
Once again, it was Rochester’s turn to show IBM and the whole computer world what we could do. After an unprecedented 28-month development cycle, we were ready to announce the converged system. We told the world it was a new system and called it the AS/400. Insiders, however, know that under the covers of every AS/400 lurks a System/38.2
2We even changed the name of our operating system for the AS/400 to Operating System/400 (OS/400). To this day, many of our developers still call it XPF. XPF stands for Extended CPF. Control Program Facility (CPF) was the name of the System/38 operating system.
The AS/400 was an immediate success. Not only did it take back the market share lost to competitors in earlier years, but it also quickly surpassed all of them. Soon, more than 500,000 systems will have been shipped to businesses all over the world, making the AS/400 the best-selling multiuser computer system ever. The System/38 cult had become a full-fledged religion.
In 1991, Apple Computer, Motorola, and IBM reached an historic agreement to develop a new family of processors. These processors would use a Reduced Instruction Set Computer (RISC) design and would be used in everything from hand-held devices to supercomputers. Called PowerPC, these new processors were poised to take the computer world by storm. At the time, Rochester was looking at a new processor design for the next generation of AS/400 systems. This was to be the first totally new design since the 1978 processor used in the original System/38. Why not join forces with the PowerPC alliance to create the new AS/400 processor based on this design?
I led a team of people from Rochester to identify the requirements for the AS/400 processor. We then worked with the PowerPC architects and designers to create a 64-bit processor based on the PowerPC architecture. Processors built to this new architecture should take the AS/400 well into the next century.
The introduction of these new PowerPC processors marks a milestone in the AS/400’s history and demonstrates the power of the AS/400 architecture. With mixed emotions, other computer-system vendors are beginning to move their systems to new 64-bit processor designs. Those making the transition are causing major disruptions to their existing customers. Application software must be recompiled or rewritten. Operating systems also must be rewritten to take advantage of their new processors. As a result, it will be years before their customers are able to fully use the latest processor technologies. In contrast, the AS/400 architecture’s hardware-independent nature makes incorporating the new processor technologies relatively easy for an existing customer. Existing AS/400 applications can take advantage of 64-bit speed and capacity without the need for lengthy rewrites or recompiles, a claim no other company can make.
A question often asked is “How did the AS/400 come about, and who were the people responsible for this system?” I will cover more of the AS/400 history and identify some of those people who were involved as we go through this book. There are, however, a few key technical and management leaders without whom this system would never have been created.
IBM likes to promote the development of any new product as a team effort with everyone contributing. In truth, a small handful of technical and management leaders with the foresight, creativity, and drive usually make a product successful. Such leaders are responsible for the development and success of both the System/38 and the AS/400.
Rochester has had many good technical and management leaders but only a few true visionaries. A visionary leader not only has a vision of what is possible but also has the ability to convey that vision to others. A visionary leader is able to give away the ownership of that vision to everyone involved. Soon the vision takes on a life of its own as it grows and takes shape. The leader’s role becomes one of a cheerleader, encouraging everyone to excel with his or her part of the vision.
In 1972, I was still struggling to sell the radical concepts of the System/38 architecture to our developers. The engineering organization was making progress on the hardware design primarily because most of the group thought they were just building System/370 hardware with some new software on top. The format of the internal instructions in the System/38 looked very much like that used in a System/370. This was no coincidence. It was the only way to get the engineers on board and comfortable that they were not doing anything unusual.3
3In later years, people would come to Rochester, see this instruction format, and declare the System/38 was built on a System/370. IBM even funded projects to make the System/38 software run as an operating system on System/370 hardware. These projects all failed.
Little progress was evident on the software front. Most of our programmers in Rochester were busy building better versions of the System/3 software. They were comfortable with the System/3 design and wanted no part of a revolutionary new architecture.
It was during this time that two individuals stepped forward to help create the total architecture and convince the entire development community that we were on the right track. Dick Bains and Roy Hoffman are two of the most creative, truly visionary people I have ever met. They were also true believers. During 1972, the three of us completed the definition of the AS/400 architecture, and though some of the details changed in the following years, none of the concepts have.
Dick’s talents were in compiler technology and languages. His expertise was critical to the definition of the high-level machine interface and the internal translator. He had grown up in the neighboring state of Wisconsin. Before joining IBM in Rochester, Dick held several different jobs. At one point he was a ski instructor in Aspen, Colorado. Whenever things were not going well with our architecture definition, Dick would long for the simpler life of a ski instructor. Thankfully, he never followed through on those longings.
Dick was always someone who could get so involved in solving a problem he would do something without necessarily thinking about the consequences. For example, a year earlier, Dick tried to convince management that some of the site’s computer systems had a security problem. When no one would listen to him, he decided to demonstrate the problem. He went into a system to which he was not authorized and left a message for those responsible for the system to call him if they wanted to close the security exposure. In the process, he managed to unintentionally overwrite some files and almost lost his job. Fortunately for all of us, management recognized his talents and he kept his job. He also made his point.
To this day, Dick has these same qualities. When he sees something that needs to be done, he doesn’t stand on formalities; he just does it. His breadth of knowledge on the AS/400 and his ability to work closely with customers and business partners to solve both technical and business problems keep him in high demand. Dick remains one of the key technical leaders on the AS/400.
Roy at that time was an engineer with expertise in computer architectures and operating-system designs. His contributions, especially in the low-level operating system functions, made the System/38 architecture a success. Roy had grown up on a farm just outside of Rochester. Like many young men, he had chosen to leave home to attend college and find a job. He had worked for another computer company for a while; but after finishing his Ph.D., he had returned to Rochester to work for IBM. On weekends, Roy could be found riding through the countryside on his motorcycle. We would have long discussions about the merits of motorcycles versus sports cars, my hobby (I have always preferred to have a roof or a roll bar over my head).
Roy has always been very good at solving technical problems. He has a tremendous knowledge of computer systems and can attack a technical problem from a vantage point most of us do not have. His new view often has led to the technical solution; helping others with technical advice has always been one of his real strengths. (In fact, Roy didn’t stop at technical advice. He often gave those of us around him whimsical personal advice as well, whether we wanted it or not. I still laugh at the great delight he would take in analyzing and giving me outrageous advice on child rearing and other subjects for which he had little or no experience.)
After his work on the System/38, Roy led some of the advanced technology work in Rochester. He also worked on new technologies for all of IBM. Roy was a member of the IBM Academy that was responsible for helping set technical directions in IBM. In 1994, he retired from IBM. Roy has just finished writing a technical book about data compression. On a nice day, you will still find him out riding his Harley-Davidson.
Somehow, the combination of a ski instructor, a motorcycle enthusiast, and a car nut worked. By the end of 1972, the design of the architecture was whole. In the following years, Dick, Roy, and I would often get together to discuss changes and new ideas. To this day I am amazed that others are just now discovering many of the ideas we collectively put into the system.
Rochester has been blessed with good technical leaders. The many innovations in both hardware and software are testimony to these people. None of the others, however, has had the same vision and foresight for the system as did Dick and Roy. They clearly saw the future. Like so many technical leaders who usually work behind the scenes and are seldom visible outside of their own organizations, these two have never received the recognition they deserve.
No system can be successful with only technical leadership; management leadership is also critical. In my opinion, five management leaders had the vision to make the System/38 and the AS/400 into successful products. One of them, above all others, needs to be recognized: Harry Tashjian saw the need for a small, easy-to-use business system and created a new market for computers. Without his vision, there would be no Rochester-developed computers.
Harry was the management force behind the System/3, System/32, System/34, System/36, and System/38. He was originally the system manager for all of these products and later became the director of the Rochester laboratory. It was Harry’s vision that transformed Rochester from an obscure, insignificant little facility in the middle of a Minnesota cornfield into a world leader in the development of business computer systems.
It was also Harry Tashjian, manager of the bank-terminal project, who convinced me to pursue computers that first summer many years ago. I still remember our long talks about Rochester’s potential for developing new computer systems. Harry encouraged me to return to school to study computer architecture. When I returned to Rochester, he gave me the assignment and the support to design the architecture of the System/38, which would become the AS/400. Without Harry, there would be no AS/400.
In addition to Harry Tashjian, two other management leaders made the System/38 a success. Ray Klotz was our engineering manager and my boss for most of the project. In 1970, Harry put Ray in charge of the initial development team of nine people. Ray had a strong hardware background, having led a System/360 processor development in Endicott, New York, before coming to Rochester to lead the System/3 hardware effort.
Ray’s initial vision for the System/38 was less ambitious than what some of us had in mind. He would sometimes remind us that the entire System/3 hardware required only 3,000 circuits, and he would ask why we needed so many more. He liked to challenge us on our technical decisions until he was convinced we had looked at all the options. Then he gave us the freedom to take ownership of the design and let us make our own decisions. Whenever we got into trouble, he was always there to support us and help us find the way out.
Ray was very much a father figure for most of us. We all jumped whenever he raised his voice, which he did often. But under his gruff exterior was a tremendously caring individual who demanded perfection from each of us, and he usually got it.
Gaylord Glenn Henry was the most brilliant, and totally outrageous, manager I have ever known in IBM. To say that Glenn did not fit the model of a typical, conservative IBM manager is an understatement. The scruffy beard, the often mismatched clothing, and the six-packs of Tab in the pink cans he carried everywhere identified him as a unique individual. Glenn came from the IBM laboratory in Boca Raton, Florida, in 1972 to be the programming manager for the System/32 and then the System/38. He was an intense individual with tremendous personal drive that inspired everyone around him.
Glenn was a con artist who could convince developers and managers alike to follow him. When seemingly insurmountable problems arose, Glenn convinced all of us that he had everything under control. Soon, a solution to the problem would appear and Glenn would just smile. Without his talent and vision, the System/38 development likely would have been terminated on numerous occasions.
I miss the shouting matches between Glenn and Ray. When they disagreed, the walls would shake. It was fun to watch the two argue, especially when you knew neither could support the position he was arguing (on occasion, Harry would join in, but more often he would let them settle their own disagreements). They did, however, both agree on one thing: We were going to build the best computer system the world had ever seen. The System/38 was a tribute to these two strong-willed individuals.
After the System/38 was announced, we lost all three of these leaders. Harry Tashjian left Rochester to lead a new start-up company for IBM called Discovision. After Discovision, he directed other activities within IBM before retiring with 38 years of service. Glenn transferred to Austin, Texas, to take over the development effort for the PC-RT. He left IBM in 1988 after 21 years, disgusted with the organization’s inability to integrate new ideas. He would go on to work for other computer companies before starting Centaur Technology, Inc., in 1995 to develop high-performance, low-cost, Pentium-class microprocessors. Glenn’s leaving was a major loss for IBM. Ray saw the System/38 announced, but died before seeing the full impact his system would have on the entire computer industry. No one has ever been able to take his place.
Without a visionary leader, Rochester’s computer systems faltered in the early 1980s. We did, however, have some strong managers who understood the value of the systems we built. Through often devious means, these individuals managed to keep our systems alive. Still, it seemed we did not have much of a future as we continued to lose business to competitors. Fortunately, someone stepped in at the eleventh hour to pull us out from near oblivion. His name was Tom Furey.
Tom has always been a master salesman. He knew how IBM worked internally and managed to convince the corporation that Rochester systems were strategic to IBM’s future. He then set about to convince all of us to put in the extraordinary effort required to get a new system out the door in record time.
Tom also understood marketing and customer requirements. He transformed Rochester from a product-driven to a market-driven organization. He first got our customers directly involved with development. Customer councils had a big say in making system trade-off decisions, and the result was a system for which many customers felt personal ownership. Rochester would later win the prestigious Malcolm Baldrige National Quality Award for this market-driven effort.
True leadership is often only recognized in hindsight. Tom was not a technical leader as some of his predecessors had been, and many in the laboratory didn’t recognize the leadership he provided. Our technical people didn’t think he fully understood what they were doing. He didn’t, but it also didn’t matter. For example, Tom never understood that the AS/400 was a repackaged System/38; or if he did, he never let on. He told everyone outside of Rochester it was a totally new system from the ground up, and they believed him.
The early commercial success of the AS/400 is clearly due to Tom’s leadership. He orchestrated the biggest product launch IBM had seen since the System/360. This launch propelled the AS/400 to the front of the multiuser commercial market. After Rochester, Tom moved to Santa Teresa, California, to be the general manager for the development of IBM’s DB/2 database. Later, he became the general manager for client/server computing in IBM. Today, Tom heads IBM’s technology efforts for the Olympic Games.
After Tom left for his new job in California, the laboratory lost a good share of its marketing focus. Even as we were accepting the Malcolm Baldrige National Quality Award for being market-driven, the new laboratory management was moving us back to being a product-driven organization. Customer councils disappeared, as did much of the direct customer involvement that Tom had established. Our new management came out of the ranks of the development community and did not feel comfortable having customers share decisions about future products.
The one shining exception to the laboratory’s move away from customers was our Partners in Development (PID) program. This dedicated group of men and women, originally under Jim Kelly’s leadership, focused an enormous amount of energy to support the worldwide community of AS/400 business partners who develop and sell much of the application software that our customers use in their businesses. These people deserve all the credit for our success in this area.
Thankfully, because of one man, Bill Zeitler, the AS/400 Division did not lose its market-driven focus. Bill was our Assistant General Manager in charge of marketing for the division from about the time of the original announcement until late in 1995, when he left for a 15-month assignment in Asia. During these years until Bill left temporarily, our division had five general managers (IBM in the late 1980s dropped the title of division president and began to use the title general manager). Each of these general managers had something to contribute to the success of the AS/400 division, but it was Bill who had a steady hand on the tiller and steered the AS/400 ship through some rough waters.
For example, in 1993 when the AS/400’s image among the press and consultants was at its lowest point, and many in these communities were predicting the system’s demise, Bill charged ahead to educate them. On more than one occasion, I donned my bulletproof vest and joined Bill on an expedition into some particularly unfriendly consulting company. When these firms began to understand the potential of the AS/400 and where we were taking the product, most of them became supporters rather than detractors.
The overall marketing success of the AS/400 was due mainly to the efforts of Bill and his team of people. Without them, the product would not enjoy its current position in the marketplace. Fortunately, after his assignment in Asia, Bill rejoined the AS/400 Division as our general manager to launch the AS/400e series.
IBM has not provided an in-depth look at the design, architecture, and history of the AS/400. Neither has it explained how this remarkable system can do the things it does. My goal in writing this book is to demystify the AS/400 and perhaps shed some light on how this system came to be.
As you might already have sensed, I feel a strong responsibility to include in this book some historical information. A few years back, I informally inherited the position as Rochester’s resident historian from its originator, Carl Gebhardt. Carl was our business manager for the early systems and later became the system manager for both the System/34 and the System/38 when Harry Tashjian was the laboratory director. Carl was responsible for the financial success of Rochester’s early systems. I worked for Carl in the early 1980s when he was our director of strategy. Carl was a Rochester landmark, having been here for many years. If you ever had a question about something that had happened in Rochester several years earlier, chances are Carl knew the answer. He would often introduce himself as Rochester’s resident historian (there was no official resident historian, but both of us thought there should be). When Carl retired, we discussed who should take over this unofficial position, and he passed the title on to me.
This book is written for those who want to know more about the AS/400. It is not a specification written for operating-system designers who need far more detail than that documented in these pages. Neither is it a rehash of IBM product-announcement material. It is written for customers, application developers, and students who want to understand how the AS/400 works so they can make business decisions, write better applications, or simply see what makes this system tick. Is it magic, or just good design? Perhaps it’s a little of both.
I need to point out that the views expressed in this book are my own. I am unashamedly an AS/400 bigot. My views are not necessarily the official views of the IBM Corporation. I hope you enjoy reading this book about the AS/400 as much as I enjoyed creating it.
When we announced the Advanced Series in 1994, we also announced the first release of a new operating system version we called Version 3 Release 1 (V3R1). We stated that we intended to move our processors from a non-RISC to a RISC design, but that we would keep the system software for the two designs functionally equivalent to ease the transition to RISC. With the first RISC models in 1995, we announced V3R6, which was intended to maintain functional compatibility with the V3R1 non-RISC software release. In 1996, we announced enhancements to both of these software releases with V3R2 and V3R7. We can, therefore, consider Version 3 a transitional operating system while many customers moved to the new RISC models.
The introduction of the AS/400e series in 1997, along with the Version 4 (V4) software, marks the end of the transition period to RISC. Releases within this new version (V4R1, V4R2, V4R3, and so on) will run only on RISC models of the AS/400. Specifically, V4 software runs on some models of the Advanced Series (the RISC models) and on all models of the e-series.
While the external interfaces for the RISC and non-RISC systems are fairly similar, the same is not true for all the internals. Some internal components are the same; others are vastly different. In a book like this that describes the internals of the AS/400, we cannot cover both designs completely; that would require two separate books. But instead of just concentrating on the RISC systems’ internals, I have decided, where appropriate, to also describe some of the design for the non-RISC systems. I made this decision for two reasons:
In all cases, I attempt to distinguish when I am discussing RISC designs and when I am discussing non-RISC designs.
The remaining content of the book is as follows:
Throughout the discussion of each component and its interaction with other components, I include explanations of how these components are designed to enhance the application environment. After all, applications are still what the AS/400 is all about, and many of the newest applications are beginning to leverage the world of e-business.
With the announcement of Version 4 software and the AS/400e series hardware, we are delivering on our vision to extend the integrated value of the AS/400 to e-business. We define e-business as a secure, flexible, and integrated approach to delivering business solutions by combining the systems and processes that run core business operations with the simplicity and reach made possible by Internet technologies and the Worldwide Web.
In the beginning, Web serving in businesses has mostly taken the form of Web publishing, e-mail, and employee access to information. Almost any computer system can be used for this form of Web serving. However, as businesses move to true e-business, where they begin to connect their mission-critical applications to the Web, demands on system robustness and integrity become much more important. For years, the AS/400 has been providing a robust, reliable, available, highly secure system for traditional and client/server mission-critical applications. Now we are bringing those strengths to the new world of e-business.
An explanation of how to read this book may seem strange, but there is good reason. The intended audience is reasonably broad, ranging from business executives who want to know how an AS/400e system or server can benefit their business to “bit-head techies” who want to understand minute design details. I wrestled with how to satisfy such diverse interests. I considered splitting the book into two parts, one part giving an executive overview and the other part offering the technical details. But that organization is difficult for someone who needs business benefits and first-level technical details. I also considered putting a road map into the book, recommending which sections should be read by executives, application developers, students, or bit-heads, respectively. I decided against this approach because the classifications are so arbitrary; and whenever I read a book with a road map, I have difficulty keeping track of the sections I should read and those I should skip.
One day while I was discussing my dilemma with Malcolm Haines1 from London, he came up with a solution. Malcolm, who is one of the most creative people in IBM, suggested I mark the more difficult sections and let the reader decide whether to read them. He further suggested using chili peppers to denote the degree of difficulty of a particular section. This idea came from the fact that a few years ago Malcolm introduced me to Chutney Mary, an Anglo-Indian restaurant in London. This fine restaurant uses small drawings of red chili peppers in its menu to show which dishes are hot — the more peppers, the hotter the seasoning. So, he reasoned, why not use the same approach to identify the “hotter” technical sections in this book?
1Malcolm Haines is frequently referred to as the AS/400’s “propaganda minister,” whose duties include promoting IBM via videos and CDs. Malcolm’s CD, The Case for AS/400, is a great example of his classic humor.
My chili pepper rating system is as follows:
No chili peppers means the section is relatively mild when it comes to technical content; there will be some, but everyone needs a little spice.
| One chili pepper means there is a little more technical detail. It is usually okay for most readers, but if it gets too hot, skip to a milder section. |
| Two chili peppers means the material is definitely beginning to pick up the technical content. You may want to try just a taste. |
| Bit-heads are beginning to smile, and sweat may break out on their foreheads when three chili peppers appear. The rest of us may find smoke coming out our ears if we concentrate too hard in these sections. Depending on your tastes, you may want to skip those sections altogether. |
Happy dining.
| Table of Contents |