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!"
Converting something that was unmaintainable due to lack of proper skils to something totally unmaintainable due to lack of readability is not a good trade off.
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.
Bye!
As though a few hundred cobol coders cried out in terror, and were suddenly obsolete...
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.
putting the 'B' in LGBTQ+
The right tool for the right job. Java is a perfectly acceptable programming language in many circumstances. The key is understanding what it is capable of and what its limitations are.
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.
import system.cool.Sig;
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.
Ha, ha! You misspelled skilz!
-dZ.
Carol vs. Ghost
I hacked into their source code, and found something a little odd:
Table-ized A.I.
"sluggish java"??
.NET.
I've heard this misfound rumor time and again.
Java - when properly written - has been proven to be as fast in file operations, memory access and sequential processing as true "compiled" applications.
The same goes for other JIT languages such as
The Kai's Semi-Updated Website Thingy
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
The JIT code is actually pretty fast. (especially when Hotspot is running in -server mode, which does some impressive optimization)
It just consumes way too much memory, and starts damn slow. (though still faster than C#, in my experience)
A couple times now I've taken base classes and rewritten them in Java to speed them up. ArrayList? Much too slow for my needs, even with a wrapper class ensurance it allocates in large enough chunks. By rewriting it in Java using Object arrays, I saw 60-100% speedups in the get/add methods, translating into roughly a ~2-4% speedup. (mileage may vary depending on workload)
It was about 20000% faster than a default ArrayList - mind you, by default those things allocate in 6-index chunks, so every 6 objects you add it copies the whole ArrayList to a new one, with 6 more spots available. @_@
There's a reason Java got the sluggish reputation, but it's not because the JIT code is slow. It's because the developers can get by with less of an understanding of what goes on behind the scenes, which never turns out good...
He isn't out-of-date. I have to suffer Java 1.6 at my college. The VM is still slow to start, and the GUI libraries still suck.
I propose a fix:
I don't therefore I'm not.
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.
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...
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).
I am TheRaven on Soylent News