Updated: 12 December 1998

OpenVMS Version 7.2 Release Notes

This section contains release notes pertaining to OpenVMS system parameters.

4.21.1 Changes and Enhancements

The following sections describe the changes made to system parameters and system parameter help in Version 7.2. For descriptions of new system parameters, refer to online help, the OpenVMS Version 7.2 New Features Manual, or the OpenVMS System Management Utilities Reference Manual.

4.21.1.1 System Parameters Help

V7.2

Help for system parameters is now easier to access. Look for system parameter help in the following new locations:

• In the top level of DCL help as topic Sys_Parameters.
• In the top level of SYSGEN help as topic Sys_Parameters.
• In the top level of SYSMAN help as topic Sys_Parameters.

Starting with Version 7.2, the special parameters are now alphabetically merged with the other system parameters to make them easier to find. This new organization is also used in the OpenVMS System Management Utilities Reference Manual.

4.21.1.2 CRD_CONTROL

V7.2

The CRD_CONTROL system parameter is implemented on Alpha as well as VAX systems. On VAX systems, CRD_CONTROL serves the function performed by CRDENABLE in earlier releases. On Alpha systems, CRD_CONTROL can be used to expand the function defined by CRDENABLE.

CRD_CONTROL is a bit mask for corrected read data (CRD) soft error control flags. These flags control the use of CRDERROR routines. With OpenVMS Version 7.2, several new bits have been defined to support extended functions for Alpha systems.

Default values are different for VAX and Alpha. On VAX systems, the default CRD_CONTROL setting has changed from 7 to 6, which enables CRD processing, scrubbing, and page replacement. On Alpha systems, the default CRD_CONTROL setting is 22, which enables CRD processing, scrubbing, page replacement, and extended CRD handling.

For detailed bit descriptions for VAX and Alpha systems, refer to the Sys_Parameters topic in online help or see the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual: M--Z.

4.21.1.3 MAXBOBMEM (Alpha Only)

V7.2

On Alpha systems, the MAXBOBMEM system parameter defines the maximum amount of physical memory, measured in pagelets, that can be associated with buffer objects. A page that is to be associated with a buffer object is counted against this parameter only once even if it is associated with more than one buffer object at the same time.

Beginning with OpenVMS Version 7.2, memory-resident pages are not counted against this parameter. (However, pages locked in memory through the $LCKPAG system service are counted.)

MAXBOBMEM is a DYNAMIC parameter.

4.21.1.4 MMG_CTLFLAGS (Alpha Only)

V7.2

Beginning with OpenVMS Version 7.2, you can control when memory is tested. This helps reduce the time between when you turn on the system and when you log in to an AlphaServer 4100 computer.

Bit 2 in the MMG_CTLFLAGS parameter controls deferred memory testing:

• If the bit is clear (the default), OpenVMS tests memory in the background and not necessarily before the bootstrap process has completed.
• If you set the bit, all memory is tested by the end of EXEC_INIT in the system bootstrap process, that is, before IPL is lowered from 31.

V7.2

The MSCP_CMD_TMO system parameter specifies the time in seconds that the OpenVMS MSCP server uses to detect MSCP command timeouts. The MSCP server must complete the command within a built-in time of approximately 40 seconds plus the value of the MSCP_CMD_TMO parameter.

The default value of this parameter, which is 0, is normally adequate. A value of 0 provides the same behavior as in earlier releases of OpenVMS that did not have an MSCP_CMD_TMO system parameter. A nonzero setting increases the amount of time before an MSCP command times out.

If command timeout errors are logged on client nodes, setting the parameter to a nonzero value on OpenVMS servers reduces the number of errors logged. Increasing the value of this parameter reduces the number of client MSCP command timeouts and increases the time it takes to detect faulty devices.

If you need to decrease the number of command timeout errors, Compaq recommends that you set an initial value of 60. If timeout errors continue to be logged, you can raise this value in increments of 20 seconds.

