|
HP OpenVMS Systems Documentation |
|
OpenVMS Version 7.3 Release Notes
6.9.22 Source View ErrorsV7.3 Previous versions of the debugger had problems within the source view of the DECwindows Motif interface, including the following:
These problems have been corrected.
V7.3
In previous versions, the DECwindows Motif interface to the debugger
did not correctly update the source view on a return step command from
a subroutine call when the calling routine was in a different source
module. This problem has been corrected.
V7.3
The ability of the debugger to set modules dynamically has been
improved.
V7.3 On Alpha systems, some recent compilers introduce certain stack errors. If previous versions of the debugger encounter these errors while program execution is suspended at a breakpoint, a STEP or other resume command can result in the following error:
This problem has been corrected, and you should upgrade the compiler
that causes the corrupt stack.
V7.3
When attempting just-in-time debugging (for example, when DBG$TRACE is
defined as SYS$SHARE:DEBUG.EXE), previous versions of the debugger
sometimes fail. This has been corrected.
V7.3 The OpenVMS Version 7.3 debugger does not support previous versions of the client/server interface. You must install the client/server interface found in the kit on the distribution media, as identified in the following table:
These client kits are self-extracting .EXE files. Once the appropriate executable file has been transferred to the PC, you can run the file to install the debug client on the PC. The InstallShield installation procedure guides you through the installation.
By default, the debug client is installed in the
\Program Files\OpenVMS Debugger
folder. You can also click Browse to select an alternate location.
V7.1 The OpenVMS operating system has a number of special modes of operation designed to help you debug complex hardware and software problems. In general terms, these special modes enable an extra level of tracing, data recording, and consistency checking that is useful in identifying a failing hardware or software component. These modes of operation are controlled by several system parameters: MULTIPROCESSING, POOLCHECK, BUGCHECKFATAL, and SYSTEM_CHECK. If you are using one of these special modes (for example, to debug a device driver or other complex application), under certain conditions, generally related to high I/O loads, it is possible to incur a CPUSPINWAIT bugcheck. To prevent a CPUSPINWAIT bugcheck, either use the system default settings for these system parameters, or reduce the loading of the system.
If you have reason to change the default settings, you can reduce the
likelihood of encountering a problem by setting the SMP_LNGSPINWAIT
system parameter to a value of 9000000.
The following sections contain release notes pertaining to restrictions and known problems in the use of the High-Performance Sort/Merge utility, Hypersort. These restrictions and known problems supplement the material in the OpenVMS Utility Routines Manual.
Hypersort (HYPERSORT.EXE) can optionally be selected for use by SORT,
MERGE, CONVERT, Compaq COBOL, and Oracle Rdb. Use SORT32 as a
work-around for problems or restrictions in Hypersort, unless the
problem or restriction also exists in SORT32.
V7.3
Hypersort does not support /FORMAT=RECORD_SIZE for use with SORT or
MERGE.
V7.3
Hypersort does not support asterisk (*) as an input file specification.
V7.3
Hypersort does not support work-file specifications that result in
insufficient free disk space to complete the sort or merge operation.
V7.3
Hypersort work files must be redirected to directories that allow
multiple-file versions that can handle the number of requested work
files. This restriction also exists in SORT32.
V7.3
Hypersort does not correctly calculate the byte offset for keys for VFC
Format files.
V7.3
Hypersort overflows the working-set display in the /STATISTICS output
for any working set that is 1,000,000 pages or larger. This is also a
known problem with SORT32.
V7.3 Both SORT32 and Hypersort depend on the proper relationship between working-set size and page-file quota to avoid insufficient virtual memory. In general, page-file quota may need to be three times the working-set size or even larger to avoid insufficient virtual memory.
If insufficient virtual memory is detected, SORT32 signals INSVIRMEM
and attempts to complete the sort. Hypersort terminates in this
situation with INSVIRMEM or possibly ACCVIO.
V7.2 The NODE_HWTYPE item is obsolete. Please use the HW_NAME item instead. The NODE_HWTYPE item has not been removed; therefore, programs using this item will still work. However, Compaq recommends that you migrate such programs to use the HW_NAME item whenever possible to take advantage of new capabilities.
On OpenVMS VAX systems, applications using NODE_HWTYPE receive cryptic,
4-character, system model names for all VAX systems and receive the
string ALPH for all Alpha systems. In contrast, the HW_NAME item
operates on both OpenVMS VAX and OpenVMS Alpha systems, and provides
longer, more descriptive names to be returned. For example, HW_NAME
returns "VAXstation II," whereas NODE_HWTYPE returns "VUV2" for the
same system.
The OpenVMS Alpha LIBRARIAN sometimes does not inform you of errors during compression, data reduction, or data expansion operations. This problem occurs if the account or process in which the LIBRARIAN is running has a low PGFLQUOTA process quota. Operation failure is not readily apparent because the $PUTMSG system service always returns a status of SS$_NORMAL, even when the system service fails. However, when a failure occurs, the LIBRARIAN returns a status other than Success.
To work around this problem, run the compression, data reduction, or
data expansion operation in an account with a PGFLQUOTA process quota
greater than 23000. In addition, ensure that your command procedures
check the return status from the LIBRARY command.
The following sections describes release notes pertaining to the Linker
Utility.
V7.3 The Linker utility shipped with OpenVMS Alpha Version 7.3 omits the solitary attribute specified in an option file, causing solitary program sections not to be solitary. The resulting image may be corrupted. No error message is displayed during the link operation. The following TIMA kit addresses this problem: DEC-AXPVMS-VMS73_LINKER-V0100--4.PCSI
This kit will be available at the end of June 2001, from the following
location:
V7.2
Developers who are creating object files should be aware that the
linker's internal stack is guaranteed for only 25 elements. Any
calculations must be done within this constraint.
In releases prior to OpenVMS Version 6.1, LTDRIVER did not set the "extended DDT" bit; therefore, the POSIX function CANCEL SELECTIVE did not work with LTDRIVER. This problem has been corrected, but a restriction remains.
Although this fix allows $QIO reads and writes to be selectively
canceled, any $QIO done to the port driver (that is, with the
IO$_TTY_PORT function modifier---like a LAT connect $QIO)
cannot be canceled with CANCEL SELECTIVE.
See Chapter 8 for a number of notes that concern the MACRO--32
compiler.
V7.1 OpenVMS callable mail routines are not thread-safe. Refer to the Guide to POSIX Threads Library for more information about calling non-thread-safe routines within a threaded application. Because callable mail context information is maintained on a per-process (rather than a per-thread) basis, multiple threads performing context-based processing must be synchronized so that only one mail context of a given type is active at once. Otherwise, one thread could corrupt another thread's mail operations.
On OpenVMS Alpha systems, there is an additional restriction when
kernel threads is enabled in a multithreaded environment. In this
environment, callable mail should be used only in the initial thread.
This version of OpenVMS VAX provides updated versions of the Mathematics Run-Time Library (RTL) images MTHRTL.EXE, UVMTHRTL.EXE, and VMTHRTL.EXE that contain new entry points in support of DEC Fortran Version 6.0. (UVMTHRTL.EXE is an alternate form of MTHRTL.EXE; references to MTHRTL.EXE in the following paragraphs also apply to UVMTHRTL.EXE.) Due to the large number of entry points added to MTHRTL.EXE, that image's transfer vector was extended and its global section match identifier incremented. This means that images linked against the new version of MTHRTL.EXE will not run on a system running an earlier version of OpenVMS VAX, unless that system has also installed DEC Fortran Version 6.0. In addition, images linked against the new MTHRTL.EXE cannot be translated to run on OpenVMS Alpha using DECmigrate. To link an image so that it will run on an earlier version of OpenVMS VAX, create a directory that contains saved copies of the .EXE and .OLB files from the SYS$LIBRARY directory of the earliest version you want to support, and define the logical name SYS$LIBRARY to point to that directory before linking. Because OpenVMS VAX also defines a system logical name MTHRTL to refer to either MTHRTL.EXE or UVMTHRTL.EXE, you must also define MTHRTL as a logical name in the process or job table to point to the copy in the directory of older images. For example:
Images to be translated using DECmigrate should be linked against the
SYS$LIBRARY files of OpenVMS VAX Version 5.5-2 or earlier.
The release notes in this section pertain to the OpenVMS Registry.
For general release notes about the OpenVMS Registry, refer to the
OpenVMS Connectivity Developer Guide, which is installed as part of the COM for OpenVMS
installation process and available on the OpenVMS Documentation
CD-ROM.
The $REGISTRY system service provides a function code, REG$FC_NOTIFY_CHANGE_KEY_VALUE, which you can specify to receive notification when changes are made to a key. Along with this function code, you specify the item code REG$_NOTIFYFILTER to pass or filter certain type changes to the key. This item code is a mask of the types of changes to pass. At this time, only the REG$M_CHANGENAME, REG$M_CHANGELASTSET, and REG$M_CHANGESECURITY mask bits have any effect on which notifications are passed or filtered. The REG$M_CHANGEATTRIBUTES mask bit is currently not supported. For the most part, specifying the REG$M_CHANGENAME, REG$M_CHANGELASTSET, and REG$M_CHANGESECURITY mask bits is equivalent to specifying the REG$M_CHANGEATTRIBUTES mask bit. Any change that would be passed as a change to an attribute would also pass as either a name change, update of a key, or a security descriptor change.
We expect to support notification for attribute changes in a future
version of OpenVMS.
Previous versions of OpenVMS placed restrictions on the size of a data transfer between the $REGISTRY system service and the OpenVMS Registry server. The data transfer restrictions, in turn, placed restrictions on the maximum size of a single block of data that can be stored or retrieved from the Registry database. They also limited the depth of a REG$CP Search command, and placed limits on the number of Advanced Server domain groups of which a user can be a member. These restrictions have been eased in OpenVMS V7.3, but have not been eliminated entirely. Previously the restrictions were approximately 8K bytes transmit (service to server) and approximately 4K bytes receive. The current restriction depends on the setting of the SYSGEN parameter MAXBUF. The range for MAXBUF is 4K to 64K, with a default of 8K. MAXBUF is the maximum allowable size for any single buffered I/O packet. You should be aware that by changing MAXBUF you also affect other areas of the system that perform buffered I/O.
We expect to further ease this restriction in future versions of
OpenVMS.
The following sections contain release notes pertaining to the Compaq
POSIX Threads Library (formerly named DECthreads).
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.
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.
V7.3
The POSIX Threads Library provides enhanced data collection
capabilities to support monitoring and debugging tools. These
capabilities provide support for Visual Threads, a new debugging and
analysis tool for threaded programs on OpenVMS Alpha systems. Visual
Threads, which is licensed with OpenVMS Version 7.3, provides
monitoring, automatic debugging, and performance evaluation of
multithreaded applications. For more information about Visual Threads,
see the OpenVMS Version 7.3 New Features and Documentation Overview.
V7.0
The POSIX 1003.4a, Draft 4 (or "d4") interface of the POSIX Threads
Library is slated for retirement in a future release. Applications that
were written using the POSIX 1003.4a, Draft 4 interface should be
migrated to the new POSIX 1003.1c standard (or "pthread") interface
provided by the POSIX Threads Library. A compatibility mode for the
Draft 4 POSIX 1003.4a interface is provided in this release to help
ease migration. This compatibility mode will be removed in a future
release.
V7.3 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. The OpenVMS Executive can schedule each kernel thread to execute on a separate CPU and, therefore, can execute simultaneously. The number of kernel threads that a single process can create may be further bounded by the value of the SYSGEN parameter MULTITHREAD. In OpenVMS Version 7.3, when running on a Non-Uniform Memory Access (NUMA) platform (for example, GS160), all of the kernel threads created by the threads library are limited to execution on the CPUs that are located in the home Resource Affinity Domain (RAD) of the process. Typically, there are four CPUs in a RAD. When optimizing the performance of a threaded application, you may want to set the MULTITHREAD parameter to four or fewer to ensure that any one process creates no more than four kernel threads.
If a process creates more than four kernel threads, all of those kernel
threads compete for the four (say) CPUs within the process's home RAD.
At best, little or no gain would be realized, while in fact performance
could decrease due to extra scheduling overhead.
V7.0
The metering capability of the POSIX Threads Library debugger does not
work in this release.
V7.0
When errno is accessed from the OpenVMS Debugger, the value of
the global errno (not the per-thread errno) is returned. (This is not a
new condition; it just has not been documented previously.)
The OpenVMS Debugger command SET TASK/ACTIVE does not work either for the POSIX Threads Library (on both OpenVMS Alpha and VAX systems) or for Compaq Ada for OpenVMS Alpha systems, the tasking for which is implemented using the POSIX Threads Library. Instead, you can use the following effective substitutes on the POSIX Threads Library:
6.21 Privileged Interfaces and Data Structures (Alpha Only)
This section contains release notes concerning privileged code and data
structures.
V7.2 The security information previously stored in several data structures has moved to a new Persona Security Block (PSB) data structure, making the relevant fields in those structures obsolete in OpenVMS Version 7.2. The affected structures include the Access Rights Block (ARB), Process Control Block (PCB), Process Header Descriptor (PHD), Job Information Block (JIB), and Process Control (CTL) region fields. Table 6-1 shows the obsolete data cells and where the information in those cells has moved. For single persona execution within a process, the obsolete data cells are maintained for backward compatibility. The cells are not maintained while a process is executing with multiple user-level personae (because any code checking the old cells would likely make the wrong security decision).
Backward compatibility of the obsolete data cells may not be maintained in future releases of OpenVMS. Writers of privileged code are encouraged to search for the obsolete symbols in their code and make the necessary modifications to remove the code's dependence on the obsolete cells, and to obtain the information from the new locations.
1OpenVMS Version 7.2 does not maintain the structures to support MAC (mandatory access checking) in a level B1 security environment. 2Security information within this cell is not backward compatible because the JIB is shared among all processes in a job tree.
|