Changes Affecting Version 1.5

Compiler Changes

• Since the release of Version 2.0, indexed, relative, and binary sequential files can have variable-length records. You might have syntax in your existing programs that implies variable-length records, even though your files on disk are fixed-length. If this is the case, you will receive error 39 when you try to open your existing files after recompiling your programs. This type of error will occur most frequently with files that have multiple records declared for them (more than one 01 entry in the file's FD). In order to prevent the error, compile with either the -C5 or -Cf compile-time option. The -Cf option causes the compiler to assume fixed-length records for these kinds of files.
• The function of the RETURN-CODE special register was expanded in Version 2.0. This register is used to return a status value to the operating system or calling program. The return status of the SYSTEM library routine is also stored here. This can cause an existing program to behave differently if you set RETURN-CODE to a particular value and then call the SYSTEM routine. This can also cause programs that return zero to the operating system (the default value of RETURN-CODE) to return a non-zero value if they call SYSTEM. Note that this change affects programs only after they have been recompiled with Version 2.0 or later. You can inhibit the change with the -C5 compile-time option.
• The CALL PROGRAM verb behaves differently since Version 2.1. If you used CALL PROGRAM under Version 1.5, use the -C5 option to maintain compatibility when you compile with Version 3.0. Also note, that since Version 2.1 the -Ci option implies the recursive PERFORM switch -Zr.
• Under Version 1.5, the-Vc compile-time option caused ACCEPT statements that entered numeric fields to be treated as if the CONVERT phrase were specified for them. Since Version 2.1, this option also implies the CONVERT phrase for numeric edited fields.
• Under Version 1.5, the WRITE and REWRITE verbs did not check the length of the record for legality. Since Version 2.1, an illegally sized record returns error 44.
• The option -Zz causes spaces in a USAGE DISPLAY numeric item to be treated as the value zero. Because this action was formerly handled by the SPACES-ZERO runtime option, if you have a mix of object files from Version 3.0 or later and from any versions prior to Version 2.0, then you should use -Zz to create the new objects and should also add the SPACES-ZERO option to your runtime configuration file to handle prior versions.

Runtime Changes

The changes described in this section take effect when you install the latest runtime system.

• Important: Beginning with Version 2.0 and continuing through Version 3.1, the ACUCOBOL-GT runtime was delivered with Version 3 of the Vision file system. Version 3.2 and later versions are delivered with Vision Version 4. The Vision file system is used on all ACUCOBOL-GT implementations except VAX systems running VMS and Alpha Micro systems running AMOS. Vision Version 3 introduced a new file format that is portable across all machines, and is (generally) smaller. Vision Version 4 introduced a dual file format, in which the indexes are kept in a separate file from the data. When you are installing the latest version of the runtime system, you have three choices:
  1. You can leave your existing data files in place. ACUCOBOL-GT will continue to use them. However, any new data files created by Version 3.2 or later will have the new Vision Version 4 format. This is the default behavior.
  2. You can convert all of your files to the new format with the rebuild option of vutil. In particular, running vutil -rebuild -3 on your data files will convert them to the Vision Version 3 format, and running vutil -rebuild -4 on your data files will convert them to the Vision Version 4 format.
  3. You can continue to use the old format for all of your data files, including any newly created ones. To do this, add the line:

     V-VERSION 2

     to your cblconfig file. This will ensure that any newly created files use the old format.

• The default method of editing numeric and numeric edited fields on the screen changed slightly when Version 2.0 was released. In Version 1.5, when a user was editing an existing value, the user could type over the value. This left any trailing digits in place, and sometimes caused confusion. Beginning with Version 2.0, if the user starts typing over an existing field, the current contents are erased first. If the user instead starts by editing the field (by using an arrow key or an editing key), then the default value remains on the screen and the user can modify it.

  This behavior is controlled by the NUMERIC-UPDATES and EDITED-UPDATES configuration options. If you already have the following entries in your configuration file, then the default change will not affect you. If you do not have these entries and want to maintain exact compatibility with Version 1.5, then you should add the following to your configuration file:

  SCREEN  Numeric-Updates=Converted
  Edited-Updates=Converted