OpenVMS Version 7.1 Release Notes

In programs that link with a version of the DEC C RTL that supports passing sockets from a parent process to a child process and that links with DEC TCP/IP Services for OpenVMS (UCX) Versions 3.2 or earlier, a parent process cannot shut down or close a socket that has been closed by a child process, either specifically by the child or by default when the child terminates. With these versions of UCX, closing a socket breaks the TCP connection and another process cannot send any more data to it. For the shutdown function, the error status returned is EINVAL "invalid argument." For the close function, errno indicates EVMSERR.

Additionally, when a parent closes a socket, the socket is no longer available to any child processes that have inherited the socket in programs linked as specified above. On UCX Version 3.2 or earlier, a parent's closure of a socket interrupts operations pending from a child process on the same socket. In this case, a parent process should await termination of all its children before closing its sockets, and then ignore any errors when it does close them.

5.5.2.3 Linking DEC C Applications Using /NOSYSSHR

V7.0

When linking DEC C programs against the DEC C RTL object libraries using the /NOSYSSHR qualifier, applications that previously linked without undefined globals may now result in undefined globals for the CMA$TIS symbols. To resolve these undefined globals, add the following line to your link options file:

SYS$LIBRARY:STARLET.OLB/LIBRARY/INCLUDE=CMA$TIS 

V7.0

If a program linked with the /NOSYSSHR qualifier makes a call to a routine that resides in a dynamically activated image, the routine returns a value indicating an unsuccessful status, errno is set to ENOSYS, and vaxc$errno is set to C$_NOSYSSHR. The error message corresponding to C$_NOSYSSHR is "Linking /NOSYSSHR disables dynamic image activation." An example of this situation is a program linked with /NOSYSSHR that makes a call to a socket routine.

5.5.3 Documentation Changes and Corrections

This section describes corrections to the DEC C RTL documentation.

5.5.3.1 DEC C Run-Time Library Reference Manual for OpenVMS Systems

V7.1

The DEC C Run-Time Library Reference Manual for OpenVMS Systems erroneously states that the pipe function ignores the second parameter. This function has been corrected to ignore all values except O_NDELAY and O_NONBLOCK. The documentation for this second argument should be changed as follows:

• flag
  An optional argument used as a bitmask. If either the O_NDELAY or O_NONBLOCK bit is set, the I/O operations to the mailbox using array_fdscptr file descriptors terminate immediately, rather than waiting for another process.
  If, for example, the O_NDELAY bit is set and the child issues a read request to the mailbox before the parent has put any data into it, the read terminates immediately with zero status. If neither the O_NDELAY nor O_NONBLOCK bit is set, the child waits on the read until the parent writes any data into the mailbox. This is the default behavior if no flag argument is specified.
  The values of O_NDELAY and O_NONBLOCK are defined in the <fcntl.h> header file. Any other bits in the flag argument are ignored. You must specify this argument if the second optional, positional argument bufsize is specified. If the flag argument is needed only to allow specification of the bufsize argument, specify the flag as zero.

The following sections contain release notes pertaining to DECthreads. Release notes about kernel threads are in Section 5.10.

5.6.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.6.1.1 Behavior With Multiple Kernel Threads and Upcalls Enabled (Alpha Only)

V7.1

Starting with OpenVMS Alpha Version 7.1, DECthreads can use the kernel threads features introduced in OpenVMS Alpha V7.0, provided these features have been enabled in a multithreaded process.

The following sections describe changes in DECthreads behavior when multiple kernel threads and upcalls are enabled.

By default, the kernel threads features are disabled for an application. Refer to Section 5.10.1 for information on enabling kernel threads for a multithreaded process.

5.6.1.1.1 Multiprocessor Support

Starting with OpenVMS Alpha Version 7.1, DECthreads can create virtual processors as they are needed by the application. The number of virtual processors that DECthreads can create is limited by the system parameter MULTITHREAD. Typically, this parameter is set to the number of processors that reside in the system. Regardless of this parameter's value, DECthreads will create no more virtual processors than there are user threads (excluding DECthreads internal threads).

DECthreads does not delete virtual processors or let them terminate. They are retained in an idle (HIB) state until they are needed again. During image rundown, they are deleted by the OpenVMS executive.

