BrainBlog for CloudFrame by Jason Bloomberg
Even though mainframes remain the transactional backbone of the modern economy, powering industries from banking to airlines, many enterprises with mainframes find their modernization strategies require migrating workloads off this platform into the cloud.
Over the years, this requirement has led to a plethora of COBOL conversion applications that typically convert this venerable language into modern Java.
If you’re looking to convert a COBOL program to Java, buyer beware: different approaches to such conversions with widely disparate results.
Programs never live in isolation. They always depend upon the execution context of the platforms they run on – and you can’t find two more different platforms than mainframes and cloud-native execution environments.
However, the more severe problem is that line-by-line language conversions generally deliver poor results. Not only does COBOL have a different syntax from Java, but COBOL programs have a different architecture altogether.
Converting COBOL to Java without taking into account all of these externalities is a recipe for the dreaded ‘JOBOL’ – a portmanteau that refers to generated Java code that still retains COBOL syntax – as well as the continued need for COBOL skills and even COBOL licenses.
Don’t let JOBOL sink your modernization initiative. There’s a better way.
Approaching COBOL Conversion as Data Problem
Most of the COBOL conversion products on the market today have been around since the 1980s and 1990s, and their technology hasn’t changed much since. CloudFrame, in contrast, approaches COBOL conversion as a data problem.
Even when older conversion products generate Spring Boot or other modern flavors of Java, it’s still JOBOL. These products generate Java code that leaves the COBOL class hierarchy in place, retaining classes that instantiate variables using COBOL’s group and elementary variable syntax – bringing COBOL semantics into the new Java code.
Even though such JOBOL is technically valid Java, the conversion step has increased its technical debt. For example, a Java string might represent a COBOL data name – obscuring the behavior of the Java code from any programmer that must work with it.
The resulting Java code is virtually unmaintainable. Java developers must now learn COBOL and preserve its semantics in the Java code to maintain and extend the code. And if you must train your developers on COBOL, why migrate off the mainframe in the first place?
CloudFrame’s text analytics approach, in contrast, reworks both COBOL syntax and semantics to generate maintainable Java code. For example, CloudFrame will generate POJOs using Java’s native types and classes for variables, and rework deeply nested IF statements as SWITCH statements. This approach can also identify poorly constructed COBOL code, dead or duplicated code, GO TO’s (which don’t exist in Java), and then automatically refactor it.
Read the entire BrainBlog here.
Comments
Comments are closed.