Document revision date: 9 May 2001

V7.2

Enclosing a Fibre Channel path name in quotation marks is valid, starting in OpenVMS Alpha Version 7.3.

Prior to OpenVMS Version 7.3, the documentation and help text indicated that a path name could be enclosed in quotation marks, for example:

$ SET DEVICE $1$dga166:/PATH="PGA0.5000-1FE1-0000-1501"/SWITCH

In versions of the system prior to OpenVMS Version 7.3, this command fails with the following error:

%SET-E-NOSUCHPATH, path "PGA0.5000-1FE1-0000-1501" does not exist for device $1$DGA166:

To prevent this problem on systems running prior versions of OpenVMS, omit the quotation marks that surround the path identifier string, as follows:

$ SET DEVICE $1$dga166:/PATH=PGA0.5000-1FE1-0000-1501/SWITCH

5.9.27 Reconfigured Fibre Channel Disks Do Not Come On Line

V7.2

The following problem is corrected in OpenVMS Alpha Version 7.2-1H1 and OpenVMS Alpha Version 7.3.

Each Fibre Channel device has two identifiers on the HSG80. The first is the logical unit number (LUN). This value is established when you use the command ADD UNIT Dnnn on the HSG80, where nnn is the LUN value. The LUN value is used by the HSG80 to deliver packets to the correct destination. The LUN value must be unique on the HSG80 subsystem. The second identifier is the device identifier. This value is established when you use the following command, where nnnnn is the device identifier:

$ SET Dmmm IDENTIFIER=nnnnn

The device identifier is used in the OpenVMS device name and must be unique in your cluster.

5.9.28 Device Identifier Requirement for the HSG80 CCL

V7.2

In OpenVMS Alpha Version 7.2-1H1 and OpenVMS Alpha Version 7.3, assigning a device identifier to the HSG CCL is optional. If you do not assign one, OpenVMS will not configure the $1$GGA device but will configure the other devices on the HSG subsystem.

5.9.29 Undesired Automatic Path Switches

V7.2

The problem described in this note is corrected in OpenVMS Alpha Version 7.3 by giving preference to the current path, thereby avoiding path switching after a transient error.

Every I/O error that invokes mount verification causes the multipath failover code to search for a working path. In earlier versions of OpenVMS, the multipath algorithm started with the primary path (that is, the first path configured by OpenVMS) and performed a search, giving preference to any direct paths to an HSx controller that has the device on line. Before the correction, the algorithm did not test the current path first, and did not stay on that path if the error condition had cleared.

5.10 OpenVMS Registry

The release notes in this section pertain to the OpenVMS Registry.

5.10.1 Registry Services in a Mixed OpenVMS V7.3/V7.2-1 Cluster

V7.3

Removing the data transfer size restrictions on the OpenVMS NT Registry required a change in the communication protocol used by the Registry. The change means that components of the Registry (the $REGISTRY system service and the Registry server) in OpenVMS V7.3 are incompatible with their counterparts in OpenVMS V7.2-1.

If you plan to run a cluster with mixed versions of OpenVMS, and you plan to use the $REGISTRY service or a product that uses the $REGISTRY service (such as Advanced Server, or COM for OpenVMS) then you are restricted to running these services on the OpenVMS V7.3 nodes only, or on the V7.2-1 nodes only, but not both.

If you need to run Registry services on both V7.3 and V7.2-1 nodes in the same cluster, please contact your Compaq Services representative.

5.10.2 Backup and Restore of the OpenVMS NT Registry Database

V7.3

The backup and restore of the OpenVMS NT Registry database is discussed in the OpenVMS Connectivity Developer Guide. Compaq would like to stress the importance of periodic backups. Database corruptions are rare, but have been exposed during testing of previous versions of OpenVMS with databases larger than 2 megabytes. A database of this size is itself rare; initial database size is 8 kilobytes. The corruptions are further isolated by occurring only when rebooting an entire cluster.

The Registry server provides a way of backing up the database automatically. By default, the Registry server takes a snapshot of the database once per day. However, this operation is basically a file copy and, by default, it purges the copies to the most recent five. It is conceivable that a particular area of the database may become corrupted and Registry operations will continue as long as applications do not access that portion of the database. This means that the daily backup could in fact be making a copy of an already corrupt file.

To safeguard against this, Compaq recommends that you take these additional steps:

1. Ensure that the SYS$REGISTRY directory is part of your incremental or full backup regimen, so that previous versions of the database are always preserved. If, for example, you perform backups on a weekly basis, you may want to increase the number of snapshot versions that are retained from 5 to 8. See the OpenVMS Connectivity Developer Guide for instructions on how to change this parameter.
2. Periodically export the database. Exporting the database has several advantages. First, it causes the server to read every key and value, so it effectively performs a validation of the database. Second, it writes out the database in a form that can be edited and repaired. This is not true of the snapshot files which may be difficult to repair. Third, by periodically exporting the database, creating a new database, and importing the saved export file; you are effectively compacting the database and thereby keeping it smaller and more efficient.

It should also be noted that in previous versions of OpenVMS, the EXPORT command may have failed to complete the operation under some conditions. You could normally recover simply by re-invoking the REG$CP image and retrying the operation until it was successful.

In addition, in previous versions of OpenVMS, the IMPORT command failed to properly import keys with classnames or links. The only way to recover from this was to modify the keys to add in the classnames or links, or to recreate the keys in question.

5.11 Performance---Comparing Application Performance Data

V7.3

The OpenVMS virtual I/O cache (VIOC) and the extended file cache (XFC) are file-oriented disk caches that can help to reduce I/O bottlenecks and improve performance. (Note that the XFC appears on Alpha systems beginning with Version 7.3.) Cache operation is transparent to application software. Frequently used file data can be cached in memory so that the file data can be used to satisfy I/O requests directly from memory rather than from disk.

Prior to Version 7.0, when an I/O was avoided because the data was returned from the cache, the direct I/O (DIO) count for the process was not incremented because the process did not actually perform an I/O operation to a device. Starting with Version 7.0, a change was made to cause all I/O requests---even those I/Os that were actually avoided because of data being returned from the cache---to be counted as direct I/Os.

This change can be a potential cause for confusion when you are comparing application performance data on different versions of OpenVMS. Applications running on Version 7.0 and later may appear to be performing more I/O than they did when run on earlier versions, even though the actual amount of I/O to the disk remains the same.

5.12 Point-to-Point Utility Documentation

V7.3

The Point-to-Point utility (PPPD) initiates and manages a Point-to-Point Protocol (PPP) network connection and its link parameters from an OpenVMS Alpha host system.

A chapter in the OpenVMS System Management Utilities Reference Manual: M--Z describes the PPPD commands with their parameters and qualifiers, which support PPP connections.

5.13 Queue Manager---Long Boot Times

V7.3

At certain instances the queue journal file (SYS$QUEUE_MANAGER.QMAN$JOURNAL) may grow to a large size (over 500,000 blocks), especially if there is a very large volume of queue activity. This may cause either a long boot time or the display of an error message, QMAN-E-NODISKSPACE , in the OPERATOR.LOG. The long boot time is caused by the queue manager needing a large space to accommodate the queue journal file.

The following example shows the error messages displayed in the operator.log:

%%%%%%%%%%% OPCOM 2-MAR-2000 23:05:31.24 %%%%%%%%%%% Message from user QUEUE_MANAGE on PNSFAB %QMAN-E-OPENERR, error opening $1$DUA0:[SYS3.SYSCOMMON.][SYSEXE] SYS$QUEUE_MANAGER.QMAN$JOURNAL;1 %%%%%%%%%%% OPCOM 2-MAR-2000 23:05:32.42 %%%%%%%%%%% Message from user QUEUE_MANAGE on PNSFAB -RMS-F-FUL, device full (insufficient space for allocation) %%%%%%%%%%% OPCOM 2-MAR-2000 23:05:32.87 %%%%%%%%%%% Message from user QUEUE_MANAGE on PNSFAB -SYSTEM-W-DEVICEFULL, device full - allocation failure %%%%%%%%%%% OPCOM 2-MAR-2000 23:05:32.95 %%%%%%%%%%% Message from user QUEUE_MANAGE on PNSFAB %QMAN-E-NODISKSPACE, disk space not available for queue manager to continue %%%%%%%%%%% OPCOM 2-MAR-2000 23:05:33.07 %%%%%%%%%%% Message from user QUEUE_MANAGE on PNSFAB -QMAN-I-FREEDISK, free up 191040 blocks on disk _$1$DUA0

