Slashdot Mirror
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!"
I sympathize, but I suspect you're out of date. I remember doing some projects in Java in 1996/97. My conclusions at the time were that the language was pretty nice and clean, but lacked some of the stuff that seemed to me at the time to be important (type-safe generic programming capability), the runtime was too slow and too clumsy (shouldn't have felt like installing another OS on top of my OS), and the standard libraries were reasonable except for some stupid omissions (no interruptible I/O primitives .. from a Unix company??), and a horrible GUI (twice: AWT didn't expose the richness of the native GUI, Swing was slow as a dog for a long, long time.)
.. but I still don't understand why it took so long, or why everyone got so excited by version 1.0. Looking back, I'd've been interested in, say, a version of C++ with the direct memory access removed, i.e. no pointers, and some decent cross-platform standard libraries. The VM didn't interest me, but could easily have been added as an option later, as has happened with languages (Perl, Python, ...)
I felt it had its place but couldn't understand what all the hype was about, and went back to my C++. Now I gather most of my grievances are fixed
Of course, "web hype" sells stuff in IT, just like sex does everywhere else. Witness the current Web 2.0 lunacy, where everyone's excited that we might just finally manage to produce web apps with usability that approaches that of the native applications we had 15 years ago. *sigh*
Though I could think of a ton of jokes - and have already seen a few - my first question is, "why."
.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.)
:)
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
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...)
The Kai's Semi-Updated Website Thingy
I agree with your objections and have seen these problems so many times over the last decade that it is getting hard to believe that someone can't write a decent translator.
Java is usually very easy to refactor (smart editors).
It seems like a two or even three stage pass would work.
Stage one, COBOL to raw java.
Stage two, raw java to better formatted java.
Stage three, better formatted java to even better formatted java.
I wrote an RPG3 to RPG4 converter back in 2000.
It used 5 passes-- each a small simple program.
The result was actually fairly close to procedural java-- if we had decided to go with java, I could have written a 6th program to do that conversion.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
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.