Richard wrote:

The real deal and work is in the integration, licensing negotiations, and
central control over future directions, plus, the thorny technical parts of
making this work.


Thank you Richard.

 Richard and I are in agreement.  I look at my five clients running on MPE.
I estimate that to rewrite their apps to UNIX/ORACLE or NT/SQL would cost
them between $10 million and $20 million.  3 of the clients are Amisys.
They spent millions in conversion, testing, configuration to get where they
are today.  If they had to do it over again, it would cost the same. On top
of that they are making major investments to satisfy HPPA requirements.

MPE/Linux is a doable solution that would minimize the migration issue.

The most difficult technical point will be running native mode and
compatibility mode on MPE/Linux.  Most people have their source code due to
recent Y2K projects.  I know for each of my clients, this is not an issue.

Compare rewriting your app vs. recompiling your app and the decision is a no
brainier.  Compare redoing database structure vs. unloading your database
and reloading your database and the decision is a no brainier.

Also I look at MPE/Linux purely from an application interface point of view.
From an application point of view, it does not matter if MPE/ix does i/o
differently from MPE/Linux.   MPE/ix may accomplish tasks differently from
MPE/Linux, but the end result should be the same.

In addition, this project should be an MPE users initiative rather than a
particular vendor's sole solution.  A vendor needs to make a profit.  And as
users we run the risk that a solution will be put to death without regard to
the end user community.  So the MPE/Linux organization should be owned by
the users of MPE/Linux where vendors are a viable part of that organization.
In fact, I envision vendors doing most of the work and being compensated
accordingly.

But should a profit making organization fail to continue to support their
portion of the solution, the MPE/Linux organization can pick up the source,
documentation, etc and continue the solution to the benefit of the entire
community.

The issue about MPE/Linux reliability should not be an issue.  Any rewrite
or migration solution will not be as reliable as MPE/ix.  To hold MPE/Linux
to that standard may be a future goal, but to expect that standard in the
near term is unrealistic.

If this is a roadmap to OPEN MPE, what should be our next step?

Terry Warns

--

"Richard Gambrell" <[log in to unmask]> wrote in message
news:9v7hv8010eo@enews1.newsguy.com...
> 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 *
>

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