HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 Release Notes

The following sections contain notes related to system parameters.

4.26.1 New System Parameters

V8.2

The following system parameters are new in OpenVMS Version 8.2:

ERLBUFFERPAG_S2
ERRORLOGBUFF_S2
SCSI_ERROR_POLL
SHADOW_HBMM_RTC
SHADOW_REC_DLY
SHADOW_SITE_ID
SYSSER_LOGGING
TTY_DEFCHAR3
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

V8.2

The following system parameters have been marked as obsolete in OpenVMS Version 8.2:

BJOBLIM
BOOT_STYLE
EXUSRSTK
LAMAPREGS
NISCS_LAN_OVRHD
NJOBLIM
QBUS_MULT_INTR
SA_APP
SBIERRENABLE
SCSCONNECT
SD_ALLOCLASS
TAILORED
UDABURSTRATE
VECTOR_MARGIN
VECTOR_PROC
XFMAXRATE

V8.2

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:

  SYSGEN> SHOW/OBSOLETE

• 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

V8.2

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:

  BALSETCNT
  IJOBLIM
  MAXPROCESSCNT

• 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:

  NPAG_AGGRESSIVE
  NPAG_GENTLE

• 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

V8.2

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

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:

$ @SYS$MANAGER:TFF$SYSTARTUP.COM

To enable fallback or to change fallback characteristics, invoke the Terminal Fallback Utility (TFU), as follows:

$ RUN SYS$SYSTEM:TFU
TFU>

To enable default fallback to the terminal, enter the following DCL command:

$ SET TERMINAL/FALLBACK

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
  HANYU_TELEX	CNS	CNS 11643 for MITAC TELEX-CODE terminal
  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

V8.2

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)

V8.2

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.

V8.2

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

V7.3-2

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

V7.3-2

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

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

  $ DISMOUNT/POLICY=MINICOPY $1$DGA22:

  
  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:

  $ SET VOLUME/SIZE DSA1

  
  $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

V7.3-2

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.

V7.3-2

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

V7.3-2

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

V7.3-2

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

V7.3

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.

Workaround

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.
$
$ SHOW DEVICE DSA5555
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:)
$
$
$ DISMOUNT/POLICY=MINICOPY $80$DKA302:
%DISM-W-CANNOTDMT, $80$DKA302: cannot be dismounted
%DISM-F-SRCMEM, only source member of shadow set cannot be dismounted
$
$
$ DISMOUNT/POLICY=MINICOPY $80$DKA302:
$

This problem will be corrected in a future release.