How many people work in CSY (what does it stand for?), would it really not
make sence for someone to offer to buy the MPE business lock stock and
barrel from HP, like a management buyout with financial/commitment backing
from all the major third party people, Bradmark, Quest, Roc etc. who stand
to look a great chunk of their revenues anyway after 2006

I know that HP have made a business decision to move out of the MPE arena
because the spend outweigh the revenues, but a smaller leaner company with a
(shock horror) Marketing department could make this work - look at how well
the AS400 is doing!

With such a loyal following of customers I'm sure that you could build up a
very impressive list of reference sites many mission critical and push
MPE/3000 for it's real use - 24/7 uptime and proper TPS.

I understand from vendors that you require a box which is 2.5x the
performance to get the same Power rating under unix than MPE, so if this
jolly bunch in CSY where there own company they could just keep modifying
the HAL of MPE to run on what ever the HPUX hardware was at the time, buy
the boxes from HP sans unix and sell to the customer inc. MPE, HP still gets
hardware sales/support (which seems to be the business they want to be in)
and customers get a quality system to boot.

Just my 2p, may have been discussed before but I've not seen it

Comments are mine and not my employers dar di dar

ps. Before you all shoot me down, I've got 5 '3000's and will be buying a
6th next week (second hand) so I've got as much to lose as everyone else.

Regards

Peter Martin
IT Operations Manager
Initial Electronic Security
t. 01254 291413
f. 01254 267549
e. [log in to unmask]
----- Original Message -----
From: "Jerry Fochtman" <[log in to unmask]>
To: <[log in to unmask]>
Sent: Friday, October 04, 2002 3:06 PM
Subject: Re: MPE source (was: POSIX on MPE)


> At 08:25 PM 10/3/02 -0500, Chuck Ryan wrote:
> >Um Jeff, you do know that some of us are actually programmers that do
have
> >some small idea of what is involved in maintaining and enhancing old
code?
>
> Certainly!  However, do keep in mind that working in systems-level code,
> hardware/driver, etc. at kernal level can be a bit more complex than
> managing a COBOL/COGNOS application.  I stand by my earlier statement that
> there are at best, only a small handful of folks outside of HP that
> have the skill and breath of knowledge to handle many areas in the OS.
> This is not to say that others can't learn those skills given enough
> time and experience.  Only that today's pool of skilled resources can
> probably be counted on 2 hands...maybe only 1 hand....  And clearly it
> would require collaboration among them, as no one individual can keep
> up to date on everything.
>
> Certainly there is a wider pool of resources when it comes to things
> such as EDITOR, FCOPY and similar tools.
>
>
>
> >The repeated statements made by you and others at CSY have led me to
expect
> >a mass of undocumented hacks and quick fixes that will be no small
challenge
> >to work with. Which is why I think rolling back to a version before the
> >large number of appeasement changes might provide the most stable code
base.
>
> What makes you think that rolling back to some prior version would be any
> different?  And if doing that causes you to lose the re-designs of things
> needed in say storage mgmt, hardware drivers, etc. that are dependent on
> changes that one deems as quick fixes, how does this loss of newer
hardware
> tied to these changes benefit those moving forward on MPE?
>
> Given 7.5 will probably be the last platform release, coupled with the
> next 3-4 years of support/patches for problems that arise, I would
> think that by HP's EOL stability should not be a problem.  There simply
> is no comparison of this against the loss of functionality, size,
hardware,
> etc. by taking some fairly large step backwards.  And because of the
> inter-dependency in the code, unwinding some changes have very broad
> impact.  For example, if you wanted to back-out large files (128Gb) for
> stability, you'd also impact >3Gb memory because all of virtual storage
> mgmt was re-designed as a part of making it to large files.  This would
> downsize the number of current processes/users, and on and on.  And
> at the same time the I/O architecture was changed to support PCI, so
> moving prior to large files results in possibly losing this and some of
> the hardware items.  Loss of them would mean people would have to go
> back to some older hardware which is no longer manufactured.
>
> Nope, I would oppose going backwards, it would be way too painful and
> have tremendous impact in MPE.