2 Patch Management Utility

This chapter introduces you to the dupatch utility for installing, removing, and managing patches. It also provides information you must be aware of when installing patches.

2.1 Overview of dupatch

All official Tru64 UNIX and TCR patches are installed, removed, and managed through the setld-based patch management utility dupatch. Because dupatch manages patch interdependencies, direct setld installations and deinstallations (setld -l -d) are disabled.

Directions for enabling or disabling patches are provided after the successful installation or removal of all selected patches (for example, kernel rebuild and system reboot).

The dupatch utility is a command line interface that provides you with menus that step you though the various tasks. With dupatch, you can perform the following actions:

Install and remove all or selected patches.

View the patch-specific documentation.

View patch tracking and management information.

Establish a baseline for systems that had manually installed system files placed on them.

The dupatch utility captures patching activities in the following log files:

/var/adm/patch/log/session.log
Every time you run dupatch it creates a session log that captures dupatch activities is created. Up to 25 copies of the session log are saved. The order is first in, first out -- with session.log.25 as the oldest file.

/var/adm/patch/log/Dupatch_load_Date.log
When you run dupatch from the newly untarred kit or from the mounted Tru64 UNIX Patch CD-ROM, dupatch determines if the patch distribution contains new patch tools, and loads them if necessary.
This log file would have a name similar to this: Dupatch_load_2000Feb1:15:43:35.log

/var/adm/patch/log/baseline.log
When you run the system baselining feature, dupatch creates a baseline log. Up to 25 copies of the baseline log are saved. The order is first in, first out -- with baseline.log.25 as the oldest file.

When patches are installed or removed, an event log that captures installation and removal information is created. It is located in /var/adm/patch/log/event.log. Only one copy of the file is updated each time patches are installed or removed.

The dupatch utility also manages the system inventory for Tru64 UNIX and TCR patches. This enables patch tracking and management of patch activity such as:

Tracking current dupatch-installed patches.

Ensuring correct handling of customized system configuration files so that customizations are not lost (for example, conf.c). These files are also referred to as system-protected files (.new..).

Validating patch applicability to existing system files (collision detection).

2.2 Patch Installation and Removal

Patch installation and removal is accomplished through the dupatch utility. For patch installation and removal dupatch manages the following:

Patch applicability

Patch dependencies

Patch reversibility

System inventory changes for patches

Capturing patch activities in log files

2.2.1 Patch Applicability

Patch applicability to the existing system files is done on a file-by-file basis for each patch. This ensures that the installation of a patch will not degrade or crash the system. The installation of a patch is blocked if any system files to be replaced by a patch are not valid predecessors of the patch files.

Patch applicability also enables consistency checking and reporting for the installation of Tru64 UNIX and TCR patches.

In all cases where a patch is blocked, informative messages are provided to assist you in determining how to proceed. Chapter 6 lists common error messages and suggested corrective actions.

The installation of a patch is blocked if any of the following conditions exist:

The underlying software product subset is not installed. For example if the applicable Tru64 UNIX or TCR release subset is not installed.

The setld inventory is inconsistent with the existing system files. This occurs when an operating system or TCR setld subset is installed and individual operating system files that are part of that subset are moved, deleted, or replaced.

Any of the existing system files (files that are targeted to be updated by a patch) have changed and cannot be related to previous versions of the patch. This ensures that operating system files that change due to other explicit system administrator action (for example, layered product or customer-specific patch installations) are not inadvertently overwritten. You must take special action, through the baseline feature, to enable patch installation in this situation.

2.2.2 Patch Dependency Management

Selective patch installation and removal is allowed in the Tru64 UNIX and TCR patch kits. When patches are selectively chosen, dupatch provides warning messages regarding other dependent patches requiring installation or removal for correct system operation.

The dupatch utility manages the dependencies between patches within each product patch kit and across product patch kits. For example, dupatch manages the following kinds of dependencies when patches on systems where both Version 4.0D and TCR1.5 are installed or removed:

Patch dependencies within a product patch kit
If, for example, you choose to install DIGITAL UNIX 4.0D Patch 1.00 and it depends upon DIGITAL UNIX 4.0D Patch 5.00, which is not already installed or chosen for installation, the dupatch preinstallation check will warn you of the dependency and prevent the installation of DIGITAL UNIX 4.0D Patch 1.00.
If the patch selections are reversed, dupatch will warn you and prevent installation of the chosen patch.

