Document revision date: 9 May 2001

V7.2-1

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.

V7.3

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

V7.2-1

When you use V5.6 or later versions of the console, you will see the error message kgpsaa0.0.0.2.4 - 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.0.0.8.1 - Nvram read failed. [ 0] kgpsaa0.0.0.8.1 1000-0000-c920-05ab FABRIC UNAVAIL kgpsab0.0.0.10.1 - Nvram read failed. [ 1] kgpsab0.0.0.10.1 1000-0000-c921-0ce0 FABRIC UNAVAIL [9999] All of the above. P00>>>wwidmgr -set adapter -item 9999 -topo fabric kgpsaa0.0.0.8.1 - Nvram read failed. Reformatting nvram kgpsab0.0.0.10.1 - Nvram read failed. Reformatting nvram P00>>>wwidmgr -show adapter item adapter WWN Cur. Topo Next Topo [ 0] kgpsaa0.0.0.8.1 1000-0000-c920-05ab FABRIC FABRIC [ 1] kgpsab0.0.0.10.1 1000-0000-c921-0ce0 FABRIC FABRIC [9999] All of the above. P00>>>init

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.0.0.6.1 - Nvram read failed. Reformatting nvram *** MBX not ready *** pgb0.0.0.1.2 - Nvram read failed. Reformatting nvram P00>>>wwidmgr -show adapter item adapter WWN Cur. Topo Next Topo *** MBX not ready *** pga0.0.0.6.1 - Nvram format incorrect. [ 0] pga0.0.0.6.1 1000-0000-c920-a763 FABRIC UNAVAIL [ 1] pgb0.0.0.1.2 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.0.0.6.1 1000-0000-c920-a763 FABRIC FABRIC [ 1] pgb0.0.0.1.2 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

V7.2-1

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)

V7.2

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:

$ SHOW DEV/FULL $1$DGA1000 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)

V7.3

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.2 (or a Version 7.2 variant)
• 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:

[DOCUMENTATION]HW_MEMORY_CHANNEL2_UG.PS

5.9.12 Boot Support for Multipath Devices with an HSZ Allocation Class

V7.2

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

V7.2

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

V7.2

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.
SHADOW_MBR_TMO	3 x MSCP_CMD_TMO
SHADOW_SYS_TMO	3 x MSCP_CMD_TMO
MVTIMEOUT	At least 2 x SHADOW_MBR_TMO

The following example shows the use of the recommended settings:

MSCP_CMD_TMO 60 SHADOW_MBR_TMO 180 SHADOW_SYS_TMO 180 MVTIMEOUT 1200

5.9.15 Multipath Devices: Volume Rebuilds During Mount Operation

V7.2-1

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/CLUSTER $1$DGA32762: MYVOL %MOUNT-I-MOUNTED, DGA1016 mounted on _$1$DGA32762: (FIBRE2) %MOUNT-I-REBUILD, volume was improperly dismounted; rebuild in progress

Workaround

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

V7.3

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:

%DISM-W-CANNOTDMT

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.

Workaround

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.17 Multipath Failover Fails Infrequently on HSZ70/HSZ80 Controllers

V7.2-1

Under heavy load, a host-initiated manual or automatic path switch from one controller to another may fail on an HSZ70 or HSZ80 controller. Testing has shown this to occur infrequently.

V7.2

OpenVMS Alpha Version 7.2 introduced the SCSI multipath feature, which provides support for failover between the multiple paths that can exist between a system and a SCSI device.

This SCSI multipath feature may be incompatible with some third-party disk caching, disk shadowing, or similar products. Compaq advises you to avoid the use of such software on SCSI devices that are configured for multipath failover (for example, SCSI devices that are connected to HSZ70 and HSZ80 controllers in multibus mode) until this feature is supported by the manufacturer of the software.

Third-party products that rely on altering the Driver Dispatch Table (DDT) of the OpenVMS Alpha SCSI disk class driver (SYS$DKDRIVER.EXE) may require changes to work correctly with the SCSI multipath feature. Manufacturers of such software can contact Compaq at vms_drivers@zko.dec.com for more information.

For more information about OpenVMS Alpha SCSI multipath features, see Guidelines for OpenVMS Cluster Configurations.

5.9.19 Gigabit Ethernet Switch Restriction in an OpenVMS Cluster System

V7.3

Attempts to add a Gigabit Ethernet node to an OpenVMS Cluster system over a Gigabit Ethernet switch will fail if the switch does not support autonegotiation. The DEGPA enables autonegotiation by default, but not all Gigabit Ethernet switches support autonegotiation. For example, the current Gigabit Ethernet switch made by Cabletron does not.

Furthermore, the messages that are displayed may be misleading. If the node is being added using CLUSTER_CONFIG.COM and the option to install a local page and swap disk is selected, the problem may look like a disk-serving problem. The node running CLUSTER_CONFIG.COM displays the message "waiting for node-name to boot," while the booting node displays "waiting to tune system." The list of available disks is never displayed because of a missing network path. The network path is missing because of the autonegotiation mismatch between the DEGPA and the switch.

To avoid this problem, disable autonegotiation on the new node's DEGPA, as follows:

• Perform a conversational boot when first booting the node into the cluster.
• Set the new node's system parameter LAN_FLAGS to a value of 32 to disable autonegotiation on the DEGPA.

V7.3

Multiple systems in a cluster could each have IDE, ATA, or ATAPI devices potentially sharing the following names: DQA0, DQA1, DQB0, and DQB1.

Such sharing of device names could lead to confusion or errors. Starting with OpenVMS Version 7.2-1, you can avoid this problem by creating devices with unique names.

To create a list of uniquely named devices on your cluster, use the following procedure:

1. In SYSGEN, make sure DEVICE_NAMING is set to 1 and ALLOCLASS is set to a nonzero value.
2. Create a file named SYS$SYSTEM:SYS$DEVICES.DAT that specifies a port allocation class of 0 for the two DQ controllers (DQA and DQB).
   You can either edit this file to add the information manually, or update this file automatically by using the following commands at bootstrap time:

   SYSBOOT> SET /CLASS DQA 0 SYSBOOT> SET /CLASS DQB 0

Following is a sample SYS$SYSTEM:SYS$DEVICES.DAT file (for node ACORN::):

[Port ACORN$DQA] Allocation Class = 0 [Port ACORN$DQB] Allocation Class = 0

This procedure causes all DQ devices to be named according to the following format, which allows for unique device names across the cluster:

node-name$DQxn:

where:

node-name is the system name.
x is either A or B.
n is either 0 or 1.

Port allocation classes are described in the OpenVMS Cluster Systems manual, where this technique is fully documented.

You have the option of using a nonzero port allocation class in the SYS$DEVICES.DAT file. However, if you use nonzero port allocation classes, be sure to follow the rules outlined in the OpenVMS Cluster Systems manual.

Restriction:

If you attempt to use the DCL command $INITIALIZE to initialize an IDC hard drive on a remote system using the mass storage control protocol (MSCP) server, you may receive a warning message about the lack of a bad block file on the volume. You can safely ignore this warning message.

Additionally, previously unused drives from certain vendors contain factory-written data that mimics the data pattern used on a head alignment test disk. In this case, the OpenVMS software will not initialize this disk remotely. As a workaround, initialize the disk from its local system. Note that this workaround also avoids the bad block file warning message.

5.9.21 Shadowing Restriction on Fibre Channel Multiple-Switch Fabrics Removed

V7.3

Multiple-switch Fibre Channel fabrics are supported by OpenVMS, starting with the DEC-AXPVMS-VMS721_FIBRECHAN-V0200 remedial kit. However, a significant restriction existed in the use of Volume Shadowing for OpenVMS in configurations with a multiple-switch fabric. All Fibre Channel hosts that mounted the shadow set had to be connected to the same switch, or all the Fibre Channel shadow set members had to be connected to the same switch. If the Fibre Channel host or shadow set member was connected to multiple fabrics, then this rule had to be followed for each fabric.

Changes have been made to Volume Shadowing for OpenVMS in OpenVMS Version 7.3 that remove these configuration restrictions. These same changes are available for OpenVMS Versions 7.2-1 and 7.2-1H1 in the current version-specific Volume Shadowing remedial kits.

5.9.22 Fibre Channel Installation May Require Additional NPAGEVIR

V7.3

This problem is corrected in OpenVMS Alpha Version 7.2-1H1 and OpenVMS Alpha Version 7.3 with a new system parameter, NPAGECALC, which automatically calculates a value for NPAGEVIR and NPAGEDYN based on the amount of physical memory in the system.

5.9.23 Fibre Channel Adapters Off Line After a System Boot

V7.3

The problem of Fibre Channel adapters being off line after a system boot has been corrected in the following versions:

• OpenVMS Alpha Version 7.2-1 with the remedial kit DEC-AXPVMS-VMS721_FIBRECHAN-V0300-4.PCSI
• OpenVMS Alpha Version 7.2-1H1
• OpenVMS Alpha Version 7.3

V7.2-1

The problem of SHOW DEVICE failing in large Fibre Channel configurations has been corrected in the following versions:

• OpenVMS Alpha Version 7.2-1 with the remedial kit DEC-AXPVMS-VMS721_UPDATE-V0100-4.PCSI
• OpenVMS Alpha Version 7.2-1H1
• OpenVMS Alpha Version 7.3

Before the correction, SHOW DEVICE might fail with a virtual address space full error on systems with more than 2400 unit control blocks (UCBs). In multipath SCSI and FC configurations, there is a UCB for each path from the host to every storage device.

Note that any procedure that calls SHOW DEVICE, such as CLUSTER_CONFIG, can also experience this problem.

5.9.25 Boot Failure with the KGPSA Loopback Connector Installed

V7.2-1

The problem of boot failure with the KGPSA loopback connector has been corrected in the following versions:

• OpenVMS Version 7.2-1 systems with the current FIBRE_SCSI update kit for OpenVMS Alpha Version 7.2-1 installed
• OpenVMS Alpha Version 7.2-1H1
• OpenVMS Alpha Version 7.3

Before the correction, the system failed to boot if there was a KGPSA in the system with a loopback connector installed. The loopback connector is the black plastic protective cover over the GLMs/fiber-optic ports of the KGPSA.

If possible, install OpenVMS Alpha Version 7.2-1 and the current FIBRE_SCSI update kit for OpenVMS Alpha Version 7.2-1 kit before installing the KGPSA in your system.

If the KGPSA is installed on your system and the current FIBRE_SCSI update kit for OpenVMS Alpha Version 7.2-1 is not installed, you can connect the KGPSA to your Fibre Channel storage subsystem and then boot OpenVMS.

If you are not ready to connect the KGPSA to your Fibre Channel storage subsystem, you can do either of the following:

• Remove the loopback connector but leave the KGPSA in the Alpha system, then boot OpenVMS. Do not replace the loopback connector after you boot OpenVMS.
• Remove the KGPSA from the Alpha system, then boot OpenVMS.

If you attempt to boot OpenVMS when a KGPSA is installed with the loopback connector still attached, the system hangs early in the boot process, at the point when it should configure the Fibre Channel adapters.

	privacy and legal statement
6637PRO_005.HTML