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.

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

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:

$ @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.

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:

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.

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:

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:

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

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.

Caution

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.

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.

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.

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.

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.