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:

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:

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.


Previous Next Contents Index