Differences between Interactive COBOL 5.xx         June-2026
and Interactive COBOL 2.xx

NOTE: Envyr offers consulting services to assist with the upgrade
      to ICOBOL 5, if needed.

1.  ICOBOL 3 introduced a new .cx format that required that all COBOL
    programs be re-compiled.

    ICOBOL 5 allows either ICOBOL 3 format .cx files or ICOBOL 2
    format .cx files to be run. The runtime will automatically
    detect an ICOBOL 2 .cx at startup time and run in that mode.

    This option is especially useful for those who want to move
    forward with logging, thinclient support, .pdf printing, etc.
    but cannot or do not wish to recompile their programs.

2.  Under Windows, all runtime processes require a runtime license.
    In the past some runtimes did not "count" as a license.

3.  All configuration files (.cf), printer translation files (.pt),
    and terminal description files (.td), have a new .ini based
    format.

    The extensions for these new file types are .cfi, .pti, and .tdi,
    respectively.

    The utility ICREVUP, has been provided to rev-up existing
    configuration, terminal description, and printer translation
    files to their new counterpart.

    NOTE: The ICOBOL 5 system has the default .pt and .td definitions
          built into the system, and so it may not be necessary to
          convert the old files.

    Note that in ICOBOL 5 (5.04) icrevup can also convert rev 5
    and 6 ICISAM files to rev 7 or 8 ICISAM files.

    Please see the ICOBOL 5 readme for more information.

4.  ICOBOL 5 supports new ISAM version 8 files.

    Version 8 files can contain up to 4 giga-records versus
    version 7 files, which are limited to 4 giga-bytes in size.

    Version 8 is now the default for newly created ISAM files.

    Version 7 files are still fully supported.

    ICREORG can be used to convert files to/from previous versions.

    ICREVUP can convert rev5 or 6 files to rev7 or 8.

5.  There is NO runtime support for version 5 or 6 ISAM files.

    These files must be converted to version 7 or 8 files
    using ICREORG before they can be used by ICOBOL 5.

6.  There is a new 64-bit release of the ICOBOL 5 product
    for both Windows and Linux.

    The 64-bit release may have some functional differences
    with the 32-bit release for programs using SP2 and FormPrint.

    See the appropriate readme for more information.

7.  Under Windows, the services (icexec, icnetd, icpermit) will now
    place their log files in the c:\programdata\icobol folder
    instead of the windows folder.

    In addition any surrogates started from the client/server service
    (icnetd) will also place their logfiles in the c:\programdata\icobol
    folder if logging is requested.

8.  The logon.cx and sp2logon.cx files have been moved from the main
    installation folder to the examples\programs subfolder.

    Under Windows, ICCODEPATH is now set to include the
    examples\programs subdirectory by default.

9.  The convention for finding .tdi, .pti, and .pdf form files has
    changed.  They are no longer stored in subfolders of the installation
    folder.  They are now found by using the ICCONFIGDIR environment
    variable, or by searching the current directory. Note that the
    default .pti and .tdi definitions are built into the system, so
    this mechanism is only needed for user-customized definitions.

10. The tcs subdirectory has been renamed icnet and ALL surrogate
    executables are released in that directory.
    (icios, iclogs, icrunrs, icsqls)

11. The icrevw utility on Windows is no longer a part of the installed system.

12. The facilities to access ICOBOL ICISAM files from other programming
    languages (called the User Library or icapi) and the ability to
    integrate custom calls into the runtime (called the link kit) are
    no longer part of the standard release, but they are still available.
    Furthermore, an ICOBOL 2 icbltn.dll(.so) requires programming
    changes before it can be built for ICOBOL 5. Please contact Sales
    for assistance if either of these are needed.

13. As of version 5.30 the U/FOS file manager used by the VX/COBOL
    dialect is no longer supported since Envyr Corporation is no
    longer a reseller.

14. As of version 5.40 the file logging features using ICLOG and ICLOGS
    are no longer included in the product. Before upgrading all logged
    files should be brought up to date, and then the logging feature
    should be turned off.  In addition, the logging related environment
    variables used by ICRUN are no longer referenced.  Any startup
    scripts that set those variables may be modifed to remove them.

15. As of version 5.40 the old AOS compatibility builtins have been
    removed, along with the COPY file "cobsysid.in".  The interfaces of
    these routines were inherently 32-bit and no longer work on 64-bit
    systems and most calls have alternative, supported replacements.
    If you need help with substitutes, please contact Support.

16. As of version 5.40 the install scripts for RHEL 7 and up now install
    the ICOBOL service daemons as native SYSTEMD daemons instead of
    running them under the old /etc/init.d system.  It follows that
    this is the mechanism used by 5.60 for all Linux releases.

