HP OpenVMS Systems Documentation
HP OpenVMS Alpha Version 7.3--2 Release Notes
4.13.3 SCSI Tape Drives: MEDOFL Errors After Tape Dismount
Occasionally, a "%SYSTEM-F-MEDOFL, medium is offline" error can occur on the first command executed on a SCSI tape after the tape has been dismounted using a DISMOUNT/NOUNLOAD command. For example, this can happen when you attempt to initialize or mount the tape immediately after dismounting it. The error is returned because the tape is still rewinding as part of the dismount operation.
If the tape unit is a member of a multipath set, a path switch might occur (instead of a MEDOFL error) as part of multipath recovery. These MEDOFL errors and path switches are more likely to occur on certain models of SCSI tape drives such as the LTO-2 HP Ultrium 460.
If a path switch occurs on the first command after a tape DISMOUNT
command, this indicates that the tape has recovered and no user action
is required. If a MEDOFL error occurs, retry the failed command after
the tape finishes rewinding. The SCSI tape driver will be modified in a
future remedial kit to eliminate the need for such manual retries.
This note updates Table 8-3 (Data Requested by CLUSTER_CONFIG_LAN.COM and CLUSTER_CONFIG.COM) in the OpenVMS Cluster Systems manual.
The documentation specifies a limit on the number of hexadecimal digits you can use for computers with direct access to the system disk. The limit is correct for VAX computers but not for Alpha computers.
The command procedure prompts for the following information:
The documentation currently states:
Press Return to accept the procedure-supplied default, or specify a name in the form SYSx:
The limit on the range of hexadecimal values with direct access to the system disk is correct for VAX computers. For Alpha computers with direct access to the system disk, the valid range of hexadecimal values is much larger. It includes both the VAX range of 1 through 9 or A through D, and also the range 10 through FFFF. Note that SYSE and SYSF are reserved for system use.
The OpenVMS Cluster Systems manual will include this information in its next
Changes to OpenVMS Version 7.3 (or higher) may affect satellite booting over FDDI for satellites running versions of OpenVMS earlier than Version 7.3. 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:
4.13.6 PEdriver Error Message Change
In the final build of OpenVMS Version 7.3-2, it was discovered that a last-minute bug changed the way the error message is displayed when PEdriver is closing a virtual circuit. Prior to Version 7.3-2, the error message dislayed the remote node name. For example:
The Version 7.3-2 message displays PEdriver's internally assigned number for the remote port instead of the remote node name. For example:
Unfortunately, there is no easy way to determine the mapping between remote port numbers and the name of the node associated with that numeric value.
This problem will be fixed in the next release.
Starting with OpenVMS Version 7.3-2, a PEdriver channel whose priority is -128 will not be used for cluster communications. Therefore, you can disable cluster communications for a particular channel by using SCACP or the Availability Manager to set the channel's priority to -128.
A channel's priority is the sum of the management priorities assigned
to the local LAN device and the channel itself. Therefore, you can
assign any combination of channel and LAN device management priority
values to achieve a total of -128.
In rare cases, in an OpenVMS Cluster configuration with both CI and multiple FDDI, 100 Mb/s or Gb/s Ethernet-based circuits, you might observe that SCS connections are moving between CI and LAN circuits at intervals of approximately 1 minute. This frequent circuit switching can result in reduced cluster performance and may trigger mount verification of shadow set members.
PEdriver can detect and respond to LAN congestion that persists for a few seconds. When it detects a significant delay increase or packet losses on a LAN path, the PEdriver removes the path from use. When it detects that the path has improved, it begins using it again.
Under marginal conditions, the additional load on a LAN path resulting from its use for cluster traffic may cause its delay or packet losses to increase beyond acceptable limits. When the cluster load is removed, the path might appear to be sufficiently improved so that it will again come into use.
If a marginal LAN path's contribution to the LAN circuit's load class increases the circuit's load class above the CI's load class value of 140 when the marginal path is included (and, conversely, decreases the LAN circuit's load class below 140 when the path is excluded), SCS connections will move between CI and LAN circuits.
You can observe connections moving between LAN and CI circuits by using SHOW CLUSTER with the CONNECTION and CIRCUITS classes added.
If excessively frequent connection moves are observed, you can use one of the following workarounds:
4.13.9 Gigabit Ethernet Switch Restriction in an OpenVMS Cluster System
Attempts to add a Gigabit Ethernet node to an OpenVMS Cluster system 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.
In addition, the messages that are displayed may be misleading. If the node is being added using 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 node-name to boot," while the booting node displays "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:
4.13.10 Multipath Tape Failover Restriction
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.
Automatic path switching is not implemented in OpenVMS Alpha Version 7.3-1 or higher for SCSI medium changers (tape robots) attached to Fibre Channel using a Fibre-to-SCSI tape bridge. Multiple paths can be configured for such devices, but the only way to switch from one path to another is to use manual path switching with the SET DEVICE/SWITCH command.
This restriction will be removed in a future release.
OpenVMS provides Galaxy support on AlphaServer ES47, ES80, and GS1280 systems. Galaxy support on these systems requires Version 6.6 firmware and may require additional Version 7.3-2 patch kits. The firmware can be obtained from the following website:
Eventually, the Version 6.6 firmware will also be available on CD-ROM.
The OpenVMS Graphical Configuration Manager (GCM) is not supported for
AlphaServer ES47/ES80/GS1280 Galaxy configurations at this time.
However, the Graphical Configuration Utility (GCU) is supported. This
restriction will be removed in the future.
The Smart Array 5300 (KZPDC) Backplane Raid Controller is currently supported only as a data device in ES47/ES80/GS1280 Galaxy configurations. Boot and crash dump capability are not supported at this time on these controllers. The goal is to provide support with corrected firmware or corrected OpenVMS software.
For information about configuring a Galaxy on an AlphaServer
ES47/ES80/GS1280 system, see the HP OpenVMS Alpha Partitioning and Galaxy Guide.
Hard partition support, which requires a firmware update and a patch kit, has been qualified and is now available on the AlphaServer ES47/ES80/GS1280 systems. The HP OpenVMS Alpha Partitioning and Galaxy Guide provides more information about the firmware and patch kit requirements and describes how to configure hard partitions on these systems.
4.14.4 Shared-Memory Global Section Creation Can Return Incorrect Status
Calls to SYS$CRMPSC_GDZRO_64 with the flag SEC$M_SHMGS can fail with status SS$_INFMEM instead of status SS$_INSF_SHM_REG.
The most likely explanation for this error is that the Galaxy shared-memory code has run out of internal SHM_REG data structures. To correct this condition, increase the value of the SYSGEN parameter GLX_SHM_REG and reboot all Galaxy instances with this larger parameter value.
Note that each SHM_REG data structure consumes only a small amount of memory. Therefore, you can safely increase this parameter to a relatively high number (for example, double the number of expected shared-memory regions) to avoid changing this parameter in small increments and having to reboot the entire Galaxy more than once.
In a mixed-version cluster, driver kits
or later and
or later should be installed to avoid Galaxy shared-memory interconnect
On AlphaServer ES40 Galaxy systems, you cannot write a raw
(uncompressed) dump from instance 1 if instance 1's memory starts at or
above 4 GB (physical). Instead, you must write a compressed dump.
If you do not turn off Fast Path on instance 1, I/O on instance 1 will
hang when instance 0 is rebooted. This hang will continue until the PCI
bus is reset and instance 1 rebooted. If there is shared SCSI or Fibre
Channel, I/O will hang on the sharing nodes and all paths to those
devices will be disabled.
The OpenVMS Alpha Version 7.3-2 installation includes OpenVMS
Management Station Version 3.2B, which is also available on the web.
If you create eight or more volatile subkeys in a key tree and then reboot a standalone system or a cluster, the OpenVMS Registry server can corrupt a Version 2 format Registry database when the server starts up after the reboot.
To avoid this problem, do one of the following:
Note that Advanced Server for OpenVMS and COM for OpenVMS do not create
The following release notes pertain to RMS Journaling for OpenVMS.
For more information about RMS Journaling, refer to the RMS Journaling for OpenVMS Manual.
You can access this manual on the OpenVMS Documentation CD-ROM (in the
archived manuals directory).
Because DECdtm Services is not supported in a multiple kernel threads
environment and RMS recovery unit journaling relies on DECdtm Services,
RMS recovery unit journaling is not supported in a process with
multiple kernel threads enabled.
Prior to Version 7.2, recovery unit (RU) journals were created temporarily in the [SYSJNL] directory on the same volume as the file that was being journaled. The file name for the recovery unit journal had the form RMS$process_id (where process_id is the hexadecimal representation of the process ID) and a file type of RMS$JOURNAL.
The following changes have been introduced to RU journal file creation in OpenVMS Version 7.2:
These changes reduce the directory overhead associated with journal file creation and deletion.
The following example shows both the previous and current versions of journal file creation:
Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
If RMS does not find either the [SYSJNL] directory or the node-specific
directory, RMS creates them automatically.
OSI nodes that host recovery unit journaled files that are to be
accessed remotely from other nodes in the network must define SYS$NODE
to be a Phase IV-style node name. The node name specified by SYS$NODE
must be known to any remote node attempting to access the recovery unit
journaled files on the host node. It must also be sufficiently unique
for the remote node to use this node name to establish a DECnet
connection to the host node. This restriction applies only to recovery
unit journaled files accessed across the network in an OSI or mixed OSI
and non-OSI environment.
You can use after-image (AI) journaling to recover a data file that becomes unusable or inaccessible. AI recovery uses the AI journal file to roll forward a backup copy of the data file to produce a new copy of the data file at the point of failure.
In the case of either a process deletion or system failure, an update can be written to the AI journal file, but not make it to the data file. If only AI journaling is in use, the data file and journal are not automatically made consistent. If additional updates are made to the data file and are recorded in the AI journal, a subsequent roll forward operation could produce an inconsistent data file.
If you use Recovery Unit (RU) journaling with AI journaling, the automatic transaction recovery restores consistency between the AI journal and the data file.
Under some circumstances, an application that uses only AI journaling can take proactive measures to guard against data inconsistencies after process deletions or system failures. For example, a manual roll forward of AI-journaled files ensures consistency after a system failure involving either an unshared AI application (single accessor) or a shared AI application executing on a standalone system.
However, in a shared AI application, there may be nothing to prevent
further operations from being executed against a data file that is out
of synchronization with the AI journal file after a process deletion or
system failure in a cluster. Under these circumstances, consistency
among the data files and the AI journal file can be provided by using a
combination of AI and RU journaling.
You cannot update variable fixed-length control (VFC) sequential files
when using before-image or recovery unit journaling. The VFC sequential
file format is indicated by the symbolic value FAB$C_VFC in the
FAB$B_RFM field of the FAB.
In OpenVMS Version 7.1 and higher, if you execute the DCL command DIRECTORY/SECURITY or DIRECTORY/FULL for files that contain Advanced Server (PATHWORKS) access control entries (ACEs), the hexadecimal representation for each Advanced Server ACE is no longer displayed. Instead, the total number of Advanced Server ACEs encountered for each file is summarized in the message, "Suppressed n PATHWORKS ACEs."
To display the suppressed ACEs, use the SHOW SECURITY command. You must have the SECURITY privilege to display these ACEs. Note that, in actuality, the command displays OpenVMS ACEs, including the %x86 ACE that reveals the Windows NT® security descriptor information. The Windows NT security descriptor information pertains to the Advanced Server.