Apply several patches with only one reboot

[Jeroen Bleeker_2]

We have a two node OpenVMS cluster (shared systemdisk) with V7.2-1. We want to apply 14 patches, and most of them needs a reboot. This is what i intent to do:
- shut down the cluster
- make a system-disc backup
- boot one node with most applications not started
- apply all the patches
- reboot
- boot the second node.

I couldn't find anywhere in the HP manuals that you can apply several patches with only one reboot. I think it can because for example the kit VMS721_UPDATE-V0300 has many updates included.
I attached the patches i want to install and also a list of the current patches / software.

Greetings,
Jeroen Bleeker

[Wim Van den Wyngaert]

Don't know where it is documented (if it is)but I've done it several times without any problem.

Wim

[Bojan Nemec]

Jeroen,

Usualy I check all the dependencies of each patch and sort them in different directories.
In the first directory I put the patches which are not dependant of any ather in the second patches which depends on patches from the first directory and so on.
Then I install from the first to the last directory with:

$ SET DEF [.1]
$ PRODUCT INSTALL *
REBOOT if needed
$ SET DEF [.2]
$ PRODUCT INSTALL *
REBOOT if needed
and so on

Bojan

[Arch_Muthiah]

Hi,

Compaq recommmends cluster reboot for each patch to take effect clusterwide. If it is not possible or convenient to reboot the entire cluster at this time, a rolling re-boot may be performed.

Archunan

[Ian Miller.]

I install the patches then do one reboot at the end. The exception is for PCSI update kits where I install them and logout/in then continue.

Note that
$ PRODUCT INSTALL *
creates one set of undo data so you have to uninstall all of them
$ PRODUCT INSTALL a
$ PRODUCT INSTALL b
and so on
creates one set for each patch.

PCSI is supposed to sort out the depenency stuff for you and mostly it does except when somebody gets the generation numbers wrong.

[Vladimir Fabecic]

I applied them one by one from the oldest patch to newer ones. Did it many times with no problem.
But, what Bojan said, must check if some patches dependant of any other.
Also machine must not be heavy loaded. Best is when you are alone on the system and no applications running

[Robert_Boyd]

When I install the PCSI patch kit I usually don't bother with logout/login like Ian does.

I found from testing that usually it is sufficient to do a

$ SET COMMAND/TABLE=SYS$SHARE:DCLTABLES

This refreshes the command definitions and incorporates the changes delivered by the PCSI kit.

As others have mentioned, I partition the patch kits into separate directories for the ones that MUST be done before others, the ones that depend on the first set, and the ones that do not depend on other patches into another directory.

I have not had any problems with applying multiple patch kits before rebooting by following this practice.

Robert

[Jan van den Ende]

Jeroen,

we do much like others already wrote.

When some reason warrants the effort, we collect all patches since the last.
Skip those less than a month (some issue may not yet have been found; happened before, will happen again).
Check for dependencies (cf Bojan).
Clear one node of the cluster of all users and batches (ie, do not allow new users to that node, and move batches to another node).
Perform all patches in one go; if all goes well (usually, but not guaranteed), we reboot that node.
Move users and batches of off another node, and reboot.
Repeat for all nodes.

Has worked for us everytime.

Success.

Proost.

Have one on me.

jpe

[Lawrence Czlapinski]

Jeroen, We normally only do one reboot for VMS OS patches. We maintain a DCL procedure with the PCSI patch listed first but usually commented out.Then we do latest UPDATE patch, patches that don't require reboot and patches that require reboot. If there is a dependency we make a note of that and do that patch before the ones that depend on it.
We do the patches that are most likely to cause system instability last.
We then copy the procedure and comment out any patches that have already been updated.
We do a
$SET HOST/LOG=UPGRADES_DIR:logfile_name.log1 0
We login from SYSTEM account
$SET DEF upgrades_dir
$@PATCH-ALP732_2005-mm-dd_NR.COM (if only no reboot patches)
or
$@PATCH-ALP732_2005-mm-dd.COM (for all patches)
$LO
Then we reboot. We usually don't have any problems with the updates because of doing one reboot. We have had problems with specific updates which would have occurred any way.
Lawrence

[Thomas Ritter]

Almost all our our patch work is done using batch jobs running under the system account.

Where possible a reboot is done after the last patch. Performed a VMS 7.3-1 to 7.3-2 upgrade in this manner.


Extract

$!
$ PROD INSTALL VMS732_UPDATE/PRODUCER=DEC/BASE=AXPVMS/VER=V3.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_SYS/PRODUCER=DEC/BASE=AXPVMS/VER=V7.0/SAVE_RECOVERY_DATA
$!
$ PROD INSTALL VMS732_DRIVER/PRODUCER=DEC/BASE=AXPVMS/VER=V1.0/SAVE_RECOVERY_DATA
$!

Then reboot.

We have spare system disks. If we need to backout we shutdown and boot off a copy of the before patched system disk. Only ever needed to do this once.

Summary: have spare system disks, use batch mode where possbile. Always have a backout plan.

