The following paragraphs describe changes that can affect programs originally written with ACUCOBOL-GT Version 5.1.
The licensing mechanism changed with the release of Version 5.0. In Version 5.2, this mechanism has been simplified:
- Node IDs are no longer used.
- When the license is installed, the Windows version of the Activator creates a separate license file for each product, in the
same manner as UNIX.
- The Activator utility is not backwards compatible. You must use the version of the Activator utility that corresponds to the
version of the product you are installing in order to create a proper license file.
A complete description of the current licensing mechanism is available in Getting Started with ACUCOBOL-GT.
- Two compilation switches provide compatibility with Version 5.1:
||Causes the compiler to generate code according to the rules used by Version 5.1.
||Creates object code that can be run with a Version 5.1 runtime.
- Compiler switch
-Zt is not supported in Version 5.2.
- In versions prior to 5.2, the grid would not pass a MSG-GOTO-CELL-MOUSE event to the program when the user clicked on the
cell containing the grid cursor. This was done to prevent extraneous messages from being sent to the program. However, this
message can be useful in some cases, for example, to allow a user to deselect something that is already selected. Therefore,
in Version 5.2 and later, the runtime no longer filters out MSG-GOTO-CELL-MOUSE messages just because the destination cell
is the same as the current cell.
Note: This change is active only for programs compiled for Version 5.2 or later. This means that the Version 5.2 runtime will use
the old behavior when executing programs compiled with versions prior to 5.2, or compiled with the
C51 or the
Z51 switch. You can disable the new behavior by setting the configuration variable
- Version 5.2 introduces
ENTRY as a new reserved word in ACUCOBOL-GT. A program that compiled with a previous version of the compiler will not compile with
Version 5.2 if it uses
entry in certain places. For example:
entry appears in a paragraph name in your program, the compiler returns the error:
Identifier expected, ENTRY found
entry appears in a variable in your program, the compiler returns the error:
syntax error scanning ENTRY
See the ENTRY Statement in Procedure Division Statements, for usage syntax and rules.
- The ACUCOBOL-GT Version 5.2 runtime on SCO UNIX systems runs in the ELF binary format. Prior to Version 5.2, the runtime ran
in the COFF format, but COFF does not support calling shared libraries so it was changed to ELF. If you have your own C routines
that you used to link to the runtime, you will need to recompile those C routines to create ELF objects to link to the 5.2
runtime. For details on calling shared library routines in UNIX environments, see Working with C and C++ Programs in A Guide to Interoperating with ACUCOBOL-GT.
- In versions prior to 5.2, the runtime would eliminate requests to resize a screen control if the new size and position matched
the control's current size and position on the screen. With the current version, the runtime optimizes the control resize
request using the SIZE and LINES indicated (or implied) by your program instead of the current size and position.
These two ways of optimizing control resize requests produce nearly identical results. However, there are a few cases where
the results can differ. For example, if you change the size of the subwindow that contains the control in such a way that
the control would crop differently, then a comparison of the "actual" size shows a difference, while a comparison of the "requested"
size does not. In this case, earlier versions of the runtime would resize the control, while the current version will not.
This change was made to provide more predictable behavior and to improve efficiency when the display service is on a remote
If necessary, you can disable this behavior by setting OPTIMIZE_CONTROL_RESIZE to "0" (off, false, no). This prevents any
optimization of control resizing operations. Note that this can result in additional screen painting (in which controls may
appear to flicker) and should be used only as a short-term fix while any required coding changes are made.
- The way the runtime handles mouse click events in COBOL programs that contain both bitmap push buttons and multiple windows
under the control of a single thread has changed.
In Version 5.1 and earlier, in some cases, simply clicking down on the mouse button when a bitmap push button was selected,
generated a CMD-CLICK event. This was not consistent with the way Microsoft Windows handles these events.
In Version 5.2 and later, clicking down on a bitmap pushbutton on a non-active window running in the same thread will cause
the current ACCEPT to terminate with CMD-ACTIVATE event. The pushbutton is not considered clicked until the COBOL program
performs some action that allows it to activate, such as ACCEPTing some control in the newly activated window. For self-activating
pushbuttons, this allows the pushbutton to self activate. For non-self-activating pushbuttons, the new ACCEPT will terminate
with a CMD-GOTO so that the COBOL program can ACCEPT the correct control.
This change is only available in COBOL objects compiled for Version 5.2 or later and run with a Version 5.2 or later runtime.
COBOL objects compiled with Versions 5.1 or earlier will still exhibit the old behavior, even if they are run with a Version
5.2 or later runtime.
- The resolution of the ACCEPT BEFORE TIME timer has been substantially increased in Version 5.2. In rare cases, this could
affect existing programs. To forestall any such problems, the runtime automatically uses the pre-5.2 resolution when running
pre-5.2 objects and objects compiled for pre-5.2 compatibility (e.g.