|
HP OpenVMS Systems Documentation |
|
OpenVMS Version 7.3 Release Notes
5.8.4 Workstations in OpenVMS ClustersV7.3 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:
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:
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:
For additional PEDRIVER troubleshooting information, see Appendix F of
the OpenVMS Cluster Systems manual.
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:
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.
V7.3 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.
5.9.4 Fibre Channel Remedial Kits Support for SANWorks DRMOpenVMS 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.
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
5.9.6 OpenVMS Version 7.2-1 Installation Restrictions for Fibre ChannelV7.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:
5.9.7 Devices Not Configured if HSG Host Connection Table Is FullV7.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.
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:
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:
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.
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:
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:
This restriction also applies to SCSI devices on OpenVMS Alpha Version
7.1 systems, if the SCSI device names include a port allocation class.
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:
The device type in this case should be DEC HSG80.
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:
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:
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 ClassAll 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.
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.
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.
The following example shows the use of the recommended settings:
5.9.15 Multipath Devices: Volume Rebuilds During Mount OperationV7.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:
Workaround A user with privileges can work around this problem by issuing an I/O to the device immediately before dismounting it. For example:
5.9.16 Multipath Device Dismount Problem with Volume ShadowingV7.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:
This error does not occur under the following conditions:
A user with privileges can work around this problem by issuing an I/O to the device immediately before dismounting it. For example:
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||