HP 3000 Manuals HP 3000 Manuals
Incompatible Features
Incompatible features are those that work differently in ANSI85 and
ANSI74. When you invoke the COBOL compiler through its ANSI85 entry
point, it compiles these features according to ANSI COBOL 1985. When you
invoke the compiler through its ANSI74 entry point, it compiles them
according to ANSI COBOL 1974.
There are four exceptions, features that both entry points compile
according to ANSI COBOL 1985. See "CANCEL and STOP RUN Statements,"
"EXIT PROGRAM Statement," and "Exponentiation."
ALPHABET Keyword
The keyword ALPHABET is required in the ALPHABET clause of an ANSI85
program. In an ANSI74 program, it is optional.
Example.
The following paragraph is legal in ANSI74:
SPECIAL-NAMES. WORD-1 IS WORD-2.
In ANSI85, the above must be changed to:
SPECIAL-NAMES. ALPHABET WORD-1 IS WORD-2.
Justification for Changing the ALPHABET Keyword.
Implementor-names are system-names. Alphabet-names and mnemonic-names
are user-defined words. In ANSI COBOL 1985, system-names and
user-defined words form intersecting sets and can therefore contain the
same words. In the legal following clause, if WORD-1 is both an
implementor-name and an alphabet-name, and WORD-2 is both a mnemonic-name
and an implementor-name, then it is impossible to tell whether the
implementor-name clause or the alphabet-name clause is intended.
SPECIAL-NAMES.
WORD-1 IS WORD-2.
The introduction of the keyword ALPHABET in the alphabet-name clause
resolves this ambiguity.
This problem did not exist in ANSI COBOL 1974 because system-names and
user-defined words formed disjoint sets (therefore, the above clause was
illegal). The keyword ALPHABET did not appear in the alphabet-name
clause of the SPECIAL-NAMES paragraph in ANSI COBOL 1974.
Allowing system-names and user-defined words to intersect makes it easier
to move a program from implementation to implementation, because
system-names need not be changed. To modify an existing program, insert
the keyword ALPHABET into the alphabet-name clause.
CANCEL and STOP RUN Statements
Both ANSI85 and ANSI74 entry points conform to ANSI COBOL 1985, which
specifies that the CANCEL and STOP RUN statements close all open files.
ANSI COBOL 1974 does not specify the status of files that are in open
mode when the program is canceled.
Justification for Changing CANCEL and STOP RUN.
In 1974 Standard COBOL, the status of files left in the open mode when
the program was canceled was not defined. The change in 1985 Standard
COBOL produces a predictable result for the CANCEL statement. The only
programs that may be affected are those that cancel other programs and
expect files associated with the canceled programs to remain open after
the CANCEL statements execute.
In 1974 Standard COBOL, the status of files left in the open mode when
the program finished executing was not defined. In some cases, this
situation could have caused errors. The change in the 1985 Standard
COBOL produces a predictable result for the STOP RUN statement. Few
programs will be affected, because many implementations already close
files after executing the STOP RUN statement.
EXIT PROGRAM Statement
Both ANSI85 and ANSI74 entry points conform to ANSI COBOL 1985, which
specifies that an implicit EXIT PROGRAM statement is executed when there
is no next executable statement in a called program. ANSI COBOL 1974
does not specify the action in this situation.
If you want to detect an error in this situation, instead of executing an
implicit EXIT PROGRAM statement, end your program like this:
999-END-PROG SECTION.
DISPLAY "999-END-PROG THIS SHOULD NEVER PRINT".
Justification for Changing EXIT PROGRAM.
In 1974 Standard COBOL, this situation was undefined. The change in 1985
Standard COBOL makes programs more transportable. The change only
affects programs that depend on another implementation action when the
EXIT PROGRAM statement is omitted.
Exponentiation
Both ANSI85 and ANSI74 entry points conform to ANSI COBOL 1985, which
specifies the following:
* If an expression whose value is zero is raised to a negative or
zero power, a size error occurs.
* If the value of an exponentiation is not a real number, a size
error occurs.
ANSI COBOL 1974 did not address these special cases of exponentiation.
Example.
The following expressions cause size error conditions because they raise
the value zero to negative or zero powers:
0**0
0**(-2)
((4*3)-(2*6))**(5-7)
The following expression causes a size error condition because it takes
the square root of a negative number:
-2**(1/2)
Justification for Changing Exponentiation.
1974 Standard COBOL did not state what would happen in these special
cases of exponentiation, so implementors were free to decide how to
handle them. The change in 1985 Standard COBOL resolves an undefined
situation and promotes program portability. The change affects few
programs, because two of the previously undefined cases caused errors and
the other case is consistent with most implementations.
OCCURS Clause
When a receiving item contains an OCCURS clause with a DEPENDING ON
phrase, and the receiving item also contains the object of the DEPENDING
ON phrase, ANSI85 assumes that the object has its maximum length.
In the same situation, ANSI74 assumes that the object has the length of
its current value. Consequently, a MOVE or READ INTO statement can
result in loss of data unless you change the value of the object of the
DEPENDING ON phrase before you change the value of the entire receiving
item.
Example.
The following example shows two records that contain tables with OCCURS
DEPENDING ON clauses, where the OCCURS DEPENDING ON items, A-SIZE and
B-SIZE, are part of the record:
FD INPUT-FILE.
01 A.
02 A-TABLE.
03 A-SIZE PIC 99.
03 A-ITEM OCCURS 1 TO 10 TIMES DEPENDING ON A-SIZE.
WORKING-STORAGE SECTION.
01 B.
02 B-TABLE.
03 B-SIZE PIC 99.
03 B-ITEM OCCURS 1 TO 10 TIMES DEPENDING ON B-SIZE.
In the preceding program fragment, assume that the value of A-SIZE is 10
and the value of B-SIZE is five. In ANSI74, the following statements
move all of the data in A to B:
MOVE A-SIZE TO B-SIZE.
MOVE A TO B.
In ANSI85, the following statement moves all of the data in A to B:
MOVE A TO B.
In ANSI74, the following statements read INPUT-FILE into B:
READ INPUT-FILE.
MOVE A-SIZE TO B-SIZE.
MOVE A TO B.
In ANSI85, the following statement reads INPUT-FILE into B:
READ INPUT-FILE INTO B.
Justification for Changing the OCCURS Clause.
1974 Standard COBOL computed the value of the length based on the value
of the item in the DEPENDING ON phrase prior to execution of the
statement. Using 1974 Standard COBOL rules with a MOVE or READ INTO
statement could have caused loss of data if the value of the DEPENDING ON
data item was not set to indicate the length of the sending data before
the MOVE or READ INTO statement executed.
This change does not affect programs that conform to 1974 Standard COBOL.
To change an affected program, restructure the affected data records so
that data items do not follow variable-length items.
READ NEXT after OPEN I-O, WRITE and REWRITE Statements
In ANSI85, for a relative or indexed file in dynamic access mode, a READ
NEXT statement that follows an OPEN I-O statement and one or more WRITE
statements accesses the first record in the file when the READ NEXT
statement is executed.
In ANSI74, for a relative or indexed file in dynamic access mode, a READ
NEXT statement that follows an OPEN I-O statement and one or more WRITE
statements accesses the first record in the file when the OPEN I-O
statement is executed. Therefore, if one of the WRITE statements inserts
a record before the original first record, the READ NEXT statement
accesses the original first record instead of the new first record.
Example.
The file looks like the following when the OPEN I-O statement is
executed:
-----------------------------------------------------
| | | | |
| Original | Record | Record | ... |
| First | | | |
| Record | | | |
| (key=n) | | | |
| | | | |
-----------------------------------------------------
A WRITE statement inserts a new first record so that the file looks like
the following:
In ANSI74, a READ NEXT statement accesses this
record.
downarrow
------------------------------------------------------------------
| | | | | |
| New | Original | Record | Record | ... |
| First | First | | | |
| Record | Record | | | |
| (key=n-3) | (key=n) | | | |
| | | | | |
------------------------------------------------------------------
uparrow
In ANSI85, a READ NEXT statement accesses this
record.
Justification for Changing READ NEXT.
It is considered more logical that on execution of the first READ
statement after an OPEN statement, the record accessed is the first
record in the file at the time that the READ statement is executed.
VARYING...AFTER Phrase in PERFORM Statement
In the VARYING...AFTER phrase in a PERFORM statement, ANSI85 augments
identifier-2 before it sets identifier-5. ANSI74 performs these steps in
reverse order: it sets identifier-5 before it augments identifier-2.
The reason for this change is that the ANSI74 PERFORM statement was often
misinterpreted, resulting in incorrect programs.
ANSI85 and ANSI74 produce different results when identifier-5 depends on
identifier-2 or vice versa.
Example.
In the following PERFORM statement, Y depends on X:
PERFORM PARA3 VARYING X FROM 1 BY 1 UNTIL X IS GREATER THAN 3
AFTER Y FROM X BY 1 UNTIL Y IS GREATER THAN 3
ANSI85 executes PARA3 six times with the following values for X and Y:
X: 1 1 1 2 2 3
Y: 1 2 3 2 3 3
ANSI74 executes PARA3 eight times with the following values for X and Y:
X: 1 1 1 2 2 2 3 3
Y: 1 2 3 1 2 3 2 3
In ANSI85 (but not ANSI74), the following statement sequence is
equivalent to the statement above:
PERFORM PARA2 VARYING X FROM 1 BY 1 UNTIL X IS GREATER THAN 3.
PARA2.
PERFORM PARA3 VARYING Y FROM X BY 1 UNTIL Y IS GREATER THAN 3.
In ANSI85 (but not ANSI74), the above statement sequence is equivalent to
the following nested PERFORM statement:
PERFORM VARYING X FROM 1 BY 1 UNTIL X IS GREATER THAN 3
PERFORM VARYING Y FROM X BY 1 UNTIL Y IS GREATER THAN 3
code for PARA-3
END-PERFORM
END-PERFORM.
Justification for Changing PERFORM VARYING.
The situation where one VARYING variable depends on another is useful for
processing half a matrix along the diagonal. The rules of 1985 Standard
COBOL specify this function properly, while the rules of 1974 Standard
COBOL did not. This change affects few existing programs.
File Status Codes
File status code incompatibilities between ANSI85 and ANSI74 file status
codes are shown in Table 5-9 .
Justification for Changing File Status Codes.
1974 Standard COBOL specified only a few file status code conditions.
This made the following true:
* A COBOL program could not distinguish the many different
exceptional conditions and treat them differently.
* Each implementor specified a different set of implementor-defined
status codes to cover many situations in many ways.
* The results of many I-O situations were undefined. That is, 1974
Standard COBOL stated that certain criteria were to be met, but
not what happened when they were not met.
1985 Standard COBOL attempts to define file status codes for these
undefined I-O situations, so that a COBOL program can check for these
error conditions in a standard way and take corrective action where
appropriate.
The addition of new file status codes affects the following kinds of
programs:
* Programs that check specific file status code values.
* Programs that test for specific implementor-defined status values
to detect conditions that are now defined.
* Programs that rely on a successful completion status for any of
the conditions that are now defined (in the case of new file
status values 04, 05, and 07, this only affects programs that
examine both character positions of the file status to check for
successful completion).
* Programs that rely on an implementor-dependent action (such as
abnormal termination of the program) when a newly defined
condition arises.
The STAT74 control option causes the compiler to follow ANSI74 rules even
when it is invoked through its ANSI85 entry point. See Chapter 6 for
more information on STAT74.