# Compaq COBOL
User Manual

Previous | Contents | Index

### B.4.4.2 LINAGE Clause

Compaq COBOL on Alpha and Compaq COBOL on VAX exhibit different behavior when handling large values for the LINAGE clause. If the line count for the ADVANCING clause of the WRITE statement is larger than 127, Compaq COBOL on Alpha advances one line, whereas VAX results are undefined.

### B.4.4.3 MOVE Statement

Unsigned computational fields can hold larger values than signed computational fields. In accordance with the ANSI COBOL Standard, the values for unsigned items should always be treated as positive. Compaq COBOL on VAX, however, treats unsigned items as signed, while Compaq COBOL on Alpha treats them as positive. Therefore, in some rare cases, a mixture of unsigned and signed data items in MOVE or arithmetic statements can produce different results between Compaq COBOL on VAX and Compaq COBOL on Alpha.

Example B-1 produces different results for Compaq COBOL for OpenVMS VAX and Compaq COBOL on Alpha.

Example B-1 Signed and Unsigned Differences

           IDENTIFICATION DIVISION.
           PROGRAM-ID. SHOW-DIFF.
           ENVIRONMENT DIVISION.
           DATA DIVISION.
           WORKING-STORAGE SECTION.
           01 A2       PIC 99    COMP.
           01 B1       PIC S9(5) COMP.
           01 B2       PIC 9(5)  COMP.
           PROCEDURE DIVISION.
           TEST-1.
               MOVE 65535 TO A2.
               MOVE A2 TO B1.
               DISPLAY B1 WITH CONVERSION.
               MOVE A2 TO B2.
               DISPLAY B2 WITH CONVERSION.
               STOP RUN.

VAX Results

                   B1 =  -1
                   B2 =  -1

Alpha Results

                   B1 =  65535
                   B2 =  65535

### B.4.4.4 SEARCH Statement

In Compaq COBOL on Alpha and in Compaq COBOL on VAX Version 5.0 and higher, the END-SEARCH and NEXT SENTENCE phrases are mutually incompatible in a SEARCH statement. If you use one, you must not use the other. This rule, which complies with the ANSI COBOL Standard, does not apply to VAX COBOL versions earlier than Version 5.0.

## B.4.5 System Return Codes

Example B-2 illustrates an illegal coding practice that exhibits different behavior on Alpha and VAX. The cause is an architectural difference in the register sets between the VAX and Alpha architectures: on Alpha, there is a separate set of registers for floating-point data types.

The bad coding practice exhibited in Example B-2 can impact OpenVMS Alpha and Tru64 UNIX systems and any supported Alpha floating-point data type.

Example B-2 Illegal Return Value Coding

    IDENTIFICATION DIVISION.
    PROGRAM-ID. BADCODING.
    ENVIRONMENT DIVISION.
    DATA DIVISION.
    FILE SECTION.
    WORKING-STORAGE SECTION.
        01  FIELDS-NEEDED.
            05 CYCLE-LOGICAL      PIC X(14) VALUE 'A_LOGICAL_NAME'.
        01  EDIT-PARM.
            05  EDIT-YR            PIC X(4).
            05  EDIT-MO            PIC XX.
        01  CMR-RETURN-CODE        COMP-1 VALUE 0.
    LINKAGE SECTION.
           01 PARM-REC.
              05 CYCLE-PARM         PIC X(6).
              05 MY-RETURN-CODE     COMP-1 VALUE 0.
    PROCEDURE DIVISION USING PARM-REC GIVING CMR-RETURN-CODE.
    P0-CONTROL.
        CALL 'LIB$SYS_TRNLOG' USING BY DESCRIPTOR CYCLE-LOGICAL,
                                    OMITTED,
                                    BY DESCRIPTOR CYCLE-PARM
                                    GIVING MY-RETURN-CODE.
        IF  MY-RETURN-CODE  GREATER 0
          THEN
            MOVE MY-RETURN-CODE TO CMR-RETURN-CODE
            GO TO P0-EXIT.
        MOVE  CYCLE-PARM  TO  EDIT-PARM.
        IF  EDIT-YR  NOT  NUMERIC
          THEN
            MOVE  4  TO CMR-RETURN-CODE, MY-RETURN-CODE.
        IF  EDIT-MO  NOT NUMERIC
          THEN
            MOVE  4  TO  CMR-RETURN-CODE, MY-RETURN-CODE.
        IF  CMR-RETURN-CODE GREATER 0
                     OR
            MY-RETURN-CODE GREATER 0
          THEN
            DISPLAY "***************************"
            DISPLAY "** BADCODING.COB  **"
            DISPLAY "** A_LOGICAL_NAME> ", CYCLE-PARM, "   **"
            DISPLAY "***************************".
    P0-EXIT.
        EXIT PROGRAM.

In Example B-2, the programmer incorrectly defined the return value for a system service call to be F_floating when it should have been binary (COMP). The programmer was depending on the following VAX behavior: in the VAX architecture, all return values from routines are returned in register R0. The VAX architecture has no separate integer and floating-point registers. The Alpha architecture defines separate register sets for floating-point and binary data. Routines that return floating-point values return them in register F0; routines that return binary values return them in register R0.

The Compaq COBOL on Alpha compiler has no method for determining what data type an external routine may return. You must specify the correct data type for the GIVING-VALUE item in the CALL statement. On the Alpha architecture, the generated code is testing F0 instead of R0 because of the different set of registers used for floating-point data items.

In the sample program, the value in F0 is unpredictable in this code sequence. In some cases, this coding practice may produce the expected behavior, but in most cases it will not.

## B.4.6 Diagnostic Messages

Several diagnostic messages have different meanings and results depending on the platform, as follows:

- Compaq COBOL on Alpha does not perform the same run-time error recovery behavior as Compaq COBOL on VAX upon receipt of the following diagnostic:

      %COBOL-E-EXITDECL, EXIT PROGRAM statement invalid in GLOBAL DECLARATIVE

- Compaq COBOL on VAX always ignores an EXIT PROGRAM in a GLOBAL USE procedure. Compaq COBOL on Alpha ignores the EXIT PROGRAM only if the GLOBAL USE is invoked from other than the current program unit.
  To produce behavior identical to Compaq COBOL for OpenVMS VAX, correct the problem causing the diagnostic.
- If one of the operands in a comparison is illegal, causing an error message, Compaq COBOL on VAX continues analyzing the statement containing the conditional, but Compaq COBOL on Alpha skips to the next statement (thus not finding any additional errors in the statement).
- If a source statement contains multiple divides and the divisor(s) are a literal zero, a figurative zero, or a variable whose value is zero, Compaq COBOL on Alpha issues a single divide-by-zero run-time diagnostic, while Compaq COBOL on VAX issues the same diagnostic for each divide-by-zero in the statement. For example, the following code produces three diagnostics with Compaq COBOL on VAX and only one diagnostic with Compaq COBOL on Alpha:

      DIVIDE 0 INTO A, B, C.

  In accordance with the ANSI COBOL Standard, both compilers allow execution to continue with unpredictable results.
- The Compaq COBOL RTL on Tru64 UNIX can give a result that differs from OpenVMS Alpha in the case where your program tries to create an ISAM file with two keys that are the same except for the status of the duplicates (one key specifies DUPLICATES and the other key does not). In this case, on Tru64 UNIX you will receive the following message (if `-rkc` is not specified):

       COB_S_ISAM_BADKEY
       ISAM file %s created with two keys that are the same except for
       their acceptance of duplicate values

  This will be translated into the COBOL status code 39, which is used for a conflict in file attributes.
  Compaq COBOL on OpenVMS Alpha does not allow duplicate keys unless directed in both key specifications.
- There is a difference between Compaq COBOL on VAX and Compaq COBOL on Alpha in the enforcement of the general rule that name conflicts should be avoided, including names used for COPY libraries. On VAX, the compiler does not enforce this rule in some cases, including COPY and PROGRAM-ID. Hence a COBOL program that compiles without error on VAX might result in a NAMCLASS error on Alpha, as follows:

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

  To avoid the error, you should either change the conflicting name or make it a literal by putting it in quotation marks, for example:

      COPY "LIBRARY-FILE" FROM COPYLIB.

## B.4.7 Storage for Double-Precision Data Items

On OpenVMS, the difference in storage format of D_floating items between the VAX and Alpha 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 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

Compaq COBOL on Alpha and Compaq 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, Compaq COBOL on Alpha returns File Status 49 (incompatible open mode), while Compaq 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, Compaq COBOL for OpenVMS Alpha and Compaq COBOL for OpenVMS VAX update the values for the RMS special registers differently for some I/O operations. On OpenVMS Alpha, 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 Compaq 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 OpenVMS Alpha, 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 Compaq 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 VAX. On Alpha, 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

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

> RMS_STS
> RMS_STV
> RMS_CURRENT_STS
> RMS_CURRENT_STV

## B.4.10 Calling Shareable Images

On OpenVMS, Compaq COBOL exhibits different behavior on Alpha and VAX when calling a subprogram installed as a shareable image. On Alpha, 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, Compaq 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, Compaq COBOL exhibits behavior more like Compaq 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 a Compaq 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 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 Compaq COBOL on Alpha and Compaq COBOL on VAX:

