Choosing a Path for the 3000’s Tomorrow

Gavin Scott stands at a good spot to see the future of the HP 3000. That because he’s vice president at Allegro Consultants, a company that seems to be at the crossroads of all HP 3000 options for the years to come: emulation projects, migration advice, discussion of how to enhance MPE beyond HP’s departure from the market in less than five years. Allegro has committed to providing software support for the HP 3000 for another 10 years, at least through December 2011. Some think it will take at least half that amount of time to figure out what will happen to the 3000 community.

Whatever that future is, Allegro believes it can help every customer in deciding what to do. Company president Steve Cooper says it’s had more visitors to its office in the past two months than in the past two years. Many of the remaining companies in the 3000 ecosystem are turning to Allegro to help in future endeavors. “We seem to be a part of what everyone is envisioning their future to be,” Cooper said. HP has relied on Allegro in the past while creating parts of MPE/iX; at one point company engineers quipped that the firm felt like “Cupertino East” by doing some of HP’s MPE engineering on contract.

Cooper told us that Scott is walking point on MPE’s path for the company, coalescing the many options to supply the firm’s expertise in PA-RISC. Scott has been working on the HP 3000 RISC hardware since HP let it out of the labs more than 14 years ago, starting with beta testing one of the first Series 930 prototypes while programming for ADI, a job he first took in high school. Scott picked up his 3000 experience through a highschool classroom, programmed his way through a few college years, and took off into the world of commercial product design at Quest. He joined Allegro in 1995 after putting together Quest’s support department, and of late has been looking hardest at the possibilities for emulating the HP 3000 and MPE outside of HP’s product offerings. As the 3000’s creators consider what HP will do to assist the thousands of customers staying put, and Allegro pledges to help both homesteaders and migrating customers, we asked Scott to outline how far he thought the platform could go under the community’s engineering steam.

So what are the options facing 3000 customers?

There are three basic paths that MPE customers can take going forward. The first is to stay on MPE forever, the second is to replace (or rewrite) their MPE applications with new applications on some non-MPE platform, and the third is to migrate their applications to another platform.

Many customers may find themselves following more than one of the three paths. They might replace their major applications, migrate some key business applications — those custom systems that define the company and provide critical differentiators versus their competitors — and there might be some applications that they choose to leave running on MPE forever. A lot of them might end up with multiple choices from those three paths.

Which one of these paths do you believe most people will follow?

Initially, I think the naive view many people will have is a sort of bell curve-shaped spectrum of options with a few people staying on MPE on one end, a lot of people migrating their applications in the middle, and a small number replacing their applications outright at the other end. But I think we’re actually going to see the inverse of this, where migration ends up being the smallest segment, while the largest becomes outright replacement of old systems with new ones, and a higher number of people staying on MPE than one might initially expect.

Why not just migrate, as HP recommends?

There’s still going to be a lot of migration work to be done. But many people who today assume that they must find a way to migrate are going to discover that in many cases it’s just easier and cheaper to buy something new rather than go through the migration process.

What about the future of MPE without HP’s support?

I think there are also three possible future roads for MPE to travel. The first would be a decline into virtual non-existence by the end of HP support in 2006. I suspect this is the path that HP initially expected MPE to follow, having worked out to their own satisfaction the various justifications for setting an obsolete date for MPE, such as the belief that nobody wanted it anymore. But I believe there has been significant resistance to the idea of being entirely off MPE by the end of 2006 from many important customers.

The second path would amount to a “life extension” for MPE, but probably not a great deal of growth. This road would involve options such as software to emulate the HP e3000 hardware on, say, a Windows or Linux system, allowing one to run the existing PA-RISC MPE/iX operating system and all its applications on cheap PC-class hardware, third-party support to replace the HP Response Center, and some minimal maintenance of the operating system itself (perhaps even without source code) to keep it running indefinitely with today’s functionality.

The third option would be a growth option, involving the transfer or licensing of MPE and its source code to a third-party organization or group of organizations who would then attempt to maintain, support, and enhance MPE.

Because HP owns MPE and tightly controls its licensing, they are the only ones who can decide which of these routes is possible. Whether each is practical or not is another issue.

How do your estimates of costs impact these options?

The first and third options are the most expensive. In the first, customers have to spend a lot of money to get off of MPE before the deadline. In the third option, someone has to essentially replicate CSY and manage to make money in an environment that HP decided was impractical for them, which sounds like a very hard road to take. I think these two are the least likely to happen. Nobody has come up with a business model to make money in a business HP has decided they can’t make money in. It’s certainly still possible in the future that HP will open-source MPE.

From an MPE point of view, I believe it will be the second or middle path that turns out to be the most useful, if HP will permit it to happen. If HP will allow it, then various companies will make it possible for people who want, need or must keep running MPE applications in 2007 and beyond to do so indefinitely.