The DECthreads scheduler can schedule any user thread onto any virtual processor. Therefore, a user thread can run on different kernel threads at different times. Normally, this should pose no problem. However, you may notice small changes; for example, a user thread's PID (retrieved by querying the system) might change from time to time.

See Section 5.10.1 for more information about kernel threads.

5.6.1.1.2 $EXIT and Exit Handling Changes

With OpenVMS Alpha Version 7.1, $EXIT and exit handling for multithreaded processes changes significantly when kernel threads is enabled. Exit handlers are now executed in a separate thread, not in the thread that calls the $EXIT system service routine. A call to $EXIT in a multithreaded process results in a call to pthread_exit. See the Guide to DECthreads for more information.

5.6.1.1.3 Condition Variable Waits

On OpenVMS Alpha Version 7.1, threaded applications that use the condition wait and timed condition wait routines may experience more spurious wakeups than previously. Correctly coded applications should not be affected by this change. See the Guide to DECthreads for more information.

5.6.1.1.4 Blocking System Service Calls

Starting with OpenVMS Alpha Version 7.1, system service calls that block are now thread synchronous; that is, they block only the calling thread instead of the entire process. See the Guide to DECthreads for more information.

5.6.1.1.5 $HIBER

Starting with OpenVMS Alpha Version 7.1, threaded applications that use $HIBER may experience more spurious wakeups than in previous releases. After the call to $HIBER returns, you must validate the wakeup to ensure that it is appropriate for execution to proceed. This wakeup validation has always been required, but it is now more important. See the Guide to DECthreads for more information.

Prior to Version 7.1, a thread that called $HIBER (or that called a library routine that resulted in a call to $HIBER) would cause the whole process to hibernate briefly whenever that thread was scheduled to run. With multiple threads in simultaneous calls to $HIBER, there was no reliable way to wake one or all of the threads. The next hibernating thread to be scheduled would awaken, and any other threads would continue to sleep.

With Version 7.1, these problems are resolved. However, the new behavior has other effects. For instance, hibernation-based services such as LIB$WAIT and the C RTL sleep() routine might complete prematurely if the service does not validate its wakeup (to ensure that enough time has passed or that there is some other reason for it to return).

5.6.1.2 POSIX 1003.1c Standard Interface

V7.0

Starting with OpenVMS Version 7.0, the DECthreads library (PTHREAD$RTL.EXE) implements a POSIX 1003.1c standard interface. The new POSIX.1c (or "pthread") interface is the most portable, efficient, and powerful OpenVMS programming interface for a multithreaded environment. This interface is defined by the C language header file pthread.h.

No exception-returning interface exists for the POSIX 1003.1c standard interface.

5.6.1.3 Thread Independent Services (TIS) Interface

V7.0

OpenVMS Version 7.0 and later includes the Thread Independent Services (TIS) application programming interface (CMA$TIS_SHR.EXE). TIS provides services that assist with the development of thread-safe application programming interfaces (APIs).

Thread synchronization can involve significant run-time cost, which is undesirable in the absence of threads. TIS enables you to build thread-safe APIs that are efficient in the nonthreaded environment, yet provide the necessary synchronization in the threaded environment.

When DECthreads is not active within the process, TIS executes only the minimum steps necessary. Code running in a nonthreaded environment is not burdened by the run-time synchronization that is necessary when the same code is run in a threaded environment. When DECthreads is active, the TIS functions provide the necessary thread-safe synchronization.

5.6.1.4 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 has been provided in this release to help ease migration. This compatibility mode will be removed in a future release.

5.6.1.5 CMA Interface: Change in Status

V7.0

In future releases, the DECthreads CMA interface (or "cma") will continue to exist and be supported in the OpenVMS operating system. However, starting with this release, it will no longer be documented or enhanced. Therefore, Digital recommends that you port your CMA-based application to the IEEE POSIX 1003.1c-1995 standard (or "pthread") interface provided by DECthreads.

5.6.1.6 Application Coding Errors

V7.0

Substantial changes made to threads in OpenVMS Version 7.0 will likely expose programming errors in existing applications that use DECthreads. Such errors include, but are not limited to, the following:

• Attempting to unlock a mutex that is not locked
• Use of uninitialized variables (for example, uninitialized condition variables)
• Improper use of data structures (for example, using a pthread_attr_t instead of a pthread_mutexattr_t in a call to pthread_mutexattr_create())
• Improper data access synchronization
• Use of an undocumented or unsupported routine

This section describes known DECthreads problems and restrictions.

5.6.2.1 Release Compatibility

V7.0

Binary compatibility and a source compatibility mode for the Draft 4 POSIX interface and the CMA interface to DECthreads are provided starting with OpenVMS Version 7.0. However, no object compatibility for object modules created on earlier OpenVMS releases is provided for object modules that use the Draft 4 POSIX interface.

5.6.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.6.2.3 DECthreads Debugger Metering Function

V7.0

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

5.6.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.6.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.

V6.2

Applications that use thread-safe run-time libraries might not be able to use LIB$FIND_IMAGE_SYMBOL to dynamically activate DECthreads or products that depend on DECthreads.

Certain run-time libraries use conditional synchronization mechanisms. These mechanisms typically are enabled during image initialization when the run-time library is loaded only if the process is multithreaded. If the process is not multithreaded, the synchronization is disabled.

If the application dynamically activates DECthreads, any run-time library using conditional synchronization may not behave reliably.

To work around this problem, link the image that calls LIB$FIND_IMAGE_SYMBOL against PTHREAD$RTL.

5.7 DECTPU for DECwindows Motif

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

5.7.1 Problems and Restrictions

This section describes DECTPU for DECwindows Motif problems and restrictions.

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

This section contains release notes pertaining to the Digital Portable Mathematics Library (DPML). See the Digital Portable Mathematics Library for information about using this utility.

5.8.1 Changes and Enhancements

This section describes a change to values returned in some DPML routines.

5.8.1.1 Returned Values Are Different in Some DPML Routines

V7.1

For OpenVMS Alpha Version 7.1, many of the DPML routines have been modified or rewritten to improve their performance or accuracy.

Occasionally these changes cause the modified routines to return values that differ by one least significant bit (lsb) when compared to results obtained in previous versions.

The results of the routines in this release are generally more accurate than the results in the previous release. This difference in results should not be considered a bug in the new version of the library.

5.9 High-Performance Sort/Merge Utility (Alpha Only)

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

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 Kernel Threads (Alpha Only)

This section contains release notes pertaining to using kernel threads on OpenVMS Alpha systems. Release notes about DECthreads are in Section 5.6.

5.10.1 Changes and Enhancements

V7.1

Several changes have been made to kernel threads in OpenVMS Alpha Version 7.1 to let you control whether kernel threads is enabled for a process.

You can safely use an application with kernel threads if the threads do not interfere with each other during their independent execution. However, if they do interfere, you may not wish to enable kernel threading.

One example of interference is when two or more threads modify a common memory location without synchronization. This condition can lead to incorrect and inconsistent results. Using kernel threading, where the threads run concurrently on multiple CPUs, can aggravate this problem. With multiple kernel threading disabled for a process, an application runs much less risk of encountering this problem.

The following changes have been made to kernel threads in OpenVMS Alpha Version 7.1 to give you more control over enabling or disabling kernel threads:

• MULTITHREAD System Parameter
  In OpenVMS Alpha Version 7.0, the default behavior for applications that use DECthreads was to run without the kernel threads features introduced in that release. Kernel threads was disabled systemwide by setting the MULTITHREAD system parameter to 0.
  In OpenVMS Alpha Version 7.1, AUTOGEN now sets the MULTITHREAD system parameter value equal to the number of CPUs in the system. This setting makes the kernel threads features available systemwide for applications that choose to enable them. For more information about the MULTITHREAD system parameter, see the OpenVMS System Management Utilities Reference Manual, or SYSMAN or SYSGEN help.
• /THREADS_ENABLE Linker Qualifier and THREADCP Tool
  Once kernel threads features are enabled systemwide, the determination of whether an application uses these features is made at the main image level. Information stored in the image header of a main image dictates whether the features are to be used. The features are disabled by default.
  When building new images, you can control this information by using the new linker qualifier /THREADS_ENABLE. (For details about the /THREADS_ENABLE qualifier, see the OpenVMS Linker Utility Manual or DCL help for the LINK command.)
  To modify the control information in existing images, use the THREADCP tool described in the OpenVMS Version 7.1 New Features Manual. The THREADCP tool enables testing to verify that a threaded application runs correctly with the new kernel threads features.

