I would like to point some things which add
some additional reality to the discussions
on this thread. Not to dissuade anyone from
pursuing these ideas, but to make sure everyone
is thinking about the true effort(s).

* There is a big issue with mpe applications
  with regard to the file system. In mpe you
  have files that can be different types and
  based on the type you get different/specialized
  behavior. Emulating this on Linux with little
  or no source code change might be a challenge.
  But, Linux does support different file systems
  so an interprising individual could implement
  a complete mpe file system. Also, consider that
  without a complete mpe file system you don't have
  basic things we take for granted like FILE EQUATIONS.

* Currently the cobol compilers that are robust
  enough for recompile migrations of mpe apps
  are purchased by developer and deployed with
  run-time charges (per simultaneous execution of
  cobol code). The compile most are looking at is
  AcuCobol which is finishing up a hp3ek port.
  This compiler is an interpreter and doesn't currently
  generate native instructions (except for Sun UltraSparc).

* Even though mpe provides a core set of functionality
  a lot of shops have chosen to use additional 3'rd
  party tools. Some for job management, some for
  report management and some for data management.
  Migrating a package like Amisys might require
  additional migration efforts for any tools that
  application depends upon. Some of these tools are
  using internal knowledge of mpe and its file system
  to work. For example, lots of applications depend
  upon Suprtool. What would you do if wasn't available?

* Some vendors have already wrapped mpe like features into
  their applications so they could run on hp-ux. Maybe it
  would be a good idea to find these solutions and see if
  they would be a good starting point or maybe even a solution
  for those that want a more painless migration.


Wishing everyone the best during this holiday/migration season :-)

Duane Percox    wk: 650.372.0200x608  fax: 650.372.3386
[log in to unmask]
www.qss.com
qwebs.qss.com


> -----Original Message-----
> From: Terry Warns [mailto:[log in to unmask]]
> Sent: Wednesday, December 12, 2001 7:17 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] A possible roadmap to Open MPE
>
>
> 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 *
>

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