HP OpenVMS Systems Documentation
HP OpenVMS Version 8.2 Release Notes
$ ANALYZE/IMAGE IMAGE.EXE /OUTPUT=IMAGE.TXT $ SEARCH IMAGE.TXT "SYS$K_"
If any of the versions reported match this list, OpenVMS Version 8.2
will fail to activate the image and issue a SS$_SYSVERDIF (system
version mismatch error) for images linked on prior versions of the
5.3.1 KPB Extensions
Prior versions of OpenVMS supported the use of KPBs for kernel mode
above IPL 2. To make the transition to I64 easier, usage of KPBs has
been expanded for use in outer modes and all IPLs. This Alpha and I64
change allows certain code that previously had private threading
packages to make use of KPBs on both Alpha and I64. In order to support
these changes to kernel processes, some changes to the KPB structure
were required. No source changes should be necessary for existing Alpha
5.3.2 CPU Name Space
OpenVMS currently has an architectural limit of a maximum CPU ID of 31. Various internal data structures and data cells have allocated 32 bits for CPU masks. We are increasing the amount of space allocated for these masks to 64 bits for Alpha and 1024 bits on I64 to allow supporting larger CPU IDs in a future release. The existing longword CPU mask symbols and data cells will still be maintained.
There should be no initial impact to privileged images and drivers.
However, at some time in the future, HP will document how privileged
products that refer to CPU masks must change their code to support
systems with CPU IDs greater than 31.
5.3.3 64-Bit Logical Block Number (LBN)
OpenVMS today supports LBNs of only 31 bits. This limits our support of
a disk volume to 1 terabyte. The amount of space allocated for internal
LBN fields is being increased to 64 bits to allow support for larger
disk volumes in the future. The existing longword LBN symbols will
still be maintained and will be overlaid with a quadwords symbol.
5.3.4 Forking to a Dynamic Spinlock
In order to scale the OpenVMS operating system on large SMP systems, a number of areas in the operating system have been using dynamic spinlocks as opposed to the very limited number of static spinlocks. The ability to FORK and have the fork dispatcher obtain synchronization with a dynamic spinlock is desirable. We are adding this capability to OpenVMS Version 8.2 by extending the size of the FKB structure and by adding a FKB$L_SPINLOCK field to the end of this structure. This spinlock field is referenced only if FKB$B_FLCK contains the value SPL$C_DYNAMIC. The FKB structure is embedded in many other system data structures, and this change impacts the size and layout of a large number of privileged data structures
Applications that copy the FKB$B_FLCK field from an OpenVMS created structure to another FKB should also consider copying the data in the FKB$L_SPINLOCK field.
HP recommends that privileged code check for cases of allocating FKB
structures and using a hard-coded value for the size of 32. Code should
use the symbol FKB$C_LENGTH for the size of a FKB.
5.3.5 UCB/DDB Updates
A number of updates have been made to the UCB and DDB structures.
The list of UCBs associated with a DDB is currently a singularly linked list. When creating and deleting a UCB, this list must be walked until the appropriate location is found. For OpenVMS Version 8.2, UCBs are now linked to the DDB with a double linked list. In addition, the DDB maintains a seed pointer to where the search should start when creating a new unit to allow for faster device creation. Drivers that manipulate their unit seed pointer in a template UCB will not be able to take advantage of the faster device creation.
Any code that manipulates the DDB list of UCBs will no longer work correctly. HP highly recommends that you use the provided internal routines for linking and unlinking UCBs. Code-walking the list of UCB forward continues to work correctly.
The UCB$W_UNIT field is currently a 16-bit word field. There are now 32 bits allocated for this field. The UCB$W_UNIT field will still be maintained, so no source code changes are necessary. In a future release, OpenVMS might support larger unit numbers. This would be done only for drivers that indicate they can support this feature.
Byte and Word fields in the terminal driver's UCB extension are now
aligned on longword boundaries.
5.3.6 PCB$T_TERMINAL Size Increase
The Process Control Block (PCB) structure contains a field PCB$T_TERMINAL, which is 8 bytes to hold the device name for an interactive process (such as LTA123:, RTA7:, NVA456: and so forth). This field is a counted ASCII string, with the first byte being the length of the string and the remaining 7 bytes holding the device name. With a 3-letter device name, only four digits can be used to hold the unit number, and the colon would be stripped off for unit numbers greater than 999. For OpenVMS Version 8.2, this field has been increased to 16 bytes to hold device names with larger unit numbers.
If you fetch this field using a call to $GETJPI with the JPI$_TERMINAL
item code, you are not impacted, but you might want to increase the
buffer passed to the system service to hold up to 16 bytes.
5.3.7 Per-Thread Security Impacts Privileged Code and Device Drivers
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:
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.3.8 IPL Requirement For OpenVMS Fork Thread Creation Now Enforced
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:
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.4 Applications Using Floating-Point Data
The Itanium® architecture implements floating-point arithmetic in hardware using the IEEE floating-point formats, including IEEE single and IEEE double.
The Alpha hardware supports both IEEE and VAX floating-point formats. On OpenVMS Alpha, the compilers generate code to use the VAX formats by default with options to use the IEEE formats.
On OpenVMS I64, the compilers generate code to use the IEEE formats by default with options to use the VAX formats. HP recommends the use of IEEE formats on Integrity servers unless applications need to process VAX floating-point binary data that has been generated on VAX or Alpha systems. For details about using VAX formats on OpenVMS I64, refer to the OpenVMS Floating-Point White Paper on the following website:
OpenVMS Version 8.2 contains new IEEE floating-point versions of LIB$
and OTS$ run-time library routines for use by applications using IEEE
floating-point data. The function prototype definitions of these new
routines are not included in the system-supplied header files. To use
these functions you must define the function prototypes in your
applications. Refer to the LIB$ and OTS$ run-time library reference
manuals for descriptions of these functions. These function prototype
definitions will be included in the system-supplied header files in a
5.5 Ada Compiler Not Yet Available (I64 Only)
The Ada compiler is supported on OpenVMS Alpha Version 8.2. HP is not
porting the HP Ada 83 compiler from Alpha to I64; AdaCore is porting
the Ada 95 compiler to OpenVMS I64. Customers can contact AdaCore
directly when this product becomes available.
5.6 Backup API: Journaling Callback Events Restriction
If an application registers a callback routine for any of the journaling events, it must register a callback routine for all the journaling callback events. The following is a list of the journaling callback events:
Refer to the Backup API chapter in the OpenVMS Utility Routines Manual for more
information about registering callback routines.
5.7 C Programs: Compiling with CASE_LOOKUP=SENSITIVE Settings
If you are compiling C programs in a process where the characteristics were set to CASE_LOOKUP=CASE=SENSITIVE, any #include files in your C program specified with the .h file type (lowercase h) will not be seen and executed. In addition, if a system #include file specifies another #include file with a .h file type, the second #include file will not be seen and an error will be generated.
To avoid this behavior, compile with case set to blind. If it is necessary to use case=sensitive , specify any #include files in your C programs either with no file type (for example, #include <stdio> ) or with an uppercase H file type (for example, #include <stdio.H> ).
Note that this does not correct the scenario where system #include
files, such as stdlib.h, in turn specify #include files with a .h file
type and cause an error to be generated.
5.8 C Run-Time Library
The following sections describe changes and corrections to the C
Run-Time Library (RTL).
5.8.1 Memory Leak in Programs Using socket_fd Fixed
Previously, there was a memory leak in programs using
, which in certain circumstances consumed the page-file quota. This
problem has been fixed.
5.8.2 vsnprintf and snprintf User Buffer Overwrite Fixed
Previously, under certain conditions, the vsnprintf and snprintf functions could overwrite memory beyond the maximum count allowed in the user's buffer.
For example, the following call to snprintf would overwrite user buffer t beyond the allowed t , using the format string provided:
snprintf(t, 3, "%2sxxxx", "a");
This problem has been fixed.
5.8.3 mmap and mprotect Changes
Previously, a change in the C RTL for OpenVMS Versions 7.3-1 and 7.3-2 would return an error unless memory for the mprotect function had already been mapped by mmap .
This problem has been fixed by restoring the legacy behavior: you can
once again set protection using
for memory that was not mapped by
5.8.4 getpwnam_r and getpwuid_r Pointer Problem Fixed
Previously, programs calling the short-pointer version of getpwuid_r ( _getpwuid_r32 ) could incorrectly pass a long-pointer value for the third argument (buffer).
This user-specified buffer was allocated to members of the resulting passwd structure, which are 32-bit pointers. This caused an incorrect result for those members ( pw_name , pw_dir , and pw_shell ) if the buffer was in high memory.
The same problem existed for the short-pointer version of getpwnam_r ( _getpwnam_r32 ).
This problem has been fixed. The prototypes for
have been changed so that the functions now accept only a 32-bit
pointer for the buffer argument instead of allowing a 64-bit
5.8.5 _strtok_r32 and _strtok_r64 Now in Scope
Previously, programs that included
would not find a prototype in scope. This problem has been fixed.
5.8.6 const Type Qualifier Added to iconv Prototype (Alpha Only)
To conform to the X/Open standard, the const qualifier will be added to the second argument of the iconv function prototype in <iconv.h> when the XOPEN_SOURCE feature test macro is defined to be 500 (#DEFINE XOPEN_SOURCE 500):
size_t iconv (iconv_t cd, const char **inbuf, size_t *inbytesleft, char **outbuf, size_t *outbytesleft);
Previously, the C++ compiler did not recognize the result of the offsetof macro as an integral constant expression, which led to C++ compiler errors when used in that manner.
This problem has been fixed. The <stddef.h> header file has been modified to provide an alternative definiton of the offsetof macro for use by C++ Version 6.5 and later.
This alternative definition uses an EDG extension (__INTADDR__) to
perform the otherwise nonstandard conversion from pointer to integer.
This solution was provided by and recommended by EDG, and is the same
as their solution (except for the use of nonpolluting names).
5.8.8 getc Macro Argument Now Protected by Parentheses (Alpha Only)
To comply with the ISO C Standard (ISO/IEC 9899), the argument to the
macro is now protected by parentheses.
5.8.9 CXXL Prefix Problems with Inlined Functions getc and getchar Fixed (Alpha Only)
Previously, C++ compilations of getc and getchar resulted in undefined symbol warnings at link time. Under certain circumstances, the getc macro (in C) or inline function (in C++) called the actual decc$getc function. The problem was that the inline getc function declared the actual decc$getc function under extern_prefix "CXXL$". A similar problem occurs with getchar .
This problem has been fixed. The
header file has been modified to provide a prototype for
within the scope of the
directive, while leaving the inlined implementation definition outside
the scope of CXXL$ prefixing.
5.8.10 Non std Functions Declared in std Namespace (Alpha Only)
Previously, C++ compilations of source files that reference v*scanf or *snprintf functions resulted in %CXX-E-UNDECLARED errors because the <stdio.h> header declared these functions in the std namespace, but did not inject them into the global namespace.
This problem has been fixed. These function declarations have been
moved to a location outside the
5.8.11 lseek on Large File Offset Problem Fixed (Alpha Only)
function failed to correctly position files on offsets larger than
ULONG_MAX (4294967295) bytes (under the _LARGEFILE feature control
macro). For example, calling
on a 6-gigabyte (16 megablock) file and specifying an offset of
0x100000000 left the file position at 0. This problem has been fixed.
5.8.12 New EABANDONED Code in <errno.h>
A new errno code EABANDONED has been added to the <errno.h> header file.
Pthreads functions can now return an EABANDONED ("Owner cannot release
resource") code if the system has determined that the target
process-shared mutex is locked by a process that has terminated (that
is, the mutex is considered "abandoned" because the rightful owner
cannot release it).
5.8.13 mktime Problem Fixed
Previously, the UTC-time-based function
lost a day when the structure member
was supplied with 0 or negative values.
also generated inconsistent days. This problem has been fixed.
5.8.14 POLLWRNORM Now the Same as POLLOUT in <poll.h>
According to the X/Open documentation for the
header file, POLLWRNORM should equal POLLOUT. Previously it did not;
now it does.
5.8.15 IPV6 Structures in <in6.h> Now Packed
The IPV6 structure
header file was not packed, causing problems when applications expected
and checked the size for packed structures. This structure should have
been packed because the member alignment is on natural boundaries. This
problem has been fixed.
5.8.16 __PAL_BUGCHK Fixed in <builtins.h>
Previously, when using the C and C++ compilers, calling __PAL_BUGCHK
with a parameter resulted in a fatal error. Also, many of the builtins
had misleading comments about their implementation. This has been fixed.
5.8.17 C++ Compiler Error with statvfs Fixed
The restrict type qualifier is added to the <decc$types.h> and <statvfs.h> header files when the C or C++ compiler or the X/Open standard (XPG6) supports it.
This fixes the following problem:
int statvfs(const char * __restrict path, struct statvfs * __restrictbuf); ....................................^ %CXX-E-EXPRPAREN, expected a ")"
The following glob and globfree issues have been fixed:
Previously, OpenVMS Version 7.3-2 did not correctly optimize the DECC$SHR_EV56.EXE image.
The C RTL build is done with two sets of objects: one compiled
normally, and one optimized for Alpha EV56 processors. The
DECC$SHR_EV56.EXE image was not linked with the optimized objects. This
problem has been fixed.
5.8.20 Zone Information Compiler (zic) Updates
New time indicators have been added for the AT field in the Rule line.
The letter "u" (or "g" or "z") indicates that the time in the AT field is UTC.