HP OpenVMS Systems Documentation

Content starts here

OpenVMS Version 7.3 Release Notes

Previous Contents Index

6.9.22 Source View Errors


Previous versions of the debugger had problems within the source view of the DECwindows Motif interface, including the following:

  • Breakpoints set on routines through the source browser sometimes failed to toggle on and off.
  • The source view was unstable whenever the code was scrolled when used with DECwindows Motif Version 1.2-5.
  • Debugger errors occurred when the user was scrolling source code after the RUN command and before the first GO command.

These problems have been corrected.

6.9.23 Source View Update


In previous versions, the DECwindows Motif interface to the debugger did not correctly update the source view on a return step command from a subroutine call when the calling routine was in a different source module. This problem has been corrected.

6.9.24 SHOW SYMBOL IN Clause


The ability of the debugger to set modules dynamically has been improved.

6.9.25 Corrupted Stack Errors (Alpha Only)


On Alpha systems, some recent compilers introduce certain stack errors. If previous versions of the debugger encounter these errors while program execution is suspended at a breakpoint, a STEP or other resume command can result in the following error:

%DEBUG-W-NORESUME, unable to resume execution, stack or PC corrupted.

This problem has been corrected, and you should upgrade the compiler that causes the corrupt stack.

6.9.26 Just-in-Time Debugging


When attempting just-in-time debugging (for example, when DBG$TRACE is defined as SYS$SHARE:DEBUG.EXE), previous versions of the debugger sometimes fail. This has been corrected.

6.9.27 Debugger Does Not Support Previous Version of Client/Server Interface


The OpenVMS Version 7.3 debugger does not support previous versions of the client/server interface. You must install the client/server interface found in the kit on the distribution media, as identified in the following table:

CPU Operating System Client Kit
Intel Microsoft Windows 95, 98 [DEBUG_CLIENTS011.KIT]DEBUGX86011.EXE
Intel Microsoft Windows NT, 2000 [DEBUG_CLIENTS011.KIT]DEBUGX86011.EXE
Alpha Microsoft Windows NT [DEBUG_CLIENTS011.KIT]DEBUGALPHA011.EXE

These client kits are self-extracting .EXE files.

Once the appropriate executable file has been transferred to the PC, you can run the file to install the debug client on the PC. The InstallShield installation procedure guides you through the installation.

By default, the debug client is installed in the \Program Files\OpenVMS Debugger folder. You can also click Browse to select an alternate location.

6.10 Debugging Modes---Avoiding CPUSPINWAIT Bugchecks


The OpenVMS operating system has a number of special modes of operation designed to help you debug complex hardware and software problems. In general terms, these special modes enable an extra level of tracing, data recording, and consistency checking that is useful in identifying a failing hardware or software component. These modes of operation are controlled by several system parameters: MULTIPROCESSING, POOLCHECK, BUGCHECKFATAL, and SYSTEM_CHECK.

If you are using one of these special modes (for example, to debug a device driver or other complex application), under certain conditions, generally related to high I/O loads, it is possible to incur a CPUSPINWAIT bugcheck. To prevent a CPUSPINWAIT bugcheck, either use the system default settings for these system parameters, or reduce the loading of the system.

If you have reason to change the default settings, you can reduce the likelihood of encountering a problem by setting the SMP_LNGSPINWAIT system parameter to a value of 9000000.

6.11 Hypersort (SORT/MERGE/CONVERT)---Alpha Only

The following sections contain release notes pertaining to restrictions and known problems in the use of the High-Performance Sort/Merge utility, Hypersort. These restrictions and known problems supplement the material in the OpenVMS Utility Routines Manual.

Hypersort (HYPERSORT.EXE) can optionally be selected for use by SORT, MERGE, CONVERT, Compaq COBOL, and Oracle Rdb. Use SORT32 as a work-around for problems or restrictions in Hypersort, unless the problem or restriction also exists in SORT32.

6.11.1 Hypersort and /FORMAT=RECORD_SIZE - Restriction


Hypersort does not support /FORMAT=RECORD_SIZE for use with SORT or MERGE.

6.11.2 Hypersort and Input Asterisk (*)---Restriction


Hypersort does not support asterisk (*) as an input file specification.

6.11.3 Hypersort and Free Disk Space for Work Files---Restriction


Hypersort does not support work-file specifications that result in insufficient free disk space to complete the sort or merge operation.

6.11.4 Hypersort Work File Directories---Restriction


Hypersort work files must be redirected to directories that allow multiple-file versions that can handle the number of requested work files. This restriction also exists in SORT32.

6.11.5 Hypersort and VFC Files---Known Problem


Hypersort does not correctly calculate the byte offset for keys for VFC Format files.

6.11.6 Hypersort and /STATISTICS Working-Set Display---Known Problem


Hypersort overflows the working-set display in the /STATISTICS output for any working set that is 1,000,000 pages or larger. This is also a known problem with SORT32.

6.11.7 Hypersort and INSVIRMEM---Restriction


Both SORT32 and Hypersort depend on the proper relationship between working-set size and page-file quota to avoid insufficient virtual memory. In general, page-file quota may need to be three times the working-set size or even larger to avoid insufficient virtual memory.

