Automated Migration From Cobol To Java On Linux

Didier DURAND writes "Just published an article about our 100% automated migration from IBM mainframe with Cobol to Linux Java: we could convert of our own application (4 million lines of code) through the tools that we developed. Those tools are open-sourced under GPL for other companies to benefit from them. We save 3 millions euros / year after this migration!"

Comments

Serious Question Here

[filesiteguy]

Though I could think of a ton of jokes - and have already seen a few - my first question is, "why."

I can see the possible benefits of no longer relying on aging cobol programmers. I am often dealing with just this issue as I migrate '70's and '80's era systems off off ADABAS and COBOL. However, why would one want to make a one for one class creation of existing mainframe applications. I honestly remember a few programmers I knew doing this right before they retired back in '05. They took a COBOL/IMS application running on an AS390 and turned it into a HTML/ASP.NET application written in C# with IMS and SQL Server on a z890 in virtual MVS and SLES environments. The screens - web based now - were one for one matching with the previous mainframe screens.

My question then too, was why bother?

I just finished a second project in taking a '80's era mainframe application - this one to track the purchase of vital (birth death marriage) records - from mainframe into an n-tier model. Instead of simply copying the mainframe screens we spent time deciding what worked on the mainframe and what didn't. Some of the mainframe concepts - particularly in the public lookup - were fine. They stayed and became web-based applications. Other items were thrown out the window and completely re-worked into a user-friendly and efficient system. (In this case, we used MS .NET 2005 and C#, but we could have just as easily used Java. I'm not trying to say anything about the choice of language or underlying platform.)

Having done a similar project for real property records in '07, we learned many lessons and were able to reuse assemblies in the new application. In fact, the entire UI, security, printing, data encapsulation, image import (there are over 160M TIFF files in our system), reporting and cashiering/finance/cash handling subsystems are identical and shared among both applications.

I can see possibly wanting to utilize some classes for back end work but wouldn't it be better to review these individually and decide what is best?

Oh, and we're saving roughly $3M/year in mainframe costs. :)

(Okay, post finished now to wait for someone to mod me as a troll...)

Re:"Automated"

[dwye]

Java - when properly written - has been proven to be as fast in file operations, memory access and sequential processing as true "compiled" applications.

Will the conversion program "properly write" its Java code, though? Care to lay odds? Especially considering that most COBOL code still in use is the code that uses COBOL's documented features (what were bugs in IBM 360, until they were written down, used, and so had to be replicated in any "real" COBOL implementation) to ... an unfortunate extent?

The place that I worked at had a project to convert its legacy COBOL to C/C++, and it got to 90% easily, but the last 10% required manual conversion and/or rewriting the converter to handle the "missing" elements. I doubt that conversion to Java will be any more successful, at least on live, rather than sample, code.