The isCOBOL 2022 R2 compiler includes a new feature that allows developers to write a PreProcessor in COBOL or in Java to integrate custom logic to be applied to source code.

Compatibility with other COBOL dialects and performances has been improved to simplify migrations, and isCOBOL ESQL has been improved to ease migration from IBM DB2 PRE and Oracle Pro*COBOL (ESQL precompilers).

A new compiler configuration,“iscobol.compiler.custompreproc”, has been added to enable Preprocessor parsing. Set this configuration to one or more classes that implement the isCOBOL compiler interface “com.iscobol.compiler.custpreproc.LinePreProcessor". For example, when compiling a program with this set in the configuration:

the compiler will pass every line of the source code being compiled to the MyPreProc class, which may perform source code changes. The resulting line is then passed to the SecondPreProc class, which can perform additional changes, and the resulting source code line is finally passed to the compiler for compilation.

isCOBOL already supports the use of the compiler option "iscobol.compiler.regexp” that can be used to replace text within the source code, but the new PreProcessor feature is more flexible and allows the parsing of multiple lines of code for analysis.

Both configuration options can be used simultaneously, letting you make complex code substitutions. The regexp will be executed first, then the custom preprocessor.

To implement the com.iscobol.compiler.custpreproc.LinePreProcessor interface, the class needs to include a “process” method with the signature:

So, the source can be written in COBOL declaring a CLASS-ID that has a METHOD-ID receiving these parameters:

For example, this method can be used to implement custom logic to write comments for a block of code, or to replace some code with another. You can also return Warnings or Errors exactly like the standard compiler produces. Another example use of the PreProcessor is to enforce or suggest code changes to comply with a desired standard set of rules.

When compiling sources with the -lf option, the resulting .list file will contain the output after the processing executed by the preprocessor classes is finished.

When debugging a COBOL program compiled using the preprocessor, the source shown will be the original source, as written by the developer, but the instructions executed will be the result of the preprocessor output.

To better follow the logic of the class-id MyPreProc, you can debug the COBOL source with the Remote Debugger feature. To do that, first compile with this variable set in the configuration:

and start the Remote Debugger with the command:

This will start the Remote Debugger on the default localhost using the default port number 9999 where the compilation process is waiting for the debugger execution. If the compilation is executed on a different server, you can pass the hostname of that server when launching the Remote Debugger.

For additional details on this feature, refer to the updated 2022 R2 documentation and new samples installed in the sample folder “compiler-pre-process”.

isCOBOL 2022 R2 provides a new compiler option named “-zmf” that internally activates a new compiler engine designed to maximize runtime performance and minimize resource usage. The new compiler engine has been developed for maximum compatibility with Enterprise IBM Cobol and Micro Focus COBOL. This early version can be used for batch COBOL programs without user interface. There are some syntax limitations as well in this first version.

The new compiler engine uses top-down (recursive descent) parsers as opposed to bottom-up parsers generated by a YACC-like tool. Based on the most popular parser generator, JavaCC, the new compiler engine runs in three steps:

As shown Figure 1, NCR CSAMPLE Benchmark, performance comparison was made using NCR CSAMPLE benchmark test between isCOBOL 2022 R2 with “-zmf” and other COBOL compilers from the market. The test was run on Windows 11 Pro 64-bit with i7-8550U CPU @ 1.80GHz and 16 GB of RAM. The test shows that isCOBOL’s new compiler engine beat our competitors by running 13% - 80% faster and executing at least 22% more instructions per second.

Enhancements have been implemented in this release to improve compatibility with MicroFocus COBOL, such as:

The THREAD-LOCAL-STORAGE Section describes data which is unique to each thread, useful for resolving contention problems related to concurrent access to the same dataitem. If a data-item is declared inside this new SECTION, every thread has its own copy of the variable instead of sharing the same with other threads.

The IS THREAD-LOCAL clause can be used in the WORKING-STORAGE SECTION or on the FD level to declare that a data-item or File Record needs to be treated with the thread logic described above, making every thread access its separate variables or record definitions.

Here is a code snippet that shows how to declare variables in the THREAD-LOCALSTORAGE SECTION and variables and FD with the THREAD-LOCAL clause:

With isCOBOL, underscore and hyphen are treated as the same character, but in the MicroFocus compiler the underscore and hyphen are 2 different characters. When a COBOL program contains the same variable or paragraph name, with the only difference being an underscore and hyphen, the isCOBOL compiler will throw a Severe “Ambiguous identifier” and “Duplicate procedure name” error message when compiling.

With the new compiler option –smfu, isCOBOL treats underscore and hyphen as 2 different characters, allowing sources as described to be compiled without errors.

For example, the following code can be compiled correctly:

This simplifies sharing file paths between operating systems. Windows uses the “;” as a path separator, while MacOS and Linux use “:”. The isCOBOL compiler will translate the universal path separator, “;”, to the OS-specific character.

For example, the following command used to compile on Windows:

can now be used without changes when compiling in Linux or MacOS.

This change also benefits the isCOBOL IDE when sharing the same Workspace to compile programs using different operating systems such as Windows, Linux and MacOS.

Enhancements have been made in this release to improve compatibility with IBM COBOL, such as:

The existing XML PARSE and XML GENERATE statements gave you the ability to manage XML streams, and starting from this release, the JSON PARSE and JSON GENERATE statements are supported to manage JSON streams.

isCOBOL already supports the “com.iscobol.rts.JSONStream” class to manage JSON streams, but now direct migration from IBM COBOL sources that contain these statements is supported by the compiler. Here’s a code snippet of the instructions:

The generated JSON will be:

When the COBOL program receives a JSON stream, the JSON PARSE statement will parse the stream and set the values in the corresponding WORKING STORAGE items.

Enhancements have been made in this release to improve compatibility with RDBMS PreCompilers such as IBM DB2 PRE and Oracle Pro*COBOL.

A Common Table Expression (CTE) is the result set of a query which exists temporarily and for use only within the context of a larger query. The result of a CTE is not stored and exists only for the duration of the query. CTEs enable users to easily write and maintain complex queries with increased readability and simplification. This reduction in complexity is achieved by deconstructing ordinarily complex queries into simple blocks to be used and reused as necessary in rewriting the query. CTEs initiate with the WITH keyword. Here’s a code snippet as an example:

Note that some databases might not support this syntax, so ensure it’s supported by your RDBMS before using. The larger RDBMS like IBM DB2, Oracle, Postgres, and Microsoft SQL Server support it.

Previously, the ESQL CALL statement required the procedure or function name to be a constant string. Now in 2022 R2 the name can be specified using host variables. For example:

This feature lets you write more dynamic code.

The compatibility with ESQL preprocessors has been increased in this version by supporting the Oracle Pro*COBOL format of the SQLDA structure. An SQLDA (SQL Descriptor Area) is a set of group items that store all the information the database needs about select-list items or place-holders for bind variables, except their values.

Previously, SQLDA was supported only in compatibility with the IBM DB2 preprocessor.

From the new isCOBOL 2022 R2 release, SQLDA is also supported with Oracle Pro*COBOL.

The SQLDA structure from Oracle Pro*COBOL is defined as follows:

These data items are used in DESCRIBE, OPEN and FETCH ESQL statements, for example: