This is significant energy spent on a factual dead
possibility. The market isn't going to go this
direction, hasn't gone this way and won't. There are a
lot of intelligent people out there with MPE passion,
but trying to revive it, move it to other hardware, or
save it is ignoring the market. Face it, as much as I
too don't like it, MPE is a dead O.S. and the market
has/is dictating such. Its not gonna happen. 

Out of 10 MPE companies since 1997, 4 are on other
platforms and not looking back, or desire to go to
MPE, 3 more are in transition and near other solutions
concluding this year. 2 are planning to transition and
have chosen the platforms and 1 will stay - for how
long who knows. 

If my estimates are correct, in 1997 it was thought
that there were 30,000 MPE's in the world. Based on my
knowledge and experience of the 10 companies above,
this comes out to 300 companies still on MPE for who
knows how long. 

There are several factors enabling the judgment of the
market, a few of them are MPE-HP3000 job postings.
Look at how many fewer there are. I know of several
major outsource/companies/firms/contractor/consulting
establishments that don't even exist anymore or part
of the focus isn't to fill HP3000 openings. When was
the last time you seen 20 MPE/HP3000 jobs listed in
hotjobs, monster, workplace, dice that shown current
openings? How many MPE's went away with Y2K? How many
professionals do you know who no longer work on MPE? 

Even bright and passionate folks sometimes don't see
the reality. 

Respectfully. 

--- Gavin Scott <[log in to unmask]> wrote:

> Pete ponders:
> 
> > Running Classic binaries on PA-RISC was the best
> performing emulation
> > I have ever seen.  QEMU is not going to give you
> nearly the
> > performance.
> 
> CM on MPE/XL was probably as good as it gets in
> terms of emulated speed
> versus native speed on the same platform.  In fact I
> believe it resulted in
> HP having unrealistic expectations about PA-RISC
> emulation on Itanium.
> 
> In the case of emulating an HP-3000 though, you care
> only about emulated
> performance versus native performance ON THE
> ORIGINAL HP-3000.  Most 3000s
> are so amazingly slow by modern standards that
> there's not likely to be a
> big problem exceeding the original performance even
> with a pure emulation of
> the hardware platform.  And this situation just gets
> better over time.  If
> it's not fast enough today, just wait a year.
> 
> In terms of relative difficulty of an emulation
> solution that allows you to
> run the existing MPE/iX OS and applications without
> any changes, versus
> developing a whole new MPE compatible OS, the
> emulator program would be
> miniscule in size when compared with MPE, and the
> work to be done would be
> much better defined.  So I still believe a software
> emulation of the HP-3000
> hardware platform capable of booting and running
> unchanged MPE/iX is a
> perfectly viable idea.  Whether it does anything to
> "save MPE" or not is a
> different debate.
> 
> > The other issues are getting the source for MPE in
> total, which appears
> > to have some problems with inclusion of 3rd party
> software and the fact
> > that HP doesn't want to spend the time to clean up
> the code for release.
> 
> For an emulator, you need no source code.  You
> simply emulate one or more
> HP-3000 models and you run the OS unchanged.  You
> need only a runtime
> license as you have today, which should not
> complicate the included 3rd
> party software licensing.
> 
> > Another problem going forward, is getting hardware
> drivers for new
> > server peripherals.
> 
> A simulation of the hardware solves this problem
> completely.  You simply
> teach your hardware simulation program to make a
> LudicrousTapeXVII drive
> with a sub-ether trans-light SCSI 23 interface look
> like a DLT4000 with a
> single-ended SCSI interface.  MPE already supports
> one or more devices of
> each "type" (disk, tape, network, etc.) that you are
> likely to ever want to
> connect, so the emulator simply maps the behavior of
> your new exotic
> peripheral into one of the already supported devices
> in MPE.  No changes to
> MPE are ever necessary.
> 
> > To get anywhere near native speed in hardware
> emulation, you have to
> > have some very talented CPU design engineers to
> design it into the CPU
> > circuitry.  Doing it in software is always going
> to take a major hit
> > in performance.
> 
>     928LX:    48,000,000 instructions per second.
> Modern PC: 3,000,000,000 instructions per second.
> 
> You can waste 60 native instructions emulating each
> PA-RISC instruction (and
> this only has to be an average of the most common
> instructions) and still
> come out ahead.  The numbers are only approximate of
> course.  And again this
> "problem" gets better every year.
> 
> > And, if you are taking a major hit in performance,
> how do you stack up
> > to the competition?
> 
> Ah, yes, well, if you want your MPE to compete in
> performance with, say,
> modern Linux on a modern x86 platform, because you
> think you have a hope of
> convincing new customers to run MPE, then I think
> you have a much harder
> struggle ahead of you.  MPE is unlikely to ever
> again "compete" with any
> operating system.  Now you might have an
> *application* (that can compete
> with other *applications*) that happens to have MPE
> under it, but there's
> just no hope for competing OS vs. OS at this point.
> 
> > Which brings me back to my original idea.
> 
> So, unfortunately, I have to say that ideas are a
> dime a dozen and of
> practically no value when compared to some actual
> effort.  As the old saw
> goes, genius is 1% inspiration and 99% perspiration.
>  So come back and show
> us when you have it working.
> 
> All of these ideas were discussed at length five
> years ago.
> 
> We had the emulation discussion (at great length). 
> We actually had the
> "let's implement an MPE file system in Linux"
> discussion (several times).
> What it comes down to is that nobody has yet done
> any of these things after
> five years.  There exist several commercial packages
> designed to simplify
> migration of MPE applications to other platforms
> that implement various
> parts of MPE functionality (Intrinsics, CI language,
> etc.) but none of them
> can be said to "be MPE" in any significant respect.
> 
> If you think the world needs MPE extensions to Linux
> then by all means go do
> it.  That's where things like this actually come
> from.  You might not have
> to do too much before you get other people
> interested in helping, but you
> have to have something you can show to people and
> say "come look at this,
> isn't it cool?".  Ideas are fun, but other people
> volunteering to implement
> your ideas for you does not happen in practice.
> 
> G.
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com