Why modernization is hard? – Series 3

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.  

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. 

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. 

07 Oct 2022

Is It Time to “Modernize” your Modernization Plans?

Over the last several decades, I have spoken to many organizations about…

04 May 2024

FS Firm envisions a COBOL-less future by collaborating with CloudFrame…

FS Firm envisions a COBOL-less future by collaborating with CloudFrame and EPAMDownload…

23 May 2022

Modernizing COBOL for Maintainability, Automation, and Quality

The debate as to whether you should or shouldn't modernize any portion…

Written by

Venkat Pillay

Venkat is a true technology visionary, serial entrepreneur, strategist, deep generalist, and architect. With over 25 years of experience and a passion for innovation, his expertise ranges from Legacy to emerging technology and company building.

Founder and CEO