Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS Version 7.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 OpenVMS Version 7.2 New Features Manual.

4.1 Alpha System Dump Analyzer (SDA)

This section contains release notes pertaining to the Alpha System Dump Analyzer (SDA).

4.1.1 Changes and Enhancements

The following note describes a change that is visible from the SDA utility.

4.1.1.1 Number of Nonpaged Pool Lookaside Lists Increased

V7.2

In Version 7.2, 48 more nonpaged pool lookaside lists have been added to now accommodate a maximum packet size of 8192 bytes. The number of packets on each list can be viewed by entering the CLUE MEMORY /LOOKASIDE command from the SDA utility.

4.2 Backup Utility

Release notes in this section pertain to the Backup utility (BACKUP).

4.2.1 Changes and Enhancements

The note in this section provides a performance tip.

4.2.1.1 Writing a Save Set to a Files-11 Mounted Disk

V7.2

Beginning with OpenVMS Version 7.2, performance is improved when you write a save set to a Files-11 mounted disk with high-water marking. This performance improvement is the result of avoiding high-water marking erase IOs when the save set is written to the disk.

4.2.2 Problems and Restrictions

This section describes known problems and restrictions for the Backup utility.

4.2.2.1 /MEDIA_FORMAT=COMPACTION Qualifier Ineffective on TA90 Devices

V7.2

The introduction of multiple tape density in OpenVMS Version 7.2 causes TA90 tape drives not to be properly placed in compaction mode when the standard DCL qualifier /MEDIA_FORMAT=COMPACTION is used in INITIALIZE, BACKUP, or MOUNT commands. The command and qualifier are accepted at the DCL level, but the device does not change modes.

To work around this problem, use the new qualifier /MEDIA_FORMAT=(DENSITY=3480,COMPACTION) to correctly place the device in compaction mode.

4.2.2.2 /OWNER and /BY_OWNER Qualifiers Require Numerical Identifiers

V7.2

Commands like the ones in the following sequence produce an error and error messages in BACKUP: 


$ CREATE X.X 
$ BACKUP X.X X.SAV/SAVE 
$ BACKUP X.SAV/SAVE *.*/OWNER=SYS$NODE_'F$GETSYI("NODENAME") 
%BACKUP-F-BADOPTVAL, invalid callable interface option value, 
 argument position 7, option type = 59, option value = 2147549196

The qualifier /BY_OWNER can also result in an error and a message similar to the one in the preceding example.

With both qualifiers, the error occurs when you enter a general identifier rather than a numerical one; for example, BACKUP accepts a command like the following one: 


$ BACKUP [.EXE]S.SAV/SAV *.*/OWNER=[100,100]/LOG 
%BACKUP-S-CREATED, created $4$DUA155:[BTE.VMSTEST.BACKUP_REG]X.X;2 
%BACKUP-S-CREATED, created $4$DUA155:[BTE.VMSTEST.BACKUP_REG]X.X;1 
$

You can work around this problem by entering a numerical identifier.

4.3 Compaq Galaxy Software Architecture on OpenVMS Alpha

V7.2

OpenVMS Alpha Version 7.2 introduces the Galaxy Software Architecture on OpenVMS Alpha. By running multiple instances of OpenVMS in a single computer, an OpenVMS Galaxy computing environment provides extremely flexible operational computing capabilities. This computing environment can be dynamically adapted to changing application needs and workload demands.

The Compaq Galaxy Software Architecture on OpenVMS Alpha is available as a separately licensed System Integrated Product (SIP).

For more information about how to transform an AlphaServer 8400, 8200, or 4100 system into an initial OpenVMS Galaxy computing environment and how to use the OpenVMS Galaxy capabilities available in OpenVMS Version 7.2, refer to the OpenVMS Alpha Galaxy Guide. This manual also contains any release notes about the Galaxy Software Architecture on OpenVMS.

4.4 DECamds

This section contains release notes pertaining to DECamds.

4.4.1 Changes and Enhancements

The following sections describe important changes to DECamds beginning with OpenVMS Version 7.2.

4.4.1.1 Installation Procedure Change

V7.2

DECamds consists of client and server software:

In earlier versions of OpenVMS, you needed to install both client and server software on your system from the lastest DECamds kit.

Server Software: No Installation Required

Beginning with OpenVMS Version 7.2, the Data Collector ships as part of the OpenVMS installation. In other words, after you install or upgrade to OpenVMS Version 7.2, the Data Collector is on your system.