- Results of numeric and integer intrinsic functions might be formatted differently by a DISPLAY statement.
- OpenVMS VAX and OpenVMS Alpha handle COMP-2 items differently. As a result, DISPLAY of a USAGE COMP-2 data item's low order digits might differ on Alpha and VAX.
- Compaq COBOL on Alpha issues the ALL_LOST (all digits lost) warning diagnostic in different cases than Compaq COBOL on VAX.
- When overflow occurs in an arithmetic statement without a SIZE ERROR phrase and native arithmetic is used, the results are undefined. Compaq COBOL on VAX often returns the low order digits of the true result in such cases; Compaq COBOL on Alpha does not. When standard arithmetic is used, the results are unaltered.
- The precision of intermediate results is different between Compaq COBOL on VAX and Compaq COBOL on Alpha. 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 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 systems. Also, any programs that check for specific floating values rather than ranges of values might be impacted.
- The results of numeric comparisons with Compaq COBOL on VAX and Compaq COBOL on Alpha are undefined with invalid decimal data. Compaq COBOL on Alpha 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 Compaq COBOL on Alpha.
- There is some inevitable incompatibility in results of arithmetic operations involving large intermediate values between Compaq COBOL on Alpha and Compaq COBOL on VAX. On Alpha, 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 Compaq COBOL on Alpha and Compaq COBOL on VAX. Even with CIT3, however, there are differences:
  - Invalid decimal data
    In Compaq COBOL on Alpha, 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 Compaq COBOL on VAX.
  - Floating-point data items
    On Alpha, COBOL expressions involving COMP-1 or COMP-2 data items are converted to G_floating (on OpenVMS Alpha) or T_floating before conversion to CIT3. CIT3 operations involving D_floating (on OpenVMS Alpha) 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. Compaq COBOL on Alpha and Compaq 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 Compaq COBOL implementation on Alpha is compatible with Compaq COBOL on VAX with /STANDARD=85.
  - Special contexts
    The CIT3 implementation does not provide support equivalent to the Compaq COBOL on VAX behavior for intrinsic functions MEDIAN, NUMVAL, and NUMVAL-C.
    See Section 2.7.1 in this manual, and refer to the Compaq COBOL Reference Manual for more information on the /MATH_INTERMEDIATE and /ARITHMETIC qualifiers.

# B.5 Compaq COBOL Differences Between Releases and Across Operating Systems

Certain Compaq COBOL features have unique behaviors, depending on which operating system you are using, and sometimes these differences differ from release to release. You should refer to the Release Notes to get the most recent information about these differences. The next few sections describe distinct differences in feature implementation and behavior.

## B.5.1 REWRITE

A REWRITE operation for an ISAM file is dependent on whether the DUPLICATES clause for the primary key is specified. There is an ambiguity when DUPLICATES is specified in one way at the time a file is created, and another way when it is reopened (a program should use the same declarations). Both Compaq COBOL for OpenVMS VAX and Compaq COBOL for OpenVMS Alpha use the specification of the current program. So, if DUPLICATES was specified for the primary key when a file was created, but not when reopened by the current program, the behavior will be as if DUPLICATES were not allowed.

Compaq COBOL for Tru64 UNIX issues a severe run-time error if there is a mismatch, unless relax key checking (the `-rkc` flag) is specified, in which case the behavior is inconsistent. In many cases, you will get the behavior of the specification when the file was created, but you should not rely on this.

## B.5.2 File Sharing and Record Locking

With Compaq COBOL for Tru64 UNIX, certain file-sharing and record-locking operations might behave differently from the same operations on Compaq COBOL on OpenVMS Alpha. Compaq COBOL for Tru64 UNIX issues warning diagnostics where applicable.

- File sharing for sequential and relative files on all systems remains essentially the same.
- File sharing for indexed files has the following limitation: The OPEN statement ALLOWING READERS phrase is minimally supported for indexed files on Tru64 UNIX systems. Using the ALLOWING READERS phrase for indexed files is not recommended.
- File-sharing protocols for all file organizations are in effect for Tru64 UNIX systems for the OPEN statement in OUTPUT mode, which is similar to EXTEND and I-O modes. On Tru64 UNIX systems, access is denied or granted depending on the file lock requested and the file lock held (with the exception of the READERS support noted previously). On OpenVMS Alpha, a new version of the file is always created.
- On Tru64 UNIX, manual record locking for files with the indexed organization has the following limitations:
  - For the READ and START statements, the REGARDLESS phrase is not fully supported. The read or start operation is performed but the soft record lock status is not returned.
  - The START statement does not detect or acquire a record lock.
  - The READ statement with the ALLOWING READERS phrase is not supported. It is treated as NO OTHERS if the file is opened in I-O mode or it is treated as ALL if the file is opened in INPUT mode.
  - The REWRITE and WRITE statements do not retain record locks.
  - The (current) RECORD phrase is not supported for the UNLOCK statement. The ALL RECORDS phrase is assumed for all UNLOCK statements.

Previous | Next | Contents | Index