V8.3

As of OpenVMS Alpha and Integrity servers Version 8.2, no new entry points are being added to the DECC$*.OLB object libraries. This means new C RTL entry points do not get mapped through these libraries to prefixed entries. For example, the new OpenVMS Version 8.3 entry point crypt , compiled with /PREFIX=NONE, does not get mapped from crypt to decc$crypt .

5.17 Calling Standard and Rotating Registers (Integrity servers Only)

V8.3

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. That is, 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.

Previously, 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 interpreted their register number parameters without applying an adjustment for the effects of the register rename base and rotating size registers. This error is corrected.

5.18 Common Data Security Architecture (CDSA) Considerations

The following notes pertain to CDSA.

5.18.1 Secure Delivery

V8.4

From Version 8.4 onwards, all OpenVMS kits including the PCSI and VMSINSTAL based kits will be signed using HP Code Signing Service (HPCSS). The signing and validation do not use the CDSA infrastructure. A new companion file,
<full kit name>_HPC is created and is provided along with the kit. The kit is then validated using this companion file.

A new validator, "HPBinarychecker" is installed on all OpenVMS systems to validate the kits signed using the HP Code Signing Service. For more information, see HP OpenVMS Version 8.4 New Features and Documentation Overview.

Note that the kits that are signed before Version 8.4 can be validated using CDSA on OpenVMS Version 8.4.

5.18.2 Installation and Initialization Considerations

V8.4

Installation of CDSA is done automatically when you install the operating system.

• When a new version of CDSA is installed separately from an Operating System upgrade, you must run the CDSA upgrade procedure:

  $ @SYS$STARTUP:CDSA$UPGRADE

  
  You must shut down any CDSA application before you run the upgrade procedure.
  It is not necessary to rerun the upgrade procedure when the system is rebooted. You also do not need to add the upgrade procedure 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:

  The following product has been selected: HP I64VMS CDSA V2.4-315 Layered Product Do you want to continue? [YES] %PCSI-E-HRDREF, product HP I64VMS CDSA V2.4-315 is referenced by HP I64VMS OPENVMS V8.4 The two products listed above are tightly bound by a software dependency. If you override the recommendation to terminate the operation, the referenced product will be removed, but the referencing product will have an unsatisfied software dependency and may no longer function correctly. Please review the referencing product's documentation on requirements. Answer YES to the following question to terminate the PRODUCT command. However, if you are sure you want to remove the referenced product then answer NO to continue the operation.

Permanent Condition

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.20 Delta/XDelta Debuggers

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

5.20.1 XDELTA Register Display Consideration (Integrity servers Only)

V8.2

XDELTA on OpenVMS Integrity server 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.17 for additional details.

5.21 File Applications: Corrections to Guide to OpenVMS File Applications

Permanent Correction

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."

Permanent Condition

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.23 Potential Must-Be-Zero RMS Error: Making Room for New File Options in the FAB

V8.3

There is less unassigned space in the RMS user file access block (FAB). To allow for future growth in file-processing options implemented through the FAB, the last unassigned bit in the file-processing options field in the FAB (FAB$L_FOP) has been defined as the FAB$V_EXTEND_FOP option. This option will be used in the future to request and validate assignments to two new FAB fields that span previously unused bytes in the FAB:

• FAB$W_FOPEXT : The FOPEXT word field is reserved for the definition of new file-processing options that might require implementation in the future.
• FAB$W_RESERVED_MBZ : The RESERVED_MBZ word field is being reserved for future use. Its usage is currently open for future definition.

In a future release, when one or more new file-processing options are implemented, the FAB$V_EXTEND_FOP bit will have to be set in the FAB$L_FOP field to take advantage of any new option in the FOPEXT field. However, when it is set, it will also indicate that any undefined bits in the FOPEXT field are clear and FAB$W_RESERVED_MBZ contains a zero. If these conditions are not met when this bit is set, a fatal error (RMS-F-FOPEXTMBZ) will be returned to the user for any RMS file-level service.

The addition of the EXTEND_FOP option is fully upwardly compatible except if you set this last bit in the FAB$L_FOP field by accident and either of these two new FAB fields happens to be nonzero. Previously, RMS ignored this last bit in the FAB$L_FOP field if it was set by accident.

If the RMS-F-FOPEXTMBZ error is returned, you must clear either the EXTEND_FOP option in the FAB$L_FOP field or the two new fields (FAB$W_FOPEXT) and FAB$W_RESERVED_MBZ .

5.24 HP COBOL Run-Time Library (RTL)

V8.4

For OpenVMS Alpha and OpenVMS Integrity servers Version 8.4, the HP COBOL RTL (DEC$COBRTL) has been updated to V2.9-785.

5.24.1 Performance Improvement of COBOL CALL Statement

V8.4

Performance degradation was observed on OpenVMS Integrity servers while calling subroutines, using the COBOL CALL statement. The time taken was much longer on OpenVMS Integrity servers than on OpenVMS Alpha.

The Run-Time Library (RTL) has been modified and the performance of the COBOL CALL statement has significantly improved. Now, the performance on OpenVMS Integrity servers is comparable to OpenVMS Alpha.

5.25 HP Fortran for Integrity servers

V8.2

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

HP Fortran for OpenVMS Integrity servers 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 Integrity servers F90 compiler, including FDML and CDD support. See the Fortran V8.0 or V8.1 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 V8.0 or V8.1 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

5.26 HP MACRO for OpenVMS

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 Integrity servers. The following notes pertain to the MACRO compiler.

5.26.1 Enhancements for the Macro-32 Compiler

V8.4

The Macro-32 compiler has been enhanced to include several new instruction level built-ins for OpenVMS Alpha and OpenVMS Integrity server systems.

Table 5-1 summarizes the new built-ins added.

Table 5-1 Macro-32 New Built-ins

Built-in	Operands1	Description	Supported on
EVAX_WH64	<AB>	Generates Alpha write hint 64 instructions.	Alpha
IA64_PADD1	<WQ,RQ,RQ>	Generates Parallel Add instruction, single byte form with the first argument as the destination and the next two arguments as the source operands.	Integrity servers
IA64_PADD1_SSS	<WQ,RQ,RQ>	Generates Parallel Add instruction, single byte form, with the first argument as the destination and the next two arguments as the source operands. Result and both source operands are treated as signed.	Integrity servers
IA64_PADD1_UUS	<WQ,RQ,RQ>	Generates Parallel Add instruction, single byte form, with the first argument as the destination and the next two arguments as the source operands. Result and first source operand are treated as unsigned and the second source operand is treated as signed.	Integrity servers
IA64_PADD1_UUU	<WQ,RQ,RQ>	Generates Parallel Add instruction, single byte form, with the first argument as the destination and the next two arguments as the source operands. Result and both source operands are treated as unsigned.	Integrity servers
IA64_PADD2	<WQ,RQ,RQ>	Generates Parallel Add instruction, two byte form, with the first argument as the destination and the next two arguments as the source operands.	Integrity servers
IA64_PADD2_SSS	<WQ,RQ,RQ>	Generates Parallel Add instruction, two byte form, with the first argument as the destination and the next two arguments as the source operands. Result and both source operands are treated as signed.	Integrity servers
IA64_PADD2_UUS	<WQ,RQ,RQ>	Generates Parallel Add instruction, two byte form, with the first argument as the destination and the next two arguments as the source operands. Result and first source operand are treated as unsigned and the second source operand is treated as signed.	Integrity servers
IA64_PADD2_UUU	<WQ,RQ,RQ>	Generates Parallel Add instruction, two byte form, with the first argument as the destination and the next two arguments as the source operands. Result and both source operands are treated as unsigned.	Integrity servers
IA64_PADD4	<WQ,RQ,RQ>	Generates Parallel Add instruction, four byte form, with the first argument as the destination and the next two arguments as the source operands.	Integrity servers
IA64_MUX1	<WQ,RQ,RQ>	Generates 'mux1' instruction with the first argument as the destination and the second argument as the source operand. The third argument specifies the permutation to be performed. 2	Integrity servers
EVAX_S4ADDQ	<WQ,RQ,RQ>	Generates Alpha scaled quadword add instruction.	Alpha and Integrity servers
IA64_LFETCH_NT1, IA64_LFETCH_NT2, IA64_LFETCH_NTA, IA64_LFETCH_EXCL_NT1, IA64_LFETCH_EXCL_NT2, IA64_LFETCH_EXCL_NTA	<RQ,RQ>	These enhanced prefetch built-ins provide a method for specifying non-default cache locality hints (that is, ".nt1",".nt2",and ".nta"). The first operand is the address to prefetch and the second operand is for either the reg-base-update-form or the imm-baseupdate-form; if the operand is the literal zero, the no-baseupdate- form will be used.	Integrity servers
All the _FAULT_variants of the LFETCH built-in		Generates 'lfetch' instructions with the 'fault' completer. For example, IA64_LFETCH_FAULT_EXCL_NT1	Integrity servers

• BRCST 0
• MIX 8
• SHUF 9
• ALT 10
• REV 11

For additional information about underlying instructions, see the respective hardware architecture manuals.

5.26.2 HP MACRO for OpenVMS Integrity servers

V8.3

The following notes pertain to the HP MACRO for OpenVMS Integrity servers compiler:

• Prior to OpenVMS Version 8.3, the compiler generated the wrong code for the HALT instruction. On Integrity servers, the HALT instruction is implemented using the Itanium break instruction with a reserved literal value of BREAK$C_SYS_HALT . Because of a bug in the compiler's build environment, the Macro-32 compiler used the wrong literal value. This problem has been fixed in Version 8.3. Any code that uses the HALT instruction should be recompiled with the Version 8.3 compiler. For systems prior to Version 8.3, the correct behavior can be accomplished as follows:

  $BREAKDEF IA64_HALT #BREAK$C_SYS_HALT ; Issue break instruction with correct literal HALT ; Use HALT built-in to inform compiler that this ends the flow of control

• The compiler might optimize away instructions prior to HALT , BPT , and EVAX_BUGCHK . The optimizer does not identify these special instructions as implicitly reading all registers by either writing a dump file or transferring control to a debug environment. The apparently unused instructions are removed by mistake. The compiler must be taught about the special behavior of these instructions. Though there is no syntax to force arbitrary instructions to be included in the final object file, the IA64_LD8_A built-in can be used as a workaround. See the following Macro-32 paragraphs for information about this built-in. In addition, specifying /NOOPTIMIZE preserves the apparently unused instructions at the expense of slower and larger code.
• The compiler might optimize away apparently unused memory loads. The compiler's optimizer can recognize whether or not the result of a memory load is used. If the result appears to be unused, the optimizer removes the memory load as well. However, some code might be using the memory load to fault a page into memory before raising IPL for example. In these cases, the removed instruction prevents the page from being faulted into memory, and the subsequent code at high IPL experiences a fatal page fault at high IPL exception. Although there is no syntax to force arbitrary instructions to be included in the final object file, the IA64_LD8_A built-in can be used as a workaround. The IA64_LD8_A built-in, new in Version 8.3, generates a special form of the Itanium "ld8" instruction that also places the fetched address into the Advanced Load Address Table (ALAT). The compiler identifies this special form of "ld8" as having a side effect and that it cannot be removed from the final object file even if the result appears to be unused. The insertion of the address into the ALAT does not cause any problems or require any additional changes. For unused memory loads that must remain in final object file, change them from:

  MOVL (Rn),Rn

  
  into

  IA64_LD8_A Rn,(Rn),#0

  
  HP will add new syntax to the compiler in a future release to designate instructions that must survive to the final object file.
  For systems prior to Version 8.3, there is no IA64_LD8_A built-in. The only workaround is to use /NOOPTIMIZE .

V8.3

The compiler might optimize away apparently unused memory loads. The compiler's new optimizer can recognize whether or not the result of a memory load is used. If the result appears to be unused, the optimizer removes the memory load as well. However, some code may be using the memory load to fault a page into memory before raising IPL for example. In these cases, the removed instruction prevents the page from being faulted into memory, and the subsequent code at high IPL experiences a fatal page fault at high IPL exception. The only workaround is either to use /NOOPTIMIZE or revert to the prior Macro-32 compiler, which does not contain the optimization.

The new Macro-32 compiler is named SYS$SYSTEM:MACRO.EXE and is the default image activated by the DCL MACRO command. The older compiler can be found at SYS$SYSTEM:ALPHA_MACRO.EXE . For the DCL command MACRO to use the older compiler, define a MACRO logical name as follows:

$ DEFINE MACRO SYS$SYSTEM:ALPHA_MACRO.EXE

5.26.4 /OPTIMIZE=VAXREGS Qualifier not Supported on Integrity servers

V8.2

