![]() |
![]() HP OpenVMS Systems Documentation |
![]() |
HP OpenVMS Version 8.4 Release Notes
Chapter 5
|
#ifdef __NEW_STARLET unsigned int lib$stat_vm_64( __int64 *code, unsigned __int64 *value_argument); #else /* __OLD_STARLET */ unsigned int lib$stat_vm_64(__unknown_params); #endif /* #ifdef __NEW_STARLET */ |
V8.4
On OpenVMS Alpha Version 8.4, when you set breakpoints, the debugger
will not be able to differentiate between the FORTRAN functions and
declared variables of the same name in different compilation unit.
5.3 C++ Run-Time Library
V8.3-1H1
Problems corrected in OpenVMS Version 8.3-1H1 include the following:
cxxl$set_condition(pure_unix); condition_behavior enum declared in <cxx_exception.h> header has been extended to include pure_unix member. |
#include <stdio.h> #include <cxx_exception.h> void generateACCVIO() { *((int*)0) = 0; } int main() { cxxl$set_condition(pure_unix); try { generateACCVIO(); } catch(...) { puts("caught"); } } |
To use this new functionality you must have a new version of cxx_exception.h , which is included in the CXXL$ANSI_DEF.TLB file provided with the Version 7.3 compiler (or higher). |
To use this new functionality, you must have a new version of cxx_exception.h , which is included in the CXXL$ANSI_DEF.TLB provided with the V7.3 compiler (or higher). |
The following problems are fixed in this version of the C++ Library (Version 7.3 and higher compiler):
#include <vector> int main() { std::vector<int> v; v.push_back(0); } |
istream_type& get(char_type *s, streamsize n, char_type delim); istream_type& get(char_type *s, streamsize n); |
The following restriction applies to the LIBRTL documentation for the lib$find_image_symbol run-time library routine:
If your application might dynamically activate shareable images that
use pthreads (or the older CMA thread interface), the main image must
be linked with the
pthread$rtl
image.
5.5 AST Delivery Clarification in Programs using POSIX Threads
V8.3-1H1
It is possible to utilize ASTs in threaded programs. Section B.12.5 in the Guide to the POSIX Threads Library describes some general usage notes and cautions. However, that section does not make clear how AST delivery behaves in programs with upcalls disabled (which is the default configuration).
In a program with upcalls disabled, user-mode ASTs will interrupt the thread that is executing when the AST is delivered. Therefore, the AST service routine cannot make any assumptions about the context in which it executes (with respect to thread ID, stack space available, and so on.)
Also, note that much of the material in Section B.12.5 of the Guide
describes a possible future version of OpenVMS. The description of
generalized "per-thread" or thread-targeted ASTs represents possible
future enhancements to the operating system. In all OpenVMS releases to
date, however, user-mode ASTs are treated as if they are directed to
the process as a whole.
5.6 RMS $PARSE Validation of Directory Files
V8.3-1H1
Starting with OpenVMS Version 8.3, the $PARSE service further validates
all directories named in a directory specification to ensure that the
directory characteristic is set. In previous OpenVMS versions,
attempting to use a file with a .DIR extension that was not a directory
resulted in a SS$_BADIRECTORY error from the $OPEN service, but not
necessarily from the $PARSE service. As of Version 8.3, the error is
consistently returned by the $PARSE service as long as it is not a
syntax-only $PARSE.
5.7 No-IOLOCK8 Fibre Channel Port Drivers
V8.3-1H1
Many I/O subsystem components synchronize their operations across CPUs using the IOLOCK8 spinlock, which has made acquiring the spinlock a performance bottleneck. Starting with Version 8.3-1H1, each Fibre Channel port driver (SYS$PGQDRIVER, SYS$PGADRIVER and SYS$FGEDRIVER) device uses its own port-specific spinlock instead of IOLOCK8 to synchronize its internal operations. In most configurations, this results in a significant decrease in the amount of time each CPU spends waiting for the IOLOCK8 spinlock as well as some increase in the Fibre Channel I/O rate.
Some minor changes are required to any class driver that connects to one of these new port drivers, so customers must determine whether they are running any non-HP class drivers that will not work with them. The simplest way to do this is to examine the output of the SDA command CLUE SCSI/SUMMARY and see whether the name of any third-party class driver device appears in the device hierarchy for an FGx0 or PGx0 port device in the "Device" column.
For more information, refer to the notes following this sample SDA session.
$ ANALYZE/SYSTEM OpenVMS system analyzer SDA> CLUE SCSI /SUMMARY SCSI Summary Configuration: --------------------------- SPDT Port STDT SCSI-Id SCDT SCSI-Lun Device UCB Type Rev -------------- -------------- -------------- -------- -------- ------ ---- 81624200 FGB0 8162CDC0 3 8162D240 0 GGA22 8162F380 HSV200 8162F180 1 DGA22801 8162FD40 HSV200 6100 81632900 2 DGA22802 81632AC0 HSV200 6100 816354C0 3 DGA22803 81635680 HSV200 6100 81638080 4 DGA22804 81638240 HSV200 6100 8162D400 4 8162DD80 0 GGA22 8163AC40 MRD200 8163B5C0 1 RJA22801 8163B780 RFD200 6100 8163C840 2 RJA22802 8163CA00 RFD200 6100 8163DAC0 3 RJA22803 8163DC80 RFD200 6100 8163ED40 4 RJA22804 8163EF00 RFD200 6100 |
All the DGA and GGA devices in this output are accessed through the modified HP class drivers SYS$DKDRIVER and SYS$GKDRIVER respectively; so they are safe to use with the new port drivers. Even though the physical device of Type MRD200 is not an HP qualified device, it does not present an IOLOCK8 problem because it is accessed through a GGAx unit, indicating that it uses the modified HP Generic class driver SYS$GKDRIVER. The RJA devices are not controlled by a modified HP class driver; they will not work with the new port drivers. |
V8.3-1H1
The C++ Version 7.2 for OpenVMS for Integrity servers predefines the macro __INITIAL_POINTER_SIZE to 0, unlike the C++ Version 7.1 compiler, which leaves it undefined. This is an intentional change that makes the C++ Version 7.2 consistent with the C compiler and provides support for pointer_size pragmas, while C++ Version 7.1 does not.
This change can cause diagnostics to appear in code that compiled cleanly with certain declarations selected by system header files that declare pointer types. This effect is most likely to appear in applications that use starlet headers and that compile with the __NEW_STARLET defined.
If you cannot modify the application source code to conform to the new
declarations, add the command-line qualifier
/UNDEF=__INITIAL_POINTER_SIZE to the CXX command line to prevent the
C++ Version 7.2 compiler from predefining this macro and thus causing
the system headers to provide the same declarations as with Version 7.1
of the compiler.
5.9 Building DCE IDL C++ Applications
V8.3-1H1
Building DCE IDL C++ applications on CXX Version 7.2 and higher results
in an undefined symbol linker warning. This is a known issue. To
overcome this warning, contact HP Support Services to request any
necessary patches.
5.10 Privileged Programs may Need a Recompile (Alpha Only)
V8.2
OpenVMS Alpha Version 8.2 is a major version release in which a number of privileged data structures have changed. It may be necessary to recompile and relink privileged applications linked with /SYSEXE that refer to internal OpenVMS data structures or routines.
If you get a SYSVERDIF error message when you invoke an image or load a
device driver, this indicates that the privileged image or driver was
compiled and linked under a prior version of the operating system. You
must then recompile and relink the image or driver to run on OpenVMS
Alpha Version 8.2.
5.11 Privileged Data Structures Updates
V8.2
OpenVMS Version 8.2 contains updates for a number of privileged data structures. These changes apply to both Alpha and Integrity server systems. The majority of these data structure updates are to support future scaling and performance projects in the operating system. As a result of these changes, any images or drivers that link against the base operating system (that is, those that use /SYSEXE on the LINK command) might need to be recompiled and relinked in order to run on OpenVMS Version 8.2.
The privileged data structure changes do not necessarily affect all privileged images and drivers --- only those linked with one of the specific subsystems that has changed. For these subsystems, the major version identification number associated with the subsystem has been increased. The subsystems that have changed are the following:
SYS$K_IO
SYS$K_MEMORY_MANAGEMENT
SYS$K_CLUSTERS_LOCKMGR
SYS$K_FILES_VOLUMES
SYS$K_CPU
SYS$K_MULTI_PROCESSING
SYS$K_PROCESS_SCHED
On Integrity servers, these versions are reported as SYS$K_VERSION_xxxx. |
The versions of these subsystems are linked to images based on the usage of various privileged system routines and data cells. You can use the ANALYZE/IMAGE utility to determine with what specific subsystem a privileged image is linked. For example:
$ 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.11.1 KPB Extensions
V8.2
Prior versions of OpenVMS supported the use of KPBs for kernel mode
above IPL 2. To facilitate the transition to Integrity servers, usage
of KPBs has been expanded for use in outer modes and all IPLs. This
Alpha and Integrity servers change allows certain code that previously
had private threading packages to make use of KPBs on both Alpha and
Integrity servers. In order to support these changes to the kernel
processes, some changes to the KPB structure were required. No source
changes should be necessary for existing Alpha code.
5.11.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. The space allocated for masks is being increased to 64 bits for Alpha and 1024 bits on Integrity servers to allow support for 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.11.3 64-Bit Logical Block Number (LBN)
V8.4
OpenVMS supports LBNs of only 32-bits. This limits the support of a
disk volume to 2 TiB. The 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.11.4 Forking to a Dynamic Spinlock
V8.2
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. This capability is added 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. The Code
should use the symbol FKB$C_LENGTH for the size of a FKB.
5.11.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 recommends that you use the provided internal routines to link and unlink 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.11.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.11.7 Per-Thread Security Impacts Privileged Code and Device Drivers
Permanent Change
The method used to attach 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:
#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 must 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.12 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 Integrity servers, 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 Integrity servers, refer to the OpenVMS Floating-Point White Paper on the following website:
http://www.hp.com/products1/evolution/alpha_retaintrust/openvms/resources.html
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.
The 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.12.2 Ada Event Support (Integrity servers 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 Integrity servers. 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.12.3 C++ Language Issues (Integrity servers Only)
V8.3
Condition: The debugger does note support debugging C++ programs compiled with /OPTIMIZE.
Workaround: Compile C++ programs with /NOOPTIMIZE.
5.13 Ada Compiler(Integrity servers Only)
V8.2
GNAT Pro (Ada 83, Ada 95 and Ada 2005) is available from AdaCore.
Contact AdaCore at www.adacore.com or sales@adacore.com for more
information.
5.14 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.15 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.16 C Run-Time Library
The following sections describe changes and corrections to the C
Run-Time Library (RTL).
5.16.1 C RTL TCP/IP Header File Updates
V8.4
The C RTL ships header files for users to call TCP/IP. C RTL places the headers into the C RTL header library (DECC$RTLDEF.TLB).
New header files are added, as appropriate for new features in TCP/IP.
SCTP.H SCTP_UIO.H |
These header files provide Stream Control Transmission Protocol (SCTP)
support. For more information on SCTP, see the HP TCP/IP Services
for OpenVMS Version 5.7 Release Notes.
5.16.2 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.16.3 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 that the C RTL selects the appropriate prefixing for the
listed functions.
5.16.4 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.16.5 Header File <builtins.h> __CMP_SWAP* and _Interlocked* Visible to C++
V8.3
The compare and swap built-ins (__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
built-ins visible.
5.16.6 Builtin __fci Added for Integrity servers
V8.3
The <builtins.h> header file is updated with the prototype for the new __fci built-in (a built-in for the fc.i instruction) now supported by the HP C compiler.
Previous | Next | Contents | Index |