Transforming COBOL to Java

How can businesses move safely and cost-effectively from COBOL to leading a Object Oriented language such as Java? This document explores migration through automated code transformation, a mature approach being perfected by Anubex, as an answer to this question.

The document explores the key business drivers for making the step from COBOL to Java #, and how Anubex’ CodeTurn makes this transition possible. It will explain the added value Anubex migration offers over other approaches, and demystify the migration process. Detailed white papers with a step-by-step look at the way COBOL can be transformed into working, maintainable Java code are available upon request through the button at the top of this page.

1. Why transform from COBOL to Java?

1.1 Reasons to go to Java

There are many good reasons to make the move to Java from COBOL, but the following are the largest concerns for businesses today:

Java offers answers to all of the above concerns:

Next to that, moving to Java also means:


1.2.    Approaches: Replacement, Rewrite or Automated Migration

Once the need to move away from COBOL has been established, the next big question is: how to turn a large, mature COBOL code base into its OO equivalent?

Most organizations take one of three approaches:

Replacement by COTS software is the most cost-effective solution, but only practical if one can actually find 3rd party software that offers the same functionality as the existing COBOL application.

Rewriting on the other hand too often has led to huge costs and ultimately to project failures. According to a research note from Gartner(2), the cost for rewriting is between $6 and $26 per Line of Code (LOC), and accomplished at a rate of 160 LOC per day and per developer. Extrapolated even to a moderate code base of 1M LOC, it is obvious that these will become very expensive, lengthy and risky projects.

Anubex advocates automated migration as the only realistic approach for large, legacy COBOL applications:

All the above, combined with a vast experience in executing migration projects, gives Anubex the confidence to offer projects with fixed duration and fixed price, equivalent functional behavior and equivalent performance.

Like most IT projects, a migration project is a complex undertaking, one that deserves the right amount of expertise and dedication. Anubex has developed project and product methodologies over the past decades to deal successfully with these challenges: we are happy to provide you with more information regarding these.

[1] Gartner Research Note "Forecasting the Worldwide IT Services Industry: 1999,1"

2.    COBOL to Java: Architecting a Transformation

This section focuses on the underlying design principles that any migration from COBOL to Java should take into account, and how Anubex has incorporated these in its flexible toolset.

2.1.    Keys to a Successful Migration

What are the keys to a successful migration project? A primary concern in any migration is how to validate the functional correctness of the migrated programs. In COBOL to Java migrations, this can be hard, especially if the COBOL programs are driving business-critical processes and they are being adapted to evolving user requirements while a migration is running at the same time.

Under these circumstances, migrations should target:

Equivalent program behavior and performance
For programs to be functionally correct, business users have to accept them. For large COBOL applications that are being actively maintained, users and developers have an existing and well-tried process to specify changes, develop, test and bring new releases into production. This familiar process should not be disturbed by migration efforts. An important best practice in migrations is targeting functional and performance equivalence with the production release, and avoiding whenever possible the introduction of functional extensions that don’t exist in the COBOL application. This approach makes it possible to leverage automated testing tools to reduce project costs, improve accuracy and move the project forward faster.

Automated, iterative processes
To manage risk, the generally accepted process in migrations is no different from that of conventional software engineering: using agile, iterative processes that can periodically align the migration project to the latest versions of the COBOL programs undergoing the migration. Consistency and speed are also critical to a parallel iterative process. Using tools to automate the migration imposes rigorous consistency of transformation and brings the end goal within reach of stakeholders.

Developer confidence
There are many differences between COBOL (a structured, compiled, business-oriented language) and Java (an object-oriented, managed, multi-purpose language). COBOL developers that need to maintain the new Java programs will need to be confident in their ability to recognize the business rules and correctly implement and test the changes they make after the migration is completed. Meanwhile, new Java developers also need to feel comfortable with the migrated code to maintain it like any other regular program.