4.21.1.6 MSCP_SERVE_ALL

V7.2

The MSCP_SERVE_ALL system parameter has been enhanced to accommodate the serving of disks connected to HSx controllers whose allocation class differs from the system's node allocation class. In addition, the default setting for MSCP_SERVE_ALL has changed from 0 (off) to 4 (serve only the system disk) to prevent a problem that can occur in unusual circumstances.

Starting with OpenVMS Version 7.2, the serving types are implemented as a bit mask. For a complete description of the serving types controlled by each bit, see the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual: M--Z.

See Section 4.21.1.13 for a similar change to the TMSCP_SERVE_ALL parameter. For more information about MSCP and TMSCP serving, see the OpenVMS Cluster Systems manual.

4.21.1.7 NOCLUSTER

V7.2

The NOCLUSTER system parameter is now supported on both VAX and Alpha systems. This parameter controls whether page read clustering is inhibited when the system boots. The NOCLUSTER parameter should be set to 1 (inhibit page read clustering) only for debugging purposes.

4.21.1.8 PASTDGBUF

V7.2

The definition of the PASTDGBUF system parameter has changed:

PASTDGBUF
The number of datagram receive buffers to queue initially for the cluster port driver's configuration poller; the initial value is expanded during system operation, if needed.

Memory Channel devices ignore this parameter.

PASTDGBUF is an AUTOGEN parameter.

4.21.1.9 PIOPAGES

V7.2

The default value for the PIOPAGES system parameter has been increased to 575. This new setting should accommodate the increased demands for process-permanent memory that result from changes made to RMS file-name parsing in Version 7.2.

4.21.1.10 QDSKINTERVAL

V7.2

Beginning with OpenVMS Version 7.2, the default value of QDSKINTERVAL has been changed from 10 to 3.

4.21.1.11 SCSCONNCNT Is Obsolete

V7.2

Beginning with OpenVMS Version 7.2, the SCSCONNCNT system parameter is obsolete. SCS connections are now allocated and expanded only as needed, up to a limit of 65,000.

4.21.1.12 STARTUP_P3

V7.2

Beginning in OpenVMS Version 7.2, if STARTUP_P3 is set to AGEN, the system executes AUTOGEN at the end of the startup sequence.

4.21.1.13 TMSCP_SERVE_ALL

V7.2

The TMSCP_SERVE_ALL system parameter has been enhanced to accommodate the serving of tapes connected to HSx controllers whose allocation class differs from the system's node allocation class.

Beginning in OpenVMS Version 7.2, the TMSCP_SERVE_ALL parameter is a bit mask that controls the serving of tapes during a system boot. Also beginning in Version 7.2, a tape is served regardless of its allocation class unless bit 3 has a value of 1.

For a complete description of the serving types controlled by each bit, see the Sys_Parameters help topic or the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual: M--Z.

See Section 4.21.1.6 for a similar change to the MSCP_SERVE_ALL parameter. For more information about TMSCP and MSCP serving, see the OpenVMS Cluster Systems manual.

4.21.1.14 VBN_CACHE_S (VAX Only)

V7.2

As of OpenVMS VAX Version 7.2, the default value and behavior of this system parameter have changed. The new default and current behavior are described in the following paragraphs.

On VAX systems, the static system parameter VBN_CACHE_S enables or disables file system data caching. By default its value is 1, which means that caching is enabled and the virtual I/O cache is loaded during system startup.

To disable file system data caching on the local node and throughout the OpenVMS Cluster, set the value to 1. In an OpenVMS Cluster, none of the other nodes in the cluster can cache any file data until this node either leaves the cluster or reboots with the VBN_CACHE_S parameter set to 1.

4.21.1.15 VCC_MAXSIZE (Alpha Only)

V7.2

The description of this system parameter has changed, as follows:

On Alpha systems, the static system parameter VCC_MAXSIZE controls the size of the virtual I/O cache. This parameter, which specifies the size in blocks, is 6,400 by default.

