The enterprise journey to decompose the COBOL banking core into Java — The developer perspective 4/5
Facing the challenge to translate code automatically and not to die in the attempt. Part 4 of 5. — Automatic translation — The journey.
Someday meanwhile I was bored in my chair tracking and identifying Cobol variables I started to think that if wouldn’t be great to automatize all this process and in some way being able to write java code automatically similarly to the tools seen before but adapting it to our necessities.
Then, for a moment I remembered my compilers class in the university in which I developed a C compiler and realized that exactly it is what we are looking for, only without the last phase to generate bytecode or intermediate code, we needed to identify the cobol syntax and then translate each sentence into a equivalent sentence in Java.
We needed a source-to-source compiler.
Why I haven’t tough that before? If I have seen the automatic translation tools… The explanation I found it’s that I saw the tools as a final product and because I was unaware of how this tools are created I didn’t correlate the concepts, until now I feel a bit guilty for non identifying earlier this opportunity.
Once I realized this chance, started with my coworkers to develop one solution, that’s where ‘the journey’ started.
The journey —Understanding how the code it’s made.
I started to do a bit research on topics like lexical, syntax analysis and language translation. Even inspecting some old school notes about compilers and tools. I understand that developing a tool to analyze the syntax would take some time, then, doing some research I found some interesting tool named “Koopa” that could give a boost in the development process.
Koopa it’s a cobol parser, one of the most interesting characteristics it’s that the parser can generate an XML with the syntax tree of the source cobol file that its being analyzed. The parser generates XML tags specifying the instruction being processed. i.e. for the MOVE statement.
Analyzing it, we decided to develop a tool capable of traverse the XML file to generate the equivalent Java code.
Next you can see a diagram about the process proposed, additionally we processed the cobol copybooks using a program written by a coworker and generate equivalent java beans.
It sounds like a great deal, we were achieving results assigning different Cobol instructions to each member of the team to translate into a Java equivalent, i.e. the ADD instruction used in Cobol to compute the sum of two numbers, or the programming of the PERFORM instruction into a method declaration in Java, unfortunately the progress was really slow and earlier we found that the process taken to develop a system, programming each equivalent from an XML tag into a java structure would take a lot of time and certainly not enough to be able to translate every sentence into a productive Java code; also the process of generating Java beans by copybooks started to take a lot of time of development because my college was reading directly the copybook file instead of using the XML generated by Koopa provoking a lot of issues related to understand all the different ways a copybook can be defined and handle each one into a representation in Java.
After a meeting with the manager and the development team, we decided to shutdown this initiative. We have found another way in which we cannot migrate the banking core.
Which way the team should follow if appeared that each idea didn’t accomplish our expectations or becomes too long to realize, we have traveled the first part of the journey and everything appeared like deep shadows with no promising results; but programming like life have ups and downs and we’re not going to give up easily.
If you are interesting reading further follow this ->link
