HP OpenVMS Systems Documentation

HP OpenVMS Version 8.3--1H1
for Integrity Servers
New Features and Release Notes

This chapter contains the OpenVMS Version 8.3--1H1 release notes. Because most of the OpenVMS Version 8.3 release notes still apply, read the release notes that apply to OpenVMS I64 (that is, all notes not marked "Alpha only") in the HP OpenVMS Version 8.3 Release Notes manual as well as the notes in this chapter before installing or upgrading your system.

Additionally, for further information on booting the system, see Section 1.8.

3.1 OpenVMS Version 8.3-1H1 System Parameters

The following sections describe obsolete, renamed, and new system parameters for OpenVMS 8.3--1H1.

3.1.1 Obsolete Parameters

Table 3-1 lists system parameters that are obsolete in OpenVMS Version 8.3-1H1. The following sections contain information on the replacement parameters.

The following system parameter has been renamed and supplemented in OpenVMS Version 8.3--1H1. Table 3-2 contains additional information about the new parameters.

3.1.3 New Parameter

Only images linked with the /SEGMENT=CODE=P2 qualifier can have code placed in this region. See the HP OpenVMS Linker Utility Manual and the INSTALL utility in the HP OpenVMS System Manager's Manual for more information.

GH_RES_CODE has the AUTOGEN and FEEDBACK attributes.

3.1.4 Failure of AUDIT_SERVER to Initiate During Boot

During boot, if the AUDIT_SERVER fails to initiate for any reason, the startup process enters a retry loop that attempts to restart the AUDIT_SERVER until the condition preventing the initiate to complete is cleared and AUDIT_SERVER initiates correctly. This behavior is deliberate and is designed to prevent the system from running in an incomplete security state.

Conditions that can prevent complete initiation include the following:

• Invalid journal file specification in the audit server database.
• Corrupt Audit Server database (SYS$MANAGER:VMS$AUDIT_SERVER.DAT).
• Corrupt Object Server database (SYS$SYSTEM:.VMS$OBJECTS.DAT)
• Failed access to target disk
• Failure to synchronize with other Audit Servers on the cluster
• Required resources being held by other Audit Servers on the cluster

Clearing the condition might require manual intervention. The action required depends on the fault source. Corrective action can include restarting the AUDIT_SERVER processes on other cluster nodes or rebooting the affected node in MINIMUM state and manually correcting the fault. Corrupt database files can be identified by renaming the files and then restarting the AUDIT_SERVER. The server recreates these files and populates them with system default entries.

For more information about booting options, refer to Chapter 4 of the HP OpenVMS System Management Utilities Reference Manual.

3.2 C Run-Time Library

Problems corrected in OpenVMS Version 8.3-1H1 include the following:

• The run-time library had faulty code that accessed memory just freed to advance a pointer. In multithreaded code, another thread could reuse that memory before the original thread could advance its pointer. This has been fixed by updating accesses prior to freeing pointers.
• A new processwide exception processing mode--- pure_unix --- has been introduced. In this mode, non-C++ exceptions, also known as OpenVMS conditions, cannot be caught in a C++ catch-all handler. This mode can be requested by calling cxxl$set_condition(condition_behavior) with a pure_unix argument:

  cxxl$set_condition(pure_unix); condition_behavior enum declared in <cxx_exception.h> header has been extended to include pure_unix member.

  
  To demonstrate how pure_unix mode works, consider the following program sample. As it is written, the program crashes with ACCVIO. If the call to cxxl$set_condition() is commented out, the program outputs "caught" and exits:

  #include <stdio.h> #include <cxx_exception.h> void generateACCVIO() { *((int*)0) = 0; } int main() { cxxl$set_condition(pure_unix); try { generateACCVIO(); } catch(...) { puts("caught"); } }

  Note 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).

• The run-time library sometimes failed to destruct objects of automatic storage duration defined in a function, if such a function exited via an exception that could be caught. This problem has been fixed.
• The run-time library now allows the thread cancel signal (CMA$_ALERTED) and the thread exit signal (CMA$_EXIT_THREAD) to be caught in a catch handler with a pointer or a reference to type CXXL$PTHREAD_CANCEL (or CX6L$PTHREAD_CANCEL) and CXXL$PTHREAD_EXIT (or CX6L$PTHREAD_EXIT), respectively, if catching the signals are enabled. The new types catch these signals exclusively.

  Note 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 C++ RTL has changed its internal mapping of SIGTRAP from SS$_BREAK to SS$_TBIT, to match a recent CRTL change.
• The C++ RTL used to call std::terminate() when a destructor raised an exception during stack unwinding, even if that destructor did not exit via the exception. This problem has been fixed.
• The C++ RTL used to call std::terminate() , if a foreign exception (such as a non-C++ OpenVMS condition) was raised while a C++ exception was being processed. This behavior has been refined to calling std::terminate() only if the raised OpenVMS condition also leads to unwinding the stack.
• Because OpenVMS conditions can be caught in C++ catch handlers, the C++ RTL converts the conditions to an internal format that matches the representation of C++ exceptions. This conversion would sometimes lead to incorrect information being shown in the traceback. This problem has been fixed.

The following problems are fixed in this version of the C++ Library (Version 7.3 and higher compiler):

• As described in http://issues.apache.org/jira/browse/STDCXX-397 (the Apache Software Foundation Issues website), the __introsort_loop() function in <algorithm.cc> header has a bug which, for some input sequences, can adversely affect performance of std::sort . For more information, see the Apache tracker for the issue STDCXX-397 at http://issues.apache.org/jira/browse/STDCXX-397.
  The bug has been fixed. However, for some input sequences, the fix can change the behavior of std::sort with regard to the relative order in which elements that have equivalent ordering are placed into the sorted sequence. Though this change in behavior is permissible because, unlike std::stable_sort , std::sort does not guarantee any particular relative order of elements having equivalent ordering, to avoid breaking applications that rely on existing behaviour of std::sort , the fix is conditionalized with __RW_ FIX_APACHE_STDCXX_397 macro. The fix is in effect only when the program is compiled with this macro defined.
• When compiled in standard GNU mode, the library now defines the _RWSTD_NO_IMPLICIT_INCLUSION macro, which causes library headers to include their respective template definition files. This is necessary because in standard GNU mode, implicit inclusion is disabled.
  Before this change, the program below would link with undefined symbol when compiled in standard GNU mode:

  #include <vector> int main() { std::vector<int> v; v.push_back(0); }

• According to section 27.6.1.3 [lib.istream.unformatted] of the C++ Standard, the following get member functions of the std::basic_istream class should call setstate(failbit) if no characters have been stored, as is the case for an empty line. While on I64 systems the functions set failbit, on Alpha systems they do not, for example:

  istream_type& get(char_type *s, streamsize n, char_type delim); istream_type& get(char_type *s, streamsize n);

On certain Integrity configurations, typing Ctrl/P at the console does not cause OpenVMS to display the IPC (Interrupt Priority C) menu. If you plan to use Ctrl/P, you should test it to ensure that it works, after installing or upgrading to OpenVMS Version 8.3-1H1.

If necessary, you can restore Ctrl/P functionality by performing the following steps:

1. Invoke SDA to analyze the running system:

   $ ANALYZE/SYSTEM

2. Use the CLUE CONFIG to display the adapters on the system:

   SDA> CLUE CONFIG/ADAPTER

3. Locate the "Console Serial Line Driver" adapter (SRA:) in the display:

   System Adapter Configuration: ----------------------------- TR Adapter ADP Hose Bus BusArrayEntry Node GSIN iVec SCB -- ----------- ----------------- ---- ----------------------- ---- ---------------- ... 5 ACPI_IA64_I FFFFFFFF.8832E0C0 0 00 IA64_BUS 6 PCI FFFFFFFF.88342A80 9 00 PCI FFFFFFFF.88342E58 0 0018 00DF 15F0 FFFFFFFF.88342F68 8 0018 00DF 15F0 ... Port Slot Device Name/HW-Id ---- ---- ----------------------- SRA: 0 Console Serial Line Driver EWA: 1 A6865A (Fast Ethernet)

4. Identify the controller that shares the same GSIN (Global System Interrupt Number) as SRA:. In this example, it is EWA:.
5. Exit from SDA and enter the following command (substituting EWA with the correct controller):

   $ SET DEVICE EWA0/PREFERRED_CPUS='F$GETSYI("PRIMARY_CPUID")'

When you complete these steps, Ctrl/P should now function correctly. HP recommends that you edit SYS$MANAGER:SYLOGICALS.COM to include the SET DEVICE command to ensure correct behavior when the system reboots. Note that Ctrl/P might stop working again if you add or remove I/O adapters. If this happens, redo the steps listed above.