2.2.    Key Traits of a Professional Software Conversion Tool

The key hallmarks of a professional language translation tool are the way it can strike a balance between three spectra of interest. Anubex’ CodeTurn for COBOL transformation offers a solution to each of these areas:

Customization and Consistency
Anyone who has written software in a team before, knows any program can be written in a variety of ways. A professional software code transformation tool will provide the means to apply customization options that suit the requirements of the customer. These options can be simple things like naming conventions and the formatting of comments, or they can be more sophisticated, like the extent to which the tool will optimize structural patterns in the COBOL code. At the same time, the tool should make it possible to manage such a configuration of customization options for a consistent application in an iterative process. These management facilities should also include configuration of other aspects of the migration like the translation of scripts, screens, or databases.

Maintainability by COBOL and Java Developers
Consistent translation improves the maintainability of the generated Java, but for the Java code to be easy to work with for the original COBOL developers, it also needs to be based around simple design principles. This means the tool should generate code that allows as much as possible a 1:1 relationship between the number of lines of COBOL code and the number of lines in the target language, and reuse (wherever it is syntactically allowed) the names of identifiers appearing in code. This will facilitate the recognition of business entities and rules in the target language by the COBOL developer. At the same time, Java developers with limited exposure to COBOL should be able to pick up the programs and be optimally productive in the shortest possible timeframe. Simple design principles improve the understandability of the converted programs also by these developers. Typical COBOL constructs that are unknown in Java (like DECLARATIVES or PERFORM) are transformed into their closest equivalents in the target languages.

Functional Equivalence with COBOL and Full Support for the Target Platform
The basic requirement of a conversion tool is that the code it produces is 100% functionally equivalent (including side effects encountered at runtime) with the original COBOL code. At the same time, the code that is produced should enable full use of the richness of the target platform. This means some COBOL language syntax will be replaced with calls to platform APIs in Java or .NET. It also means that the code should be fully usable in modern development tools like Visual Studio, Eclipse, IntelliJ or NetBeans and support execution in debug mode. Last but not least, the converted programs must easily be integrated with newly written programs and vice versa, hereby ensuring a solid basis for continuous improvement and further modernization.

2.3.    Flexible Tools

2.3.1.    Rationale

For transformations from one programming language to another, Anubex has built a set of tools collectively called CodeTurn. These tools share one important consideration: each customer is different, and each migration is different. Every organization has its own development and design standards, patterns and frameworks. Some prefer all data access in a separate layer, others choose for embedded data access.

When migrating from COBOL to Java, some organizations prefer to keep the resulting code relatively close to the original COBOL, for reasons of readability and maintainability by the existing developers. Other organizations will choose a more radical approach and prefer code that uses more Object-Oriented design patterns.
In order to be able to accommodate these considerations, standards, and frameworks the Anubex tools can be parameterized and customized for each project.  

To address the stringent requirements listed above, Anubex has chosen a modular approach to building a migration toolset for all of its supported source technologies (COBOL, IDMS, Natural, …).

For language to language transformations, such as from COBOL to OO, the architectural overview of the internals of CodeTurn looks like this:

  • Parsers that support all COBOL dialect syntax, and also embedded languages (e.g. EXEC CICS or EXEC SQL)
  • Resolvers that link together the AST  that is produced by the parsers with control-flow and data-usage information
  • Conversion rules for all COBOL syntax, from single statements to complex patterns of code, as part of the COBOL to OO Converter
  • Code generators for Java, C#, and various COBOL dialects enabling any desired coding style
2.3.3.    Procedural vs. Object-Oriented Paradigm

Another example of the importance of flexible tools lies in the preference of some developers for Procedural-Style code, while others prefer to take maximum advantage of OO-concepts.

Anubex offers both variations, as can be seen in the following short COBOL code snippet:


More information

To read more, request your copy of the full 40-page COBOL to Java transformation white paper, including elaborate examples, by clicking the button below!