Document revision date: 19 July 1999

The following sections contain release notes pertaining to DECthreads.

5.7.1 Changes and Enhancements

This section summarizes some significant changes and enhancements made to DECthreads. For detailed information about using DECthreads, refer to the Guide to DECthreads.

5.7.1.1 Thread Stack Size

V7.2

Prior to OpenVMS Version 7.2, when an application requested to allocate a thread stack of a specific, absolute size, DECthreads would increase the size by a certain quantity, then round up that sum to an integral number of pages. This process resulted in the actual stack size being considerably larger than the caller's request, possibly by more than one page.

Starting with OpenVMS Version 7.2, when an application requests DECthreads to allocate a thread stack of a specific, absolute size, no additional space is added, but the allocation is still rounded up to an integral number of pages.

Any application that uses default-sized stacks is unlikely to experience problems due to this change. Similarly, any application that sets its thread stack allocations in terms of either the DECthreads default or the allowable minimum stack size is unlikely to experience problems due to this change; however, depending on the allocation calculation used, the application might receive more memory for thread stacks.

Starting with OpenVMS Version 7.2, any thread that is created with a stack allocation of a specific, absolute size might fail during execution because of insufficient stack space. This failure indicates an existing bug in the application that was exposed by the change in DECthreads.

When the application requests to allocate a thread stack of a specific size, it must allow for not only the space that the application itself requires, but also sufficient stack space for context switches and other DECthreads activity. DECthreads only occasionally uses this additional stack space, such as during timeslice interruptions. A thread with inadequate stack space might encounter no problems during development and testing because of timing vagaries --- for instance, a thread might not experience problems until a timeslice occurs while the thread is at its maximum stack utilization --- and this situation might never arise during in-house testing. In a different system environment, such as in a production environment, the timing might be different, possibly resulting in occasional failures when certain conditions are met.

With OpenVMS Version 7.2, DECthreads has increased the default thread stack size for both OpenVMS Alpha and OpenVMS VAX. Applications that create threads using the default stack size (or a size calculated from the default) will be unaffected by this change.

As of OpenVMS Version 7.2, DECthreads has increased the minimum thread stack size (based on the PTHREAD_STACK_MIN constant) for OpenVMS VAX only. Applications that base their thread stack sizes on this minimum must be recompiled.

5.7.1.2 Static Initialization Inappropriate for Stack-Based Synchronization Objects

V7.2

Although it is acceptable to the compiler, it is inappropriate to use the following macros to initialize DECthreads synchronization objects that are allocated on the stack:

• PTHREAD_MUTEX_INITIALIZER
• PTHREAD_COND_INITIALIZER
• PTHREAD_RWLOCK_INITIALIZER

Each thread synchronization object is intended to be shared among the program's threads. If such an object is allocated on the stack, its address can asynchronously become invalid when the thread returns or otherwise terminates. For this reason, Compaq does not recommend allocating any thread synchronization object on the stack.

As of OpenVMS Version 7.2, DECthreads detects some cases of misuse of static initialization of automatically allocated (stack-based) thread synchronization objects. For instance, if the thread on whose stack a statically initialized mutex is allocated attempts to access it, the operation fails and returns EINVAL. If the application does not check status returns from DECthreads routines, this failure can remain unidentified, and (if the operation was "lock mutex") the program can encounter a thread synchronization failure, which in turn can result in unexpected program behavior including memory corruption. (For performance reasons, DECthreads does not currently detect this error when the mutex is accessed by a thread other than the one on whose stack the object was automatically allocated.)