The /OPTIMIZE=VAXREGS qualifier, which is supported on Alpha, is not supported on Integrity servers. All the related code was not removed from the command line processing. If you specify /OPTIMIZE=ALL on Integrity servers, 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.26.5 Floating Divide-by-Zero Error Not Raised (Integrity servers 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.27 Hypersort Utility

The following notes pertain to Hypersort V08-006 for OpenVMS Alpha and OpenVMS Integrity servers 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.39.

5.27.1 Reporting a Problem to HP

Permanent Condition

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.27.2 Large Files Restriction

V8.2

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

5.27.3 Hypersort and VFC Files Restriction

V7.3-2

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

5.27.4 /FORMAT=RECORD_SIZE Restriction

Permanent Restriction

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.

Permanent Restriction

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.27.6 Lack of Free Space for Work Files

Permanent Restriction

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.

Permanent Restriction

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

5.27.8 Optimal Working Set Extent and Page File Quota Settings

Permanent Restriction

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.28 Intel Assembler (Integrity servers Only)

Permanent Restriction

All modules written in the 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.29 Librarian Utility

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

5.29.1 Linking Against Data-Reduced ELF Object Libraries Not Recommended (Integrity servers Only)

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 recommends that DCX data-reduced ELF object libraries first be expanded before performing Linker operations.

5.29.2 Failure to Insert or Replace .STB files in an Integrity servers Library (Integrity servers Only)

V8.2

On OpenVMS VAX and Alpha, .STB files can be stored in object libraries. On OpenVMS Integrity servers, 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 Integrity servers.

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 the .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 Integrity servers, 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. This is a permanent condition.

5.29.3 Librarian Fails to Report Errors When Process Quota Too Low

Permanent Restriction

The OpenVMS Alpha and Integrity servers 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.30 Linker Utility for OpenVMS Alpha

The following release notes pertain to the Alpha Linker Utility on all OpenVMS platforms. For Integrity servers Linker release notes, see Section 5.31.

5.30.1 SYMBOL_VECTOR Linker Option Restriction

Permanent Restriction

The name of the symbol or the name of the program section in a shareable image that you want to declare universal, using the SYMBOL_VECTOR linker option, must consist of characters that belong to the TPA$_SYMBOL symbol type. The TPA$_SYMBOL symbol type consists of the following characters:
uppercase and lowercase A through Z, the dollar sign ($), the underscore (_), and the DEC multinational characters with code greater than 192.

In the following example, the procedure name contains a '~' character that does not belong to the TPA$_SYMBOL symbol type and hence the SYMBOL_VECTOR linker option displays the following error message:

$ LINK/SHARE SOME_LIBRARY, SYS$INPUT/OPT SYMBOL_VECTOR=(WRONG~NAME=PROCEDURE) %ILINK-F-OPTSYNERR, syntax error in options file SYS$INPUT:.; -ILINK-E-OPTLIN, options line in error SYMBOL_VECTOR=(WRONG'~'NAME=PROCEDURE)

5.30.2 Linker Appears to Hang When Many Files Are Specified

V8.3

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 may take 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 by pressing Ctrl/Y after the linker has called LIB$FIND_FILE.

To determine which file is missing, follow the steps described with the RMS_RELATED_CONTEXT= option in the Linker Manual, Part IV, LINK Command Reference.

5.30.3 Change in Linker Default Behavior with Library Check

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.

For more information, see the /LIBRARY qualifier in the Linker Manual Part IV, LINK Command Reference.

Shareable image libraries do not contain a copy of an image. They contain the image's name, the image's identification information, and a table including the image's universal symbols. The identification information is provided by the GSMATCH= option when the shareable image is linked. For more information, see the GSMATCH= option in the Linker Manual Part IV, LINK Command Reference.

It may happen that a shareable image is relinked but that a library is not updated. To handle such a case, the linker checks for compatibility. The linker makes the same check that the image activator does: that is, it uses the GSMATCH criteria to verify compatibility.

For VAX, the linker also compares against the date and time, signaling LINK-I-DATMISMCH , if they are different.

For Alpha, the initial behavior of linker was the same as the VAX linker. The check was seen as too sensitive and the default behavior was changed to use only the GSMATCH criteria. The old VAX behavior can be obtained by setting the logical name LINK$SHR_DATE_CHECK .

5.30.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.31 Linker Utility for OpenVMS Integrity servers

The following release notes pertain to the Integrity servers Linker utility.

For Alpha Linker release notes, see Section 5.30.

5.31.1 SYMBOL_VECTOR Linker Option Restriction

Permanent Restriction

For SYMBOL_VECTOR linker option restriction, see Section 5.30.1.

5.31.2 Linker Writes Incorrect Interimage Debug Fixups into Debug Symbol File

V8.3-1H1

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.

5.31.3 /SELECTIVE_SEARCH Qualifier Might Incorrectly Ignore Transfer Address

V8.3-1H1

If you have an Integrity server 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 Integrity server 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.

V8.3-1H1

For more than 65280 sections, the ELF format uses an extended numbering scheme, which was not implemented in the linker on OpenVMS Integrity server 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.

5.31.5 Incorrect Creation Date of Shareable Images in the Map File

V8.3-1H1

On OpenVMS Integrity servers, 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.

5.31.6 Demangler Information Look Up Results in Linker Access Violation

V8.3-1H1

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 violation.

This problem is corrected in the OpenVMS V8.3-1H1 Linker.

5.31.7 Incorrect Secondary Messages for the NOGLOSYM Error Message

V8.3-1H1

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.

5.31.8 Incorrect Information for Undefined Symbols

V8.3-1H1

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.

5.31.9 Incorrect UNMAPFIL Error

V8.3-1H1

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.

5.31.10 Max Ident Length Change for Shareable Images in Map

V8.3-1H1

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.

5.31.11 Linkage Type Check for Shareable Images

V8.3-1H1

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.

5.31.12 Program Section Attribute ABS Ignored

V8.3-1H1

On Integrity servers, 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 section attribute and prints the following informational message:

%ILINK-I-PSCATTIGN, psect attribute ABS is not supported for OpenVMS ELF sections, attribute ignored

5.31.13 Linker ACCVIOs when FP_MODE Literal Missing From Command Line

V8.3-1H1

In the Version 8.3, the Integrity server Linker encountered an access violation when the FP_MODE literal was missing on the command line.

This problem is corrected in OpenVMS Version 8.3-1H1.

5.31.14 OpenVMS Integrity servers Object Module and Image File Information Currently Unavailable

V8.3

Information about the OpenVMS Integrity servers extension to ELF (Executable and Linkable Format; the object module and image file format on Integrity servers) is not available at this time. It will be provided in a future release.

For information about the Alpha or VAX object language format, see the respective appendixes in the OpenVMS Alpha/VAX Version 7.3 OpenVMS Linker Utility Manual, available from the documentation bookshelf at the following URL:

http://h71000.www7.hp.com/doc/os732_index.html

5.31.15 Differences Between the Integrity servers Linker and the Alpha Linker

V8.3

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

5.31.16 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.

5.31.17 Linking Against Data-Reduced ELF Object Libraries Not Recommended

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 recommends that DCX data-reduced ELF object libraries first be expanded before performing Linker operations. This is a permanent condition.

5.31.18 Error in Handling Initialized Overlaid Program Sections Fixed

V8.3

In previous versions of the Integrity servers linker, the initialized overlaid program sections with zeros are incorrectly seen as compatible initializations. In OpenVMS Version 8.2 and Version 8.2­1, the Integrity servers Linker accepts sections initialized with zeros to be compatible with sections containing nonzero initial values. Under this condition, the order of modules in a link operation can result in different initial values in the image.

This problem is fixed in Version 8.3.

5.31.19 Removal of Linker Qualifiers /EXPORT_SYMBOL_VECTOR and /PUBLISH_GLOBAL_SYMBOLS

V8.3

Creating a shareable image by simply exporting all global symbols does not work. Previous Integrity servers Linker versions provide the /EXPORT_SYMBOL_VECTOR and /PUBLISH_ GLOBAL_ SYMBOLS qualifiers to assist in creating symbol vector options for all global symbols on a per-module basis. However, using these qualifiers exports the same universal symbol from different images. Because you cannot exclude exporting the same C++ template from different images, this creates problems.

Both qualifiers are removed from the Version 8.3.

This problem will be fixed for the Integrity servers Linker in a future release of OpenVMS for Integrity servers.

5.31.20 Support for Longer Symbol Names in Options

V8.3

For options, the linker internal line buffer is increased to hold 2048 characters. This allows specifying options with symbol names of the maximum supported length of 1024 characters.

5.31.21 Better Use of Memory for Linker-Created Code Stubs

V8.3

The Integrity servers linker generates code stubs, which are visible when stepping through the code with the OpenVMS Debugger. The code can be inserted for calls and can have different sizes. However, the earlier linker added the code as fixed-size code sections using the maximum necessary code size.

The Version 8.3 linker writes the code stubs using the actual size. This eliminates unused space between the stubs and might also release unused memory.

5.31.22 Compiler Support for Demangled Symbol Names

V8.3

To make symbol names unique, name mangling is used for some programming languages. Starting with Version 8.3, the linker tries to display the demangled names, also known as source code names. These names are used in linker messages and, on request, in a translation table for mangled global symbols that appears in the linker map (see HP OpenVMS Version 8.3 New Features and Documentation Overview). This feature depends on compiler support for name demangling.

5.32 LTDRIVER: CANCEL SELECTIVE Restriction

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.33 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 are enabled in a multithreaded environment. In this environment, callable mail should be used only in the initial thread.

5.34 OpenVMS System Dump Analyzer (SDA)

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

5.34.1 CLUE Commands Not Ported to OpenVMS Integrity servers

V8.2

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

CLUE CALL
CLUE ERRLOG
CLUE FRU
CLUE REGISTER