I've been watching this thread and thinking about the various comments that
have been made - which ones I feel I agree with, and which ones I don't.

I've also been listening to the discussions about current and future
servers in the company I work for, the hobbyist efforts of the younger
employees, and then stewing on the implications.

So where do I see myself and the company I work for going (and this is my
own personal opinion, not my employers)?

At first I thought we would stay on MPE for a few years and eventually
migrate to the HP 9000.  I no longer think that is possible.  The same
logic that HP used in justifying its decision to kill the HP 3000 has been
heard by others in the company to apply equally well to the HP
9000.  Effectively, HP killed the 9000 with the 3000, just on a slightly
longer time frame.  The signs I'm seeing are that we won't be migrating to
the HP 9000, but that we will be migrating, and sooner rather than later,
and to Linux.  Personally, I plan to start learning C.  Keep in mind that
the HP 3000 we have is less than a year old, and really wasn't operational
until last March.

We have many, many Linux workstation boxes, and more and more Linux servers
every day.  They are sprouting up like weeds, and they are about as hard to
kill (crash) as weeds (unlike Windows).  And they are getting more and more
productive work done at less cost and with fewer problems.


Like Ken, I, too am an HP 3000 hobbyist.  I have one Classic 3000 in my
basement up and running 24x7, and a stockpile of parts on my basement
shelves.  Discs are a problem.  Some day I may take my EE friend up on his
offer to whip up a program that would allow a PC with a GPIB card (he has 4
ISA versions of these relics) to act as a disc drive on the classic
3000.  Strange as it may seem, one of the packages I've been playing with
is an old HP 2000 ACCESS game that I'm trying to migrate to the Classic HP
3000.  I still play around with my old classic system, and while it is slow
and limited in its capabilities, I enjoy working on it.

Which brings me to my thoughts on the emulator, MPE, and future direction
issues.  I don't want to see MPE die.  Unfortunately, I don't see any long
term future for it unless it becomes hobbyist-available and goes open
source.  Long term, MPE will only survive if there are hobbyists playing
with it, enhancing it, and moving it forward.  Those hobbyists will only be
able to do so if they can get it up and running on a home/garage/basement
PC for a small sum - $100 to $200 at most.  Most of us MPE folks have job
and family obligations that severely limit the amount of time we have for
such efforts, but every day I see young 20-something software engineers
playing with and enhancing Linux as a hobby.  Those are the people who are
also pushing Linux.  The two feed on each other.  MPE needs that youthful
passion and hobbyist zeal for it to survive and grow.  A $500 or $1,000
emulator and MPE license fee will prevent that and likely kill any hobbyist
activity.  Anything much more than $500 to $1,000 for the emulator and MPE
license fee will likely kill the ability to justify using MPE instead of
going straight to Linux.


So what brought me to these rather absurd thoughts?

First, unless the emulator builder is only in it for a few bucks over a
very short time span, the price has to be low enough to allow MPE to
compete with Linux over the long haul.  I can get a Linux server with a 2
GHz processor, 2 GB RAM, 200 GB RAID, redundant power supplies, and
multiple NICs for about $10,000, including database and backup
software.  How much can I justify spending more than a few hundred dollars
(total) on an emulator and an MPE license for a production machine, despite
the features an capabilities of MPE, when a program run on emulated MPE
will no doubt run slower than a native Linux program and the Linux OS is
free?  I'm going to have to run multiple copies of the emulator/MPE/Intel
hardware to have throughput equivalent to one Linux box.  That right there
will make management look funny at running an emulated MPE.  Add to that
the "what if you get hit by a bus" factor.  There are dozens and dozens of
Linux experts on site, but only one MPE expert.

Second, how long a gap will there be between the end of sales of HP 3000s
by HP and the availability of a working, ready for purchase production
emulator?  It better not be too long.  Hardware cost is also driving other
migration decisions.  The replacement of big iron Unix (HP 9000, Sun, etc.)
with Linux is underway.  Disc mirroring runs on Linux, and it is a lot
cheaper to have three Linux boxes mirrored than it is to have one HP 9000,
and if one of the Linux boxes crashes, the other two keep running.  Buying
used 3000s is only viable if the cost is competitive with the costs of
building a Linux box or boxes.  Will the supply/demand for used MPE boxes
cause used HP 3000 system prices to be competitive with a
Linux/emulator/MPE license alternative?  Thus, the emulator must be
available at the time HP ends HP 3000 sales, or very soon afterward.

Third, MPE must be enhanced and patched and grow and evolve or there is
only more pressure to migrate off of MPE.  MPE cannot stay static.  If it
stays static, it will die, and die quickly.  Thus, another problem.  How
will MPE grow and evolve over the coming years BEFORE the HP end of support
date?  It can't stay static until HP ends support, so that then implies
that OpenMPE will first run on the emulator, and the newer, more modern
version of MPE will be on the emulated hardware and not the original
PA-RISC hardware?  How is HP going to feel about that?

Fourth, what will happen to MPE over the long haul?  What will happen to
Image?  An emulator may ease the transition to other hardware, but what
about the long-term continuation of MPE?  At some point OpenMPE (or
whomever) will have to think about it (MPE) running directly on Intel/AMD
hardware if it has any chance to survive in a Linux on Intel/AMD world.

Which brings me to my fifth and final point.  If you concede that Linux
will gradually take over the server market, what about adding "MPE" to
Linux, as in modules that can be compiled into a Linux build to give some
flavor of MPE to Linux?  Here the primary problem (as I see it) is that the
Linux file system is far more primitive than the MPE file system.  However,
Linux can be (and sometimes is) built with various mods on the file system,
so is it that much of a stretch to add another mod that provides MPE file
system capabilities?  What if the module defaults to the standard Linux
file system capabilities, but the MPE features, normally hidden, can be
invoked by an MPE shell or by calls to OS library routines with our
familiar MPE Intrinsic names?  Wouldn't it be better to build MPE into
Linux than to build it on top of Linux?  I guess the real issue with that
statement is that of the Linux open source licensing
requirements/restrictions - it would have to be a volunteer effort unless
companies could find a way of "bundling MPE capabilities" into Linux in
such a way as to be able to sell the "bundle".  Maybe the emulator should
be a first step, with a slow progression of parts of MPE into Linux
itself.  Who knows, this is just...

Food for thought.

John