OpenVMS Version 7.1 Release Notes

Several combinations of VAXstations, AlphaStations, 486, and Pentium processors have been tried, with no serious restrictions or performance problems.

Following are some general tips:

• Use a high-resolution monitor. A typical 640-X-480 pixel VGA display is too small. You can fine-tune the geometry and placement of your OpenVMS Debugger windows by editing your VMSDEBUG.DAT file (using the customization features described in the OpenVMS Debugger Manual). It is suggested that you make the windows as small as you are comfortable with, and overlap their placement as needed to minimize display space requirements.
• Users of DECterm emulators should restrict their use to the screen-mode command interface, and not try to run the DECwindows Motif interface. Screen-mode debugging should be successful with any reasonably X-compliant terminal emulator, such as a DECterm (that is, created with the CREATE/TERM/DETACH command).

This section contains release notes pertaining to DECamds. DECamds is a separately installable, real-time, high-performance, multisystem monitoring utility that is operated from a centralized, mouse-driven DECwindows display. For more information about DECamds, refer to the DECamds User's Guide, which ships on the OpenVMS Version 7.1 Documentation CD--ROM.

4.5.1 Changes and Enhancements

The following section describes a change in licensing for DECamds.

4.5.1.1 License is Now Included with OpenVMS

V7.1

Starting with OpenVMS Version 7.1, the right to use DECamds will be provided with the OpenVMS base operating system license. Prior to Version 7.1, the right to use DECamds was provided with the OpenVMS Cluster software license. This change was made in response to customer demand to use the system management capabilities provided by DECamds in a nonclustered environment.

4.5.2 Problems and Restrictions

The following section describes a DECamds restriction.

4.5.2.1 Kernel Threads Not Supported (Alpha Only)

V7.0

DECamds support for kernel threads has not been implemented on OpenVMS Alpha systems. If you use threaded processes, DECamds displays only the top thread.

4.6 DECdtm Services

This section contains release notes pertaining to DECdtm services.

4.6.1 Problems and Restrictions

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

4.6.1.1 Kernel Threads Restriction (Alpha Only)

V7.1

On OpenVMS Alpha systems, unpredictable results can occur if DECdtm services are used in a multithreaded environment. Do not make calls to DECdtm services in kernel threads other than the root thread because much of the work performed by DECdtm uses the context of the calling process.

4.7 DECevent Fault Management Support (Alpha Only)

Alpha V6.2

Starting with OpenVMS Alpha Version 6.2, DECevent replaces the Error Reporting Formatter (ERF) as the bit-to-text translating tool for fault management on OpenVMS systems. While the ERF is still available, it will be retired in a future release of the OpenVMS operating system.

Refer to Section 1.4.1.1 for information about a change in how the DECevent DIAGNOSE command is enabled starting with OpenVMS Alpha Version 7.1.

4.7.1 Problems and Restrictions

This section describes problems and restrictions related to using the DECevent fault management tool.

4.7.1.1 Bit-to-Text Translation Support

V6.2

DECevent bit-to-text translation is supported on many products and devices. On other devices, as much translation as possible is performed and all remaining information in the event is dumped in hexadecimal.

Contact your Digital support representative if you have questions about the type of DECevent support currently available for your devices.

4.7.1.2 Logical File Names

V6.2

DECevent is unable to translate as input any logical defined as a search list of file names. For example:

 
$ DEFINE EVENT_LOG DISK1:[EVENTS]EVENT_LOG1.SYS,DISK1:[EVENTS]EVENT_LOG2.SYS 
$ DIAGNOSE/ANALYZE EVENT_LOG 
 
 
DECevent T1.0 FT2 
_DIAGNOSE-FAT: Analyze - No files found ' event_log ' 
_DIAGNOSE-FAT: An error occurred while executing a command ruleset 
_DIAGNOSE-INF: No Error Messages to send in thread 1 

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 LAN Manager user IDs and passwords.

To enable external authentication on your system, the following are required:

• PATHWORKS Version 5.0E for OpenVMS, operating as a LAN Manager domain member, BDC, or PDC
• Windows NT server (if used) must enable LAN Manager Version 2.x updates
• DECwindows Version 1.2--4

For more information about external authentication, refer to the OpenVMS Version 7.1 New Features Manual or the version of the OpenVMS Guide to System Security that ships on the OpenVMS Version 7.1 Documentation CD--ROM.

4.8.1 Changes and Enhancements

The following note describes a change in behavior related to external authentication.

4.8.1.1 OpenVMS User Name Prompt Accepts Case-Sensitive Terminal Input

V7.1

You can enter a case-sensitive user name at the OpenVMS user name prompt if you enclose it in quotation marks. If you do not enclose the user name in quotation marks, LOGINOUT converts the user name to uppercase characters.

OpenVMS and LAN Manager user names are not case-sensitive. Therefore, quotation marks are not necessary if you enter an OpenVMS user name or a LAN Manager user ID. In future releases, external authentication may support other authentication services that allow case-sensitive user names.

You can restore previous behavior on your OpenVMS system by setting the forced uppercase configuration bit in the SYS$SINGLE_SIGNON logical name. (See the OpenVMS Version 7.1 New Features Manual or the Managing System Access chapter in the OpenVMS Guide to System Security for more information.)

4.8.2 Problems and Restrictions

The following notes describe problems or restrictions related to external authentication.

4.8.2.1 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 LAN Manager user ID and OpenVMS user name are different
• Where the user's SYSUAF password is different than the LAN Manager 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. 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 LAN Manager user ID used to authenticate the user during login

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

If you enable external authentication, Digital 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 LAN Manager 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 LAN Manager 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 LAN Manager. Enabling external authentication is not recommended for sites using software that makes calls to these services for the purposes of password checking or updates. Digital expects to provide a new programming interface for this purpose in a future release.

4.8.2.2 Mixed-Version OpenVMS Cluster Systems

V7.1

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

When external authentication is enabled on systems running versions of OpenVMS earlier than Version 7.1, only the Version 7.1 systems directly interact with LAN Manager. The earlier version systems continue to use the SYSUAF file for authentication and management of passwords.

If password synchronization is enabled on the Version 7.1 systems (the default), the SYSUAF passwords are kept synchronized with LAN Manager passwords and users can log in to the earlier version systems using their OpenVMS user names and passwords. LAN Manager user IDs cannot be used on the earlier version systems. (If a site maintains identical OpenVMS user names and LAN Manager user IDs, this is not an issue.)

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.8.2.3 LGI Callout Services Disable External Authentication

V7.1

In Version 7.1, the presence of LOGINOUT (LGI) callouts disables external authentication. This restriction is expected to be removed in a future release.

4.8.2.4 DECwindows Pause Screen Uses SYSUAF Password

V7.1

The DECwindows pause screen unlock mechanism does not use LAN Manager 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.8.2.5 FTP Server and Failed Connections With External Authentication

V7.1

The File Transfer Protocol (FTP) server does not use external authentication to authenticate FTP connections on the OpenVMS system. This causes connects to fail if either of the following conditions exist:

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

V7.1

In order to run DECnet-Plus for OpenVMS with external authentication enabled, set the SYSGEN parameter NET_CALLOUTS to 255. This enables LAN Manager user ID mapping and authentication for network logins.

4.8.2.7 PATHWORKS LAN Manager Server Required for External Password Updates

V7.1

External authentication using LAN Manager requires a running LAN Manager server to support external password changes initiated by users. Password changes fail if a LAN Manager server is not present.

This restriction will be removed in a future release.

4.8.2.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 LAN Manager 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.

This problem will be fixed in a future release.

4.9 Install Utility

This section contains release notes pertaining to the Install utility (INSTALL).

4.9.1 Changes and Enhancements

This section describes a change to INSTALL.

4.9.1.1 Installing Images

V6.2

The REPLACE option for the OpenVMS Install utility (INSTALL) has been changed to modify the known file database in an atomic fashion.

