COBOL compiler options significantly affect calculation results and logic flow. Both human intelligence and AI struggle to replicate business logic in newer systems without considering these options. This challenge is like landing a plane on a foggy night without navigation-success is largely coincidental. In this blog, I'll share a few examples of issues customers have encountered during their modernization journey.
SSRANGE/NOSSRANGE Compiler Option
Unlike Java, which uses 0 based index, COBOL arrays start from index 1. A COBOL array when defined as OCCURS 3 (e.g.) has a subscript that ranges from 1 to 3, while the same array definition in Java will range from 0 to 2. When programs are compiled with SSRANGE option, any reference to array beyond its defined area will result in an abend that indicates a subscript out-of-bounds condition.
-1727430607.png)
We have customers using NOSSRANGE as the default in their Source Control Management (SCM) for fear of abends in production. We also have a customer application that was intentionally coded to refer to the zero index in COBOL using NOSSRANGE to solve a particular business logic. The following structure definition shows how it was coded in COBOL.
A Department table was populated from a database that mapped a number to a Department ID. Due to legacy issues there were some rows in the database that had zero as the Department#, which signified the assignment of a default department ID. If you observe the above structure definition in COBOL, the customer deliberately placed a variable, DEPT-ZERO-INDEX-ROW, before the array definition of Department table with a default Department code as "ABC". So the above table, in essence, became an array of 1001 entries where you could deliberately reference a zero-index item in COBOL.
The challenge for any code transformation using AI or HI is to understand the business logic and preserve the functional equivalence.
Should AI or HI assume NOSSRANGE for analyzing all the transformation to newer system?
The clear answer is "NO" because you will find many applications that do want to protect array boundaries to enforce business rules.
TRUNC (STD/OPT/BIN), ARITH(COMPAT/EXTEND), NUMPROC(PFD) numeric compiler options
Let's understand one example of how truncation compiler option impacts variables defined with Binary COBOL Datatype 'COMP'.
The above variable defined as COMP can store values in the range -32768 to +32767. Compiler TRUNC options can truncate or retain full value. For example, if you move +12345 to the above variable, TRUNC(STD) will truncate the resulting value to 2345, TRUNC(BIN) will honor +12345 and TRUNC(OPT) can produce unpredictable results since the data being moved doesn't conform to PICTURE clause.
We have seen customer applications exploiting TRUNC(STD) compiler option to intentionally truncate a numeric variable for certain business logic. Additionally, in the above definition of WS-NUMBER, there is no 'Sign' attribute that is part of Picture clause so it can have value in the range of 0 to 65536. Transforming to a java-based system, one finds no concept of "unsigned short", so the variable definition would require it to be mapped as "int".
Similarly we see the use of large numbers to store business data in customer applications, and the application being compiled is required to have ARITH(EXTEND) option to produce correct results.
NUMPROC option is designed to repair sign in the data field. Not knowing the compiler options during code transformation will hinder carrying over correct business logic to the newer system and create business issues in the newer system that are difficult and costly to resolve.
ADV | NOADV Compiler option
COBOL Batch applications generate reports that are traditionally printed for customers. To handle page breaks and line breaks while writing reports, COBOL programs use a 'WRITE' verb with 'ADVANCING' extension viz. WRITE REPORT_DATA ADVANCING PAGE. When such extensions are used while writing records, the report files will have an extra byte known as ASA or Printer control character.
We come across applications that don't account for this extra character in their defined report record structures and let the compiler add it by compiling with ADV option. Some applications account for this extra character in their record structure and compile with NOADV creating a direct dependency on knowing the compiler option during code transformation or business rule extraction.
Summary
What I have mentioned above is only a small subset of issues that we have seen during modernization. Without knowing the compiler options many such challenges go unnoticed, resulting in a transformation that causes business issues that are hard to fix later.
