Transcoding Cobol to java: the ‘Hello, World!’ case

This content is also available in: French

This post is the first of our serie about transcoding. Read them all via the link “Transcoding” to get an understanding on how we proceed to convert application 1oo% automatically from Cobol to Java.

The right first step for such a tutorial serie is to go through the traditional “Hello World” in Cobol and see how we transcode it to Java.

DISPLAY "Hello World!".

The java version of the original Cobol demonstrates many points.

package com.nea_samples.batch.basic.programme_batch ;                   // (1) IDENTIFICATION DIVISION.

import com.eranea.neaRuntime.*;
import com.eranea.neaRuntime.core.basePrgEnv.*;
import com.eranea.neaRuntime.core.lineMode.*;
import com.eranea.neaRuntime.core.misc.KeyPressed;
import com.eranea.neaRuntime.core.program.*;
import com.eranea.neaRuntime.core.sqlSupport.*;
import com.eranea.neaRuntime.core.varEx.*;
import com.eranea.neaRuntime.pluginsIntf.cics.CESMReturnCode;
import java.math.BigDecimal;
import com.eranea.neaRuntime.core.neaVersionning.*;

public class HELLO_WORLD extends CobolProgram
                                                                        // (2) PROGRAM-ID. HELLO_WORLD.
                                                                        // (3) AUTHOR. DIDIER DURAND.
                                                                        // (4) DATE-WRITTEN. JAN 2012.
    public void procedureDivision() {                                   // (5) PROCEDURE DIVISION.
        display("Hello World!") ;                                       // (6) DISPLAY "Hello World!".
        stopRun();                                                      // (7) STOP RUN.

Java source code not byte code

we generate fully compliant Java source code and not JVM byte code. This approach has major advantages:

  • the generated application is no longer dependent on our transcoding tools when the migration project is finished.
  • the new source code is regular and plain Java source code that can be handled, processed and analyzed by all Java tools available on the market: javac, Eclipse, Netbeans, CheckStyle, Findbugs, Cobertura, etc.
  • the customer can fully get rid of the obsoleting Cobol technology and mutates its development environment to Java (Eclipse, etc.) which clearly represents current state-of-the-art technology for large corporate applications
  • we made quite a lot of efforts to make the Java source code readable, understandable and maintainable as it becomes the new reference. We preserve original code organization, variable and paragraph names, etc.
  • for readability purposes and for a simpler transition of Cobol programmers to the new Java world, we generate the original Cobol as Java comments on the right side. Each line is Cobol is on the same line as its Java replacement: Cobol developers can better understand how we replace Cobol verbs with their Java equivalent. The learning curve is then much shorter as people on a permanent basis the correspondence between Java and Cobol. It also makes us of Java interactive debugger much easier for beginners.

Java package organization

At the beginning of translated Cobol program as in any Java class definition,  a Java package is defined [here it is com.nea_samples.batch.basic.programme_batch - see line 1] to “position” the class in the hierarchical grouping of source code in the application.

It  allows smart grouping of original Cobol files. When we enter a new project, we usually get thousands of files (Cobol programs, Copy books, SQL statements, BMS / 3270 map definitions) in a single big and flat bucket.

This non-organization is not safe and can make use of an important feature of Java: packages. Packages have several capabilities: package access protection being among the most salient ones. See this Wikipedia page for more details.

So, we have a tool (based on regular expressions applied to original file names of Cobol application objects) that allows all the files to be dispatched in various sub-buckets: the name of those sub-buckets combined to domain name of our customer allows us to generate a hierarchical structure of Java packages that makes it simple for developers to work only on a part of the application.

Rather than checking out, updating and committing the full Subversion source tree under Eclipse, each developer can restrict its working set to a limited number of packages and consequently be more efficient and generate less issues.

Additionally these packages reflected as a hierarchical path in Subversion allow to erect barriers among different parts of source code for better security in corporations where it is required (finance institutions, etc.)

Java code structure

We preserve file organization and names: a Cobol program PGM.CBL become the equivalent Java class named The class stored in this file inheritates from java class CobolProgram.

This class CobolProgram is very important in our runtime framework (named NeaRuntime): it encompasses all the methods that emulate the Cobol verbs. In this 1st example, we see that DISPLAY in Cobol is changed to a call to method display() of Cobol program. In the same manner, STOP RUN in Cobol is replaced by a call to stopRun() of CobolProgram.

We also preserve the structures of Cobol: the Procedure Division is here . It is in fact an abstract method required by CobolProgram in the object-oriented hierarchy of our runtime framework. This way we make sure that the method is always present (generated anyway by the transcoder) and we can call it safely to start program execution by calling it.

procedureDivision() implements then the various verbs in reading order of original Cobol. More details about paragraphs, PERFORM, GOTO, etc. in upcoming articles.

At top of file, we also include all of the packages of our framework that are needed to emulate Cobol verbs and  also CICS and SQL verbs when used.

Leave a Reply

Please use your real name instead of you company name or keyword spam.