In the past, REPLACE was equivalent to DELETE followed by ADD. Consequently, there was a short time during which neither the new nor the old image was in the known file database. When activating protected or privileged images, this could result in failed image activations. Also, if the new image could not be installed, it was possible for neither the old nor the new image to be installed after the failure.

These problems are now corrected.

With the change, REPLACE operations for images installed with the /SHARED qualifier might require more global sections or global pages than in the past. Also, the names of global sections have been changed to avoid naming conflicts. The global sections can be displayed with one of the following commands:

$ INSTALL LIST /GLOBAL

or

$ INSTALL LIST image-name /GLOBAL

This section contains release notes pertaining to the LAN ATM (asynchronous transfer mode) software.

4.10.1 Problems and Restrictions

This section describes a problem with the LAN ATM Software.

4.10.1.1 ATM Switch Problem

V7.1

The LAN ATM software is set to automatically sense the User-to-Network Interface (UNI) version. Some ATM switches do not work with this feature. If your emulated LAN or classical IP subnet cannot be enabled, set both the ATM switch and the OpenVMS Alpha system to run at the same UNI version. (Use the SYSGEN parameter LAN_FLAGS to set the OpenVMS system.)

4.11 LANCP/LANACP Servers

This section contains release notes pertaining to the LANCP/LANACP servers.

4.11.1 Changes and Enhancements

The following note describes a change that affects how the LANACP LAN server application is started.

4.11.1.1 LANACP LAN Server Application Startup (Alpha Only)

V7.1

The LANACP LAN server application is now started in VMS$DEVICE_STARTUP.COM. The LAN$STARTUP command has been removed from the system startup template file, SYSTARTUP_VMS.TEMPLATE, because the command is no longer necessary.

4.12 Mail Utility

This section contains release notes about the Mail utility that are of interest to system managers. Release notes of interest to programmers are documented in Section 5.14.

4.12.1 Changes and Enhancements

The following note describes an important change to Mail.

4.12.1.1 MAIL.EXE and Privileges

V7.0

The OpenVMS installation procedure does not initially install MAIL.EXE with any privileges (because MAIL.EXE does not require privileges to perform its functions). Prior versions of the OpenVMS operating system did include mechanisms that allowed MAIL.EXE to check, ignore, grant, or override certain privileges that a system manager might assign when reinstalling MAIL.EXE. Because these regulatory mechanisms sometimes created unexpected or undesirable conditions, they have been removed in Version 7.0 of the OpenVMS operating system.

Caution

If you reinstall MAIL.EXE with certain privileges, you must carefully consider possible ramifications, including the potential for security breaches. For example, because MAIL.EXE confers its privileges on any user who invokes the Mail utility, that user will inherit those privileges if the user creates a subprocess from within Mail by specifying the SPAWN command.

The following release notes pertain to the Mount utility (MOUNT).

4.13.1 Corrections

This section describes corrections to MOUNT.

4.13.1.1 MOUNT/CLUSTER and DISMOUNT/CLUSTER Commands Function Correctly

V7.1

The Mount utility has been completely rewritten for OpenVMS Version 7.1 and is now significantly faster and more robust.

In previous releases, some cluster configurations could not successfully use the DCL commands MOUNT/CLUSTER and DISMOUNT/CLUSTER, and were forced to use workarounds such as using the SYSMAN utility to issue remote node MOUNT and DISMOUNT commands. With OpenVMS Version 7.1 this restriction is removed. The MOUNT/CLUSTER and DISMOUNT/CLUSTER commands now function correctly under all circumstances.

4.14 Nonpaged Pool

This section contains release notes pertaining to nonpaged pool.

4.14.1 Changes and Enhancements

This section describes changes to nonpaged pool.

4.14.1.1 Reclamation Algorithms Changed (Alpha Only)

V7.1

On OpenVMS Alpha systems, nonpaged pool reclamation algorithms have been changed to ensure that packets put onto lookaside lists are returned to variable pool in a timely fashion. Both gentle and aggressive reclamation algorithms have been changed to return more packets to variable pool.

Reclamation of a list first puts all the packets on the list back into variable pool, and then repopulates the list to the requested percentage of original packets.

