HP OpenVMS Systems Documentation
HP OpenVMS Version 8.4 Release Notes
5.35 PL/I Libraries Not Included in OpenVMS Integrity servers Version 8.2
The PL/I libraries (native and translated) are not included in OpenVMS Integrity servers as they are in OpenVMS Alpha. The core PL/I images that are not available in OpenVMS Integrity servers are:
Applications and shareable images that reference the PL/I library do not work on OpenVMS Integrity servers. (Typically these are applications and shareable images that contain code written in PL/I.) This restriction applies to both native code and translated VAX and Alpha images.
The following sections contain release notes pertaining to the POSIX
Threads Library (formerly named DECthreads).
The POSIX Threads Library on OpenVMS Alpha and Integrity servers supports process-shared mutexes and condition variables.
The supported pthread routines on OpenVMS are:
5.36.2 New Return Status for pthread_mutex_lock
The POSIX Threads library pthread_mutex_lock when used with
process-shared mutexes now returns a new error status known as
EABANDONED. This status is returned only when the process has
terminated while owning the mutex.
The POSIX Threads library supports a new API called pthread_mutex_tryforcedlock_np. The pthread_mutex_tryforcedlock_np API takes the ownership of abandoned process-shared mutexes.
With process-shared objects, the objects such as mutexes and condition variables can be shared among multiple processes. If a process terminates while owning a mutex, the mutex will be owned by the terminated process. Hence, none of the other threads or processes can own that mutex.
However, there is an optional system service sys$pshared_register . Usage of this system service makes the terminating process mark the mutexes that are owned by it as abandoned.
In such a scenario, the call to pthread_mutex_lock would return EABANDONED and the application could call pthread_mutex_tryforcedlock_np to get the ownership of the abandoned mutex.
If an error condition occurs, this routine returns an integer value indicating the type of error. The possible return values can be:
5.36.4 Stack Overflows During Exception Handling (Integrity servers Only)
Exception handling on Integrity servers requires considerably more stack space than it does on Alpha. When porting an application from OpenVMS Alpha, if a thread that uses exception handling does not have a generous amount of unused stack space, the thread might experience a stack overflow during exception handling on Integrity servers. Usually this appears as an improperly handled ACCVIO that is associated with one of the following operations:
If you see such a problem, increase the size of the stack allocated for the thread by a small number of pages. HP recommends initially increasing the stack by 24 KB.
The default stack size has been increased by 24KB to try to address the
increased stack usage on Integrity servers. If your application creates
a large number of threads (using the default size), the application
might run out of memory resources. If this happens, you might have to
increase process quotas or make application changes to reduce the
number of threads that exist simultaneously.
The DCL command THREADCP cannot be used on OpenVMS Integrity servers to query and change the two threads-related main image header flags, UPCALLS and MULTIPLE_KERNEL_THREADS. Instead, you must use the DCL commands SET IMAGE and SHOW IMAGE to set and show threads header flags on Integrity servers.
Alpha users should continue to use the THREADCP command.
Any source modules that call either of the following two old cma threads library routines must be compiled for use on OpenVMS Integrity servers with the /FLOAT=G_FLOAT compiler qualifier (or language-specific equivalent).
These routines accept only VAX-format floating-point values as
arguments. Normally, OpenVMS Integrity servers compilers default to
using the IEEE formats for floating-point values --- unlike OpenVMS
Alpha compilers, which default to using VAX formats. These two cma
threads routines accept only floating-point arguments in VAX format on
both Alpha and Integrity servers. Failure to properly compile any calls
to these routines might result in unexpected exceptions being raised
when the IEEE format floating-point values are erroneously passed at
The following changes have been made in OpenVMS Version 7.3-2:
5.36.8 New Priority Adjustment Algorithm
Starting with 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.
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.
Starting with 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 affects 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
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.
The OpenVMS Version 8.2 help file for the LIB$ run-time library is
missing help for the LIB$LOCK_IMAGE routine. The help file will be
corrected in a future release. Meanwhile, refer to the HP OpenVMS RTL Library (LIB$) Manual
for a complete description of this routine.
This release note clarifies how rotating registers are handled by the following calling standard routines:
The Calling Standard invocation context block (ICB) and mechanism vector always record general, floating-point, and predicate registers as if the register rename base (CFM.rrb) and rotating size (CFM.sor) were both zero. In other words, when rotating registers are in use, the effects of the rotation are ignored. This is also true of the register masks used by the LIB$I64_PUT_INVO_REGISTERS routine, because these masks are defined in terms of fields in the ICB structure.
Currently, the supplemental access routines LIB$I64_GET_FR, LIB$I64_SET_FR, LIB$I64_GET_GR, and LIB$I64_SET_GR improperly interpret their register number parameters without applying an adjustment for the effects of the register rename base and rotating size registers. This is an error and will be corrected in a future release.
In the meantime, any code that examines the general, floating-point and
predicate registers in an ICB or mechanism vector and that seeks to
interpret the register contents as it would be seen by the code during
its execution must examine the saved CFM register and apply the
appropriate adjustments itself.
The following information should be added to topics in the reference section at the end of the OpenVMS RTL Screen Management (SMG$) Manual:
5.39 SORT32 Utility
SORT32 is recommended as a workaround for unresolved problems with
Hypersort and for functionality not implemented in Hypersort. Release
notes for Hypersort are in Section 5.27.
The SORT, MERGE, and CONVERT operations with output directed to a UNIX-served, DFS-mounted disk return a %SORT-E-BAD_LRL error.
To work around this restriction, do one of the following:
5.39.2 Temporary Work Files Not Always Deleted
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 whether any undeleted work files can be deleted to free up disk
SORT32 does not issue a diagnostic message for a compound condition in a key specification file unless it is enclosed in parentheses. For example:
5.39.4 Performance Problem with Variable Length Records
SORT32 allocates fixed-sized slots for sort work files based on the
longest record length (LRL) information in the input files. To improve
performance, try to set LRL information in the input files as close as
possible to the actual longest record length. Poor initial performance
might be the result of sorting some files produced by C programs,
because the LRL is set higher than necessary (up to 32767).
SORT32 work files must be redirected to directories that allow multiple
file versions that can handle the number of requested work files.
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.
The Watchpoint Utility has not been ported to OpenVMS Integrity
servers. HP intends to port this utility in a future release.
On OpenVMS Alpha, the floating-point rounding behavior, exception behavior, and precision control are defined at compile time; each module is independently compiled with its own set of floating-point behaviors. For example, one module can be compiled with a directive that causes overflow calculations to signal an overflow exception, and another module can be compiled with a directive that causes overflow calculations to compute the value InfinityT rather than to signal an exception. When these two modules are combined and run, the code in the modules performs overflow calculations that were specified at compile time.
On OpenVMS Integrity servers, the floating-point rounding behavior, exception behavior, and precision control are defined at run time and are guided by the concept of whole program floating-point mode. With whole program floating-point mode, the module that contains the program main entry point (as determined by the Linker) is the module that defines the default floating-point rounding behavior, exception behavior, and precision control.
Most programs are not affected by this difference. Refer to the white paper "OpenVMS Floating-Point Arithmetic on the Intel® Itanium® Architecture" for essential reading. You can link to this document from the following web site: