Document revision date: 31 July 2002

V7.2

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.

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 higher and Advanced Server for OpenVMS or PATHWORKS for OpenVMS (Advanced Server), and meet any requirements outlined in the Installation and Configuration Guide for the appropriate server. See this manual and the OpenVMS Guide to System Security for detailed information about using external authentication.

4.14.1 Failed Connection Attempts on POP Server

V7.2

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.

V7.2

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 $

4.14.3 Compaq DECnet-Plus Requirement

V7.2-1

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.

V7.1

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.

4.14.5 DECnet-Plus and NET_CALLOUTS Parameter

V7.3

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.

4.14.6 Impact on Layered Products and Applications

V7.1

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.

4.14.7 Mixed-Version OpenVMS Cluster Systems

V7.1

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

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.

4.14.8 No Password Expiration Notification on Workstations

V7.1

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.

4.15 Fixing EDIT/FDL Recommended Bucket Size

V7.3

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.16 OpenVMS Galaxy Version 7.3-1

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

4.16.1 Galaxy on ES40: Turning Off Fast Path (Temporary Restriction)

V7.3-1

When you implement Galaxy on an ES40 system, it is necessary to turn off Fast Path on instance 1. Do this by setting the SYSGEN parameter FAST_PATH to 0 on that instance.

If you do not turn off Fast Path on instance 1, I/O on instance 1 will hang when instance 0 is rebooted. This hang will continue until the PCI bus is reset and instance 1 rebooted. If there is shared SCSI or Fibre Channel, I/O will hang on the sharing nodes and all paths to those devices will be disabled.

This restriction should be removed in the future.

4.16.2 Using Fibre Channel in OpenVMS Galaxy Configurations

V7.3-1

Fibre Channel support for OpenVMS Galaxy configurations is included in OpenVMS Alpha Version 7.3 or higher, Version 7.2-2, and 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:

V7.2

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:

• Your OpenVMS Galaxy is configured in a cluster with non-Galaxy systems.
• The non-Galaxy cluster nodes share the VMS$OBJECTS.DAT security database file.
• You use Galaxywide global sections in your OpenVMS Galaxy.
• 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 fail if they encounter an unknown security class in the VMS$OBJECTS.DAT file.

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

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

V7.2-1

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

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.

4.16.5 MOP Booting Restrictions

V7.2

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.

4.16.6 Restriction on KFMSB and CIXCD Adapters in Galaxy Configurations

Permanent Restriction

Because of 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.

4.17 AlphaServer GS Series: NPAGERAD System Parameter Default Behavior

V7.3-1

On AlphaServer GS series processors on OpenVMS systems prior to Version 7.3-1, system managers frequently saw pool expansion that increasing NPAGEDYN did not reduce. This problem was caused by leaving NPAGERAD at its default value of 0.

Starting in OpenVMS Version 7.3-1, when NPAGERAD is 0 (the default), the system calculates a value to use for NPAGERAD with the following formula:

Base RAD memory NPAGEDYN * (1- --------------- ) Total memory

This calculation gives more pool to the nonbase RADs than before and so reduces the expansion of nonbase RAD pool.

4.18 LAN ATM---Restrictions on DAPBA/DAPCA Adapters for LAN Emulation

V7.3

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 nonpaged pool, and therefore, care should be taken when configuring them. For each DAPBA, Compaq recommends increasing the system 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.

V7.3-1

If you have installed any of the following kits:

VMS73_ACMS-V0100
VMS722_ACMS-V0100
VMS721H1_ACMS-V0100
VMS721_ACMS-V0100

and then you upgrade to V7.3-1, the following ACMS files could be deleted:

ACMSSTART.COM
ACMSBOOT.EXE

This will cause ACMS to fail after the upgrade. To remedy this, install the ACMS_U2_043.A remedial kit. This kit replaces the kits in the preceding list.

You can get the kit from the following web site (follow the version links to the ACMS_U2_043.A kit):

This section contains notes pertaining to the lock manager.

4.20.1 Fast Lock Remastering and PE1

V7.3

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, 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.

4.20.2 Lock Manager and Nonpaged Pool

V7.2

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.

4.21 OPCOM

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

4.21.1 Handling of Invalid Operator Classes---Problem Corrected

V7.3

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

This problem has been corrected in OpenVMS Version 7.3 or higher.

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:

CARDS
CENTRAL
CLUSTER
DEVICES
DISKS
LICENSE
NETWORK
OPER1 through OPER12
PRINTER
SECURITY
TAPES

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

4.21.2 OPC$ALLOW_INBOUND and OPC$ALLOW_OUTBOUND Changes

V7.3

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.

4.21.3 Workstations in OpenVMS Clusters

V7.3

The default behavior of OPCOM is to not enable OPA0: on workstations in clusters. OPCOM also does not enable the logfile, OPERATOR.LOG, on these systems. The only exception is if the workstation is the first system into the cluster.

OPCOM determines whether a system is a workstation by testing for a graphics device. This test is specifically:

F$DEVICE ("*", "WORKSTATION", "DECW_OUTPUT")

OPCOM is treating systems shipped with graphic devices as workstations. As a result, OPA0: and OPERATOR.LOG are not enabled by default.

To override the default behavior, define the following logical names in SYS$MANAGER:SYLOGICALS.COM to be TRUE:

• OPC$OPA0_ENABLE
• OPC$LOGFILE_ENABLE

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

4.22.1 SET PREFERRED_PATH for Disk with MSCP Access Only---Problem Corrected

V7.3-1

The following problem (reported in the V7.2-2 Release Notes) has been corrected:

Previously, if you specified a preferred path (using the command SET PREFERRED_PATH/HOST) for a disk with only MSCP server access (that is, not a local disk) and the host that you specified shut down or failed, failover to an alternate path would not happen.

	privacy and legal statement
6652PRO_005.HTML