HP OpenVMS Systems Documentation

HP OpenVMS Alpha Version 7.3--2 Release Notes

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.12.3 Limit of 25 Elements on Stack

Permanent Restriction

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.13 LTDRIVER: CANCEL SELECTIVE Restriction

Permanent Restriction

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.14 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.15 POSIX Threads Library

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

Also see Section A.3 for a related note.

5.15.1 C Language Compilation Header File Changes

V7.3-2

The following changes have been made in OpenVMS Version 7.3-2:

• INTS.H
  In some prior releases of OpenVMS, the POSIX Threads C language header file PTHREAD_EXCEPTION.H inadvertently contained a #include of the C header file INTS.H. This has been corrected in OpenVMS Version 7.3-2. PTHREAD_EXCEPTION.H no longer causes INTS.H to be included in a compilation. There may be some applications whose compilation requires the presence of INTS.H and which are erroneously relying on PTHREAD_EXCEPTION.H to provide it.
  Recompiling such application source modules on an OpenVMS Version 7.3-2 system will result in diagnostic messages from the C compiler. These messages identify symbols or data types (for example, int32) that originate in INTS.H and are undefined. To correct such application source modules, add a direct #include of <ints.h> before the first use of the corresponding symbols or types.
• timespec_t typedef
  In prior releases of OpenVMS, the POSIX Threads C language header file PTHREAD.H contained a definition for a typedef named timespec_t . This is a nonstandard symbol, which does not belong in PTHREAD.H. (This typedef was present for historic reasons related to the contents of C RTL header files such as TIME.H and TIMERS.H.) For OpenVMS Version 7.3-2, the standards compliance of the C RTL and threads header files has been improved. As a result, PTHREAD.H no longer provides the timespec_t typedef.
  There may be some applications whose compilations require the timespec_t typedef, and which erroneously rely on PTHREAD.H to provide it---either directly or indirectly (for example, by using TIS.H). If such an application source module is recompiled on an OpenVMS Version 7.3-2 system, you may get C compiler diagnostic messages listing timespec_t as an unknown symbol or type. To correct such application source modules, either replace the uses of timespec_t with structure timespec , or include the C RTL header file TIMERS.H before the first use of the timespec_t symbol.
  If your application build environment uses a private copy of any older C RTL or threads header files or an extract of them that includes the timespec structure or the timespec_t typedef (both of which are not recommended), you may see an additional compilation error. The compiler may display messages stating that the timespec structure is redefined or defined twice. In such a case, revert to using the system-supplied C RTL and threads header files, or replace the private extracts involving the timespec structure with an inclusion of the system-supplied TIME.H header file.

V7.3-2

As of OpenVMS Version 7.3-2, the adaptive thread scheduling behavior that is described in the Guide to the POSIX Threads Library has been implemented with a new priority adjustment algorithm. In some cases, the new algorithm should help avoid problems that can arise when throughput-policy threads of different priorities share synchronization objects. Priority adjustment can also improve application throughput and overall system utilization. Priority adjustment of threads with throughput scheduling policy is automatic and transparent.

5.15.3 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.15.4 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.15.5 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.15.6 Debugger Metering Function Does Not Work

V7.0

The metering capability of the POSIX Threads debugger does not work.

If you use the procedure to debug a running program that is described in Section C.1.1 of the Guide to the POSIX Threads Library, your process could fail with an ACCVIO message.

5.16 Privileged Interfaces and Data Structures

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

5.16.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.16.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.17 RTL Library (LIB$)

The following notes pertain to LIB$FIND_IMAGE_SYMBOL.

5.17.1 LIB$FIND_IMAGE_SYMBOL: Error in the OpenVMS 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 revision of the OpenVMS RTL Library (LIB$) Manual.

5.17.2 LIB$FIND_IMAGE_SYMBOL Signals Warning

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.

5.18 Screen Management (SMG$) Documentation

The following information should be added to topics in the reference section at the end of the OpenVMS RTL Screen Management (SMG$) Manual:

V7.2

• The following statement should be added to the Condition Values Returned section of routine SMG$DELETE_VIRTUAL_DISPLAY:
  "Any condition value returned by the $DELPRC system service."
