HP OpenVMS Systems Documentation

Content starts here

HP OpenVMS Alpha Version 7.3--2 Release Notes

Previous Contents Index

Chapter 4
System Management Release Notes

This chapter contains information that applies to system maintenance and management, performance management, and networking.

For information about new features included in this version of the software, refer to the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview.

4.1 ACME_SERVER has Multiple Channels to RIGHTSLIST.DAT


The ACME_SERVER process opens a new channel to the RIGHTSLIST.DAT file each time the server is disabled or reenabled and the server processes at least one of the following requests:


If this operation is performed a certain number of times, the server may reach its FILLM process quota and become unresponsive.

To resolve the problem, stop the server using one of the following commands:


Then restart the server using one of the following commands:

$ SYS$STARTUP:ACME$STARTUP.COM        ! for OpenVMS authentication
$ SYS$STARTUP:NTA$STARTUP_NT_ACME.COM ! for NT authentication with
                                      ! COM for OpenVMS applications

4.2 AUTOGEN: New Behavior with NEWPARAMS.DAT Files


AUTOGEN no longer allows layered product kits to provide NEWPARAMS.DAT records that do not include a product name. The most commonly used products that previously did not adhere to this rule are DECwindows and DECnet-Plus. You must install new versions of both products when you install OpenVMS Alpha Version 7.3-2. (See Section 1.9.5.)

AUTOGEN looks for files named SYS$SYSTEM:NEWPARAMS.DAT;*, which contain SYSGEN parameter modifications specifying the consumption of system resources by layered products. A software installation kit may provide a NEWPARAMS.DAT file instead of telling the system manager to modify MODPARAMS.DAT to accommodate the requirements of the software being installed. For more information, refer to the AUTOGEN chapter in the HP OpenVMS System Management Utilities Reference Manual.

4.3 DECdtm Services

This section describes known problems and restrictions associated with using DECdtm services.

4.3.1 DECdtm/XA with Oracle® 8i and 9i (Alpha Only)


When you are using DECdtm/XA to coordinate transactions with the Oracle 8i/9i XA Compliant Resource Manager (RM), do not use the dynamic registration XA switch (xaoswd). Version of the Oracle shareable library that supports dynamic registration does not work. Always use the static registration XA switch (xaosw) to bind the Oracle RM to the DECdtm/XA Veneer.

The DECdtm/XA V2.1 Gateway now has clusterwide transaction recovery support. Transactions from applications that use a clusterwide DECdtm Gateway Domain Log can now be recovered from any single-node failure. Gateway servers running on the remaining cluster nodes can initiate the transaction recovery process on behalf of the failed node.

4.3.2 IPC-E-BCKTRNSFAIL Error Message


This note pertains to ACMS users, possibly Rdb users, and anyone else running a user-written application that calls DECdtm to participate in a distributed transaction with a remote system having these characteristics:

  • The network connection is HP DECnet-Plus for OpenVMS.
  • The nodes are connected using only an IP router.

Users may see the following error returned by DECnet:

IPC-E-BCKTRNSFAIL, failure on the back translate address request

This error is displayed upon a logical connection failure when the remote node name cannot be translated by DECnet-Plus. The error can be triggered when the DECnet-Plus node name for the remote system is not defined in the local DECnet-Plus database and is defined only as ALIAS in the TCP/IP name server for the remote node. For example, node XXYZZY may be defined as follows:    XXYZZY.ABC.DEF.COM, XXYZZY

To avoid this situation, either define the node name in the local DECnet-Plus database or define the logical SYS$DECDTM_NODE_NAME to be equivalent to one of the following:

  • The value of the system parameter SCSNODE
  • The DECnet-Plus simple name
  • The TCP/IP alias (a six-character node name string such as XXYZZY, as shown in the preceding example)

For other requirements and restrictions, refer to the section about managing DECdtm Services in the HP OpenVMS System Manager's Manual.

4.4 ECP Data Collector and Performance Analyzer V5.4D


