|Document revision date: 19 July 1999|
OpenVMS now supports Fibre Channel on several AlphaServer models. For detailed information about Fibre Channel support, including configuration requirements and restrictions, refer to the Guidelines for OpenVMS Cluster Configurations manual for OpenVMS Alpha Version 7.2-1.
For the most up-to-date Fibre Channel documentation, refer to the OpenVMS Fibre Channel web site:
Multipath failover support is for failover between multiple paths that might exist between an OpenVMS system and certain types of disk devices. Multipath failover increases availability. If the current path to a mounted disk fails, the system automatically fails over to the alternate path. A system in an OpenVMS Cluster system can access the supported disk types through its direct paths. Multipath failover for MSCP served paths is not supported.
Table 2-2 shows the progression of multipath support for SCSI and Fibre Channel devices, starting with SCSI support in OpenVMS Alpha Version 7.2.
|Component||OpenVMS Alpha Version 7.2||OpenVMS Alpha Version 7.2 + HW01 Remedial Kit||OpenVMS Alpha Version 7.2-1|
|Shadowing of multipath SCSI and multipath FC devices||No||No||Yes|
|Failover from direct to MSCP served paths (SCSI or FC)||No||No||No|
Multipath failover support was introduced in OpenVMS Alpha Version 7.2 for SCSI devices. This support was extended to Fibre Channel devices in the OpenVMS Alpha Version 7.2 HW01 Remedial Kit and is now integrated into OpenVMS Alpha Version 7.2-1.
In addition, this release introduces failover support for shadowed SCSI or Fibre Channel disk devices. Shadowed disk devices are devices attached to an OpenVMS Alpha system that is using Volume Shadowing for OpenVMS. Volume Shadowing for OpenVMS ensures that data is available to applications and users by duplicating data on multiple disks.
For more information about multipath failover support, see the Guidelines for OpenVMS Cluster Configurations manual for OpenVMS Alpha Version 7.2-1. For the most up-to-date multipath documentation, refer to the OpenVMS Fibre Channel web site where the updated multipath and Fibre Channel chapters are posted:
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 is Version 5.3 or 5.4, depending on the requirement of the AlphaServer.
The Digital Modular Computing Component (DMCC) systems will provide
boot support for devices with an HSZ allocation class in a future
version of console firmware.
2.3.3 MEMORY CHANNEL Version 2.0 Support
OpenVMS Alpha Version 7.2-1 supports the following MEMORY CHANNEL Version 2.0 features:
The OpenVMS Alpha Version 7.2-1 release is recommended for MEMORY CHANNEL Version 2.0 hardware support. Although MEMORY CHANNEL Version 2.0 is supported on OpenVMS Alpha Version 7.2 (the previous release), the final qualification of MEMORY CHANNEL Version 2.0 hardware was completed on systems running OpenVMS Alpha Version 7.2 with the OpenVMS Alpha V7.2 HW01 Remedial Kit, which is incorporated into OpenVMS Alpha Version 7.2-1.
OpenVMS support of MEMORY CHANNEL Version 2.0 includes the improvements introduced in support of MEMORY CHANNEL Version 1.5 hardware:
Note that you can configure a computer in an OpenVMS Cluster system with both a MEMORY CHANNEL Version 1.5 hub and a MEMORY CHANNEL Version 2.0 hub. However, the version number of the adapter and the cables must match the hub's version number for MEMORY CHANNEL to function properly.
For more information about MEMORY CHANNEL, refer to the Guidelines for OpenVMS Cluster Configurations
manual for OpenVMS Alpha Version 7.2-1.
2.3.4 Gigabit Ethernet Support
Gigabit Ethernet technology addresses congestion experienced at the backbone and server levels by today's networks.
OpenVMS Alpha Version 7.2-1 provides run-time support for the DIGITAL PCI-to-Gigabit Ethernet adapter (DEGPA). The DEGPA incorporates a new technology that transfers data at a rate of one gigabit per second---ten times the rate of a Fast Ethernet adapter.
Support for the DEGPA was introduced in the OpenVMS Alpha Version 7.1-2 release. For OpenVMS Alpha Version 7.2, support for the DEGPA became available with the OpenVMS Alpha Version 7.2 HW01 Remedial Kit and is now incorporated into OpenVMS Alpha Version 7.2-1.
The DEGPA is supported on single systems and as a cluster interconnect. The nodes in a Gigabit Ethernet OpenVMS Cluster system are connected to a Gigabit Ethernet switch. If there are only two nodes, they can be connected point-to-point so that no switch is needed.
For more information about Gigabit Ethernet support, including
configuration requirements and restrictions, see Chapter 3 of this
manual and the Guidelines for OpenVMS Cluster Configurations manual for OpenVMS Alpha Version 7.2-1.
2.4 Fast Ethernet Support
Support for Compaq's Fast Ethernet Network Interface Cards (NICs) based on Intel's i8255x Ethernet controllers has been added to the OpenVMS Alpha Version 7.2-1 release. These NICs replace the end-of-life DE500 family of adapters. These PCI based NICs support 10/100BaseTX, 100BaseFX, Full Duplex, Half Duplex, and Auto Negotiation.
OpenVMS displays these devices as EIx0 devices, where x is the controller's unit letter. The device drivers for these devices are SYS$EIDRIVER.EXE for the run-time environment and SYS$EIBTDRIVER.EXE for LAN booting.
The SRM console provides an environment variable for setting the mode of operation. The variable is EIx0_MODE, where x is the controller's unit letter. Only newer Alpha platforms will provide console support for these NICs.
The supported NICs include:
The DE600-AA NIC is also known as the NC3123 and is based on the i82559 Ethernet controller. This is a single port NIC using a standard RJ45 connector. This NIC supports 10/100BaseTX, Full Duplex, Half Duplex, and Auto Negotiation.
The DE602-AA NIC is also known as the NC3131 and is based on the i82558 Ethernet controller. This is a dual port NIC using two standard RJ45 connectors. This NIC supports 10/100BaseTX, Full Duplex, Half Duplex, and Auto Negotiation. It also provides support for an additional daughter card, which allows one PCI slot to be configured with one of the following:
The DE602-TA NIC daughter card, also known as the NC3132, should be used with the DE602-AA. This is a dual-port card using two standard RJ45 connectors. This card supports 10/100BaseTX, Full Duplex, Half Duplex, and Auto Negotiation.
The DE602-FA NIC daughter card, also known as the NC3133, should be
used with the DE602-AA. This is a single-port card using one standard
SC connector for use with multimode fiber. This card supports
100BaseFX, Full Duplex, and Half Duplex.
2.5 Netscape FastTrack Web Server Version 3.01A for OpenVMS Alpha
In OpenVMS Version 7.2, Compaq provided Netscape FastTrack Web Server Version 3.01 for OpenVMS Alpha, an easy-to-use web server that enabled you to quickly establish a web presence and deploy intranet solutions. It combined the high performance and reliability of an open Internet standards-based web engine with the ability to quickly and easily set up and publish a sophisticated web site. Within minutes you could run FastTrack Version 3.01 and serve web pages across the Internet and within an intranet. Netscape Navigator Gold, included with FastTrack, makes it easy to create web pages and use the One Button Publish feature to publish them.
With OpenVMS Alpha Version 7.2-1, Netscape FastTrack Web Server Version 3.01A for OpenVMS Alpha (the latest release of FastTrack) allows you to deploy and manage multiple FastTrack servers in a clustered environment. You can easily manage many different Netscape servers from a single administration server.
For more information about Netscape FastTrack, visit the FastTrack web site and refer to the FastTrack Server for OpenVMS Alpha---OpenVMS Supplement and the FastTrack Server for OpenVMS Alpha---Release Notes documents.
The Availability Manager is a new version of the tool known as DECamds with a new Java-based interface. The Availability Manager is a system management tool that allows you to monitor one or more OpenVMS (or Windows NT) nodes on an extended local area network (LAN) from either an OpenVMS or a Windows NT system.
The Availability Manager helps system managers and analysts target a specific node or process for detailed analysis. This tool collects system and process data from multiple OpenVMS nodes simultaneously; it then analyzes the data and uses a Java graphical user interface (GUI) to display the output.
For more information, see the Availability Manager web site:
This chapter contains OpenVMS Alpha Version 7.2-1 release notes that
you should review before installing or upgrading the operating system.
Read the OpenVMS Version 7.2 release notes before you install, upgrade,
or use Version 7.2-1.
3.1 Correction to the BACKUP Application Programming Interface (API)
The BACKUP API was introduced in the OpenVMS Version 7.1 release and is documented in the OpenVMS Utility Routines Manual manual.
For the OpenVMS Versions 7.1-2 and 7.2 releases, certain item codes and symbol definitions were inadvertantly changed in an incompatible manner. This change means that applications using the BACKUP API are not compatible across the stated releases.
With OpenVMS Version 7.2-1, the BACKUP API definitions were corrected and are now compatible with their original release. However, applications built using BACKUP API on OpenVMS Versions 7.1-2 and 7.2 must be recompiled to work on OpenVMS Alpha Version 7.2-1. Remedial kits are available to correct the BACKUP API definitions for systems remaining on OpenVMS Versions 7.1-2 or 7.2.
Note that this correction applies to applications that use the BACKUP
API. The use of the BACKUP command through the DCL interface is not
3.2 BACKUP/JOURNAL Failure Corrected
In OpenVMS Version 7.2, using the BACKUP/JOURNAL command to back up a moderate number of files to a tape saveset resulted in a failure with an ACCVIO error message. However, backing up a saveset to disk did not cause a failure.
This BACKUP/JOURNAL failure was due to an OpenVMS Version 7.2
performance enhancement that deleted Parallel File Lists (PFLs) for a
group before all references to the PFLs were completed. This problem
has been fixed in OpenVMS Version 7.2-1.
3.3 Cluster Compatibility: Remedial Kits Needed for Versions 6.2, 7.1, 7.1-2, and 7.2
Remedial kits must be applied to your systems running OpenVMS Versions 6.2, 7.1, 7.1-2, and 7.2 prior to introducing an OpenVMS Version 7.2-1 system into an OpenVMS Cluster system. For Fibre Channel support, version-specific kits are also required.
Table 3-1 indicates the facility affected, the name and location of the remedial kit file, and the location of the documentation. Note that the documentation listed, except for the Version 7.1 Release Notes, is available on the documentation CD-ROM that is included in your kit. All the documentation listed is also available on the OpenVMS web site.
For kit locations listed on the World Wide Web (WWW), download the specified kit from the following Internet site:
|Facility||File Name||Kit Location||Documentation|
DEC-AXPVMS-VMS712_PORTS-V0100--4.PCSI (Alpha 7.1-2)
DEC-AXPVMS-VMS72_PORTS-V0100--4.PCSI (Alpha 7.2)
Alpha V7.2 CD#2
VAX 7.2 CD
|Version 7.2 Release Notes, Section 220.127.116.11|
ALPDRIV20_062 (Alpha 6.2)
ALPDRIV11_071 (Alpha 7.1)
DEC-AXPVMS-VMS712_DRIVER-V0100--4.PCSI (Alpha 7.1-2)
VAXDRIV07_062 (VAX 6.2)
VAXDRIV05_071 (VAX 7.1)
VAXDRIV01_072 (VAX 7.2)
|WWW||Fibre Channel and Multipath chapters of Guidelines for OpenVMS Cluster Configurations|
ALPMONT01_062 (Alpha 6.2)
ALPMONT02_071 (Alpha 7.1)
VAXMONT01_062 (VAX 6.2)
VAXMONT02_071 (VAX 7.1)
|WWW||Version 7.2 Release Notes, Section 18.104.22.168|
ALPMOUN05_062 (Alpha 6.2)
ALPMOUN07_071 (Alpha 7.1)
VAXMOUN04_062 (VAX 6.2)
VAXMOUN05_071 (VAX 7.1)
DEC-AXPVMS-VMS712_MOUNT96-V0100--4.PCSI (Alpha 7.1-2)
DEC-AXPVMS-VMS72_MOUNT96-V0100--4.PCSI (Alpha 7.2)
|WWW||Version 7.2 Release Notes, Section 22.214.171.124|
ALPSHAD08_062 (Alpha 6.2)
ALPSHAD05_071 (Alpha 7.1)
VAXSHAD08_062 (VAX 6.2)
VAXSHAD05_071 (VAX 7.1)
|WWW||Version 7.1 Release Notes, Section 126.96.36.199 and Version 7.1 New Features, Section 3.11.10|
If you plan to use Volume Shadowing for OpenVMS with this release, Compaq recommends that you install the latest remedial kit for Volume Shadowing for OpenVMS. You can obtain the latest remedial kit from the following World Wide Web (WWW) location:
The information in this section corrects and replaces Section 188.8.131.52 in the OpenVMS Version 7.2 Release Notes.
Users with the EXTAUTH bit set in their SYSUAF account record cannot use explicit access control strings with systems running DECnet unless their externally authenticated password is all uppercase characters.
For example, if you enter the following command:
$ DIRECTORY nodename"username password"::
where nodename is a system running DECnet and username is an EXTAUTH account, DECnet converts the string supplied in the password to uppercase characters before it is passed to the external authentication agent (a PATHWORKS or NT domain controller).
There are two workarounds:
Attempts to add a Gigabit Ethernet node to an OpenVMS Cluster 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 by 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 <nodename> to boot, while the booting node displays the message 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:
On Compaq AlphaServer DS10, Compaq AlphaServer DS20, and Compaq AlphaServer ES40 systems, you cannot use the following system routines to perform I/O tribyte reads and writes:
If a device driver calls any of these system routines with a length of three, you must use one of the following methods instead---depending on your I/O cards characteristics:
For IOC$READ_IO and IOC$READ_PCI_CONFIG:
For IOC$WRITE_IO and IOC$WRITE_PCI_CONFIG:
Note that AlphaServer 8200/8400 and GS60/140 systems with Alpha 21264
CPUs support tribyte reads and writes.
3.8 I/O to Unaligned Words in PCI Space Is Not Allowed
This note applies to Compaq AlphaServer DS10, DS20, and ES40 systems.
When device drivers call the IOC$CRAM_CMD, IOC$READ_IO, and
IOC$WRITE_IO system routines with the IOC$K_WORD or IOC$K_WORD_LANED
parameters, the I/O address must be on a natural, word-aligned
boundary. (In other words, the I/O address must be an even number). If
the I/O address is an odd number, these system routines return
3.9 MOUNT Timing Change
To support multipath failover on SCSI disks, the following changes have been made in how MOUNT waits for disks to become ready:
Note that under certain failure conditions, the SCSI disk driver may
take up to 30 seconds to return an error status. This can cause MOUNT
to take up to 30 seconds to invoke operator assist or respond to
Ctrl/y. Also, the /NOASSIST wait time under these error conditions can
be as long as 60 seconds.
3.10 Mount Verification Failure of Write-Locked Devices
If a device is write-locked when you mount it (either by entering MOUNT/NOWRITE or through the mounting of a former member of a shadow set), mount verification fails with a wrong volume status. This often occurs when a shadow set member has been removed from the set and is being used as a backup source device.
The mount verification fails because the device's lockname could not be stored in the disk's SCB (because the disk is write-locked). As a result, the SCB lockname and the VCB lockname for the device do not match, and the wrong volume error is generated.
To avoid this problem, mount the disk write enabled by removing the /NOWRITE qualifier, or by adding the /OVERRIDE=SHADOW qualifier. This allows MOUNT to update the SCB of the device with the correct lockname. If the device goes into mount verification, it will not fail because of a mismatch.
|privacy and legal statement|