What about my COBOL programmers when migrating to Java?

Much of the world’s critical infrastructure, such as state agencies, financial services, healthcare, transportation, and other major industries, depend on mainframes and business applications written in COBOL (COmmon Business Oriented Language).

For many of these organizations, modernizing their IT systems and moving workloads to the Cloud has become imperative for agility, cost-efficiency, and competitiveness reasons. In this context, there are many good reasons to make the move from COBOL to a modern object-oriented (OO) programming language, and the following are some of the biggest concerns for businesses today:

• High (and rising) maintenance and runtime fees for the existing COBOL products
• End-of-life scenarios for certain COBOL technologies
• Lack of application extensibility and interoperability with other, non-COBOL applications

COBOL talent-shortage is another major factor that comes into play when organizations decide to migrate to more popular programming languages, such as Java or C#. That’s when every IT leader must make a decision about the development team, and what will happen to the COBOL programmers in this scenario.

Preserving the application's behavior

The short answer after having implemented tens of migrations to OO is that the COBOL development team can transition together with the application by learning Java while retaining their core value: profound knowledge and insight into your company’s applications and business processes.

In general, in takes a lot more time and effort to get accustomed to the ins and outs of a mature, decades-old codebase than it takes to learn a new programming language and the associated toolset.

Next to this general learning principle, our COBOL to Java solution exhibits very specific characteristics that make it easy for a COBOL developer to still recognize their code after the transformation.  

Here are the most important ones:

• At the highest level: the overall structure of the application – with its divide into programs – will still be there, as each COBOL program will result in a single Java class. This means that the application remains recognizable in terms of its source files: each COBOL source will be represented by a single Java source, and that holds true not only for sources that contain actual programs but also for almost all copybooks, which will become separate Java classes.
• Looking deeper inside these Java classes, the inner structure of COBOL programs, the divide between data areas and code areas and even the order of paragraphs are still there with the order of the Java methods corresponding exactly to the original paragraph order.
• At a still more detailed level: all comments are preserved and still attached to the sections of code they were originally associated with. The names of variables, programs, files, and sources are also there.
• At the COBOL individual statements level: most COBOL statements have very specific behavior that doesn’t correspond directly to what is available in Java. So, during the transformation, we have to provide implementations of these statements that conform 100% to the original COBOL behavior and in order to avoid code-blow. We do that by bundling them inside a support library. This leads to transformed code doing lots of method invocations that look like ‘cobol.display’, ‘cobol.unstring’ or ‘cobol.call’, corresponding to the three well-known COBOL statements DISPLAY, UNSTRING and CALL.

For the COBOL developer, this means he will not only feel immediately familiar with the structure of the Java codebase, he can also understand most of its meaning even before he will have learned Java.

COBOL applications maintenance

What does it take for a COBOL developer to not only recognize the transformed code but actually be capable of further maintaining and extending it? A basic java language course and a one-day training session in which the core principles of the transformation and the support library are explained.

Past experience shows that this is enough to enable almost all COBOL developers to become productive maintainers of the new Java codebase. Depending on the individual ambition and talent, some will go beyond and become general-purpose Java developers. Others will stay productive application developers, just as they were before.

To conclude, a COBOL to Java migration project really empowers COBOL developers to extend their careers. At the same time, a forward-looking company has the opportunity to build a mixed team that combines the very specific and deep application knowledge of the existing COBOL programmers with the Java-technology specific skills and know-how of new Java programmers.

Planning to migrate from COBOL? Get in touch with our experts to learn how your team can prepare for this transition.

Additional Resources

Transforming COBOL into Java White Paper

Transforming COBOL into C# White Paper

COBOL Transformation Options White Paper

Moving COBOL Workload to Microsoft Azure Webinar‍