HP OpenVMS Systems Documentation

Content starts here

OpenVMS Version 7.3 Release Notes

Previous Contents Index

5.8.4 Workstations in OpenVMS Clusters


The default behavior of OPCOM is to not enable OPA0: on workstations in clusters. OPCOM also does not enable the logfile, OPERATOR.LOG, on these systems. The only exception is if the system is the first system into the cluster.

OPCOM determines whether a system is a workstation by testing if it has a graphics device. This test is specifically:


OPCOM is treating systems shipped with graphic devices as workstations. As a result, OPA0: and OPERATOR.LOG are not enabled by default.

To override the default behavior, define the following logical names in SYS$MANAGER:SYLOGICALS.COM to be TRUE:


5.9 OpenVMS Cluster Systems

The release notes in this section pertain to OpenVMS Cluster systems.

5.9.1 New Error Message About Packet Loss


Prior to OpenVMS Version 7.3, an SCS virtual circuit closure was the first indication that a LAN path had become unusable. In OpenVMS Version 7.3, whenever the last usable LAN path is losing packets at an excessive rate, PEDRIVER displays the following console message:

%PEA0, Excessive packet losses on LAN Path from local-device-name -
 _  to device-name on REMOTE NODE node-name

This message is displayed when PEDRIVER had to recently perform an excessively high rate of packet retransmissions on the LAN path consisting of the local device, the intervening network, and the device on the remote node. The message indicates that the LAN path has degraded and is approaching, or has reached, the point where reliable communications with the remote node are no longer possible. It is likely that the virtual circuit to the remote node will close if the losses continue. Furthermore, continued operation with high LAN packet losses can result in significant loss in performance because of the communication delays resulting from the packet loss detection timeouts and packet retransmission.

Take the following corrective steps:

  1. Check the local and remote LAN device error counts to see if a problem exists on the devices. Issue the following commands on each node:

    $ SHOW DEVICE local-device-name
    $ MC SCACP
    SCACP> SHOW LAN device-name
    $ MC LANCP
    LANCP> SHOW DEVICE device-name/COUNT
  2. If device error counts on the local devices are within normal bounds, contact your network administrators to request that they diagnose the LAN path between the devices.
    If necessary, contact your Compaq Support representative for assistance in diagnosing your LAN path problems.

For additional PEDRIVER troubleshooting information, see Appendix F of the OpenVMS Cluster Systems manual.

5.9.2 Class Scheduler in a Mixed Version Cluster


When using the new permanent Class Scheduler in a mixed-version cluster environment with nodes running OpenVMS Alpha Version 7.2x, the SMISERVER process on these nodes aborts when you issue any SYSMAN CLASS_SCHEDULE subcommand that involves those nodes.

If this happens, you can quickly restart the SMISERVER process on those nodes with the following command:


A remedial kit will be available from the following web site to correct this problem:


This problem exists only on Alpha platforms running OpenVMS Alpha Version 7.2x.

5.9.3 Remedial Kits Required for Extended File Cache (XFC) Used in Mixed Version OpenVMS Cluster Systems


The Extended File Cache (XFC), introduced in this version of the OpenVMS Alpha operating system, improves I/O performance and gives you control over the choice of cache and cache parameters.

If you have an OpenVMS Cluster system that contains earlier versions of OpenVMS Alpha or OpenVMS VAX and you want to use XFC with OpenVMS Version 7.3, you must install remedial kits on the systems that are running the earlier versions of OpenVMS. See Section 5.9.5 for information on the required kits.


These remedial kits correct errors in the cache locking protocol and allow older versions of the caches to operate safely with the new XFC. Without the remedial kit functionality, the system or processes could hang.

5.9.4 Fibre Channel Remedial Kits Support for SANWorks DRM


OpenVMS supports SANworks Data Replication Manager (DRM), except when using the DEC-AXPVMS-VMS721_FIBRECHAN-V0300-4.PCSI kit. An incompatibility exists between DRM and this kit that causes hard hangs. This problem has been addressed in two new remedial kits, one for OpenVMS Alpha Version 7.2-1 and one for OpenVMS Alpha Version 7.2-1H1. For kit names, see Section 5.9.5.

Note that the kit name format has changed. The SCSI and Fibre Channel remedial kits have been consolidated into one kit; the new name format reflects this consolidation.

This remedial kit is not required for V7.3 because the relevant fix is included with the operating system.

5.9.5 Remedial Kits Needed for Cluster Compatibility


