HP OpenVMS Systems Documentation
HP OpenVMS Alpha Version 7.3--2 Release Notes
4.19 Server Management Process (SMHANDLER)
The server management process, SMHANDLER, now starts automatically on Alpha systems that support it. System managers should remove references to the obsolete startup file, SYS$STARTUP:SYS$SMHANDLER_STARTUP.COM, from SYSTARTUP_VMS.COM or other site-specific startup files. This reference has been removed from SYSTARTUP_VMS.TEMPLATE.
On certain Alpha systems, the server management process is started to assist the system firmware in reporting and responding to imminent hardware failures. Failure conditions vary but typically include over-temperature conditions, fan failures, or power supply failures. SMHANDLER may report warning conditions to OPCOM, and may initiate a shutdown of OpenVMS if system firmware is about to power off a failing system. In most situations, a controlled shutdown of OpenVMS would be less disruptive than abrupt loss of system power.
To ensure the longest possible up time, system managers can set the
POWEROFF system parameter to 0. This prevents SMHANDLER from shutting
down OpenVMS on a failing system but does not prevent system firmware
from powering off the system.
Previously, enabling SYSGEN audits, or alarms, did not provide any
audits or alarms with information about the parameters being modified.
As of OpenVMS Version 7.3-2, this problem is corrected. Audits or
alarms now provide a list of the changed parameters along with their
old and new values.
The following release notes pertain to the SYSMAN utility.
When you use the SYSMAN command DUMP_PRIORITY LOAD to load the contents of the System Dump Priority registry into memory, any entries with a UIC specification of [group-id,*] (for example, [TCPIP$AUX,*]) are ignored --- even though the specification is correct. This will be fixed in a remedial kit for OpenVMS Alpha Version 7.3-2.
You can work around this problem by using the SYSMAN command DUMP_PRORITY MODIFY to remove ",*" from the System Dump Priority registry entry. For example:
This workaround creates the identical in-memory contents during a DUMP_PRORITY LOAD command. Any subsequent DUMP_PRIORITY SHOW command displays it as [group-id,*].
The workaround will continue to work even after the remedial kit is
The SYSMAN IO AUTOCONFIGURE command does not configure LUNs on an XP port when a Fibre Channel adapter on a booted host is given access to those LUNs. This problem occurs because of the way the XP array implements selective storage presentation.
You could configure the LUNs by rebooting the host, but any of the following safe, less disruptive workarounds will do the job and can be performed prior to executing SYSMAN IO AUTOCONFIGURE:
The first two options have the benefit of being seen by all host Fibre Channel adapters on the fabric that have been given access to the LUNs. However, these options also briefly block access to all other LUNs on the XP port and cause mounted volumes to go through Mount Verify.
The last option limits the disruption to those LUNs whose current path
is through the affected Fibre Channel adapter --- even those that are
not on the affected XP port --- but the process must be performed for
The following sections contain notes related to system parameters.
The following system parameters are new in OpenVMS Alpha Version 7.3-2:
Refer to online help for the definitions of these new parameters.
Definitions of the following system parameters have been modified in OpenVMS Alpha Version 7.3-2:
Refer to online help for changes in the definitions of these parameters.
The following system parameters have been removed in OpenVMS Alpha Version 7.2-3:
4.22.4 SCSNODE Parameter Size Now Strictly Enforced
Previously, the documented maximum size of 6 characters for the SYSGEN parameter SCSNODE was not strictly enforced. You could set SCSNODE to a name containing 8 characters, which could lead to device names being too long and producing undesirable effects.
The documented maximum of 6 characters is now strictly enforced. The
value of SCSNODE will be truncated by SYSBOOT if the size is set to
more than 6 characters in the system parameter file.
On AlphaServer GS series processors on OpenVMS systems prior to Version 7.3-1, system managers frequently saw pool expansion that increasing NPAGEDYN did not reduce. This problem was caused by leaving NPAGERAD at its default value of 0.
Starting with OpenVMS Version 7.3-1, when NPAGERAD is 0 (the default), the system calculates a value to use for NPAGERAD with the following formula:
This calculation gives more pool to the nonbase RADs than before and so
reduces the expansion of nonbase RAD pool.
On OpenVMS Alpha systems, the Terminal Fallback Facility (TFF) includes a fallback driver (SYS$FBDRIVER.EXE), a shareable image (TFFSHR.EXE), a terminal fallback utility (TFU.EXE), and a fallback table library (TFF$MASTER.DAT).
To start TFF, invoke the TFF startup command procedure located in SYS$MANAGER, as follows:
To enable fallback or to change fallback characteristics, invoke the Terminal Fallback Utility (TFU), as follows:
To enable default fallback to the terminal, enter the following DCL command:
OpenVMS Alpha TFF differs from OpenVMS VAX TFF in the following ways:
For more information about the Terminal Fallback Facility, refer to the
OpenVMS Terminal Fallback Utility Manual. You can access this manual on the OpenVMS Documentation
CD-ROM (in the archived manuals directory).
The User Environment Test Package (UETP) does not currently support DEGPA network devices. If you get an unsupported device error when running UETP and you have a DEGPA device, edit the UETPSUPDEV.DAT file in the SYSTEST directory, and add the following line just before the last line in the file:
Then rerun UETP. The device should now test properly.
Previously, if HELPLIB was in use during a VMSINSTAL installation,
messages were automatically sent to all users. VMSINSTAL has been
modified to check for logical name VMSINSTAL_NOBROADCAST. If the
logical name is set, VMSINSTAL will not send a reply to all users when
HELPLIB is in use.
The following release notes pertain to HP Volume Shadowing for OpenVMS,
also known as host-based volume shadowing (HBVS).
Volume Shadowing for OpenVMS supports device names whose ddc portion of the full device name of $alloclass$ddcu: is three characters.
Prior to this release, it was possible to create device names whose ddc portion of the full device name was longer, such as $1$DECRAM10:, and these devices mounted successfully. However, mounting such devices as part of a shadow set caused operational problems, such as %MOUNT-F-XSMBRS errors when other disks were added to the shadow set.
Starting with OpenVMS Alpha Version 7.3-2, the Mount utility enforces this three-character requirement for the ddc portion of the full device name during the initial attempt to mount the device. If you attempt to mount a device whose name does not conform to this requirement, the following error message is displayed:
4.26.2 Warning About Using SET SHADOW and SHOW SHADOW in DCL Command Procedures
The new DCL commands SET SHADOW and SHOW SHADOW will continue to evolve. In a future release, the default display and implementation of a SHOW SHADOW/FULL display will change the current formatting. Therefore, HP advises customers not to rely on parsing the current format of output in DCL command procedures to obtain information about the shadow set. Instead, consider using the F$GETDVI lexical function to obtain many of the items displayed by the SHOW SHADOW command.
Furthermore, the behavior of the SET SHADOW command will also change. In addition to other new qualifiers, a new /ALL qualifier will be required if SET SHADOW is used to set characteristics in all shadow sets on a system at the same time.
Please keep these changes in mind if you are writing DCL command
procedures that use these new commands.
Dissimilar device shadowing (DDS) is a new feature introduced in OpenVMS Version 7.3-2. This note describes a temporary restriction on when it is advisable to add the first dissimilar member to a shadow set that is currently mounted in the cluster.
A dissimilar member is added to an existing shadow set by using the MOUNT command. For example, the following command adds $1$DGA221 to shadow set DSA22:
HP advises that a dissimilar device should be added to an existing non-DDS shadow set only from a node on which the shadow set is currently mounted and only under one of the following conditions:
Once a shadow set has dissimilar members, it can safely be mounted or remounted on any other Version 7.3-2 system in the cluster. (Version 7.3-2 is required to access a shadow set with dissimilar members.) Once one dissimilar member has been added to a given shadow set in its current mount lifetime, dissimilar members can be added or removed without restriction as long as that shadow set remains mounted.
Failure to adhere to this restriction results in a continuous level of OpenVMS distributed locking activity between the nodes that currently have the shadow set mounted. Once started, this locking activity will not cease until the shadow set is dismounted from all nodes or from all but one node. This locking activity can interfere with your ability to mount the shadow set on additional nodes and it also consumes system resources. However, this problem does not put your on-disk data at risk.
HP expects to correct this problem in a remedial kit for Version 7.3-2.
An interaction occurs between write bitmaps and dissimilar device shadowing (DDS) when Volume Shadowing for OpenVMS is used.
DDS, a new feature in OpenVMS Version 7.3-2, allows you to construct shadow sets of disk devices that are of dissimilar sizes. (For details about DDS, refer to the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview and HP Volume Shadowing for OpenVMS.)
Write bitmaps keep track of application writes made to a shadow set virtual unit so that a member can be returned to that virtual unit without the overhead of a full copy. A write bitmap is created when the user issues a DISMOUNT/POLICY=MINICOPY command for a shadow set member or mounts a shadow set using the MOUNT/POLICY=MINICOPY command. When this bitmap is created, its size depends on the current size of the volume.
When a shadow set is mounted, the logical size of the shadow set virtual unit is set to the size of the smallest member unit. When a member of the shadow set is removed, the logical size of the virtual unit is recomputed based on the sizes of the remaining members of the set. Consequently, the logical size of the virtual unit may increase.
When a write bitmap is created for a shadow set, its size is determined by the current size of the shadow set virtual unit. If the virtual unit's size subsequently increases, the bitmap will not cover the entire virtual unit. If the bitmap is then used to bring back a shadow set member with a minicopy operation, the portion of the virtual unit that is not covered by the bitmap will be copied with a full copy operation.
The following example illustrates this problem:
If the removal of a smaller shadow set member is planned, removing it
before removing a larger member with a minicopy bitmap will cause a
larger bitmap to be created and will avoid the performance impact of a
short bitmap. (In the preceding example, you would remove $1$DGA20:
before removing $1$DGA22:.)
Volume Shadowing for OpenVMS can be used with the KZPDC controller (Smart Array 5300) subject to the restriction that all shadow set members are formed using devices composed of fault-tolerant devices, such as the following:
A fault-tolerant device on the KZPDC (Smart Array 5300) controller is one that can repair data errors when the media yields errors on one of the underlying LUNs.
OpenVMS Alpha Version 7.3-2 supports shadow sets with members whose total block count varies. This new feature is known as dissimilar device shadowing (DDS). DDS allows a KZPDC device to be shadowed with a device from any supported controller.
For all prior OpenVMS versions, all devices must report the same number of total blocks for HBVS to create a multiple-member shadow set. The configuration utility sets the total number of blocks on a KZPDC or MSA1000 device to the closest match that it can make to the requested size. Because the KZPDC and the MSA1000 use the same calculation, a device created on both with the same requested size will be set to the same size. This allows HBVS to create multiple-member shadow sets.
4.26.6 SHOW DEVICE/BITMAP Command Might Produce SYSTEM-F-INTDIV Errors
If you attempt to display a bitmap of a shadow set that is no longer mounted on the local node, you may get a SYSTEM-F-INTDIV error if minicopy bitmaps were being used by this shadow set.
To avoid this error, do not attempt to display bitmap information unless the shadow set is mounted. Alternatively, you can try executing the command from another node in the cluster.
This restriction will be removed in a future release of OpenVMS.
In OpenVMS Version 7.3-2, you must have LOG_IO privilege to execute the SHOW DEVICE/BITMAP command. If you do not have LOG_IO privilege, the command shows no bitmaps active.
This temporary restriction will be corrected with a patch in the near
During an unassisted shadow set merge operation, read I/O performance available to applications is reduced by two factors:
The shadow set merge operation employs a throttling mechanism to limit the impact of merge I/O on applications. The merge process is throttled by introducing a delay between merge I/Os when system load is detected. The logic for computing this delay has been redesigned for OpenVMS Alpha Version 7.3-2. With the new merge delay computation, the default parameter settings will result in faster merge rates for some I/O controllers, such as the HSG-80. For more information, refer to the HP Volume Shadowing for OpenVMS manual.