Changes Affecting Version 5.1

ACUCOBOL-GT is generally backwards 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.

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

Licensing Changes

Acucorp's 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 Acucorp 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.

Compiler Changes

• Two compilation switches provide compatibility with Version 5.1:
  -C51 Causes the compiler to generate code according to the rules used by Version 5.1.
  -Z51 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 "V52_GRID_GOTO" to "0".

  ---

• 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:
  If "entry" appears in a paragraph name in your program, the compiler returns the error:

  "Identifier expected, ENTRY found"

  If "entry" appears in a variable in your program, the compiler returns the error:

  "syntax error scanning ENTRY"

  See Book 3, Reference Manual, section 6.6, "Procedure Division Statements," ENTRY Statement, for usage syntax and rules.

Runtime Changes

• 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. See Appendix M, section M.3 "UNIX," for details on calling shared library routines under UNIX.

• 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 machine, such as situations where the optimization is made on the application server without interacting with the display service.
  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 available only 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.