HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 Release Notes

V8.2

The PL/I libraries (native and translated) are not included in OpenVMS I64 as they are in OpenVMS Alpha. The core PL/I images that are not available in OpenVMS I64 are:

[SYSLIB]DPLI$RTLSHR.EXE
[SYSMSG]PLI$MSG.EXE
[SYSLIB]PLIRTL.IIF
[SYSLIB]PLIRTL_D56_TV.EXE

Applications and shareable images that reference the PL/I library do not work on OpenVMS I64 for 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.

See a related note in Section 2.8.

5.31 POSIX Threads Library

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

Also see Section A.8 for a related note.

5.31.1 Stack Overflows During Exception Handling (I64 Only)

V8.2

Exception handling on I64 systems 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 I64. Usually this appears as an improperly handled ACCVIO that is associated with one of the following operations:

• RAISE
• pthread_cancel
• pthread_exit
• A thread has an active TRY or pthread_cleanup_push block, and an OpenVMS condition is signaled (for example, as a hardware exception or using LIB$SIGNAL or LIB$STOP).

If you see such a problem, try increasing 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 I64 systems. 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.

5.31.2 THREADCP Command Behavior on I64 Systems

V8.2

The DCL command THREADCP cannot be used on OpenVMS I64 systems 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 I64 systems.

Alpha users should continue to use the THREADCP command.

5.31.3 Floating-Point Compilations and Exceptions (I64 Only)

V8.2

Any source modules that call either of the following two old cma threads library routines must be compiled for use on OpenVMS I64 with the /FLOAT=G_FLOAT compiler qualifier (or language-specific equivalent).

cma_delay()

cma_time_get_expiration()

These routines accept only VAX-format floating-point values as arguments. Normally, OpenVMS I64 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 I64. Failure to properly compile any calls to these routines may result in unexpected exceptions being raised when IEEE format floating-point values are erroneously passed at runtime.

5.31.4 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.31.6 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.31.7 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.31.8 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.32 RMS: Improved Global Buffer VA Management

V8.2

In prior releases, certain patterns of repeated opens and closes of files with RMS global buffers by an application could lead to a VASFUL (virtual address space is full) error and consequently to application failure.

Starting with OpenVMS Version 8.2, RMS has enhanced virtual address (VA) space management, which greatly reduces the possibility of these VASFUL errors.

5.33 RMS Journaling

The following release notes pertain to RMS Journaling for OpenVMS.

For more information about RMS Journaling, refer to the RMS Journaling for OpenVMS Manual. You can access this manual on the OpenVMS Documentation CD-ROM (in the archived manuals directory).

5.33.1 Recovery Unit Journaling Incompatible with Kernel Threads

V7.3

Because DECdtm Services is not supported in a multiple kernel threads environment and RMS recovery unit journaling relies on DECdtm Services, RMS recovery unit journaling is not supported in a process with multiple kernel threads enabled.

5.33.2 Modified Journal File Creation

V7.2

Prior to Version 7.2, recovery unit (RU) journals were created temporarily in the [SYSJNL] directory on the same volume as the file that was being journaled. The file name for the recovery unit journal had the form RMS$process_id (where process_id is the hexadecimal representation of the process ID) and a file type of RMS$JOURNAL.

The following changes have been introduced to RU journal file creation in OpenVMS Version 7.2:

• The files are created in node-specific subdirectories of the [SYSJNL] directory.
• The file name for the recovery unit journal has been shortened to the form: YYYYYYYY, where YYYYYYYY is the hexadecimal representation of the process ID in reverse order.

These changes reduce the directory overhead associated with journal file creation and deletion.

The following example shows both the previous and current versions of journal file creation:

Previous versions: [SYSJNL]RMS$214003BC.RMS$JOURNAL;1
Current version: [SYSJNL.NODE1]CB300412.;1

If RMS does not find either the [SYSJNL] directory or the node-specific directory, RMS creates them automatically.

5.33.3 Remote Access of Recovery Unit Journaled Files in an OSI Environment

V6.1

OSI nodes that host recovery unit journaled files that are to be accessed remotely from other nodes in the network must define SYS$NODE to be a Phase IV-style node name. The node name specified by SYS$NODE must be known to any remote node attempting to access the recovery unit journaled files on the host node. It must also be sufficiently unique for the remote node to use this node name to establish a DECnet connection to the host node. This restriction applies only to recovery unit journaled files accessed across the network in an OSI or mixed OSI and non-OSI environment.