17. As of version 5.50 and the Linux 9 release, the 32-bit components
    will no longer be installed. One implication is that clients using
    icnetd services will need to be upgraded to 64-bit.

18. As of version 5.50, the icruncgi components are no longer released.

19. As of version 5.50, RHEL 6 (and equivalents) is no long released
    and so there is no 32-bit only release for Linux.

20. None of the OS environments that were supported in ICOBOL 3 are
    supported by ICOBOL 5 and the system is 64-bit vs. 32-bit.
    The miniumum OS versions are RHEL 8 for linux, and Windows 10 or
    Windows Server 2016 for Windows.

21. As of version 5.60, ICPERMIT only supports MAC address licensing.
    Support for USB, parallel port, and serial port hardware protection
    devices has been removed.

22. Despite the many changes, as long as the data and configuration
    files are updated as described above, our customer's experience
    is that their applications continue to run fine in IC2x mode.


Below apply ONLY if the ICOBOL 2 sources are recompiled under
ICOBOL 5

1.  ICOBOL 3 added many new reserved words for the ICOBOL and
    ICOBOL85 dialects.  Variables with these names must be renamed
    if the programs are recompiled.

2.  The ICOBOL 2 compiler allowed a FROM and a USING clause in the
    SCREEN section and generated code as if it was a FROM and a TO
    clause.  This case is now an error.  It must be re-coded if the
    program is recompiled.

3.  Items with USAGE INDEX require 4-bytes of storage.  In ICOBOL 2
    these items required only 2-bytes.  If USAGE INDEX items have been
    included in data files, these files will have to be reorganized to
    allow for 4 rather than 2 bytes for each USAGE INDEX item.

4.  The COMPUTE statement no longer truncates immediate results so
    results in COMPUTE statements should be more accurate as required
    by the COBOL standard.

5.  ICOBOL 5 handles parameters to builtins differently than
    ICOBOL 2.  Programs should have exception handling for
    builtin calls to detect errors.

    If a builtin calls for a PIC X(n) then only an alphanumeric item
    can be passed.  Passing a numeric PIC 9(n) will cause a
    209 Parameter mismatch error.

6.  Size error conditions for COMP-5 data items are based on the
    allocated storage rather than the number of digits in the item's
    picture.

7.  The ICOBOL 5 compiler will not allow an OPEN INPUT on a file
    with an ASSIGN TO PRINTER.

    (This option was sometimes used to check whether a file existed)

    A workaround is to have a duplicate file descriptor as
    an ASSIGN TO KEYBOARD with the same record, name, file status
    etc. and use it in the OPEN INPUT.

8.  When doing an increment to a number that overflowed and no
    size condition was set, ICOBOL 2 would internally generate the
    size condition and not do the store (leaving the value unchanged).
    ICOBOL 5 will not check the size condition and will store the
    truncated value.

    Code should be changed to detect the size condition and do a
    CONTINUE, i.e., ON SIZE CONTINUE.

9.  In ICOBOL 5, screens do not support embedded control codes
    for positioning as in ICOBOL 2.  Use variable line and column
    phrases.

10. Comparisons of a numeric data item and a non-numeric data
    item or figurative constant may return different results.

    ICOBOL 2 and previous ICOBOL compilers incorrectly generated
    a non-numeric compare with the storage occupied by the numeric
    data item.

    When mixing a numeric item and a non-numeric item in a comparison,
    the COBOL Standard requires that the numeric item be treated as
    if it was moved to a temporary alphanumeric item and then that
    temporary item is compared using a non-numeric comparison.

    Some ICOBOL 2 (or earlier) code initialized storage by moving
    LOW-VALUES to the storage and then comparing numeric and
    non-numeric items from that storage area with LOW-VALUES.
    The old ICOBOL compiler would return TRUE, and ICOBOL 3 and 4
    will return FALSE.  When the numeric item is converted for the
    comparison, it has ASCII zero characters, which are not the
    same as LOW-VALUES.

    See VI. Procedure Division, B. Concepts, 2. Conditional
    Expressions in the Language Reference Manual.

    A Warning is generated by the compiler when this is detected.

    A better practice is to use the INITIALIZE statement to properly
    initialize data items and to use numeric [figurative] constants
    when the data item is numeric.

    Another way this old construct can fail is when
    COLLATING SEQUENCE is used, since LOW-VALUES may not be a binary
    zero value.

11. ACCEPT FROM LINE NUMBER in ICOBOL 3 and up returns more digits than
    in ICOBOL 2 (5 instead of 3).  Some programs used a PIC X(3)
    field as the target of ACCEPT FROM LINE NUMBER instead of a PIC 9(3)
    (e.g., because the field is a key).  The effect is that the field
    receives only the left 3 digits of the line number, and the
    right two digits are lost.

End of Differences
