Document revision date: 9 May 2001

V6.1

This version of OpenVMS VAX provides updated versions of the Mathematics Run-Time Library (RTL) images MTHRTL.EXE, UVMTHRTL.EXE, and VMTHRTL.EXE that contain new entry points in support of DEC Fortran Version 6.0. (UVMTHRTL.EXE is an alternate form of MTHRTL.EXE; references to MTHRTL.EXE in the following paragraphs also apply to UVMTHRTL.EXE.)

Due to the large number of entry points added to MTHRTL.EXE, that image's transfer vector was extended and its global section match identifier incremented. This means that images linked against the new version of MTHRTL.EXE will not run on a system running an earlier version of OpenVMS VAX, unless that system has also installed DEC Fortran Version 6.0. In addition, images linked against the new MTHRTL.EXE cannot be translated to run on OpenVMS Alpha using DECmigrate.

To link an image so that it will run on an earlier version of OpenVMS VAX, create a directory that contains saved copies of the .EXE and .OLB files from the SYS$LIBRARY directory of the earliest version you want to support, and define the logical name SYS$LIBRARY to point to that directory before linking. Because OpenVMS VAX also defines a system logical name MTHRTL to refer to either MTHRTL.EXE or UVMTHRTL.EXE, you must also define MTHRTL as a logical name in the process or job table to point to the copy in the directory of older images. For example:

$ DEFINE/USER SYS$LIBRARY disk:[OLD_SYSLIB] $ DEFINE/USER MTHRTL SYS$LIBRARY:MTHRTL.EXE $ LINK ...

Images to be translated using DECmigrate should be linked against the SYS$LIBRARY files of OpenVMS VAX Version 5.5-2 or earlier.

6.19 OpenVMS Registry (Alpha Only)

The release notes in this section pertain to the OpenVMS Registry.

For general release notes about the OpenVMS Registry, refer to the OpenVMS Connectivity Developer Guide, which is installed as part of the COM for OpenVMS installation process and available on the OpenVMS Documentation CD-ROM.

6.19.1 Registry Key Attribute Change Notifications Unsupported

V7.3

The $REGISTRY system service provides a function code, REG$FC_NOTIFY_CHANGE_KEY_VALUE, which you can specify to receive notification when changes are made to a key. Along with this function code, you specify the item code REG$_NOTIFYFILTER to pass or filter certain type changes to the key. This item code is a mask of the types of changes to pass. At this time, only the REG$M_CHANGENAME, REG$M_CHANGELASTSET, and REG$M_CHANGESECURITY mask bits have any effect on which notifications are passed or filtered. The REG$M_CHANGEATTRIBUTES mask bit is currently not supported.

For the most part, specifying the REG$M_CHANGENAME, REG$M_CHANGELASTSET, and REG$M_CHANGESECURITY mask bits is equivalent to specifying the REG$M_CHANGEATTRIBUTES mask bit. Any change that would be passed as a change to an attribute would also pass as either a name change, update of a key, or a security descriptor change.

We expect to support notification for attribute changes in a future version of OpenVMS.

6.19.2 Easing of Registry Data Transfer Size Restriction

V7.3

Previous versions of OpenVMS placed restrictions on the size of a data transfer between the $REGISTRY system service and the OpenVMS Registry server. The data transfer restrictions, in turn, placed restrictions on the maximum size of a single block of data that can be stored or retrieved from the Registry database. They also limited the depth of a REG$CP Search command, and placed limits on the number of Advanced Server domain groups of which a user can be a member. These restrictions have been eased in OpenVMS V7.3, but have not been eliminated entirely.

Previously the restrictions were approximately 8K bytes transmit (service to server) and approximately 4K bytes receive. The current restriction depends on the setting of the SYSGEN parameter MAXBUF. The range for MAXBUF is 4K to 64K, with a default of 8K.

MAXBUF is the maximum allowable size for any single buffered I/O packet. You should be aware that by changing MAXBUF you also affect other areas of the system that perform buffered I/O.

We expect to further ease this restriction in future versions of OpenVMS.

6.20 POSIX Threads Library

The following sections contain release notes pertaining to the Compaq POSIX Threads Library (formerly named DECthreads).

6.20.1 Process Dumps

V7.3

If the POSIX Threads Library detects an uncorrectable serious problem at run time (such as data structures that have been damaged by data corruption somewhere in the application), the library may terminate the running image. During termination, the library may trigger creation of a process dump file (which can subsequently be used to diagnose the failure, by way of ANALYZE/PROCESS_DUMP). The size of such a process dump file depends on the size of the process's address space at the time of the failure and can be quite large.