You can shrink the size of the journal file by having a privileged user issue the following DCL command:

$ MCR JBC$COMMAND DIAG 7

Executing this DCL command check points the queue journal file and shrinks the file to the minimum size required for queue system operation.

Until this problem is fixed, use this workaround to shrink the size to a small file.

5.14 RMS Journaling

The following release notes pertain to RMS Journaling for OpenVMS.

5.14.1 Modified Journal File Creation

V7.2

Prior to Version 7.2, recovery unit (RU) journals were created temporarily in the [SYSJNL] directory on the same volume as the file that was being journaled. The file name for the recovery unit journal had the form RMS$process_id (where process_id is the hexadecimal representation of the process ID) and a file type of RMS$JOURNAL.

The following changes have been introduced to RU journal file creation in OpenVMS Version 7.2:

• The files are created in node-specific subdirectories of the [SYSJNL] directory.
• The file name for the recovery unit journal has been shortened to the form: YYYYYYYY, where YYYYYYYY is the hexadecimal representation of the process ID in reverse order.

These changes reduce the directory overhead associated with journal file creation and deletion.

The following example shows both the previous and current versions of journal file creation:

Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
Current version: [SYSJNL.NODE1]CB300412.;1

If RMS does not find either the [SYSJNL] directory or the node-specific directory, RMS creates them automatically.

5.14.2 Recovery Unit Journaling Incompatible with Kernel Threads (Alpha Only)

V7.3

Because DECdtm Services is not supported in a multiple kernel threads environment and RMS recovery unit journaling relies on DECdtm Services, RMS recovery unit journaling is not supported in a process with multiple kernel threads enabled.

5.14.3 After-Image (AI) Journaling

V6.0

You can use after-image (AI) journaling to recover a data file that becomes unusable or inaccessible. AI recovery uses the AI journal file to roll forward a backup copy of the data file to produce a new copy of the data file at the point of failure.

In the case of either a process deletion or system crash, an update can be written to the AI journal file, but not make it to the data file. If only AI journaling is in use, the data file and journal are not automatically made consistent. If additional updates are made to the data file and are recorded in the AI journal, a subsequent roll forward operation could produce an inconsistent data file.

If you use Recovery Unit (RU) journaling with AI journaling, the automatic transaction recovery restores consistency between the AI journal and the data file.

Under some circumstances, an application that uses only AI journaling can take proactive measures to guard against data inconsistencies after process deletions or system crashes. For example, a manual roll forward of AI-journaled files ensures consistency after a system crash involving either an unshared AI application (single accessor) or a shared AI application executing on a standalone system.

However, in a shared AI application, there may be nothing to prevent further operations from being executed against a data file that is out of synchronization with the AI journal file after a process deletion or system crash in a cluster. Under these circumstances, consistency among the data files and the AI journal file can be provided by using a combination of AI and RU journaling.

5.14.4 Remote Access of Recovery Unit Journaled Files in an OSI Environment

V6.1

OSI nodes that host recovery unit journaled files that are to be accessed remotely from other nodes in the network must define SYS$NODE to be a Phase IV-style node name. The node name specified by SYS$NODE must be known to any remote node attempting to access the recovery unit journaled files on the host node. It must also be sufficiently unique for the remote node to use this node name to establish a DECnet connection to the host node. This restriction applies only to recovery unit journaled files accessed across the network in an OSI or mixed OSI and non-OSI environment.

5.14.5 VFC Format Sequential Files

VAX V5.0
Alpha V1.0

You cannot update variable fixed-length control (VFC) sequential files when using before-image or recovery unit journaling. The VFC sequential file format is indicated by the symbolic value FAB$C_VFC in the FAB$B_RFM field of the FAB.

5.15 Security---DIRECTORY Command Now Summarizes Suppressed PATHWORKS ACEs

V7.1

In OpenVMS Version 7.1 and later, if you execute the DCL command DIRECTORY/SECURITY or DIRECTORY/FULL for files that contain PATHWORKS access control entries (ACEs), the hexadecimal representation for each PATHWORKS ACE is no longer displayed. Instead, the total number of PATHWORKS ACEs encountered for each file is summarized in this message: "Suppressed n PATHWORKS ACE." To display the suppressed PATHWORKS ACEs, use the DUMP/HEADER command.