Each gentle reclamation pass processes two lists. Therefore, using the 30-second default interval, all 80 lists are processed every 20 minutes.

If you have some very long lookaside lists (because of increased activity), and the packets are no longer frequently used, take the following temporary actions:

• Decrease the value of the NPAG_GENTLE system parameter so that a smaller percentage of packets remains on the list after reclamation.
• Decrease the value of the NPAG_INTERVAL system parameter so that reclamation occurs more frequently.

Aggressive reclamation still processes lists until one of the following events occurs:

• The allocation request is satisfied.
• The request cannot be satisfied from existing pool, so pool is expanded until the request can be satisfied.

If you are willing to use extra cycles to avoid expanding pool, decrease the value of the NPAG_AGGRESSIVE system parameter. This causes more packets to return to variable pool, thus increasing the chances of satisfying a request without expanding pool.

Refer to the OpenVMS Version 7.1 New Features Manual for descriptions of the new system parameters that are related to changed reclamation algorithms.

4.15 OpenVMS Cluster Systems

The following sections contain release notes pertaining to OpenVMS Cluster systems.

4.15.1 Changes and Enhancements

This section contains notes about changes and enhancements to OpenVMS Cluster systems.

4.15.1.1 Cluster Client License Changes

V7.1

A change has been made to OpenVMS Cluster Client licensing. Prior to Version 7.1, the OpenVMS Cluster Client license enabled full OpenVMS Cluster functionality, with the following exceptions:

• Client CPUs could not provide votes toward the operation of the OpenVMS Cluster system.
• Client CPUs could not use MSCP to serve disks or TMSCP to serve tapes.

Previously, the first exception regarding voting was not enforced. Starting with Version 7.1, this exception is enforced.

4.15.1.2 OpenVMS Cluster Compatibility Kit for Version 6.2 Systems

V7.1

The OpenVMS Cluster Compatibility Kit provides many OpenVMS Version 7.1 enhancements for Version 6.2 systems. This kit is required for Version 6.2 systems if they are included in a cluster with Version 7.1 systems (same system architecture or a mix of VAX and Alpha systems). Optionally, users can install it on other OpenVMS Version 6.2 systems to derive the same benefits.

Cluster Compatibility Kit Features

The Cluster Compatibility Kit includes the following improvements for systems running OpenVMS Version 6.2:

• OpenVMS Version 7.1 Volume Shadowing enhancements
  The volume shadowing enhancements include significant quality improvements and an increase in supported shadow set members from 400 to 500. Note that the Version 7.1 volume shadowing system disk minimerge feature is not included in the Cluster Compatibility Kit nor is the Dump file off the system disk for OpenVMS Alpha. (Dump file off the system disk has been available for OpenVMS VAX systems since Version 6.2.)

  ---

  Note

  If you use volume shadowing, be sure to read the volume shadowing release notes in Section 4.25.

  ---

• OpenVMS Version 7.1 Mount enhancements
  The Mount utility has been completely rewritten, resulting in a faster, more robust utility.
• Correction to a lock manager problem found in OpenVMS Version 6.2
  The lock manager changes correct a problem in OpenVMS Version 6.2 that could corrupt some internal states in lock information used by fork lock routines, notably the I/O cache subsystem. This problem was corrected in OpenVMS Version 7.0, and also in the limited hardware releases for OpenVMS Alpha Version 6.2-1H2 and Version 6.2-1H3.
• Limited support for new port allocation classes for SCSI devices
  Port allocation classes are a new naming option for SCSI devices on systems running OpenVMS Alpha Version 7.1. If you have installed the Cluster Compatibility Kit (on a VAX or Alpha system), you can access SCSI disks on an OpenVMS Alpha Version 7.1 system that use port allocation classes in their names, but you cannot name SCSI disks on a Version 6.2 system with port allocation classes.

Snapshot Facility Disabled

Installing the Cluster Compatibility Kit on a Version 6.2 system disables the Snapshot facility, which has been removed from OpenVMS VAX Version 7.1 (see Section C.9).

