Document revision date: 31 July 2002

V7.3-1

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. Specifically, any privileged code that runs for extended periods of time while holding a spinlock can cause a CPU spinwait bugcheck. Spinlocks are used to delineate the entry and exit points for critical sections, and should not be held continuously, as can occur in this situation.

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.

5.13 Hypersort Utility

V7.3-1

The following notes concern the Hypersort utility. Hypersort has been updated for OpenVMS Alpha Version 7.3-1. The new version of Hypersort is V04-003.

As always, continue to use SORT32 as a workaround for any unresolved problems with Hypersort or any functionality not implemented in Hypersort.

5.13.1 Hypersort and VFC Input Files

V7.3-1

Hypersort now properly handles /KEY for VFC input files. You must specify /FORMAT=(RECORD_SIZE:n) for Hypersort with VFC input files where n = longest record length + vfc fixed control area size.

5.13.2 Hypersort and /FORMAT=RECORD_SIZE---Restriction

V7.3-1

Hypersort supports /FORMAT=RECORD_SIZE:n for use with both SORT and MERGE, with the following two restrictions:

• In all cases, if the command-specified RECORD_SIZE is less than the longest record size (LRL) of any record in the input files, the records that are too long are truncated to the RECORD_SIZE size in the sorted output file and the diagnostic message %SORT-E-BAD_LRL is issued. In this situation, the output file should be discarded and the sort should be rerun. The RECORD_SIZE parameter for the SORT command should be revised to a value appropriate to the size of the largest record as shown in the listing of a DIR/FULL command for the input files.
• SORT and MERGE produce output sequential files from input indexed files. The %SORT-E-BAD_LRL diagnostic message can also be issued for this case.

V7.3

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

5.13.4 Hypersort and Large File Processing---Problems Corrected

V7.3-1

Hypersort provides support for high performance sorting of large files. Two problems have been corrected that previously resulted in incorrect offset computations, and an eventual hang or access violation (ACCVIO) in Hypersort.

5.13.5 Hypersort and /STATISTICS Overflow

V7.3-1

Hypersort now supports larger values for SORT/STATISTICS for working set extent and work file allocation. (This new support is in both SORT32 and Hypersort.)

5.13.6 Hypersort and the user_compare and user_equal Parameters

V7.3-1

Hypersort, unlike SORT32, does not support the feature of allowing an application caller to specify an address for the user_compare or user_equal parameters. It now correctly returns an NYI diagnostic if there is an attempt to do so.

5.13.7 Hypersort Internal Work File and User Output File Extensions---Problem Corrected

V7.3-1

Hypersort extends on-demand any work file or output file that it is writing. A problem in the extend logic that previously caused the sort to terminate prematurely has been identified and corrected.

5.13.8 Hypersort Compliance with the SORT32 File-Naming Convention---Problem Corrected

V7.3-1

Hypersort should comply with the SORT32 file-naming convention of cascading input file path attributes to form the output file name. A problem in the cascading logic has been found and corrected, resulting in improved compliance with SORT32.

5.13.9 Hypersort and Output File Attributes---Problem Corrected

V7.3-1

Hypersort should detect and set accurate output file attributes based on the input data being processed. A problem that previously caused an inaccurate MRS attribute has been corrected.

5.13.10 Hypersort and AST Quota---Problem Corrected

V7.3-1

Hypersort uses asynchronous QIO to process basic RMS file types. A problem that previously caused an AST quota depletion, and an eventual hang, has been corrected.

5.13.11 Hypersort and NULL Duplicate Records---Problem Corrected

V7.3-1

Hypersort allows for duplicate record processing. A problem that previously caused an unintentional filtering of NULL duplicate records has been corrected.

5.13.12 Hypersort and RMS-F-SYN---Problem Corrected

V7.3-1

Hypersort now properly issues the secondary diagnostic -RMS-F-SYN, file specification syntax error.

5.13.13 Hypersort with Search Lists and Other Uses of Logical Names---Restriction

V7.3-1

Hypersort does not fully support search lists and logical names used for input files and work files. SORT32 should be used when this is a problem.

5.13.14 Hypersort and Lack of Free Space for Work Files---Restriction

V7.3-1

Hypersort does not properly terminate if free space is exhausted in all available sort work files. To avoid this restriction, allocate sufficient free space for the devices used for sort work files; or use SORT32 to detect that work file space has been exhausted.

5.13.15 Hypersort and SORT32 Performance---Working Set and Page File Quota

V7.3-1

SORT32 and Hypersort use different sorting and work file algorithms. Either sort utility may be faster depending on the input file and the memory/disk/CPU configuration. Make sure that page file quota is at least three times working set extent with either SORT32 or Hypersort.

5.13.16 Hypersort and SORT32 Performance with Variable Length Records

V7.3-1

SORT32 and Hypersort allocate fixed sized slots for sort work files based on the longest record length (LRL) information in the file. To improve sort performance, try to set LRL information in the file as close as possible to the actual longest record length. Poor initial performance may be the result of sorting some files produced by C programs, because the LRL is set higher than needed (to 32767).

5.13.17 Hypersort Work File Directories---Restriction

V7.3

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.

5.14 Librarian Utility---PGFLQUOTA Exceeding 23000 Needed

V1.5

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.

5.15 Linker Utility

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

5.15.1 Change in Linker Default Behavior with Library Check

V7.3-1

Previously, the linker's check between the library and the shareable image was too sensitive. It compared against the exact date and time, signaling LINK-I-DATMISMCH, if no match was found. Now, however, it makes only the same check that the image activator does: that is, it uses the GSMATCH criteria to verify compatibility.

The old behavior (check for date and time) can be obtained by setting the logical name LINK$SHR_DATE_CHECK.

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

V7.2

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.

5.16 LTDRIVER---CANCEL SELECTIVE Restriction

V6.1

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---such as a LAT connect $QIO) cannot be canceled with CANCEL SELECTIVE.

5.17 Mail Utility---Threads Restriction for Callable Mail

V7.1

OpenVMS callable mail routines are not thread-safe. Refer to the Guide to the 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.

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

V7.3-1

OpenVMS VAX Version 6.1 updated the Mathematics Run-Time Library (RTL) images MTHRTL.EXE, UVMTHRTL.EXE, and VMTHRTL.EXE to 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.)

Because of 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 this version of MTHRTL.EXE will not run on a system running a version of OpenVMS VAX prior to Version 6.1, 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.

5.19 POSIX Threads Library

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

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

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

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

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

5.19.5 Multiple RAD Support on NUMA Systems

V7.3-1

Starting in OpenVMS Version 7.3-1, the Compaq POSIX Threads Library can utilize the CPUs in all Resource Affinity Domains (RADs) to execute the threads within a single process. Previously, thread execution was essentially limited to the CPUs within the process's home RAD. Now, when the application work load justifies it, the threads library can create and use kernel threads running on CPUs within additional RADs to execute the application's POSIX threads. One multithreaded process can now utilize all CPUs within a NUMA system.

5.20 Privileged Interfaces and Data Structures

This section contains a release note concerning privileged code and data structures.

5.20.1 Per-Thread Security Impacts Privileged Code and Device Drivers

V7.3-1

The method used for attaching a security profile to an I/O Request Packet (IRP) changed with Version 7.2.

In versions of OpenVMS prior to Version 7.2, the IRP structure contained the address of the processwide Access Rights Block (ARB) security structure of the requestor. Beginning with OpenVMS Alpha Version 7.2, the address of the new security profile structure (Persona Security Block, or PSB) was added to the IRP as a functional replacement of the ARB address.

The I/O subsystem maintains its access to the PSB through a reference counter within the PSB. The I/O subsystem increments this reference counter at the time of IRP creation and decrements the counter at I/O postprocessing of that IRP. When this counter reaches zero, the PSB structure is deallocated.

Device drivers that create or clone copies of IRPs to facilitate multiple I/O operations per request, and subsequently pass the copies to the I/O subsystem for postprocessing, must make code changes to account for the extra references to the PSB in these additional IRPs. This is done by passing the PSB address located in the copied IRP to the NSA_STD$REFERENCE_PSB routine. 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 Version 7.2 or higher 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 failures.

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.2 or higher.

5.20.2 IPL Requirement For OpenVMS Fork Thread Creation Now Enforced

V7.3-1

Several routines are used by privileged code to create OpenVMS fork execution threads. These routines run in system context independent of any process. There are four variations of these routines, depending on whether an immediate or queued fork is required and on which language interface is being used:

• EXE$QUEUE_FORK
• EXE_STD$QUEUE_FORK
• EXE$PRIMITIVE_FORK
• EXE_STD$PRIMITIVE_FORK

These routines must be called at or above IPL$_RESCHED, to prevent accidental rescheduling to a different CPU during their execution. Such a reschedule could cause the system to hang.

In OpenVMS V7.3-1, if SYSTEM_CHECK is set to 1, these routines check the system IPL at entry. If the IPL is below IPL$_RESCHED, the system will fail with an SPLINVIPL bugcheck.

For performance reasons, the IPL is not verified if SYSTEM_CHECK is set to zero (the default). Incorrect code may cause the system to hang if a reschedule to another CPU occurs during execution of these routines from process context (for example, below IPL$_RESCHED).

5.21 Record Management Services (RMS)

This section contains a release note pertaining to RMS.

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

5.22 LIB$FIND_IMAGE_SYMBOL---Error in the RTL Library (LIB$) Manual

V7.3-1

In the OpenVMS RTL Library (LIB$) Manual, there is an error in the description of the flags argument to LIB$FIND_IMAGE_SYMBOL. Flags is documented as passed by reference. This is incorrect and returns an error message, LIB-F-INVARG, as a return value. If flags is passed by value, LIB$FIND_IMAGE_SYMBOL works as expected.

This error will be corrected in the next release of the OpenVMS RTL Library (LIB$) Manual.

	privacy and legal statement
6652PRO_009.HTML