|
HP OpenVMS Systems Documentation |
|
HP OpenVMS Version 8.3 Release Notes
Chapter 5
|
$ 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
operating system.
5.4.1 KPB Extensions
V8.2
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
code.
5.4.2 CPU Name Space
V8.2
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.4.3 64-Bit Logical Block Number (LBN)
V8.2
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.4.4 Forking to a Dynamic Spinlock
V8.2
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.4.5 UCB/DDB Updates
V8.2
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.4.6 PCB$T_TERMINAL Size Increase
V8.2
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.4.7 Per-Thread Security Impacts Privileged Code and Device Drivers
Permanent Change
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.
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:
These routines must be called at or above IPL$_RESCHED, to prevent accidental rescheduling to a different CPU during their execution. Such a reschedule could cause the system to hang.
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.5 Applications Using Floating-Point Data
V8.2
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:
http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resource s.html
In order to allow floating point exceptions to conform completely with IEEE-Std 754-1985, Intel provides a function called an IEEE filter. An application developer who wants to use this function can place a call to this function code within a normal OpenVMS exception handler. When an exception occurs, the filter can decode the floating point instructions that caused the exception, as well as decoding the IEEE rounding modes and precision, and determining the operands that caused the exception
To obtain a copy of this filter, access the following Intel Web site and look for the OpenVMS header:
http://www.intel.com/cd/software/products/asmo-na/eng/219748.htm
The application note available at this site explains the filter in more detail. The example source code and the filter object library are supplied as an OpenVMS backup save set.
Note that this filter is required only to make certain details of
floating point exceptions conform to the IEEE standard. It is not
required for normal floating point operation.
5.5.2 Limitation When Using Ctrl/C and STOP Button (OpenVMS Alpha)
Condition: Pressing Ctrl/C to interrupt a program running under debugger control works only once. Thereafter, the Crtl/C interrupt is ignored. The same is true when using the DECwindows STOP button; the action is acknowledged only the first time the button is pressed.
Workaround: None.
5.5.3 Ada Event Support (I64 Only)
V8.3
Ada event support (SET BREAK/EVENT=ada_event, where ada_event is one of the events described by SHOW EVENT) is enabled on OpenVMS I64. However, this support is incomplete.
If you encounter problems with event breakpoints, switch to pthread
events (SET EVENT_FACILITY pthread) as a workaround. Note that
not all Ada events have an equivalent in the pthreads facility.
5.5.4 SHOW SYMBOL/TYPE Now Reports Correct Array Size (Alpha and I64)
V8.3
The SHOW SYMBOL command now reports the correct overall size of an array type. The previous behavior of SHOW SYMBOL/TYPE erroneously reported an incorrect size, for example:
DBG> sho sym/type z data MATINV\Z noncontiguous array descriptor type, 2 dimensions, bounds: [0:10,0:10], size: 4 bytes cell type: atomic type, IEEE single precision floating point, size: 4 bytes DBG> |
The corrected behavior is:
DBG> sho symbol/type z data MATINV\MATINV\Z noncontiguous array descriptor type, 2 dimensions, bounds: [0:10,0:10], size: 484 bytes cell type: atomic type, IEEE single precision floating point, size: 4 bytes DBG> |
V8.3
The EXAMINE/INSTRUCTION %PREVLOC command (and the EXAMINE/INSTRUCTION ^
alternative command) now works as expected. Previously, the debugger
would not decrement the PC so that the same instruction was displayed.
5.5.6 SHOW MODULE Command Now Computes Module Size (I64 only)
V8.3
The SHOW MODULE command now reports a nonzero value for the size of a
module. The value is an estimate, so you should use it only as a guide
to compare the relative sizes of modules.
5.5.7 C++ Language Issues (I64 Only)
Condition: The SHOW CALLS command sometimes displays C++ mangled names, rather than demangled names.
Workaround: None.
V8.3
Condition: The debugger does note support debugging C++ programs compiled with /OPTIMIZE.
Workaround: Compile C++ programs with /NOOPTIMIZE.
5.6 Ada Compiler(I64 Only)
V8.2
GNAT Pro (Ada 95) is available from AdaCore. Contact AdaCore at
www.adacore.com or sales@adacore.com for more information.
5.7 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:
BCK_EVENT_K_JOURNAL_OPEN
BCK_EVENT_K_JOURNAL_WRITE
BCK_EVENT_K_JOURNAL_CLOSE
Refer to the Backup API chapter in the HP OpenVMS Utility Routines Manual for more
information about registering callback routines.
5.8 C Programs: Compiling with CASE_LOOKUP=SENSITIVE Settings
Permanent Restriction
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.9 C Run-Time Library
The following sections describe changes and corrections to the C
Run-Time Library (RTL).
5.9.1 C RTL TCP/IP Header File Updates
V8.3
The C RTL ships header files for users to call TCP/IP. These headers have had numerous problems, making some of them unusable for anything beyond trivial TCP/IP programming.
Corrected headers shipped previously with several releases of TCP/IP and are located in their examples area. For OpenVMS Version 8.3, C RTL places those corrected headers into the C RTL header library (DECC$RTLDEF.TLB).
The following are examples of changes in the files:
BITYPES.H IN.H NAMESER_COMPAT.H RESOLV.H IF.H IN6.H NETDB.H SOCKET.H IF_ARP.H INET.H PCAP-BPF.H STROPTS.H IF_TYPES.H NAMESER.H PCAP.H TCP.H |
V8.3
The toascii function required by the X/Open specification had only a macro definition in <ctypes.h> .
This fix adds the
toascii
function, with an entry point in the DECC$SHR image.
5.9.3 64-Bit sigaction Problem Fixed
V8.3
Compile-time warnings resulted from using 64-bit pointers to the sigaction function.
This fix allows regular, long pointer (/POINTER=LONG), and short
pointer (/POINT=SHORT) compilations.
5.9.4 64-Bit Pointer Capability Added to Several Math Functions
V8.3
The following C RTL math functions can now pass 64-bit pointers when a user compiles with the /POINTER_SIZE qualifier:
frexp modf frexpf modff frexpl modfl |
V8.3
The C RTL malloc function accepts an unsigned int ( size_t ) as its parameter. The lib$vm_malloc action accepts a (positive) signed integer as its parameter.
Allocating 2 GB (0x80000000) did not allocate the proper amount of
memory and did not retun an error indication. A check is now added to
the
malloc
,
calloc
, and
realloc
functions for sizes equal to or greater than 2 GB that fail the call.
5.9.6 Memory Leak in exec* Fixed
V8.3
A memory leak in
exec
* is fixed.
5.9.7 Behavior of exit after a Failed execl Fixed
V8.3
The C RTL contains a fix for the problem in which a call to _exit after a failed execl really exits but should not.
In the OpenVMS implementation of vfork , a child process is not actually started as it is started on most UNIX systems. However, the C RTL creates some internal data structures intended to mimic child-process functionality (called the "child context").
A bug occurred whereby after a vfork while in the child context, a call to an exec function justifiably fails, then calls _exit . On UNIX systems, after the failed exec call, the child process continues to execute. A subsequent call to _exit terminates the child. In the OpenVMS implementation, after the failed exec call, the child context terminates. A subsequent call to _exit terminates the parent.
The C RTL fix is enabled by a feature logical switch, DECC$EXIT_AFTER_FAILED_EXEC. Enabling this feature logical allows the child context to continue execution.
With DECC$EXIT_AFTER_FAILED_EXEC disabled or not defined, the current
behavior remains the default.
5.9.8 confstr Enhancements
V8.3
To conform to the X/Open specification, the confstr function now allows a zero-length buffer to be passed in.
Also, confstr now supports the following three HP-UX symbolic constants, which are added to header file <unistd.h> :
_CS_MACHINE_IDENT
_CS_PARTITION_IDENT
_CS_MACHINE_SERIAL
V8.3
Previously, if a user called fopen (file, "wb+"), where file was a quoted DECNET specification and the remote file was absent, RMS reported a syntax error in the file specification instead of opening the file for update (creating a new version).
This problem is fixed in Version 8.3.
5.9.10 Possible File-Pointer-Locking Hang Condition
V8.3
OpenVMS Version 8.2 introduced file-pointer locking for multithreaded C programs ( flockfile and friends). The C RTL internally locks file pointers to conform to the X/Open specification.
A problem occurred in instances where file pointers were not unlocked on an error return during the preloading of data.
Users who experience this problem might see application hangs in multithreaded programs using file-pointer I/O. Analysis of the program state shows a deadlock of threads on TIS-recursive mutexes used to implement the file-pointer locks.
This problem is fixed in Version 8.3.
5.9.11 Backport Library No Longer Shipped
V8.3
Previously included with the compiler distribution kit was a C RTL
backport object library, which allowed developers on older versions of
OpenVMS to use the latest C RTL functions. This backport object library
is no longer being shipped.
5.9.12 Header File <time.h> Changes
V8.3
The following problem is fixed. Users who still experience this problem might have to recompile their application to see the corrected behavior.
The C RTL <time.h> header file defines the struct tm structure and the functions gmtime , localtime , gmtime_r , and localtime_r .
When the calling of one these functions and the application and the C RTL disagree about the size of struct tm , a user application can see data corruption or an access violation.
The tm structure has optional members for BSD extensions: tm_gmtoff and tm_zone . These are not defined in the ANSI or POSIX specifications or, for compatibility, with older compilations.
The previously mentioned functions have three different definitions in the C RTL:
The __UTCTZ_ prefixed functions expect to assign only the longer tm structure with the BSD extensions defined.
The problem occurs when the <time.h> header file and the C RTL do not agree on the number of structure members in struc tm . For example, the problem occurs with a C++ compilation using a compile-time macro implying _ANSI_C_SOURCE (such as _POSIX_C_SOURCE), which maps the listed C RTL functions using __UTC_ prefixes. The functions expect the shorter tm data structure, but the user program uses the longer tm structure definition. The copy-back of data from the function return tries to access data not allocated by the C RTL for the tm data members. This can result in unpredictable behavior, such as an unintended memory or access violation.
In OpenVMS Version 8.3, changes are made to
<time.h>
to make sure the C RTL selects the appropriate prefixing for the listed
functions.
5.9.13 Header File <time.h> Makes *_r Non-ANSI Functions Visible
V8.3
The C RTL functions ctime_r , gmtime_r , and localtime_r defined in the X/Open specification are not in the ISO/ANSI C standard and should not be visible when compiling only for ANSI compliance. Previously in the C RTL, they were visible.
This situation is fixed. Checks are added in the
<time.h>
header to make these functions visible only when not compiling for ANSI
compliance.
5.9.14 Header File <decc$types.h>: time_t int Declaration
V8.3
The time_t structure defined in the <decc$types.h> header file has been historically declared as unsigned long int on OpenVMS systems. UNIX platforms tend to declare it as a signed type, which can cause problems for ported programs on OpenVMS.
For UNIX compatibility, this fix uses a compile macro __SIGNED_INT_TIME_T to declare time_t as int .
The default remains
unsigned long int
for compatibility with older programs.
5.9.15 New DECC$SHRP.EXE Image
V8.3
OpenVMS installs a new shareable image DECC$SHRP.EXE to implement C RTL
functions requiring protected mode. This shareable image is installed
on all Alpha and Integrity processors and is invoked from either the
DECC$SHR.EXE or DECC$SHR_EV56.EXE shareable image.
5.9.16 Header File <wchar.h> and C++ %CXX-W-ENVIRSTKDIRTY Message
V8.3
The
<wchar.h>
header file is fixed to avoid the problem where the C++ Version 7.1
compiler can issue a %CXX-W-ENVIRSTKDIRTY warning when compiling with
the _XOPEN_SOURCE macro defined.
5.9.17 Header File <builtins.h> __CMP_SWAP* and _Interlocked* Visible to C++
V8.3
The compare and swap builtins (__CMP_SWAP* and _Interlocked*) in
<builtins.h>
did not include the OpenVMS Alpha C++ compiler. Because HP C++ Version
7.1 requires them, a change in conditional compilation now makes these
builtins visible.
5.9.18 Extra Parameters to fcntl Ignored
V8.3
Previously, calls to fcntl with a third-optional parameter when only two were expected (for commands not expecting a third parameter) returned errors.
This problem is fixed. Any unneeded third parameter is now ignored.
5.9.19 Problem with fwrite to stdout Fails with Large System MAXBUF
V8.3
Previously, using fwrite to stdout resulted in an error if the system's MAXBUF SYSGEN parameter was greater than or equal to 33278.
The following message might have been returned when using perror (as viewed by perror ) after the failing fwrite call:
Error writing output: : non-translatable vms error code: 0x186A4 %rms-f-rsz, invalid record size |
This problem is fixed.
5.9.20 Problem with Read/Write for Socket Transfers Greater Than 64K
V8.3
Support is added for socket transfers greater than 64K bytes for the following socket routines:
send recv read sendto recvfrom write sendmsg recvmsg |
V8.3
On OpenVMS I64 systems, the nanosleep function used to return an invalid status of -1 and set errno to EINTR (interrupted system call) when the function was correctly sleeping.
This problem is fixed.
5.9.22 Builtin __fci Added for I64 Systems
V8.3
The
<builtins.h>
header file is updated with the prototype for the new
__fci
builtin (a builtin for the
fc.i
instruction) now supported by the HP C compiler.
5.9.23 _FAST_TOUPPER Macro Added
V8.3
As of OpenVMS Version 8.3, to comply with the C99 ANSI standard and X/Open Specification, the _tolower and _toupper macros by default do not evaluate their parameter more than once. They simply call their respective tolower or toupper function. This avoids side effects (such as i++ or function calls) where the user can tell how many times an expression is evaluated.
To retain the older, optimized behavior of the
_tolower
and
_toupper
macros, compile with /DEFINE=_FAST_TOUPPER. Then, as in previous
releases, these macros optimize the call to avoid the overhead of a
run-time call. However, the macro's parameter is evaluated more than
once to determine how to calculate the result. this could create
unwanted side effects.
5.9.24 Call to atof("NaN") no Longer Gives Arithmetic Trap
V8.3
On OpenVMS Alpha Version 8.2 and higher, the following call to atof("NaN") gave an arithmetic trap:
d = atof("NaN");
%SYSTEM-F-HPARITH, high performance arithmetic trap, Imask=00000000,
Fmask=00000002, summary=02, PC=FFFFFFFF80BB23D4, PS=0000001B
-SYSTEM-F-FLTINV, floating invalid operation, PC=FFFFFFFF80BB23D4,
PS=0000001B
|
This is fixed in OpenVMS Version 8.3. The arithmetic trap is no longer generated.
| Previous | Next | Contents |