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.
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
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. |