Rich,
let me take the opportunity of this problem and try to summarize my view of this problem:
Doing OpenVMS support during the last 3 decades, I have come to the conclusion,
that everything being done by OpenVMS Engineering has been done for a reason.
While I don't remember ever seeing the OpenVMS patch strategy being publicly or
even internally documented, here is my perception of this strategy:
- OpenVMS patches are always cumulative. This rule applies to both individual facility patches (e.g. VMS83I_SYS-Vnn00) and the UPDATE patches. Each facility patch kit in itself must be cumulative.
- Once an image or procedure had been included in a facility patch kit, it needs to be included in all future versions of this facility patch kit, even if no further changes have been done to this image.
- The release notes of a patch describe the problems solved or functionality added by this specific version of the patch.
- Because of the cumulative nature of OpenVMS patches, all release notes of the previous patches for this facility (e.g. SYS or SHADOWING etc.) are included in each patch. This makes sure, that you get a description of ALL problems fixed in this patch (and it's predecessors) for this facility.
- OpenVMS UPDATE patches are just a consolidation of all current facility patches combined into one patch kit. This makes patching OpenVMS easier by having to just install one UPDATE kit instead of multiple facility patches.
- OpenVMS UPDATE are not allowed to contain any changes, that are not available as individual facility patch kits
- OpenVMS UPDATE patches include all bits and pieces of the most recent versions of all individual facility patches, including the release notes of all previous versions of those facility patches as described in the patch release note chapter 5 (example from VMS732_UPDATE-V1700):
Note that OpenVMS Patch kits are cumlative and that they contain all changes that have been released in earlier versions of the kit.
The issues addressed by these kits can be found in the following
Release Notes files after the VMS732_UPDATE-V1700 kit is installed:
o [SYSHLP]VMS732_ACC-V0100.RELEASE_NOTES
o [SYSHLP]VMS732_ACRTL-V0100.RELEASE_NOTES
o [SYSHLP]VMS732_ACRTL-V0200.RELEASE_NOTES
...
- OpenVMS UPDATE kits releases were being projected in the MASTER_ECO_LISTs since a couple of years. This allowed customers for planning ahead to reserve the required downtime for UPDATE patch installations.
- After starting with the 3-month release cycle for the UPDATE kits, new facility patches 'required' the current UPDATE as a pre-requisite, but this changed very soon based on customer feedback. Dependencies of new facility patches on previous UPDATE patches have been 'relaxed', whenever technically possible (Example: VMS732_AUDRSV-V0400 released 22-FEB-2007 did not require VMS732_UPDATE-V0900 released 7-DEC-2006, but could be installed against VMS732_UPDATE-V0800 released 14-SEP-2006). This feature had been implemented based on feedback by customers, allowing them to install urgent individual facility patches without having to install a bigger and newer UPDATE kit at the same time. OpenVMS customers are typically very serious about change management and stability of their systems.
- OpenVMS patches should never be re-released without incrementing the version number. Exceptions have been seen when non-critical kit contents has been changed (like correcting checksum or updating release notes). The reasons for those changes were usually being documented in the MASTER_ECO_LIST.
- In the past, a group of people in the CSC in Colorado Springs have been doing their own patch verification of the patches released by OpenVMS Engineering. This additional testing seems to have been abandoned.
- One of the early examples of this problem is the VMS831H1I_SYS-V0400 kit (released 9-JUL-2009), which is missing IO_ROUTINES present in VMS831H1I_SYS-V0300 (released 4-DEC-2008) and previous versions of the VMS831H1I_SYS kit. This violates the rule, that each individual facility patch kit in itself must be cumulative.
By requiring VMS831H1I_UPDATE-V0600 to be installed before VMS831H1I_SYS-V0400, the IO_ROUTINES from VMS831H1I_SYS-V0300 are being installed on the system, but this is not following the OpenVMS patch rule of 'cumulative' patches. This is some kind of 'shortcut' and not without risks. If all facility patches are cumulative in themselves and UPDATE patches are just a consolidation of facility patches, such a problem jsut cannot happen.
This list may not be complete and most likely does not cover all rules for the
OpenVMS patch strategy, but it is an attempt to summarize the most important
topics learned over time.
This is a very clean and straightforward design. Taking 'shortcuts', like with
the VMS83A_SYS-V1200 kit by taking images out of this kit and only providing
them in a required UPDATE kit, does not follow these rules and creates
unnecessary confusion and concerns within the OpenVMS community, as can clearly
be seen.
Volker.
