HP OpenVMS Systems Documentation

Content starts here

OpenVMS Version 7.3 Release Notes

Previous Contents Index

5.3 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 using their external user IDs and passwords.

Starting with OpenVMS Version 7.2, if you are running DECwindows and you want a DECwindows user to be externally authenticated, you must be running DECwindows Version 1.2-4 or later and Advanced Server for OpenVMS, and meet any requirements outlined in the Advanced Server for OpenVMS Server Installation and Configuration Guide. See this manual and the OpenVMS Guide to System Security for detailed information about using external authentication.

5.3.1 FTP Server Uses External Authentication


With the release of Compaq TCP/IP Services for OpenVMS Version 5.0, the File Transfer Protocol (FTP) server uses external authentication to authenticate connections on the OpenVMS system.

5.3.2 DCL Command Interface to Control External Authentication


Chapter 7 of the OpenVMS Guide to System Security describes the SYS$SINGLE_SIGNON and SYS$ACME_MODULE logical names currently used for external authentication. Note that in a future release, the current interface for enabling and controlling external authentication will be replaced by a DCL command interface.

5.3.3 Failed Connection Attempts on POP Server


The Post Office Protocol (POP) server does not use external authentication to authenticate connection attempts on the OpenVMS system. This causes connection attempts to fail if either of the following conditions exist:

  • The external user ID is different from the OpenVMS user name.
  • The OpenVMS password is not synchronized with the external user password.

5.3.4 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

5.3.5 Compaq DECnet-Plus Requirement


Users with the EXTAUTH bit set in their SYSUAF account record cannot use explicit access control strings with systems running Compaq DECnet-Plus unless their externally authenticated password is all uppercase characters.

For example, if you enter the following command:

$ DIRECTORY nodename"username password"::

where nodename is a system running DECnet-Plus and username is an EXTAUTH account, DECnet-Plus converts the string supplied in the password to uppercase characters before it is passed to the external authentication agent (a PATHWORKS or NT domain controller).

There are two workarounds:

  • If you are using DECnet-Plus and you want to use explicit access control strings, define an uppercase NT password.
  • Set up a proxy account on your DECnet-Plus nodes so that you do not have to use explicit access control strings to perform functions.

5.3.6 DECwindows Pause Screen Uses SYSUAF Password


The DECwindows pause screen unlock mechanism does not use the external authentication service for password validation. It continues to use the password in the SYSUAF file, even if you have external authentication enabled on your system.

Password synchronization is enabled by default. If you have disabled password synchronization, be sure to keep the LAN Manager and SYSUAF passwords synchronized manually.

5.3.7 DECnet-Plus and NET_CALLOUTS Parameter


To run DECnet-Plus for OpenVMS with external authentication enabled, set the system parameter NET_CALLOUTS to 255. This causes user verification and proxy lookups to be done in LOGINOUT rather than DECnet.

5.3.8 Impact on Layered Products and Applications


Certain layered products and applications that use an authentication mechanism based on the traditional SYSUAF-based user name and password (for example, software that calls $HASH_PASSWORD or $GETUAI/$SETUAI to alter, fetch, or verify OpenVMS passwords) will encounter problems in either of the following cases:

  • When external authentication is used in an environment where a given user's external user ID and OpenVMS user name are different
  • Where the user's SYSUAF password is different from the external user password

In such cases, the problem symptom is a user authentication failure from the layered product or application.

For externally authenticated users, the normal system authorization database (SYSUAF.DAT) is used to construct the OpenVMS process profile (UIC, privileges, quotas, and so on) and to apply specific login restrictions. However, there are two key differences between externally authenticated users and normal OpenVMS users. The following is true for externally authenticated users:

  • The password stored in the SYSUAF is not the password used to verify the user.
  • The user name stored in the SYSUAF and used to identify the OpenVMS process is not necessarily the same as the external user ID used to authenticate the user during login.

