This horse may not make it back to the barn for hay... I feel it may be
dead. ;)
Hopefully no one looked in it's mouth... no... wait... that's a gift horse
i'm thinking of.
David Gibbs
<david@xxxxxxxxxx
om> To
Sent by: Midrange Systems Technical
midrange-l-bounce Discussion
s@xxxxxxxxxxxx <midrange-l@xxxxxxxxxxxx>
cc
07/24/2007 02:18 Subject
PM Customers vs. ISV (was: New
redpaper)
Please respond to
Midrange Systems
Technical
Discussion
<midrange-l@midra
nge.com>
Lukas Beeler wrote:
Then how do you explain the 8 days of downtime the company I used to
work for experienced when trying to upgrade our CISC system to a RISC
system?
I don't know. But what I do know is that it is entirely possible to
avoid those 8 days of downtime.
I can tell you that, absolutely positively, you are WRONG. My manager
and I did *EVERYTHING* we were supposed to. The disk vendor lied to us
(ok, partially our fault, we went with non IBM disk).
The cheap variant: Roll back if it doesn't work within half the allotted
upgrade timeframe.
Sorry, Lukas, you really can't speak with authority on this ... you have
no idea what our situation was. There was no cheap or simple variant.
Once we started the upgrade we were committed.
Luckily we were able to get IBM involved and do very low level traces on
the system to identify the drive, platter, cylinder, and head, that was
generating the error. It was only then we got the disk vendor to fess
up and give us a free disk upgrade (same capacity, newer hardware).
You should kick the Windows Admin. 50 Desktops and no software
deployment solution?
And that solved the problem how? My friends was a consultant, brought
in to upgrade this package ... and the customer only had a part time
system administrator (backups, change paper in the printer, do routine
maintenance on PC's when required).
If you system is running fine, your application isn't dependent on new
functionality in later OS400 versions, and you hardware support is
being
handled by a 3rd party vendor, what's the driving need to upgrade?
The _POSSIBILITY_ of getting unforeseen consequences if you don't.
I've observed that the main thing that causes problems in stable systems
is change. If an application is running fine in V5R1, and IBM doesn't
support it anymore, and there isn't any need for change, the main thing
that WILL cause problems is change.
But they should hit them with the cluestick whenever they have
the opportunity.
That's a very easy way to loose customers.
As I said before ... I work for an tools vendor ... requirements of a
development tool does not (and should not) dictate what OS400 version is
used (within reason). Especially when there are downstream
ramifications (i.e., the customer is a ISV themselves ... and has their
own release level requirements).
david
p.s. I think this horse pulling this thread has gotten enough beating
... perhaps we let it go back to barn for some hay?
--
System i ... for when you can't afford to be out of business
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