Patch dependencies across product patch kits
If, for example, choose to install DIGITAL UNIX 4.0D Patch 1.00 and it depends upon TruCluster 1.5 Patch 17.00, which is not already installed or chosen for installation, the dupatch preinstallation check will warn you of the dependency and prevent the installation of the DIGITAL UNIX 4.0D Patch 1.00.
If the patch selections are reversed, dupatch will warn you and prevent installation of the chosen patch.

Note

Even though selective patch installation capabilities exist, Compaq recommends that you install all patches in each kit for Tru64 UNIX and TCR to prevent the occurrence of known and corrected software problems.

2.2.3 Patch Reversibility

Enabling patch reversibility during patch installation allows you to revert the system to its state prior to the installation of a particular patch.

By default, the reversibility installation option is set to enable reversibility for patches. If you choose to make patch subsets nonreversible, then those patches will become nonremovable upon the successful installation of those patches.

Patch reversibility is dependent upon saving the existing system files that will be updated by the patch. Saving these files requires the availability of adequate storage space in /var/adm/patch/backup, which can be a mount point for a separate disk partition, an NFS mount point, or a symbolic link to another file system. This allows you to configure your system to reduce the impact on system disk space for the /, /usr, and /var partitions.

To further reduce the storage space required to save existing system files, the patch kits for Tru64 UNIX and TCR save the files in a compressed tar image for each patch. Tru64 UNIX Version 4.n releases do this with the gzip utility. This results in a file with a name like filename.tar.gz.

The dupatch utility checks for the required storage space prior to patch installation. Patch installation is prevented if adequate backup space is unavailable.

2.2.4 Patch Installation and Removal Event Log

Patch installation and removal activities are logged in the patch event log located in /var/adm/patch/log/event.log. The information in the patch event log is not yet available through the dupatch user interface. However, the file is plain text and can be viewed manually.

The following list describes the types of information an event log provides, although the format and content are subject to change. Example 2-1 shows a typical event log.

DUPATCH_REV>	The revision of `dupatch` being used
TYPE>	The type of action that was taken; either install or remove
NAME>	The name entered by user through a `dupatch` query
USER>	the name of the user performing the action
NOTES>	Notes that were entered by the user through a `dupatch` query
KITLOC>	The directory from which the patch kit was installed
KITNAME>	The name of the patch kit that was installed
REVERT>	The choice made on whether or not the patch installation is reversible
BACKUP_DIRECTORY>	A pointer to the directory that contains the original files before they were patched
BACKUP_SETUP>	A plain directory; not a mount point or a symbolic link
SUCCEED>	A list of patches for which the action succeeded
FAIL>	A list of patches for which the action failed

Example 2-1: Sample Event Log

<RECORD>
DUPATCH_REV>26-03
TYPE>install
NAME>msmith
USER>msmith
DATE>Fri Feb 4 13:03:33 EST 2000
NOTES>Install BL13 patches from CD-ROM
>
KITLOC>/cdrom/Digital_UNIX_V4.0F/patch_kit/DIGITAL_UNIX_V4.0F/kit
KITNAME><DUV40FAS0002-19991116> OSF440
REVERT>Y
BACKUP_DIRECTORY>//var/adm/patch/backup
BACKUP_SETUP>
SUCCEED>OSFPAT00001900440

2.3 Viewing Patch Documentation

The dupatch utility allows you to view the patch documentation for installed patches and for the patches available from a specified patch kit. This documentation includes the following:

Patch summaries
These summarize the problems corrected by the patches. You can view the problems corrected by installed patches or by patches available from a specific kit.

Patch README files
These files provide complete descriptions of the problems corrected by the individual patches. You can view the problem descriptions for installed patches or for patches available from a specific kit.

Patch Special Instructions
These files describe special instructions you need to be aware of for individual patches. You can view the instructions for installed patches or for patches available from a specific kit.

2.4 Viewing Patch Tracking Information

The dupatch utility allows you to view the following patch installation and removal information:

List of dupatch-installed patches on the system

DIGITAL UNIX Patch Utility (Rev. 26-03) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Patch Tracking Menu: -------------------- 1) List installed patches 2) List installed patch files 3) List patch kit information on installed patches b) Back to Main Menu q) Quit Enter your choice: 1 Patches installed on the system: ------------------------------- (depending upon the number of patches you installed, this may take a while) - DIGITAL_UNIX_V4.0D / Commands, Shells, & Utility Patches: Patch 0101.01 - dd Command Correction Patch 0207.00 - named, screend Correction (SSRT0296U) Patch 0208.00 - uucp Command Correction (SSRT0296U) - DIGITAL_UNIX_V4.0D / Filesystem Patches: Patch 0157.01 - Filesystem, Vmstat, And IO Device Corrections - DIGITAL_UNIX_V4.0D / Network Patches: Patch 0060.01 - Token Ring Transmission Timeout Correction Patch 0531.00 - Token Ring Transmission Timeout Correction - DIGITAL_UNIX_V4.0D / Security Related Patches: Patch 0049.01 - Security, sendmail (SSRT0421U) Patch 0136.01 - libc Corrections, Security (SSRT0425U),(SSRT0296U) Press RETURN to get back to the Patch Tracking Menu...

List of patched files on the system

DIGITAL UNIX Patch Utility (Rev. 26-03) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Patch Tracking Menu: ------------------- 1) List installed patches 2) List installed patch files 3) List patch kit information on installed patches b) Back to Main Menu q) Quit Enter your choice: 2 The list of all patched files on your system: -------------------------------------------- (depending upon the number of patches you installed, this may take a while) ./sbin/dd (DIGITAL_UNIX_V4.0D Patch 0101.01) ./sbin/ls (DIGITAL_UNIX_V4.0D Patch 0136.01) ./sbin/mount (DIGITAL_UNIX_V4.0D Patch 0136.01) ./sbin/ufs_fsck (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sbin/umount (DIGITAL_UNIX_V4.0D Patch 0136.01) ./shlib/libc.so (DIGITAL_UNIX_V4.0D Patch 0136.01) ./shlib/libc_r.so (DIGITAL_UNIX_V4.0D Patch 0136.01) ./sys/BINARY/arch_alpha.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/arch_alphapmap.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/cam.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/cam_disk.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/cam_isp1020.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/cam_sim.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/ether.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/ffm_fs.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/inet.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/loop.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/nfs.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/presto.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/procfs.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) ./sys/BINARY/re_xcr.mod (DIGITAL_UNIX_V4.0D Patch 0157.01) Press RETURN to get back to the Patch Tracking Menu...

List of patch kit information on installed patches

DIGITAL UNIX Patch Utility (Rev. 26-03) ========================== - This dupatch session is logged in /var/adm/patch/log/session.log Patch Tracking Menu: ------------------- 1) List installed patches 2) List installed patch files 3) List patch kit information on installed patches b) Back to Main Menu q) Quit Enter your choice: 3 Patches installed on the system came from following patch kits: -------------------------------------------------------------- - Patches for Digital UNIX V4.0D (DUV40DAS00002-19980808,08-Aug-1998:15:02:19) - Patches for TruClusters V1.5 (DUV40DAS00002-19980808,08-Aug-1998:15:02:19) NOTE When a patch kit is listed, it does not necessarily mean all patches on that kit are installed on your system. Press RETURN to get back to the Patch Tracking Menu...

If no patches are installed on the system, you will receive a message similar to the following:

There are no patches installed on your system.

2.5 Handling Manually Installed System Files with Baselining

The dupatch utility adheres to installation conflict management rules that prevent it from installing patches when the system files have been changed through manual installation methods.

System files with unknown origins can result from the following:

Manually installing customer-specific patches

Replacing Tru64 UNIX commands and utilities with system administrator customized versions or freeware versions of those commands or utilities

Moving files between various systems

Missing system files result from a root user manually deleting system files that were installed via setld. The file is removed but the system inventory records are still in place.

The dupatch baselining feature allows you to enable dupatch to override the collision detection mechanisms so it will selectively install patches over system files that are unknown or missing. It is important that you understand the origin of the changed system files prior to enabling dupatch to overwrite them through patch installation.