6.20.2 Dynamic CPU Configuration Changes

V7.3

Starting in OpenVMS Version 7.3, the POSIX Threads Library is sensitive to dynamic changes in the number of CPUs that are configured for a running multiprocessor Alpha system. When use of multiple kernel threads is enabled (by way of the LINK/THREADS_ENABLE qualifier or the THREADCP command verb) for an image, the POSIX Threads Library monitors the apparent parallelism of an application and creates multiple kernel threads up to the number of CPUs available. Each kernel thread can be scheduled by the OpenVMS executive to execute on a separate CPU and, therefore, can execute simultaneously.

While an application is running, an operator can stop or start a CPU. Such a dynamic change affects the allowable number of kernel threads that future image activations can create. It also will now affect images that are currently executing.

When a CPU is added or removed, the threads library will query for the new number of active CPUs, and compare this to the number of kernel threads that the process is currently using. If there are now more CPUs than kernel threads, the library will try to spread out the existing POSIX threads over the CPUs (creating new kernel threads as needed, now or in the future). If there are now fewer CPUs than kernel threads, the library will force the extra kernel threads to hibernate, and will reschedule the POSIX threads onto the remaining kernel threads. This will ensure that---so far as the process is concerned---there will not be more kernel threads competing for CPU resources than are available.

6.20.3 Enhanced Debugging of Threaded Programs

V7.3

The POSIX Threads Library provides enhanced data collection capabilities to support monitoring and debugging tools. These capabilities provide support for Visual Threads, a new debugging and analysis tool for threaded programs on OpenVMS Alpha systems. Visual Threads, which is licensed with OpenVMS Version 7.3, provides monitoring, automatic debugging, and performance evaluation of multithreaded applications. For more information about Visual Threads, see the OpenVMS Version 7.3 New Features and Documentation Overview.

6.20.4 POSIX 1003.4a Draft 4 Interface Retirement

V7.0

The POSIX 1003.4a, Draft 4 (or "d4") interface of the POSIX Threads Library is slated for retirement in a future release. Applications that were written using the POSIX 1003.4a, Draft 4 interface should be migrated to the new POSIX 1003.1c standard (or "pthread") interface provided by the POSIX Threads Library. A compatibility mode for the Draft 4 POSIX 1003.4a interface is provided in this release to help ease migration. This compatibility mode will be removed in a future release.

6.20.5 Setting of the MULTITHREAD SYSGEN Parameter on NUMA Systems

V7.3

When use of multiple kernel threads is enabled (by way of the LINK/THREADS_ENABLE qualifier or the THREADCP command verb) for an image, the POSIX Threads Library monitors the apparent parallelism of an application and creates multiple kernel threads up to the number of CPUs available. The OpenVMS Executive can schedule each kernel thread to execute on a separate CPU and, therefore, can execute simultaneously. The number of kernel threads that a single process can create may be further bounded by the value of the SYSGEN parameter MULTITHREAD.

In OpenVMS Version 7.3, when running on a Non-Uniform Memory Access (NUMA) platform (for example, GS160), all of the kernel threads created by the threads library are limited to execution on the CPUs that are located in the home Resource Affinity Domain (RAD) of the process. Typically, there are four CPUs in a RAD. When optimizing the performance of a threaded application, you may want to set the MULTITHREAD parameter to four or fewer to ensure that any one process creates no more than four kernel threads.

If a process creates more than four kernel threads, all of those kernel threads compete for the four (say) CPUs within the process's home RAD. At best, little or no gain would be realized, while in fact performance could decrease due to extra scheduling overhead.

6.20.6 POSIX Threads Library Debugger Metering Function

V7.0

The metering capability of the POSIX Threads Library debugger does not work in this release.

6.20.7 C Run-Time Library errno Value

V7.0

When errno is accessed from the OpenVMS Debugger, the value of the global errno (not the per-thread errno) is returned. (This is not a new condition; it just has not been documented previously.)

6.20.8 SET TASK/ACTIVE Command

V6.2

The OpenVMS Debugger command SET TASK/ACTIVE does not work either for the POSIX Threads Library (on both OpenVMS Alpha and VAX systems) or for Compaq Ada for OpenVMS Alpha systems, the tasking for which is implemented using the POSIX Threads Library.

Instead, you can use the following effective substitutes on the POSIX Threads Library:

• For query-type actions, use the SET TASK/VISIBLE command.
• To gain control to step through a particular thread, use strategic placement of breakpoints.

