This is the approach I had been favoring at first, building a
"MPE" linux distribution, but this is not completely incompatible
with the enulation approach.  Viewed in ths context, an emulator
would only need to be available for the application binaries, not
the full MPE o.s. There is already a HPUX emulator for binaries on
IA-64 (running inside HPUX on IA-64), so this might not be so very
difficult for the MPE distribution of Linux running on IA-64.  Also,
there are vendors that already have major pieces of the components
Terry includes below, so some of the  puzzle is already done and in
use, so it would not all be as "raw" as you might thing.  The real
deal and work is in the integration, licensing negotitions, and
central control over future directions, plus, the thorny technical
parts of making this work.

You have to think about what's under the hood.  MPE i/o and
priority handling is all port of the o.s. and my guess would be
that it is not easily replaced by Linux.  The semantics are just too
different and MPE expects a lot more control. There is a need
for some very serious hard work to cover this problem and it is
similar to more complex parts of doing the full emulator.

Terry's approach might be a good evolution of the emulator approach,
to bring more "native" performance to the MPE emulation.

Let's also keep in mind that MPE on HPUX might be easier and more
likely to support the interest (and thus get the help) of HP.
This would be a stepping stone to greater independence, since
it would adapt MPE in ways that would make it easy to move to Linux
later.

Richard

Terry Warns wrote:
>
> Group,
>
> Let me try to expand a little of how I see Wirt's idea to be implemented
> without using the emulation word.   The base reason we like MPE is it is a
> set of expectations that are met consistently.  Some of this is in certain
> pieces of software that our applications interface directly such as IMAGE
> and VPLUS.  Others are the portability, reliability issues.
>
> We know that MPE support on PA-RISC is doomed. So each of us has to look as
> to what the best possible solution there is. So if there are 5,000 of us, we
> have 5,000 different solutions.  Where in MPE, decisions have been made for
> us in Job management, Database Management, Terminal interface, Spooling, etc
> and we deal with one vendor to provide those things.  In Linux, we deal with
> many vendors to provide those things.  Where  there was somebody who
> integrated those features into one package, all of sudden that falls on to
> me.
>
> I would propose that instead of trying a large binary emulation, we instead
> choose a set of vendors to support an MPE operating environment.  Vendor A
> would do B, Vendor C would do D.  NCSY would search out, negotiate the best
> deals with all these vendors and when they add up the sum of their parts, we
> have an MPE environment.  Now NCSY starts an integration testing of all
> these parts to see that they work together.  At some point this integration
> will be release as a package for Beta testing.  Now other vendors and some
> users start testing their software.  At some point this becomes a release
> x.0.  Now more users start using it.  Eventually it becomes stable and is
> put into final release where it sticks around for x years.  This different
> phases can overlap where the next Beta is being testing while the current
> x.0 is being released.  NCSY provides a known environment and known
> expectations.
>
> For most HP3000 installations knowing this testing and retesting is being
> done, is very very valuable service.
>
> As an example, let me take IMAGE as to where that could go.  I see one of
> four possible solutions.
>
> 1.  A new rewrite from scratch
> 2.  A IMAGE API on top of a SQL DB (already done)
> 3.  A modification to an existing DB (Possible)
> 4.  HP Eloquence from Germany enhancement
>
> I do not know which is the best or the final solution.
>
> If we approached an existing DB vendor to make a modification, the cost
> might be borne by them if it is not difficult and they see they can get
> 5,000 new customers.  (I think this may be the case)
>
> So as each important area is addressed in MPE, the solution could take
> different approaches.  Let me give another example.  Backups.
>
> Let say our requirement for a backup solution is that it take either
> Turbostore's tape or their own tape run on PA-RISC and restore the files
> appropriately into MPE name space.  Are there products today that run on
> both MPE and Linux in the backup arena? Yes.  There is a solution that
> solves a problem, that emulation is not needed.
>
> Now we take the best of the solutions,  fill in any gaps ourselves and we
> have a MPE solution working within Linux OS.  This is Linux as any other
> Linux solution.
>
> Now let's look at it from a application vendor point of view.  I will take
> Amisys for instance.  This is probably the cheapest method they can
> anticipate to migrate their users to Linux.  A Rewrite of a new database,
> new JCL, new COBOL, etc would prove costly.  They tried it and it was not
> successful.  This would be successful.  I would think that application
> vendors in the 3000 world would accept this.  If not they would have to do
> it on their own anyway.
>
> I think this method will result in the following:
>
> 1.  Smoother migration for existing HP3000's
> 2.  Hardware independence
> 3.  Better licensing agreements than 1 on 1
> 4.  Better testing of an operating environment
>
> Do we have binary compatibility?  Probably not, we will need to recompile.
> Are there any languages not supported?  Maybe but COBOL and C and Fortran
> are supported by someone.
>
> Is this less costly than building from scratch - By far.
>
> Is this less reliable than current MPE - probably, but if you want to move
> forward, any solution is.  But due to the integration testing it will be
> more reliable than build your own.
>
> I suggest that the modification that I am making to Wirt's proposal is let
> see how close we can get to an MPE operating environment before we write
> emulators.
>
> I like to apply the 80/20 rule.  We can get 80% for 20% of the dollars.  But
> one more iteration of the 80/20 rule states we can get 96% for 36% of the
> dollars.  The question is Is that 4% worth 64% of the dollars?
>
> Also remember, many vendors would like to pick up 5,000 new users.  If we
> work together we can have a much greater impact on any solution than working
> separately.
>
> Thank you for your time.
>
> Terry Warns
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *


--
Richard L Gambrell, Senior Information Technology Consultant and
Director of Computing Systems and Networks
Information Technology Division, University of Tennessee at Chattanooga
Fax: 423-755-4150                Support Help-Desk: 423-755-4000
Direct phone: 423-755-5316       ITD Business Office: 423-757-1755
Mobile (urgent): 423-432-5122    Main UTC: 423-755-4111
Email: [log in to unmask]

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