Note also that if XDELTA or the System Code Debugger has been loaded when the system was booted, Ctrl/P is not affected. Entering Ctrl/P will cause the XDELTA prompt to be displayed, for example:

 Console Brk at 807CF3D2 on CPU 0

 807CF3D2!            cmp4.lt     p0, p6 = 3F, r4  (New IPL = 3)

HP hopes to provide a fix to this problem shortly with an ECO kit.

3.3 Encryption Issues and Resolutions

The following sections describe corrected and known issues in the Encrypt utility for OpenVMS V8.3-1H1.

3.3.1 PARSE=EXTENDED

Previously, a problem existed with Encrypt version V2.0 where %ENCRYPT-F-KEYLENERR errors were reported if the process parse style was set to extended. This usually occurred when specifying the algorithm with the /KEY_ALGORITHM or the /DATA_ALGORITHM encrypt command qualifiers, which may result in causing a modify access ACCVIO error.

This problem has been corrected in OpenVMS Version 8.3-1H1.

3.3.2 Large File Encryption

Previously, a problem existed where Encrypt could not encrypt file larger than 4,194,303 blocks (2,147,483,136 bytes). Encrypt immediately returned to the command prompt with no error message, leading the user to believe that the file was properly encrypted. A CRC error warning would result when attempting to decrypt the corrupted encrypted file.

This problem has been corrected in OpenVMS Version 8.3-1H1.

3.3.3 Input/Output File Performance

A problem has been addressed that corrects Encrypt's I/O performance. This performance was substantially improved (approximately 40x) using multiple buffered reads and multibuffered, multiple writes using $QIO, eliminating two levels of caching (RMS and XFC) over the single RMS block I/O $READ and $WRITE. This results in improved performance, especially with larger files, and improved CPU utilization and less I/O latency between I/Os. This also decreases overall encryption, decryption, and I/O operation completion time.

3.3.4 ENCYPT/COMPRESS Issue

A problem exists with all versions of Encrypt when using ENCRYPT/COMPRESS with certain file types, notably .BCK and .EXE files. The problem occurs when trying to recover the original (plain-text) data with the DECRYPT command. A key record CRC or another error can occur. The actual encrypted data is incorrect, but no error occurs until decryption.

The problem is potentially serious if the /DELETE qualifier is used when encrypting, because the original file is deleted. The original file can also be lost if the /OUTPUT=file-spec were not used when encrypting and a PURGE command were used.

The /COMPRESS qualifier has been deprecated, disabling its use with Encrypt until HP can resolve this issue. Decryption of compressed files will continue to work normally.

3.4 Documentation Corrections

The following sections describe corrections to various manuals in the OpenVMS documentation set.

3.5 GiCAP Functionality Not Currently Available

While running SYS$MANAGER:ICAP$CONFIG.COM, if you respond "Y" to the "Enter (Y)es to configure this system with GiCAP support (N):" prompt, the following message is displayed:

                   HP OpenVMS Industry Standard 64

    Global Instant Capacity on Demand (GiCAP) configuration utility

        *** GiCAP functionality is not currently available ***

     *** GiCAP will be enabled at a later date via an ECO kit ***

Also, note that the release notes for iCAP (Instant Capacity) specify GiCAP support for OpenVMS Version 8.3--1H1. This support is not available currently, but will be available in a future update kit. For more information, see the OpenVMS website.

3.6 Iconv Fixes

The following fixes have been made to iconv function/utility:

• Previously, iconv() does not handle NULL parameters on input. This problem has been corrected.
• The iconv converters for DEC Korean can convert to and from Unicode (UCS-2/UCS-4/UCS-8) correctly.

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

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

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:

• The linker displays a warning message. This condition occurs if no other object module in the link operation provides a transfer address, weak or otherwise.
• The linker does not display a message. This condition occurs if other object modules in the link operation provide a transfer address, weak or otherwise. If the linker fails to properly identify the transfer address from the selectively searched object module, it selects one from the other object modules. That transfer address becomes the main entry point for the image. Even though the map file does indicate the incorrect transfer module and transfer address the linker has assigned, the problem might not become evident until you actually run your application.
  This error is corrected in the OpenVMS Version 8.3-1H1 Linker.