Compaq COBOL
User Manual


Previous Contents Index

B.4.2.6 REPLACE and COPY REPLACING Statements

For the REPLACE and COPY REPLACING statements, the line numbers in compiler listing files differ between Compaq COBOL and Compaq COBOL for OpenVMS VAX. Compaq COBOL arranges the line number for the replacement line to correspond to its line number in the original source text, while subsequent line numbers differ. Compaq COBOL for OpenVMS VAX arranges the line numbers consecutively.

The following source program produces compiler listing files with different ending line numbers, depending on whether you compile the program with Compaq COBOL or Compaq COBOL for OpenVMS VAX.

Source File


 
                REPLACE ==A VERY LONG STATEMENT== by ==EXIT PROGRAM==. 
                A 
                VERY 
                LONG 
                STATEMENT. 
                DISPLAY "To REPLACE or not to REPLACE". 
 

Compaq COBOL Listing File for REPLACE Statement


 
 
        ----------------------------------------------------------------- 
                1 REPLACE ==A VERY LONG STATEMENT== by ==EXIT PROGRAM==. 
                2 EXIT PROGRAM. 
                6 DISPLAY "To REPLACE or not to REPLACE". 
 

Compaq COBOL for OpenVMS VAX Listing File for REPLACE Statement


 
 
        ----------------------------------------------------------------- 
                1 REPLACE ==A VERY LONG STATEMENT== by ==EXIT PROGRAM==. 
                2 EXIT PROGRAM. 
                3 DISPLAY "To REPLACE or not to REPLACE". 

The diagnostic messages for the COBOL source statements REPLACE and DATE-COMPILED result in compiler listing files that contain multiple instances of the source line.

For a REPLACE statement in a Compaq COBOL program, if the Compaq COBOL compiler issues a message on the replacement text, the message corresponds to the original text in the program, as shown in the following compiler listing file.

Compaq COBOL Listing File for REPLACE Statement


 
 
                     18 P0.     REPLACE ==xyzpdqnothere== 
                     19                         BY ==nothere==. 
                     20 
                     21         copy "drep3hlib". 
        L            22         display xyzpdqnothere. 
                     ...................1 
             %COBOL-F-UNDEFSYM, (1) Undefined name 
 
        LR           22     display nothere. 
 

In a Compaq COBOL for OpenVMS VAX program, the compiler message corresponds to the replacement text, as shown in the following compiler listing file.

Compaq COBOL for OpenVMS VAX Listing File for REPLACE Statement


 
 
        18         P0. REPLACE ==xyzpdqnothere== 
        19                             BY ==nothere==. 
        20 
        21             copy "drep3hlib". 
        22LR           display nothere. 
                               1 
             %COBOL-F-ERROR  349, (1) Undefined name 

B.4.2.7 DATE COMPILED Statement

The following two compiler listing files demonstrate the difference between using the DATE-COMPILED statement with Compaq COBOL and Compaq COBOL for OpenVMS VAX.

Compaq COBOL Listing File for DATE-COMPILED Statement


 
             33 * 
             34 date-compiled 
                .............1 
%COBOL-E-NODOT, (1) Missing period is assumed 
 
             34 date-compiled  16-Jul-1992. 
             35 security. none. 

Compaq COBOL for OpenVMS VAX Listing File for DATE-COMPILED Statement


        
   33        * 
   34         date-compiled   16-Jul-1992. 
                           1 
%COBOL-E-ERROR   65, (1) Missing period is assumed 
   35         security. none. 
 

B.4.2.8 Compiler Listings and Separate Compilations (OpenVMS)

The /SEPARATE_COMPILATION qualifier produces distinct listings. For separately compiled programs (SCP) compiled without /SEPARATE_COMPILATION, the listings are as follows:

The /SEPARATE_COMPILATION result would be as follows:

Note that this is consistent with listings produced by Compaq COBOL for OpenVMS VAX.

B.4.3 Output Formatting

VFU-CHANNEL

Compaq COBOL does not support VFU-CHANNEL and thus provides no direct support for VFU and VFP (Vertical Forms Unit utilities and Vertical Forms Printing).

Control byte sequences

Compaq COBOL and Compaq COBOL for OpenVMS VAX may use different control byte sequences in VFC files to accomplish similar output file formatting.

VFC files

VFC formatted REPORT WRITER or LINAGE files are normally viewed by using the TYPE command or by printing them out. If you need to mail reports through electronic mail or to bring them up in an editor, you can accomplish this by compiling with /NOVFC on the compile command line.

All REPORT WRITER and LINAGE files that are opened in a single .COB source file will have the same format (either VFC or NOVFC). VFC is the default. If the /NOVFC qualifier is present, the NOVFC condition is set for each source file. For example:


   $ COBOL A/NOVFC,B/VFC,C/NOVFC,D 

