HP OpenVMS Systems Documentation
HP OpenVMS Version 8.2 Release Notes
4.26 System Parameters
The following sections contain notes related to system parameters.
The following system parameters are new in OpenVMS Version 8.2:
The DEVICE_NAMING parameter was introduced in an earlier release, but was inadvertently omitted from the documentation; it is now included.
Refer to online help or the HP OpenVMS System Management Utilities Reference Manual for definitions of all system
The following system parameters have been marked as obsolete in OpenVMS Version 8.2:
4.26.3 Displaying Obsolete System Parameters
SHOW commands in the SYSGEN, SYSMAN, SDA, and SYSBOOT utilities no longer display obsolete system parameters unless you do one of the following:
4.26.4 System Parameter Changes
In OpenVMS Version 8.2, a number of system parameters are updated to provide optimum default, minimum, and maximum values.
Refer to online help or HP OpenVMS System Management Utilities Reference Manual for detailed descriptions of these
The description of bit 0 of system parameter MMG_CTLFLAGS is incorrect in online help, the HP OpenVMS System Management Utilities Reference Manual, and the OpenVMS Performance Management manual. The correct description of bit 0 is as follows:
"If this bit is set, reclamation is enabled by trimming from periodically executing, but otherwise idle, processes. This occurs when the size of the free list plus the modified list drops below two times the value of FREEGOAL. This function is disabled if the bit is clear."
There is also an error in the description of Bit 1 in the OpenVMS Performance Management manual. That description should be corrected to read as follows:
"Reclamation enabled by outswapping processes that have been idle for longer than LONGWAIT seconds. This occurs when the size of the free list drops below the value of FREEGOAL."
4.27 Terminal Fallback Facility (TFF)
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 now archived OpenVMS Terminal Fallback Utility Manual on the OpenVMS documentation website:
Click on "Archived documents" in the left sidebar to link to
In OpenVMS Version 8.2, 204 time zones have been added and existing time zones have been updated for a total of 540 time zones. This list of time zones is based on the time zone public database tzdata2003e.tar.gz, which is available from:
An appendix listing all the time zones is included in HP OpenVMS System Manager's Manual, Volume 2: Tuning, Monitoring, and Complex Systems.
The User Environment Test Package (UETP) can be used with the following cautions:
4.30 Recommended Caching Methods
Virtual I/O Cache (VIOC) --- also known as VAX Cluster Cache (VCC) --- is not available on OpenVMS I64. On I64 systems, setting the SYSGEN parameter VCC_FLAGS to 1 is equivalent to setting VCC_FLAGS to 0 or not loading caching at all.
HP recommends Extended File Cache (XFC) as the preferred method for caching on both Alpha and I64 systems. For more information about XFC, refer to the HP OpenVMS System Manager's Manual.
In a future release of OpenVMS Alpha, support for VIOC will be removed.
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.31.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.
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 manual 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 and higher 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.31.5 Changes in Shadow Set Merge Delay Computation
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.
When you specify the /SHADOW qualifier (new in OpenVMS Version 7.3-2) with the ANALYZE/DISK_STRUCTURE command, the entire contents of a shadow set or a specified range of blocks in a shadow set are examined for discrepancies.
If a member of the shadow set experiences connectivity problems for any reason, the ANALYZE/DISK_STRUCTURE command displays the error that it received and then returns the user to the DCL prompt.
To correct the connectivity problem and run the utility again on the same shadow set, you might need to create a temporary file on the virtual unit before reissuing the ANALYZE/DISK/SHADOW command.
Additionally, this utility may report explainable discrepancies between the shadow set members if the shadow set has not undergone a full merge since the shadow set was created. This happens if the shadow set was created using the DCL command INITIALIZE/SHADOW without the /ERASE qualifier and if the disk devices had different contents. It is important to realize that this is not disk corruption. The blocks that are reported as different have not been written to, but they may contain stale data; the blocks reported as inconsistent may even be allocated to a file because there may be unwritten space between the file's end-of-data location and the end of the allocated space.
You can eliminate such inconsistencies by performing a full merge. To initiate a full merge, execute the DCL command SET SHADOW/DEMAND_MERGE DSAxxx. If the devices are served by controllers that support controller-based minimerge (for example, HSJ50s), this command should be issued while the shadow set is mounted on only one node within the cluster. Otherwise, a minimerge will occur, and the discrepancy may not be resolved. When you are adding members to a single member shadow set, a full copy operation will also ensure that the disk is consistent both within and outside of the file system.
If errors are reported on an ANALYZE/DISK/SHADOW command after a full merge has been executed, they should be investigated.
Also see Section 4.31.7 for another note about ANALYZE/DISK/SHADOW
An ANALYZE/DISK/SHADOW command may also report explainable discrepancies if a full merge has not occurred since the shadow set was logically expanded after a new member was added. The following example illustrates this problem:
The discrepancies reported by ANALYZE/DISK/SHADOW are harmless because the space in question has not yet been written by applications.
Also see Section 4.31.6 for another note about ANALYZE/DISK/SHADOW
In a single site or in a multiple-site OpenVMS Cluster configuration, if you issue a DISMOUNT command with the /MINICOPY qualifier from a client system to dismount a shadow set member, the command might fail.
If the first DISMOUNT command fails, repeat the command, as shown in the following example: