John Penney writes:

[snip]
>It is interesting to note that DG had a 32 bit 'supermini'
>8 years before HP did. Fat lot of good it did them.
[snip]

Another good reason to remember that it isn't the technology.

It's how you package it, the market forces at the time,
and whether anyone is willing to buy your solution.

Hard work, luck and good fortune, go hand in hand.

I bet if you search the history you will find that HP was
the *last* vendor with a 16-bit solution to deliver a
32-bit general purpose system.

So, what allowed them to keep the HPe3000 around for so long when
almost all the other's were either cancelled or the company went
out of business?

I would offer these tidbits of opinion:

* The unique feature-set of MPE was not easily duplicated on other
  systems so migrating off a 16-bit MPE to a 32-bit whatever was not
  that easy.

* A 16-bit MPE running business database applications was equal to other
  vendor 32-bit offerings because MPE, COBOL, and Image were finely tuned
  to deliver quite a punch on the slower hardware.

* The typical HP customer for the HPe3000 has been more interested in
  practical, working solutions than the latest glitzy tech-mag solution.

* On average, HPe3000 customers are by nature more conservative, move
  slower in their technology adoption, and reward stability and loyalty.

Well then, if after delivering a really nice 32-bit MPE, did the HPe3000
have to suffer the same fate as other similar systems?

Once again, I offer some tidbits of opinion:

* Computing performance reached a point where it was now possible to get
  similar db performance as Image using SQL RDBMS systems therefore reducing
  and/or eliminating a key differentiator.

* Business applications now being written in other languages besides COBOL
and
  these languages are available and execute nicely on lower priced commodity
  hardware platforms.

* Newer ways of providing business solutions (application architecture) that
  perform better on non-MPE operating systems. Java, web-based, etc.

* Cheaper total solutions (non-MPE) that are 'good enough' and make MPE
irrelevant in
  the minds of those choosing what platforms to support.

Well, if HP has always been interested in customer investment protection,
then why
did they abandon the HPe3000 and make us all migrate to other solutions?

And finally, I offer some totally off the wall ideas, as opinion:

* HP is a for-profit company and their ability to invest in any line of
  business is going to be based on the potential returns for that
investment.
  Sometimes that means hard choices have to be made.

* All HP supported operating systems are required to play together in their
  Itanium and Adaptive Enterprise strategy. The cost to get MPE to that
point
  was probably too high.

* HP doesn't need MPE to sell systems. HP is making a ton of money selling
  cell-based systems (Superdome, mid-range rx) that have hardware partioning
  (nPars) that allow for full electrical isolation of components and can
  run hp-ux, windows, linux, (and soon openvms), all at the same time, in
different
  partitions. Customers love this type of solution and aren't demanding MPE
before
  they buy.

* The marketplace is demanding flexibility, adaptability, and lower cost.
MPE
  is not very flexible, adaptable, nor is it anywhere near low cost.

So why does OpenVMS survive. Doesn't it have the same problems as MPE when
it
comes to supporting Itanium and the HP Adaptive Enterprise strategy?

In case, you thought I was all answered out, here is more opinion:

* OpenVMS is written in c, while MPE is primarily pascal (and legacy spl).

* The OpenVMS port to Itanium was started well before the HP/Compaq merger.

* I bet the OpenVMS team has access to all the source code they might need
  for porting, while that might not be the case for MPE.

* OpenVMS is the home of amazing clustering technology, which also made it
  to tru64. While tru64 doesn't survive, the clustering will live on, being
  ported to hp-ux. OpenVMS for Itanium is already ahead of the game when it
  comes to supporting an Adaptive Enterprise strategy.

duane percox

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