HP OpenVMS Systems Documentation
HP OpenVMS Alpha Version 7.3--2 Release Notes
$ SET SERVER ACME/DISABLE $ SET SERVER ACME/ENABLE
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:
$ STOP/ID $ SET SERVER ACME/ABORT
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
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 126.96.36.199.0 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:
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:
188.8.131.52 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:
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
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.
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: Verification: %SET-I-SNDEXTAUTH, Sending password request to external authenticator %SET-I-TRYPWDSYNCH, Attempting password synchronization $
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:
$ SET FILE/CACHING_ATTRIBUTE=NO_CACHING CONTAINER_FILE.DSK.
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
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.
|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|
|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|
|Mutex Release Error||VAXDUP01_072|
|XFC/VCC compatibility support and logical names||VAXSYS03_072|
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.