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.

Table 1. Compiler options for IBM COBOL programs
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
01 X pic 9(2) binary.
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.