Can a company outside of HP maintain and improve the 3000’s operating system, in terms of technical capability?

If we’re talking about maintaining the status quo as far as MPE features and functionality goes, then I think all of the resources needed are already in place. We have third-party hardware and software support organizations who are quite capable of making sure that your 3000 is able to do tomorrow what it did yesterday.

If we’re talking about taking over the full source code and doing major enhancements or a port to IA-64 or something like that, then it’s a much harder question. MPE/iX consists of millions of lines of code assembled over three decades. Major development work will require a significant investment of capital, plus getting some of the best minds in the MPE world involved from both outside and inside of HP. If you were going to create a new CSY, you’d want to acquire one or more of the key architects from HP to become part of that new organization. If you couldn’t do that, it’s certainly still possible, but it would be so much easier to have people who understand the tools and the environment. You’re probably talking about HP letting go of a few of their employees, people who are really interested enough in MPE they’d want to continue their careers in that direction beyond when HP’s doing it.

You’d probably also need others among the best people in the community as architects and directors, to ensure MPE stays MPE and goes in a direction that makes sense. If you’re going to try to merge it with Linux, for example, you’ve got to do things that make sense for the same reasons that continuing with MPE makes sense.

What kind of revenue model do you think is required as a minimum to make such stewardship of MPE possible?

Maintaining MPE/iX as it exists today and even running it under an emulator on other hardware platforms is a relatively small amount of work, and need not even require access to the source code, so I think this model is viable even if fewer people are running MPE in the future. That requires relatively little funding and would probably work just fine on a standard product model: you buy the emulator and pay an annual support fee, and buy software support from Allegro or Beechglen or somebody like that. That model is there today.

For a CSY-style organization to do major work on MPE, I think you would need to sign up a significant fraction of the existing customer base, and have a good prospect for future new sales, so that’s a much less certain proposition.

Outside-of-HP support for MPE systems looks like a growth market, at least for the next several years. Has there been enough interest yet for Allegro to believe that’s true?

Yes, I think so. We’re already seeing an upsurge in people interested in third-party software support. I’m actually a little surprised at this, as I would have expected to see people stay with their current providers while they figure out what they are going to do, followed by a gradual shift to third-party support as HP reduces their investment in the platform.

What kind of time frame do you see people making that shift in?

It’s kind of hard to tell. I would have thought more people would have spent more time waiting to see what’s going to happen. Unless people are upset enough with HP to drop them from support right now, there’s no different reason this year to go to a third party this year. It’s not any cheaper this year than last year. I think a lot of the shift is emotion, and people reacting more quickly to the decision than they need to.

There will be waves, here at the beginning, at the end of 2003, and at 2006, seeing people making shifts. As far as when people are actually going to take action on things, it’s going to vary. I’ve seen more people doing more things earlier than I expected.

Allegro is part of the Customer Care Consortium. What’s your role in that alliance?

The primary thing that drove the creation of the Customer Care Consortium by M.B. Foster was a realization that even if a majority of people end up replacing their MPE functionality by an off-the-shelf application, it still leaves us with 20 percent of the customers who want to migrate. It was created as a response to the recognition that there was going to be a lot of work to do in supporting those customers who desire to migrate their applications to another platform, and no one company or organization was going to be able to meet all of the technical and manpower requirements.

By pooling the resources of the Consortium members, we can provide more seamless and cost-effective solutions for customers. We have compiler technologies and low-level system know-how. We also have consultants available for planning on migration, and people we can bring in who are interested in doing that kind of work. [The] SPLash [SPL compiler] is still a going thing, and people are still buying it for MPE/iX. It’s also available for HP-UX PA-RISC.

What does your study of PA-RISC architecture tell you about the feasibility of emulating it on IA-32 chips?

The advantage here is that the IA-32 chips are so fast (2.2GHz and climbing) relative to the typical CPU requirements of MPE — which was originally designed to run on a machine whose speed was measured in hundreds of KHz! — that we don’t have to worry too much about architectural differences between PA-RISC and IA-32 or whatever.

If you ask me to have somebody with a 4-way N-Class replace that with an emulator, I would probably be relatively skeptical. People who have those kinds of boxes would be less interested in that kind of solution to begin with. All of the very small and medium-size customers could run their applications under an emulation environment with no real problem.

What about those people whose performance needs outstrip an emulator?

We may be able to buy 16-way IA-64 boxes running 3-4 GHz three or four years from now. The very large customers may not even be looking at getting off the machine. They can afford to keep paying HP for support, and they’ll be the last ones looking for an emulation solution. They tend to be running large packages like Amisys, Summit, Ecometry. Their software vendors might be providing them with their ultimate solution, replacement versions on another platform.

What’s your preference: Build an MPE emulator on your own, or partner with SRI or another experienced emulator provider?

