HP OpenVMS Systems Documentation

HP COBOL
User Manual

%COBOL-E-NAMCLASS, Multiply defined name - name used in more than one
user-defined word class at line number ...

COPY "LIBRARY-FILE" FROM COPYLIB.

OpenVMS Alpha supports VAX floating-point data types and IEEE floating point data types in hardware. OpenVMS I64 supports IEEE floating-point in hardware and VAX floating-point data types in software.

The OpenVMS I64 compilers provide /FLOAT=D_FLOAT and /FLOAT=G_FLOAT qualifiers to enable you to produce VAX floating-point data types. If you do not specify one of these qualifiers, IEEE floating-point data types will be used.

You can test an application's behavior with IEEE floating-point values on Alpha by compiling it with an IEEE qualifier on OpenVMS Alpha. If that produces acceptable results, you can build the application on an I64 system using the same qualifier.

When you compile an OpenVMS application that specifies an option to use VAX floating-point on I64, the compiler automatically generates code for converting floating-point formats. Whenever the application performs a sequence of arithmetic operations, this code does the following:

1. Converts VAX floating-point formats to either IEEE single or IEEE double floating-point formats.
2. Performs arithmetic operations in IEEE floating-point arithmetic.
3. Converts the resulting data from IEEE formats back to VAX formats.

Where no arithmetic operations are performed (VAX float fetches followed by stores), conversions do not occur. The code handles these situations as moves.

In a few cases, arithmetic calculations might have different results because of the following differences between VAX and IEEE formats:

Values of numbers represented
Rounding rules
Exception behavior

On OpenVMS, the difference in storage format of D_floating items between the VAX and Alpha and I64 architectures produces slightly different answers when validating execution results. The magnitude of the difference depends on how many D-float computations and stores the compiler has performed before outputting the final answer. This behavior difference may cause some difficulty if you attempt to validate output generated by your program running on OpenVMS Alpha and OpenVMS I64 systems against output generated by OpenVMS VAX systems when outputting COMP-2 data to a file.

Only IEEE floating point is available on the Tru64 UNIX operating system.

For information about storage format for floating-point data types, refer to the Alpha Architecture Reference Manual, available from Digital Press.

B.4.8 File Status Values

HP COBOL on Alpha and I64 and HP COBOL on VAX return different file status values when you open a file in EXTEND mode and then try to REWRITE it. For this undefined operation, HP COBOL on Alpha and I64 returns File Status 49 (incompatible open mode), while HP COBOL on VAX returns File Status 43 (no previous READ).

B.4.9 RMS Special Registers (OpenVMS)

There are some differences in the behavior of RMS Special Registers depending on your OpenVMS platform.

Loading Differences

At run time, HP COBOL for OpenVMS Alpha and I64 and HP COBOL for OpenVMS VAX update the values for the RMS special registers differently for some I/O operations. On Alpha and I64, the run-time system checks for some I/O error situations before attempting the RMS operation; in those situations, the run-time system does not attempt an RMS operation and the RMS special register retains its previous value. The HP COBOL for OpenVMS VAX run-time system performs all RMS operations without any prior checking of the I/O operation. As a result, the run-time system always updates the values for the RMS special registers for each I/O operation.

For example, on Alpha and I64, in the case of a file that was not successfully opened, any subsequent COBOL record operation (READ, WRITE, START, DELETE, REWRITE, or UNLOCK) fails without invoking RMS. Thus, the values placed in the RMS special registers for the failed OPEN operation remain unchanged for the subsequent failed record operations on the same file. The same subsequent record operations on HP COBOL for OpenVMS VAX always invoke RMS, which attempts the undefined operations and returns new values to the RMS special registers.

There is one other instance when the RMS special registers can contain different values for applications on OpenVMS Alpha and I64 and VAX. On Alpha and I64, upon the successful completion of an RMS operation on a COBOL file, the RMS special registers always contain RMS completion codes. On VAX, upon the successful completion of an RMS operation on a COBOL file, the RMS special registers usually contain RMS completion codes, but occasionally these registers may contain COBOL-specific completion codes.

Difference in Rule for Compiler-Generated and User Variables

HP COBOL for OpenVMS Alpha and I64 does not allow the following compiler-generated variables to be declared as user variables, as HP COBOL for OpenVMS VAX does:

RMS_STS
RMS_STV
RMS_CURRENT_STS
RMS_CURRENT_STV

On OpenVMS, HP COBOL exhibits different behavior on Alpha or I64 than it does on VAX when calling a subprogram installed as a shareable image. On Alpha and I64, the program name you specify in a CALL statement can be either a literal or a data-name. (The same is true for the CANCEL statement.) On VAX, the program name you specify in a CALL (or CANCEL) statement must be a literal. In addition, on VAX, HP COBOL programs installed as shareable images cannot contain external files. (See Chapter 1 and refer to the OpenVMS Linker Utility Manual for more information about shareable images.)

On Tru64 UNIX systems, HP COBOL exhibits behavior more like HP COBOL for OpenVMS VAX with regard to shared objects. (Shared objects are the Tru64 UNIX equivalent of OpenVMS shared images.) For more information, see Chapter 12, Interprogram Communication.

B.4.11 Sharing Common Blocks (OpenVMS)

