Previous | Contents |
V8.3
Before introducing an OpenVMS Version 8.2--1 system into an existing OpenVMS Cluster system, you must apply certain patch kits (also known as remedial kits) to your systems running earlier versions of OpenVMS. Note that these kits are version specific.
The versions listed in Table 4-2 are supported in a warranted configuration. For more information about these configurations, see the HP OpenVMS Version 8.2--1 for Integrity Servers Upgrade and Installation Manual.
Table 4-2 lists the facilities that require patch kits and the patch kit file names. Each patch kit has a corresponding readme file by the same name with a .README file extension.
You can either download the patch kits from the following Web site or contact your HP Support representative to receive the patch kits on media appropriate for your system:
Patch kits are periodically updated on an as-needed basis. Always use the most recent patch kit for the facility, as indicated by the version number in the kit's readme file. The most recent version of each kit is the version posted on the Web site. |
Facility | Patch Kit File Name |
---|---|
OpenVMS Alpha Version 7.3-2 | |
Update kit with most patch kits except those listed in this section | VMS732_UPDATE-V0600. |
C RTL | VMS732_ACRTL-V0100 |
Drivers | VMS732_DRIVER-V0200 |
PCSI | VMS732_PCSI-V0100 |
OpenVMS Alpha Version 8.2 | |
VMS82A_UPDATE-V0200 | |
DECnet-Plus for OpenVMS Alpha ECO1 | DNVOSIECO01_V82 1 |
OpenVMS I64 Version 8.2 | |
VMS82I_UPDATE-V0200 |
Before introducing an OpenVMS Version 8.2 (or higher) system into an existing OpenVMS Cluster system, you must apply certain patch kits (also known as remedial kits) to your systems running earlier versions of OpenVMS. If you are using Fibre Channel, XFC, or Volume Shadowing, additional patch kits are required. Note that these kits are version specific.
The versions listed in Table 4-2 are supported in either a warranted configuration or a migration pair configuration. For more information about these configurations, refer to either HP OpenVMS Cluster Systems or the HP OpenVMS Version 8.3 Upgrade and Installation Manual.
Table 4-2 lists the facilities that require patch kits and the patch ID names. Each patch kit has a corresponding readme file with the same name (file extension is .README).
You can either download the patch kits from the following web site (select the OpenVMS Software Patches option), or contact your HP support representative to receive the patch kits on media appropriate for your system:
Patch kits are periodically updated on an as-needed basis. Always use the most recent patch kit for the facility, as indicated by the version number in the kit's readme file. The most recent version of each kit is the version posted on the web site. |
Facility | Patch ID |
---|---|
OpenVMS Alpha Version 7.3-2 | |
Update kit with most patch kits except those also listed in this section | VMS732_UPDATE-V0600 |
OpenVMS VAX Version 7.3 1 | |
Audit Server | VAXAUDS01_073 |
Cluster | VAXSYSL01_073 |
DECnet-Plus | VAX_DNVOSIECO04-V73 |
DECwindows Motif | VAXDWMOTMUP01_073 |
DTS | VAXDTSS01_073 |
Files 11 | VAXF11X02_073 |
VAXMAIL01_073 | |
MIME | VAXMIME01_073 |
MOUNT | VAXMOUN01_073 |
RMS | VAXRMS01_073 |
RPC | VAXRPC02_073 |
Volume Shadowing | VAXSHAD01_073 |
System | VAXSYS01_073 |
Note that VAX systems cannot be in a cluster with I64 systems. For a
complete list of warranted groupings within a cluster, refer to the
HP OpenVMS Version 8.3 Upgrade and Installation Manual.
4.14.2 API Can Correct Incompatibility of Fibre Channel and SCSI Multipath with Some Third-Party Products
V7.3-2
OpenVMS Alpha Version 7.2-1 introduced the multipath feature, which provides support for failover between the multiple paths that can exist between a system and a SCSI or Fibre Channel device. OpenVMS Alpha Version 7.3-1 introduced support for failover between Fibre Channel multipath tape devices.
This multipath feature can be incompatible with some third-party disk-caching, disk-shadowing, or similar products. HP advises that you do not use such software on SCSI or Fibre Channel devices that are configured for multipath failover until this feature is supported by the producer of the software.
Third-party products that rely on altering the Driver Dispatch Table (DDT) of either the OpenVMS Alpha SCSI disk class driver (SYS$DKDRIVER.EXE), the OpenVMS Alpha SCSI tape class driver (SYS$MKDRIVER.EXE), or the SCSI generic class driver (SYS$GKDRIVER) may need to be modified in order to function correctly with the SCSI multipath feature.
Producers of such software can now modify their software using DDT Intercept Establisher routines introduced in OpenVMS Alpha Version 7.3-2. For more information about these routines, refer to the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview manual.
If you are using a third-party disk-caching product or disk shadowing application, refrain from using it in an OpenVMS SCSI or Fibre Channel multipath configuration until you confirm that the application has been revised using these new routines. |
For more information about OpenVMS Alpha SCSI and Fibre Channel
multipath features, refer to Guidelines for OpenVMS Cluster Configurations.
4.14.3 DDT Intercept Establisher Routines and Device Configuration Notification Results
V8.3
To ensure proper behavior of certain routines, a patch kit is required. Using those routines without the required patch kit can result in system hangs, crashes, or data corruption, and is not supported by HP.
For more information about these routines, see the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview manual.
4.14.4 Cluster Performance Reduced with CI-LAN Circuit Switching
V7.3-1
In rare cases, in an OpenVMS Cluster configuration with both CI and multiple FDDI, 100 Mb/s or Gb/s Ethernet-based circuits, you might observe that SCS connections are moving between CI and LAN circuits at intervals of approximately 1 minute. This frequent circuit switching can result in reduced cluster performance and may trigger mount verification of shadow set members.
PEdriver can detect and respond to LAN congestion that persists for a few seconds. When it detects a significant delay increase or packet losses on a LAN path, the PEdriver removes the path from use. When it detects that the path has improved, it begins using it again.
Under marginal conditions, the additional load on a LAN path resulting from its use for cluster traffic may cause its delay or packet losses to increase beyond acceptable limits. When the cluster load is removed, the path might appear to be sufficiently improved so that it will again come into use.
If a marginal LAN path's contribution to the LAN circuit's load class increases the circuit's load class above the CI's load class value of 140 when the marginal path is included (and, conversely, decreases the LAN circuit's load class below 140 when the path is excluded), SCS connections will move between CI and LAN circuits.
You can observe connections moving between LAN and CI circuits by using SHOW CLUSTER with the CONNECTION and CIRCUITS classes added.
Workarounds
If excessively frequent connection moves are observed, you can use one of the following workarounds:
$ MC SCACP SCACP> SET PORT PNA0 /PRIORITY=2 ! This will cause circuits from local ! CI port PNA0 to be chosen over ! lower priority circuits. SCACP> SET PORT PEA0 /PRIORITY=2 ! This will cause LAN circuits to be ! chosen over lower priority circuits. |
SCACP> SET CHANNEL LARRY /LOCAL=EWB/REMOTE=EWB /PRIORITY=-2 |
V7.3-1
While the INITIALIZE command is in progress on a device in a Fibre Channel multipath tape set, multipath failover to another member of the set is not supported. If the current path fails while another multipath tape device is being initialized, retry the INITIALIZE command after the tape device fails over to a functioning path.
This restriction will be removed in a future release.
4.14.6 No Automatic Failover for SCSI Multipath Medium Changers
V7.3-1
Automatic path switching is not implemented in OpenVMS Alpha Version 7.3-1 or higher for SCSI medium changers (tape robots) attached to Fibre Channel using a Fibre-to-SCSI tape bridge. Multiple paths can be configured for such devices, but the only way to switch from one path to another is to use manual path switching with the SET DEVICE/SWITCH command.
This restriction will be removed in a future release.
4.14.7 Availability Manager AVAIL_MAN_BASE Kit Fails to Collect Lock Contention Information
The OpenVMS Version 8.3 installation includes the installation of the AVAIL_MAN_BASE SIP kit. This kit, in turn, installs the Availability Manager Data Collector.
The Data Collector in the AVAIL_MAN_BASE SIP kit has a defect that
causes it to collect lock contention data incorrectly. To correct this
problem, install the AVAIL_MAN_COL Version 2.6 kit, which is available
on the operating system update media.
4.15 OpenVMS Galaxy (Alpha Only)
The following sections contain notes pertaining to OpenVMS Galaxy systems.
Note that OpenVMS Galaxy is supported on OpenVMS Alpha systems only.
4.15.1 Galaxy Definitions
V8.2
Because the HP OpenVMS Alpha Partitioning and Galaxy Guide is not being updated for this release, this note provides improved definitions of the word Galaxy, which depends on context.
Galaxy as a: | Functions this way: |
---|---|
License | Is required to create and run multiple instances of OpenVMS in a single computer. Without this license, only one instance of OpenVMS can be run in a single computer. |
System parameter | Sets memory sharing. GALAXY set to 1 specifies that OpenVMS instances with the parameter set in a hard partition will share memory between soft partitions within that hard partition. (You can run more than two soft partitions in a hard partition, and you may not want to share memory among all of them.) Note that this parameter only specifies whether a node uses shared memory. There is no need to use this parameter to run multiple, cooperative instances of OpenVMS; this is achieved by console setup of the desired configuration tree. GALAXY set to 0 means that memory is not shared (the default). |
Soft partition | Provides the capability of several OpenVMS instances to execute cooperatively in a single computer so as to be able to migrate CPUs, use APIs, share memory, and so on. Platform partitioning makes possible the separation of resources into multiple soft partitions, each of which can run an OS instance. A soft partition is that subset of resources that the OS instance running in it can see and use. |
If you have multiple nPartitions on your HP Integrity rx7620, HP
Integrity rx8620, or HP Integrity Superdome servers, and you are
running a multi-operating system environment with OpenVMS on one of the
nPartitions, one of the other operating systems might register an error
or event on the System Event Log (SEL) while OpenVMS is booting.
OpenVMS holds the SEL until it has produced a table of Field
Replaceable Units (FRU), which might cause other operating systems to
register an error or an event.
4.16.1 OpenVMS Graphical Configuration Manager
The OpenVMS Graphical Configuration Manager (GCM) is now supported for
AlphaServer ES47/ES80/GS1280 Galaxy configurations. Previously, only
the Graphical Configuration Utility (GCU) was supported.
4.16.2 Galaxy on ES40: Uncompressed Dump Limitation
Permanent Restriction
On AlphaServer ES40 Galaxy systems, you cannot write a raw
(uncompressed) dump from instance 1 if instance 1's memory starts at or
above 4 GB (physical). Instead, you must write a compressed dump.
4.16.3 Galaxy on ES40: Turning Off Fast Path
Permanent Restriction
When you implement Galaxy on an AlphaServer ES40 system, you must turn off Fast Path on instance 1. Do this by setting the SYSGEN parameter FAST_PATH to 0 on that instance.
If you do not turn off Fast Path on instance 1, I/O on instance 1 will
hang when instance 0 is rebooted. This hang will continue until the PCI
bus is reset and instance 1 rebooted. If there is shared SCSI or Fibre
Channel, I/O will hang on the sharing nodes and all paths to those
devices will be disabled.
4.17 OpenVMS Management Station
V8.2
Version 3.2D is the recommended version of OpenVMS Management Station for OpenVMS I64 Version 8.2 and higher and for OpenVMS Alpha Version 8.2 and higher. However, OpenVMS Management Station is backward compatible with OpenVMS Version 6.2 and higher.
The OpenVMS installation includes OpenVMS Management Station Version
3.2D.
4.18 OpenVMS Registry Can Corrupt Version 2 Format Database
V7.3-2
If you create eight or more volatile subkeys in a key tree and then reboot a standalone system or a cluster, the OpenVMS Registry server can corrupt a Version 2 format Registry database when the server starts up after the reboot.
To avoid this problem, do one of the following:
Note that Advanced Server for OpenVMS and COM for OpenVMS do not create
volatile keys.
4.19 System Parameters
The following sections contain notes related to system parameters.
4.19.1 New System Parameters
V8.3
To learn about new system parameters, see the HP OpenVMS Version 8.3 New Features and Documentation Overview.
4.19.2 Obsolete System Parameters
V8.3
The following system parameters are marked as obsolete in OpenVMS Version 8.3:
The following new parameters replace the preceding ones:
For more information about these new system parameters, see the
HP OpenVMS System Management Utilities Reference Manual or online help.
4.19.3 System Parameter Changes
The following system parameters are changed in OpenVMS Version 8.3. For more information, see the HP OpenVMS System Management Utilities Reference Manual.
For detailed descriptions of these parameters see the online help or
the HP OpenVMS System Management Utilities Reference Manual.
4.19.4 Documentation Error: LCKMGR_CPUID System Parameter
V8.3
The OpenVMS Performance Management manual contains several references to the system
parameter LCKMGR_CPUID as LOCKMGR_CPU. This latter reference is
incorrect and will be corrected the next time the manual is updated.
4.19.5 MMG_CTLFLAGS: Documentation Error
V8.2
There is an error in the description of Bit 1 of the MMG_CTLFLAGS system parameter in the OpenVMS Performance Management manual. That description should be corrected to read as follows:
"Reclamation enabled by outswapping processes that have been idle for longer than LONGWAIT seconds. This occurs when the size of the free list drops below the value of FREEGOAL."
On OpenVMS Alpha systems, the Terminal Fallback Facility (TFF) includes a fallback driver (SYS$FBDRIVER.EXE), a shareable image (TFFSHR.EXE), a terminal fallback utility (TFU.EXE), and a fallback table library (TFF$MASTER.DAT).
TFFSHR has been removed from IMAGELIB because it is not a documented, user-callable interface. The image is still available in the SYS$LIBRARY: directory. |
To start TFF, invoke the TFF startup command procedure located in SYS$MANAGER, as follows:
$ @SYS$MANAGER:TFF$SYSTARTUP.COM |
To enable fallback or to change fallback characteristics, invoke the Terminal Fallback Utility (TFU), as follows:
$ RUN SYS$SYSTEM:TFU TFU> |
To enable default fallback to the terminal, enter the following DCL command:
$ SET TERMINAL/FALLBACK |
OpenVMS Alpha TFF differs from OpenVMS VAX TFF in the following ways:
Table Name | Base | Description |
---|---|---|
BIG5_HANYU | BIG5 | BIG5 for CNS 11643 (SICGCC) terminal/printer |
HANYU_BIG5 | CNS | CNS 11643 (SICGCC) for BIG5 terminal/printer |
HANYU_TELEX | CNS | CNS 11643 for MITAC TELEX-CODE terminal |
HANGUL_DS | KS | KS for DOOSAN 200 terminal |
RT terminals are not supported by TFF.
For more information about the Terminal Fallback Facility, refer to the now archived OpenVMS Terminal Fallback Utility Manual on the OpenVMS documentation website:
Click on "Archived documents" in the left sidebar to link to this manual.
Previous | Next | Contents |