Patch installations

[Alon Jacob]

Labadie - what did you mean by "culprit file"?

Thanks.

[Uwe Zessin]

'culprit file' is the file that is responsible for the problem. Changing the name makes the previous version available unless you have deleted this one already.

[Andy Bustamante]

How about having a patch recalled by Engineering the morning after you installed it? No I didn't roll back, but I watched that system closely until the fixup came out. One of the "SYSxx" patches for 7.2-1 broke Pathworks as I recall. I knew that from comp.os.vms where the problem was posted with a work around.

My in house rules include not installing anything that hasn't been out for a least 4 weeks, 6 months for an o/s upgrade. My first internal system was upgraded to 7.3-2 last week. We test on internal systems before allowing any patch or upgrade near a production site. The only issue I've ever seen in a production site, was with ZIP/UNZIP after upgrading from 7.1 to 7.2-1. There was an upgraded release and I've since added ZIP/UNZIP to to testing. Internally I bundle and test ECOs into internal levels. Our core application hasn't seen any problems with VMS upgrades.

[Doug Phillips]

I've experienced about as many problems from *not* patching as from patching. Now, my S.O.P. is to wait at least one year before upgrading VMS after a new version appears and read the patch release notes on-line as they come out.

The 7.3-2 batch of patches is growing so rapidly that it's hard to keep up with them, and if I remember, there are around 10 reboots required if one follows the instructions (not counting layered products)!

I *really* wish that HP would publish a patch sequence list that tells what patches can be installed together and in which sequence without a reboot.

The UPDATE kit seems to be setup like this, because many of the patches said "reboot required" before they were bundled into one kit, and not all of those do a reboot (IIRC). But when there are 12 or more "kits not included in update kit", and 8 of them ask for reboot... that's a lot of (expletive deleted;-) reboots!

Doug

[Wim Van den Wyngaert]

I have a GS160 interbuilding cluster running very sophisticated software (using tcp, x25, decnet, X) and all is written inhouse. It is handling stock exchange orders in real time and keeps this banks situation in memory (the new applic needs a lot more power for doing less). If I patch and TCP is not working in the same way, or there is a small memory leak, or whatever, my head is cut off.
And testing the application is almost impossible.

So I'm especially interested in problems that caused application failures (by preference even unrunable).

Wim

[Jan van den Ende]

Wim,
if I project my experience (V7.3-1 => V7.3-2) into your description of your situation, then I WOULD invest the effort of re-linking your apps.
_MOST_ of ours apps were just fine, but:
We have one bundle of 5 interacting applics.
4 of them worked fine, also together. #5 ACCVIO'd. After re-linking #5 that one functioned, but #1 did not communicate with it (2,3,4 DID!). Re-link #1, then that communicated nicely with #5, but NOT with 2 anymore!. Re-link #2, and we are back in business (note: #3 & #4 were NOT re-linked).
Historic detail:
#5 originally linked under VMS 7.1; #1 under V7.1-2, #2 under V7.1-2, #3 under V7.2-1.
So far looks consistent, but.. #4 under V6.2!!!
No real basis for trustworthy guidelines there eigther.
Bottom line:
Wanna be on the safe side? Re-link!

hth.

Jan

[Lawrence Czlapinski]

1. I do UPDATE patch, non-reboot patches, then reboot patches with instability patches last.
Then I do one reboot.
2. EDIT/TPU problem during patch updates: If using EDIT/TPU from a console manager window or OPA0:, be sure your window size is 24 lines. Otherwise the changes on the screen often don't match what you're actually changing.

[Willem Grooters]

"If it ain't broke, don't fix it."

If your software relies on non-documented features, internal structures that are not normally accesable using system services or system variables - you ARE required to re-link, eventually re-compile your software. You, and your programmers should know that this is the case.

Caution is Ok, HP should be more aware of the implications and test the software and installations more thoroughly (and re-do some engineering (I mean: porting) since I think that introduced quite some problems)

Anyway: consider the update-procedure I have used for a critical system for years:

1. Keep your system disk as clean as possible. You should need a small one only.
2. Be sure to have multiple, identical backup copies of your system disk (a relatively small (cheap)disk will normally be sufficient).
3. Boot your system from such a copy.
4. Now do the update, reboot (from that disk) if required.
5. Run your application(s) and determine whether all works as expected.
6. If it does, let the system run for some time monitoring all processes, and if no problem is found, promote that to be the system disk.
First, make multiple image copies of that disk, store them in a safe place. If your original system disk is a shadow set, create one now of the NEW one. Then, when in a cluster, reboot the other node(s) (one by one).
If there are problems, revert to original system disk and reboot from that one. To solve the problems, you need a second system, boot that from the updated disk to analyze and fix the problem(s). (you could do that on this machine, of course)

At the time, a one-day period with average load and access was enough to tackle any problems. We only had minor ones one time, that were solved by re-linking part of the application.
However, be aware that when autogen is run after upgrade, you may have to run over a longer period and under heavier load, to get new feedback. Then run autogen again and reboot.

HTH

Willem

[Wim Van den Wyngaert]

Willem,

We have the problem that to relink an application you need an owner. And that one is missing. If you relink it yourself, you become the owner. And that's the last thing I want : owner of some complicated, undocumented system.

We have programs linked under 6.2 in 1997 running on 7.3. Luckely without problems. Also : applications refuse to take relinked programs into production. And no manager that forces them to do so ...

The migration of 6.2 to 7.3 has costed at least 1000 mandays ...

Wim

[Jan van den Ende]

Wim,


The migration of 6.2 to 7.3 has costed at least 1000 mandays ...


And the generated extra cost of the business not going smoothly!


And no manager that forces them to do so ...


Is there NO way to use quote1 to get anyone in the chain of upwards managers to become aware of the real validity of your requests, and the risks of ignoring them?

I thought I knew about irresposible managers, but you are setting a new standard!

Probably all you are left with now is 'cover your ass' with a heavy load of memo's pointing out the risks (and repeat that until at least one of them gets annoyed enough to respond in a way that PROVES they HAVE received your warning.

But it remains sad that these things keep happening, time and time again, at all levels...

I think all that is left now is to wish you strength (& luck)

Jan