5.33.4 After-Image (AI) Journaling

V6.0

You can use after-image (AI) journaling to recover a data file that becomes unusable or inaccessible. AI recovery uses the AI journal file to roll forward a backup copy of the data file to produce a new copy of the data file at the point of failure.

In the case of either a process deletion or system failure, an update can be written to the AI journal file, but not make it to the data file. If only AI journaling is in use, the data file and journal are not automatically made consistent. If additional updates are made to the data file and are recorded in the AI journal, a subsequent roll forward operation could produce an inconsistent data file.

If you use Recovery Unit (RU) journaling with AI journaling, the automatic transaction recovery restores consistency between the AI journal and the data file.

Under some circumstances, an application that uses only AI journaling can take proactive measures to guard against data inconsistencies after process deletions or system failures. For example, a manual roll forward of AI-journaled files ensures consistency after a system failure involving either an unshared AI application (single accessor) or a shared AI application executing on a standalone system.

However, in a shared AI application, there may be nothing to prevent further operations from being executed against a data file that is out of synchronization with the AI journal file after a process deletion or system failure in a cluster. Under these circumstances, consistency among the data files and the AI journal file can be provided by using a combination of AI and RU journaling.

5.33.5 VFC Format Sequential Files

VAX V5.0
Alpha V1.0

You cannot update variable fixed-length control (VFC) sequential files when using before-image or recovery unit journaling. The VFC sequential file format is indicated by the symbolic value FAB$C_VFC in the FAB$B_RFM field of the FAB.

5.34 RTL Library (LIB$)

The following notes pertain to the LIB$ run-time library.

5.34.1 RTL Library (LIB$) Help Omission

V8.2

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.

5.34.2 RTL Library (LIB$): Calling Standard Routines (I64 Only)

V8.2

This release note clarifies how rotating registers are handled by the following calling standard routines:

LIB$I64_GET_FR
LIB$I64_SET_FR
LIB$I64_GET_GR
LIB$I64_SET_GR
LIB$I64_PUT_INVO_REGISTERS

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.

5.35 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 pertain to SORT32 V08-010 for OpenVMS Alpha and OpenVMS I64 Version 8.2. For additional notes, refer to Section 5.20.8 and Section 5.20.1.

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

5.36.1 CONVERT Problem With DFS-Served Disks

V8.2

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:

• Write the output file to an OpenVMS disk, and then copy the output file to the UNIX-served, DFS-mounted disk.
• Use the CONVERT/FDL command, where the FDL specifies the longest record length (LRL) required for the output file.

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 whether any undeleted work files can be deleted to free up disk space.

5.36.3 SORT/SPECIFICATION With Compound Conditions: Requirement

V7.3-1

SORT32 does not issue a diagnostic message for a compound condition in a key specification file unless it is enclosed in parentheses. For example:

Incorrect:

/CONDITION=(NAME=TEST1, TEST=(Field2 EQ "X") AND (Field3 EQ "A"))

Correct:

/CONDITION=(NAME=TEST1, TEST=((Field2 EQ "X") AND (Field3 EQ "A")))

V7.3-1

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

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

5.37 System Code Debugger (SCD) Not Available on I64 Systems

V8.2

The HP OpenVMS System Analysis Tools Manual implies that the System Code Debugger (SCD) is available on both I64 and Alpha systems. In fact, SCD is not available on I64 in Version 8.2. It will be available in a future release.

5.38 System Services

The following notes pertain to OpenVMS system services.

5.38.1 $GETJPI Item Code SCHED_CLASS_NAME Documented Incorrectly

V8.2

In the Version 8.2 HP OpenVMS System Services Reference Manual and online help, the $GETJPI item code SCHED_CLASS_NAME is incorrectly documented as CLASS_NAME. This error will be corrected in the next full release.

5.38.2 New GETSYI Item Codes Required for PFN-Mapped Sections (I64 Only)

V8.2

On OpenVMS VAX and Alpha, PFNs are 32-bit numbers (bits 0 to 31). When bit 31 is set, this indicates uncached I/O space.

On OpenVMS I64, PFNs are 64-bit numbers. A program written for I64 that uses PFN-mapped sections must indicate that it has been modified to recognize the larger data size. This is done by setting the new flag SEC$M_ARGS64 in calls to the following system services:

