I am sorry, but I cannot agree with the below statements. What made the
HP3000 great and still does today was the ability to run old code on new
machines. But attention had to be paid to the hardware, i.e. instruction set
of the computer. When the PA-Risc was being designed, HP strove to make sure
that the old code would run on it. This had nothing to do with the OS as it
did with the hardware. Before you disagree, I do understand the controls in
which the OS has in choosing who runs what code, but without a choice, there
is little the OS can do.
That said, for MPE to continue into the future it will most likely have to
incorporate the IA-64 instruction set or what ever instruction set that
comes down the pike. IBM and HP for that matter, write hardware emulators to
run obsolete instruction sets, and give their new OS's knowledge of given
emulator. Thus IBM is it main OS runs virtual OS's below it to allow their
clients to continue with their old code. HP did the same with compatibility
mode, where some of their clients did not have source code anymore to
recompile to the new instruction set.
This level of emulation, especially for speed purposes, is not for the faint
of heart. Linux, which is supposed to run on many platforms, still needs
good hard work to make it run on different platforms and to maintain it.
Most of us have been made soft by the work done before us. Oh, I want to put
Linux on my machine, great, download the source (made ready for PC
machines), also get the GNU C to compile it, (which is also been made for
machine) and compile it and test it. What?! I need drivers, go get Linux
drivers written for my hardware by someone else. Get my drift.
As has been mentioned before MPE is not all written in C and in order to
make it universal it (the source) will either have to be translated into a
universal language, I will let you pick, or the compiler will have to be
written for each hardware platform.
One of the things that made PC cheaper and cheaper was the fact of Windows
and standards. Which allowed drivers and code to be written without the
worry of the hardware. But I had the opportunity to run NT on a Dec system
with their Risc chip. There was differenct things that had to be done then
was done on a Intel machine.
So the long and short of it emulation is good if you have no alternatives
but running true is best and preferable for longevity. Why pay $$$ for a
high speed chip and not be able to get your money's worth.

James

-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]]On
Behalf Of Russ Smith
Sent: Wednesday, March 06, 2002 9:39 PM
To: [log in to unmask]
Subject: [HP3000-L] OpenMPE IA64 port (was HP full page ad...)


Wayne writes

> My gut feel is that if/when OpenMPE gets the source code, there will be a
> movement in the future to port the code to newer hardware at some point.
> This may be 5 or 10 years down the road but since the hardware world won't
> hold still somehow the software will need to keep up.  We need to be able
to
> create MPE/iX 8.0 and other future versions anyway in order to continue
> enhancing MPE (regardless of emulator!).

Before going to the trouble of changing the software to keep up with the
hardware, we should decide whether or not we want to keep up with the
hardware.  My recommendation: enhance the software/application components
and let someone else deal with the hardware side.

From a couple of emails I passed back and forth with Jeff, and lurking
around a series of discussions on portability, my understanding is that
HP/CSY, had they wanted to, COULD have ported MPE to IA64, but recognized
that the scale of the undertaking was a bad use of limited resources (more
so after the EOL date had been estimated/set).  I would argue that in the
post November 14th world, that point is moot unless the "new owners" of MPE
want to fight what is now probably an unwinable battle.

OpenMPE shouldn't spend limited resources to port MPE to IA64, either.  We
couldn't get HP to market the 3000 with MPE/IMAGE as a total solution the
way IBM is marketing the zSeries line with DB2, so continuing to spend time
and money on MPE as an operating system playing catchup with the next group
of peripherals is also a waste of time.  Nor should OpenMPE market the
platform/OS/application package that way either, because we can't outgun Big
Blue.  IBM is marketing a midsize server family with embedded DBMS, bells
and whistles (which we know they developed from their need for a product to
compete with the 3000), but HP is telling its clients to get off MPE, and
OpenMPE is not going to have the clout to argue the point.

If we want to keep MPE, then MPE needs to evolve past the reasons that CSY
made the decision to drop it.  MPE should become, for all intents and
purposes, a highly standard application meant to be platform independent,
but probably aimed at Linux.  The hardware interfaces should either become
someone else's headache, or be limited to a series of drivers for specific
default hardware, and customers can have the option to pay for the
development of drivers they want.  Making an MPE emulator that is platform
independent makes the most sense, and this means that OpenMPE's first
version of MPE (9.0?, if CSY makes an 8.0) will have independence as its
major selling point.  Then what we're developing is an application that
pretends to be the operating environment (with its included products like
IMAGE), and the people needed to maintain it are split into (a) twenty
somethings writing drivers to communicate with new peripherals and make the
emulator think it's talking to DATs and SCSI_disks, and (b) a few MPE gurus
who can enhance MPE's components to the user's requests, all paid for by a
scaled back version of the suppor dollars clients used to pay HP for MPE
support.

If I open my QCTerm or Reflections window and say "connect to ip X, port Y",
does it matter if I'm connecting to an HPe3000 via VT or a Telnet listener
job, or a *nix box running an MPE emulator and routing messages to it?
Think about it.  This is no different than opening a browser and pointing it
to an address that starts a script running on a webserver somewhere.  I'm
running an application that communicates with a machine running an
application (web listener) which, depending on my responses and keystrokes,
starts and runs other "sub" applications.

A multiple high speed processor, WINTEL server running linux, with an MPE
emulator would be cheap to buy, support, and maintain, but we still have CI,
IMAGE, etc.  My applications run as they did before, and can be easily
modified, and enhanced, all WITHIN the emulator environment.  Development of
new code to run inside the MPE emulator is done just as new page scripts are
written in ASP or XML to run on a webserver processing scripts for remotely
connected users.

What we view now as the operating system becomes drastically easier to
support and enhance.  We no longer have to worry about supporting new
hardware within MPE, rather the drivers for them are part of the linux shell
around the MPE emulator application.  MPE enhancments are limited to
improvements to its components (IMAGE, etc), and "sub" applications (what
the ISV's are selling that requires the HPe3000 now).

Even if the number of customers shrank going forward, the current selling
point is still that existing mission critical applications being run by
current MPE users are "ported" with nothing more than some backup and
restore strategy.  And, the support dollars for the "MPE Application" can be
spent more heavily on IMAGE, SQL, compilers, etc., rather than on dealing
with the new hardware component that Vendor X is making.  Additionally, we
can still push to users around the world an encapsulated development and
production environment that does not interfere with the operating system
(think a winapp flaking and taking the entire box with it), that has built
in security and recovery, and that comes with a unique and relentless
support community (you know..."us").  The emulator might evolve to be its
own middleware, and users wouldn't need an ODBC job running inside the
emulator to communicate with the java process running on the same linux box,
etc.

The money for OpenMPE, then, comes from the clients who purchase the MPE
Application, and who pay an annual support cost to get upgrades.  Patching
might not be necessary because it is now an application: just get the new
version.  Run it on another box to test it with your applications, and then
"install" it on the production box with the emulator down.

Anyone want to the first to say "Russ, you're full of crap"?

Just my $.0194 (2 cents, adjusted for after hours trading),
Rs~

Russ Smith
Systems Analyst, Cal State 9 Credit Union, Concord CA, rsmith AT
calstate9.comm
Programmer/Analyst, Problem Solved, Vacaville CA, rsmith AT cu-help.comm
3000L/SU-Talk participant, work AT rsmith.orgg

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

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