| Previous | Contents |
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.32.4 C Language Compilation Header File Changes
V7.3-2
The following changes have been made in OpenVMS Version 7.3-2:
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.32.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.32.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.32.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.33 RTL Library (LIB$)
The following notes pertain to the LIB$ run-time library.
5.33.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.33.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.34 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
| access: | write-only |
| mechanism: | by reference, array reference |
| 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
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.35.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:
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.35.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.35.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.36 System Services
The following notes pertain to OpenVMS system services.
5.37 Timer Queue Entries (TQEs)
Permanent Restriction
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.38 Watchpoint Utility (I64 Only)
V8.2
The Watchpoint Utility has not been ported to OpenVMS I64. HP intends
to port this utility in a future release.
5.39 Whole Program Floating-Point Mode (I64 Only)
V8.3
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:
5.40 HP OpenVMS Debugger Heap Analyzer Conditions and Workarounds (I64 only)
Condition: The Heap Analyzer startup and the Heap Analyzer START command on the I64 kept debugger (START HEAP_ANALYZER) hangs for threaded applications with upcalls enabled.
Workaround: For threaded or AST-involved applications, HP strongly recommends that you either start the Heap Analyzer before setting up any debug events or after disabling or canceling those events. (You can enable/reset events after the Heap Analyzer startup and START returns you to debugger control.)
This chapter contains information about the following hardware products:
A few notes about using device drivers are also included at the end of
this appendix.
6.1 MP and BMC Console Restrictions (I64 Only)
The following notes pertain to the MP and BMC consoles.
6.1.1 Input, Output, and Error Device Restriction
V8.2
Currently, the OpenVMS operating system requires that the input, output, and error devices for each MP or BMC console point to a single serial-line console. If your system has an MP console, that is preferable.
If you do not boot from the designated console, a warning is sent to the VMS_LOADER, and you might see other errors during the boot. You might also lose output that you would normally expect to see when booting.
6.1.2 Remapping Ctrl/H to the Delete Key
V8.2
Unlike the OpenVMS operating system, which uses the character 0X7F for DEL/RUBOUT, the MP and BMC consoles and the EFI console environment use Ctrl/H. If you press the delete key on a VTxxx terminal, or if you press a key you have mapped to send 0X7F in your terminal emulator, no character is deleted.
Note: The driver does not perform remapping under the following conditions:
The following sections contain information specific to the AlphaServer
2100 series computer.
6.2.1 Console Display
V7.2
On AlphaServer 2100 and 2100A systems, a console display similar to the following is normal and does not represent system errors:
P00>>>SET CONSOLE SERIAL P00>>>INIT VMS PALcode X5.48-112, OSF PALcode X1.35-81 starting console on CPU 0 initialized idle PCB initializing semaphores initializing heap initial heap 1c0c0 memory low limit = 132000 heap = 1c0c0, 13fc0 . . . probing hose 0, PCI probing PCI-to-EISA bridge, bus 1 probing PCI-to-PCI bridge, bus 2 *** unable to assign PCI base address *** bus 2, slot 7, function 0, size 00001000 (16 bit I/O) bus 1, slot 1 -- fra -- DEFEA bus 1, slot 2 -- vga -- Compaq Qvision bus 1, slot 3 -- pua -- KFESA bus 2, slot 1 -- pka -- NCR 53C810 bus 2, slot 6 -- pkb -- NCR 53C810 bus 2, slot 7 -- pkc -- DEC KZPSA bus 0, slot 7 -- ewa -- DECchip 21041-AA initializing keyboard Memory Testing and Configuration Status Module Size Base Addr Intlv Mode Intlv Unit Status ------ ----- --------- ---------- ---------- ------ 0 64MB 00000000 1-Way 0 Passed Total Bad Pages 0 Testing the System Testing the Disks (read only) Testing the Network econfig: 20041 99 econfig: 20042 04 econfig: 20043 00 AlphaServer 2100A Console V4.3-130, built on Oct 26 1996 at 19:44:57 P00>>>P |
Note that in the previous display, the KZPSA adapter is successfully installed despite the error message displayed in the following lines:
*** unable to assign PCI base address *** bus 2, slot 7, function 0, size 00001000 (16 bit I/O) |
The Adaptec 1740/1742 SCSI controller (PB2HA--SA) is not supported on AlphaServer 2100 systems having more than 1 gigabyte (GB) of memory. If the controller is connected to such a system, the following message appears on the operator's console:
%PKJDRVR-E- The direct DMA window does not map all of memory. Port is going OFFLINE. |
V7.2
The error log buffer size is controlled by the system parameter
ERLBUFFERPAGES, which has a maximum value of 32 pagelets. If the Field
Replaceable Unit (FRU) table exceeds this limit during a boot of the
OpenVMS Alpha operating system on an AlphaServer 8200/8400 or 4100
system, an entry will not be written to the error log file.
6.4 AlphaServer ES47/ES80/GS1280 Systems
This section contains release notes of interest to users of AlphaServer
ES47/ES80/GS1280 systems. The note in Section 6.5.2 also applies to
these systems.
6.4.1 INIT Console Command Usage on ES47/ES80/GS1280 Soft Partitions
V8.2
Usage of the INIT console command on ES47/ES80/GS1280 soft partitions is not supported when other instances within the hard partition are booted and running OpenVMS. Issuing an INIT command might result in system crashes of the other instances running OpenVMS. Shut down the other instances prior to performing an INIT command.
While a console INIT is in progress, do not issue boot commands to other instances within the same hard partition; wait until the INIT has completed.
| Previous | Next | Contents |