OpenVMS attempts to keep a user's SYSUAF and external user password synchronized to minimize these problems. An up-to-date copy of the user's external password is kept in the SYSUAF, but this is not the case if, for example, the external password contains characters that are invalid in OpenVMS, or if SYSUAF password synchronization is disabled by the system manager. (Password synchronization is enabled by default.)

If you enable external authentication, Compaq recommends you do the following to minimize incompatibility with layered products or applications that use traditional SYSUAF-based authentication:

  • Do not disable password synchronization.
  • Limit external user passwords to those characters from the OpenVMS valid password character set (A--Z, 0--9, underscore (_), and dollar sign ($)).
  • Assign users the same user name in both the external authentication service and OpenVMS.
  • Do not assign the same user name or user ID to more than one user.

The $GETUAI and $SETUAI system services do not support external passwords. These services operate only on passwords stored in the SYSUAF, and updates are not sent to the external authentication service. Sites using software that makes calls to these services to check passwords or updates should not enable external authentication. Compaq expects to provide a new programming interface to support external passwords in a future release.

5.3.9 Mixed-Version OpenVMS Cluster Systems


Compaq recommends using external authentication on OpenVMS Cluster systems only if all systems are running OpenVMS Version 7.1 or later.

LOGINOUT on earlier version systems continues to enforce normal OpenVMS password policy (password expiration, password history, and so on), on all users, including externally authenticated users.

5.3.10 LGI Callout Services Disable External Authentication


Starting with Version 7.1, the presence of LOGINOUT (LGI) callouts disables external authentication.

5.3.11 No Password Expiration Notification on Workstations


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

Users on personal computers (PCs) 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 if the external password is about to expire. Therefore, sites that enforce password expiration, and whose user population does not primarily use PCs, may elect not to use external authentication for workstation users.

5.4 FDL Utility---Fixing EDIT/FDL Recommended Bucket Size When Disk Cluster Size Is Large


Prior to OpenVMS V7.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 V7.3 modifies the algorithms for calculating the recommended bucket size to suggest a more reasonable size when the disk cluster is large.

5.5 OpenVMS Galaxy Version 7.3

This section contains OpenVMS Galaxy release notes for OpenVMS Version 7.3 and notes from OpenVMS Versions 7.2-1H1, 7.2-1, and 7.2 that apply to this release.

5.5.1 Using Fibre Channel in OpenVMS Galaxy Configurations


Fibre Channel support for OpenVMS Galaxy configurations is included in OpenVMS Alpha Version 7.3 and OpenVMS Alpha Version 7.2-1H1. For OpenVMS Alpha Version 7.2-1, Fibre Channel support for OpenVMS Galaxy configurations is available in Fibre Channel remedial kits, starting with V721_FIBRECHAN-V0200. For the most current information about OpenVMS Fibre Channel configurations, go to:


5.5.2 CPU Migration Restriction


The release of the Compaq Analyze service tool that supports the new Compaq AlphaServer GS Series systems includes a Director process that sets hard affinity to a CPU. A CPU with processes hard affinitized to it cannot be reassigned from one Galaxy instance to another.

This is a temporary restriction.

For more information about Compaq Analyze and its operation, contact your Compaq support representative.

5.5.3 Compatibility of Galaxy Computing Environment and Non-Galaxy Cluster Members


OpenVMS Version 7.2 introduced new security classes that are used in an OpenVMS Galaxy computing environment. The new security classes are not valid on non-Galaxy systems. If your OpenVMS Galaxy is configured in an existing OpenVMS Cluster, you must ensure that all the nodes in the cluster recognize the new security classes as described in this release note.

This situation applies if all of the following conditions are met:

  • If your OpenVMS Galaxy is configured in a cluster with non-Galaxy systems
  • If the non-Galaxy cluster nodes share the VMS$OBJECTS.DAT security database file
  • If you use Galaxywide global sections in your OpenVMS Galaxy
  • If versions of OpenVMS prior to OpenVMS Version 7.1-2 are in use

OpenVMS VAX and Alpha systems running OpenVMS Version 6.2 or Version 7.1 will crash if they encounter an unknown security class in the VMS$OBJECTS.DAT file.