For more information about kernel threads, refer to the OpenVMS Alpha Guide to Upgrading Privileged-Code Applications.

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 LTDRIVER

The following sections contain release notes pertaining to the LTDRIVER.

5.12.1 Problems and Restrictions

This section describes known LTDRIVER problems and restrictions.

5.12.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.13 MACRO-32 Compiler for OpenVMS Alpha (Alpha Only)

The following sections contain release notes pertaining to the MACRO-32 Compiler for OpenVMS Alpha.

5.13.1 Problems and Restrictions

This section describes problems and restrictions pertaining to the MACRO-32 Compiler for OpenVMS Alpha.

5.13.1.1 Quadword Moves Into the VAX SP and PC

V7.1

Due to architectural differences between VAX and Alpha computers, it is not possible to completely emulate quadword moves into the VAX stack pointer (SP) and the program counter (PC) without programmer intervention. The VAX architecture defines R14 as the SP and R15 as the PC. A MOVQ instruction with SP as the target would simultaneously load the VAX SP and PC, as shown in the following example:

MOVQ    R0,SP   ; Contents of R0 to SP, R1 to PC 
 
MOVQ    G^CTL$AQ_STACK+16, SP   ; ctl$aq_stack+16 to SP 
                                ; ctl$aq_stack+20 to PC 

Note

Even though the VAX MACRO assembler permits this operation, it is specifically disallowed because the results are unpredictable (see the VAX Architecture Reference Manual, second edition).

If the compiler encounters a MOVQ instruction with SP as the destination, it generates a sign-extended longword load from the supplied source into R30 (the Alpha stack pointer) and issues the following informational message:

%AMAC-I-CODGENINF, (1) Longword update of Alpha SP, PC untouched 

If the intended use of the MOVQ instruction is to achieve the VAX behavior, the MOVQ should be followed by a branch to the intended address, as shown here:

MOVQ    G^CTL$AQ_STACK+16, SP   ; Load the SP 
JMP     G^CTL$AQ_STACK+20       ; And branch 

If the intended use of the MOVQ instruction is to load the stack pointer with an 8 byte value, the EVAX_LDQ built-in should be used instead, as follows:

EVAX_LDQ        G^CTL$AQ_STACK+16 

V7.0

The MACRO-32 compiler has been modified to include 64-bit addressing support. When you use this new version of the compiler, regardless of whether you use the 64-bit addressing features, you must also use the OpenVMS Version 7.0 (or later) ALPHA$LIBRARY:STARLET.MLB.

STARLET.MLB contains the MACRO_COMPILER_DIRECTIVES macro definitions, including the revised .CALL_ENTRY directive. If you do not use ALPHA$LIBRARY:STARLET.MLB from OpenVMS Version 7.0 or later, your program will not compile successfully. Instead, the following errors will be reported:

%AMAC-E-DIRARGERR, error in compiler directive argument 
at line number n in file filename 
 
%AMAC-E-DIRSYNX, directive syntax error 
at line number n in file filename 

Make sure that ALPHA$LIBRARY:STARLET.MLB from OpenVMS Version 7.0 or later is on your system and that the ALPHA$LIBRARY logical points to the correct directory.

If necessary, you can extract .CALL_ENTRY from the new STARLET.MLB, and insert it in an alternate STARLET, if you are using one.

5.14 Mail Utility

This section contains release notes about the Mail utility that are of interest to programmers. Release notes of interest to system managers are documented in Section 4.12.

5.14.1 Changes and Enhancements

The following section describes a change made to some MAIL utility routines.

5.14.1.1 MAIL$SEND, MAIL$MESSAGE, and MAIL$MAILFILE Return Status Modifications

V7.1

The MAIL utility routines MAIL$SEND, MAIL$MESSAGE, and MAIL$MAILFILE have been modified to return a word-sized length for items specified in the output item list.

5.14.2 Problems and Restrictions

The following note describes a restriction for callable mail.

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

  6481P007.HTM
  OSSG Documentation
  11-DEC-1996 07:52:22.88

Copyright © Digital Equipment Corporation 1996. All Rights Reserved.

Legal