contents.gifindex.gifprev1.gifnext1.gif

Changes Affecting Version 4.2

ACUCOBOL-GT is generally upwards compatible with prior versions of ACUCOBOL-GT and ACUCOBOL-85. There are, however, some changes that can affect existing programs. These changes are detailed in this appendix.

Compiler Changes

Version 4.3 contains two new compilation switches for compatibility with Version 4.2:

-C42 --Causes the compiler to generate code according to the rules used by Version 4.2.

-Z42 --Creates object code that can be run with a Version 4.2 runtime.

The following paragraphs describe changes that can affect programs originally written with ACUCOBOL-GT Version 4.2.

gt490000.gif The default ACCEPT size for a numeric-edited field now includes a space for the sign only if the field is signed. You can set the program to include a space for an implied sign by compiling for semantic compatibility with an earlier version of ACUCOBOL-GT using a compilation switch in the command line.

gt490000.gif One of the general rules for screen control entry has been modified: Prior to version 4.3, an ACCEPT statement used to set ACCEPT-CONTROL to "1" if the event was a "message" ("MSG-…") event. Starting with version 4.3, if the reason for entry is a "notify" ("NTF-…") event, ACCEPT-CONTROL is set to "1"; otherwise it defaults to "0").

gt490000.gif The "-Fo" compiler option has replaced the "-Zo" option. Both compiler options produce the same results, but the "-Zo" option should be considered obsolete.

gt490000.gif The compiler option "-Rw" has been expanded to allow, in addition to reserved words, the suppression of some non-reserved words, such as control names (e.g., "entry-field", "label") or property names (e.g., "max-text", "bitmap-number"). If you tell the compiler to suppress a non-reserved word, however, it will do so with the following warning: "Unknown reserved word: non-reserved word."

Runtime Changes

The following paragraphs describe changes that can affect programs originally written with ACUCOBOL-GT Version 4.2.

gt490000.gif If a program is in the event procedure for an active control, and the control activates and subsequently destroys another control, the control whose event procedure is executing is reactivated. In previous versions, the "active" control was left in an undefined state.

gt490000.gif When using the library routine WIN$PRINTER with the 32-bit runtime, the newer Windows PageSetup dialog box will appear by default. If you wish to use the old 16-bit PrintSetup dialog box, you must use the operation code WINPRINT-SETUP-OLD.

gt490000.gif In all releases up to and including the ACUCOBOL-GT 4.2 release, anytime you created an Entry-Field control with a LINES value of "2" or greater, it was treated as a multiline entry field. In version 4.3, this rule is modified so that a LINES value of "2" or greater implies MULTILINE only if the "CELLS" phrase is not also used or implied.
Note: When programming entry fields with Version 4.3, keep in mind that starting with ACUCOBOL-GT 5.0 release, the program will no longer automatically assign the "MULTILINE" style to an entry field with LINES value of "2" or greater. Although Version 5.0 will correctly handle cases compiled with 4.x versions, in order to do so you will need to specify an appropriate source-compatibility flag (such as "-Z43"). This means that you are not yet required to explicitly set the "MULTILINE" style, but doing so now will save you from having to use a compatibility flag in the future.

Calling COBOL from other languages

gt490000.gif Windows 95/98 and NT sites that are calling COBOL routines from C with the "cobol" routine need to be aware of a change to the calling convention. The calling convention has changed from "__cdecl" (the C calling convention) to "__stdcall" (the Pascal calling convention, used by Windows API routines). This was done to make integration with Visual Basic and Delphi more straightforward.

Programs that call the "cobol" routine must be sure to include "sub.h" (included with ACUCOBOL-GT in the "lib" directory). This includes a declaration of the "cobol" routine for all platforms. This ensures that you use the correct calling convention when calling the "cobol" routine. If you have established routines that call "cobol", these must be recompiled in order to use the new calling convention.