HP OpenVMS Systems Documentation

HP OpenVMS Version 8.2 Release Notes

V8.2

This note supplements information in the HP OpenVMS Calling Standard.

The Calling Standard invocation context block (ICB) (see Table 4-16 in the HP OpenVMS Calling Standard) and mechanism vector (see Figure 8-7 and Table 8-6 in the HP OpenVMS Calling Standard) 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 (see Section 4.8.3.13 in the HP OpenVMS Calling Standard), 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 (see Section 4.8.4 in the HP OpenVMS Calling Standard) 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.10 Common Data Security Architecture (CDSA) Considerations

The following notes pertain to CDSA.

5.10.1 Secure Delivery Advanced Developer's Kit

V8.2

Downloading of files over the Internet is becoming a requirement of OpenVMS customers who want to use this easy and convenient method to acquire software updates, but are wary of the security vulnerabilities. Secure Delivery makes use of public key and digital signature technology to implement a system that provides OpenVMS users with the ability to authenticate and validate the files they download from OpenVMS and third party OpenVMS vendors.

The preliminary documentation for Secure Delivery can be found on the following website:

This documentation provides an overview of Secure Delivery on OpenVMS, and how to invoke its components. Secure Delivery is provided as an Advanced Developer's Kit (ADK) with OpenVMS Version 8.2, and is planned to be fully supported in a subsequent release of the operating system. With the exception of a future tie-in to PCSI for automatic verification of software kits, all of the Secure Delivery functionality is present in OpenVMS Version 8.2.

5.10.2 Installation and Initialization Considerations

V7.3-2

Installation of CDSA is done automatically when you install the operating system. However, you must be aware of the following considerations:

• Although the CDSA installation is part of the OpenVMS Version 7.3-2 (and later) installation, the setup and initialization of CDSA must be performed separately. Before you can use CDSA, you must perform the following manual procedure. You need the SYSPRV privilege to run this procedure. Enter the following command:

  $ @SYS$STARTUP:CDSA$INITIALIZE

  
  When a new version of CDSA is installed (for example, in an upgrade from field test to a production version, or to a new version of OpenVMS), you must run the CDSA upgrade procedure (@SYS$STARTUP:CDSA$UPGRADE). You should shut down any CDSA application before you run the upgrade procedure.
  It is not necessary to rerun the initialization or upgrade procedures when the system is rebooted. You also do not need to add the initialization or upgrade procedures to the OpenVMS startup procedures.
• Do not attempt to remove CDSA from your system. Use of the PCSI command PRODUCT REMOVE is not supported for CDSA, even though there is an apparent option to remove CDSA. (This option is due to the use of PCSI in the installation.) CDSA is installed together with the operating system and is tightly bound with it. An attempt to remove it from OpenVMS will not work cleanly and could create other undesirable effects. An attempt to remove CDSA will result in a message similar to the following:

  %PCSI-E-HRDREF, product CPQ AXPVMS CDSA Vn.n is referenced by DEC AXPVMS OPENVMS V8.2 -PCSI-E-HRDRF1, the two products are tightly bound by this software dependency

V7.3

This potential change in behavior is restricted to a CONVERT command that specifies both the /NOSORT qualifier and a collated key type on one of the keys in the output file.

The /NOSORT qualifier on a CONVERT command indicates that the primary key is already in sorted order in the input file and directs the Convert utility not to sort it. Prior to OpenVMS Version 7.3, the Convert utility had a defect that caused it to always sort the input file if some key specified for the output file had a collated key type, regardless of whether /NOSORT was specified. As of OpenVMS Version 7.3, the Convert utility has been fixed to appropriately obey the /NOSORT qualifier on the command line, even if one of the keys in the output file is a collated key.

This means that a convert operation that previously succeeded as a side-effect of the collated key defect may now produce %CONVERT-I-SEQ messages if the input file is not already in sorted order by the primary key and /NOSORT is specified on the command line. The /NOSORT qualifier should not be used if the input file is not already in sorted order by the primary key.

5.12 Debugging Modes: Avoiding CPUSPINWAIT Bugchecks

V7.3-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. Specifically, any privileged code that runs for extended periods of time while holding a spinlock can cause a CPU spinwait bugcheck. Spinlocks are used to delineate the entry and exit points for critical sections, and should not be held continuously, as can occur in this situation.

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.

5.13 Delta/XDelta Debuggers

The following release notes pertain to the OpenVMS Delta and XDelta debuggers running on OpenVMS Alpha and I64 systems.

OpenVMS Debugger release notes are in Section 5.28.

5.13.1 Delta Debugger Not Available on OpenVMS I64

V8.2

The Delta debugger has not yet been ported to the OpenVMS I64 operating system.

5.13.2 Restrictions for XDELTA on I64 Systems

V8.2

The following Intel® Itanium® hardware registers are not supported by XDELTA:

• CPUID
• Debug Data Break Registers
• Debug Instruction Break Registers
• Region Registers
• Protection Key Registers
• Instruction Translation Registers
• Data Translation Registers
• Device Interrupt Control Register