This section contains release notes concerning privileged code and data structures.

6.21.1 Per-Thread Security and Backward Compatibility

V7.2

The security information previously stored in several data structures has moved to a new Persona Security Block (PSB) data structure, making the relevant fields in those structures obsolete in OpenVMS Version 7.2. The affected structures include the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Process Control (CTL) region fields.

Table 6-1 shows the obsolete data cells and where the information in those cells has moved.

For single persona execution within a process, the obsolete data cells are maintained for backward compatibility. The cells are not maintained while a process is executing with multiple user-level personae (because any code checking the old cells would likely make the wrong security decision).

Backward compatibility of the obsolete data cells may not be maintained in future releases of OpenVMS. Writers of privileged code are encouraged to search for the obsolete symbols in their code and make the necessary modifications to remove the code's dependence on the obsolete cells, and to obtain the information from the new locations.

Table 6-1 Obsolete Data Cells and New Location of Security Information

Obsolete Data Cell	New Location
ARB$L_CLASS	PSB$AR_CLASS (Not supported 1)
ARB$L_RIGHTSLIST	PSB$AR_RIGHTS (Array of rights chains pointers) --- Persona, image, and system rights chains
ARB$L_UIC	PSB$L_UIC
ARB$Q_PRIV (Working privileges logically OR'd with image privileges)	PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV
CTL$GQ_PROCPRIV	PSB$Q_PERMPRIV
CTL$T_ACCOUNT	PSB$T_ACCOUNT
CTL$T_USERNAME	PSB$T_USERNAME
EXE$GL_RIGHTSLIST	EXE$AR_SYSTEM_RIGHTS (Rights chain pointer)
JIB$T_ACCOUNT 2	PSB$T_ACCOUNT
JIB$T_USERNAME 2	PSB$T_USERNAME
PCB$L_NOAUDIT	PSB$L_NOAUDIT
PCB$V_SECAUDIT	PSB$L_SECAUDIT
PHD$Q_AUTHPRIV	PSB$Q_AUTHPRIV
PHD$Q_IMAGPRIV	PSB$Q_IMAGE_WORKPRIV
PHD$Q_PRIVMSK	PSB$Q_WORKPRIV, PSB$Q_IMAGE_WORKPRIV --- Working privileges logically OR'd with image privileges (PSB)
PHD$R_MAX_CLASS	PSB$AR_CLASS (Not supported 1)
PHD$R_MIN_CLASS	PSB$AR_CLASS (Not supported 1)

V7.0

Privileged-code applications that were recompiled and relinked to run on OpenVMS Alpha Version 7.0 do not require source-code changes and do not have to be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and later.

Privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 that were not recompiled and relinked for OpenVMS Alpha Version 7.0 must be recompiled and relinked to run on OpenVMS Alpha Version 7.1 and later.

OpenVMS Alpha Version 7.0 included significant changes to OpenVMS Alpha privileged interfaces and data structures. As a result of these changes, privileged-code applications from releases prior to OpenVMS Alpha Version 7.0 may require source-code changes to run correctly on OpenVMS Alpha Version 7.0 and later. For more details about OpenVMS Alpha Version 7.0 changes that may require source changes to privileged-code applications, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

For information about recompiling and relinking device drivers, see Chapter 7.

6.21.3 Per-Thread Security Impacts Privileged Code and Device Drivers

V7.2

The method used for attaching a security profile to the I/O Request Packet (IRP) has changed.

In previous versions of OpenVMS, the address of the processwide Access Rights Block (ARB) security structure was copied directly into the IRP. Beginning with OpenVMS Alpha Version 7.2, the address of the new security profile structure (Persona Security Block, or PSB) of the thread making the I/O request is moved into the IRP.

The I/O subsystem maintains its access to the PSB through a reference counter. The I/O subsystem increments this reference counter at IRP creation and decrements the counter at I/O completion. When the counter reaches zero, the PSB is deleted from the system.

Device drivers that created copies of IRPs to facilitate multiple I/O operations per request, and subsequently pass the copied IRPs to the I/O subsystem for postprocessing, must make code changes to account for the extra references to the PSB that result. This is done by calling NSA_STD$REFERENCE_PSB and passing the PSB address located in the copied IRP before I/O postprocessing of the IRP copy. The include file and routine call for NSA_STD$REFERENCE_PSB is as follows:

#include <security-macros.h> /* Increment REFCNT of PSB that is now shared by both IRPs */ nsa_std$reference_psb( irp->irp$ar_psb );

Device drivers need to make this change under the following conditions:

• If a device driver creates a new IRP by duplicating an existing IRP and submits both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$SIMREQCOM or IOC_STD$DIRPOST1 the device driver must call NSA_STD$REFERENCE_PSB sometime after duplicating the IRP, but before submitting it for I/O postprocessing.
• If a device driver creates a new IRP by duplicating an existing IRP and does not put the address of some procedure descriptor into the IRP$L_PID cell in either the copy or the original IRP, and the device driver submits both the original and the duplicate IRPs for I/O postprocessing by calling IOC_STD$REQCOM, COM_STD$POST, COM_STD$POST_NOCNT, or IOC_STD$POST_IRP, the device driver must call NSA_STD$REFERENCE_PSB sometime after duplicating the IRP but before submitting it for I/O postprocessing.
  Device drivers that perform these steps are also likely to put the address of some procedure descriptor into IRP$L_PID. Therefore, most device drivers that duplicate IRPs should be able to function correctly on OpenVMS 7.2 without making source changes, relinking, or recompiling.

Failure to call NSA_STD$REFERENCE_PSB in these circumstances will result in corrupt tracking information within the PSB, which can result in system crashes.

If you make code changes in a device driver to call NSA_STD$REFERENCE_PSB, you must recompile and relink the driver to run on OpenVMS Version 7.3.

6.22 Record Management Services (RMS)

This section contains release notes pertaining to RMS.

6.22.1 Potential CONVERT-I-SEQ Error on CONVERT/NOSORT with Collated Key

V7.3

This potential change in behavior is restricted to a CONVERT command that specifies both the /NOSORT qualifier and a collated key type on one of the keys in the output file.

The /NOSORT qualifier on a convert command indicates that the primary key is already in sorted order in the input file and directs the convert utility not to sort it. Prior to OpenVMS Version 7.3, the convert utility had a defect that caused it to always sort the input file if some key specified for the output file had a collated key type regardless of whether /NOSORT was specified. As of OpenVMS Version 7.3, the convert utility has been fixed to appropriately obey the /NOSORT qualifier on the command line, even if one of the keys in the output file is a collated key.

This means that a convert operation that previously succeeded as a side-effect of the collated key defect may now produce %CONVERT-I-SEQ messages if the input file is not already in sorted order by the primary key and /NOSORT is specified on the command line. The /NOSORT qualifier should not be used if the input file is not already in sorted order by the primary key.

6.22.2 Circular Directory Path Detection (Alpha Only)

V7.2

Circular directory paths result when a SET FILE/ENTER command enters the directory name of a higher-level directory into a lower directory in its subdirectory tree. Prior to Version 7.2, such a directory tree appeared circular to RMS during ellipsis processing (for example, when processing a specification such as [A...]) because RMS did not detect that a directory's directory ID (DID) resulting from a SET FILE/ENTER command had already been encountered higher up in the path.

In earlier releases, an 8-deep directory limit inhibited RMS from looping while following a potentially infinite circle of DIDs. With the introduction of deep directories in OpenVMS Version 7.2, the 8-deep directory limit has been removed. In this release, RMS has been enhanced to detect when a node in the path initiates a circle. Instead of looping, RMS now treats such a node as if it were the lowest element in the current branch of the path.

6.22.3 Directory Cache Limits Removed

V7.2

During most wildcard searches, RMS caches the target directory file in memory to optimize calls to the file system. Prior to this release, the maximum size of a directory file that RMS would cache was 127 blocks; wildcard lookups to larger directories would go directly to the file system.

Beginning with Version 7.2, RMS attempts to cache directories of any size. If memory or other resources are not available to cache the file, wildcard lookups are then directed to the file system.

6.23 Run-Time Library (LIB$)---LIB$FIND_IMAGE_SYMBOL Signals Warning for Modules with Compilation Errors

V7.1

LIB$FIND_IMAGE_SYMBOL may signal a warning (LIB$_EOMWARN) to indicate that the image being activated contains modules that had compilation warnings. A condition handler used with LIB$FIND_IMAGE_SYMBOL should probably handle this as a special case.

To allow LIB$FIND_IMAGE_SYMBOL to continue execution after signaling LIB$_EOMWARN, the condition handler should exit with SS$_CONTINUE. For this reason, you may choose not to use LIB$SIG_TO_RET as a condition handler for LIB$FIND_IMAGE_SYMBOL.

	privacy and legal statement
6637PRO_009.HTML