Version 5.4D is the recommended version of Enterprise Capacity and Performance (ECP) Data Collector and the Enterprise Capacity and Performance (ECP) Analyzer for OpenVMS Alpha Version 7.3-2. Both the ECP Data Collector and the ECP Performance Analyzer are backward compatible with OpenVMS Version 6.2 and higher.

4.5 EDIT/FDL: Fixing Recommended Bucket Size


Prior to OpenVMS Version 7.3, when running EDIT/FDL, the calculated bucket sizes were always rounded up to the closest disk-cluster boundary, with a maximum bucket size of 63. This could cause problems when the disk-cluster size was large, but the "natural" bucket size for the file was small, because the bucket size was rounded up to a much larger value than required. Larger bucket sizes increase record and bucket lock contention, and can seriously impact performance.

OpenVMS Version 7.3 or higher modifies the algorithms for calculating the recommended bucket size to suggest a more reasonable size when the disk cluster is large.

4.6 Error Log Viewer (ELV) Utility

The following release notes pertain to the Error Log Viewer (ELV) utility for OpenVMS.

4.6.1 Translating Error Log Files from OpenVMS Versions 7.2 through 7.3-1


When you use the ELV TRANSLATE command to examine error log files created on systems running OpenVMS Version 7.2 through 7.3-1, you might see the following set of messages displayed after the translation of certain types of events:

%ELV-E-B2TNOTFND, valid bit-to-text translation data not found
-ELV-W-NODNOTFND, bit-to-text node not found

These messages are the result of a minor change in the error log file format between OpenVMS Versions 7.3-1 and 7.3-2, and can be disregarded. The affected events should otherwise be translated correctly.

4.6.2 Using the /PAGE Qualifier with the TRANSLATE Command


If a message is signaled while you are viewing a report using the /PAGE qualifier with the TRANSLATE command, the display might become corrupted. The workaround for this problem is to refresh the display using Ctrl/W.

If you press Ctrl/Z immediately after a message is signaled, the program abruptly terminates. The workaround for this problem is to scroll past the signaled message before pressing Ctrl/Z.

4.7 Extended File Cache (XFC) Remedial Kits


The problems that led to the requirement to disable XFC in Version 7.3 were addressed for Version 7.3-1. Issues were corrected that sometimes led to data corruption and system hangs, and XFC performance was also improved. HP recommends that you reenable XFC.

The minimum amount of memory that XFC allocates was increased from about .25 MB to about 3.2 MB; the latter amount is the same as the default for VIOC.

An XFC kit for OpenVMS Version 7.3 is available that contains all the XFC corrections that were included in OpenVMS Version 7.3-1.

If you have an OpenVMS Cluster system that contains earlier versions of OpenVMS Alpha or OpenVMS VAX and you want to use XFC with OpenVMS Version 7.3 or higher, you must install remedial kits on the systems that are running the earlier versions of OpenVMS. For information about the required kits, see Section 4.13.1.


The remedial kits correct errors in the cache-locking protocol of VIOC, the predecessor to XFC, and allow older versions of the caches to operate safely with the new XFC. Without the functionality in the remedial kits, however, the system or processes might hang.

4.8 External Authentication

This section contains release notes pertaining to external authentication. External authentication is an optional feature introduced in OpenVMS Version 7.1 that enables OpenVMS systems to authenticate designated users with their external user IDs and passwords. For detailed information about using external authentication, refer to the HP OpenVMS Guide to System Security.

4.8.1 SET PASSWORD Behavior Within a DECterm Terminal Session


A DECterm terminal session does not have access to the external user name used for login and must prompt for one during SET PASSWORD operations. The external user name defaults to the process's OpenVMS user name. If the default is not appropriate (that is, if the external user name and mapped OpenVMS user name are different), you must enter the correct external user name.

The following example shows a SET PASSWORD operation initiated by a user with the external user name JOHN_DOE. The mapped OpenVMS user name is JOHNDOE and is the default used by the SET PASSWORD operation. In this case, the default is incorrect and the actual external user name was specified by the user.