If your application must allocate a thread synchronization object on the stack, the application must initialize the object before it is used by calling one of the routines pthread_mutex_init(), pthread_cond_init(), or pthread_rwlock_init(), as appropriate for the object. Your application must also destroy the thread synchronization object before it goes out of scope (for instance, due to the routine's returning control or raising an exception) by calling one of the routines pthread_mutex_destroy(), pthread_cond_destroy(), or pthread_rwlock_destroy(), as appropriate for the object.

5.7.1.3 POSIX 1003.4a Draft 4 Interface Retirement

V7.0

The POSIX 1003.4a, Draft 4 (or "d4") interface of DECthreads 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 DECthreads. 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.7.2 Problems and Restrictions

This section describes known DECthreads problems and restrictions.

5.7.2.1 Incorrect Success Exit Status Values Returned

V7.2

OpenVMS Version 7.2 contains a DECthreads regression that causes a process or image exit to incorrectly return a success exit status value under either of the following conditions:

• A thread explicitly invokes the $EXIT system service or the C RTL exit() function.
• The initial thread terminates by returning an error status value from the program's main function.

For example, this regression causes the DEC Ada Compilation System (ACS) to always return SS$_NORMAL, whether or not errors are encountered in the compilation or linking. This regression will be corrected in a remedial kit.

5.7.2.2 Language Support

V7.0

This release does not include interface definitions for non-C languages for the POSIX 1003.1c standard-style interface to DECthreads. All DECthreads routines are usable from non-C languages; however, the application must provide the routine declarations. These self-defined declarations should be modeled after the C language declarations in pthread.h.

5.7.2.3 DECthreads Debugger Metering Function

V7.0

The metering capability of the DECthreads debugger does not work in this release.

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

5.7.2.5 SET TASK/ACTIVE Command

V6.2

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

Instead, you can use the following effective substitutes on DECthreads:

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

The following sections contain release notes pertaining to DECTPU for DECwindows Motif.

5.8.1 Problems and Restrictions

This section describes DECTPU for DECwindows Motif problems and restrictions.

5.8.1.1 Small Display Monitors and DECwindows Motif Applications

V6.0

When running DECwindows Motif DECTPU on small display monitors, the main window can be less than fully visible.

To correct this condition, follow these steps:

1. Add the following resources to your DECTPU X resource file:

   Tpu.Tpu$MainWindow.X: 0 Tpu.Tpu$MainWindow.Y: 0 Tpu.Tpu$Mainwindow.Rows: 21 Tpu*condensedFont: on Tpu*fontSetSelection: 1

2. Copy the resource file from SYS$LIBRARY:EVE.DAT and add the previous lines.
3. Use logical name TPU$DEFAULTS to point at the new resource file.
   The following example invokes the EVE DECwindows Motif user interface using the X resource file named eve_small_window.dat in your login directory to edit the file LOGIN.COM.

   $ DEFINE TPU$DEFAULTS SYS$LOGIN:EVE_SMALL_WINDOW.DAT $ EDIT/TPU/INTER=DECWINDOWS LOGIN.COM

For programming release notes pertaining to the callable interface (SOR routines) of the OpenVMS Alpha high-performance Sort/Merge utility, see Section 3.4.

For information about using the OpenVMS Alpha high-performance Sort/Merge utility, refer to the OpenVMS Utility Routines Manual and the OpenVMS User's Manual.

5.10 Lexical Functions

This section contains a release note pertaining to a lexical function.

5.10.1 Changes and Enhancements

The following note describes an obsolete item that has been replaced.

5.10.1.1 F$GETSYI Lexical: Item NODE_HWTYPE Is Obsolete

V7.2

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.

5.11 Librarian Utility

The following sections contain release notes pertaining to the Librarian utility (LIBRARIAN).

5.11.1 Problems and Restrictions

This section describes known LIBRARIAN problems and restrictions.

5.11.1.1 PGFLQUOTA Should Exceed 23000 (Alpha Only)

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.12 Linker Utility

The following sections contain release notes pertaining to the OpenVMS Linker utility (linker).

5.12.1 Problems and Restrictions

This section describes a linker restriction.

5.12.1.1 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.12.2 Documentation Changes and Corrections

This section describes a correction to the linker documentation.

5.12.2.1 OpenVMS Linker Utility Manual

V7.2

In Appendix A, the TRANSFER FLAGS field of the end-of-module record is incorrectly listed as EOM$L_TFRFLG. This field is a byte, not a longword; therefore, the correct name of the field is EOM$B_TFRFLG.

5.13 LTDRIVER

The following sections contain release notes pertaining to the LTDRIVER.

5.13.1 Problems and Restrictions

This section describes known LTDRIVER problems and restrictions.

5.13.1.1 CANCEL SELECTIVE Cannot Cancel IO$_TTY_PORT Functions

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 has been fixed, 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.

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

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

5.15 Mail Utility

This section contains release notes about the Mail utility that are of interest to programmers.

5.15.1 Problems and Restrictions

The following note describes a restriction for callable mail.

5.15.1.1 Threads Restriction for Callable Mail

V7.1

OpenVMS callable mail routines are not thread-safe. Refer to the Guide to DECthreads for more information about calling nonthread-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.16 Mathematics (MTH$) Run-Time Library

The following sections contain release notes pertaining to the Run-Time Mathematics Library (MTH$).

5.16.1 Problems and Restrictions

This section describes known MTH$ problems and restrictions.

5.16.1.1 Linking Images to Run on Previous OpenVMS VAX Versions (VAX Only)

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.

5.17 OpenVMS Registry (Alpha Only)

For release notes about the OpenVMS Registry, refer to the OpenVMS Connectivity Developer's Guide, which is installed as part of the COM for OpenVMS installation process. That document is available in PostScript, HTML, and PDF formats.

OpenVMS Connectivity Developer's Guide is also available from the OpenVMS website at the following location:

The release notes in this section pertain to the POLYCENTER Software Installation utility. Also see Section 4.16 for notes about this utility that are of interest to system managers.

5.18.1 Problems and Restrictions

This section describes a known problem with using the POLYCENTER Software Installation utility to create software kits. Problems and restrictions of interest to system managers are described in Section 4.16.2.

5.18.1.1 Generation Option of File Statement

V7.1

The generation option of the file statement does not work correctly on product removal.

For example, the product description files for products TEST1 and TEST2 are as follows:

product DEC VAXVMS TEST1 V1.0 full ; file [SYSEXE]TEST.EXE generation 1 ; end product ; product DEC VAXVMS TEST2 V1.0 full ; file [SYSEXE]TEST.EXE generation 2 ; end product ;

Installing product TEST1 followed by product TEST2 works correctly. Generation 2 of file TEST.EXE replaces generation 1 of file TEST.EXE. However, if you remove product TEST2, generation 1 of file TEST.EXE is not restored; generation 2 of the file is left on the system.

One workaround is to use an execute install...remove statement sequence in product TEST2. The command procedure invoked during the execute install portion of the statement saves any previous version of the file. Later the execute remove portion of the statement restores the saved version of the file.

Compaq expects to correct this problem in a future release.

	privacy and legal statement
6534PRO_013.HTML