|
Plan B: Staying on the HP3000 Indefinitely Hewlett-Packard and a few others are stating that staying on the HP3000 for the long term is your least desirable option, the one that puts you at the greatest risk. Let me argue here that remaining on the HP3000 is not likely to be all that much of a risk, at least for the next 25 years. It will certainly be your least expensive option and the one that will provide you with the greatest protection for your current investment in software and business procedures. AICS Research, Inc. wholly and enthusiastically supports the evolution of an HP e3000 MPE emulator, another path that has been described as "risky." But there's nothing risky at all about the option, should HP give its blessing to the project. It is technically feasible and completely doable. Indeed, the emulator actually offers the very real possibility of greatly expanding MPE's user base. However, staying on the HP3000 does not require HP's blessing. It's something you can decide to do by yourself. And should you decide later to move off of the HP3000, you've really lost nothing in the interim. Indeed, you've gained time to think about what is best in your circumstances.  Risk Estimation A part of calculating your "risk" is really nothing more than sitting back and determining what part of the computer market is rapidly evolving and which part is more or less stable. I have never been a fan of POSIX on the HP e3000 for two reasons: one is that it complicates a very simple operating system, and that's a shame. But the more important is that POSIX can never be UNIX, and thus it will always have a "day late, dollar short" attribute to it, never quite up to speed. And because of the manner by which POSIX was put onto the HP e3000, most UNIX programs won't run without some significant porting effort. The HP e3000 is well-known for its qualities: a very nice CI scripting language, a very robust job scheduler, an extremely stable and scalable database, and its simple, English-like commands. Beyond that, we have also been lucky that the HP e3000 has also recently had put into it several standards-based attributes: network-based IP addressable printing, telnet and FTP, and all of these qualities are now very stable. But all of the other processes of modern computing, the material emcompassed by POSIX (java, samba, apache, bind, dns, etc.) are the qualities that are rapidly evolving. And none of these need to be on the HP e3000. In fact, you're probably better off if they weren't on the platform. The picture above is of a $450, 128MB, 900MHz, 30GB Dell server running Red Hat Linux and a used, unlimited-number-of-users, 128MB, 8GB Series 927 we bought from a customer for $200. Because of HP's announcement, some fraction of users, undoubtedly greater than 50%, are going to move off of the HP3000. What this migration is going to do is provide a glut of hardware on the market in the next several years that is simply going to be unbelievably inexpensive, and there's no reason that you shouldn't take advantage of the situation. You can actually telnet to this 927 by logging onto 67.41.4.238 and typing: :hello <yourname>,demo.qctermOnce there, you can then telnet from the HP3000 to the little Dell server by typing: :telnet 192.168.1.3And that's very much the point. The telnet and FTP standards are now very stable. Almost no change is going to occur in these standards in the next quarter-century. Fortunately both the HP3000 and Linux have them deeply embedded in their structure now. Because of that, you can very readily append Linux and Windows processes onto your HP3000 as auxiliary cheap external boxes. Using the FTP site command, the HP3000 can easily operate as a master controller of any number of external Linux and Windows machines. It is our intention to move our web pages up on the Linux box. It is undeniable that Linux makes a fine webserver. But on the other hand, it is equally undeniable that the HP3000 is a very nice database platform. Using HP3000 scripts and jobs, it is very easy to transfer files to and from the Linux box, constantly updating web pages as need be from data held in your HP3000's databases. Most of the applications on the HP3000 are quite old and very stable. If the more modern -- and therefore much less mature -- applications such as web and file serving are put onto the Linux box, such auxiliary Linux platforms can fail without impacting the HP3000 at all, other than perhaps holding open the one or two processes that might be waiting for a reply. But even if that should prove to be true, all that these processes should do is hang until the Linux boxes are resurrected. They certainly will not crash the HP3000.  Hardware Maintenance There are fewer parts in a modern computer than most people imagine: a power supply, a few circuit boards, a few disc drives and a backup device, generally something like a DDS or DLT tape drive. But beyond that, they're hardly anything else but sheet metal. One of our HP3000's, the 918 in the picture above, originally came with two 4GB drives mounted internally. One of the drives failed, as that particular series of 4GB drives that HP supplied had a tendency to do. Access to the drives is merely a matter of unscrewing two screws at the base of the faceplate, lifting the faceplate away, and pulling the disc drive cage out a bit from the central case. To replace the drive, all I did was unplug the power cables and the ribbon cable from the defective drive inside the cage. Otherwise, I left the drive mounted where it was. I then ordered an extremely inexpensive, external SCSI-connected LaCie drive from APS (www.apstech.com) that was designed to work on PC's or Mac's and plugged it into the SCSI port at the back of the HP3000, giving it the same SCSI address as the dead drive [I prefer SCSI-connected external drives, even though they're a bit more expensive, simply because they're so much easier to replace if the time comes again to do so]. I wasn't able to order an exact replacement 4GB drive. The smallest, cheap external $250 drive that I was able to order was 18GB, and that was from the "legacy" series. Nonetheless, it booted instantly. How stable is this sort of repair process likely to be over the next 25 years? SCSI is SCSI. We were an early and very enthusiastic adopter of Macintoshes when they first appeared in 1984, and this 18GB drive could have been just as easily connected to one of our 1985 Mac Pluses as it was to the 1999 HP3000. Although there are other external bus structures in existence (USB, Firewire, optical, etc.), SCSI is likely to be approximately as common 25 years from now as it is currently. But even if it were supplanted by some other bus structure, you can reasonably be assured that bus convertor boxes will be available. While there is likely to be a great deal of evolution in peripheral devices over the next quarter century, SCSI frees you to be able to accept that evolution rather easily. Can you really operate a business on 25-year-old hardware, 25 years from now? We do it here with our Macintoshes. Because we were an early adopter of the Macs, and because Apple has not attempted to maintain backwards compatibility in its lines, we were orphaned within just a few years of adopting the Macs. Our initial enthusiasm for the Mac caused us to put 5000 pages of company documentation on the machines. Unfortunately, the very next series of Macintoshes, the PowerPC's, would not run our software and thus we were constrained to keeping our original Mac Pluses alive forever. Although Apple has made the Mac line incompatible within itself several times since, none of these more recent incompatibilities bother us, because we were stuck on the very first generation of Macs. When the Mac Pluses and Mac Classics began to become obsolete, we bought 10 spare machines from the local high schools for almost no money at all. These spares are now stuffed in every nook, cranny and closet, but so far, they haven't proven to be necessary. Although the original Macintoshes were never made nor advertised to be rock-solid, reliable devices, so far they've held up to 17 years worth of daily use. And that too is simply the nature of electronic devices nowadays. Mechanical devices (discs, tape drives, keyboards) may fail, but the electronic circuits could easily run for several hundred years without much maintenance.  Software Maintenance Pictured above is a third small HP3000 that we run, another 918. However that's not the device of interest in this picture. Rather the machine of importance is the small $400 e-machine PC in the center of the image. Adobe Acrobat Distiller is the program that converts PostScript files into the PDF format that's become very popular on the web. Beginning about five years ago, for a period of two years, I spoke to everyone I could at HP and Adobe about porting Distiller over onto the HP3000, but I was able to make absolutely no headway with anyone. No one was interested. Even more frustrating, because POSIX is not UNIX, the UNIX version of the Acrobat distiller would not run on the HP3000 as it was, even though it was certified for HP-UX. One day, in an epiphany not unlike Saul's conversion on the road to Damascus, it simply dawned on me that I didn't need to keep beating my head on the wall. Rather, I could purchase the very inexpensive Windows-based version of Acrobat and FTP my files from the HP3000 down into a PC. The process worked so well that I have now become a very enthusiastic advocate of not porting material onto the HP3000 directly. Rather I now argue that it's best to run the programs on the platform for which they were designed and control them from the HP3000. Indeed, doing this insulates and protects the HP3000 in two ways: one is from random software bugs, the second is from obsolescence. In the arrangement we now use, a standard, simple HP3000 job runs our QueryCalc reports and prints their PostScript output to MPE flat files. As a second step in the jobs, the ASCII flat files are FTP'ed down into the e-machine, into an Acrobat "watched" folder, adding the file extension ".ps" onto the file as an intrinsic part of the transfer. The PC is set up so that when a ".ps" file appears in the watch folder, Acrobat automatically converts it into PDF, moving it to a pre-specified output folder. Although the distillation process generally takes less than a second, we have our HP3000 jobs wait 10 seconds before they retrieve the newly-converted PDF files and move them back onto the HP3000. Once the new files are back on the HP3000, they're FTP'ed to a third server, our webserver in Minneapolis, MN, inside the same job. It's all surprisingly very simple, very straightforward and very efficiently done. Because virtually any process on a Linux/UNIX or Windows machine can be controlled in this manner, there's essentially no reason to port anything to the HP3000 nowadays. But just as importantly, this simple observation makes the current version of MPE nearly obsolescence-proof. Even more than SCSI, FTP and telnet, because they are now nearly ubiquituous 30-year-old standards, are going to look the same in 25 years as they do now. They cannot be changed. Hardware ages, but software doesn't. It is essentially immortal. But can you run 25-year-old software 25 years from now, especially if no one is "maintaining" it? What does maintenance mean? To a great degree, it means keeping up with the evolving standards, not fixing bugs. But what would you really want to change on your HP3000? Your code works now. It will work just as well a quarter-century from now. The little Linux box in the topmost picture is set to dial back to Red Hat every evening, check for updates, and apply them automatically, if need be. Doing this is necessary at the moment because of the rapid evolution attendent to trying to make Linux a mission-critical operating system, and it will be that way for the next five years or so. But there's virtually nothing that really needs to be fixed on the HP3000 that sits next to the Linux box. MPE code has proven itself to be extremely reliable at tens of thousands of sites over decades of use. And although the total sum of all of the equipment in the upper image came to less than $2000, there is sufficient computing power on the table to run a $50 million/year business easily. All software contains bugs, and on the last day that HP corrects whatever bugs it finds in MPE, if no emulator and no Open MPE should come to pass, those defects that exist in the code on that day will remain there forever. But in many ways, operating under these conditions is more stable and more predictable than when code is still actively being modified. You rapidly learn where the remaining pitfalls are and you simply work around them. The real trick to operating obsoleted hardware and an O/S is to buy multiple spare equipment. This equipment is going to become startlingly cheap in the next few years, so keep your eyes open for it. In your free time, configure these spare systems to be identical to your production boxes. In this manner, if your primary systems should fail, you can actually swap out a spare system faster than you can call for assistance and certainly be back on line before the repair people arrive, if you need them. Doing this also allows you to find out what's wrong with the failed system at a leisurely pace and get it back up and running on a schedule that's far more appropriate to the task than one dictated by panic. As I mentioned at the beginning of this note, I do not believe that staying on the HP3000 indefinitely to be a particularly risky strategy. If your code and business procedures work well today, they will work just as well tomorrow, a week from today, or twenty years from now. In great contrast, migration may be the riskiest thing you can do. Over the years, we've had a great many customers move off of the HP3000 and we've been very interested in hearing about their successes and their failures. The former users who have had their companies bought out by a larger organization have had the greatest success. The larger organization dictates what kind of computer system they're going to use, and in this situation, the HP3000 often loses. Nonetheless, our former customers generally have to do no more than have their terminals changed out and learn the new business rules as they connect to the central server at company headquarters. In this company-purchase environment, everything has been relatively well smoothed out in advance by the purchasing organization, optimizing their procedures over a period of years, if not decades. But the same hasn't been true of our customers who have "migrated" off of the HP3000 onto some other platform, based on their own volition. Their costs of migration have universally been far higher than anyone originally estimated, as have the times involved. Indeed, the migration efforts were so difficult that a few of our former customers have outrightly failed during the process and many others were put at high risk. There's no single day in the life of a company when the computer system, no matter how it's architected, that it can't operate and fulfill its business purpose, and it's this simple necessity that makes migration so extremely difficult. If your choices boil down to choosing between a "migration" process, which may cost millions of dollars, and which may well put the company at risk, and doing nothing, other than purchasing a number of very inexpensive spares, staying put may well be the least risky thing you could ever do. Wirt Atmar |