Compiler options for IBM COBOL programs
The Enterprise COBOL and IBM® COBOL compilers are very similar. If you will be using the same compiler options that were used in your current IBM COBOL applications, some internal changes might take effect, but basically the behavior is unchanged.
If you do change compiler options settings from the settings you used with IBM COBOL applications, make sure you understand the possible effects on your applications. For information about other compiler options, see the Enterprise COBOL for z/OS® Programming Guide.
There are some new compiler options in Enterprise COBOL compared to compiler options in IBM COBOL. Table 1 lists the options that affect compatibility between IBM COBOL and Enterprise COBOL.
Compiler option | Comments |
---|---|
ARITH | Use ARITH(COMPAT) to get the same results as COBOL/370, Release 1, thru COBOL for OS/390® & VM, Version 2 Release 1 for intermediate results in arithmetic statements. |
INTDATE | Use
INTDATE(ANSI) to get the same results as COBOL/370, Release 1 for
date intrinsic functions. Use INTDATE(LILIAN) if you store integer
values and will be using other languages with the same data. INTDATE(LILIAN)
will cause the date intrinsic functions to use the Language Environment® start date, which
is the same starting date that would be used by PL/I or C programs
that use Language Environment date
callable services. If integer dates are used only within a single program, such as converting Gregorian to Lilian and back to Gregorian in the same program, the setting of INTDATE is immaterial. If you choose INTDATE(LILIAN) as your installation default, you should recompile all of your COBOL/370, Release 1 programs (and any IBM COBOL programs that used INTDATE(ANSI)) that use intrinsic functions to ensure that all of your code uses the Lilian integer date standard. This method is the safest, because you can store integer dates and pass them between programs, even between PL/I, COBOL, and C programs, and know that the date processing will be consistent. |
PGMNAME | Use PGMNAME(COMPAT) to ensure that program names are processed in a manner similar to COBOL/370, Release 1. |
NSYMBOL | Controls
the interpretation of the "N" symbol used on literals and PICTURE
clauses, indicating whether national or DBCS processing is assumed.
NSYMBOL(DBCS) provides compatibility with previous releases of IBM COBOL and VS COBOL II. |
TRUNC | In
releases of COBOL for OS/390 &
VM prior to Version 2 Release 2, unsigned binary data items with TRUNC(BIN)
were correctly supported only when the binary value contained at most
15 bits for halfwords, 31 bits for fullwords, or 63 bits for doublewords.
In other words, the sign bit was not used as part of the numeric value
when the data item was unsigned. With Enterprise COBOL and COBOL for OS/390 & VM, Version 2 Release
2, all 16 bits of a halfword, all 32 bits of a fullword, and all 64
bits of a doubleword can be used as part of the numeric value of an
unsigned COMP-5 data item or an unsigned binary data item with TRUNC(BIN).
For example, in a program compiled with TRUNC(BIN), a data item
declared like this
correctly supported binary values from 0 through only 32767 in prior
releases, but with Version 2 Release 2 now supports values of 0 through
65535.This support necessarily yields different arithmetic results than were obtained with the prior releases, if these very large unsigned binary values were inadvertently used. |