SYS$CRMPSC_PFN_64
SYS$CREATE_GPFN
SYS$CRMPSC_GPFN_64
SYS$MGBLSC_GPFN_64

The SEC$M_ARGS64 flag is ignored on OpenVMS Alpha but must be set on I64. If the flag is not set on I64, the error code SS$_IVSECFLG is returned.

The 32-bit oriented services SYS$CRMPSC and SYS$MGBLSC cannot be used to create or map PFN-mapped sections on I64.

To accommodate the larger data size of PFNs on I64, the SYS$GETSYI system service has been enhanced to recognize a new item code, SYI$_PFN_MEMORY_MAP_64. For details about this item code, refer to the HP OpenVMS System Services Reference Manual.

If SYI$_PFN_MEMORY_MAP_64 is specified, the service returns the layout of physical memory into a 64-bit data structure. The new item code and the new layout must be used on I64 systems. OpenVMS Alpha has been enhanced to accept the new form and continues to support the old form.

5.38.3 PFN-Mapped Sections and Uncached Memory (I64 Only)

V8.2

Mapped I/O space on an OpenVMS I64 system might require noncached access. You must set the SEC$M_UNCACHED flag when a PFN-mapped section is created if this section must be treated as uncached memory. The following system services now accept the SEC$M_UNCACHED flag:

SYS$CRMPSC_PFN_64
SYS$CREATE_GPFN
SYS$CRMPSC_GPFN_64

The SYS$MGBLSC_GPFN_64 service accepts but ignores the flag. The CACHED/UNCACHED characteristic is stored as a section attribute, and the system uses this attribute when the section is mapped.

On OpenVMS Alpha systems, all four services accept but ignore the SEC$M_UNCACHED flag.

Note that the older services SYS$CRMPSC and SYS$MGBLSC were not updated and do not accept the new flag.

5.38.4 SYS$ACM: Using on I64 Systems

V8.2

On OpenVMS I64 Version 8.2 systems, the ACME_SERVER process must be started manually. The ACME_SERVER services SYS$ACM requests. If you have applications that use the SYS$ACM system service, add the following commands to your SYS$STARTUP_VMS.COM prodecure before starting applications that use SYS$ACM:

$ SET SERVER ACME/START/LOG
$ SET SERVER ACME/CONFIG=(NAME=VMS,CRED=VMS)
$ SET SERVER ACME/ENABLE

The ACME_SERVER process will start automatically on OpenVMS I64 in a future release.

5.38.5 SYS$GOTO_UNWIND Not Available on I64

V8.2

The SYS$GOTO_UNWIND system service is not available on OpenVMS I64 systems; recode to use the new service SYS$GOTO_UNWIND_64.

SYS$GOTO_UNWIND was removed to ensure applications are ported correctly. For more information, refer to Porting Applications from HP OpenVMS Alpha to HP OpenVMS Industry Standard 64 for Integrity Servers.

The SYS$GOTO_UNWIND_64 service also exists on OpenVMS Alpha Version 7.3-2 and later, so applications can use common code. For more information about SYS$GOTO_UNWIND_64, refer to online help or to the HP OpenVMS System Services Reference Manual.

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

5.40 Traceback Facility

The following notes pertain to the Traceback facility (TRACE).

5.40.1 API Error (I64 Only)

V8.2

This note pertains to the new Traceback Facility API described in the HP OpenVMS Version 8.2 New Features and Documentation Overview. Currently, a processing error occurs if the rel_pc (relative PC value) or image_desc (image name string descriptor) argument is specified as zero. When these arguments are zero, the Traceback Facility should ignore them and continue Traceback processing. Instead, when Traceback encounters these zero values, it discontinues Traceback processing, and returns an unsuccessful return value to the calling program. This problem will be corrected in a future release.

5.40.2 Problem Corrected

V8.2

Previously, the Traceback facility did not correctly handle images installed with the /RESIDENT or /SHARED=ADDRESS_DATA qualifiers. This problem has been corrected. TRACE now displays symbolic locations in images installed with either the /RESIDENT or /SHARED=ADDRESS_DATA qualifiers, provided those images contain symbolic information (that is, they are linked using /TRACEBACK).

5.41 Watchpoint Utility (I64 Only)

V8.2

The Watchpoint Utility has not yet been ported to OpenVMS I64. HP expects to port this utility in a future release.

5.42 Whole Program Floating-Point Mode (I64 Only)

V8.2

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 I64, 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: