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 *