System Dump Analyzer Utility (SDA)

A special version of the OpenVMS Version 6.2 System Dump Analyzer (SDA) utility is included in the Cluster Compatibility Kit. It recognizes the new Volume Shadowing data structures.

When you install the Cluster Compatibility Kit, the existing OpenVMS Version 6.2 SDA is renamed SDA_OLD.EXE and the Cluster Compatibility Kit version is named SDA.EXE. Use SDA_OLD.EXE to analyze crash dumps from an OpenVMS Version 6.2 system that has not installed the Cluster Compatibility Kit. Use SDA.EXE to analyze crash dumps from an OpenVMS Version 6.2 system that has installed the Cluster Compatibility Kit.

Installing the Cluster Compatibility Kit

Two kits are available, one for OpenVMS VAX Version 6.2 systems and one for OpenVMS Alpha Version 6.2 systems. Each kit is on its respective OpenVMS CD--ROM, as follows:

• [CLUSTER_COMP_VAX062]VAXCOMPAT_062.A (for VAX)
• [CLUSTER_COMP_ALPHA062]ALPCOMPAT_062.A (for Alpha)

To install the VAX kit, use the following command:

$ @SYS$UPDATE:VMSINSTALL VAXCOMPAT_062.A ddcu:[CLUSTER_COMP_VAX062] 

To install the Alpha kit, use the following command:

$ @SYS$UPDATE:VMSINSTALL ALPCOMPAT_062.A ddcu:[CLUSTER_COMP_ALPHA062] 

V7.1

The OpenVMS Alpha Version 7.1 operating system supports the KFPSA, a PCI-to-DSSI adapter, on all PCI-based AlphaServer computers.

Previously, a maximum of four KFPSA adapters was allowed per system. With OpenVMS Version 7.1, the maximum has been raised to 24.

4.15.1.4 Maximizing CIPCA Adapter Performance With an HSJ50

V7.1

To maximize the performance of the CIPCA adapter with an HSJ50 controller, Digital recommends that you enable the use of 4K CI packets by the HSJ50. To do this, your HSJ50 firmware revision level must be at Version 5.0J--2 or higher (see Section 4.15.2.4.2).

To enable the use of 4K CI packets, specify the following command at the HSJ50 console prompt:

CLI> SET THIS_CONTROLLER CI_4K_PACKET_CAPABILITY 

This command takes effect when the HSJ50 is rebooted.

4.15.1.5 Fast Path Support for CIPCA

Fast Path, introduced in OpenVMS Version 7.0, is an optional, high-performance feature designed to improve I/O performance. In OpenVMS Version 7.1, Fast Path support for disk I/O has been extended to the CIPCA port. For OpenVMS Version 7.0, support was limited to the CIXCD port.

CI Fast Path disk I/O is now supported for both PCI and XMI based systems. For more information about Fast Path, see the OpenVMS I/O User's Reference Manual.

4.15.1.6 CIPCA Use of Synchronous Arbitration Algorithm

CIPCA uses a new, optimal CI arbitration algorithm, called Synchronous Arbitration, instead of the older Asynchronous Arbitration algorithm. The two algorithms are completely compatible. Under CI saturation conditions, both the old and new algorithms are equivalent and provide equitable round-robin access to all nodes. However, under less than saturation conditions, the new algorithm provides the following benefits:

• Reduced packet transmission latency due to reduced average CI arbitration time.
• Increased node-to-node throughput.
• Complete elimination of CI collisions that waste bandwidth and increase latency in configurations containing only Synchronous Arbitration nodes.
• Complete compatibility on the same CI between nodes using Synchronous Arbitration and nodes using the older Asynchronous Arbitration (with CIXCDs, HSCs, CIBCAs, and so forth).
• Reduced CI collision rate in configurations with mixed Synchronous and Asynchronous Arbitration CI nodes. The reduction is roughly proportional to the fraction of CI packets being sent by the Synchronous Arbitration CI nodes.

  6481P003.HTM
  OSSG Documentation
  11-DEC-1996 07:51:50.93

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal