|Document revision date: 19 July 1999|
This section contains release notes pertaining to OpenVMS system
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.
220.127.116.11 System Parameters Help
Help for system parameters is now easier to access. Look for system parameter help in the following new locations:
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.
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.
18.104.22.168 MAXBOBMEM (Alpha Only)
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.
22.214.171.124 MMG_CTLFLAGS (Alpha Only)
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:
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
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 126.96.36.199 for a similar change to the TMSCP_SERVE_ALL
parameter. For more information about MSCP and TMSCP serving, see the
OpenVMS Cluster Systems manual.
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.
The definition of the PASTDGBUF system parameter has changed:
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.
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.
Beginning with OpenVMS Version 7.2, the default value of QDSKINTERVAL
has been changed from 10 to 3.
188.8.131.52 SCSCONNCNT Is Obsolete
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.
Beginning in OpenVMS Version 7.2, if STARTUP_P3 is set to AGEN, the
system executes AUTOGEN at the end of the startup sequence.
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 184.108.40.206 for a similar change to the MSCP_SERVE_ALL parameter.
For more information about TMSCP and MSCP serving, see the
OpenVMS Cluster Systems manual.
220.127.116.11 VBN_CACHE_S (VAX Only)
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
18.104.22.168 VCC_MAXSIZE (Alpha Only)
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.
22.214.171.124 ARB_SUPPORT (Alpha Only)
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.
Compaq recommends that all OpenVMS Alpha Version 7.2 systems have the ARB_SUPPORT parameter set to 2 or to 3 (the default). (Note that Version 7.2 online help incorrectly identifies the default value as 2 in the table.) Do not change the ARB_SUPPORT parameter to any other value until all products dependent on the ARB and associated structures have been modified for the new environment.
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.
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.
See Section 126.96.36.199 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 188.8.131.52 for a description of improvements made
to system parameter help.
184.108.40.206 ARB_SUPPORT Default Value Is 3 (Alpha Only)
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
220.127.116.11 MPDEV_REMOTE Is Not Supported
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).
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:
$ 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:
|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|
RT terminals are not supported by TFF.
For more information about the Terminal Fallback facility, refer to the OpenVMS Terminal Fallback Utility Manual1.
1 This manual has been archived but is available in PostScript and DECW$BOOK (Bookreader) formats on the OpenVMS Documentation CD-ROM. A printed book can be ordered through DECdirect (800--344--4825); the order number for this manual is AA--PS6BA--TE.
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.
18.104.22.168 Shadow Set Member Support Raised to 500
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.
22.214.171.124 HSD10 Virtual Disks
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.
126.96.36.199 Minimerge Capability for System Disk Requires DUMPSTYLE Parameter (Alpha Only)
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.
|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.
188.8.131.52 Minimerge Version Incompatibility
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 184.108.40.206). This kit makes the Version 6.2 minimerge function
compatible with that of nodes running Version 7.1 or later software.
220.127.116.11 HSZ40 and Transportable SCSI Disk Shadow-Set Members
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.
The following notes describe corrections to former volume shadowing
18.104.22.168 Incompatibility with StorageWorks RAID Software Corrected
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.
This incompatibility did not affect RAID 0 (without shadowing) arrays or RAID 5 arrays.
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 22.214.171.124).
|privacy and legal statement|