Choosing a Path for the 3000s
Gavin Scott stands at a good spot to see the future of the
HP 3000. That because hes 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 HPs 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
Whatever that future is, Allegro believes it can help
every customer in deciding what to do. Company president Steve Cooper
says its 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 HPs MPE engineering on contract.
Cooper told us that Scott is walking point on
MPEs path for the company, coalescing the many options to
supply the firms 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 Quests support
department, and of late has been looking hardest at the possibilities
for emulating the HP 3000 and MPE outside of HPs product
offerings. As the 3000s 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
communitys 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
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 were
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?
Theres 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 its
just easier and cheaper to buy something new rather than go through
the migration process.
What about the future of MPE without HPs 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
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 todays 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 cant make money in. Its 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
3000s operating system, in terms of technical capability?
If were 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
If were talking about taking over the full
source code and doing major enhancements or a port to IA-64 or
something like that, then its 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, youd want to acquire one or more of the key
architects from HP to become part of that new organization. If you
couldnt do that, its certainly still possible, but it
would be so much easier to have people who understand the tools and
the environment. Youre probably talking about HP letting go of
a few of their employees, people who are really interested enough in
MPE theyd want to continue their careers in that direction
beyond when HPs doing it.
Youd 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 youre
going to try to merge it with Linux, for example, youve 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 thats 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 thats true?
Yes, I think so. Were already seeing an upsurge
in people interested in third-party software support. Im
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
Its kind of hard to tell. I would have thought
more people would have spent more time waiting to see whats
going to happen. Unless people are upset enough with HP to drop them
from support right now, theres no different reason this year to
go to a third party this year. Its 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, its going
to vary. Ive seen more people doing more things earlier than I
Allegro is part of the Customer Care Consortium. Whats
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. Its 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 dont 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
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 theyll 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
Whats 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.
Whats 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 were 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 theres 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 wed 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 Allegros 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
havent 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 dont plan to go down that path at the moment. Its
really Interexs job to position themselves, in this Internet
era when 3000-L has become the users group for MPE.
Whats 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,
theyve 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 HPs Unix rather than
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 its 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 cant get it from Red Hat yet.
Well, with all the focus on Intels 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
Its not clear that any MPE programs will need
64 bits any time in the foreseeable future. IA-64s 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 Intels reported Plan B of simply adopting
AMDs 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
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 communitys 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 its still on
MPE, making the actual move to Unix or wherever much easier.
Hows the 3000 communitys 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 well 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 theres
no reason to believe that they will drop support for MPE as long as
people are willing to pay for support.