Document revision date: 31 July 2002

V7.3

Changes to OpenVMS Version 7.3 (or higher) may affect satellite booting over FDDI for previous versions of OpenVMS. The problem can occur when the system parameter NISCS_LAN_OVRHD is set to a value less than 6 (the default is 18), and the system parameter NISCS_MAX_PKTSZ is set for maximum size FDDI packets (4468). NISCS_LAN_OVRHD decreases the maximum packet size used for LAN communications to accommodate devices such as the DESNC (an Ethernet encryption device). For OpenVMS Version 7.3 or higher, NISCS_LAN_OVRHD is not used, so the maximum packet size is not reduced.

The problem is that the buffer size used by the FDDI boot driver is 12 bytes too short. The FDDI boot driver portion of the satellite boot typically causes 12 bytes of incorrect data (often zeros) to be interspersed throughout the images loaded during SYSBOOT. This generally results in an obscure failure or halt very early in the life of the system (measured in seconds).

The solution is to obtain a Boot Driver patch kit that corrects the problem and to install the patch on the satellite system root. Alternatively, on the systems serving the system disk to the satellite, ensure that the value of the system parameter NISCS_MAX_PKTSZ is at least 12 bytes less than the maximum FDDI packet size.

The following systems are affected:

• Alpha satellite using an FDDI adapter that is booting from an OpenVMS Version 7.3 or higher Alpha or VAX system whose NISCS_MAX_PKTSZ value is greater than 4456.
• Alpha satellite using an FDDI adapter that is booting from a pre-OpenVMS Version 7.3 system, which is serving a system disk via FDDI, and the value of NISCS_MAX_PKTSZ minus NISCS_LAN_OVRHD is greater than 4456. The served system disk may be running OpenVMS Version 7.3 or higher, or an earlier version. The problem is more likely to occur if the system disk is Version 7.3 or higher, because NISCS_LAN_OVRHD is most likely set to 18 for prior versions.

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.22.4 Obtaining the Correct Status of Tape Compaction/Density on Fibre Channel

V7.3-1

In a shared initiator environment such as Fibre Channel provides, you can be sure that the SHOW DEVICE/FULL display reflects the correct compaction/density status on a given node only if you issue an INITIALIZE or MOUNT command or QIO function IO$_PACKACK from the node to the drive. These operations have the effect of refreshing the values in the SHOW DEVICE display.

In a shared initiator environment, users on different cluster nodes can, one at a time, use a SCSI tape drive in different compaction or density modes. For example, a user on Node A can allocate a drive and use it in compaction mode. After the Node A user deallocates the tape drive, a user on Node B can allocate that drive and request no compaction.

At that point, the SHOW DEVICE/FULL display on Node A will be stale, because it still shows that compaction is enabled even though the drive is now working in noncompacted mode. The displayed density value can become stale in the same way.

Therefore, to be sure that the compaction/density values in the SHOW/DEVICE display are accurate, refresh the values by issuing an INITIALIZE or MOUNT command or QIO function IO$_PACKACK from the node to the drive.

4.22.5 Tape /DENSITY Keywords Can No Longer Be Abbreviated

Beginning in OpenVMS Alpha Version 7.3-1, tape density keywords for the /DENSITY qualifier can no longer be abbreviated. The /DENSITY qualifier is present on several commands used for managing tapes, including INITIALIZE, BACKUP, MOUNT, and SET MAGTAPE.

An example of a tape /DENSITY keyword is DLT8000, which must be specified as follows:

$ INITIALIZE/DENSITY=DLT8000 $2$MGA1: MYTAPE

The density qualifier itself can still be abbreviated to /DENS.

4.22.6 New Error Message About Packet Loss

V7.3

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 or higher, 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, refer to Appendix F of the OpenVMS Cluster Systems manual.

4.22.7 Class Scheduler in a Mixed-Version Cluster

V7.3

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:

@SYS$SYSTEM:STARTUP SMISERVER

The following remedial kits correct this problem:

VMS721_MANAGE V2.0 (or higher)
VMS721H1_MANAGE V2.0 (or higher)

These remedial kits are available from the following web site:

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

4.22.8 Remedial Kits Needed for Cluster Compatibility

V7.3-1

Before you introduce an OpenVMS Version 7.3-1 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, Volume Shadowing, or Volume Shadowing with minicopy, additional remedial kits are required. Note that these kits are version-specific.

Table 4-1 lists the facilities that require remedial kits and the remedial kit names. Each remedial kit has a corresponding ReadMe file with the same name (file extension is .README).

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

http://www.support.compaq.com/

Table 4-1 Remedial Kits Required for Cluster Compatibility

