Hi Russ,

...
> All of which describes my greatest concern about open
> sourcing MPE, which I
> view as a great opportunity, and a pretty hefty challenge.
> If I know Jeff
> Vance's or Mark Bixby's hands have been in the mix for some
> change to MPE,
> I'm fairly certain (read: I'd bet money) that it will not
> break some other
> portion of the OS on which my programs, and processes are
> dependent.  Or at
> least, that it will be documented clearly what will break and why.

Thanks for the compliment!  We certainly try not to break things,
and we try hard to ensure forwards compatibility.  We run a lot
of tests before the bits leave HP. But we (at least I) make
mistakes and I have contributed to my share of bugs in MPE (mostly
the CI area).  I hate it when that happens, and I try to be quick to
correct the mistakes. I think others can and do behave similarly.

> I'm intrigued by the idea of an open source version of MPE,
> for various
> reasons; not the least of which is that I like thinking the
> 911 emergency
> systems running on a 3000 should remain as stable and
> reliable as they are
> now, or that this platform I've come to love won't fade away.

So you can trust an open source version of MPE?  One (of several
issues) with open source MPE is that there are much fewer eyeballs
to notice problems with submittals. And also fewer people to
correct problems once spotted -- unlike Linux and other popular
open source projects.

> Opening the
> source also means that the product will not disappear without
> HP maintaining it.

Correct, at least in theory.  You still need to be able to
understand, change, build and test MPE changes either yourself
or pay someone else to.  If that can't be done open source MPE
could also die.

...
> I had always taken it that Open Source meant that if your
> shop can't use the standard, then roll your own.

I am somewhat new to open source myself, but so far I see it
differently.  I see open source MPE as potentially the ultimate
security blanket or insurance policy for the end customer and
for the ISVs that depend on MPE.  By that I mean, if you have
write access to the source then you have at least some chance of
fixing bugs, adding features, etc.  You have the potential of
doing these things, but not a guarantee.

> That's good and bad: good because it means we don't have to wait
> for the powers that be to write, test, incorporate, test
> further, release as beta, approve, and general release a
> product;

You may have to wait a long time depending on the number of people
available to change MPE.  If there are only a handful of folks
able and willing to work on the MPE OS and you want some feature
added (and cannot add it yourself) then you will need to wait, IMO.
I also believe that the ramp up time for many pieces of MPE will
be fairly high.

> but, bad
> because it means that the stability of a baseline disappears.  "You're
> getting an error in THAT subsystem?  But nothing's changed
> that touches it?
> Oh, YOU changed it.  Okay, revert to the standard and remove
> all your own
> modules then duplicate the error, okay?  Thanks."

Fragmented MPE open source would not be good.

...
> Okay, so we won't be able to input a series of key strokes
> and get someone's video game from the CI;

How about random words of wisdom? :-)

> but that extreme is indicative of the problems we'll
> face if too many of the existing shops opt to leave the
> platform rather than fight for it in an open source model.

I assume most vendors will have the health of their company
and retaining their customer base as top goals.  Their
actions will reflect their method of obtaining these goals.

> Without that broad user base to catch
> problems and report them, the product will lose at least one
> pillar to its
> strength.  The gurus upon whom we depend are the
> key to making open source work, and if they get swallowed by other HP
> divisions/projects/etc....

There are gurus inside and outside of HP.  For open source MPE to
be somewhat successful I assume you'd need our test suites and
test drivers -- no small amount there!

> I have been wondering if a "temporary" open source solution
> is better: the
> open source entity (we'll call it "BOB") works on MPE,
> migrating it to IA64,

Slow down! It is a HUGE effort to migrate MPE to IA-64, at
least to do it natively, with forwards compatibility (that means
CM programs work on IA-64), with testing etc...

> If BOB can play well with HP, why wouldn't they
> want to incorporate back into HPUX the core strengths of MPE,

If HP-UX saw something of value in MPE that helped them meet
a strategic objective they can get it anytime they want. There
are many former MPE'ers working on HP-UX right now.

> I saw a posting on slashdot that basically said a really good
> way to make
> some money would be to write an MPE emulator to run in the
> the Linux shell.

I'm not sure how much money there is for this idea, but I do
believe it is technically feasible.
...
> aren't we
> all running shells?  Isn't the main difference between starting a
> session on a
> unix box and starting a session on the 3000, that we are
> automatically tied
> to a process running CI.PUB.SYS, which then acts like a
> filter for every additional call or instruction we make?

Not in my opinion.  The CI is a shell.  But, it is a program that
exposes some of the innards of MPE to the user.  The CI exposes
parts of the file system, intrinsics, some POSIX, some AIFs, some
kernel data structures, etc.  Think how much of the file system
is revealed in the BUILD or FILE commands alone!  You cannot
easily port the CI to, say Linux or HP-UX, because the CI is
tied into the guts of MPE.  Consider the TUNE command, FILE,
RUN, NEWJOBQ, STREAM, etc. and all of the parameters for these
commands.

Also, MPE users have non-CI access to MPE via Intrinsics, AIFs,
3rd party tools and apps.
...
> If the overhead of maintaining MPE is so extreme that HP/CSY
> is giving up
> the ghost, how can BOB do it for any great length of time?

Good question.

> Certainly the resources exist to get BOB to accomplish some set
> of goals (IA64, Unix merge, etc),

I personally doubt it. Your list of two above represents a very,
very large investment of time and money -- assuming native ports
to IA-64 and rewriting large pieces of MPE to leverage more unix
code.

...
> but if we get the reliability and
> flexibility of our platform incorporated into *nix, and maybe
> teach those
> user groups a few of our lessons on being a community in the process,

I do see value in MPE experiences and expertise being
shared with the Unix world.  There are many folks here that really
know how to run an efficient and safe data center, to write efficient
and solid code, to anticipate unexpected events, to plan for
change, etc.  These skills should be transferable to any platform.
And I agree that the MPE community that I've seen, read and been
involved with is very special, and that may be the hardest part of
seeing the 3000 (slowly) fade away.

> If the solution includes even a scaled back CI emulater which
> can keep us
> from having to completely rewrite applications, doesn't that
> give us what we have to have?

A CI-only emulator will be a LOT of work, but a full MPE emulator
should be less work and less risk -- but at what performance hit
remains to be seen.

Today you could have a supported-by-HP 3000 running your business.
With an emulator you have support from whoever writes the emulator.
Probably a smaller company than HP, FWIW.  With an emulator you
have a chance of staying on current h/w and peripherals, but not
for free.  Support of an emulator will be more difficult, I imagine.

> I know, I know, I want my MPE, too!  But, I'm
> not Winston and
> I don't get to say whether or not it will be possible.

I don't either...

My MPE open source comments are mine personally and may not
reflect CSY management's opinions.

regards,
 Jeff Vance, CSY

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *