Stages of Keeping a 3000 Living Onward
HP's migration choices vs. the vendor's end

Migration connections, as well as about-faces

Second of three parts

In our 3000 Newswire print issue Q&A interview with 3000 community performance and management consultant Jeff Kubler, I asked him where the advantages seemed to rest in the customer base he's encountered during the Transition Era.

What makes migration a better choice for some customers?

   I think re-creation with Eloquence [as a database], and using one of the portable COBOL compilers can make a migration happen very readily. I've heard stories of people getting a huge, expensive picture painted for them, the cost to migrate to .NET, C Sharp and a SQL or Oracle application. Then they make the decision to go to Eloquence and use some of these tools, see how little investment they must make, compared to what the full-blown thing would have cost, and how easy it was.

    If a person has a very functional application in the main, solving the problems of your entity, and you want to get to a place where if you have a problem you want to get an HP-UX box that could be 2-3 years old, instead of 5-8 on the HP 3000 — and the UX box can be supported by HP or some other competent provider, a person can get to a migrated state using compilers like AcuCOBOL. You can get 500 programs compiled in a couple of days solve a few other issues and be up and running.

Do companies report they're migrating, but do little once they say so?

   "We are migrating off next year," is the most common thing I've heard, year after year. It puts everything in a dangerous place, and many companies have only been saved by the rock-solid nature of the HP 3000. Companies have stopped investing in software, support and training.

Even announced migration plans, once they pass through the do-little period, are being rescinded. The major reason for this kind of an about-face is an inability to locate a third party application that does everything an HP 3000 app has been doing. Kubler said

   I've seen a lot of places where they're migrating for three, four or five years since 2001. They still haven't migrated, and they don't have a plan to go anywhere. And while they're migrating, they're not going to make any investment in training, or keeping their third party tools licensed, or even knowing if they're supported, or by whom.

    I even had a company who made that migration statement for years, then realized they couldn't find an application of what they had now, designed for their business rules. After saying they're migrating for a number of years, they've started to come back and reinvest in 3000 things.

Why hasn't that neglect caused more turmoil?

   It's the dual-edged sword of the 3000, it's ease of use and hardiness. At one large customer in Minnesota, I was consulting on performance and capacity. The CIO was describing the environment and he said nothing about having HP 3000s. When I went down to talk to the datacenter manager, he shows me the three of these, ten of those and four of that. Then he said, "Now these three, 997 whatevers, are the most critical boxes in the room here. They do all the things that haven't been migrated, and consequently, they're the most important ones. The non-important tasks are being done by these other ones now."

    The CIO didn't have any knowledge of the 3000s. You ask them, "What's that box over there?" and they say, "That's where I set my bucket of water next to when I mop." There sits an HP 3000 that no one even recognizes as the critical system, because it never needs to be rebooted, and it just runs.