To allow VAX and Alpha systems running older versions of OpenVMS to cooperate with Version 7.2 Galaxy instances in the same OpenVMS Cluster environment, a SECURITY.EXE image is provided for each of these versions. The appropriate remedial kit from the following list must be installed on all system disks used by these systems. (Later versions of these remedial kits may be used if available.)

Alpha V7.1 and V7.1-1xx ALPSYS20_071
Alpha V6.2 and V6.2-1xx ALPSYSB03_062
VAX V7.1 VAXSYSB02_071
VAX V6.2 VAXSYSB03_062

Before you create any galaxywide global sections, you must reboot all cluster members sharing one of the updated system disks.

5.5.4 AlphaServer GS60/GS60E/GS140 Multiple I/O Port Module Configuration Restriction


AlphaServer GS60/GS60E/GS140 configurations with more than a single I/O Port Module, KFTHA-AA or KFTIA-AA, might experience system crashes.

When upgrading OpenVMS Galaxy and non-Galaxy AlphaServer 8200/8400 configurations with multiple I/O Port Modules to GS60/GS60E/GS140 systems, customers must install one minimum revision B02 KN7CG-AB EV6 CPU (E2063-DA/DB rev D01) module as described in Compaq Action Blitz # TD 2632.

For complete details about this restriction and its solution, refer to Compaq Action Blitz # TD 2632.

5.5.5 MOP Booting Restrictions


In an OpenVMS Galaxy computing environment, MOP (Maintenance Operations Protocol) Booting is only supported on Instance 0. This restriction will be removed in a future release.

5.5.6 Restriction on KFMSB and CIXCD Adapters in Galaxy Configurations

Permanent Restriction

Due to firmware addressing limitations on driver-adapter control data structures, KFMSB and CIXCD adapters can only be used on hardware partitions based at physical address (PA) = 0. In OpenVMS Galaxy configurations, this restricts their use to Instance 0.

5.6 LAN ATM (Alpha Only)

This section contains a release note pertaining to the local area network (LAN) asynchronous transfer mode (ATM) software.

5.6.1 Requirements/Restrictions Using DAPBA/DAPCA Adapters for LAN Emulation over ATM (Alpha Only)


The DAPBA (155 Mb/s) and the DAPCA (622 Mb/s) are ATM adapters for PCI-bus systems that are supported by SYS$HWDRIVER4.EXE.

Both adapters require a great deal of non-paged pool, and therefore, care should be taken when configuring them. For each DAPBA, Compaq recommends increasing the SYSGEN parameter NPAGEVIR by 3000000. For each DAPCA, Compaq recommends increasing NPAGEVIR by 6000000. To do this, add the ADD_NPAGEVIR parameter to MODPARAMS.DAT and then run AUTOGEN. For example, add the following command to MODPARAMS.DAT on a system with two DAPBAs and one DAPCA:

             ADD_NPAGEVIR = 12000000

The following restrictions apply to the DAPBA and DAPCA adapters:

  • The adapter cannot be located on a PCI bus that is located behind a PCI-to-PCI bridge.
  • Classical IP is not supported.

5.7 Lock Manager

This section contains notes pertaining to the lock manager.

5.7.1 Lock Manager System Parameter Renamed (Alpha Only)


The OpenVMS Performance Management incorrectly refers to the LOCKMGR_CPU system parameter in its discussion of the Dedicated CPU lock manager. The LOCKMGR_CPU system parameter name has been changed to LCKMGR_CPUID.

5.7.2 Instituting the Dedicated CPU Lock Manager Functionality (Alpha Only)


With OpenVMS Version 7.3, Compaq introduces an alternative locking mode that allows a CPU to be dedicated to the lock manager. The dedicated CPU lock manager can perform better than the traditional lock manager under heavy locking loads. The performance gains are a result of reducing SMP contention and obtaining the benefits of improved CPU cache utilization on the CPU dedicated to the lock manager.

