V8.3

There is very little remaining 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 a user sets 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.17 HP COBOL Run-Time Library (RTL)

V8.3

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

5.18 HP Fortran for I64

V8.3

The HP Fortran for OpenVMS Integrity servers 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 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:
• 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 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.19 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 I64 systems. The following notes pertain to the MACRO compiler.

5.19.1 HP MACRO for OpenVMS I64

V8.3

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

• Prior to OpenVMS Version 8.3, the compiler generated the wrong code for the HALT instruction. On I64 platforms, 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 builtin 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 will 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 builtin can be used as a workaround. See the following Macro-32 paragraphs for information about this builtin. 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 builtin can be used as a workaround. The IA64_LD8_A builtin, new in Version 8.3, generates a special form of the Itanium "ld8" instruction that also places the fetched address into the ALAT (Advanced Load Address Table). 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 builtin. 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.19.3 /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.4 /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.5 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.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.35.

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

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.20.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.20.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.21 Intel® Assembler (I64 Only)

Permanent Restriction

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. This is a permanent condition.

5.22.3 Librarian Fails to Report Errors When Process Quota Too Low

Permanent Restriction

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.23 Analyze Utility for OpenVMS (I64 Only)

The following release notes pertain to the Analyze utility on OpenVMS I64.

5.23.1 Releasing Process Resources Fixed in I64 Analyze Image /SELECT

V8.3

For I64 image files, ANALYZE/SELECT did not release process resources; a wild card operation could fail with SECTBLFUL (or other exceeded quota messages).

This problem is fixed in Version 8.3.

5.23.2 Selective Output for Debug Line Information Fixed

V8.3

For I64 image files, ANALYZE/IMAGE/SELECT=DEBUG=LINE did not format the corresponding debug line information. The line selection only worked with /TRACE.

This problem is fixed in Version 8.3.

5.24 Command Definition Utility (I64 Only)

The following release notes pertain to the Command Definition utility on OpenVMS I64.

5.24.1 Record Attributes Fixed for I64 Images

V8.3

For I64 images (command tables), the Command Definition Utility (CDU) set record attributes, which caused warnings when copying or appending image files. Despite these warning messages, the copied or appended files contained correct content.

In Version 8.3, CDU sets compatible attributes that allow these file operations to complete without a warning message.

5.25 Linker Utility for OpenVMS Alpha

The following release notes pertain to the Alpha Linker Utility on all OpenVMS platforms. For I64 Linker release notes, see Section 5.26.

5.25.1 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.25.2 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.25.3 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.