V8.2

To interrupt a running system on OpenVMS I64, press Ctrl/P at the system console. Note that XDELTA must have been loaded previously. When you press Ctrl/P, the system is halted at the current PC and at the current IPL. There is no delay in waiting for the IPL to drop below 14, as there is on OpenVMS Alpha systems.

5.13.4 XDELTA Register Display Consideration (I64 only)

V8.2

XDELTA on OpenVMS I64 displays general, floating-point, and predicate registers as if the register rename base (CFM.rrb) and the rotating size (CFM.sor) are both zero. In other words, when rotating registers are in use, the effects of the rotation are ignored. This condition will be corrected in a future release. See Section 5.9 for additional details.

5.14 File Applications: Corrections to Guide to OpenVMS File Applications

V8.2

The following corrections will be made to the Guide to OpenVMS File Applications if this manual is revised in the future.

• Table 1-4 is potentially confusing. In the comparison of file formats, directory limitations are listed as 256 for ODS-2 and ODS-5 file formats. This statement should be clarified to say 256 directory levels so that users do not think directories are limited to 256 files.
  A similar table in the HP OpenVMS System Manager's Manual has been corrected for Version 8.2.
• In Section 6.6.3, replace the fourth paragraph (not counting the note) with the following text:
  "When you define the rooted-device logical name for use in a program in a SET DEFAULT command, you specify that the logical name is a concealed-device logical name by using the /TRANSLATION_ATTRIBUTES=CONCEALED qualifier with the DCL command DEFINE or ASSIGN. To define the concealed-device logical name as a rooted-device logical name, the root directory must contain a trailing period (.), such as DUA22:[ROOT.] and the device specification must be a physical device name. The equivalence name for a rooted-device logical name must not contain other logical names. When specifying a directory, you can use only a trailing period for the root directory."

V8.2

Quadword alignment has been added to the BLISS macros ($xxx_DECL) that can be used to allocate RMS user structures (for example, FAB, RAB). Alignment faults are costly to performance---especially as processors get faster. By implementing the alignment directly in the macros, a number of OpenVMS utilities and user applications written in BLISS that use these macros show improved performance.

The specific names of the macros are: $FAB_DECL, $NAM_DECL, $NAML_DECL, $RAB_DECL, $RAB64_DECL, $XABALL_DECL, $XABDAT_DECL, $XABFHC_DECL, $XABITM_DECL, $XABJNL_DECL, $XABKEY_DECL, $XABPRO_DECL, $XABRDT_DECL, $XABRU_DECL, $XABTRM_DECL, and $XABSUM_DECL.

The alignment added in the RMS macros might result in compiler warnings of conflicting alignment. Programs with compiler warnings should link and execute correctly. However, the minor source changes to eliminate the warnings are recommended.

If you use any of these macros in a BLISS application and the declaration includes the ALIGN attribute, the BLISS compiler issues a "conflicting or multiply specified attribute" warning. For example, the warning is issued for the following declaration: FAB: $FAB_DECL ALIGN(2). The compiler also issues this warning even if quadword alignment (ALIGN(3)) is specified. You should remove any explicit ALIGN attributes associated with these macros.

In addition, if any of these allocations is included in a PSECT that contains an explicit alignment that is in conflict with ALIGN(3) (that is, is lower than ALIGN(3)), the BLISS compiler issues an "align request negative or exceeds that of psect" warning. For example, the warning would be issued for the following declaration:

 PSECT OWN = $OWN$ (..., ALIGN(2), ...)

 OWN

     FAB = $FAB_DECL, ...

If warnings on PSECT alignment are seen when recompiling a BLISS application, the correction is to increase the alignment of the PSECT to ALIGN(3) (or higher). In rare cases, applications may have assumptions on adjacency of data between PSECTs. Those assumptions could be broken in making this change. Therefore, check the code for such assumptions and make any necessary corrections.

While a number of OpenVMS utilities are written in BLISS, only a few warnings were generated in a full OpenVMS build. Changes in OpenVMS to eliminate warnings did not require other changes to correct assumptions. Based on this, few user applications likely will require modification.

5.16 HP COBOL Run-Time Library (RTL)

V8.2

For OpenVMS Alpha and OpenVMS I64 Version 8.2, the HP COBOL RTL (DEC$COBRTL) has been updated to V2.8-775.

5.16.1 SET and COB$SWITCHES

V8.2

The implementation of the COBOL SET verb (implemented using the logical COB$SWITCHES) has been changed to use LNM$PROCESS if the attempt to use the first entry in LNM$FILE_DEV fails. Previously, the COBOL SET verb failed if the first entry in LNM$FILE_DEV was a nonwritable logical name table.

5.16.2 Record Locking Problem Corrected

V8.2

Under certain circumstances with the START or WRITE statement, COBOL used to acquire multiple record locks with automatic record locking. This problem has been fixed.

5.17 HP Decimal Support Run-Time Library (RTL)

V8.2

For OpenVMS Alpha and OpenVMS I64 Version 8.2, the HP Decimal Support RTL (LIBOTS2) has been updated to V2.8-67.

