Follow

Does Elastic COBOL generate Object Oriented Java?

Yes.  By definition, anything in Java is "object oriented," but the Elastic COBOL compiler generates code in such a way that a Java programmer can leverage the formerly COBOL program in an object oriented way.  Further, even if the Java program is run just like the COBOL version (from a command line, from a JCL batch job in Elastic Batch Platform, or from a JEE Application Server as a transaction using Elastic Transaction Platform (ETP) capabilities) it leverages the full object-oriented nature of Java to do its job. 

Take, for example, the following COBOL statement:

MOVE A TO B.

It is translated to Java:

wrk.b.move(wrk.a);

This works no matter how A and B are defined because the COBOL standards outline specific steps that are to be followed when converting between data types.  If A is character string (PIC X(10)) and B is a numeric (COMP-3 integer or COMP-2 floating point), what happens to the fractional portion, what if it doesn't contain a number or is all blank?  Try this in using an assignment statement in Java and you get a syntax error at compile time,

String a = "bad.data";
Double b = a; // syntax error - incompatible types in assignment

or a Java traceback at runtime,

String a = "$45.32";
Double b = Double.parseDouble(a); // runtime error - NumberFormatException, Java stack trace

By using Java polymorphism to have multiple "move" methods, the Elastic COBOL runtime can follow the appropriate standards concerning conversion "conditions," "size errors," etc. some of which have changed over the years or by different COBOL dialect implementations.  Using compile-time or run-time options allow the generated Java program to perform exactly as the original COBOL program did on its original platform, without source code modification.

Another example is the ability of the Elastic COBOL compiler to perform a "business rules extraction" service, allowing Java programmers to use individual rules (in the form of paragraphs or sections) without invoking the entire program.  Consider the following COBOL program:

IDENTIFICATION DIVISION.
PROGRAM-ID. TAX-PGM.
INPUT-OUTPUT SECTION.
FILE-CONTROL.
    SELECT PURCHASE-FILE ASSIGN TO DD1
    FILE STATUS IS STAT-CODE
    ORGANIZATION INDEXED
    RECORD KEY IS ORD-NUM
    ACCESS IS DYNAMIC.
DATA DIVISION.
FILE SECTION.
    FD PURCHASE-FILE.
    01 REC.
       03 ORD-NUM PIC X(10).
       03 ST      PIC 99 COMP.
       03 PURCH   PIC 9(5).99 COMP.
       03 TAX     PIC 9(5).9(2) COMP.
WORKING-STORAGE SECTION.
    01 STAT-CODE  PIC 99.
    01 PURCHASE   COMP-1.
    01 STTAX      COMP-1.
    01 STATE-BASE-TAX.
       03 RATE COMP-1 OCCURS 50 TIMES INDEXED BY STATE-NUMBER.
PROCEDURE DIVISION.
A SECTION.
INIT.
    MOVE 0.0175 TO RATE(1). |> AK
    MOVE 0.0825 TO RATE(2). |> AZ
    |> ...
    MOVE 0.0542 TO RATE(50). |> WY
OPEN-PURCHASE-FILE.
    OPEN I-O PURCHASE-FILE.
MAIN.
    READ PURCHASE-FILE.
    PERFORM UNTIL STAT-CODE NOT = 00
        MOVE ST OF REC TO STATE-NUMBER
        MOVE PURCH OF REC TO PURCHASE
        PERFORM TAXIT
        MOVE STTAX TO TAX OF REC
        REWRITE REC
        READ PURCHASE-FILE NEXT
    END-PERFORM.
CLOSE-PURCHASE-FILE.
    CLOSE PURCHASE-FILE.
    GOBACK.
TAXIT.
    COMPUTE STTAX = PURCHASE * RATE(STATE-NUMBER).
    END PROGRAM.

The compiler generates "rules" (Java methods) for each paragraph.  Further, the working storage section (variable storage) is separate for each instance of the program, allowing threading, invocation from Web services when operating under a JEE Application Server, etc.  A Java program could leverage this capability by writing a native Java program:

import com.heirloomcomputing.ecs.exec.*;
public class taxing {
    private static int name2num(String state_name) { /* ... */ return 1; }
    public static void main(String args[]) {
        if (args.length != 2) {
            System.err.println("Usage: java taxing state-name purchase-amount");
            System.exit(1);
        }
        tax_pgm tp = new tax_pgm();
        tp.setup(null);
        tp.init_OF_a();
        tp.wrk.state_number.move(name2num(args[0]));
        tp.wrk.purchase.move(args[1]);
        tp.taxit_OF_a();
        System.out.println(" base state tax on purchase of $" + args[1] +
                " in " + args[0] + " is $" + tp.wrk.sttax.toText());
    }
}

Leveraging the object-oriented nature of generated Java allows the logic from the original COBOL application to be extended to folks that don't normally deal with COBOL procedural programs.  This is common in the Java world as it is dominated by packages, frameworks and downloadable, "obfuscated," jars that perform various functions.  Java programmers can simply think of the Elastic COBOL generated Java as a "magic jar" that does exactly the business logic they need to accomplish their goals.

These programs are compiled and run with the following commands,

$ ecobol -out:translate tax-pgm.cbl
$ javac  taxing.java
$ java   taxing AK 1100.00
 base state tax on purchase of $1100.00 in AK is $19.25

Was this article helpful?
1 out of 1 found this helpful
Have more questions? Submit a request

0 Comments

Please sign in to leave a comment.
Powered by Zendesk