To use the Data Collector, do either of the following:

Client Software: Installation Required

In OpenVMS Version 7.2, you still need to reinstall the DECamds client software on the system where you run the client, or graphical user interface. You need to do this to obtain the new library for DECamds Version 7.2.

Making RMDRIVER part of OpenVMS requires moving the following files:
File New Directory Location
AMDS$DRIVER_ACCESS.DAT SYS$MANAGER
AMDS$RMCP.EXE SYS$SYSTEM
AMDS$LOGICALS.COM SYS$MANAGER

These new directory locations should not affect previous copies of AMDS$DRIVER_ACCESS.DAT that are in the AMDS$SYSTEM directory because the AMDS$SYSTEM logical is now a search list for SYS$COMMON:[AMDS] and SYS$COMMON:[SYSMGR]. Copies of the files listed above from previous versions of DECamds will still be valid; however, new copies of the files will be placed in the new locations.

4.4.1.2 Event Log File and Lock Log File Enhanced

V7.2

Prior to Version 7.2, the Event Log File and Lock Log File were created with a default creation size of 1 block and a default extension size of 1 block. This sometimes resulted in a very fragmented log file (and disk) when DECamds was allowed to run for a long period of time.

Two new logicals in the AMDS$LOGICALS.COM file allow users to define additional sizes in log files; these logicals and their default values are shown in the following table:
Logical Description Default Value
AMDS$EVTLOG_ALLOC_SIZE Sets the initial size of the log files 100 blocks
AMDS$EVTLOG_EXTNT_SIZE Sets the extension size of a file when it needs to grow 0 blocks

The default value for AMDS$EVTLOG_EXTNT_SIZE causes DECamds to use the system defaults for extent size.

4.4.1.3 Handling of Unknown Adapter Types Improved

V7.2

Prior to Version 7.2, DECamds labeled an adapter that reported an unknown RPORT value "UNKNOWN", but provided no other information in the SCA Summary Window. Beginning with Version 7.2, DECamds displays the value that a remote system returns for RPORT as well as the "UNKNOWN" label.

4.4.1.4 Similar Groups Sorted Correctly

V7.2

Prior to Version 7.2, if the first three characters of group names were similar, DECamds sometimes did not sort them correctly. In OpenVMS Version 7.2, the sorting algorithm has been corrected, and DECamds now sorts group names correctly.

4.4.2 Problems and Restrictions

The following section describes DECamds restrictions.

4.4.2.1 Kernel Threads Not Supported (Alpha Only)

V7.2

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.5 DECdtm Services

This section contains release notes pertaining to DECdtm services.

4.5.1 Problems and Restrictions

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

4.5.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 initial thread because much of the work performed by DECdtm uses the context of the calling process.

4.6 DECevent Fault Management Support

This section contains a release note about the changes included in the latest version of DECevent. For information about installing DECevent, see Section 1.2.1.4.

4.6.1 Changes and Enhancements

The following release note explains the requirement to use DECevent Version 2.9 with OpenVMS Version 7.2.

4.6.1.1 DECevent Version 2.9 or Later Required to Analyze Errors

V7.2

Starting with OpenVMS Version 7.1--2, DECevent Version 2.9 or later is required to analyze error log files.

The binary error log file format has changed and older versions of DECevent will not work. Additionally, there have been changes made for some device-specific error log entries.

DECevent Version 2.9 provides a separate utility, the Binary Error Log Translation utility, in the DECevent kit. The Binary Error Log Translation utility is used to convert the new Common Event Header (CEH) binary error log file into a binary error log file whose header format and structure can be read by earlier versions of DECevent and by the Error Reporting Formatter (ERF), an older utility. For more information about the Binary Error Log Translation utility, refer to its documentation, which is included in the DECevent kit.

Note that the DCL command ANALYZE/ERROR_LOG, which invokes ERF, does not support MEMORY CHANNEL and other new devices. Using that command will result in improperly formatted error log entries.

Install the DECevent kit supplied on the OpenVMS CD-ROM. Then use the following commands to invoke DECevent to analyze dump files:

For information about the DIAGNOSE command, use the HELP DIAGNOSE command; for additional information, refer to the OpenVMS DCL Dictionary. For more information about DECevent, refer to the OpenVMS System Manager's Manual, the OpenVMS System Management Utilities Reference Manual, and the DECevent documentation included in the DECevent kit.

