| Previous | Contents |
The following fixes have been made to iconv function/utility:
Many I/O subsystem components synchronize their operations across CPUs by using the IOLOCK8 spinlock, which has made acquiring the spinlock a performance bottleneck. As of 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 of 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. Note that 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 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 so they will not work with the new port drivers. |
The following sections describe corrected problems in the Linker
Utility for OpenVMS I64.
3.8.1 Linker Writes Incorrect Interimage Debug Fixups into Debug Symbol File
In some situations, the linker creates interimage fixups for the OpenVMS debugger. The inter-image debug fixup is a result of compiler-generated debug relocations, which the linker cannot resolve. That is, the debugger requires these fixups to determine a value from a shareable image at run time. Compilers might differ on how often they require the linker to create interimage fixups for the debugger. The C compiler rarely uses inter-image debugger fixups, although the C++ compiler often uses them. When linking such images with the /DEBUG qualifier, the linker writes the debug information followed by the interimage debug fixups. With the /NODSF qualifier (the default) the information is written correctly into the image file, but with /DSF the information is sometimes written incorrectly into the DSF file.
For example, the DEBUG informationals and the DEBUG error in the following sample occur because the linker has written the DSF file incorrectly:
$ RUN/DEBUG MINIREF
%DEBUG-I-INFODWARF, error reading Dwarf info: Section 0a extends outside file
%DEBUG-I-INFODWARF, error reading Dwarf info: Section 0c extends outside file
%DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 10 size 17eb
e0 not multiple of 18
%DEBUG-I-INFODWARF, error reading Dwarf info: SHT_VMS_FIXUP section 12 size 17ec
30 not multiple of 18
OpenVMS I64 Debug64 Version V8.3-003
%DEBUG-F-ACCVIO, access violation, reason mask=00, virtual address=000000000014A
000, PC=000000007BD73100, PS=0000001B
%DEBUG-I-INITIAL, Language: C, Module: MINIREF
DBG>
The image file is not affected; it can be executed with the RUN command
without any problem:
$ RUN MINIREF
|
This error is corrected in the OpenVMS Version 8.3-1H1 Linker.
3.8.2 /SELECTIVE_SEARCH Qualifier Might Incorrectly Ignore Transfer Address
If you have an I64 object module containing a transfer address and you
include the module in the link operation with the /SELECTIVE_SEARCH
qualifier, the linker cannot find its transfer address.
In the following example, the object module (MAIN.OBJ) contains a transfer address but /SELECTIVE_SEARCH qualifier ignores it:
$ LINK MAIN/SELECTIVE_SEARCH %ILINK-W-USRTFR, image USER:[JOE]MAIN.EXE;1 has no user transfer address |
This condition happens only when I64 object modules, meant to provide the program's transfer address, are included in the link operation with the SELECTIVE_SEARCH attribute. The SELECTIVE_SEARCH attribute is given to an object module when you specify the /SELECTIVE_SEARCH qualifier to the object module in the LINK command or in a LIBRARY command.
For example:
$ LINK MAIN/SELECTIVE_SEARCH |
or
$ LIBRARY/INSERT LIB.OLB MAIN.OBJ/SELECTIVE_SEARCH |
This problem manifests itself in one of two ways:
For more than 65280 sections, the ELF format uses an extended numbering scheme, which was not implemented in the linker on OpenVMS I64 Version 8.3. As a result, the number of sections that a single input object module or shareable image can have was limited. Because the linker usually creates the shareable images with sections, this limit also applied when you created shareable images. In that case, ELF sections were used for exporting C++ templates or shared sections. That is, the maximum number of such interfaces in a shareable image had to be fewer than 65280.
In the OpenVMS Version 8.3-1H1 Linker, this restriction is removed. An
input file, an object module or a shareable image can have more than
65280 sections.
3.8.4 Incorrect Creation Date of Shareable Images in the Map File
On OpenVMS I64 platforms, shareable images sometimes showed an incorrect creation date in the linker map. The incorrect date shown was usually 3686. This condition occurred when the linker processed the shareable image as an input file and then extracted the date field, which was then shown in the map. The image itself had the correct date that you can see from ANALYZE/IMAGE output.
This error is corrected in the OpenVMS Version 8.3-1H1 Linker.
3.8.5 Demangler Information Look Up Results in Linker Access Violation
In some cases, when the linker tried to look up demangler information in a shareable image that did not contain such information, the linker aborted with an access violoation.
This problem is corrected in the OpenVMS V8.3-1H1 Linker.
3.8.6 Incorrect Secondary Messages for the NOGLOSYM Error Message
For the NOGLOSYM error message, the OpenVMS Version 8.3 Linker printed the wrong relocation type and printed some information twice.
This problem is corrected in OpenVMS Version 8.3-1H1.
3.8.7 Incorrect Information for Undefined Symbols
For undefined symbols, a USEUNDEF operation sometimes incorrectly showed information twice for the same reference. The problem occurred when the compiler generated a pair of relocations (LTOFF22X/LDXMOV) for the reference to an undefined symbol.
This problem is corrected in OpenVMS Version 8.3-1H1.
3.8.8 Incorrect UNMAPFIL Error
If a non-ELF input file was encountered, the linker printed an INVLDHDR error message. After an INVLDHDR error, an incorrect UNMAPFIL error message was printed.
This problem is corrected in OpenVMS Version 8.3-1H1.
3.8.9 Max Ident Length Change for Shareable Images in Map
In the linker map, the linker printed up to 14 characters of the ident from object modules and shareable images. (The maximum length of an ident for an object module is not limited; the maximum length of an ident for a shareable images is 15.)
The Version 8.3-1H1 linker now prints up to 15 characters as the
maximum of the ident for a shareable image.
3.8.10 Linkage Type Check for Shareable Images
Previously, the linker did not check the type and linkage for symbols from shareable images.
OpenVMS Version 8.3-1H1 Linker now performs this check.
3.8.11 Program Section Attribute ABS Ignored
On I64 systems, you cannot set the ABS attribute to a program section that contains labels to convert its offsets to constants. The linker prints the error message:
%ILINK-E-ILLABSPSC, absolute psect <psect-name> has non-zero length (not allowed) |
The OpenVMS 8.3-1H1 Linker ignores the ABS program sectoin attribute and prints the following informational message:
%ILINK-I-PSCATTIGN, psect attribute ABS is not supported for OpenVMS ELF sections, attribute ignored |
In the Version 8.3, the I64 Linker encountered an access violation when the FP_MODE literal was missing on the the command line.
This problem is corrected in OpenVMS Version 8.3-1H1.
3.9 Analyze Utility for OpenVMS
The following sections describe corrected problems in the Analyze
Utility for OpenVMS.
3.9.1 Unwind Data Display Problem Corrected
In OpenVMS Version 8.3, the analyze utility (ANALYZE) showed unwind data twice: once as raw data and again as formatted data. If you selected the segment with unwind data (using the segment number or the ALL keyword), ANALYZE displayed the raw data. ANALYZE displayed only the formatted data, however, if you selected the dynamic segment using segment number along with the ALL or the DYNAMIC keyword.
This problem is corrected in OpenVMS Version 8.3-1H1. The formatted unwind data now appears with the segment.
To avoid formatting the same data twice, ANALYZE no longer shows the unwind information with the dynamic segment. To make the selecting of unwind data easier, ANALYZE allows the UNWIND keyword for the /SEGMENT qualifier.
For equivalent output as the former command for unwind information,
/SEGMENT=DYNAMIC
, use the
/SEGMENT=(DYNAMIC,UNWIND)
command. Note that if there are multiple segments with unwind data, the
/SEGMENT=UNWIND
command formats all of them.
3.9.2 Formatted Symbol Vector Correctly Shown in Data Segement
Previously, the symbol vector summary information did not indicate the segment in which the symbol vector resided. The symbol vector was formatted only in the dynamic segment.
This problem is fixed in OpenVMS Version 8.3-1H1. The formatted symbol vector now appears with the data segment in which it is contained. The formatted symbol vector is embedded in data and visible in a dump of the data.
To avoid formatting the same data twice, the symbol vector is no longer shown with the dynamic segment. To make formatting of the symbol vector easy, the SYMBOL_VECTOR keyword is allowed for the /SEGMENT qualifier. When you specify this keyword, the resulting output is only the formatted symbol vector. The surrounding data are not shown. To show and format all of the data, select the segment by number.
To get equivalent output for the former command /SEGMENT=DYNAMIC for symbol vectors, use the /SEGMENT=(DYNAMIC,SYMBOL_VECTOR) qualifier.
The summary information shows the name of the data segment that
contains the symbol vector.
3.9.3 Transfer Array Now Formatted in Data Segment
Previously, if you selected the data segment that contained the transfer array (either by segment number or with the ALL keyword), the transfer array was not formatted. Information about the transfer array was shown only in the summary.
This problem is corrected in OpenVMS Version 8.3-1H1. The formatted
tranfer array now appears in the data segment.
3.9.4 System Version Array Now Formatted in Dynamic Segment
System version data is in the dynamic segment. Previously, if you selected the dynamic segment (either by segment number, or with the ALL or DYNAMIC keyword), the system version array was not shown. Information about the system version array was only shown in the summary.
This problem is corrected in OpenVMS Version 8.3-1H1. The formatted
system version array now appears in the dynamic segment.
3.9.5 Enhancements for the /SEGMENT Qualifier
Enhancements have been made to the /SEGMENT qualifier for dynamic segments. Analyze has been enhanced to accept keywords for the /SEGMENT=DYNAMIC qualifier to provide customized information. The keywords for selectable information are:
The default, /SEGMENT=ALL, formats all of the image information.
Note that formatting using the TAGS keyword includes the names of the
needed images, so you do not have to add IMAGE_STRINGS to print the
names.
3.9.6 Support for Section Escaping Added
On OpenVMS V8.3, the Analyze utility did not complete when analyzing an object module with more than 65,280 sections. Instead, it looped when attempting to print the section header table.
This problem has been fixed in OpenVMS V8.3-1H1.
3.10 INSTALL Utility for OpenVMS (Installing Resident Images in S2 Space)
The INSTALL utility now supports installing code segments of resident images into 64-bit S2 address space. Not all code can run in a full 64-bit address space (P2 or S2). For example, the code must be prepared for 64-bit PCs when handling exceptions. Also, some compilers require the /POINTER_SIZE=64 command qualifier, when generating code, suitable for a 64-bit address space.
To avoid mapping unprepared code in S2 space, the INSTALL utility by default will continue to map the code segments in S0/S1 space. The INSTALL utility will map code segments of resident images to S2 if two conditions are met:
The Librarian Utility now has the following enhancement.
3.11.1 Support for Section Escaping
Previously, object modules with more than 65,280 sections could not be added to an object library. The Librarian aborted with an error message:
$ LIBRARIAN/CREATE MYLIB 64K_SECTIONS %LIBRAR-E-REPLACERR, error replacing USER$DISK:[JOE]64K_SECTIONS.OBJ;1 in USER$DISK:[JOE]MYLIB.OLB;1 $ |
This condition is corrected in OpenVMS Version 8.3-1H1. Support for
section escaping has been added for OpenVMS Version 8.3-1H1.
3.12 InfoServer Utility and FDDI
Using the InfoServer utility on OpenVMS to boot a client over an FDDI
network adapter is not supported.
3.13 New Qualifier for DCL Command SET PASSWORD
The DCL command SET PASSWORD now accepts the /PROMPT qualifier with two
permitted values: /PROMPT=FIXED and /PROMPT=VARIABLE. If you use the
SET PASSWORD command in a DCL command procedure, do not specify the
/PROMPT=VARIABLE qualifier. If you do, it works as expected, but any
failing status is only displayed and not returned to DCL.
3.14 INITIALIZE/ERASE=INIT Before Using Media
HP recommends that you issue the DCL command INITIALIZE/ERASE=INIT on storage media prior to using them for the first time. This eliminates any stale data that was left from previous use by another operating system or diagnostics.
An indication of such stale data is three questions marks (???) in the console command output, as shown in the following example:
Shell> ls fs1:\
Directory of: fs1:\
00/00/07 19:16p 1,788,984,016 ???
00/00/80 12:00a 0 ???
2 File(s) 1,788,984,016 bytes
0 Dir(s)
The problem will be corrected in a future release.
|
The XML-C product for OpenVMS for Integrity servers is delivered as a
ZIP file that contains a self-extracting executable file. The XML-C
installation documentation describes how to install the product by
using this executable file. To obtain the executable file, extract it
from the ZIP file.
3.16 Using the OpenVMS e-Business and Integration Infrastructure Package
The OpenVMS e-Business and Integration Infrastructure Package for OpenVMS is contained on two CDs that are formatted so that they appear as a Files-11 file structure to an OpenVMS system and an ISO 9660 file structure to a Windows, Linux, or UNIX system.
Installation
The component installation kits and documentation are split across the two CDs. Component installation can be done only on an OpenVMS Alpha system from the specific CD designated in the top-level index.html file.
Documentation
For OpenVMS systems, partial component documentation is viewable based on which CD is mounted for use. Component documentation is available only for the components present on the specific CD.
For Windows, Linux, or UNIX systems, complete component documentation
is viewable on both CDs.
3.17 Performance Data Collector for OpenVMS (TDC)
TDC_RT Version 2.2-107 is included in the OpenVMS Version 8.3--1H1 installation. An update to TDC Version 2.2-108 is now available from the TDC Web site at:
http://www.hp.com/products/openvms/tdc/ |
TDC Version 2.2-108 corrects several issues discovered in TDC_RT
Version 2.2-107. It also enables collection of internet metrics in
TCPware and MultiNet environments, adds additional metrics to several
data records, and provides new programming features and sample code in
the TDC Software Developers Kit.
3.18 C++ Compiler
C++ Version 7.2 for OpenVMS for Integrity servers predefines the macro __INITIAL_POINTER_SIZE to 0, unlike C++ Version 7.1 compiler, which leaves it undefined. This is an intentional change that makes C++ Version 7.2 consistent with the C compiler and provides support for pointer_size pragmas, while C++ Version 7.1 does not.
Note that 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 __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.
3.19 Building DCE IDL C++ Applications
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.
3.20 CDSA Errors During Installation
You might see the following errors when upgrading to OpenVMS Version 8.3-1H1. You can safely ignore these errors because CDSA and Secure Delivery will still function properly and PCSI kits will install normally and securely.
CDSA-I-Init, CDSA has previously been initialized on this system. CDSA-I-Init, Re-initializing CDSA. CDSA-I-Init, Initializing CDSA MDS installed successfully. Module installed successfully. Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (Clean): 300A (Code #300A)! Module: MDS Error (common-DL): 300A (Code #300A)! Module installed successfully. Module: MDS Error (common-DL): 300A (Code #300A)! CDSA-I-Init, CDSA Initialization complete CDSA-I-Init, Initializing Secure Delivery. Install completed successfully. Module: MDS Error (Clean): 300A (Code #300A)! Module installed successfully. CDSA-I-Init, Secure Delivery Initialization complete |
| Previous | Next | Contents |