Goodbye, AS/400, Old Friend
April 7, 2008 Brian Kelly
|
The AS/400 is dead. Long live the AS/400. This phrase as associated with my favorite “midrange system” has changed over the years to meet the many successor systems that IBM has put forth to replace our good ole AS/400. In fact, even before the litany of replacement systems, the AS/400 itself was involved in a replacement act of its own when it was brought forth to succeed both the System/38 and the System/36. As we in this “AS/400 community” well know, nothing was and nothing will ever be as revolutionary to the world of computing as the System/38 in its day, even if we choose to call it an AS/400 or something else. The System i, also known as our beloved AS/400, today is nothing more than an operating system. IBM would like us to see the new physical incarnation of the AS/400 in its new IBM Power System line. But, it isn’t there. The System p has been able to run the i5/OS operating system for quite some time. It still can, but now with no holds barred. There is no new System i. IBM this week chose to remove the identity of the AS/400. It no longer exists under any name. Get used to it. Our old friend is gone. Besides AIX and Linux, these new Power 520, 550, and 570 servers also run a proprietary operating system known as IBM i. This fact enables it to run your workloads, almost as if your workloads are being re-hosted on a non-AS/400. Well, at least emotionally. All of this is unsettling for me and for those of us who think a combination of box and identity removal is not the best way to highlight our favorite machine. Overall, it is a good time for IBM since its 25-year homogenization goal is all but accomplished. While I continue to digest the implications of last week’s news, I thought I would sit down and put together a little piece of documentation about the good friend I remember so well. Goodbye, AS/400, old friend. Now, don’t say anything or I’ll get emotional. The Place Where Great Ideas Once Were Permitted to Grow The IBM Plant in Rochester, Minnesota, first opened its doors in 1956 and shipped its first product, the IBM 077 numeric collator. By 1957, the plant began pounding out other mechanical units, such as the IBM 514 reproducing punch and the IBM 523 gang summary punch. You see, in the 1950s, there were no Rochester Labs creating the most sophisticated operating system software in the world. There was the beginnings of a plant complex that was designed to build these huge electromechanical units, each of which existed on a diet of lots more than 100 boxes of 80-column punch cards every day. Even before 1960, this plant from nowhere established its own engineering department and soon IBM announced that Rochester was designing and developing its own products. In 1957, the first two Rochester-designed and developed units, the IBM 085 and 087 collators, were shipped from a plant less than a year old. These units were famous for such innovative concepts as match, merge, and the infamous match/merge. IBM in Rochester was well on its way to fulfill its legacy.
From the early part of the 20th century, IBM customers were using expensive tabulating machines, sorters, reproducers, interpreters, and accounting machines in much the same way that the early computers of the 1950s were used. In the mid-1960s, computers such as the IBM 1401 and the then-new System/360 were making major inroads in larger companies across the world. Because IBM believed there was still life in the notion of a “tabulating system,” the company gave Rochester the mission of building a smaller version of these punched card processing units with some even less expensive report writing capabilities. The exciting part was that Rochester was to do this from scratch. The objective was to provide a simple solution for the small business marketplace. IBM’s major computer facilities were located in Endicott and Poughkeepsie, two cities in New York, so this new, yet to be designed, small business-oriented miniature mechanical marvel was to be all done in Rochester. Considering that Rochester was blessed with the electrical and mechanical engineering know-how that could make the project a success, it was a natural fit. Please note that this to-be-designed unit was not supposed to be a computer system, since IBM already had these two well-oiled plants that handled this mission for the corporation. In the mid-1960s, in addition to the mechanical engineering teams, there were also computer scientists and computer engineers on staff in Rochester, since the engineering lab and the plant also built the card readers (1622 and 2501) and card punches (1442) for the IBM 1401 and IBM 1620, as well as the unit record gear for the System/360. Overall, Rochester made over 70 products at this time, each with major electromechanical components. There were always moving parts. With this mixed bag of mechanical and electronic experts, Rochester, as prescribed by Mother IBM, created the specifications for the smaller and less expensive next generation unit record system. Rather than make the machine family all electromechanical, which would necessitate lots of mechanical parts, largeness, heaviness, bulky wiring panels, and cost, the engineers decided to build their “electromechanical” system using fewer moving parts by adopting the computer technologies of the day. Rather than use wiring boards to trigger actual relays, for example, as in the mechanical unit-record machines, the new unit-record punch card system would use small “computer” programs. To enable work to be accomplished, the “system” would be shipped with a means of translating source instructions in punched cards into programs. These programs would emulate the functions of the wiring boards of the past.
The translating device of course would be software–a card-based compiler, very similar to that designed for the System/360 Model 20. This compiler language was not a new idea and had been, in fact, developed to provide accounting machine functions on IBM’s 1400 series computer systems. It produced programs with a fixed logic cycle that emulated the functions of IBM’s best unit-record accounting machines (402, 403, 407, etc.). The IBM 1401 compiler was named RPG, short for Report Program Generator, since that was its function–to produce reports. When introduced for the new announcement in July 1969 (shortly after I joined IBM as a Systems Engineer), this compiler had been substantially enhanced and its new name was RPG II. The chicanery of the Rochester team began with their full awareness that their mission was not to build a computer. They knew well that this mission rested elsewhere in IBM. So, no matter what, while this new machine was in development it was not called a computer, but rather a next-generation small business unit record system. The machine that flowed from this work would eventually be named the System/3. It would change IBM forever, offering ease-of-use IBM computing to small businesses for the very first time. By the time it was ready for announcement, Rochester had named the machine, the System/3, which signified that, just as System/360, it was a computer system. Just as important as the word system in this scheme was the fact that the number was a single digit. This gave great solace to Endicott and Poughkeepsie as it helped assure them that IBM was not creating another mainframe plant that would compete with their products.
Though the System/3 was simple, it was very capable and innovative. Pictures of the as-announced model and a later-model system, looked almost the same as the announced model. The original models had no disk drives, and card-based (unit-record) System/3 units were Rochester’s only computer product for a while after announcement. Note the vented drawers under the 96-column multi-function card unit (MFCU), These two optional drawers contained two 2.45 MB fixed disk units and also two 2.45 MB disk drives that used the flying-saucer-like disk drives scattered across the console table. That amounts to 9.8 MB of hard drive capacity on four drives. We’ve sure come a long way from such limited technology days, haven’t we? The notions of think small-sized and think inexpensive were prevalent as IBM Rochester designed the least expensive IBM computer at the time. It was, in fact, affordable by small businesses. The new 96-column card developed by Rochester was one-third the size of the 80-column punched cards and yet could store 20 percent more data. The industry was abuzz. IBM marketed the system well, and it sold quite well and gave Rochester a real place in IBM history and in IBM’s future.
RPG for the Business System/3 The most significant innovation for IBM with System/3 was the perfection of the RPG programming language. RPG II for the System/3 was a real programming language. It was rich in business function and thus made the System/3 a real business computer. The language was instrumental in making the System/3 an instant success. It was simple. It was somewhat English-like, and it was not verbose or intimidating for new programmers, as COBOL was. Most of all, it was easy to learn. Since there were not many for-hire programmers back then, the lucky folks tapped to learn RPG in the 1970s with System/3 were often young, bright, and trustworthy employees from blue-collar or white-collar departments. They held other positions in their companies and seemed like the right candidates. Many of these programmers grew up to become the gray-haired AS/400 professionals who now, from their reserved perches on the world’s finest cruise ships, still complain about IBM not marketing their favorite system. IBM rewarded Rochester for its clandestine accomplishments by permitting the lab to continue improving these computers. The biggest and most powerful System/3 was introduced in 1973. It was known as the Model 15D. The unit-record façade for Rochester was officially over. The IBM System/32 Is Introduced With all of this innovation, the System/3 became a big hit in businesses all across the world, and Rochester became a big hit within IBM because it was making money for the corporation. In 1975, Rochester was at it again. The Rochester Lab introduced a System/3-like machine that was desk-sized. Notice I did not say desktop. Desk-sized was about as small as it got back then. This unit had a keyboard and a small monitor, and had a printer attached to its back. It was an all-in-one computer called the System/32.
The System/32 used the same notion of Operation Control Language (OCL) as did the System/3 disk systems. The Set and the Key operations were taken from the System/3 Model 6 and made an integral part of System/32’s interactive RPG. The system had one large fixed disk (up to 13.7 MB). As nice as it was, this desk-size box had one major disadvantage. It had just one input keyboard for interactive work. As such, the System/32 lasted just two years before IBM improved the design with a new and improved System/32. At the time, IBM was good at adding two to the model number as long as it did not reach three digits. So, this upgraded machine was introduced as the IBM System/34. It was constrained in size, but not in its tuning and device innovations. On its best day, total disk capacity was 27 MB. After toying with terminal monitors on the System/3 such as the Communication Control Program (CCP), with the System/34, Rochester chose to make a terminal a real device to the operating system and to the RPG compilers. This brought ease of use workstation programming to the world. By also introducing the notion of multi-programming with the System/34, IBM enabled each user to have a piece of this one computer system as if it were his or her own machine, and unlike mainframes, no system programmer was required.
The System/34 used terminals, but got around the complexities of System/3 CCP. Terminal management was built-into the System Support Program (SSP) operating system. It was an industry first. You could attach a number of semi-intelligent, high-speed terminals to the system over a local wiring type called twin-axial cable, without the need for modems. The new terminal that IBM invented was big and square, and it was called the IBM 5250. Each of these terminals, at the time, could be purchased for about $4,000. Though 5250s are no longer sold, the green-screen 5250 legacy continues today through PC products that emulate the 5250 terminal’s data stream.
The 5250 terminal had been built for Rochester’s System/38 computer system, which was to be the follow-on computer to the entire System/3 line. In 1977, when the in-process System/38 was taking much longer to complete than originally anticipated, Rochester decided to announce the System/34 and to use the terminals and printers that had been designed for the slowly developing System/38. The System/38 Is Announced with Much Fanfare IBM finally announced the long-awaited System/38, which had been code-named “Pacific,” in October 1978. Rochester knew that the machine was not working well at the time, but somehow felt that it would be ready in 1979 in order to meet its planned first customer shipment. System/3 Model 15D customers, as well as many others, enamored by the outstanding specifications of the System/38, and the excitement of the System/38 marketing announcement, signed up in droves on the day it was announced for an early shipment of this new box. Those who may recall 1978 and 1979 know that there would be no early shipments. In fact, there would be no shipments. In 1979, shortly before the system was supposed to ship, Frank Cary, IBM’s chairman and chief executive officer, gave his humble apology and announced a delay of 11 months to make the system ready for business use. If IBM actually knew how difficult it was going to be to bring out a system with the most advanced function ever available (including single level storage, the technology-independent machine interface, and the integrated relational database management system, the object file structure and tight compiler integration for all these components–all hallmarks of the AS/400) in even the largest computer systems, while still providing small system ease-of-use, I am convinced the project never would have been funded. A monument to the practical limits of computer science, the System/38 finally arrived in 1980 to a mostly welcoming customer set. It was the best system that IBM had ever built with an architecture that is yet to be surpassed.
While IBM was bringing in the world of IBM to Rochester to work on the System/38 “problem,” the System/34, with its 5250 workstations, caught on like gangbusters and shipped well over 100,000 units. Fort Knox or Bust! In the early 1980s, the mainframe division of IBM became increasingly alarmed that there were just too many IBM systems aimed at the same customer. Add to this the undisputed fact that IBM executives were never quite happy that Rochester built computers in the first place, and it was easy to see why things got a little dangerous to be employed in Rochester, Minnesota. IBM execs believed that real computers should be built in mainframe plants, such as Endicott or Poughkeepsie. It was tough to argue with success, however, as Rochester units were far more popular than their mainframe counterparts. When you have a lot of money like IBM had, you can spend it on projects that go bust. So, the mainframe-oriented IBM Company spent hundreds of millions of dollars on a project known as Fort Knox to come up with one new system that would do everything that the System/3X machines could do as well as integrating functions from the Series 1 (basically, a glorified switch), and the smaller IBM mainframes of the day (the 43XX series). Since advanced chip technology was not one of IBM’s areas of expertise in those days, the final design of Fort Knox was not one processor that could handle instructions for multiple systems. Instead the hydra-like design was one processor in the system for each system that needed to be emulated. There was no notion of integration as with today’s Power Systems. All the king’s horses could not figure out how to put Fort Knox together, even one time. With processors being very expensive back then, this notion would never fly. It never got off the ground. The System/36 was announced in 1983. It was an enhanced System/34 and offered more capacity and speed. By 1985, the Fort Knox systems convergence project, sponsored mostly by the mainframe plants, had gone bust. The story many Rochester stalwarts were telling other IBMers at the time was that one of the secret goals of Fort Knox was to minimize the impact of the Rochester Lab on the company. The mainframe plants were a bit jealous of Rochester. Their idea was for the mainframe plants and labs to take over the Rochester systems work and send the workforce over to the Mayo Clinic for jobs. Of course, this also failed, but the disdain for Rochester and its products persisted in many important parts of the corporation. Some might argue that the Power Systems convergence is a long-time-coming informal Fort Knox success, since the venerable System/38 and AS/400 names as well as the not so venerable i5, iSeries, and System i monikers have been cast off to the island of unwanted toys, along with the Ford Edsel. Finally, the AS/400 For Tom Furey and other IBM Rochester Lab managers in the mid 1980s, life was not so good. IBM had taken all of the design dollars for the System/36 and System/38 follow-up systems and had given the dollars to the mainframe division, er, the Fort Knox project. There was no cash left for Rochester to create its follow-on products. When Fort Knox went bust and the money began to come back to Rochester, the famous and infamous “Silverlake” project was launched. The Silverlake idea was to create one new hardware system that would replace both the System/38 and the System/36. After little more than two years, in June 1988, IBM announced the results of Silverlake as the Application System/400, or AS/400. In many ways, the box was a repackaging of the System/38, with some left over Fort Knox parts, but it also ran System/36 programs untouched.
The original AS/400 was a resounding success by all measurements but one. System/36 customers were not too happy about it. They expressed their displeasure by keeping their old System/36 boxes as long as they could, and when they upgraded, they would buy either a second used System/36 (same size) or a bigger used System/36. It took a long time for IBM’s System/36 customers to warm up to the AS/400. However, there was enough new AS/400 business at the time from the former minicomputer vendors, such as DEC and Data General, that IBM did not have to care about not fully pleasing its own System/36 installed base. Eventually, IBM was able to place the entire System/36 instruction set, as well as the AS/400 instruction set, on newer and better 64-bit RISC chips. With this change, the company was able to withdraw the Advanced System/36 from marketing several years ago. Today, the AS/400 can perform both System/36 and AS/400 operations.
In 1995, IBM introduced the AS/400 Models 400 and 500 series using the “Cobra” and “Muskie” PowerPC AS RISC chips. Users got to move to a 64-bit RISC architecture from a 48-bit CISC hardware architecture by merely offloading and onloading programs and data. The templates and abstraction facilities in the design of the System/38 permitted the CISC object code to move to RISC at 64-bits without a recompilation (because the operating system did the necessary recompilation in the highly virtualized microcode at the heart of OS/400). Meanwhile, in the Microsoft world at the time, anybody going from Windows 3.11 to Windows 95 (from 16-bits to 32-bits) had to recode their applications–not just recompile. Re-code as you know is a code word for rewrite or write again that which was already written and working. How soon we forget. Too bad IBM could not sell its technical superiority while these major innovations were being released. But that is another topic for another day. In October 2000, IBM recast the AS/400 as the iSeries and in 2004 the company again renamed it as the System i5 or just i5. This name ultimately morphed into System i. Until the launch of the Power 520 and 550 systems last week, most shops continued to call their OS/400 or i5/OS machine “the AS/400.” I would suspect that the AS/400 will not die from our vocabulary until years after the last one has been shipped. With all of the enhancements over its 20 years, the AS/400 has been the most architecturally elegant and capable machine in the industry. From the ground-up, it was built as an integrated machine. When you add this internal elegance to the Power6 engines that are now available with AS/400 technology running on them, the box was clearly the best and most powerful computer of all time. The New Power-Based Power Systems IBM has almost accomplished its Fort Knox dream of converging all platforms. Other than the mainframe, the job is done. From scads of different computers to just two computer lines today based on IBM technology: the mainframe and the Power Systems. I think we can expect that the mainframe will be joining the fold soon, and it is a fair guess to believe that X64 servers will also be brought into the fold. You can bet Fort Knox on that. By the way, one might suggest that if you see the reduced revenue from hardware during the time period from which the Fort Knox project was scrapped until Power Systems emerged as its de facto incarnation, IBM bet Fort Knox that it could do it. IBM won that bet, but lost billions of dollars of hardware revenue over the years in so doing. Now, because of this death-wish desire to have just one computer line, IBM is about to have the revenue stream from just one computer line. Stockholders need to continue to thank former chairman, Lou Gerstner, for getting the software and services businesses going within Big Blue. That’s where IBM is making its money today. Hardware, however, is becoming a diversion and so, the Power Systems will preserve IBM executive energy from having to deal with all of those different system brands. In the short term, nothing will change for AS/400 shops–especially if they opt to stay clear of V6R1 or the new politically correct i 6.1. IBM enabled the Power6 chips to be as integrated for AS/400 as the real AS/400 chips ever were. Power6 just happens to also carry the water for the System p and its virtualization and I/O processor functions. Additionally, one can speculate that there are probably some mainframe pretrails (as opposed to entrails) on that little marvel of technology. So, if you go to a Power System today, you will be better off tomorrow. It has more, not less, and when supporting the AS/400’s newly named OS, i 6.1, it is as good and in fact better than OS/400 or i5/OS V5R4. What Is the Problem, Then? So, what is the problem? Well, to me it’s like General Motor’s Cadillac Division buying the Lincoln division from Ford and announcing a convergence strategy on a new luxury car called the Lincad. Nothing more is coming for the Lincoln drivers who relish whatever the differences are between the two. Nothing more is coming for Cadillac drivers who also love to languish in the extra feature or two that they see in their machine. Quite frankly, the System i had an identity and has been neglected by Mother IBM. Now, without a name or an identity, what should we expect? What is left for the AS/400 shop? Clearly, the notion of real integration is passe with the new IBM. IBM now makes its killing on software piece parts and erector set services to put the parts together. There is no convergence going on in Global Services or Software Group. They make their money on your assembly pain, and the more products you believe you need, the more pain there is. The Web has been available for almost 20 years as a commercial entity and it is the most important part of many businesses today. Yet, IBM still treats it as a non-essential (by which I mean a non-integrated) component. It’s handled on all platforms by the same piece parts software that works the same on all of IBM’s platforms (and other platforms, too). Of course there are just two IBM platforms now. Piece parts development components and one size fits all rule the day. Depending on who you are, it can’t get any better than that and likewise, depending on who you are, it can’t get any worse. Goodbye, AS/400, old friend. I’ll miss you. Brian Kelly was an IBM Midrange Systems Engineer for 30 years, and has spent nearly a decade as a System i5 consultant based in Scranton, Pennsylvania. He is also author of thirty AS/400, iSeries, and System i5 books and he serves as an assistant professor at Marywood University, which uses the OS/400 and i5/OS platform and teaches courses in the box as well. Kelly is also one of the contributing technical editors to the Four Hundred Guru newsletter. He can be contacted through the IT Jungle contact page.
|