Usage of the dedicated CPU lock manager is only of benefit to systems with a large number of CPUs and heavy SMP contention due to the lock manager. By default, a CPU will not be dedicated to the lock manager. See the OpenVMS Version 7.3 New Features and Documentation Overview for information and details about enabling the dedicated CPU lock manager.

5.7.3 Fast Lock Remastering and PE1 (Alpha Only)


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 later can use large transfers for lock remastering. Remastering between OpenVMS Version 7.3 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, Compaq 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.

5.7.4 Lock Manager and Nonpaged Pool (Alpha Only)


To improve application scalability on OpenVMS Alpha systems, most of the lock manager data structures have been moved from nonpaged pool to S2 space. On many systems, the lock manager data structures accounted for a large percentage of nonpaged pool usage.

Because of this change to nonpaged pool, Compaq recommends the following steps:

  • Use AUTOGEN with feedback information to tune the size of nonpaged pool.
  • Inspect MODPARAMS.DAT to check for any NPAGEDYN or NPAGEVIR settings previously made to increase the size of nonpaged pool due to the lock manager's usage.
    You may find that these parameters can be either trimmed back or removed due to changes to the lock manager.

The SHOW MEMORY documentation in the OpenVMS DCL Dictionary: N--Z describes the memory associated with the lock manager.


This section contains release notes pertaining to the Operator Communication Manager (OPCOM).

5.8.1 OPCOM Messages Changed (Alpha Only)


In OpenVMS Alpha Version 7.2 and later, OPCOM messages from the job controller and the queue manager now display SYSTEM as the user process. For example:

%%%%%%%%%%% OPCOM 16-NOV-2000 15:07:49.33 %%%%%%%%%%%
Message from user SYSTEM on NODEX
%JBC-E-FAILCREPRC, job controller could not create a process

%%%%%%%%%%% OPCOM 16-NOV-2000 15:07:49.34 %%%%%%%%%%%
(from node BENN at 16-NOV-2000 15:07:49.34)
Message from user SYSTEM on NODEX
-QMAN-I-QUEAUTOOFF, queue NODEX$BATCH is now autostart inactive

The examples in the OpenVMS System Manager's Manual do not currently reflect this change.

5.8.2 Handling of Invalid Operator Classes


Previously, if the OPC$OPA0_CLASSES or OPC$LOGFILE_CLASSES logicals contained an invalid class, it would cause OPCOM to signal the error and run down the process.

This problem has been corrected in OpenVMS Version 7.3.

The following two messages have been added to OPCOM:

%%%%%%%%%%%  OPCOM  18-MAY-2000 13:28:33.12  %%%%%%%%%%%
"BADCLASS" is not a valid class name in OPC$LOGFILE_CLASSES

%%%%%%%%%%%  OPCOM  18-MAY-2000 13:28:33.12  %%%%%%%%%%%
"BADCLASS" is not a valid class name in OPC$OPA0_CLASSES

If an invalid class name is specified in either of the logicals, the appropriate error message is displayed. These messages are displayed on the console at system startup and logged to the OPERATOR.LOG.

The list of all operator classes is:

OPER1 through OPER12

When you specify an invalid class, all classes are enabled. This change causes the error messages listed to reach as many operators as possible.



The algorithm formerly used by OPCOM when OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND were set to FALSE was found to be too restrictive. These logical names do not allow messages to flow into or out of the OPCOM process.

When these logicals were used together in an OpenVMS Cluster, it was possible for OPCOM processes on different systems in the cluster to stop communicating. As a result, OPERATOR.LOG files would fill up with messages similar to the following:

%%%%%%%%%%%  OPCOM  29-APR-2000 11:33:31.73  %%%%%%%%%%%
OPCOM on AAAAA is trying again to talk to BBBBB, csid 00010001, system 00001

To correct this problem, the algorithm has been relaxed to allow OPCOM processes in an OpenVMS Cluster to pass communication messages back and forth between one another.

Compaq still recommends caution in the use of these logical names, which should be used only by individuals who truly understand the impact to the entire system if OPCOM messages are disabled in one or both directions.

Previous Next Contents Index