COBOL to Java Transformation: How to do it

Hi, I’m Giovanni, development manager at Anubex, and I'm going to explain the four key ingredients to successful COBOL to Java transformation. Please be aware of everything I say applies equally when targeting c-sharp. COBOL's always used in the context with our technologies, this means that most applications use files, or they access the relational database, or they run under kicks or UTM. Also, the source code itself has embedded languages which you can recognize as exact SQL or exact kicks. What that means is that having a complete solution means having a solution that also transforms these embedded languages, and not only the global code itself.

Anubex CodeTurn has been designed with modularity from the start, this means it can handle multiple embedded languages and also multiple output languages. With regards to having many configuration options and much intelligence out of the box, I want to talk about two specific examples. The first example is that of dead code, and with dead code I mean code that is not utilized by other codes and also variables that are not used at all in the code base. CodeTurn offers three options, just keep it in the Target Java, keep it but comment it out, or omit it entirely, whatever a customer chooses is good for us. An example of built-in intelligence is how we can apply context sensitive transformationals to the widely used COBOL go-to statements.

Now in the most General case, a COBOL go-to statement really implements a state machine, in these cases we have to transform it into a COBOL. go-to method invocation where the go-to method is implemented in the support library that makes sure that the control flow is exactly in Java as it was in COBOL. Static code analysis however can show that up to 95 percent of all go-to uses are uses where the go-to implements a form of loop or early exit points, and in this case we can transform it in Java to a break statement, a return statement, or a while loop. however some customers still prefer the global.go-to Syntax for instance of familiarity, and you know that's fine too. That brings me to the third essential ingredient of successful COBOL to Java transformation, having a support library that ensures 100 correct global behavior while being in Java. COBOL is a language where each statement has very interesting and special side effects, and it's the accumulation of all those small side effects in a large application that leads to behavior that can only be replicated by replicating each and every side effect itself. Doing that in a way that doesn't lead to code below an immutable code means that you have to introduce a support library, and this support Library needs to be 100% accurate.

While I could give you many examples of these subtleties in the COBOL language, I will focus on one very pertinent one which is COBOL numeric fields. It's a fact that COBOL numeric fields can actually contain non-numeric data by virtue of the fact that each COBOL field has a backing star which is with raw bytes, and redefines and other implicit redefining mechanisms can be used to really put arbitrary bytes at those locations. What that means is that in a COBOL to Java transformation, we can often not use the native numeric types of Java like int or long or big decimal, because that would just not have the same behavior as in COBOL, because Java being a much more strict language doesn't allow non-numeric data in numeric types. Now you might ask me so you never go to native Java types if doing a transformation from COBOL to Java, and the answer is yes we do of course, if we can analyze and prove that the resulting behavior is correct, we will do so. A good example of that is COBOL loop variables, if you have a performance varying loop for instance, and the loop variables only used in the context of this loop, we will happily replace it by an internal long in Java. Now where we cannot do that and where we would like to do it however, is that of COBOL arithmetic expressions.

As you can see an arithmetic expression when evaluated in COBOL doesn't lead to the same result when doing it in the intuitive way in Java. If just using a double an INT or a long you just get a different number, and I've yet to encounter a customer that doesn't take his numbers adding up seriously. This brings us to the fourth and final ingredient of a successful call to Java transformation. Once the transformation project has ended, the resulting codes must be a good starting point to do further modernization. This really means two things, there must be absolutely no restrictions using native Java types native, Java functionality, or native Java libraries, and it must be possible to incrementally change code, to incrementally refactor and modernize parts of the transformed code base. In other words, we encourage our customers to think for themselves, hopefully they want to go in the further modernization of their application and at which pace they want to proceed.

So to summarize, a successful COBOL to Java transformation needs a flexible tool set, a complete solution, a good support library, and it needs to result in code that lends itself for further modernization. If you want to learn more, please download one of our white papers at anubex.com you will also find many code examples.

‍