5.18 HP Fortran for I64

V8.2

The OpenVMS I64 Fortran compiler is a port of HP Fortran 90 for OpenVMS Alpha. It runs on OpenVMS I64 systems and produces objects for OpenVMS I64 systems. The objects are linked using the standard linker on OpenVMS I64. This compiler requires OpenVMS I64 Version 8.2.

HP Fortran for OpenVMS I64 systems features the same command-line options and language features as HP Fortran 90 for OpenVMS Alpha systems with the following exceptions:

• Floating-point arithmetic
  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:
  http://h71000.www7.hp.com/openvms/integrity/resources.html
  
• IEEE is the default floating-point datatype (that is, the default is /FLOAT=IEEE_FLOAT).
• The /IEEE_MODE qualifier defaults to /IEEE_MODE=DENORM_RESULTS.
• Users should pick one /FLOAT value and one /IEEE_MODE value and keep it for the whole application.
• Only the F90 compiler is supported. The F77 compiler, previously invoked with the /OLD_F77 qualifier, is not available. Some of the functionality contained in the Alpha F77 compiler that is not available in the Alpha F90 compiler has been implemented in the I64 F90 compiler, including FDML and CDD support. See the Fortran T8.0 product release notes for details.
• Alpha values for the /ARCH and /TUNE qualifiers are accepted on the compiler invocation command for compile-and-go compatibility. An informational message is displayed saying that they are ignored.

For more information about this release, including installation instructions, read the Fortran T8.0 product release notes. To extract the release notes, set your default to the directory that contains the Fortran PCSI kit and enter one of the following commands:

$ PRODUCT EXTRACT RELEASE_NOTES FORTRAN ! For TXT file
$ PRODUCT EXTRACT FILE FORTRAN/SELECT=FORTRAN_RELEASE_NOTES.PS ! For PS file

The OpenVMS MACRO compiler compiles Macro-32 source code written for OpenVMS VAX systems (the VAX MACRO assembler) into machine code that runs on OpenVMS Alpha and OpenVMS I64 systems. The following notes pertain to the MACRO compiler.

5.19.1 HP MACRO for OpenVMS I64

V8.2

The native MACRO compiler has been provided with OpenVMS I64 Version 8.2. It uses the same DCL commands as the MACRO compiler on OpenVMS Alpha.

Most programs that compile on OpenVMS Alpha should recompile on OpenVMS I64 without modification. However, programs that call routines with nonstandard return values, or programs that use the JSB instruction call routines written in other languages must add some new directives to the source file.

For more information on the new directives and for details on the MACRO compiler, refer to the HP OpenVMS MACRO Compiler Porting and User's Guide.

5.19.2 /TIE Qualifier Defaults Differ on Alpha and I64

V8.2

The default for the /TIE qualifier is different on Alpha and I64 systems. On Alpha, the default is /TIE. On I64, the default is /NOTIE.

5.19.3 /OPTIMIZE=VAXREGS Qualifier Not Supported on I64

V8.2

The /OPTIMIZE=VAXREGS qualifier, which is supported on Alpha, is not supported on I64. Unfortunately, all of the related code was not removed from the command line processing. If you specify /OPTIMIZE=ALL on I64, you will accidentally turn on the unsupported VAXREGS optimization. A future release will correct the command line process to avoid turning on the VAXREGS optimization.

5.19.4 CODGENWARN Message Can Be Ignored (Alpha Only)

V8.2

The Macro-32 compiler might generate the following message:

%AMAC-W-CODGENWARN, pre-allocation of multiple condition codes overlapped

This message can be safely ignored. The generated code is correct. The Macro-32 compiler will be corrected in a future release.

5.19.5 Granularity Support (I64 Only)

V8.2

The Macro-32 compiler does not fully support the /GRANULARITY qualifier or the .PRESERVE GRANULARITY option. In most cases, the compiler generates byte granular code by default, but there are cases where it does not (for example, when accessing an unaligned quadword). This problem will be corrected in a future release.

5.19.6 Integer Divide-by-Zero Error Not Raised By Default (I64 Only)

V8.2

The Macro-32 compiler does not generate the code to detect integer divide-by-zero properly. For dividing by a run-time value, the compiler attempts to generate checking code by using the /ENABLE=OVERFLOW qualifier. However, it checks the wrong operand. It accidentally raises an error when it divides 0 by another number. In a future release, the compiler will be fixed to generate checking code by default to detect division by zero. That behavior will match the current behavior on OpenVMS VAX and OpenVMS Alpha systems.

5.19.7 Integer Divide By Most Negative Number Crashes Compiler (I64 Only)

V8.2

The following instruction causes the Macro-32 compiler to crash:

    DIVL3 R0, #^X80000000, R0
    BVS 1$

This problem will be fixed in a future release

5.19.8 Integer Divide Might Not Set "V" Condition Code Properly (I64 Only)

V8.2

The integer division instructions (DIVL, DIVW, and DIVB) might not set the overflow ("V") condition code properly. This problem will be fixed in a future release.

