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.
Integrate Domain Knowledge to Maintain Code Context
One of the primary shortcomings of the line-by-line COBOL conversion tools is that they do nothing to enhance the business context of the programs they convert.
CloudFrame plans to integrate domain knowledge into the code it generates by aligning with industry-standard ontologies.
Future CloudFrame software will ingest available data dictionaries (common with COBOL DB2 systems, for example) and then identifies the data flow corresponding to COBOL variables. In this way, CloudFrame will associate entities in the original data dictionary with industry-standard ontologies like the Microsoft Azure ontology for financial services.
This association will leverage the knowledge of the business domain to maintain semantic connections between the original and generated code, which improves the resulting code quality in many ways.
COBOL data types, for example, might represent account balances, stock prices, or other business entities. The corresponding generated string or numerical value in Java will accurately represent such entities, mapping data types to dollar values, Java dates, or other specific Java entities as appropriate.
CloudFrame plans to even pick up hints in the COBOL, for example, when variable names include a particular prefix or suffix that identifies the context for that variable. CloudFrame will leverage machine learning to provide a specific high confidence level for such interpretations of variable names.
From Batch to Event-Driven
In many cases, COBOL programs run as batch jobs – a standard and routine practice on mainframes that doesn’t convert well in the cloud-native Java world.
CloudFrame handles batch to event-driven conversions by considering the execution context of source and destination programs. It automates the refactoring from batch-oriented processing to event-based message queue processing, thus improving the scalability of the resulting system and enabling it to run cost-effectively in the cloud.
CloudFrame’s future releases will automate the work to understand the job scheduler for batch jobs, extracting each job’s run time and CPU requirements. It will then calculate the necessary compute capacity required in a particular cloud to achieve the same cycle time.
Given these parameters and the configurable parameters of the cloud in question, the operator can now transition a job that would have taken hours and instead run it in near real-time by leveraging hundreds of container instances on Kubernetes.
Furthermore, the operator has sufficient information to make appropriate judgment calls about purchasing spot versus reserved instances to control costs further.
As a result, the operator can allocate reserve capacity for the appropriate workloads that leverage whatever cloud configuration automation they wish to use.
The Intellyx Take
By treating COBOL code conversion as a data problem and leveraging machine learning-based text analytics, CloudFrame can generate modern Java fully cloud-native code in its construction.
Such conversion is never a simple question of a line-by-line translation, as there are many other considerations, including software architecture, differences in the execution environment, and the business context of the software itself.
The converted code is thoroughly modern and ready for developers to continue the refactoring and innovation tasks that will continue to move the once-legacy codebase forward – without worrying about the challenges and pitfalls of JOBOL.
Jason Bloomberg, President, Intellyx
Copyright © Intellyx LLC. CloudFrame is an Intellyx customer, and Microsoft is a former Intellyx customer. Intellyx retains final editorial control of this article.
Find Out More
Learn more about Renovate.