> I totally agree with this.  For MPE to go to new HP/Intel architecture
> is a massive investment.  If you want this, you need to get the MPE lab
> moving NOW.  The problem for CSY is: making a business case for it.
>
> Rick Ehrhart
> [log in to unmask]                     408-553-3776
>
 
Warning: this is long
 
What I'm going to say isn't new, but sometimes the obvious needs to be said.
Belief in the business requirement for what MPE offers is the most important
issue.  Also, I acknowledge borrowing from others that have commented in this
thread.  So, here is my Vision thing on MPE: essentially a new O.S.  with
MPE's traditional strenghts in DBMS, a backwards compatibility layer, and
leveraging HPUX subsystem code and device drivers. The business case is simply
the requirement for solid, reliable, scalable, transction processing.
 
The strongest benefit of MPE is the DBMS platform, Image/sql and Allbase, in
conjunction with the stability and reliability of MPE and the hardware, with
low cost of operations and administration.  Along with this, continued
backward compatibility is a must - even if it requires a compatibility layer,
but conversion for "native" performance.  The future of MPE depends, it seems
to me, on the business case for these basic benefits.
 
MPE is *the* solid, stable, scalable transaction DBMS processor - with all
the performance and reliability benefits of a single vendor solution.  CSY
really should aim investment at enhancing this most basic functionality.  The
formula for success might be redesigning Image to be as flexibile as the
typical RDBMS, while retaining the traditional, but enhanced, intrinsic layer
access.  Take the Image/sql layer and integrate it more tightly and
automatically with native Image structures.  Integrated capability for an
object-oriented method layer connected to the data would also be a good
addition.  Transform Image/sql from a legacy, out-of-date DBMS to a state of
the art, object oriented transaction processor, without losing backward
compatibility for applications.  HP would have to provide basic data
communications, of course, and good interfaces for others to use for
new technologies.  Cooperative work with 3rd parties would (continue
to) provide other needs - as long as reliability testing included these
components.
 
The business case would have to combine migration for installed base with a
market for new business.  That means identification of market segments that
would best benefit from MPE style performance and reliability, matched with
suitably agressive marketing to win new business.  Some of these would be
Mainframe replacement in the face of 21st century date change-driven process
re-engineering, back-end processing for the growing Web business transactions
(with a Java and/or cgi web support layer), upgrading AS/400 and VMS sites
that still need the single vendor solution, upgrading Unix sites that are
unhappy with UNix, etc.  This is quite a market, it seems to me.  Can Unix
and "open" solutions ever provide the same benefits?
 
HP would have to keep the risks of choosing MPE low.  The cost of software
development for MPE must be low, but the results highly reliable.  I would
think that some creative use of HPUX for cross-platform development, with MPE
systems for testing might be a possibility.  HP would have to attract
best-in-class software developers whose customers need highly scalable,
reliable, transaction performance.  In addition, it would help to have an
education marketing program to place development machines in universities and
encourage Computer Science departments to incorporate them into DBMS courses.
 
Another requirement is probably to leverage HPUX systems and application work
as much as possible, without losing MPE's strengths in file system, security,
etc.  Perhaps a structure like underlying MPE (rewritten) kernal, file
system, DBMS integrated closely with the file system, but, as much as
practical, with "bolt-on" support for HPUX subsystems and device drivers?
Might it be practical for the new MPE to "be" unix on the api level (whatever
spec 1170 is now called)?
 
HP might need to adopt a new name for the rewritten MPE, with "backward
compatiblity for hp3000 MPE customers" - to achieve market penetration - maybe
a new model name (HP3999?).
 
Microsoft has amply demonstrated the business success for the inverse of MPE,
namely, the we will pay for new features in a mostly easier to use interface,
even when we have to reboot regularly. We will live will reliability problems
to have new features and window dressing, as well as, improving (usually)
interfaces. The business case for MPE would have to demonstrate just the
reverse - there is strength in stability and reliability that customers are
more than willing to pay for, even when you don't get every new feature and
function or support for every device the comes along that day it comes out.
HOwever, you must get timely updates to meeting changing business needs -
particularly flexibility on the application front end.
 
At the time of it's original drafting, MPE defined a new level of
friendliness and usability in mini computers.  A new design that aims at
reaching this again within the tranditional strengths of MPE would be the
best, most sellable solution of all.  If it is easy to learn and use, there
will be less concern for the cost of choosing MPE by new customers.  Perhaps
a WindowsNT and a CDE based GUI for using, administering, and operating MPE,
including the integrated DBMS subsystem, would be the way to go, along with a
Pearl (or ?) backend for batch processing.  This would add to the business
case -> ease of use, with scalabiity for power users.
 
Cheers,
Richard
 
--
-- - - - Speaking for myself and not necessarily anybody else - - - - - -
Richard Gambrell        | Internet: [log in to unmask]
Mgr. Tech. Services     | POT:      504-483-7454     FAX: 504-482-1561
Xavier University of LA | Smail:    7325 Palmetto, New Orleans, LA 70125