5.19.9 Floating Divide-by-Zero Error Not Raised (I64 Only)

V8.2

The Macro-32 floating-point support routines do not detect floating division by zero. The support routines convert the VAX floating values to IEEE floating values and perform the division. Without the check, the division produces an IEEE NaN value. The support routines then attempt to convert the NaN value back into a VAX floating value. That operation raises a floating invalid error. A future release will fix the support routines to properly raise the floating divide-by-zero error.

5.19.10 INSV Instruction Overwrites Extra Memory (I64 Only)

V8.2

The code generated for the INSV instruction overwrites extra memory when the size argument is a literal 32 and the position argument is larger than 0. In those cases, the INSV instruction overwrites too much of the second longword (in the case of a memory destination) or the second register (in the case of a register destination).

In the case where the destination is a memory reference, a workaround is to place a literal 32 into a scratch register and then use that scratch register as the size operand of the INSV instruction.

For example, consider the following code:

    INSV R2, #15, #32, (R4)

This code correctly updates the upper portion of the longword pointed to by R4, but incorrectly writes all of the next longword instead of just the lower portion of the next longword. The program works correctly if you change the code to the following:

    MOVL #32, Rtmp          ; Where Rtmp is an available register
    INSV R2, #15, Rtmp, (R4)

In the case where the destination is a register reference, the workaround is to break up the INSV into multiple instructions. For example, change this code:

   INSV R2, #15, #32, R4

to this code:

   INSV R2, #15, #17, R4   ; Place bottom 17 bits of R2 into top of R4
   ASHL #-15, R2, Rtmp     ; Move high part of R2 into temp register
   INSV Rtmp, #0, #15, R5  ; Move high 15 bits of R2 into bottom of R5

These problems will be fixed in a future release.

5.20 Hypersort Utility

The following notes pertain to Hypersort V08-006 for OpenVMS Alpha and OpenVMS I64 Version 8.2.

As always, continue to use SORT32 as a workaround for any unresolved problems with Hypersort or any functionality not implemented in Hypersort. Release notes for SORT32 are in Section 5.36.

5.20.1 Reporting a Problem to HP

V8.2

If you find a problem with SORT or MERGE, execute the following commands before you submit a problem report:

$ WRITE SYS$OUTPUT "WSEXTENT =''F$GETJPI("","WSEXTENT")'"
$ WRITE SYS$OUTPUT "PGFLQUOTA=''F$GETJPI("","PGFLQUOTA")'"
$ SHOW LOGICAL SORTSHR
$ SORT/STATISTICS (or MERGE/STATISTICS)

Include the output in your problem report along with the input files that demonstrate the problem.

5.20.2 Large Files Restriction

V8.2

Hypersort V08-010 includes an improved memory allocation algorithm, but Hypersort still sometimes hangs or ACCVIOs with large input files. To reduce the chances of a hang or an ACCVIO, make sure to set page file quota and working set extent as noted in Section 5.20.8. If you encounter a hang or an ACCVIO with Hypersort, use SORT32 instead.

5.20.3 Hypersort and VFC Files Restriction

V7.3-2

Use of VFC files with Hypersort requires /FORMAT=RECORD_SIZE:n.

5.20.4 /FORMAT=RECORD_SIZE Restriction

V7.3-1

Hypersort supports /FORMAT=RECORD_SIZE:n for use with both SORT and MERGE, with the following two restrictions:

• In all cases, if the command-specified RECORD_SIZE is less than the longest record size (LRL) of any record in the input files, the records that are too long are truncated to the RECORD_SIZE size in the sorted output file and the diagnostic message %SORT-E-BAD_LRL is issued. In this situation, the output file should be discarded and the sort should be rerun. The RECORD_SIZE parameter for the SORT command should be revised to a value appropriate to the size of the largest record as shown in the listing of a DIR/FULL command for the input files.
• SORT and MERGE produce output sequential files from input indexed files. The %SORT-E-BAD_LRL diagnostic message can also be issued for this case.

V7.3-1

Hypersort does not fully support search lists and logical names used for input files and work files. If you encounter this problem, use SORT32.

5.20.6 Lack of Free Space for Work Files

V7.3-1

Hypersort does not properly terminate if free space is exhausted in all available sort work files. To avoid this problem, do one of the following:

• Allocate sufficient free space for the devices used for sort work files.
• Use SORT32 to detect that work file space has been exhausted.

V7.3

Hypersort does not support asterisk (*) as an input file specification.

5.20.8 Optimal Working Set Extent and Page File Quota Settings

V7.3-1

SORT32 and Hypersort use different sorting and work file algorithms. The relative speed of these utilities depends on the input file and the memory/disk/CPU configuration. Make sure that the working set extent is no more than one third of the page file quota. Both SORT32 and Hypersort perform best with a working set extent appropriate to a specific input file.

5.21 Intel® Assembler (I64 Only)

V8.2

All modules written in Intel assembly language must contain appropriate unwind directives, either by automatic generation using the -Xunwind flag or by explicitly placing unwind directives into the source module. Without accurate unwind information, the operating system's condition handling and exception dispatching does not work, and your program fails in unexpected ways. Programs without accurate unwind information are not supported by OpenVMS. This is a permanent requirement.