Before you introduce an OpenVMS Version 7.3 system into an existing OpenVMS Cluster system, you must apply certain remedial kits to your systems running earlier versions of OpenVMS. If you are using Fibre Channel, XFC or Volume Shadowing, additional remedial kits are required. Note that these kits are version-specific.

Table 5-1 indicates the facilities that require remedial kits and the file names of the remedial kit files.

You can either download the remedial kits from the following web site, or contact your Compaq support representative to receive the remedial kits on



Remedial kits are periodically updated on an as-needed basis. Always use the most recent remedial 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 to the WWW site.


The list of remedial kits in Table 5-1 in this version of the release notes is more up-to-date than the printed version of the release notes.

Table 5-1 Remedial Kits Required for Cluster Compatibility
Facility File Name
OpenVMS Alpha Version 7.2-1H1
All facilities except kits named below DEC-AXPVMS-VMS721H1_UPDATE-V0400--4.PCSI
OpenVMS Alpha Version 7.2-1
All facilities except kits named below DEC-AXPVMS-VMS721_UPDATE-V100--4.PCSI
Fibre Channel DEC-AXPVMS-VMS721_FIBRE_SCSI-V0400--4.PCSI
Volume Shadowing DEC-AXPVMS-VMS721_SHADOWING-V0500--4.PCSI
This kit provides Fibre Channel disaster-tolerant support.
OpenVMS Versions 7.1 and 7.1-2
All facilities except kits names below DEC-AXPVMS-VMS712_UPDATE-V0300--4.PCSI (Alpha 7.1-2)
Fibre Channel DEC-AXPVMS-VMS712_DRIVER-V0300--4.PCSI (Alpha 7.1-2)
VAXDRIV05_071 (VAX 7.1)
Monitor VAXMONT02_071 (VAX 7.1)
Mount VAXMOUN05_071 (VAX 7.1)
Volume Shadowing VAXSHAD06_071 (VAX 7.1)
VCC DEC-AXPVMS-VMS712_SYS-V0300--4.PCSI (Alpha 7.1-2)

5.9.6 OpenVMS Version 7.2-1 Installation Restrictions for Fibre Channel


Note that the OpenVMS Alpha Version 7.2-1 CD-ROM does not support the KGPSA-BC or KGPSA-CA. You must install the operating system to a disk that is not accessed through the KGPSA-BC or KGPSA-CA, then apply the latest FIBRECHAN kit, and reboot to use the KGPSA-BC or KGPSA-CA.

This restriction applies only to OpenVMS Alpha Version 7.2-1. It does not apply to OpenVMS Alpha Version 7.2-1H1 or OpenVMS Alpha Version 7.3. Also note that although versions prior to DEC-AXPVMS-VMS721_FIBRECHAN-V0300-4.PCSI will configure disks on the HSG60, you may have errors when you use these devices. These errors may be logged as INVALID INQUIRY errors, and redundant paths to the HSG60 may fail to be configured.

Before using the HSG60, Compaq recommends the following procedure:

  1. Install the operating system to a disk that is not on an HSG60.
  2. Apply the DEC-AXPVMS-VMS721_FIBRECHAN-V0300-4.PCSI kit.
  3. Reboot.

5.9.7 Devices Not Configured if HSG Host Connection Table Is Full


When a Fibre Channel host bus adapter is connected (through a Fibre Channel switch) to an HSG controller, the HSG creates an entry in the HSG connection table. There is a separate connection for each host bus adapter, and for each HSG port to which the adapter is connected. (Refer to the HSG CLI command SHOW CONNECTIONS.)

Once a connection exists, you can modify its parameters by using commands that are described in the HSG Array Controller ACS Configuration and CLI Reference Guide. Since a connection can be modified, the HSG does not delete connection information from the table when a host bus adapter is disconnected. Instead, when the user is done with a connection, the user must explicitly delete the connection using a CLI command.

The HSG supports a limited number of connections: ACS V8.5 allows a maximum of 64 connections and ACS V8.4 allows a maximum of 32 connections. The connection limit is the same for both single and dual redundant controllers. Once the maximum number of connections is reached, new connections will not be made. When this happens, OpenVMS will not configure disk devices, or certain paths to disk devices, on the HSG.

The solution to this problem is to delete old connections that are no longer needed. However, if your Fibre Channel fabric is large and the number of active connections exceeds the HSG limit, then you must reconfigure the fabric or use FC switch zoning to "hide" some adapters from some HSG ports to reduce the number of connections.

In a future version of OpenVMS, a message will be displayed when OpenVMS detects that the HSG connection table is full.

