Differences between Interactive COBOL 5.xx 30-Jan-2020 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. On 64-bit systems, certain 32-bit components are also installed. These include the development tools, which are only available as 32-bit components, and the following components for which we install both the 32-bit and 64-bit versions: the runtime system, the ODBC driver, and the icrunrs and icsqls surrogates started by icnetd. On a 64-bit system, 32-bit components are installed in an x86 subfolder. 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. None of the OS versions that were supported in ICOBOL 2 when it was released are supported by ICOBOL 5. Check the website for currently supported OS versions. 16. 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. 17. 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. 18. As of version 5.40 the install scripts for RHEL 7 and 8 now install the ICOBOL service daemons as native SYSTEMD daemons instead of running them under the old /etc/init.d system. The RHEL 6 install still uses the old system. The RHEL 6 build is available in both 32-bit and 64-bit versions, whereas the RHEL 7 and 8 builds are only available in 64-bit. 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