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!"
"Automated" (Score:3, Insightful)
Sounds like it could turn out like WYSIWYG HTML Editor code. Where every word you bold has the bold tags, etc.
Dreamweaver, Word, etc all make some dang ugly HTML.
Re:"Automated" (Score:5, Insightful)
Re:"Automated" (Score:4, Insightful)
The alternative is to maintain a pool of cobol developers to maintain the code instead of hiring (probably much cheaper) Java developers to improve any bad code.
WYSIWYG's are a bad analogy, because it abstracts the process of writing HTML to a tool with the intent of writing HTML. In both cases (by hand or by machine) the results are HTML. With a -converter- like this one, the results may still generate bad code.
Re:"Automated" (Score:4, Insightful)
Cheaper Java programmers compared to what? People who know the code and business rules or people who will take years to learn the code and business rule, by which time they will be just as expensive. BTW, one of the stated goals was to migrate the people as well. That argument is a non-starter.
Re:"Automated" (Score:4, Insightful)
Re:Thank the Lords of Cobol (Score:2, Insightful)
What do transcoders really buy you? (Score:2, Insightful)
I'll say what they don't buy you: The ability to throw away the old language.
If changes need to be made - and they will - you will want to change the original language not some intermediate that is stilted and hard to read at best and a candidate for an obscufated insert-language-here contest at worst.
What transcoders do buy you:
The ability to compile code on a platform that doesn't have a compiler for your flavor of your language.
Re:"Automated" (Score:3, Insightful)
Assuming the transcoder kept things like variable names, I guess the Java code will be more or less as (un)readable as the original. Maybe a bit worse because of "objectification" overhead without real gain in structure.
So they saved a lot of grunt work (translating to Java without changing the functionality), but there is still a lot to do. As in, reworking the old code to take proper advantage of object orientation.
Per slide 25 (Score:5, Insightful)
All it appears to be doing is mapping COBOL line of code to Java Line of code, per Slide 25.
This is more about being able to find someone who can read and write java. The code remains procedural, the COBOL programmers do the same stuff, just in Java now.
Here's an example of the code that was spit out:
sql("SELECT * FROM RS0403 WHERE CDPROJ=#1").into(vrs0403a.dvrs0403a).param(1, tuazone.tua_I_Cdproj)
Not to dissuade, but in someways, they avoided doing a rewrite at all cost.
Great if you want to get off legacy systems, but it's not going to magically improve your code base. GIGO rules still apply.
Re:I sense a modest disturbance in the job market. (Score:4, Insightful)
My question is, "Do you also convert the CICS calls embedded in the code (and possibly 3270 terminal commands?!?) or is there a Java library to interface with CICS?" My experience with converters is that they follow the 90-10 rule, where they do great with 90% of the code, but that's the easiest, and could almost be done with global Find/Replace. The remaining 10% is why the conversion wasn't already done.
Later . . . Jim
Re:"Automated" (Score:0, Insightful)
Re:I sense a modest disturbance in the job market. (Score:2, Insightful)
No its the other way round. Now we can get rid of all these useless Java programmer, use our Cobol programmers who know what they are doing, and then convert their code to Java so that the PHBs who've been sold on Java can be happy.
Re:Per slide 25 (Score:3, Insightful)
"MOVE FW-1ER-OCC-AFF TO J
INITIALIZE SW-SEL-SA02
Either way java seems like an improvement. "
Yeah,
j = FW-1ER-OCC-AFF;
and
SW-SEL-SA02 = null;
is so much easier to deal with.
COBOL and other old programming environments sucked because they had limited length variable names, and no IDEs to help you keep track of variable names. This forced you to use naming standards to keep track of yourself, of which these names are undoubtedly an example of.
Re:"Automated" (Score:3, Insightful)
Don't worry RD - all those guys are full of shit. ...
I tell you what, let's show those guys just how awesome Java is
Let's start with the fundamental awesomeness of Java (over that weak ass C and C++) by listing all the operating systems written completely in Java.
No?
Ok, maybe all the boot loaders written completely in Java.
No?
Hmmm.
Ok, maybe all the space vehicles and satellites running completely on Java.
No?
Shit.
Ok, how about the end-all, be-all of language completeness : this will show them - WHAT LANGUAGE IS THE JAVA RUNTIME WRITTEN IN?
What's that? Not Java?
Well shit.
Fuck those haters. You watch, some day someone is going to invent a nice Java-like language (we can use pretty much the same syntax as Java) that is compiled instead of interpreted and will create native executables that run on the bare metal, something that can be used to write lightning fast applications, and even be used to write Unix and Windows type operating systems. It will be like 'Compiled Java', or maybe CJ for short. Maybe even shorten it a little more to just 'C'. And then people will write all kinds of fast, stable, OS quality binary code in this new version of Java, which we will call C. That will show them how awesome Java really is.
Re:"Automated" (Score:4, Insightful)
When "everything" is, "It's slow!", yeah.
Yes, yawn, there are some things Java is slow for and that need speed. You shouldn't do those few things in Java. So what if it starts slow? Don't spawn new processes to handle incoming connections. For any given issue there are workarounds. If there are too many issues to justify it, use another tool.
But, please, SHUT THE FUCK UP ABOUT IT!
Seriously, just don't fucking use it. Just because you're too retarded to evaluate tools for the job at hand doesn't mean everyone else is.
Java's not my choice either, but I don't feel the need to find every Java coder I know and rub it in. They're too busy redundantly declaring types to stop to chat anyways...
Re:Per slide 25 (Score:1, Insightful)
You cannot have decent named variables in Cobol. Not in a program much bigger than hello world.
Why? Because you only have global variables. So, rather than 100 functions each with 10 local variables, you have 1000 global variables. You try to come up with decent names for them. And keep them short, so we don't need to scroll horizontally to read the entire line. You see, the language itself takes a lot of room. Like:
ADD SALES-TAX TO PRICE GIVING RETAIL-PRICE
Usually, making the variables local from a programmer point of view (they are still global from the compiler point of view), is done by prefixing with the function they belong to. Often multiple prefixes, as the example given in the parent post.
Now, Cobol is used (only, basically) for business application. These are big programs, with a lot of checks and calculations (called "business logic"), so the 1000 global variables is probably a bit on the short side.
Re:"Automated" (Score:4, Insightful)
Let's start with the fundamental awesomeness of Java (over that weak ass C and C++) by listing all the operating systems written completely in Java.
What an incredibly stupid test. First, no operating system is written completely in C either. C is not expressive enough for the low-level initialisation code required by most CPUs, so every modern OS begins with some bootstrapping code written in assembler for the host platform. After the CPU is initialised, you can jump to something in a high-level (i.e. not processor dependent) language. For the record, I can name operating systems written in C, Java, C#, Algol*, Lisp*, Smalltalk, Ocaml, Pascal, and even one that has device drivers written in Python.
* For these languages I can name operating systems for specific platforms which didn't need any assembly code for bootstrapping, but that's slightly cheating because they
WHAT LANGUAGE IS THE JAVA RUNTIME WRITTEN IN?
Java mostly, although this depends on the JRE you use. The first JREs were written by Smalltalk and Self hackers. A lot of Smalltalk VMs were all written in Smalltalk, specifically a subset of Smalltalk that was statically compiled (by a compiler written in Smalltalk), which then ran the rest of the environment.
You watch, some day someone is going to invent a nice Java-like language (we can use pretty much the same syntax as Java) that is compiled instead of interpreted and will create native executables that run on the bare metal, something that can be used to write lightning fast applications, and even be used to write Unix and Windows type operating systems
Ah, I see. You're an idiot who confuses a language with an implementation of a language. There's nothing stopping Java from being compiled; gcj produces static binaries from Java code, for example. Objective-C has all of the dynamic features of Java and is statically compiled. I've written a Smalltalk compiler that contains both a JIT and a static compiler, and can produce native object code from Smalltalk. Common Lisp is also statically compiled, and something like the Steel-Bank Common Lisp compiler has similar performance to g++.
Similarly, it's possible to run C in a VM. Last year's LLVM developer meeting demoed a JIT compiler for C. If you do this then you can run all sorts of run-time profiling and dynamic optimisations (just as you typically do for Java).
Re:Java is for non-hackers (Score:3, Insightful)
I guess it just goes to show that Paul Graham doesn't know very many great programmers. Either that, or his definition of 'great' is screwed up.
Great programmers use the right tool for the job. Whether that tool is Lisp, Python, Java, or even COBOL doesn't matter. The way I see it, Mr. Graham's constant advocacy of Lisp as the be-all and end-all of programming environments is no better than any other language zealotry. Yes, Lisp has its place. So does Java. A truly great programmer would have the task dictate the language, not the other way around.