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 *