• The description of routine SMG$GET_TERM_DATA contains an error in the Arguments section for the capability-data argument. The correction is as follows:

  access:	write-only
  mechanism:	by reference, array reference

• The description of routine SMG$SET_OUT_OF_BAND_ASTS contains an error in the Arguments section for the AST-argument argument. The symbolic names in the Data Structure diagram are incorrect. The symbolic names in the paragraph under this diagram are correct. The correct and incorrect symbolic names are as follows:

  Incorrect	Correct
  SMG$L_PASTEBOARD_ID	SMG$L_PBD_ID
  SMG$L_ARG	SMG$L_USER_ARG
  SMG$B_CHARACTER	SMG$B_CHAR

V7.1

• In the documentation for the SMG$READ_COMPOSED_LINE routine, the following text should be appended to the description of the flags argument:
  "The terminal characteristic /LINE_EDITING should be set for your terminal for these flags to work as expected. /LINE_EDITING is the default."
• The description of routine SMG$SET_KEYPAD_MODE should contain this note:

  Note Changing the keypad mode changes the physical terminal setting. This is a global change for all virtual keyboards, not just the virtual keyboard specified by the keyboard-id argument.

The following release notes concern the SORT32 utility. Note that SORT32 is recommended as a workaround for unresolved problems with Hypersort and for functionality not implemented in Hypersort.

SORT32 has been updated to V07-006 for OpenVMS Alpha Version 7.3-2.

5.19.1 VFC Files Now Written Correctly

V7.3-2

The version of SORT32 that shipped with OpenVMS Alpha Versions 7.3 and 7.3-1 did not properly write VFC information to VFC output files when specification files were used. This problem has been corrected.

5.19.2 SORT32 May Not Delete Temporary Work Files

V7.3-2

SORT32 does not always delete temporary work files. It's a good idea to periodically check SYS$SCRATCH or wherever you put SORT32 work files to see if any undeleted work files can be deleted to free up disk space.

5.19.3 SORT/SPECIFICATION and Compound Conditions Restriction

V7.3-1

SORT32 does not issue a diagnostic for a compound condition in a key specification file not enclosed in parentheses, such as the following:

/Condition=(Name=Test1,
      TEST=(Field2 EQ "X") AND (Field3 EQ "A"))

That condition should instead be specified as:

/Condition=(Name=Test1,
      TEST=((Field2 EQ "X") AND (Field3 EQ "A")))

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 working set extent is at most one third of page file quota with either SORT32 or Hypersort.

5.19.5 SORT32 and Hypersort 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.19.6 SORT32 Work File Directories Restriction

V7.3

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

5.20 System Services: SYS$ACM(W) Changes

V7.3-2

The functional changes to SYS$ACM[W] described in this section are introduced in OpenVMS Version 7.3-2. In these descriptions, nonprivileged processes refer to processes running in user mode that do not have SECURITY privilege.

• Timeout processing
  Timeout processing is now enforced for nonprivileged processes. Other processes can request timeout processing by specifying the ACME$M_TIMEOUT function modifier.
• Dialogue mode iteration limit
  Nonprivileged processes are now limited in the number of iterative requests they can make in a dialogue sequence of calls.
• Logon type restriction
  The following ACME$_LOGON_TYPE item code values are reserved for use by LOGINOUT:

  ACME$K_BATCH
  Zero (0)

  
  You also no longer need IMPERSONATE privilege to specify the ACME$_LOGON_TYPE item code.

Refer to the SYS$ACM[W] system service description in HP OpenVMS System Services Reference Manual for more details.

5.21 Timer Queue Entries (TQEs)

V7.3-1

Management of Timer Queue Entries was redesigned for OpenVMS Alpha Version 7.3-1 to provide significantly higher performance for systems using many TQEs. This change is transparent to nonprivileged applications.

Privileged code can no longer manipulate TQEs directly in any form. In particular, directly accessing pointers in the TQE's queue header (TQE$L_TQFL/TQE$L_TQBL) causes an access violation in almost all cases. Privileged code may continue to use the internal routines exe_std$instimq/exe$instimq and exe_std$rmvtimq/exe$rmvtimq to enter or remove Timer Queue Entries.