5.9.8 KGPSA NVRAM Error with Console V5.6 and Later


When you use V5.6 or later versions of the console, you will see the error message kgpsaa0. - Nvram read failed , when the console KGPSA driver starts. This error indicates that NVRAM on the KGPSA is unformatted or not working properly. The more likely reason is that the NVRAM is unformatted. The NVRAM was always unformatted prior to V5.6. As of V5.6, a portion of the NVRAM on the KGPSA adapter is used to indicate whether the adapter should be initialized for a fabric (switch) topology or a loop topology. By default, the console initializes the KGPSA to a fabric topology.

The NVRAM is formatted automatically when you set the topology, as shown in the following example:

P00>>>set mode diag
P00>>>wwidmgr -show adapter
item adapter WWN Cur. Topo Next Topo
kgpsaa0. - Nvram read failed.
[ 0] kgpsaa0. 1000-0000-c920-05ab FABRIC UNAVAIL
kgpsab0. - Nvram read failed.
[ 1] kgpsab0. 1000-0000-c921-0ce0 FABRIC UNAVAIL
[9999] All of the above.
P00>>>wwidmgr -set adapter -item 9999 -topo fabric
kgpsaa0. - Nvram read failed.
Reformatting nvram
kgpsab0. - Nvram read failed.
Reformatting nvram
P00>>>wwidmgr -show adapter
item adapter WWN Cur. Topo Next Topo
[ 0] kgpsaa0. 1000-0000-c920-05ab FABRIC FABRIC
[ 1] kgpsab0. 1000-0000-c921-0ce0 FABRIC FABRIC
[9999] All of the above.

While formatting the NVRAM of the KGPSA you may see a *** MBX not ready *** error when you issue the wwidmgr -set adapter command. Reissuing this command should succeed, as shown in the following example:

P00>>>wwidmgr -set adapter -item 9999 -topo fab
pga0. - Nvram read failed.
Reformatting nvram
*** MBX not ready ***
pgb0. - Nvram read failed.
Reformatting nvram
P00>>>wwidmgr -show adapter
item adapter WWN Cur. Topo Next Topo
*** MBX not ready ***
pga0. - Nvram format incorrect.
[ 0] pga0. 1000-0000-c920-a763 FABRIC UNAVAIL
[ 1] pgb0. 1000-0000-c920-c9fe FABRIC FABRIC
[9999] All of the above.
P00>>>wwidmgr -set adapter -item 9999 -topo fab
P00>>>wwidmgr -show adapter
item adapter WWN Cur. Topo Next Topo
[ 0] pga0. 1000-0000-c920-a763 FABRIC FABRIC
[ 1] pgb0. 1000-0000-c920-c9fe FABRIC FABRIC
[9999] All of the above.

For more information about the wwidmgr -set adapter command, see the WWIDMGR User's Manual in the [.DOC] directory of the Alpha Systems Firmware Update CD-ROM.

5.9.9 Selective Autoconfiguration Not Supported in Some Fibre Channel and SCSI Configurations


OpenVMS Alpha provides SYSMAN commands that enable system managers to specify which devices will be autoconfigured. Device autoconfiguration can be specified permanently so that it is applied either at each system boot or for the duration of a manual autoconfiguration command, using the following qualifiers:

SYSMAN> IO SET/EXCLUDE=(device_name)
SYSMAN> IO AUTOCONFIGURE [/EXCLUDE=(device_name)] [/SELECT=(device_name)]

You can use the /EXCLUDE and /SELECT qualifiers to exclude and include Fibre Channel port driver devices (PG and FG) and any SCSI port driver devices (PK).

However, you cannot use these qualifiers to exclude or include any of the following device types:

  • SCSI class-driver devices (DK, MK, GK) whose names include a port allocation class or an HSZ allocation class
  • Fibre Channel class-driver devices (DG, GG)

This restriction also applies to SCSI devices on OpenVMS Alpha Version 7.1 systems, if the SCSI device names include a port allocation class.

5.9.10 SHOW Command Displays Wrong Device Type for Fibre Channel Devices (VAX Only)


Fibre Channel devices can be served to OpenVMS VAX systems. On OpenVMS VAX Version 7.2 (and later) systems, issuing the SHOW DEVICE/FULL command for a Fibre Channel device ($1$DGAxxxx) incorrectly displays a device type of Snapshot-capable virtual disk device . For example:


Disk $1$DGA1000: (CRNPOP), device type Snapshot-capable virtual disk device, is
online, mounted, file-oriented device, shareable, available to cluster, error
logging is enabled.

