HP3000-L Archives

January 1999, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Thomas Madigan <[log in to unmask]>
Reply To:
Thomas Madigan <[log in to unmask]>
Date:
Wed, 13 Jan 1999 10:03:34 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (82 lines)
X-no-Archive:yes

I'll tell you what scares the hell outta' me is upgrading 3rd party
software.  It gives me the willies at least by a factor of 10 over
upgrading MPE itself.  HP generally provides step-by-step instructions on
doing an OS upgrade and, if you follow them BY THE BOOK, chances are that
you'll have a successful upgrade.  I won't repeat the other advice on
upgrading I've read in this thread -- they're all worthwhile suggestions!

Third party vendors are a different story altogether.  I once did an
upgrade to a (unnamed!) vendor's package dutifully following all of their
"instructions" to the letter ... did all of the database conversions ...
converted custom programming, etc. to the new database structure.  (BTW,
this was a Y2K-compliant upgrade, no less!)  OK -- all's well that ends
well.  As Tim the Tool Man says, "Whoa!! Back the DAT drive up!"  Not quite
so well!  The users were now TWO WEEKS into the new software and I was
1,000 miles away on a training seminar.  Capital BUMMER!  Our users
rightfully were unwilling to give up all that data entry and maintenance
effort so that we could temporarily drop back to the old stuff.  To boot,
the database conversion routine hosed up some older data that we had in
that D/B for years.

We discovered that, besides the hastily-tested conversion routine, the
vendor's code was compiled in the wrong order, XLs were missing critical
subprograms and a (no pun intended) host of other problems.  Needless to
say, it took almost an entire DP staff plus outside consulting PLUS about a
month of 24 X 7 effort to unravel the whole mess.

And the moral of the story is:  NEVER, NEVER, BUT NEVER, ACCEPT A VENDOR'S
UPGRADE ON BLIND FAITH ALONE.  Always re-create the production environment
in a test account, install the upgrade there and test the HADES out of it.
Don't contemplate doing the upgrade just before peak production time (in
our case, we were in a "Catch 22" -- we had to do the upgrade in order to
install the vendor's "latest and greatest" which had required functionality
we needed).  Last, but not least, don't go out of town right after you do
the upgrade or you might find your employment status drastically altered
when you return!!

Tom Madigan
Beautiful SE Pennsylvania

"My opinions are strictly my own.  Who else would want 'em?"

Richard Gambrell after Brad Feazell:

>Brad Feazell wrote:
>
>> Our HP3000s are more stable and generally perform better than our UNIX
>> servers. However, when it comes to updates, we can do a room full of UNIX
>> boxes in the time it takes to a 3000 - without the associated fear.
>
>   Well, I don't know what Unix your referring too, but I must disagree from
>my personal experience. HP-UX patch updates aren't always bad (however, often
>they are bad - particularly the bundled patch sets), but major O.S. upgrades
>(8 to 9, 9 to 10, 10.1 to 10.2) are always, always a major problem. The last
>one I was involved in is the first time I've ever had to go home and rest
>before returning to round up another day of working on making the update work
>- and we even had an HP SE there to do it!!!
>
>   MPE updates are much more dependable - at least you can get autoinst and
>patch/ix to run, which is more than I can say for swinstall! Every MPE update
>I've done has worked out just fine with only a little messing around. HPUX
>updates always seem to involve major screwups.
>
>  Everything I said about being prepared for MPE updates goes triple for HPUX
>updates - like don't forget to read through all the little "readme" manuals
>for every product new release for HPUX to catch the incompatibilities you'll
>run into - and you always seem to run into them.
>
>>
>> --
>> Brad Feazell
>
>--
>Richard Gambrell
>Database Administrator and Consultant to Computing Services
>University of Tennessee at Chattanooga, Dept. 4454
>113 Hunter Hall, 615 McCallie Ave. Chattanooga, TN 37403-2598
>UTC e-mail: [log in to unmask]   phone: 423-755-4551
>Home e-mail: [log in to unmask]
>

ATOM RSS1 RSS2