HP OpenVMS Systems

This section briefly describes these features. For additional details please refer to the OpenVMS V7.1 New Features Manaual, and the OpenVMS V7.1 Release Notes.

Note that OpenVMS V7.1 supports mixed version clusters. V7.1 nodes can be configured with nodes runing V7.0 and any variant of V6.2-xxx.

Memory Channel

A new feature for OpenVMS Cluster Software V7.1 is the support of Memory Channel as a cluster interconnect. Unlike the other cluster interconnects, which are network based, Memory Channel uses a "shared memory" paradigm of operation. This permits very high bandwith with low latency, over short distances. The current hardware supports up to eight nodes, each configured with a Memory Channel adapter and 10 foot cable connected to a Memory Channel hub in a radial topology.

The following rules should be observed when configuring an OpenVMS Memory Channel Cluster:

It is not possible to connect storage directly to a Memory Channel. Consequently, so another interconnect is required for storage. This can be any of the other OpenVMS storage interconnects (CI, DSSI, SCSI).

Refer to the Memory Channel chapter of the Systems and Options catalog for ordering information. Configuration examples of Memory Channel can be seen in the Cluster Overview section

The high bandwidth of Memory Channel, allied with its shared-memory style of operation, means that in a future release of OpenVMS Compaq hopes to provide a user accessible API which will permit applications to create and use shared-memory sections. This API is currently under development.

New SCSI device naming

OpenVMS V7.1 provides a new, optional, method for naming SCSI storage devices. The new naming scheme is designed specifically to allow much larger SCSI Clusters to be configured easily and flexibly without experiencing device name conflicts (for example, multiple disks having the same device name, or a single disk having multiple names).

By default OpenVMS V7.1 continues to use the traditional SCSI device naming scheme.

Traditional SCSI device names are of the form DKcnmm, where "c" is the controller letter (A, B, C...), "n"is the SCSI ID (0-7), and "mm" is the device LUN (logical unit number). So a typical device name would be of the form: DKC102 - this being LUN 2 of SCSI ID 1 on the third SCSI controller. In cluster configurations a node identifier is added to the front of the device name. The node identifier can take two forms, the node name or the node allocation class (a number) - for example, CURLY$DKC102 or $66$DKC102. Node allocation classes are used when there is more than one path to a disk. In large SCSI cluster configurations this scheme can produce the conflicts mentioned above.

With the new SCSI device naming scheme the device name has the same format with two differences:

(1) The controller letter is always "A", regardless of the physical adapter. In SCSI Clusters this permits any adapter on one node to be connected to any other adapter on another node (because the controller letters always match).

(2) Every shared (multi-host) SCSI bus can be given its own "port allocation class." This is not the same as the node allocation class, which is still used in the traditional manner for non-SCSI storage (ie, CI and DSSI). Since port allocation classes can be any number in the range 1-32767 a very large number of SCSI buses can be configured in a cluster, and there will never be any conflict of device names.

This feature is only available for Alpha systems (because SCSI Clusters are only available for Alpha systems). However a patch kit can be applied to VAX systems that are in mixed architecture clusters that permits them to access Alpha based SCSI disks that use the new naming feature.

SCSI 16 ID support

OpenVMS V7.1 supports the ability to address up to 16 IDs on a wide SCSI bus. In previous releases only 8 IDs could be addressed, regardless of whether the bus was wide or narrow. Naturally, this feature permits more devices to be configured per SCSI adapter.

SCSI Hub

The OpenVMS V7.1 documentation includes information on configuring a SCSI "hub." A hub comprises a BA356 StorageWorks rack that contains up to five DWZZB single-ended to FWD converters, and up to two power supplies. From each DWZZB a 20 meter FWD SCSI cable can be run to an Alpha system of HSZ controller. This results in a SCSI bus configured in a radial topology with a 20 meter radius. Each leg is individually terminated, simplifying maintenance. In many cases a SCSI hub will greatly simplify the configuration of large SCSI Cluster configurations.

Note that, although there is space available in the BA356 rack, a sixth DWZZB cannot be configured. This is due to the rating of the power supply. Also, 25 meter cables cannot be used due the SCSI restriction that nodes may not be more than 40 meters apart.

Lock Manager Enhancements

OpenVMS V7.1 increases many of the previous limits in the Distributed Lock Manager. Specifically, these are:

(1) An Authorize ENQLM of 32767 is taken to mean unlimited ENQLM. This permits large server applications to take out an unlimited number of locks.

(2) The LOCKIDTBL_MAX parameter is now obselete. The maximum number of locks a system may have it calculated at boot time, based on the size of the non-paged pool. To save pool space the Lock ID Table itself has been relocated to S2 space.

(3) The maximum value for RESHASHTBL (the size of the Resource Hash Table) is now effectively unlimited.

(4) There is no longer any limit on the number of sub-resources and sub-locks on a resource tree.

In combination these changes allow the lock manager to scale to a massive size, sufficient to handle the largest databases with ease.

New parameter to control Connection Manager credits

The new CLUSTER_CREDITS Sysgen parameter allows system managers of large heavily-loaded clusters to control the number of message credits extended by the Connection Manager. This will increase the lock manager performance of clusters that experience credit stalls (displayed by the Show Cluster utility), at the cost of an increase in non-paged pool consumption.

Increased CIPCA and KFPSA support

With OpenVMS V7.1 support for the CIPCA (PCI to CI adapter) has been increased. These increases have also been retrofitted to V6.2-1H3. The adapter limits are as follows:

In V7.1 it is permissable to add CIPCA adapters to AlphaServer 8000 systems configured with CIXCD adapters. This is the first time that two types of CI adapter have been supported in the same system. Additionally, the Fast Path feature, introduced in V7.0 for CIXCD adapters, has been extended to support the CIXCD. This feature can significantly enhanced the I/O throughput of a CIPCA based system.

Note that the recently announced HSJ50 controller includes support for 4K transfers. In combination with the 4K packet capability of the CIPCA the performance of the CI bus improves considerably. (Depending on load, configuration and application, the net bandwidth of the CI increases from approximately 8-10MB/sec to 14-15MB/sec.)

An AlphaServer 8000 system with a full compliment of CIPCA adapters, HSJ storage controllers and 4GB disks would have a storage capacity of over 55TB (terabytes)!

Additionally, the number of KFPSA (PCI to DSSI) adapters that are supported by OpenVMS V7.1 in a system has been increased from 4 (in V6.2-xxx) to 24. The number of adapters that can physically be connected may be limited by the number of PCI slots in the system.

V6.2-xxx hardware/software features now in V7.1

All the cluster features provided in the various V6.2-xxx variants (which were not in V7.0) are now available in V7.1. Refer to the V6.2-xxx section for information on these features.

Change in DECamds licensing

Prior to V7.1, DECamds was provided free with the OpenVMS Cluster Software product. The right to use DECamds came with the Cluster software license.

In response to customer demand DECamds is now available free with all OpenVMS systems, whether clustered or not.

DECamds is a multi-node, real-time, Motif-based, OpenVMS system monitoring, problem identification and resolution utility. Refer to the DECamds Users Manual in the OpenVMS manual set or information on DECamds.

OpenVMS Volume Shadowing enhancements

The OpenVMS Volume Shadowing product has been significantly enhanced in V7.1. It is much more robust and tolerant of many storage subsystem error conditions. These enhancements are available for V6.1-xxx systems via a patch kit. For V7.1, Volume Shadowing has also been enhanced to allow mini-merge of system disks. This feature increases the performance of system disk merge operations, and reduces the I/O consumption of these operations.