$ set password
External user name not known; Specify one (Y/N)[Y]? Y
External user name [JOHNDOE]: JOHN_DOE
Old password:
New password:
%SET-I-SNDEXTAUTH, Sending password request to external authenticator
%SET-I-TRYPWDSYNCH, Attempting password synchronization

4.8.2 No Password Expiration Notification on Workstations


In the LAN Manager domain, a user cannot log in once a password expires.

PC users receive notification of impending external user password expiration and can change passwords before they expire. However, when a user logs in from an OpenVMS workstation using external authentication, the login process cannot determine whether the external password is about to expire. Therefore, sites that enforce password expiration and whose users do not primarily use PCs can choose not to use external authentication for workstation users.

4.9 INITIALIZE Command: Incorrect Messages Are Output


An error causes incorrect messages to be output with the %INIT-I-LIMITCHANGED message, which informs the user that the value specified by INITIALIZE/LIMIT is being overridden by INITIALIZE.

If you get an %INIT-I-LIMITCHANGED message, check the value specified for the /LIMIT qualifier. It should not be less than the physical size of the disk. Because INITIALIZE detected that the value for /LIMIT is too small, INITIALIZE will use a larger value. INITIALIZE did complete successfully and the disk should mount properly. You can ignore the message or you can reenter the command and either specify a larger value for /LIMIT or specify /LIMIT with no value, in which case the maximum expansion size for the disk will be established.

For more information about /LIMIT, see online help or the description of the INITIALIZE/LIMIT command in the HP OpenVMS DCL Dictionary.

4.10 Lock Manager: Fast Lock Remastering and PE1


The OpenVMS Distributed Lock Manager has a feature called lock remastering. A lock remaster is the process of moving the lock mastership of a resource tree to another node in the cluster. The node that masters a lock tree can process local locking requests much faster because communication is not required with another node in the cluster. Having a lock tree reside on the node doing the most locking operations can improve overall system performance.

Prior to OpenVMS Version 7.3, lock remastering resulted in all nodes sending one message per local lock to the new master. For a very large lock tree, it could require a substantial amount of time to perform the lock remastering operation. During the operation, all application locking to the lock tree is stalled.

Starting with OpenVMS Version 7.3, sending lock data to the new master is done with very large transfers. This is a much more efficient process and results in moving a lock tree from 3 to 20 times faster.

Only nodes running Version 7.3 or higher can use large transfers for lock remastering. Remastering between OpenVMS Version 7.3 or higher nodes and prior version nodes still requires sending a single message per lock.

If you currently use the PE1 system parameter to limit the size of lock trees that can be remastered, HP recommends that you either try increasing the value to allow large lock trees to move or try setting the value to zero (0) to allow any size lock tree to move.

4.11 Logical Disk (LD) Utility: Error when Using RMS


A feature of the Logical Disk (LD) utility can cause problems for end users who are using logical disks. This problem can occur on any version of OpenVMS that uses the LD utility.

The LD utility bypasses the cache for the container file when it is operating on the disk. If RMS is used to read or write to the container file, RMS will have stale data if the LD utility is used to connect to the file and subsequently to the logical disk that is being written.

This problem occurs mainly when the LD utility is used to create disk images that are to be burned onto a CD-ROM.

To work around the problem, execute the following DCL command to turn caching off for any file that will be used as a container file for the LD utility:


This DCL command is not executed as part of the CDRECORD.COM command procedure. Therefore, if you reuse a container file for a logical disk created by CDRECORD.COM, be sure to turn off the caching using this command.

4.12 MAIL Utility: Documentation Correction


In the "Customizing Mail" section of the "Customizing the Operating System" chapter in the HP OpenVMS System Manager's Manual, two values for the MAIL$SYSTEM_FLAGS logical, 8 and 16, are incorrectly marked as VAX only. These values also apply to Alpha systems.

4.13 OpenVMS Cluster Systems

