HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS Version 8.2 Release Notes

Previous Contents Index

4.26 System Parameters

The following sections contain notes related to system parameters.

4.26.1 New System Parameters


The following system parameters are new in OpenVMS Version 8.2:

VHPT_SIZE (I64 only)

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

4.26.2 Obsolete System Parameters


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:

  • Include the new /OBSOLETE qualifier on the SHOW command. For example, to display all obsolete system parameters, enter the following command:

  • Specify the exact name of an obsolete parameter in a SHOW parameter-name command. For example, the following command displays OBSOLETE if the specified parameter is obsolete:

    SYSGEN> SHOW parameter-name

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.

  • Support for 32,767 processes
    OpenVMS now supports a maximum of 32,767 processes. The maximum value for the following system parameters is increased to 32765 to support this change:
  • Nonpaged pool lookaside list trimming now turned off
    Trimming of the nonpaged pool lookaside lists is now turned off by default. Trimming of these lists can result in a fragmented nonpaged pool variable list. In some cases, a heavily fragmented variable pool list might result in degraded system performance. The default value for the following system parameters is now 100:
  • Increase in minimum value of CTLPAGES
    The minimum value of CTLPAGES has been increased to 64, a value that can support a minimum boot.
  • Larger CLISYMTBL values
    Both the minimum and maximum values of CLISYMTBL are increased (64 and 8192, respectively) to support the creation of additional and large DCL symbols. The new minimum value for CLISYMTBL also supports a minimum boot.
  • Larger default values of CHANNELCNT
    The default and minimum values of CHANNELCNT increased to reduce the failure of applications that have a large number of files open because of an insufficient CHANNELCNT value. The new minimum is 64 and the new default is 512.
  • Parameters associated with global sections increased
    System quotas associated with global sections have been increased to provide more appropriate default values:
    GBLPAGFIL (Default: 16394)
    GBLSECTIONS (Default: 1024)
  • Default value of DUMPSTYLE changed for a compressed/selective dump
    The default value of the DUMPSTYLE parameter is changed to 9 to produce a compressed/selective dump. This change helps ensure that necessary data is recorded in the system dump file when a system has a small system dump file.
  • Default and minimum values of QUANTUM decreased
    With faster systems, the amount of work a CPU can do in a given amount of time has increased. Lowering the default value of QUANTUM to 5 allows a CPU to schedule more processes per second. The minimum value is 1.
  • Values of the GH_* parameters increased
    The maximum value of the GH_* parameters is increased to 65536 (512MB). Note that it is impossible to boot a system with all of these parameters increased to the MAX value. These parameters consume a 32-bit address space, which is limited to 2 GB.
    I64 images have a read-only segment that can be shared. To support this, the GH_RES_DATA parameter default has been increased from 0 to 100 pages.
  • Default value of WSMAX increased
    The default value of WSMAX is increased to 131072 to support the large physical memory on I64 systems.
  • PQL parameter values increased on OpenVMS I64
    The PQL parameters are used to provide default and minimum values for various quotas when detached processes are created. A number of these parameters are increased to provide more reasonable defaults and minimums to accommodate the large physical memory on I64 systems. The new defaults are as follows:
    Parameter Default on Alpha Default on I64
    PQL_DBYTLM 65536 262144
    PQL_MBYTLM 2048 128000
    PQL_DPGFLQUOTA 131072 700000
    PQL_MPGFLQUOTA 4096 512000
    PQL_DWSDEFAULT 2048 32767
    PQL_MWSDEFAULT 1024 16384
    PQL_DWSQUOTA 4096 65536
    PQL_MWSQUOTA 2048 32768
    PQL_DWSEXTENT 32767 131072
    PQL_MWSEXTENT 4094 65536
    PQL_DENQLM 2048 2048
    PQL_MENQLM 64 64
  • Defaults for paged and nonpaged pool increased for I64
    The default values for a number of the paged and nonpaged pool parameters are increased for I64, as follows:
    Parameter Default
    NPAGEDYN 4194304 (4 MB)
    NPAGEVIR 16777216 (16 MB)
    PAGEDYN 4194304 (4 MB)
  • Default of the system working set quota increased for I64
    The default value for SYSMWCNT is increased to 8192.
  • Default for KSTACKPAGES increased for Alpha
    The default value of KSTACKPAGES is increased from 1 page to 2. This change is to ensure that various hardware platforms with assorted devices can boot with the default value.

Refer to online help or HP OpenVMS System Management Utilities Reference Manual for detailed descriptions of these parameters.

4.26.5 MMG_CTLFLAGS: Documentation Errors


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