5.16 System Parameters

The release notes in this section pertain to OpenVMS system parameters.

5.16.1 MAXBOBMEM System Parameter Not Obsolete

V7.3

When you are using the AUTOGEN utility, the following warning may occur in the AGEN$PARAMS.REPORT:

** WARNING - Parameter MAXBOBMEM is Obsolete .

The MAXBOBMEM system parameter is not obsolete.

5.16.2 VCC_MAXSIZE System Parameter Definition Corrected

V7.3

The system parameter VCC_MAXSIZE is incorrectly described in online help and in the OpenVMS System Management Utilities Reference Manual: M--Z as follows:

"This special parameter is used by Compaq and is subject to change. Do not change this parameter unless Compaq recommends that you do so."

Please ignore the quoted paragraph; VCC_MAXSIZE is not a special parameter, and you can change it. Also, its maximum value is now correctly set at 3700000.

If you want to adjust the XFC size, use the system parameter VCC_MAX_CACHE to do so.

5.16.3 NISCS_MAX_PKTSZ System Parameter Definition Corrected

V7.3

PEDRIVER uses NISCS_MAX_PKTSZ to compute the maximum amount of data to transmit in any LAN packet:

LAN packet size <= LAN header (padded Ethernet format) + NISCS_MAX_PKTSZ + NISCS checksum (only if data checking is enabled) + LAN CRC or FCS

The following table shows the minimum NISCS_MAX_PKTSZ value required to use the maximum packet size supported by specified LAN types. These values are corrections of the values shown in online help and in the System Parameters appendix of the OpenVMS System Management Utilities Reference Manual: M--Z.

Type of LAN	Minimum Value for NISCS_MAX_PKTSZ
Ethernet	1498
FDDI	4468
Gigabit Ethernet	7532
ATM	7606

5.16.4 Parameter Description Changes

V7.3

Descriptions of the following system parameters have been changed or corrected since the last release:

• DEVICE_NAMING (Alpha only)
• FAST_PATH (Alpha only)
• GLX_INST_TMO
• IO_PREFER_CPUS (Alpha only)
• LAN_FLAGS (Alpha only)
• LGI_BRK_TERM
• MAXBOBMEM (Alpha only)
• MPDEV_REMOTE (Alpha only)
• MULTITHREAD
• NISCS_MAX_PKTSZ
• NPAGECALC
• NPAGERAD (Alpha only)
• S2_SIZE (Alpha only)
• SECURITY_POLICY
• SHADOW_MBR_TMO
• SHADOW_SYS_WAIT
• SMP_LNGSPINWAIT
• SMP_SPINWAIT
• VCC_FLAGS (Alpha only)
• VCC_MAX_CACHE (Alpha only)
• VCC_MAX_LOCKS (Alpha only)
• VCC_WRITEBEHIND (Alpha only)
• VCC_WRITE_DELAY (Alpha only)
• VIRTUALPAGECNT
• XQPCTL2
• XQPCTLD1

You can read the new descriptions of these system parameters in online help. For example:

$ HELP SYS_PARAMETERS FAST_PATH

5.16.5 Obsolete System Parameters

V7.3

Starting with OpenVMS Version 7.3, the following system parameters are obsolete:

• MAXBOBS0S1
• MAXBOBS2
• NISCS_LAN_OVRHD
• PAGFILCNT
• SWPFILCNT

MAXBOBS0S1 and MAXBOBS2

Initially, the MAXBOBS0S1 and MAXBOBS2 parameters were intended to ensure that users could not adversely affect the system by creating huge buffer objects. However, as users began to use buffer objects more widely, managing the combination of these parameters proved to be too complex.

Users who want to create buffer objects must either hold the VMS$BUFFER_OBJECT_USER identifier or execute in executive or kernel mode. Therefore, these users are considered privileged applications, and the additional safeguard that these parameters provided is unnecessary.

To determine current usage of system memory resources, enter the following command:

$ SHOW MEMORY/BUFFER_OBJECT

5.17 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 5-3 describes these additional tables.

  Table 5-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 OpenVMS Terminal Fallback Utility Manual. The order number for this manual is AA--PS6BA--TE, and you can also access it on line from the OpenVMS Documentation CD-ROM (in the archived manuals directory).

	privacy and legal statement
6637PRO_006.HTML