October 31 was the last day that the ancient line of HP 3000 mini-computers could be sold. Hewlett-Packard--who had been marketing the machine for almost 30 years--finally said, "No more!" Meanwhile, some HP customers have begun to shrink-wrap spares, in anticipation of the day when parts will become difficult to obtain. HP's support for all existing e3000 hardware will cease in 2006.

Though the initial announcement of the platform's impending fate came early this year, many in the HP user community are just now beginning to struggle with the implications. The HP 3000 line--especially the e3000 model--was supposed to be the safest, most stable platform that HP ever produced. For some companies, years of investment in custom application development will be wasted. Migration costs are expected to be significant, and a clear path to a new platform is fraught with uncertainty for many. This is particularly poignant, because HP itself does not have a truly sanctioned technical migration plan to support its loyal customers.

So what should the stalwart HP 3000 customer base do? Perhaps they could learn a few lessons from IBM's old System/36 customers.

What HP Says to Do

The International Association of HP Computing Professionals (called Interex) has suggested on their HP World Web site that there are essentially four options an HP 3000 customer should consider:

• Retire the e3000 and its application suites. Interex suggests that, if a customer's business plan hasn't already outstripped the e3000's current software suite, it probably will by 2006, when HP stops providing parts for the hardware. (But wouldn't a quick bullet through the console be a more appropriate suggestion? Instead of keeping the poor old thing on life-support?)
• Scrap the e3000 and make the move from the old MPE/ix operating system to HP-UX. Interex points to the past success of many of its customers in converting to HP-UX (customers who evidently realized long ago that the 3000's days were numbered). HP contends that the numerouse business application suites that have been written for HP-UX--as well as the Windows operating systems--could probably replace the functionality of the e3000's software. This option is also one of the current favorites sported by HP business partners. (Meanwhile, customers are hearing the bright "cha-ching!" sound of cash registers growing louder.)
• Migrate or rewrite the applications using third-party migration tools. According to Interex, applications written in 4GL languages like COGNOS or SPEEDWARE are probably available already for the HP-UX operating system. For applications written in 3GL languages, such as COBOL, HP says there are compilers available from companies like MicroFOCUS or AccuCOBOL. Used together with tools that duplicate the required functionality of the IMAGE and VPLUS databases, an HP business partner could rewrite current custom applications and actually upgrade functionality for the e3000 customer (cha-ching! cha-ching! cha-ching! cha-ching!).
• Keep the applications, and run them on an unsupported machine. Though Interex doesn't recommend this option, it claims that this is exactly the choice that many of its oldest customers are making. (Will the e3000 be covered by the Medicare packages of the future? No word yet from the AARP, the Association for the Advancement of Retired Processors!)

Are There Really Choices?

Of course, all of these proposed options trace pathways that have significant ramifications for the HP e3000 customer. Some of these pathways represent significant investments--not only in new hardware, but in managing new development environments, educating staff, and training operators.

More important, however, is the question of where these suggestions are leading the customer. HP contends that the e3000 is obsolete. But--as any business manager will tell you--"obsolescence" in business plans isn't a function of computer equipment. A computer isn't obsolete until its "useful life" has ended. If the software that supports the business plan still works, a company will be hard-pressed to invest in something new. Instead, this software will be considered a part of the critical infrastructure of the company--like the crown jewels. Just try to convince a business manager of a small or medium-sized organization "It ain't broke, but we've got to replace it anyway!" In today's business climate, that's a NO-OP!

And to be realistic, most of the e3000 customers that are still on this platform are using it because they long ago chose to optimize their investment in computing. Many custom-built their infrastructural software (or paid someone to build it) with all the embedded business rules, automation processes, and organizational procedures they could think of, just so that their businesses could maintain a strategic edge. They can't go backward in time, and they're inexperienced in what technology has in store for them down the road. They've already got well-trained staff that is skilled at maximizing the company's current investment in the e3000. For these organizations, it's not a trivial matter to buy new hardware, customize new software, and retrain personnel to replace an existing system that HP has chosen to make obsolete. The decision to move to something new not only impacts individual departments, but might even jeopardize the entire business model as they know it.

What Some HP Customers Are Actually Doing

One HP customer told me that her company has canvassed the current list of HP business partners and discovered that most have already lost the great majority of their HP e3000 expertise to attrition or retirement. Those consultants who could actually consider offering support are charging an arm and a leg. Some were pushing even more proprietary solutions--solutions based upon closed interfaces to proprietary SQL-like databases--that would, in years to come, make the company ever more dependent upon the supporting consulting service.

"It's a downward spiral of support," she said. "As soon as we sign the dotted line of these support contracts, we're mortgaging the future of the organization to goodwill and longevity of these third-party consultants. But we'll do it because HP has left us no choice."

Shrink-Wrapping the Support

Another HP customer contacted me and said his company is actually buying the remaining HP e3000s they can find on the used market, shrink-wrapping the boxes, and placing them in storage for parts.

"The cost of migrating is too steep, and our business is too reliant upon the current system. We know our current software is arcane, but we don't have the money to reinvest in software, hardware, and training. And we're really hesitant because converting to a new machine--any machine--doesn't guarantee that we won't be faced with this same problem in a couple more years!"

"We also know we're being short-sighted," he said. "But the bottom line just won't justify this kind of reinvestment at this point. It's pointless, and it's counter-productive."

Finally, after a pause, he said with a smirk, "Do you think we could get our HP support rep to step over here to the shrink-wrap machine?"

Deja Vu and the System/36

What's intriguing to me is how familiar these complaints sound. In 1988, IBM presented a similar scenario to its customers of the popular System/36, and for many years, these customer grappled with the same dilemmas. For quite some time, those of us in the consulting arena continued to service the S/36--those legendary machines that were buried under stairwells and in locked closets--trying to help those customers come to terms with the realities of IBM's decision to end support. It was a tricky psychological game, keeping the customer happy while maintaining a kind of silent duplicity in their denial of the real world.

Many of us would go to COMMON and speak candidly about our customers with IBM engineers. "You know," we said, "it's like going back in a time machine at these sites. These people are happy with the System/36! They don't have a need to move! It doesn't make good business sense to them."

Lo and behold! IBM listened! It actually listened! It listened to its consulting business partners and all the old System/36 customers! And it sent its engineers back to work in Rochester. What they came back with was a brilliant scheme that answered nearly everybody's needs.

IBM as Genetic Engineer

How did IBM figure out a way to bring the System/36 SSP operating system and all those old System/36 applications back into the IBM fold? It engineered a means by which the entire kernel of the SSP operating system could be contained within the microcode of the newer AS/400 kernel.

That's right! It genetically spliced the old System/36 operating system DNA into the operating system of the new AS/400. System/36 customers merely backed up data and their entire suite of faithful System/36 applications, and ported it--lock, stock, and, barrel--to the newer AS/400 Advanced System/36 model. IBM regained the majority of its System/36 customers, and customers got the advanced features of the AS/400 without reprogramming or retraining their users.

The Hedge Against Obsolescence

So then what? Weren't those same customers going to have to migrate their applications in the future?

Well, over time, most companies saw their older System/36 applications supplanted with newer code in the normal course of year-to-year enhancements. However, the newer code their programmers or consultants created was even more optimized for the AS/400. Slowly, these customers found that their old ways of working with the System/36 were being transformed by the advanced features of the newer box and operating system. But this process--or evolution--was controlled by their own business needs and not by IBM's technical requirements.

And did the AS/400 stop evolving? Not at all!

The AS/400 continued to evolve and grow with IBM's operating system releases. New hardware came along, but customers weren't required to reinvest unless they ran out of capacity. And when this eventuality came, with advances in the OS/400 operating system, the new hardware was more cost-effective than that which it replaced. There were no conversions of the applications, only migrations to the new more cost-effective models.

For instance, one of the most impressive migrations was to IBM's RISC technology, new microchip technology that enabled all of the AS/400's business applications (including System/36 applications) to a 64-bit operating system version of OS/400.

The iSeries Advantage

Later still, just three years ago, IBM renamed AS/400 to iSeries, and to this day, some of those original S/36 shops still run System/36 applications buried in the bowels of the advanced architecture of the IBM iSeries.

So what is an iSeries today? Well, it still runs those old System/36 applications! And it still runs AS/400 applications, too! And any analyst worth his salt will tell you that it's also the best Java application server on the market today.

But not only that! Using a highly advanced partitioning technology called Logical Partitioning (LPAR), the iSeries is an amazingly economic server of the Linux operating system, too. Finally, using the Integrated xSeries Adapter (IxA) and the Integrated xSeries Server (IxS), iSeries customers actually run Windows applications served directly from the iSeries disk. (Those genetic engineers up in Rochester were working overtime, for sure.)

The Real Options for HP 3000 Customers

You know, maybe those faithful HP e3000 customers should just sit tight and wait to see if Hewlett-Packard will do the same for them, too. Just like IBM did for their old System/36 customers. Maybe they should ask HP to build them an iSeries box to help them migrate their business applications. After all, if IBM can do it, surely HP will take up the challenge too.

They should go to the IBM "Why iSeries" Web page to get an idea of what I'm talking about. It'll help them define what HP should do.

Or maybe--since they're going to have to convert to something anyway--they should just call up an IBM business partner. They'll find them alive and thriving and fully conversant in the dilemma facing the HP e3000 customer. And if they find even one telltale shred of shrink-wrap on any of their business suits, no one will blame them for going back to HP.

Thomas M. Stockwell is Editor in Chief of MC Press Online, LP.

Thomas M. Stockwell is an independent IT analyst and writer. He is the former Editor in Chief of MC Press Online and Midrange Computing magazine and has over 20 years of experience as a programmer, systems engineer, IT director, industry analyst, author, speaker, consultant, and editor.  

 

Tom works from his home in the Napa Valley in California. He can be reached at ITincendiary.com.

 

 

Also Read

IBM i Shops Pivot to Battle COVID-19

Energy, Vibe, and Atmosphere

Murphy’s Security Law