Facility	File Name
OpenVMS Alpha Version 7.3
Update kit with all remedial kits except those below	DEC-AXPVMS-VMS73_UPDATE-V0100--4.PCSI
Cluster	DEC-AXPVMS-VMS73_CLUSTER-V0200--4.PCSI
DCL	DEC-AXPVMS-VMS73_DCL-V0200--4.PCSI
Shadowing	DEC-AXPVMS-VMS73_SHADOWING-V0200--4.PCSI
SYSINI	DEC-AXPVMS-VMS73_SYSINI-V0100--4.PCSI
XFC	VMS73_XFC-V0200
OpenVMS VAX Version 7.3
Audit Server	VAXAUDS01_073
DECwindows Motif	VAXDWMOTMUP01_073
MAIL	VAXMAIL01_073
Shadowing	VAXSHAD01_073
OpenVMS Alpha Version 7.2-2
Audit Server	DEC-AXPVMS-VMS722_AUDSRV-V0100--4.PCSI
CLI Utility	DEC-AXPVMS-VMS722_CLIUTL-V0100--4.PCSI
DECwindows Motif	DEC-AXPVMS-VMS722_DW_MOT-V0100--4.PCSI
Driver	DEC-AXPVMS-VMS722_DRIVER-V0100--4.PCSI
Fibre Channel/SCSI	DEC-AXPVMS-VMS722_FIBRE_SCSI-V0200--4.PCSI
IPC	DEC-AXPVMS-VMS722_IPC-V0100--4.PCSI
LAN	DEC-AXPVMS-VMS722_LAN-V0200--4.PCSI
RMS	DEC-AXPVMS-VMS722_RMS-V0200--4.PCSI
SYSLOA	DEC-AXPVMS-VMS722_SYSLOA-V0100--4.PCSI
Shadowing	DEC-AXPVMS-VMS722_SHADOWING-V0100--4.PCSI
OpenVMS Alpha Version 7.2-1H1
Update kit with all remedial kits except those below	DEC-AXPVMS-VMS721H1_UPDATE-V0500--4.PCSI
Backup utility	DEC-AXPVMS-VMS721H1_BACKUP-V0100--4.PCSI
Driver	DEC-AXPVMS-VMS721_DRIVER-V0300--4.PCSI
Fibre Channel/SCSI	DEC-AXPVMS-VMS721H1_FIBRE_SCSI-V0500--4.PCSI
Files 11	DEC-AXPVMS-VMS721H1_F11X-V0200--4.PCSI
RMS	DEC-AXPVMS-VMS721H1_RMS-V0700--4.PCSI
System with XFC/VCC compatibility support	DEC-AXPVMS-VMS721H1_SYS-V0500--4.PCSI
OpenVMS Alpha Version 7.2-1
Update kit of all remedial kits (available mid-July)	DEC-AXPVMS-VMS721_UPDATE-V400-4.PCSI
OpenVMS VAX Version 7.2
Update kit with all remedial kits except those below	VAXUPDATE01_072
Audit Server	VAXAUDS01_072
Backup utility	VAXBACK02_072
CLI Utility	VAXCLIU03_072
C RTL	VAXACRT02_072
DCE	DEC-VAXVMS-VAX_DCEECO_015_1-v0100--4.PCSI
DECnet OSI	DEC-VAXVMS-DNVOSIECO02-V0702--4.PCSI
DECwindows Motif	VAXDWMOTMUP01_072
Files 11	VAXF11x03_072
Fibre Channel	VAXDRIV02_072
LAT	VAXLAT01_072
LIBRTL	VAXLIBR01_072
MIME	VAXMIME02_072
ODS1	VAXODS1_01_072
PCSI	DEC-VAXVMS-VMS72_PCSI-V0101--4.PCSI
PThreads	VAXPTHR01_072
RMS	VAXRMS01_072
MANAGE	VAXMANA01_072
System with XFC/VCC compatibility support	VAXSYS02_072
Volume Shadowing	VAXSHAD03_072

4.22.9 Devices Not Configured if HSG Host Connection Table Is Full

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 Version 8.7 allows a maximum of 96 connections; ACS Version 8.5 allows a maximum of 64 connections; and ACS Version 8.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.

4.22.10 KGPSA NVRAM Errors with Console V5.6 and V5.7 Corrected in V5.8

V7.3-1

The problems described in this release note have been corrected in the console firmware Version 5.8.

When you use Version 5.6 or Version 5.7 of the console, you will see the error message kgpsaa0.0.0.2.4 - Nvram read failed , when the console KGPSA driver starts or when OpenVMS shuts down. 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 Version 5.6. As of Version 5.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.

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

V7.3-1

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 4-2 for setting these system parameters.

Table 4-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	At least 3 x MSCP_CMD_TMO
SHADOW_SYS_TMO	At least 3 x MSCP_CMD_TMO
MVTIMEOUT	At least 4 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

V7.3-1

Previously, if you mounted a Fibre Channel or SCSI device, a volume rebuild was sometimes performed even though the volume had been 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

This problem has now been corrected.

	privacy and legal statement
6652PRO_006.HTML