On OpenVMS, to prevent problems when you link an HP COBOL program and want to share a common block between processes, you should set the PSECT attribute to SHR. The defaults are SHR on OpenVMS Alpha and OpenVMS I64 systems and NOSHR on OpenVMS VAX systems. Also, you should add a SYMBOL_VECTOR to the linker options file of the shareable image, as follows:

SYMBOL_VECTOR = (psect-name = PSECT)

For more information, refer to the OpenVMS Linker Utility Manual.

B.4.12 Arithmetic Operations

The following arithmetic operations differ in behavior between HP COBOL on Alpha and I64 systems and HP COBOL on VAX:

• Results of numeric and integer intrinsic functions might be formatted differently by a DISPLAY statement.
• OpenVMS VAX handles COMP-2 items in a different way than OpenVMS Alpha and I64 do. As a result, DISPLAY of a USAGE COMP-2 data item's low order digits might be slightly different on Alpha and I64 systems than it would be on VAX.
• HP COBOL on Alpha and I64 issues the ALL_LOST (all digits lost) warning diagnostic in different cases than HP COBOL on VAX.
  For example, if you use POINTER and the size of the data item is not sufficient to hold an address, HP COBOL's more thorough analysis on Alpha and I64 will detect this situation and result in the ALL_LOST warning diagnostic.
• When overflow occurs in an arithmetic statement without a SIZE ERROR phrase and native arithmetic is used, the results are undefined. HP COBOL on VAX often returns the low order digits of the true result in such cases; HP COBOL on Alpha and I64 does not. When standard arithmetic is used, the results are unaltered.
• The precision of intermediate results is different between HP COBOL on VAX and HP COBOL on Alpha and I64. This is most noticeable in COMPUTE operations involving a divide. If you need a specific precision for an intermediate result, you should use a temporary variable with the desired precision. For example:

  COMPUTE D = (A / B) / C.

  ...could be written as

  COMPUTE TMP1 = A / B. COMPUTE D = TMP1 / C.

  
  The precision to be used for the calculation A / B is established by your declaration of TMP1.
• On Tru64 UNIX, the VAX floating point data types F_FLOAT, D_FLOAT, and G_FLOAT are not supported. On OpenVMS Alpha and I64 systems, F_FLOAT and D_FLOAT are the defaults for floating point. This difference potentially affects reading data files with COMP-1 and COMP-2 keys built on OpenVMS Alpha and I64 systems. Also, any programs that check for specific floating values rather than ranges of values might be impacted.
• The results of numeric comparisons with HP COBOL on VAX and HP COBOL on Alpha and I64 are undefined with invalid decimal data. HP COBOL on Alpha and I64 includes the /CHECK=DECIMAL and -check decimal features to do a more complete analysis of invalid decimal data. These options can be particularly helpful when you are migrating programs to HP COBOL on Alpha and I64.
• The results of numeric operations which produce undefined results (for example, when the size error condition is raised, but the ON SIZE ERROR clause is not used) are likely to be different across VAX, Alpha, and I64.
• There is some inevitable incompatibility in results of arithmetic operations involving large intermediate values between HP COBOL on Alpha and I64 and HP COBOL on VAX. On Alpha and I64, to minimize the differences, you can use the /MATH_INTERMEDIATE=CIT3 qualifier (or -math_intermediate cit3 ). With it, use the /ARITHMETIC=NATIVE qualifier (or -arithmetic native ), which is the default. (Specifying /ARITHMETIC=STANDARD would force /MATH_INTERMEDIATE=CIT4.)
  CIT3 gives improved compatibility between HP COBOL on Alpha and I64 HP COBOL on VAX. Even with CIT3, however, there are differences:
  • Invalid decimal data
    In HP COBOL on Alpha and I64, invalid decimal data detection takes place before any possible conversion to CIT3. CIT3 operations on data items containing invalid decimal data will get results possibly different from those with HP COBOL on VAX.
  • Floating-point data items
    On Alpha and I64, COBOL expressions involving COMP-1 or COMP-2 data items are converted to G_floating or T_floating (depending on the setting for /FLOAT) before conversion to CIT3. CIT3 operations involving D_floating (on OpenVMS Alpha and I64) data items, in particular, will get different results from VAX.
  • Undefined results
    If an abnormal condition arises during a CIT3 operation, for example, INTEXPOVE (intermediate exponent overflow), and the program continues, and it is not an arithmetic statement with an ON SIZE ERROR clause, then the values that are stored in destination items will be undefined. HP COBOL on Alpha and I64 and HP COBOL on VAX are highly likely to get different undefined results in such cases.
  • STANDARD dependency
    On VAX, the /STANDARD qualifier has an effect on when arithmetic expression analysis switches to one of the CIT forms. When you specify /STANDARD=V3 (-std v3), CIT is used when more than 18 digit intermediate results are needed. With /STANDARD=85 (-std 85), CIT is used when more than 31 digit intermediate results are needed. The HP COBOL implementations on Alpha and I64 are compatible with HP COBOL on VAX with /STANDARD=85.
  • Special contexts
    The CIT3 implementation does not provide support equivalent to the HP COBOL on VAX behavior for intrinsic functions MEDIAN, NUMVAL, and NUMVAL-C.
    See Section 2.7.1 in this manual, and refer to the HP COBOL Reference Manual for more information on the /MATH_INTERMEDIATE and /ARITHMETIC qualifiers.