4.7 Extended File Specifications

This section contains a release note pertaining to Extended File Specifications. For more information about Extended File Specifications, see the OpenVMS Guide to Extended File Specifications.

4.7.1 Problems and Restrictions

The following note describes a restriction to extended file names.

4.7.1.1 Mixed UNIX Style and VMS Style File Names Not Supported (Alpha Only)

V7.2

The ODS-5 volume structure, introduced in OpenVMS Alpha Version 7.2, supports long file names, allows the use of a wider range of characters within file names, and preserves case within file names.

However, the DEC C RTL shipped with OpenVMS Alpha Version 7.2 does not provide full support for extended file names on ODS-5 devices. This lack of full support imposes certain restrictions on users running Netscape FastTrack Server or using Java applications on ODS-5 devices.

In general, users running Netscape FastTrack or using Java applications on OpenVMS can enter either UNIX style file names or VMS style file names. (FastTrack usually outputs UNIX style file names.) With both products, file names are often created by FastTrack or by the Java Virtual Machine.

Because mixed UNIX style and VMS style extended file names are not yet supported by the DEC C RTL, you may be required to use UNIX style syntax when interacting with Java applications or FastTrack, for example, to modify a root to which you append additional directories or a file name.

The following example shows samples of mixed UNIX style and VMS style file names that are not supported in OpenVMS Alpha Version 7.2: 


 doc/foo.bar.bar 
 ./tmp/foo.bar.b^_ar 
 ~foo^.bar

You can, however, modify the last example so that it works as an OpenVMS extended file name that has a tilde (~) as the first character. Precede the leading tilde (~) with the Extended File Specifications escape character (^). For example: 


 ^~foo^.bar

See the OpenVMS Guide to Extended File Specifications for more information about using the tilde (~) in OpenVMS extended file names. Mixed UNIX style and VMS style file names will be supported in a future release of the DEC C RTL for OpenVMS Alpha Version 7.2.

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

4.8.1 Changes and Enhancements

The following note describes a change related to external authentication support.

4.8.1.1 FTP Server Uses External Authentication

V7.2

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

4.8.1.2 DCL Command Interface to Control External Authentication

V7.2

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.

4.8.2 Problems and Restrictions

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

4.8.2.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:

4.8.2.2 SET PASSWORD Behavior Within a DECterm Terminal Session

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.8.2.3 DECnet Phase IV Requirement

V7.2

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

For example, if you enter the following command: 


 $ DIRECTORY nodename"username password"::

where "nodename" is running DECnet Phase IV and "username" is an EXTAUTH account, DECnet will uppercase the string "password" before it is passed to the external authentication agent (a PATHWORKS or NT domain controller).

This does not happen if the node is running DECnet Phase V on OpenVMS Version 7.2 and if the system has the system parameter NET_CALLOUTS set to 255. (See Section 4.8.2.8.)

There are two workarounds:

4.8.2.4 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:

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:

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:

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

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

4.8.2.6 LGI Callout Services Disable External Authentication

V7.1

Starting with 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.7 DECwindows Pause Screen Uses SYSUAF Password

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.8.2.8 DECnet-Plus and NET_CALLOUTS Parameter

V7.1

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

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

This problem will be fixed in a future release.

4.9 Fast Path (Alpha Only)

This section contains release notes pertaining to Fast Path. Fast Path is a high-performance feature designed to improve I/O performance. For more information about Fast Path, refer to the OpenVMS I/O User's Reference Manual.

4.9.1 Changes and Enhancements

The following release notes describe recent changes in Fast Path support.

4.9.1.1 SYSGEN Parameter Changes

V7.2

Fast Path is now enabled by default. To disable Fast Path, set the FAST_PATH SYSGEN parameter to 0.

Also, the IO_PREFER_CPUS parameter is now a dynamic SYSGEN parameter. Changing IO_PREFER_CPUS results in Fast Path ports being rebalanced across the set of usable CPUs.

4.9.1.2 DCL Support

V7.2

The following DCL commands now support Fast Path:

For more information about these commands, refer to the OpenVMS DCL Dictionary.

4.9.1.3 STOP/CPU Command Is Allowed

V7.2

Prior to Version 7.2, you could not use the DCL command STOP/CPU to stop the Fast Path preferred CPU. This restriction has been removed.

4.10 Lock Manager

This section contains notes pertaining to the lock manager.

4.10.1 Changes and Enhancements

The following note describes changes that have been made to the lock manager data structures.

4.10.1.1 Lock Manager and Nonpaged Pool (Alpha Only)

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:

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

4.11 Monitor Utility

The following notes pertain to the Monitor utility (MONITOR).

4.11.1 Problems and Restrictions

The following release note describes how to deal with version incompatibilities when monitoring a pre-Version 7.2 node from a Version 7.2 node.

4.11.1.1 Monitoring Pre-Version 7.2 Nodes from Version 7.2 Nodes

V7.2

Changes made to the Monitor utility in OpenVMS Version 7.2 are incompatible with previous versions of OpenVMS. If you attempt to monitor a pre-Version 7.2 node from a Version 7.2 node, you will get an incompatible version error message, as follows: 


MONITOR> MONITOR /NODE=ARTOS1 PROCESSES 
%MONITOR-I-ESTABCON, establishing connection to remote node(s)... 
%MONITOR-E-ERRSYSINFO, failed to collect system information on node ARTOS1 
-MONITOR-E-SRVMISMATCH, MONITOR server on remote node is an incompatible version 
%MONITOR-I-CONT, continuing....

You must install a remedial kit on OpenVMS Version 7.1 and Version 6.2 systems to communicate with Version 7.2 systems. The kit names are as follows:

4.11.1.2 Changes to MONITOR Recording File

V7.2

The MNR_DSK$B_ALLOCLS field in the MONITOR DISK class record has been changed from a byte-length field to a word-length field. The change was necessary to accommodate the disk port allocation class feature. In addition, all fields following MNR_DSK$B_ALLOCLS in the MONITOR DISK class record have been moved forward by one byte.

Because of this change, the Structure Level Identification field (MNR_HDR$T_IDENT) in the File Header Record has been changed from "MON30050" to "MON31050".

These changes are not reflected in Appendix A of the OpenVMS System Management Utilities Reference Manual: M--Z.

4.11.2 Documentation Changes and Corrections

See Section 4.11.1.2 for a change that is not reflected in the OpenVMS Version 7.2 OpenVMS System Management Utilities Reference Manual: M--Z.

4.12 Mount Utility

The following release notes pertain to mounting disks.

4.12.1 Problems and Restrictions

The following notes describe how to work around several MOUNT restrictions.

4.12.1.1 /MEDIA_FORMAT=COMPACTION Qualifier Ineffective on TA90 Devices

V7.2

The introduction of multiple tape density in OpenVMS Version 7.2 causes TA90 tape drives not to be properly placed in compaction mode when the standard DCL qualifier /MEDIA_FORMAT=COMPACTION is used in INITIALIZE, BACKUP, or MOUNT commands. The command and qualifier are accepted at the DCL level, but the device does not change modes.

To work around this problem, use the new qualifier /MEDIA_FORMAT=(DENSITY=3480,COMPACTION) to correctly place the device in compaction mode.

4.12.1.2 Mounting Write-Protected Disks in a Mixed-Version Cluster

V7.1--2

A fix that was made to MOUNT in OpenVMS Version 7.1--2 causes a minor incompatibility with earlier versions of MOUNT. This incompatibility occurs when disks that are write-protected (by either hardware or software write protection) are mounted on earlier versions of OpenVMS. In such cases, MOUNT returns the following error: 


%MOUNT-F-DIFVOLMNT, different volume already mounted on this device

To avoid this error, apply the appropriate one of the following MOUNT kits (or a superseding kit):

You can also use the following workaround to mount writable disks in a mixed-version cluster: 


$ DISMOUNT ddcu:        ! on any nodes that it can be mounted on 
$ MOUNT/WRITE ddcu: label   ! on the V7.1-2 node 
$ DISMOUNT ddcu:     ! on the V7.1-2 node 
$ MOUNT/CLUSTER/NOWRITE ddcu: label

By performing a MOUNT/WRITE operation, you allow the storage control block (SCB) of the device to be updated to be compatible with the MOUNT change. Once the SCB contains the new information, any version of MOUNT can properly use the device.

4.13 OPCOM

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

4.13.1 Corrections

V7.2

OpenVMS Version 7.2 contains corrections for the following OPCOM problems:

Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6534PRO_008.HTML