In this example, source files B and D will produce reports in VFC format. (Behavior is different when the source file list items are separated by plus (+) signs. See Section 1.3.2.1, Format of the COBOL Command on OpenVMS Alpha.) <>

On Windows NT and Tru64 UNIX, the REPORT WRITER and LINAGE files produce ASCII file output, which can be viewed or mailed electronically.

B.4.4 Compaq COBOL and Compaq COBOL for OpenVMS VAX Statement Differences

The following COBOL statements behave differently when used on Compaq COBOL and Compaq COBOL for OpenVMS VAX:

B.4.4.1 ACCEPT and DISPLAY Statements

When you use any extended feature of ACCEPT or DISPLAY within your program, visible differences in behavior between Compaq COBOL and Compaq COBOL for OpenVMS VAX exist in some instances. The Compaq COBOL behavior in these instances is as follows:

Screen update behavior is not identical on Compaq COBOL and Compaq COBOL for OpenVMS VAX, and they sometimes use different escape sequences for ACCEPT and DISPLAY to accomplish similar screen formatting.

If you attempt to use extended ACCEPT/DISPLAY with input redirected from a file or output redirected to a file, the operation differs between Compaq COBOL for OpenVMS VAX and Compaq COBOL. In general, the Compaq COBOL RTL attempts to use ANSI ACCEPT/DISPLAY to handle all ACCEPT and DISPLAY statements in this situation. For example, if you use DISPLAY AT LINE or ACCEPT DEFAULT, the Compaq COBOL RTL will ignore the extensions (that is, LINE or DEFAULT) if you redirect output to a file or input from a file. The Compaq COBOL RTL for OpenVMS VAX ignores some, but not all, ACCEPT/DISPLAY extensions when input is redirected from a file or output is redirected to a file.

END-DISPLAY Difference

In Compaq COBOL, a DISPLAY statement in an ON EXCEPTION for an ACCEPT statement must be terminated, with, for example, END-DISPLAY. END-DISPLAY is supported for all formats of DISPLAY.

In Compaq COBOL for OpenVMS VAX, END-DISPLAY is not supported. If you convert code with ACCEPT ON EXCEPTION to handle DISPLAY on both VAX and Alpha, you need to PERFORM a paragraph with the DISPLAY from the ON EXCEPTION processing in the ACCEPT.

For more information about ACCEPT and DISPLAY, including sample programs, see Chapter 11, Using ACCEPT and DISPLAY Statements for Input/Output and Video Forms.

B.4.4.2 LINAGE Clause

Compaq COBOL and Compaq COBOL for OpenVMS VAX exhibit different behavior when handling large values for the LINAGE statement. If the line count for the ADVANCING clause of the WRITE statement is larger than 127, Compaq COBOL advances one line. Compaq COBOL for OpenVMS 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 for OpenVMS VAX, however, treats unsigned items as signed, while Compaq COBOL 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 for OpenVMS VAX and Compaq COBOL.

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

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. 
 
 

Compaq COBOL for OpenVMS VAX Results


               B1 =  -1 
               B2 =  -1 
 
 

Compaq COBOL Results


               B1 =  65535 
               B2 =  65535 
 
 

B.4.4.4 SEARCH Statement

In Compaq COBOL and in Compaq COBOL for OpenVMS 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 Compaq COBOL for OpenVMS VAX 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 Compaq COBOL and Compaq COBOL for OpenVMS 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, Windows NT, 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 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 upon the platform on which you are programming:

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 upon how many D-float computations and stores the compiler has performed before outputing 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 Windows NT and on the Tru64 UNIX operating system. <>

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

B.4.8 File Status Values

Compaq COBOL and Compaq COBOL for OpenVMS 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 returns File Status 49 (incompatible open mode), while Compaq COBOL for OpenVMS 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 that will be experienced depending on your 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. The Compaq COBOL run-time system checks for some I/O error situations before attempting the RMS operation. In those situations, the Compaq COBOL 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, in the case of a file that was not successfully opened, any subsequent Compaq 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 Compaq COBOL and Compaq COBOL for OpenVMS VAX applications. Upon the successful completion of an RMS operation on a Compaq COBOL file, the RMS special registers always contain RMS completion codes. Upon the successful completion of an RMS operation on a Compaq COBOL for OpenVMS VAX file, the RMS special registers usually contain RMS completion codes, but occasionally these registers may contain COBOL-specific completion codes. <>

Difference from Compaq COBOL for OpenVMS VAX

Compaq COBOL 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


Previous Next Contents Index