The enterprise journey to decompose the COBOL banking core into Java — The developer perspective 5/5
Facing the challenge to translate code automatically and not to die in the attempt. Part 5 of 5. — Automatic translation — The journey.
One day, having a conversation with my manager about the strategies taken in the last months to migrate the banking core we started questioning ourselves why we have discarded some automatic translation tools, my manager reminded me some tool that we had discarded because it was difficult to set up the and the code generated had poor quality and wasn’t functional, no one of us can remember exactly if the code was that bad and if was true that it’s difficult to set up the tool, without having much hope we decided to give a second try and after a bit effort we get the tool working. The name of the tool it’s RES and we get really surprised with the results provided.
RES it’s the name of an open source tool made by Venkat Krishnamurthy (thank you Venkat), the purpose of this tool is to provide the ability to translate automatically procedural code written in Cobol into Java classes, it works using a jj file which provides the gramatics allowed for a cobol program and generates a syntax analyzer capable of identifying each Cobol sentence and translating on the fly into productive Java code also uses Java Tree Builder to traverse the previous syntax tree using the Visitor design pattern.
One of the most interesting advantages of using this tool it’s that you didn’t need to understand the business logic immerse in each transaction to be able to migrate from one language to another, also the parser has the ability to identify sql sentences in the cobol code and parse into PreparedStatements which can be executed into the database with minor changes. Lately we modified the tool to use instead of PreparedStatements an API for persistence developed in the bank by one really brilliant teammate that probed to be really more efficient than using the traditional way to querying a database.
One of the first challenges was the understanding of how we can add new syntax words proper from the Cobol used in the bank to a new Java implementation; I wrote an article explaining this.
Another disadvantage we found was that the generated code by the tool was something similar to a JOBOL implementation because we were translating line by line and the source language was structured in a procedural way, now the code generated in the best of the cases would be procedural but using an OOP language, this situation affects the maintainability by becoming hard to make changes to the code in the future, i.e. trying to add a new field for a transaction.
Following up I’ll show you some screenshots of the tool working, we activated the printing of the concrete syntax tree meanwhile the tool was reading the cobol file being translated. I changed some names to avoid showing up information from the bank.
Despite the previous detractors found analyzing the tool, it appeared that we were ended the journey and found one way in which the migration would take place before the deadline, we decided to give a try and started translating Cobol.
We weren’t either aware that we’ll be facing one task harder than translating code, we were facing the challenge of providing these transactions with the basic data to be executed and ensuring that all processes in the bank worked in the same way that in the previous implementation of the banking core, to the working set of this characteristics it’s known as the Alnova Architecture.
But without knowing it, the journey was just beginning…