5.22 Librarian Utility

The following release notes pertain to the Librarian Utility and Library Service routines.

5.22.1 Linking Against Data-Reduced ELF Object Libraries Not Recommended (I64 Only)

V8.2

DCX data-reduced ELF object libraries are not stored in contiguous space in the library. As a result, the module cannot be directly mapped into process P2 space because data expansion must first occur. The LBR$MAP_MODULE library service expands and copies the module into process P2 space. This action causes the resulting pages in P2 space to be counted against process quota.

The LBR$UNMAP_MODULE library service recovers those pages, but the pages remain in a heap storage free list and continue to be counted against process quota. For this reason, HP strongly recommends that DCX data-reduced ELF object libraries first be expanded before performing Linker operations.

5.22.2 Failure to Insert or Replace .STB files in an I64 Library (I64 Only)

V8.2

On OpenVMS VAX and Alpha, .STB files can be stored in object libraries. On OpenVMS I64, the Librarian does not do this. For example:

 $ LIBR/CREATE OBJ$:SOME_LIBRARY OBJ$:SOME_FILE.STB
 Librarian T01-23
 %LIBRAR-E-NOTELFFILE, TPSSWRKD$:[TPSS.TRACE.IA64.LPIOBJ]TRACEMSG.STB;1
  is not an ELF object or image file

Because .STB files are neither objects nor images, the Librarian does not currently put them into an .OLB file on I64 systems.

On Alpha and VAX, however, STB files are formatted as object files. On VAX, .STB files can be used as input to the Linker. On Alpha, .STB file formats are identical to .OBJ file format (that is, nothing distinguishes them except for the .STB file extension). As such, the Alpha Librarian accepts the file, but it cannot be used as input to the Linker.

On I64, the file type (ET_VMS_LINK_STB) is embedded in the .STB file, allowing the Librarian and Linker to determine that the .STB file cannot be processed.

5.22.3 Librarian Fails to Report Errors When Process Quota Too Low

V8.2

The OpenVMS Alpha and I64 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, increase your PGFLQUOTA before running compression, data reduction, or data expansion operations. In addition, ensure that your command procedures check the return status from the LIBRARY command.

5.22.4 Object Module Name Length Problem (I64 Only)

V8.2

The Librarian incorrectly restricts the module name length to 31 characters for I64 (ELF) object and shareable image libraries. This problem will be corrected in a future release. For conventions on specifying image names, see the HP OpenVMS Version 8.2 New Features and Documentation Overview.

5.23 Lightweight Directory Access Protocol (LDAP) API

The following sections contain release notes pertaining to the LDAP API.

5.23.1 The Routine ldap_get_option Returns Error -1 When ld Is NULL

V7.3

Using a value of NULL for the ld parameter in a call to ldap_get_options() results in an error of -1 being returned, rather than the routine returning a set of global default data.

5.23.2 The Routine ber_flatten() Fails to Detect Mismatched Braces

V7.3

The routine ber_flatten() does not correctly detect the situation where '{' and '}' format modifiers in a BerElement are incorrectly matched.

5.24 Linker Utility for OpenVMS Alpha

The following release notes pertain to the Alpha Linker Utility.

For I64 Linker release notes, see Section 5.25.

5.24.1 LINK/NATIVE_ONLY Help Text Clarification

V8.2

Online help for LINK/NATIVE_ONLY could be more clearly stated as follows for both Alpha and I64:

"Prevents the linker from generating procedure signature information. Procedure signatures are required to allow the native code being linked to interoperate with images translated from either VAX or Alpha binary code. To build an executable or shareable image that calls or can be called by translated code, link it using /NONATIVE_ONLY. Code that is to interoperate with translated images must also be compiled using the /TIE qualifier. (See the associated compiler documentation for details.) "

V7.3-2

When the RMS_RELATED_CONTEXT linker option is on (the default is RMS_RELATED_CONTEXT=YES) and a nonexistent file is specified in a list of files for the LINK command, the linker's call to LIB$FIND_FILE takes a long time to complete and the linker may appear to hang. Depending on the number of files being linked and the use of logical names in their specification, the linker may take hours to finish because LIB$FIND_FILE locates every combination of the missing file's prefix before displaying a "file not found" message. Note that you cannot terminate the linker process with Ctrl/Y after the linker has called LIB$FIND_FILE.

Workaround

Specify /OPTION in the LINK command. When you press Return, the linker waits for you to enter information into an options file. When you are finished, press Ctrl/Z. To avoid the problem described in this release note, include the following items in the options file:

• On the first line, specify this option:

  RMS_RELATED_CONTEXT=NO

  
  With the RMS_RELATED_CONTEXT option set to NO, any missing file listed in this options file will generate an immediate "file not found" message.
• On subsequent lines, specify the files to be linked, using full file specifications (in the form disk:[dir]filename.ext) for every file. Full file specifications are required because when you specify RMS_RELATED_CONTEXT=NO, file name "stickiness" is disabled.