For example, a file whose origin is unknown may be part of a manually installed customer-specific patch which is not contained in the current official patch kit. Allowing dupatch to overwrite one file of a customer-specific patch will leave your operating system software environment in an inconsistent and nonoperational state.

Caution

Enabling dupatch baselining to update your system sets a new baseline for your operating system or TCR software environments. You will not be able to revert to the previous system state for manually installed patches that were marked as installed by baselining. Compaq recommends that you backup your /, /usr, and /var file systems before enabling system updates through dupatch baselining.

When you run the dupatch system baseline feature, a baseline log file is captured in /var/adm/patch/log/baseline.log. Up to 25 copies of the baseline log are saved. The order is first in, first out -- with baseline.log.25 as the oldest file.

Manually installed system customizations will block patch installation until corrective action is taken and you enable dupatch to override the installation conflict mechanisms.

You need to set the patch baseline for your system if you have manually installed system files or if dupatch informs you that patch installation is blocked by system files that are missing or unknown.

Baselining is divided into five phases that provide system information and optionally allow you to take actions that change the patch baseline of your system. You can run through all phases of baselining to get the system analysis without enabling changes to your system.

You can run baselining in multiuser mode when you are the root user.

2.5.1 Phase 1 - System Evaluation

The primary goal of Phase 1 is to evaluate your system relative to the patch kit that is being installed. However, the baselining feature will report all missing and unknown files to assist you in better understanding the state of the changed files on the system.

The rest of the baselining phases use the information gathered in Phase 1 to inform you of any installation conflicts for patches contained in the patch kit.

The amount of time needed to evaluate the state of the system varies greatly depending on the size of the patch kit, the version of the software product, and the performance of the system.

2.5.2 Phase 2 - Patch Layered Product Conflicts

Phase 2 reports information for patches whose installation is blocked by system files that were installed by layered products.

Baselining will not override layered product patch installation collision detection mechanisms as it is likely that the layered product or application customizations are not contained in the patch. Installation of the patch in this situation would render the layered product or application nonoperational.

To resolve this situation contact your layered product or application Customer Services or Compaq Services if you have purchased Business Critical Services.

2.5.3 Phase 3 - Identifying Manually Installed Patches

Phase 3 reports patches that exactly match existing files on your system that are not marked as installed by the system inventory. For example, in earlier kits, TCR official patches were installed manually. This phase will report any manually installed official patch files that exactly match a patch contained in the current dupatch-based TCR patch kit.

You can optionally enable dupatch to mark these patches as installed, which involves copying valid setld database information to your system. The dupatch utility will copy the appropriate patch_subset.inv, patch_subset.scp, and patch_subset.ctrl files into place for these patches.

If you do not want to enable dupatch to mark these patches as installed, you must manually remove the patched system files so the normal dupatch installation can install the affected patches.

2.5.4 Phase 4 - Handling Missing or Unknown Files on Your System

Phase 4 reports information about any missing and unknown system files. Missing files are those that dupatch expected to find but did not. Unknown files are ones that were originally installed on the system, but have changed in some way, for example in size or checksum.

You should consider these files as intentional customizations that are important to correct system operation. Therefore, before enabling any patch installations in Phase 5, review the information reported in Phase 4 against your log of manual system changes to ensure you understand why the system was intentionally customized and to determine how to proceed. In some cases you may need to remove customizations to ensure proper system operation.

The following sections provide general guidance for some of the normal situations where system files are intentionally customized manually.

2.5.4.1 Manually Installed Customer-Specific Patches

In response to a problem report, you may receive a customer-specific patch from Compaq Services. Customer-specific patches are a set of compatible files that deliver fixes to the problems you reported. Additionally the patch may include instrumentation necessary for debugging purposes.

If your system was customized through a manual installation of customer-specific patches, you must ensure that the fixes delivered by the customer-specific patches are included in the current official patch kit before enabling dupatch to overwrite any unknown or missing system files.

Caution

If you are unsure if the customer-specific patch is included in the official patch kit, do not enable dupatch to overwrite the manually installed customer-specific patch. If you must install the official patch being blocked by a customer-specific patch, contact your service provider for assistance.

If the unknown or missing files are attributable to manually installed customer-specific patches that are included in the official patch kit, perform one of the following steps:

If all customer-specific patch files are overwritten by the patches noted in Phase 5, you can safely enable dupatch to overwrite applicable missing or unknown system files.

If some of the customer-specific patch files are not overwritten by the patches noted in Phase 5, contact your service provider for assistance.

To determine if your customer-specific patch is included in the official patch kit, refer to the Patch Summary and Release Notes for the official patch kit, the Compaq Services Web-based patch search engine (http://www.service.digital.com/patches/index.html), your service provider, or your Compaq Services representative (if you have purchased Business Critical Services).

2.5.4.2 Manually Installed Official Patches

For some software products, manual installation has been the practiced method for patch installation. For example, up to now official patches for TCR have been manually installed.

You must determine whether the fixes delivered by the manually installed official patches are included in the current dupatch-based official patch kit before enabling dupatch to overwrite any unknown or missing system files. Once you have made this determination, proceed as follows:

If the unknown or missing system files are attributable to manual installation of official patches and the patches are included in the current dupatch-based official patch kit, you can safely enable dupatch to overwrite applicable missing or unknown system files.

If the unknown or missing system files are not attributable to manual installation, you must understand the origin of the unknown or missing system files by reviewing the information reported in Phase 4 against your log of manual system changes to ensure you understand why the system was intentionally customized, and to determine how to proceed.

2.5.4.3 User Customized Commands and Utilities

Periodically system administrators of production computing environments replace Tru64 UNIX commands or utilities with freeware or their own customized version of the command or utility. In this situation you must ensure the unknown or missing files are attributable to intentional replacement of commands, utilities, or other system files.

If the unknown or missing system files are attributable to the replacement of commands, utilities, or other system files with customized versions for the computing environment, do not enable dupatch to overwrite the manually installed customized files. Instead, determine the reason for the customization and then decide how to proceed.

2.5.5 Phase 5 - Enabling dupatch to Overwrite Changed System Files

The fifth phase reports patches that are blocked due to missing or unknown system files, and optionally allows you to override the dupatch conflict management mechanism so the dupatch-based patch may be installed.

For each patch that is blocked by a missing or unknown system file you are presented with the following information:

Software product identifier

Patch category

Patch identifier

Patch subset description

The list of unknown and missing files that block the patch installation

The origin of all other files contained in the patch

Optionally, you can enable dupatch to override the collision detection mechanisms and install any of these patches. Use the missing and unknown file information presented in Phase 4 and your system administration log of manual system changes to make Phase 5 patch installation enabling decisions.

Caution

Do not enable dupatch to install patches over missing or unknown system files for which you do not know the origin. Doing so may cause your operating system and TCR software environment to be in an inconsistent and nonoperational state.

2.6 Command Line User Interface

The dupatch utility provides a command line interface that allows dupatch to be called by other programs. You can use the command line to invoke all functions except for baselining. The functions have the same operation and definition as the menu-driven interface.

The following example shows the use of the dupatch command and several of its options to install DIGITAL UNIX 4.0D Patch 8.01:

/usr/sbin/dupatch -install -kit /var/bl11/patch_kit -name Mary -note \ "install patch" -product DIGITAL_UNIX_V4.0D -patch 08.01

The following example shows the use of the dupatch command and several of its options to delete DIGITAL UNIX 4.0D Patch 8.01:

/usr/sbin/dupatch -delete -name Mary -note "delete patch" \ -product DIGITAL_UNIX_V4.0D -patch 08.01

2.6.1 Using Command Line Options

You must specify all mandatory options on the command line or in the data_file file. If any mandatory option is missing, the command will fail with an appropriate error message; it will not prompt you for the missing option and information.

Remember, there is no reason to delete old official patches on your system before installing the new official patches.

2.6.2 Restriction on Loading New dupatch Tools from the Command Line

The new patch tools cannot be loaded using the delete command on the command line. Doing that will cause the following error to be displayed:

product_map does not exist or is empty, Cannot continue.

If you want to use delete from the command line, you can first load the new tools, without impacting the system, by issuing the install command with the -precheck_only option. This will load the tools and not cause changes to your system.

2.6.3 Command Line Interface Options

The following list shows all of the command line interface options (typing dupatch -help provides the same information):

dupatch -delete

       [Mandatory]
        -name user_name
        -note user_note
        -patch all | patch_id{patch_id...]

        [Optional]
        -data data_file
        -nolog (No session logging)
        -proceed ( Proceed with patches that passed predeletion check)
        -product all | product_id*
        -root root_path

*Mandatory when more than one product is available for operation

dupatch -help

           [Optional ]
        -data_file   (Specifiesdata_file to use)
        -kit kit_location
        -patch_id    ( Specifiespatch_id to use)
        -rev   (Lists dupatch version)
        -product_id  (Specifiesproduct_id to use)

dupatch -install

        [Mandatory ]

        -kit kit_location
        -name user_name*
        -note user_note*
        -patch all  | patch_id[patch_id...]
  *Optional when -precheck_only is specified

       [Optional ]

        -single_user (Bring system from multiuser to single-user mode)
        -data data_file
        -nobackup
        -nolog (No session logging)
        -precheck_only (Check patch applicability without installing)
        -proceed  (Proceed with patches that passed preinstallation check)
        -product all  | product_id*
        -root root_path
*Mandatory when more that one product is available for operation.
        -cfgfileconfig_file (Configuration file for kernel rebuild)

dupatch -track

        [Mandatory]

        -type file | file | patch

       (Use file to list all patched files.)
       (Use kit to list installed patch kits.)
       (Use patch to list installed patches.)

       [Optional ]
        -datadata_file
        -nolog (No session logging.)
         -rootroot_path

Specifying a Data File

When using the -data option, you must specify a data file, which is a file path that contains specifications with the following format:

switch1=value
switch2=value
       .
       .
       .
switch3

For example:

kit = /mnt
name = John Doe
note = install April patch kit
patch = all

precheck_only
nobackup

The following list describes characteristics of a data file:

Blank lines and comments (preceded with #) are allowed.

Line continuation (\) is required if a specification spans multiple lines.

When a option is specified both on the command line and in the data file, the value specified on the command line overrides that specified in the data file.

Specifying a Patch ID

The following list describes the characteristics of a patch ID:

A valid patch ID specification has the following format:
all
xxxx[.yy]

For example:
15
200.11
10.2
00111.02

Both xxxx and yy are numeric values; leading zeros can be omitted.

Patch revision (yy), when left unspecified, maps to wildcarded "??"

Multiple patch_id specifications are separated by white space.

The keyword all cannot be combined with other patch IDs.

Specifying a Product ID

The following list describes the characteristics of a product ID.

Note

When using the command line, the -product option must preceed the -patch option.

A valid product ID has the following format:

all
description_version

where description is the product description, and version is the product version.
For example:
DIGITAL_UNIX_V4.0D
TruCluster_V1.5

Product ID specifications are case insensitive.

Wildcards are not allowed in product ID specifications.

Multiple product ID specifications are separated by white space.

The keyword all cannot be combined with other product IDs.

Specifying a Root Path

The following list describes the characteristics of a root path:

The -root option, which is similar to the -D option of setld, specifies an alternative root for the specified operation.

The root path must be the root of a complete Tru64 UNIX file system.

The default root path is / for all operations.

If -root is the only argument on the command line, dupatch will proceed in interactive mode; this is an exception to the command line rule previously mentioned.

Specifying Product Strings

The following list provides valid Tru64 UNIX product strings:

TRU64_UNIT_V5.0
  DIGITAL_UNIX_V4.0F
  DIGITAL_UNIX_V4.0E
  DIGITAL_UNIX_V4.0D
  DIGITAL_UNIX_V4.0C
  DIGITAL_UNIX_V4.0B
  DIGITAL_UNIX_V4.0A
   TruCluster_V1.5
  TruCluster_V1.6

The following list describes characteristics of product strings:

A product string specification only applies to the patch ID specifications that follow it and ends when another product string is specified.

A product-string specification is not necessary when the system being patched has only one product installed. For example, DIGITAL UNIX Version 4.0D with no TCR.

Because the purpose of the product-string is to clarify the patch ID specification, its specification must precede that of the patch ID.

The following example shows a product string:

dupatch -install -product DIGITAL_UNIX_V4.0D -patch 1.1 -product TruCluster_V1.5 -patch 35 \
-name Mary -note "installing patch 1.1" -kit