If insufficient virtual memory is detected, SORT32 signals INSVIRMEM and attempts to complete the sort. Hypersort terminates in this situation with INSVIRMEM or possibly ACCVIO.

6.12 Lexical Functions---F$GETSYI Lexical: Item NODE_HWTYPE Is Obsolete


The NODE_HWTYPE item is obsolete. Please use the HW_NAME item instead.

The NODE_HWTYPE item has not been removed; therefore, programs using this item will still work. However, Compaq recommends that you migrate such programs to use the HW_NAME item whenever possible to take advantage of new capabilities.

On OpenVMS VAX systems, applications using NODE_HWTYPE receive cryptic, 4-character, system model names for all VAX systems and receive the string ALPH for all Alpha systems. In contrast, the HW_NAME item operates on both OpenVMS VAX and OpenVMS Alpha systems, and provides longer, more descriptive names to be returned. For example, HW_NAME returns "VAXstation II," whereas NODE_HWTYPE returns "VUV2" for the same system.

6.13 Librarian Utility---PGFLQUOTA Should Exceed 23000 (Alpha Only)


The OpenVMS Alpha LIBRARIAN sometimes does not inform you of errors during compression, data reduction, or data expansion operations. This problem occurs if the account or process in which the LIBRARIAN is running has a low PGFLQUOTA process quota. Operation failure is not readily apparent because the $PUTMSG system service always returns a status of SS$_NORMAL, even when the system service fails. However, when a failure occurs, the LIBRARIAN returns a status other than Success.

To work around this problem, run the compression, data reduction, or data expansion operation in an account with a PGFLQUOTA process quota greater than 23000. In addition, ensure that your command procedures check the return status from the LIBRARY command.

6.14 Linker Utility

The following sections describes release notes pertaining to the Linker Utility.

6.14.1 Problem with Linker Utility---Omits Solitary Attribute


The Linker utility shipped with OpenVMS Alpha Version 7.3 omits the solitary attribute specified in an option file, causing solitary program sections not to be solitary. The resulting image may be corrupted. No error message is displayed during the link operation.

The following TIMA kit addresses this problem:


This kit will be available at the end of June 2001, from the following location:

6.14.2 Linker Utility---Limit of 25 Elements on Stack


Developers who are creating object files should be aware that the linker's internal stack is guaranteed for only 25 elements. Any calculations must be done within this constraint.



In releases prior to OpenVMS Version 6.1, LTDRIVER did not set the "extended DDT" bit; therefore, the POSIX function CANCEL SELECTIVE did not work with LTDRIVER. This problem has been corrected, but a restriction remains.

Although this fix allows $QIO reads and writes to be selectively canceled, any $QIO done to the port driver (that is, with the IO$_TTY_PORT function modifier---like a LAT connect $QIO) cannot be canceled with CANCEL SELECTIVE.

6.16 MACRO--32 Compiler for OpenVMS Alpha (Alpha Only)

See Chapter 8 for a number of notes that concern the MACRO--32 compiler.

6.17 Mail Utility---Threads Restriction for Callable Mail


OpenVMS callable mail routines are not thread-safe. Refer to the Guide to POSIX Threads Library for more information about calling non-thread-safe routines within a threaded application.

Because callable mail context information is maintained on a per-process (rather than a per-thread) basis, multiple threads performing context-based processing must be synchronized so that only one mail context of a given type is active at once. Otherwise, one thread could corrupt another thread's mail operations.

On OpenVMS Alpha systems, there is an additional restriction when kernel threads is enabled in a multithreaded environment. In this environment, callable mail should be used only in the initial thread.

6.18 Mathematics (MTH$) Run-Time Library---Linking Images


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:

$ 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


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


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


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


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


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


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


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


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

6.20.7 C Run-Time Library errno Value


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


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.

6.21 Privileged Interfaces and Data Structures (Alpha Only)

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

6.21.1 Per-Thread Security and Backward Compatibility


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


Security information within the JIB (JIB$T_ACCOUNT, the account cell) is not backward compatible because the JIB is shared among all processes in a job tree. Modifying the JIB user-name cell (JIB$T_USERNAME) in a multiprocess job tree can adversely affect other processes in that job tree.


A process is created with a single user-mode security profile known as the natural persona. Backward compatibility based on the current value of the new SYSGEN parameter ARB_SUPPORT, which defines the level of backward compatibility between the obsolete cells and the new PSB data structure, is maintained while the process remains in this user-mode persona state. (See the OpenVMS System Management Utilities Reference Manual for information about the ARB_SUPPORT parameter.)

Backward compatibility is not supported when multiple user-mode personae exist. Multiple user-mode personae are created using the $PERSONA_CREATE system service.

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$Q_PRIV (Working privileges logically OR'd with image privileges) PSB$Q_WORKPRIV, 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)

1OpenVMS Version 7.2 does not maintain the structures to support MAC (mandatory access checking) in a level B1 security environment.
2Security information within this cell is not backward compatible because the JIB is shared among all processes in a job tree.

Previous Next Contents Index