For example, consider the following LINK command:

$ LINK DSK:[TEST]A.OBJ, B.OBJ

If you want to specify this command with RMS_RELATED_CONTEXT=NO, you would specify /OPTION and then enter full file specifications for the files to be linked, as follows:

$  LINK SYS$INPUT:/OPTION
RMS_RELATED_CONTEXT=NO
DSK:[TEST]A.OBJ, DSK:[TEST]B.OBJ [Ctrl/Z]
$

For more information about the RMS_RELATED_CONTEXT option, refer to the HP OpenVMS Linker Utility Manual.

Example

The following example shows how the linker appears to hang when file DOES_NOT_EXIST.OBJ is included in the list and the RMS_RELATED_CONTEXT option is not specified (and therefore defaults to YES).

$  DEFINE DSKD$ WORK4:[TEST.LINKER.OBJ.]
$  DEFINE RESD$ ROOT$, ROOT2$, ROOT3$, ROOT4$, ROOT5$, DISK_READ$:[SYS.] (1)
$  DEFINE ROOT$ WORK4:[TEST.PUBLIC.TEST]
$  DEFINE ROOT2$ WORK4:[TEST.LINKER.]
$  DEFINE ROOT3$ WORK4:[TEST.UTIL32.]
$  DEFINE ROOT4$ WORK4:[TEST.PUBLIC.]
$  DEFINE ROOT5$ WORK4:[TEST.PUBLIC.TMP]
$  LINK/MAP/FULL/CROSS/EXE=ALPHA.EXE  RESD$:[TMPOBJ] A.OBJ,-
_$  RESD$:[SRC]B.OBJ,C,DSKD$:[OBJ]D.OBJ,E,RESD$:[TMPSRC]F.OBJ,-
_$  RESD$:[TEST]G.OBJ,RESD$:[SRC.OBJ]H,RESD$:[COM]DOES_NOT_EXIST.OBJ
[Ctrl/T] NODE6::_FTA183: 15:49:46 LINK CPU=00:02:30.04 PF=5154 IO=254510 MEM=134 (2)
[Ctrl/T] NODE6::_FTA183: 15:49:46 LINK CPU=00:02:30.05 PF=5154 IO=254513 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:02 LINK CPU=00:02:38.27 PF=5154 IO=268246 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:02 LINK CPU=00:02:38.28 PF=5154 IO=268253 MEM=134
[Ctrl/T] NODE6::_FTA183: 15:50:14 LINK CPU=00:02:44.70 PF=5154 IO=278883 MEM=134

1. This command defines logical names and equivalents.
2. Each time you press Ctrl/T, the CPU and IO values increase, but the MEM and PF values do not, indicating that LIB$FIND_FILE is being called.

As shown in the following example, using an options file to set RMS_RELATED_CONTEXT to NO causes the link operation to finish immediately when it encounters the missing file.

$  DEFINE DSKD$ WORK4:[TEST.LINKER.OBJ.]
$  DEFINE RESD$ ROOT$, ROOT2$, ROOT3$, ROOT4$, ROOT5$, DISK_READ$:[SYS.]
$  DEFINE ROOT$ WORK4:[TEST.PUBLIC.TEST.]
$  DEFINE ROOT2$ WORK4:[TEST.LINKER.]
$  DEFINE ROOT3$ WORK4:[TEST.UTIL32.]
$  DEFINE ROOT4$ WORK4:[TEST.PUBLIC.]
$  DEFINE ROOT5$ WORK4:[TEST.PUBLIC.TMP.]
$  LINK/MAP/FULL/ CROSS /EXE=ALPHA.EXE SYS$INPUT:/OPTION
RMS_RELATED_CONTEXT=NO
RESD$:[TMPOBJ]A.OBJ,RESD$:[SRC]B.OBJ,RESD$:[SRC]C,DSKD$:[OBJ]D.OBJ
DSKD$:[OBJ]E,RESD$:[TMPSRC]F.OBJ,RESD$:[TEST]G.OBJ
RESD$:[SRC.OBJ]H,RESD$:[COM]DOES_NOT_EXIST.OBJ [Ctrl/Z]

%LINK-F-OPENIN, error opening DISK_READ$:[SYS.][COM]DOES_NOT_EXIST.OBJ; as input
-RMS-E-FNF, file not found
$

V7.3-1

Previously, the linker's check between the library and the shareable image was too sensitive. It compared against the exact date and time, signaling LINK-I-DATMISMCH, if no match was found. Now, however, it makes only the same check that the image activator does: that is, it uses the GSMATCH criteria to verify compatibility.

The old behavior (check for date and time) can be obtained by setting the logical name LINK$SHR_DATE_CHECK.

5.24.4 Limit of 25 Elements on Stack

Permanent Restriction

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.

5.25 Linker Utility for OpenVMS I64

V8.2

The following release notes pertain to the I64 Linker Utility.

For Alpha Linker release notes, see Section 5.24.

See Section 5.24.1 for a note that applies to both the Alpha and I64 Linker.

