Jon,

great, that you start this discussion!

We (CSC) are running the European HP e3000 platform for DuPont. DuPont
still has main functions of their Order Fullfillment Process / incl. Order
Entry on HP-MPE, and some businesses will not migrate to SAP R/3 now (but
all are forced to do so so that unfortunately the end of MPE for DuPont may
come in 3 to 5 years :-(
I am the responsible engineer to run those servers in Europe, and I'm
linked to a Global CSC Team offering services for other customers in the
U.S.

I have some experiences in the update area and I like to comment on this.

1. When I started on this professional level I had to step into a
colleague's project where he planned to upgrade to a more powerful system
for the sake of a consolidation project (migrating all small servers across
Europe to one site to a 995 class). To keep the dates we had to go to the
1st PULL release of 5.0 (which only supported this server type) - and I
NEVER will do a similiar in the future ! We had one backdating, several
days of total loss - an experience I hope nobody will have ! From this date
on we install new releases
* only if the end of the support of the previous is announced,
* short before this date so that PP 1 or 2 will be available,
* if there are reasons to do so like Y2K or H/W support.
So we started with 5.5 PP2 and stayed up to PP7, started with 6.0 PP2 up to
???, and will now wait for 7.0 PP# and definetly not go to 6.5. This
process is validated with our HP contact (we have a CSS contract), and for
us this is the prooven way since the 5.0 "desaster".

2. On the other hand I'm one of the system managers hoping that other HP
customers will detect the problems before we do ...
DuPont's home-written applications use EVERYTHING what is possible, and in
a lot of System Aborts (but number is fortunately decreasing since 5.5 PP5)
we hear from HP's CRC and the lab:            YOU'RE the 1st (or 2nd) with
this problem. YOU reached a corner-case.
or similiar comments pointing to the fact that we used the 2% of the OS
which has not been tested under production conditions ... Well, now I
accept this ... but this is the reason why I do not want to detect EVERY
problem by installing early in the life-time of a release.

3. The worst case is: FTP which is crucial important for us to communicate
business data across platforms (HP-UX, AIX, MVS, VMS) is always BUGGY - and
here we often encounter problems which has been solved in the previous
release by a patch but is again (or similiar) present in the following
release. This is not really acceptable.
Also 6.0 FTP under INETD creates problems for us which are not yet solved.
We have a total unsupported workaround in place: run FTP 5.5 ....

That's my remarks in generell, here my answers:

   o  What makes you decide to go up onto a newer release?
end of support of previous one, technical necessity (like Y2K or newer H/W
support), existance of power patch

   o  Which Powerpatch (first, second, third, ...?) is the appropriate
       one to "Push"?  What criteria should HP use to determine which
       Powerpatch is the "Push"?
hard to answer. If ALL customers will wait for PP2 who will test the base
system under real production conditions ? HP can not have the same S/W
portfolio / variety like all the HP e3000 customers.
We will not go for PULL releases; for PUSH we wait for PP1 or PP2.

   o  Should we "Push" at all?  Would you prefer simply to receive the
       Communicator once we come out with a release, and you can decide
       whether you want it?
If HP stays on support for the previous releases that will be great! In
this case the customer could decide on his needs whether he will update or
not. Y2K was an example: IF I need to stay without date problems I had to
go to 5.5.  A/N class is the next good example: if I want to have A or N I
need to have 7.0.
We updated to 6.0 only because of the fact that 5.5 has reached
end-of-support. The new functionality in 6.0 was not essentially needed,
and 5.5 was pretty stable. The good thing was: 5.5 PP7 was close to 6.0 PP1
(and the number of SAs (1) prooves this! We want to stay as long as
possible on a STABLE release!

   o  Once you get up onto a particular release, how long do you want to
       stay there?
see above: as long as possible (technical H/W and functional S/W, support).

   o  What is your expectation concerning the availability of new
       functionality or enhancements on your current release?
patches should be enough. Of course not possible for IA64 when the
architecture will be changed ... but 5.5 was a good example that Y2K was
introduced by patches.


Hope that will answer your questions (and raise some more discussion on
this topic),

best regards,
Andreas Schmidt
CSC Global Infrastructure Services, Global Processing Engineering Services
D-61352 Bad Homburg, DuPont-Strasse 1, Room 1-346, Germany
Phone: +49 (0) 6172 / 87-2117 Fax -2195  DUCOM x951-2117
eMail: [log in to unmask]