Thomas.

[Jeroen Bleeker_2]

Thanks for the many responses. I'm now more certain to apply the patches with only one reboot.
Still one question regarding the respons from Ian:

"PCSI is supposed to sort out the depenency stuff for you and mostly it does except when somebody gets the generation numbers wrong"

What do you exactly mean with "Generation numbers" ?

Greetings,
Jeroen Bleeker

[David B Sneddon · Accepted solution]

Jeroen,

Each "object" within a kit should have a generation
number (think version number).
The higher the number the later the "object" version.
Only the highest numbered version should ever be
installed when the kit is installed.
If the kit generation and the currently installed
generation are the same, then the kit version will
be re-installed.
You can list the generation numbers using the
PRODUCT SHOW OBJECT command.

Dave.

[Ian Miller.]

hp specify generation numbers for each file. Just occationally they have been known to get them wrong and issue a newer file with a lower generation number.

[Wim Van den Wyngaert]

John Gillings patch overview used to contain the correct date for each file. I used to transfer that page to VMS and run a script that compared the dates on that page with the actual installed files. This way, I was sure that all files were correctly installed.

Just a pitty that hp.au stopped supporting the page.

Btw : never encounter faulty files. But I did find a difference between an upgrade and a fresh install (no details were kept, sorry).

Wim

[comarow]

At the center whave seen many disks ruined without doing the intermediate reboots.
It's the luck of the draw.

A shortcut is to put $exit at the start of Sy_startup_vms.com so the reboots take longer.

It's quicker than restoring a system disk.
This is especially true when updates are involved.

YMMV but you are taking a big chance.

[Jeroen Bleeker_2]

The reply Comarow gave surprises me. Seems he's the only one that has had problems applying several patches with only one reboot.
I agree with him that putting an exit in systartup_vms.com prevents a full boot and would speed up applying patches, when after each patch/update (which requires a reboot) a reboot is performed.
I would like that HP had a clear statement regarding this. Maybe if they where asked they would advise to reboot after each patch/update, i think...

[Willem Grooters]

Comarows problem may be related to his environment; that may be the reason he's the only one that had these problems; it may be related to a particular patch. BTW: Disks can be ruined for a number of reasons and not only by updating the system.

I ususally do a number of update at a time, cheching dates and releasenotes first. The patch process will take care of dependencies, normallly there is no trouble at all. I'm reluctant however to do the update in batch. I did run into bad files once and was quite happy to run it interactively. If you keep up-to-date frequently, the time required for applying patches is limited. But of course, that does not apply to all environments.

[Jess Goodman]

I have a command procedure in which I just list all the necessary patches in the order I want them to be installed. The procedure checks if a patch has already been installed, so you can just add new patches to the end of the list. Since we have many system disks I needed to automate patch installation as much as possible. Rebooting after every patch on every system disk in our 24x7 shop just isn't feasable.

Mr. Boyd's comment about using:
$ SET COMMAND/TABLE=SYS$SHARE:DCLTABLES
after applying the PCSI kit is correct. Occasionally another kit will also require this action (or logging out and back in) before installing anything else. For example if one kit adds a new qualifier to the BACKUP, COPY, or SET coomands you could get an error like:
%CLI-F-SYNTAX, error parsing 'BLOCK_SIZE'
-CLI-E-ENTNF, specified entity not found in command tables

One pet peeve of mine is that when it comes to upgrades and patches VMS engineering assumes that the only CLI tables in use at any site is DCLTABLES.EXE, even though an alternate CLI table is supported by AUTHORIZE.

As an added layer of security we use three different CLI tables. DCLTABLES has everything in it but is used only by our IT staff. A second CLI table is used by the rest of our staff - it doesn't have verb definitions for compilers and system administration utilities. Our clients use a very limitted CLI table - we even edit individual verb defintions to take out keyword options we want to restrict (such as removing the SET_COMMAND syntax from SET.CLD).

Anyway, maintaining our customized CLI tables would be a lot easier if there was an option to save off any new or modified .CLD files contained in kits.

[Robert_Boyd]

Jess,

Try this:

$ directory sys$update:*.cld

You may be surprised to find just what you are looking for if you're running on V7.3-2.

Robert

[Anton van Ruitenbeek]

Bojan wrote
> $ SET DEF [.1]
> $ PRODUCT INSTALL *
> REBOOT if needed
> $ SET DEF [.2]
> $ PRODUCT INSTALL *
> REBOOT if needed
> and so on

A product will always be installed on SYS$COMMON: unless you specify /destination .
To change the default doesn't change anything.
The best thing in a multi-node cluster with (I hope) a single system-disk is to make sure there are no users on one node (most of the time this can be aranged by the DNS-server) and install the products and reboot. Wait for the users to login on the newly booted system and no users on the other node. Reboot the other node. Jan his method. The only thing when you got possible difficulties is when you are upgrading OpenVMS. If you make sure your systemdisk is HBVS, this will be a piece of cake. It than can be done on the same way without downtime for users !

AvR