The release notes in this section pertain to OpenVMS Cluster systems.

4.13.1 Patch Kits Needed for Cluster Compatibility


Before introducing an OpenVMS Version 7.3-2 system into an existing OpenVMS Cluster system, you must apply certain patch kits (also known as remedial kits) to your systems running earlier versions of OpenVMS. If you are using Fibre Channel, XFC, or Volume Shadowing, additional patch kits are required. Note that these kits are version specific.

Table 4-1 lists the facilities that require patch kits and the patch kit names. Each patch kit has a corresponding readme file with the same name (file extension is .README).

You can either download the patch kits from the following web site (select the OpenVMS Patch Kits option), or contact your HP support representative to receive the patch kits on media appropriate for your system:



Patch kits are periodically updated on an as-needed basis. Always use the most recent patch kit for the facility, as indicated by the version number in the kit's readme file. The most recent version of each kit is the version posted to the web site.

Table 4-1 Patch Kits Required for Cluster Compatibility
Facility File Name
OpenVMS Alpha Version 7.3-1
Update kit with all patch kits except DECnet-Plus DEC-AXPVMS-VMS731_UPDATE-V0100
OpenVMS Alpha Version 7.3
Update kit with all patch kits except DECnet-Plus DEC-AXPVMS-VMS73_UPDATE-V0200--4.PCSI
OpenVMS VAX Version 7.3
Audit Server VAXAUDS01_073
Cluster VAXSYSL01_073
DECwindows Motif VAXDWMOTMUP01_073
Files 11 VAXF11X02_073
Shadowing VAXSHAD01_073
System VAXSYS01_073
OpenVMS Alpha Version 7.2-2
Update kit with all patch kits except those listed below DEC-AXPVMS-VMS722_UPDATE-V0100-4.PCSI
OpenVMS VAX Version 7.2
Update kit with all patch kits except those listed below VAXUPDATE01_072
Audit Server VAXAUDS01_072
Backup utility VAXBACK02_072
CLI Utility VAXCLIU03_072
DECwindows Motif VAXDWMOTMUP01_072
Fibre Channel VAXDRIV02_072
Files 11 VAXF11X04_072
Mutex Release Error VAXDUP01_072
ODS1 VAXODS1_01_072
PThreads VAXPTHR01_072
Volume Shadowing VAXSHAD03_072
XFC/VCC compatibility support and logical names VAXSYS03_072

4.13.2 New API Can Correct Incompatibility of Fibre Channel and SCSI Multipath with Some Third-Party Products


OpenVMS Alpha Version 7.2-1 introduced the multipath feature, which provides support for failover between the multiple paths that can exist between a system and a SCSI or Fibre Channel device. OpenVMS Alpha Version 7.3-1 introduced support for failover between Fibre Channel multipath tape devices.

This multipath feature can be incompatible with some third-party disk-caching, disk-shadowing, or similar products. HP advises that you do not use such software on SCSI or Fibre Channel devices that are configured for multipath failover until this feature is supported by the producer of the software.

Third-party products that rely on altering the Driver Dispatch Table (DDT) of either the OpenVMS Alpha SCSI disk class driver (SYS$DKDRIVER.EXE), the OpenVMS Alpha SCSI tape class driver (SYS$MKDRIVER.EXE), or the SCSI generic class driver (SYS$GKDRIVER) may need to be modified in order to function correctly with the SCSI multipath feature.

Producers of such software can now modify their software using new DDT Intercept Establisher routines introduced in OpenVMS Alpha Version 7.3-2. For more information about these routines, refer to the HP OpenVMS Alpha Version 7.3--2 New Features and Documentation Overview manual.


If you are using a third-party disk-caching product or disk shadowing application, refrain from using it in an OpenVMS SCSI or Fibre Channel multipath configuration until you confirm that the application has been revised using these new routines.

For more information about OpenVMS Alpha SCSI and Fibre Channel multipath features, refer to Guidelines for OpenVMS Cluster Configurations.

Previous Next Contents Index