Automated Migration From Cobol To Java On Linux 195
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!"
Re:Sign of the times (Score:3, Interesting)
Re:"Automated" (Score:4, Interesting)
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*
Serious Question Here (Score:5, Interesting)
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...)
Re:Maintenance Maintenance Maintenance (Score:4, Interesting)
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.
Re:I sense a modest disturbance in the job market. (Score:3, Interesting)
Make that ten, although I've only coded COBOL at home for fun. Yeah, I'm probably some kind of masochist but I really wanted to give the language a spin and see if it was as horrible as people say it is.
/Mikael
Re:Serious Question Here (Score:3, Interesting)
I was wondering that too.
My guess is that the business rules behind the application were known by each of the COBOL programmers. They didn't want to ditch the COBOL guys, but could see the age creeping in. So they decided to switch to Java as a compromise between a expensive rewrite that would render the COBOL programmers mostly useless and business as usual. Hey, you get a modern, functional language that is popular and get transition your COBOL guys into the syntax.
I think it will come back to bite them in that they aren't going to magically be able to hire a Java programmer and have them ready to work within the same transition time as, say a truly OOP project would. The code is still the same, just with java syntax. Worse, a new programmer may start to write OOP code in a manner that the COBOL folks don't understand.
Is it certified as a conforming COBOL compiler? (Score:3, Interesting)
I know there is a certification program to check that a commercial COBOL compiler processes the whole language and produces output code that performs correctly. (Can't recall the name at the moment though I think it was in the US government - perhaps in the DoD.) I'm wondering if this tool has been submitted to that and, if so, whether it passed.
I'd occasionally thought it would be a useful thing to do something similar to this (but with ANSI V2 C++, rather than JAVA, as the target language) - and then get the tool certified. With such a certified tool IT administrators could, with confidence, transcode a COBOL application base into a language with multiple commercial and open compilers a long expected support lifetime, generating native code for virtually all possible targets (from PC clusters to current and future mainframes). If the transcoded output doesn't become excessively opaque and class-dependent it could later be warped into a more native form, should that be desirable.
Perhaps this project will be able to actually do it.
Re:Per slide 25 (Score:3, Interesting)
MOVE FW-1ER-OCC-AFF TO J
INITIALIZE SW-SEL-SA02
Either way java seems like an improvement. I know in Cobol you can have expressive variables (readability was one of the original selling points of Cobol), so I'm going to guess that they have such weird looking variables on purpose. If you had decently named variables in the Cobol, it stands to reason that you would be able to have readable code as an output from their tools.
Re:"Automated" (Score:5, Interesting)
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.
Re:I have automatic translation to machine code (Score:3, Interesting)
Ha, you think you're joking, don't you? A friend of mine used to work for the Air Force in one of their less high-tech establishments, a place that did inventory. The software, all locally developed, was written in Fortran. However, changing the source and recompiling was extremely tedious since it meant punching new cards, running them through to compile, then running the result of the first run through to link, then running the linked code, then transferring the output to another machine that could print. So, instead of changing the source, they edited the machine code. (And you wonder why they lost the aliens at Area 51...)