We think we have all the skills, tools, and resources to do the development work ourselves at this point. The only questions at this point are permission from HP (some indication that they will license MPE so that it can be used usefully on such an emulator) and some final determination of the project funding and the ultimate productization of the result.

What’s the best arrangement for Allegro to participate in prospective OpenMPE LLC plans — as an outside contractor, or some more closely-allied partnership?

At the moment we’re still investigating all avenues for participation in the plans of OpenMPE Inc. and others. We are talking with HP about the licensing issues, and have proposed to them that they actually support the development of an emulator. The possibilities for funding and turning it into a product are three-fold. One would be that Allegro does it as a standalone product, sold like any other and a support charge for that.

The second might involve OpenMPE Inc. hiring Allegro to develop the emulator, and they would arrange the funding and pay us for the development. The result could be owned by the community or by them — details to be worked out. Then there’s the “Wirt Atmar funding model,” where somebody takes up a collection of $2,000 each, and if you contribute that you get complete rights to whatever the development process produces.

One of the things we’d like to be able to do is to make available a personal edition of the emulator that could be used on a single-user development system for no or little cost. For something under $250, maybe free, you could get a copy of MPE/iX and an emulator you could run on your laptop and have your own private 3000. It would probably be restricted in some way as far as the total amount of disk space it could use or the total amount of memory.

Do you believe that Allegro’s prior engagements with CSY can help provide some measure of confidence to HP about releasing its source code to your labs?

I would certainly hope so. But at the moment we haven’t asked them to turn the MPE source code over to us for maintenance. I think that would require the resources and commitment of more than just one company!

What role should the HP user group play in future development of MPE after HP steps away from the OS?

The most important roles will be played by people who actually are in a position to make some money off continuing to support MPE, those who have a reason to want MPE to continue to exist. The users’ group could count themselves in that category. If MPE does move toward an Open Source type of environment, there would be a much larger coordination role for Interex. HP has said they don’t plan to go down that path at the moment. It’s really Interex’s job to position themselves, in this Internet era when 3000-L has become the users group for MPE.

What’s Unix got going for it that makes it worth the effort a 3000 veteran will need to spend on learning it?

If the 3000 is scheduled to be carted out the door, they’ve got to make some decision about retirement or some other computing platform. Unix is more in line with the sort of things you do with MPE. It may be the closest thing to get them into the big wide world of modern computer usage.

Can you make a case for using HP’s Unix rather than Linux?

HP was talking up Linux at Linux World a few weeks ago in a big way, merging the Tru64 functionality and the HP-UX functionality with Linux functionality. While there will almost certainly be something called HP-UX five years from now you could buy from HP, whether it’s actually a variant of HP-UX, Tru64, or Linux may be too early to say.

Linux has gotten to be enough of a power that the two games are either making your proprietary Unix compatible with Linux, so you can run Linux applications on an OS like HP-UX, or to take what functionality you feel is missing from Linux and add it in, and switch over to providing Linux as your main operating system. That said, HP-UX is a much better operating system on PA-RISC servers at the moment than Linux is. PA-RISC Linux is one of the second-tier Linux platforms, behind the x86 or the PowerPC versions of Linux. You can run Linux on PA-RISC, but you can’t get it from Red Hat yet.

Well, with all the focus on Intel’s current processors, is IA-64 worth the wait and the migration for application providers now in the 3000 space? Do they really need the 64 bits in Itanium, given that Intel has a project to add 64-bit features to its x86 architecture?

It’s not clear that any MPE programs will need 64 bits any time in the foreseeable future. IA-64’s advantage is not a technical one, but a marketing one really. At this point the future of IA-64 itself is being called into some doubt by people who point to Intel’s reported “Plan B” of simply adopting AMD’s 64-bit extensions to the old x86 architecture.

How much of the 3000 community, as you know it, would you estimate will actually want to migrate their MPE application code to Unix?

A wild guess at the moment would be 20 percent migrating, 20 percent staying on MPE forever one way or another, and 60 percent simply replacing their MPE functionality with newly acquired or developed applications on other platforms.

Is PostgreSQL going to open up some doors for companies that want to stay on the 3000? Or is continuing IMAGE development a better use of the community’s resource?

It certainly may useful for those who wish to migrate off of MPE in a phased approach, where they slowly remove as many MPE dependencies from their code as they can while it’s still on MPE, making the actual move to Unix or wherever much easier.

How’s the 3000 community’s health? Does it appear more robust to the typical 3000 customer than it did to HP? Can there be a healthy 3000 community without HP?

I think we’ll see some fallout among the smaller 3000 companies, and those who have just been hanging on for some time. But many 3000 companies like Quest, Cognos and others have long since made the transition to other platforms — and there’s no reason to believe that they will drop support for MPE as long as people are willing to pay for support.