![[Digital logo]](../../IMAGES/DIGITAL-LOGO.GIF){kind=logo}
![[HR]](../../IMAGES/REDBAR.GIF)
For a REPLACE statement in a DEC COBOL program, if the DEC 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.
DEC 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 VAX COBOL program, the compiler message corresponds to the replacement text, as shown in the following compiler listing file.
VAX COBOL 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
The following two compiler listing files demonstrate the difference between using the DATE-COMPILED statement with DEC COBOL and VAX COBOL.
DEC 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.
VAX COBOL 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.
For the REPLACE and COPY REPLACING statements, the line numbers in compiler listing files differ between DEC COBOL and VAX COBOL. DEC 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. VAX COBOL 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 DEC COBOL or VAX COBOL.
Source File:
REPLACE ==A VERY LONG STATEMENT== by ==EXIT PROGRAM==.
A
VERY
LONG
STATEMENT.
DISPLAY "To REPLACE or not to REPLACE".
DEC 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".
VAX COBOL 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 /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 VAX COBOL.
11.3.3.3 Output Formatting
DEC 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
DEC COBOL and VAX COBOL may use different control byte sequences in VFC files to accomplish similar output file formatting.
Screen formatting
DEC COBOL and VAX COBOL may use different escape sequences for ACCEPT and DISPLAY to accomplish similar screen 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 Format of the COBOL Command on OpenVMS Alpha.)
11.3.3.4 DEC COBOL and VAX COBOL Statement Differences
The following COBOL statements behave differently when used on DEC COBOL and VAX COBOL:
When you use any extended feature of ACCEPT or DISPLAY within your program, visible differences in behavior between DEC COBOL and VAX COBOL exist in some instances. The DEC COBOL behavior in these instances is as follows:
EXIT PROGRAM in a called program does not reset PERFORM ranges. With
VAX COBOL, when a program is re-entered after exiting with an EXIT
PROGRAM, then all PERFORM ranges from the previous execution have been
satisfied.
11.3.3.4.3 LINAGE Clause
DEC COBOL and VAX COBOL 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,
DEC COBOL advances one line. VAX COBOL results are undefined.
11.3.3.4.4 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. VAX COBOL, however, treats unsigned items as signed, while DEC 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 VAX COBOL and DEC COBOL.
Example 11-1 produces different results for VAX COBOL and DEC COBOL:
Example 11-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 COBOL Results:
B1 = -1
B2 = -1
DEC COBOL Results:
B1 = 65535
B2 = 65535
In DEC COBOL and in VAX COBOL 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.
11.3.3.5 System Return Codes
Example 11-2 illustrates an illegal coding practice that exhibits different behavior on DEC COBOL and VAX COBOL. 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 11-2 can impact any supported Alpha floating point data type.
Example 11-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 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 RETURN-CODE.
IF RETURN-CODE GREATER 0
THEN
MOVE 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, RETURN-CODE.
IF EDIT-MO NOT NUMERIC
THEN
MOVE 4 TO CMR-RETURN-CODE, RETURN-CODE.
IF CMR-RETURN-CODE GREATER 0
OR
RETURN-CODE GREATER 0
THEN
DISPLAY "***************************"
DISPLAY "** BADCODING.COB **"
DISPLAY "** A_LOGICAL_NAME> ", CYCLE-PARM, " **"
DISPLAY "***************************".
P0-EXIT.
EXIT PROGRAM.
In Example 11-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 DEC 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.
11.3.3.6 Diagnostic Messages
Several diagnostic messages have different meanings and results depending upon the platform on which you are programming:
%COBOL-E-EXITDECL, EXIT PROGRAM statement invalid in
GLOBAL DECLARATIVE
DIVIDE 0 INTO A, B, C.
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.
For information about storage format for floating-point data types, see
the Alpha Architecture Handbook.
11.3.3.8 High-Order Truncation of Data Items
DEC COBOL is more sensitive than VAX COBOL to potential high-order truncation of data items. This is illustrated in the following example, which was compiled with /WARNINGS=ALL qualifier:
WORKING-STORAGE SECTION.
01 K4 PIC 9(9) COMP.
PROCEDURE DIVISION.
01-MAIN-SECTION SECTION.
01-MAIN.
DISPLAY K4 WITH CONVERSION.
In this situation DEC COBOL, unlike VAX COBOL, produces the following message:
DISPLAY K4 WITH CONVERSION.
............^
Possible high-order truncation ...
RELATIVE file operations may also produce this diagnostic.
11.3.3.9 File Status Values
DEC COBOL and VAX COBOL return different file status values
when you open a file in EXTEND mode and then try to REWRITE it. For
this undefined operation, DEC COBOL returns File Status 49
(incompatible open mode), while VAX COBOL returns File Status 43
(no previous READ).
11.3.3.10 Key of Reference
With OpenVMS Alpha, when an ISAM file is being accessed dynamically and
the key of reference is a secondary key, a WRITE, DELETE, or REWRITE
changes the key of reference from the secondary key to the primary key.
11.3.3.11 RMS Special Registers
There are some differences in the behavior of RMS Special Registers that will be experienced depending on your platform.
Loading Differences
At run time DEC COBOL and VAX COBOL update the values for the RMS special registers differently for some I/O operations. The DEC COBOL run-time system checks for some I/O error situations before attempting the RMS operation. In those situations, the DEC COBOL run-time system does not attempt an RMS operation and the RMS special register retains its previous value. The VAX COBOL 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 DEC 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 VAX COBOL 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 DEC COBOL and VAX COBOL applications. Upon the successful completion of an RMS operation on a DEC COBOL file, the RMS special registers always contain RMS completion codes. Upon the successful completion of an RMS operation on a VAX COBOL file, the RMS special registers usually contain RMS completion codes, but occasionally these registers may contain COBOL-specific completion codes.
DEC COBOL does not allow the following compiler-generated variables to be declared as user variables, as VAX COBOL does:
DEC COBOL and VAX COBOL exhibit different behavior when calling
a subprogram installed as a shareable image. With DEC COBOL, 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.) With
VAX COBOL, the program name you specify in a CALL (or CANCEL)
statement must be a literal. In addition, VAX COBOL programs
installed as shareable images cannot contain external files. (See
Developing DEC COBOL Programs and OpenVMS Linker Utility Manual for more information about shareable
images.)
11.3.3.13 Sharing Common Blocks
To prevent problems when you link a DEC 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, 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, see the OpenVMS Linker Utility Manual.
11.3.3.14 Arithmetic Operations
Several arithmetic operations differ in behavior between DEC COBOL and VAX COBOL, depending upon your platform:
COMPUTE D = (A / B) / C.
...could be written as
COMPUTE TMP1 = A / B.
COMPUTE D = TMP1 / C.
Files created by different programming languages may require special processing because of language and character set incompatibilities. The most common incompatibilities are data types and data record formats. You should be aware of the following:
Data Type Differences
Data types vary by programming language and by utilities. For example, DEC Fortran does not support the packed-decimal data type and, therefore, cannot easily use PACKED-DECIMAL data in COBOL files.
You can use the following techniques to overcome data type incompatibilities:
In the following example, the input file is written in EBCDIC. This creates a file that would be difficult to handle in most languages other than COBOL on the OpenVMS Alpha operating system.
ENVIRONMENT DIVISION.
CONFIGURATION SECTION.
SPECIAL-NAMES. ALPHABET FOREIGN-CODE IS EBCDIC.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
SELECT INPUT-FILE ASSIGN TO "INPFIL"
CODE-SET IS FOREIGN-CODE.
.
.
.
The following are X/OPEN reserved words in DEC COBOL but not in VAX COBOL:
| AUTO | EXCLUSIVE | REQUIRED |
| AUTOMATIC | FOREGROUND-COLOR | RETURN-CODE |
| BACKGROUND-COLOR | FULL | REVERSE-VIDEO |
| BLINK | HIGHLIGHT | SECURE |
| EOL | LOWLIGHT | UNDERLINE |
| EOS | MANUAL |
The command line qualifier /RESERVED_WORDS=NOXOPEN causes these
reserved words to be treated as though they were not reserved words.
11.3.6 Debugger Support Differences
DEC COBOL debugger support differs in several ways from VAX COBOL:
%COBOL-I-DEBUGOPT, /NOOPTIMIZE is recommended with /DEBUG
DEC COBOL does not support the DECset/LSE Program Design Facility,
the /DESIGN qualifier, design comments, or pseudocode placeholders.
11.3.8 DBMS Support
DEC COBOL support for Oracle DBMS has some differences depending on whether you are developing programs with DEC COBOL or with VAX COBOL.
With DEC COBOL, when you use multistream Oracle DBMS DML, you
must access different schemas or streams from separate source files.
11.4 Compatibility of Digital Fortran on OpenVMS Alpha and OpenVMS VAX Systems
This section discusses the compatibility between Digital Fortran for OpenVMS Alpha systems and Digital Fortran 77 for OpenVMS VAX Systems (formerly VAX FORTRAN) in the following areas:
Digital Fortran for OpenVMS Alpha includes ANSI FORTRAN-77 and ISO/ANSI Fortran 9x standard features, as well as the Digital Fortran 77 for OpenVMS VAX Systems extensions to these Fortran standards, including:
6459P013.HTM OSSG Documentation 22-NOV-1996 13:07:24.52
Copyright © Digital Equipment Corporation 1996. All Rights Reserved.