5.25.1 Differences Between the I64 and Alpha Linkers

V8.2

Be sure to read the HP OpenVMS Version 8.2 New Features and Documentation Overview for a complete description of the differences between the OpenVMS I64 Linker and the OpenVMS Alpha Linker. The HP OpenVMS Version 8.2 New Features and Documentation Overview also contains a description of features that are new with the OpenVMS I64 Linker.

5.25.2 LINK_ORDER Section Header Flag Not Supported

V8.2

The Linker does not support the LINK_ORDER ELF section header flag. However, unwind sections, which have this flag set, are placed in the correct order.

This flag indicates that the section, if combined with other sections in the image file, be combined in the same order as the order of the sections to which they refer are combined. Unwind sections are handled as special cases and appear in the correct order.

The following figure illustrates this concept.

V8.2

DCX data-reduced ELF object libraries are not stored in contiguous space in the library. As a result, the module cannot be directly mapped into process P2 space because data expansion must first occur. The LBR$MAP_MODULE library service expands and copies the module into process P2 space. This action causes the resulting pages in P2 space to be counted against process quota.

The LBR$UNMAP_MODULE library service recovers those pages but the pages remain in a heap storage free list and continue to be counted against process quota. For this reason, HP strongly recommends that DCX data-reduced ELF object libraries first be expanded before performing Linker operations.

5.25.4 Errors in the Image Synopsis Section of the Map

V8.2

In the Image Synopsis section of the map, the numeric entities in the fields "Number of code references to shareable images:" and "Estimated map length:" are incorrect. This will be fixed in a future release of OpenVMS I64.

5.25.5 DIFTYPE and RELODIFTYPE Messages

V8.2

On OpenVMS I64 systems, if a module defines a variable as data (OBJECT), it must be referenced as data by all other modules. If a module defines a variable as a procedure (FUNC), it must be referenced as a procedure by all other modules.

When data is referenced as a procedure, the following informational message is displayed:

%ILINK-I-DIFTYPE, symbol symbol-name of type OBJECT cannot be
referenced as type FUNC

When a procedure is referenced as data, the following informational message is displayed:

%ILINK-I-DIFTYPE, symbol symbol-name of type FUNC cannot be
referenced as type OBJECT

Type checking is performed by the linker on OpenVMS I64 because the linker must create function descriptors. The equivalent procedure descriptor was created by the compiler on OpenVMS Alpha, so this informational message is new for the linker on OpenVMS I64.

This message is informational only and does not require user action. However, if the linker detects data referenced as a procedure, it might issue the following warning message in addition to the DIFTYPE message:

%ILINK-W-RELODIFTYPE, relocation requests the linker to build a
function descriptor for a non-function type of symbol

The following example of two modules demonstrates how to fix these errors.

TYPE1.C

 #include <stdio>

 int status ;   // Defines status as data.
 extern int sub();

 main ()
 {
     printf ("Hello World\n");
     sub();
 }

TYPE2.C

 extern int status (int x) ;

 sub ()
 {
 int x;
         x = (int)status;
         return status (x);
 }

When these modules are linked, you get an informational message and a warning message, as follows:

$ CC/EXTERN_MODEL=STRICT_REFDEF TYPE1
$ CC/EXTERN_MODEL=STRICT_REFDEF TYPE2
$ LINK TYPE1,TYPE2
%ILINK-I-DIFTYPE, symbol STATUS of type OBJECT cannot be referenced as
type FUNC
        module: TYPE2
        file: NODE1$:[SMITH]TYPE2.OBJ;6
%ILINK-W-RELODIFTYPE, relocation requests the linker to build a
function descriptor for a non-function type of symbol
        symbol: STATUS
        relocation section: .rela$CODE$ (section header entry: 18)
        relocation type: RELA$K_R_IA_64_LTOFF_FPTR22
        relocation entry: 0
        module: TYPE2
        file: NODE1$:[SMITH]TYPE2.OBJ;6

To fix the problem and avoid the informational and warning messages, correct TYPE1.C to define status as a procedure:

TYPE1.C

 #include <stdio>

 int status (int x);  // Defines status as a procedure.
 extern int sub();

 main ()
 {
     printf ("Hello World\n");
     sub();
 }

 int status (int x) {
     return 1;
 }

$ CC/EXTERN_MODEL=STRICT_REFDEF TYPE1
$ CC/EXTERN_MODEL=STRICT_REFDEF TYPE2
$ LINK TYPE1,TYPE2

Permanent Restriction

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 --- such as a LAT connect $QIO) cannot be canceled with CANCEL SELECTIVE.

5.27 Mail Utility: Threads Restriction for Callable Mail

V7.1

OpenVMS callable mail routines are not thread-safe. Refer to the Guide to the 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.

5.28 OpenVMS Debugger

The following release notes describe conditions specific to the OpenVMS Debugger on OpenVMS Alpha and I64 systems.

For release notes about the Delta and XDelta debuggers, see Section 5.13. For release notes about the System Code Debugger (SCD), see Section 5.37.

5.28.1 General Conditions and Workarounds (I64 Only)

V8.2

The following general conditions have been identified, along with user workarounds:

Condition: Arrays whose elements are on unaligned boundaries are not displayed properly. This occurs when a programming language construct is used to force unnatural data alignment (for example, #pragma nomember_align in C or the PACKED keyword in Pascal).

Workaround: None.

Condition: When examining an array with scalar (integer) subscripts, the debugger prints the array index values in the currently defined radix, rather than in the decimal radix.

Workaround: Issue the SET RADIX DECIMAL command.

Condition: OpenVMS Debugger on I64 systems displays general, floating-point and predicate registers as if the register rename base (CFM.rrb) and rotating size (CFM.sor) are both zero. In other words, when rotating registers are in use, the effects of the rotation are ignored. This will be corrected in a future release. See Section 5.9 for additional details.

Workaround: Examine the CFM register and manually adjust the EXAMINE command to account for the nonzero CFM.rrb and CFM.sor fields.

5.28.2 BASIC Language Issues (I64 Only)

V8.2

Condition: When examining a range of a multi-dimensional array, the debugger does not correctly symbolize the element's location. That is, the array row and column values are incorrect.

Workaround: None.

5.28.3 C++ Language Issues (I64 Only)

V8.2

Condition: The SHOW CALLS command sometimes displays C++ mangled names, rather than unmangled names.

Workaround: None.

5.28.4 COBOL Language Issues (I64 Only)

V8.2

Condition: Data declared with EDIT picture clauses are only partially supported. Examining the item (using the EXAMINE command) displays the raw data without scaling or other adjustments. Changing the item by depositing an integer or decimal constant (using the DEPOSIT command) may result in an error.

Workaround: Manually adjust the displayed value by the appropriate scale factor. If you need to change the value, execute the DEPOSIT command using another variable or a quoted string as the source.

5.28.5 Fortran Language Issues (I64 Only)

V8.2

Condition: A deposit of a value into a data item declared as REAL*16 always results in a zero being stored rather than the actual value.

Workaround: None.

5.28.6 Pascal Language Issues (I64 Only)

V8.2

Condition: Arrays declared with dynamic bounds (for example, "array [1..n]") are not always handled correctly. When examining the array, the debugger will sometimes display INVARRDSC or IVALOUTBNDS errors, and SHOW SYMBOL/TYPE may incorrectly display the array bounds.

Workaround: None.

5.28.7 SET SCOPE Command: Behavior Change

V8.2

The behavior of the SET SCOPE command has changed in this release. SET SCOPE now changes the debugger's language setting to the language of the specified scope. Previously, SET SCOPE did not affect the language setting. You can disable this capability by issuing the SET LANGUAGE NODYNAMIC command.

5.28.8 SHOW IMAGE Command Change

V8.2

The SHOW IMAGE command now displays a summary of the address space occupied by the images in your process. To see the full image section information, use SHOW IMAGE/FULL, or specify an image name (for example, SHOW IMAGE FOO).

5.28.9 Client/Server Interface: Previous Versions Not Supported (Alpha Only)

V7.3

The Debugger for OpenVMS Alpha Version 7.3 and later 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.

5.29 OpenVMS System Dump Analyzer (SDA)

The following notes pertain to the System Dump Analyzer (SDA).

5.29.1 READ Command Default Change

V8.2

The default behavior of the SDA READ command has changed from /LOG to /NOLOG.

5.29.2 CLUE Commands Not Ported to OpenVMS I64

V8.2

The following CLUE commands have not yet been ported to OpenVMS I64 and will return a message to that effect:

CLUE CALL
CLUE ERRLOG
CLUE FRU
CLUE REGISTER

V8.2

The following functionality changes have been introduced with OpenVMS I64 Version 8.2:

• You can now use the /ALL and /SUMMARY qualifiers with the following commands:
  • SHOW CALL address
  • SHOW CALL /HANDLE=address
  • SHOW CALL /EXCEPTION_FRAME=address
• Previously, the SHOW CALL address always referred to an Invocation Handle address; it can now also be an Exception Frame address.
  If address is an Exception Frame address, that frame address is remembered by SDA as a starting point for further call-stack walks.
  If address is an Invocation Handle address for a subsequent SHOW CALL command, SDA starts its call-stack walk from the previously remembered starting point.
  If the subsequent address is another Exception Frame address, SDA discards the previously remembered call-stack start point and sets the new exception frame address as the current call-stack start point.
  Similarly, any SHOW CALL/EXCEPTION_FRAME command also sets the call-stack start point to be the exception frame address given in the command.
  This method makes it possible to walk the call stack by starting from an arbitrary exception frame. Note that parts of the call chain can be in process space, even if the starting exception frame is in system space (and vice versa). For the full call-stack walk to work in either case, the SDA current process context must be set to the process where the call stack originates.
• Entering a SHOW CALL command, SHOW CALL/SUMMARY command, or SHOW CALL/ALL command without an address and without a /NEXT, /EXCEPTION_FRAME, or /HANDLE qualifier resets the starting point to the default call chain for the current process.