The device type in this case should be DEC HSG80.

5.9.11 MEMORY CHANNEL Rolling Upgrade Restriction (Alpha Only)


OpenVMS Version 7.3 supports rolling upgrades in an OpenVMS Cluster system, as described in Section 1.2.

This note applies to rolling upgrades from OpenVMS Alpha Version 7.1 (or a Version 7.1 variant) to one of the following:

  • OpenVMS Alpha Version 7.2x
  • OpenVMS Alpha Version 7.3

If MEMORY CHANNEL adapters (CCMAA-xx) have been added to the cluster before upgrading OpenVMS to either Version 7.2 (or a Version 7.2 variant) or to Version 7.3, an MC_FORCEDCRASH bugcheck occurs on the first system when the second and subsequent systems perform AUTOGEN and SHUTDOWN during their installation. This problem is caused by conflicting system parameters.

To avoid this problem when upgrading, use one of the following procedures:

  • Upgrade all systems before adding the CCMAA-xx MEMORY CHANNEL adapters.
  • If you have MEMORY CHANNEL hubs, power them off before upgrading each system.
    After all systems have been upgraded, power on the MEMORY CHANNEL hubs.
  • If the nodes are connected directly in a virtual hub configuration, disconnect the MEMORY CHANNEL cables before upgrading each system.
    After all systems have been upgraded, reconnect the MEMORY CHANNEL cables.

For detailed information about setting up the MEMORY CHANNEL hardware, see the MEMORY CHANNEL User's Guide (order number EK--PCIMC--UG.A01). You can copy this manual from the OpenVMS Version 7.3 CD-ROM using the following file name:


5.9.12 Boot Support for Multipath Devices with an HSZ Allocation Class


All AlphaServer systems that support the KZPBA-CB, except the AlphaServer 2x00(A), support booting from devices with an HSZ allocation class. (Allocation class support was added to these controllers to support SCSI multipath failover on OpenVMS.)

The minimum required Alpha console firmware for OpenVMS V7.3 is Version 5.9.

5.9.13 Failover Between Local Paths and MSCP Served Paths


Failover from a local path (to a SCSI or Fibre Channel device) to an MSCP-served path to that same device is not currently available. This type of failover is planned for delivery after the release of OpenVMS Version 7.3.

Although failover to an MSCP path is not yet available, multipath devices can be MSCP served to other systems in an OpenVMS Cluster system. Failover between MSCP served systems works as for all devices.

5.9.14 Multipath SCSI and Fibre Channel Shadow Sets: Adjustments to System Parameters


The use of default settings for certain system parameters may lead to the occasional removal of shadow set members (systems which are using Compaq Volume Shadowing for OpenVMS) that are configured for multipath support.

Therefore, when configuring multipath shadow sets using Volume Shadowing for OpenVMS, follow the recommendations in Table 5-2 for setting these system parameters.

Table 5-2 System Parameter Settings for Multipath Shadow Sets
System Parameter Recommended Setting
MSCP_CMD_TMO 60 as a minimum.
The value of 60 is appropriate for most configurations. Some configurations may require a higher setting.

The following example shows the use of the recommended settings:

MVTIMEOUT      1200

5.9.15 Multipath Devices: Volume Rebuilds During Mount Operation


When mounting a Fibre Channel or SCSI device, a volume rebuild is sometimes performed even though the volume was previously dismounted without any apparent error. For example:

$ DISMOUNT $1$DGA32762:

%MOUNT-I-MOUNTED, DGA1016 mounted on _$1$DGA32762: (FIBRE2)
%MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress


A user with privileges can work around this problem by issuing an I/O to the device immediately before dismounting it. For example:

$ CREATE $1$DGA32762:[0,0]A.TMP
$ DELETE $1$DGA32762:[0,0]A.TMP;0

5.9.16 Multipath Device Dismount Problem with Volume Shadowing


If a multipath member of a shadow set switched paths prior to being dismounted, and no I/Os were issued immediately before the DISMOUNT command was issued, the dismount fails and the following error message is displayed:


This error does not occur under the following conditions:

  • If no path switch occurred before the use of the DISMOUNT command.
  • If a path switch did occur, I/O was issued to the device before the use of the DISMOUNT command.

A user with privileges can work around this problem by issuing an I/O to the device immediately before dismounting it. For example:

$ CREATE $1$DGA32762:[0,0]A.TMP
$ DELETE $1$DGA32762:[0,0]A.TMP;0

Previous Next Contents Index