TFFSHR has been removed from IMAGELIB because it is not a documented, user-callable interface. The image is still available in the SYS$LIBRARY: directory.

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:

  • On Alpha systems, the TFF fallback driver is named SYS$FBDRIVER.EXE. On VAX systems, the TFF fallback driver is named FBDRIVER.EXE.
  • On Alpha systems, TFF is capable of handling 16-bit character fallback. The OpenVMS Alpha fallback table library (TFF$MASTER.DAT) contains four more 16-bit character tables than the VAX library. Table 4-3 describes these additional tables.

    Table 4-3 TFF Character Fallback Tables
    Table Name Base Description
    BIG5_HANYU BIG5 BIG5 for CNS 11643 (SICGCC) terminal/printer
    HANYU_BIG5 CNS CNS 11643 (SICGCC) for BIG5 terminal/printer
    HANGUL_DS KS KS for DOOSAN 200 terminal

    These tables are used mainly by the Asian region. Also, the table format was changed due to the support of 16-bit character fallback.
  • On Alpha systems, the TFU command SHOW STATISTICS does not display the size of the fallback driver (SYS$FBDRIVER.EXE).

RT terminals are not supported by TFF.

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 this manual.

4.28 Time Zone Changes


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.

4.29 User Environment Test Package (UETP) (I64 Only)


The User Environment Test Package (UETP) can be used with the following cautions:

  • During the load phase, there are sporadic access violations in UETMEMY01. This does not terminate execution or really affect the validity of the run. UETP is still useable and produces valid results.
  • The device phase currently does not complete execution due to an access violation.
  • The DECnet phase runs fine. The cluster phase is still being tested. It appears to execute properly, but there are some concerns, and the output does not show other system names properly.

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.

4.31 Volume Shadowing for OpenVMS

The following release notes pertain to HP Volume Shadowing for OpenVMS, also known as host-based volume shadowing (HBVS).

4.31.1 Device Name Requirement


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:

MOUNT-F-NOTSHDWDEV, not a valid shadow set member

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.

4.31.3 Write Bitmaps and Dissimilar Device Shadowing (DDS) Caution


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:

  • Shadow set DSA1: consists of these three members:
    $1$DGA20: (18 GB)
    $1$DGA21: (36 GB)
    $1$DGA22: (36 GB)
  • $1$DGA22: is removed from the shadow set with a minicopy bitmap using the following command:


    The write bitmap is sized for 18 GB, the current size of the shadow set virtual unit.
  • $1$DGA20: is removed from the shadow set. To allow the file system to utilize the entire 36 GB of the remaining member, use the following command:


    $1$DGA20 can no longer be used in this shadow set because it is smaller than the new volume size.
  • $1$DGA22: is returned to the shadow set using this command

    $ MOUNT/SYSTEM DSA1:/SHADOW=$1$DGA22: label

    The logical size of DSA1: remains at 36 GB; however, the bitmap covers only the first 18 GB.
  • The first 18 GB of $1$DGA22: are copied using the minicopy bitmap; the remaining 18 GB are copied using a full copy operation.

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:.)

4.31.4 KZPDC (Smart Array 5300) Restrictions


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:

  • RAID 1, also known as controller-based mirroring
  • RAID 5, which is striping with parity
  • RAID ADG (Advanced Data Guarding), which is striping with multiple parity devices

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.


There are cases where it will not be possible to use HBVS to create a multiple-member shadow set if a fault-tolerant device is not used. For example, a single member shadow set is formed using a device (physical disk or non-fault-tolerant device). If that device subsequently develops nonrecoverable data errors, it will not be possible to use HBVS successfully to add another member to this shadow set. Once the second member is added to the shadow set, HBVS will read the entire source device and copy it to the target device. When the data error is read from the founding or source shadow set member, HBVS will attempt to force all of the current shadow set members (the source member and the copy target) to create a "bad spot". If this request to create a bad spot fails on either shadow set member, the shadow set will be reduced to one member.

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 need to perform data consistency checks on all read I/Os
  • Contention for I/O bandwidth by the shadow set merge operation

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.

4.31.6 ANALYZE/DISK/SHADOW Command Behavior


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 command behavior.

4.31.7 ANALYZE/DISK/SHADOW Command Behavior with Dissimilar Device Shadow Sets


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:

  • Shadow set DSA1: consists of two members:
    $1$DGA20: (18 GB)
    $1$DGA21: (36 GB)
  • A second 36-GB member, $1$DGA22:, is added to the shadow set with a full copy operation.
  • After the copy completes, $1$DGA20: is removed from the shadow set.
  • At this point, if the SET VOLUME/SIZE DSA1: command is executed, the shadow set virtual unit DSA1: will increase to 36 GB. Then, ANALYZE/DISK/SHADOW will report discrepancies because only the first 18 GB of the shadow set contents were copied to $1$DGA22:.

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 command behavior.

4.31.8 Dismount of Shadow Set Member Using /MINICOPY


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:

$! The following commands are NOT executed on the WILD3 system.
Device                  Device           Error    Volume         Free  Trans Mnt
 Name                   Status           Count     Label        Blocks Count Cnt
DSA5555:                Mounted              0  $80$DKA107:    7994646     1  18
$80$DKA107:    (WILD3)  ShadowSetMember      0  (member of DSA5555:)
$80$DKA302:    (WILD3)  ShadowSetMember      0  (member of DSA5555:)
$80$DKA303:    (WILD3)  ShadowSetMember      0  (member of DSA5555:)
%DISM-W-CANNOTDMT, $80$DKA302: cannot be dismounted
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted

This problem will be corrected in a future release.

Previous Next Contents Index