The following contains the OpenVMS Patch FAQ

First, a few links to related topics:

• If you are reading this article looking to directly patch — hex edit or binary edit — a file on OpenVMS, read PATCH Tips: How to use PATCH /ABSOLUTE.
• If you're here reading and looking to learn more about how to use PCSI or VMSINSTAL to install patches, read OpenVMS Software Installation Tools: PCSI and VMSINSTAL.
• As for the OpenVMS FAQ, that's here.

The following text was derived from a comp.os.vms posting by George Pagliarulo. (Mr Pagliarulo is responsible for the ECO release processes within OpenVMS Sustaining Engineering, Hewlett-Packard Company.) A few typos have been corrected, and the materials have been slightly reworded and slightly reformatted for the web by HoffmanLabs.

Pronouns referenced here are to HP and to Mr Pagliarulo, unless otherwise noted.

The text has been re-posted here with permission of Mr Pagliarulo.

When installing multiple kits, do I need to reboot after each one is installed?

If multiple kits that require reboot are being installed, a reboot is not required after each installation. All kits can be installed and then one reboot done. However, all kits must be installed at the same time, either with one command or sequentially. In other words, do not install a reboot required kit, wait a day, install the next one and then reboot. Not rebooting after the installation of kits that require a reboot may result in system instability. The release notes included with each kit and posted on the patch download sites state whether or not a kit requires a reboot.

How can I get notified of kit releases?

Released kits are announced via HP's Subscriber's Choice. Customers can get more information on and sign up for Subscriber's Choice by clicking on “subscribe to patch digests” under the “useful links” sidebar on the ITRC patch download page.

Customers can also sign up for OpenVMS patch announcements and related customer advisories at www.OpenVMS.org by subscribing to the OpenVMS.org Alerts mailing list.

Where can I get OpenVMS patch kits?

Patches for all supported versions of OpenVMS are available via HTML at www.itrc.hp.com and via anonymous FTP at ftp.itrc.hp.com.

How do I install the ZIPEXE patch kit file?

Once downloaded, run the self-extracting ZIPEXE file which will extract the binary patch kit. The resulting PCSI$COMPRESSED patch kit can then be installed with the PRODUCT INSTALL command.

How can I get the patch kit release notes?

The PCSI command PRODUCT EXTRACT RELEASE_NOTES patch_kit_name will extract the release notes from the kit. See HELP PRODUCT for more information on PCSI commands.

Can patch lists in the UPDATE kits and master lists say which kits were not in the previous UPDATE kit?

Absolutely, good idea. What I will do on future UPDATE kits is to add an asterisk to the patch kit name if that patch was not in the previous UPDATE kit.

Why are there still UPDATE kits for V7.3-2?

At the time the VMS732_UPDATE-V1100 kit came out, the official plans were to make that the last UPDATE kit for V7.3-2. As it turned out, it was later decided that was not the best decision for our customers and another UPDATE kit was planned. That's about the state of V7.3-2 UPDATE kits now — when the time comes to start producing the next round of UPDATE kits we'll decide if we should do another one for V7.3-2.

Personally, at some point UPDATE kits for V7.3-2 will stop — but I don't see it happening for the next year. (My opinion, not official policy).

Why are UPDATE kits required kits?

First, a little history here. We often send out patch kits that have dependencies on other patch kits. Before UPDATE kits , these dependencies, over time, would get unmanageable — Kit A requires Kit B, Kit B does not require kit A but Kit B does require Kit C which now, since Kit A requires Kit B, it also now indirectly requires Kit C but that's not documented but.....you get the idea.

UPDATE kits were started as a way to set a new patch baseline and eliminate all those dependencies. To accomplish this, once an UPDATE kit ships it becomes a required kit for any patch kit that is produced after the release of the UPDATE kit.

There is one caveat — when we started regularly scheduled releases of UPDATE kits we changed the requirement policy. Now, patch kits that require a reboot will require the latest UPDATE kit. Patch kits that do not require a reboot will require the UPDATE kit released before the latest kit. This is to try and help customers avoid an unnecessary reboot if they haven't yet installed the latest UPDATE kit.

Why can't UPDATE kits only install what has not yet been installed with individual patch kits?

The UPDATE kits set a baseline patch level. Without installing everything in the UPDATE kit we really have no assurance that the baseline has been set. With that said, two things were mentioned — marking the database that an image has already been installed.

As has been mentioned, forget it, it's too difficult from an engineering standpoint. You are talking a major rewrite of the PCSI facility. It's not that it is difficult, there is not enough payback for such an investment of resources. The other option is to do something within the patch itself. I actually built a test UPDATE kit that checked to see what had already been installed and did not reinstall those images. I installed it on a system with no previous patches and on a system with all the previous patches installed. I purposely used a version (I think it was V7.3-2) that had a lot of patches against it; my expectation being that there would be a significant reduction in installation time.

There was almost none and for that reason and because of the baseline thing, I abandoned this idea.

What patches are included in UPDATE kits?

UPDATE kits only ship patch kits that have been released and in the field for some time. They do not ship anything new. The length of time is dependent on the complexity of the patch kit. If an UPDATE kit has a functional problem with an included image that requires us to pull the kit, what we will do is pull the kit and remove the offending patch kit and re-issue the UPDATE kit; not add a new fix to the UPDATE kit and re-issue it.

How does PCSI manage images and image generations?

If a patch kit is contains an image that is the same or a newer generation than the image generation present from a previously-installed patch kit, the image from the patch kit will be installed. If the image in the new kit is older, the image in the new kit will not be installed; the newer generation already on the target system will be preserved.

PCSI stores, maintains and tracks generation information for DCL procedures and other objects within the PCSI database. The image headers serve as secondary and parallel storage of this generation information.

If PCSI has no way of determining the generation of the currently-installed object — should the image on the system be an engineering test image or a DCL command procedure and does not or cannot have the needed image generation data stored in the image header — the object in the patch kit will be installed, overwriting the existing object. (This existing object is assumed to be an older generation.)

There is a warning in the patch documentation about this behavior.

Use caution when installing a PCSI kit over a recently-acquired patch image. If you are not certain of the compatibility, check with your support contact to ensure the fix is (also) included within the particular PCSI kit before installing the PCSI kit.