On Alpha systems, the virtual I/O cache cannot shrink or grow. Its size is fixed at system startup.

VCC_MAXSIZE is an AUTOGEN parameter.

4.21.2 Problems and Restrictions

This section contains release notes describing problems and restrictions related to system parameters.

4.21.2.1 ARB_SUPPORT (Alpha Only)

V7.2

The new Access Rights Block (ARB) compatibility option, the ARB_SUPPORT system parameter, is provided specifically to support products that have not yet been updated with the new per-thread security Persona Security Block (PSB) data structures.

For additional information on the ARB compatibility option, look up ARB_SUPPORT in online Help under the Sys_Parameters topic or refer to the system parameters appendix in the OpenVMS System Management Utilities Reference Manual.

4.21.2.2 MSCP_SERVE_ALL

V7.2

If an OpenVMS node is a boot server, the OpenVMS allocation class should be set to the allocation class of the satellite boot device. If this requirement is not met, satellite boot failures can result.

4.21.3 Corrections

See Section 4.14.3.4 for a description of corrections made to the MSCP_CMD_TMO system parameter.

4.21.4 Documentation Changes and Corrections

This section contains notes with corrections to system parameter documentation. See Section 4.21.1.1 for a description of improvements made to system parameter help.

4.21.4.1 ARB_SUPPORT Default Value Is 3 (Alpha Only)

V7.2

In the Sys_Parameters help topic on OpenVMS Version 7.2 systems, the default for ARB_SUPPORT is incorrectly documented as 2 in the table. The actual default setting is 3, as noted in the first paragraph of ARB_SUPPORT help.

4.21.4.2 MPDEV_REMOTE Is Not Supported

V7.2

The MPDEV_REMOTE system parameter that is documented in online help and in the OpenVMS System Management Utilities Reference Manual is unsupported in OpenVMS Version 7.2. OpenVMS VAX online help incorrectly lists the default value as ON.

4.22 Terminal Fallback Facility (TFF) (Alpha Only)

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-1 describes these additional tables.

  Table 4-1 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 OpenVMS Terminal Fallback Utility Manual¹.

4.23 Volume Shadowing for OpenVMS

The following release notes pertain to Volume Shadowing for OpenVMS.

4.23.1 Changes and Enhancements

This section describes changes to volume shadowing software.

4.23.1.1 Shadow Set Member Support Raised to 500

V7.1

As of OpenVMS Version 7.1, the limit on the number of supported shadow set members has been raised from 390 to 500.

4.23.2 Problems and Restrictions

The following sections describe known problems and other considerations pertaining to volume shadowing.

4.23.2.1 HSD10 Virtual Disks

V7.1

The HSD10 controller supports a virtual disk capability by partitioning physical disks. To prevent data corruption, do not use OpenVMS Volume Shadowing to create shadow sets using HSD10 virtual disks.

4.23.2.2 Minimerge Capability for System Disk Requires DUMPSTYLE Parameter (Alpha Only)

V7.1

Do not enable system disk minimerge without using the DUMPSTYLE parameter to dump off system disk, which is described in the System Parameters appendix in the OpenVMS System Management Utilities Reference Manual. If you do not set the DUMPSTYLE parameter to DOSD (for dump off system disk) and proceed to enable minimerge for system disks, minimerge will be activated, to the detriment of crash dump analysis.

With the introduction of a new setting (4097) in the SHADOW_SYS_DISK system parameter in OpenVMS Alpha Version 7.1 and the use of the DUMPSTYLE parameter, you can now enable minimerge on shadowed system disks on OpenVMS Alpha systems as well as on OpenVMS VAX systems. The DUMPSTYLE parameter lets you specify that the system write a dump to a nonshadowed, nonsystem disk of your choice. This results in a considerable performance improvement.

Control the shadowing of a system disk by setting the SHADOW_SYS_DISK system parameter as shown in Table 4-2.

