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:

http://www.openvms.digital.com/openvms/fibre/index.html

2.3.2 Multipath Failover Support

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.

Table 2-2 Multipath Support for SCSI and FC Devices

Component	OpenVMS Alpha Version 7.2	OpenVMS Alpha Version 7.2 + HW01 Remedial Kit	OpenVMS Alpha Version 7.2-1
SCSI devices	Yes	Yes	Yes
FC devices	No	Yes	Yes
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:

http://www.openvms.digital.com/openvms/fibre/index.html

2.3.2.1 Boot Support for 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 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:

• New adapter (CCMAB--AA) and a new hub (CCMHB--AA)
• Simultaneous communication between four sender-receiver pairs
• Longer cables for a radial topology up to 3 kilometers
  • Copper cables (3 sizes) up to a 10-meter (32.8 ft) topology
  • Fiber-optic cables up to a 3-kilometer topology
  
  Fiber-optic cables up to 30 meters are available from Compaq. Fiber-optic cables up to 3 kilometers are available from other vendors.

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:

• Improved performance of MEMORY CHANNEL port reinitialization
• Improved error formatting and timestamps added to all error messages

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:

• DE600-AA NIC
• DE602-AA NIC
• DE602-TA NIC
• DE602-FA NIC

DE600-AA NIC

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.

DE602-AA NIC

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:

• Two 10/100BaseTX ports
• Four 10/100BaseTX ports
• Two 10/100BaseTX port and one 100BaseFX port

DE602-TA NIC

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.

DE602-FA NIC

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.

http://www.openvms.digital.com/openvms/products/ips/register_fasttrack.html

2.6 Availability Manager Version 1.2

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:

http://www.openvms.digital.com/openvms/products/availman

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 affected.

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:

http://www.service.digital.com/html/patch_public.html

Table 3-1 Remedial Kits Required for Cluster Compatibility

Facility	File Name	Kit Location	Documentation
OpenVMS Cluster	ALPCLUSIO01_062 VAXCLUSIO01_062 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 WWW	Version 7.2 Release Notes, Section 4.14.1.2
Fibre Channel	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
Monitor	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 4.11.1.1
Mount	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 4.12.1.2
Volume Shadowing	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 4.15.1.2 and Version 7.1 New Features, Section 3.11.10

3.4 Volume Shadowing for OpenVMS: Remedial Kit Recommended

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:

http://www.service.digital.com/html/patch_public.html

3.5 DECnet Requirement

The information in this section corrects and replaces Section 4.8.2.3 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:

• If you are using DECnet and you want to use explicit access control strings, define an uppercase NT password.
• Set up a proxy account on your DECnet nodes so that you do not have to use explicit access control strings to perform functions.

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:

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

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:

• IOC$READ_PCI_CONFIG
• IOC$WRITE_PCI_CONFIG
• IOC$READ_IO
• IOC$WRITE_IO

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:

• Use a longword read, and mask out the byte.
• Do a combination of word and byte reads, and append the data.

For IOC$WRITE_IO and IOC$WRITE_PCI_CONFIG:

• Read a longword, modify the tribyte, and rewrite the longword.

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 SS$_BADPARAM.

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:

• For MOUNT/NOASSIST commands, MOUNT waits up to 30 seconds for a disk device to become ready. If the device is not ready after 30 seconds, the command fails with a DEVOFFLINE or MEDOFL error. For tape devices, the wait time is 120 seconds. In previous versions of OpenVMS, a MOUNT/NOASSIST command failed immediately.
• For MOUNT/ASSIST commands, device offline and medium offline conditions immediately invoke operator assist as in previous OpenVMS versions.
• For disk devices, the wait time for errors, such as VOLINV and DEVBUSY, has been reduced to 30 seconds. After 30 seconds, MOUNT either invokes operator assist or fails, depending on whether /NOASSIST or /ASSIST was specified.

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
6614PRO_001.HTML