Table 4-2 SHADOW_SYS_DISK System Parameter Settings

Setting	Description
0	Do not shadow the system disk.
1	Shadow the system disk; disable system disk minimerge (if enabled).
4097	Shadow the system disk; enable system disk minimerge.

If you accidentally enable minimerge to a system disk that receives a crash dump and you have not set up dump off system disk, you may be able to recover if you know which disk contains the valid dump. Remove that member, remount it, and remove the dump from that member.

4.23.2.3 Minimerge Version Incompatibility

V7.1

With OpenVMS Version 7.1, the Volume Shadowing software has been revised with substantial quality improvements. However, this creates an incompatibility in the minimerge function between Version 7.1 or later nodes and Version 6.2 nodes within the same cluster. In such configurations, the Volume Shadowing software detects this incompatibility during the installation of Version 7.1 or later systems and disables the minimerge capability for the entire cluster.

This problem is resolved by installing the Cluster Compatibility Kit (see Section 4.14.1.2). This kit makes the Version 6.2 minimerge function compatible with that of nodes running Version 7.1 or later software.

4.23.2.4 HSZ40 and Transportable SCSI Disk Shadow-Set Members

V6.2

If you are using an HSZ40 Raid-Array Controller and OpenVMS Volume Shadowing, Compaq strongly recommends that you use HSZ40 nontransportable SCSI disks. This is because of a lack of functionality in transportable disks, which can result in data corruption.

An HSZ40 Raid-Array Controller can support an OpenVMS initialized SCSI disk (that is, one with a Files-11 ODS-2 format on it) that is moved between an OpenVMS controlled SCSI bus and an HSZ40 controlled SCSI bus without reinitializing the disk and losing data. Disks that contain this functionality are called transportable disks.

A SCSI disk initialized by the HSZ40 and then subsequently initialized by OpenVMS is called a nontransportable disk and cannot be moved to an OpenVMS controlled SCSI bus without losing data.

Transportable SCSI disks, which support the READ_LONG/WRITE_LONG capability while connected to an OpenVMS controlled SCSI bus, lose this capability when they are moved to the SCSI bus controlled by an HSZ40 Raid-Array Controller. However, OpenVMS Volume Shadowing requires that a SCSI disk support the READ_LONG/WRITE_LONG SCSI commands to handle certain classes of errors as seen under normal volume shadowing operations. The lack of support for the READ_LONG/WRITE_LONG SCSI commands can cause data corruption.

The lack of READ_LONG/WRITE_LONG capability is detected at shadow-set MOUNT time, by the following error:

MOUN$_DEVNOFE, device does not support FORCED ERROR handling

If you want to use OpenVMS Volume Shadowing with this limitation, a practice that Compaq strongly discourages, you can specify the MOUNT qualifier /OVERRIDE=NO_FORCED_ERROR at shadow-set MOUNT time.

Note that specifying this MOUNT qualifier may cause shadow-set member SCSI disks to be removed from a shadow set if certain error conditions arise that cannot be corrected.

4.23.3 Corrections

The following notes describe corrections to former volume shadowing problems.

4.23.3.1 Incompatibility with StorageWorks RAID Software Corrected

V7.2

An incompatibility existed between StorageWorks RAID Software and the enhanced volume shadowing provided in both OpenVMS Version 7.1 and in the Cluster Compatibility Kit. Because of this incompatibility, RAID software could no longer detect a shadow set state change.

This problem has been corrected in the StorageWorks RAID Software Version 2.4.

V7.2

The OpenVMS Version 7.1 Volume Shadowing driver's Bad Block Repair (BBR) logic did not perform correctly in some cases.

This problem has been fixed in OpenVMS Version 7.2 and in the Cluster Compatibility Kits available for OpenVMS Version 6.2 systems (see Section 4.14.1.2).

Copyright © Compaq Computer Corporation 1998. All rights reserved. Legal

6534PRO_011.HTML