Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Automated Migration From Cobol To Java On Linux

timothy posted more than 4 years ago | from the so-kids-go-ahead-and-code-in-cobol dept.

Java 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!"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered


"Automated" (2, Insightful)

0100010001010011 (652467) | more than 4 years ago | (#28457715)

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" (5, Insightful)

nicolas.kassis (875270) | more than 4 years ago | (#28457799)

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.

Re:"Automated" (-1, Flamebait)

Anonymous Coward | more than 4 years ago | (#28457831)

That, plus the performance hit of Java in the first place... I really wish colleges never started teaching it instead of 'real' languages. Ok, java is a real language, just like basic. Maybe I should have said good languages. Heck, even C# is better than java.

Re:"Automated" (5, Insightful)

hamburgler007 (1420537) | more than 4 years ago | (#28458059)

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.

Re:"Automated" (-1, Flamebait)

Shaiku (1045292) | more than 4 years ago | (#28458069)

Modern extensions of BASIC *are* good languages. Don't know what hole you crawled out of but don't confuse a compiled BASIC with sluggish Java.

Re:"Automated" (3, Informative)

filesiteguy (695431) | more than 4 years ago | (#28458697)

"sluggish java"??

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 .NET.

Re:"Automated" (0, Insightful)

Anonymous Coward | more than 4 years ago | (#28458751)

When java calls native compiled code, it's as fast as native compiled code? Congratulations.

mod parent up! (0, Troll)

spiffmastercow (1001386) | more than 4 years ago | (#28459139)

This is the point java fanboys never seem to get! The library code is fast because its compiled. The JIT code is still damn slow, and the initial load times are horrendous.

Re:mod parent up! (3, Informative)

BikeHelmet (1437881) | more than 4 years ago | (#28459819)

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...

Re:mod parent up! (1)

BikeHelmet (1437881) | more than 4 years ago | (#28459841)

ensuring it allocates in large enough chunks.*

Yet again I have great desire for an edit button!

Re:mod parent up! (0)

Anonymous Coward | more than 4 years ago | (#28459893)

ensuring it allocates in large enough chunks.*

Yet again I have great desire for an edit button!

If only you could find a desire for the Preview button and basic proofreading.

Re:"Automated" (0)

Anonymous Coward | more than 4 years ago | (#28459251)

Thankyou for clarifying my point, I was waiting for someone to catch on :)

java's performance depends heavilly on application (1)

petermgreen (876956) | more than 4 years ago | (#28459839)

I would contend that well written java that has been jited is probablly a bit slower than well written code in a native compiled language but there isn't that much in it and it's hard to compare because the "best" coding methods in the languages are not the same.

However it does have high memory use because of the fact that jited code can't be shared between instances, the large bloat of the standard library, the limited availibility of efficiant data structures (all object types are object references) and the fact that the java garbage collectors don't realease memory back to the OS. This means that if a java app gets swapped out it takes a lot longer to swap back in. It also takes a while to start and get up to full performance, especially if it's the first time a java app has been run this OS session.

In summary on the desktop (where startup and swapin times matter) java is slow, on the server not so much.

Re:"Automated" (3, Interesting)

stevied (169) | more than 4 years ago | (#28458341)

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.)

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 .. 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, ...)

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*

Re:"Automated" (3, Funny)

BenoitRen (998927) | more than 4 years ago | (#28459905)

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.

Re:"Automated" (1)

MightyMartian (840721) | more than 4 years ago | (#28458595)

1998 called and wants it Java complaints back. Seriously though, if I were looking to port over reams of decades-old legacy code, Java would probably be exactly where I'd want to go. Even the performance hit (and it ain't that much nowadays) would be acceptable simply because I'd be moving to portable platform that would allow me to run the software on everything from x86/x64-based supercomputers and clusters right on down to my own workstation. The whole point of such an exercise isn't just to move these apps over to the latest hardware and operating systems, but to move them in such a way as to permit easier porting in the future.

Re:"Automated" (0)

Anonymous Coward | more than 4 years ago | (#28457877)

"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."

I agree, there are a lot of inefficiencies.

Considering the inefficiency of the conversion process coupled with the inefficiency of such old legacy code plus a few other inefficiencies, even for example like java itself, I wonder how many extra servers they need to buy to offset all the combined inefficiencies?

Surely the next time they need to buy more servers, its time to optimize the code to gain the extra performance, rather than the extra costs of more hardware. Maintaining this old code converted to java doesn't sound like fun or cheap development work.

Re:"Automated" (1)

stevied (169) | more than 4 years ago | (#28458481)

The problem is, the alternative with these big, old, crusty legacy systems is to convert them in a "big bang", and it is usually pretty bloody difficult to just to figure out what the existing system is doing and and why. For some reason businesses seem to be quite happy to effectively "encrypt" lots of knowledge about their processes and throw away the key .. doubtless the understanding of the system did at one time exist in the brains of some humans, but they've usually long since moved companies, retired, or even died.

In this situation, a line-by-line transcoding that might (with some in-depth study) be comprehensible by Java coders and yet (with some gnashing of teeth) still by comprehended by COBOL coders, and more importantly be reasonably likely to duplicate the logic of the old system, is probably not a bad stepping stone. Hopefully it's a base from which the system can be converted piecemeal into "proper" Java, and extended.

Re:"Automated" (0)

Anonymous Coward | more than 4 years ago | (#28458557)

Surely the next time they need to buy more servers, its time to optimize the code to gain the extra performance, rather than the extra costs of more hardware. Maintaining this old code converted to java doesn't sound like fun or cheap development work.

Surely you jest -- I can buy a 4 node VMWare cluster including HA storage, software licenses, 128GB total ram, and 32 total cores of CPU processing power for less than it would cost to hire one developer for a year (in the US).

It rarely pays to optimize code unless you're someone like Google who performs the same query billions of times.

Re:"Automated" (1)

Nutria (679911) | more than 4 years ago | (#28459535)

Surely you jest -- I can buy a 4 node VMWare cluster including HA storage, software licenses, 128GB total ram, and 32 total cores of CPU processing power

And run the COBOL code using the MicroFocus or AcuCOBOL compilers.

Re:"Automated" (1)

stevied (169) | more than 4 years ago | (#28458131)

The company that's produced this sounds like they're very keen on XP-ish development. Having a "transcoded" version of the COBOL that can be run on commodity platforms, while certainly not ideal from the viewpoint of maintainability (by people with modern skillsets), is a good first step to gradually converting to / extending with "natively written" Java.

Doing things step-by-step like they have done (and, I imagine, intend to continue to do) is a good way of making sure that they're on the right track and producing stuff that works. Too many "big bang" IT projects turn out to be utter disasters that ultimately have to be canceled, or only succeed years late and many times over budget.

Re:"Automated" (1)

Bill Dog (726542) | more than 4 years ago | (#28458981)

"natively written" Java

Heh, given that the term "compiled" was mutated to be made applicable, I can see this next, natively-written (vs. auto-converted) interpreted code being referred to as "native code"!

Re:"Automated" (2, Insightful)

Lonewolf666 (259450) | more than 4 years ago | (#28458183)

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.

Re:"Automated" (1)

cyber-vandal (148830) | more than 4 years ago | (#28458663)

If there's a lack of proper skills in COBOL then why is no-one advertising for COBOL programmers anymore? I left IT because I found it impossible to get a COBOL job after Y2K.

Re:"Automated" (1)

umghhh (965931) | more than 4 years ago | (#28458763)

If you knew Cobol at this hilarious time then you do not have to work anymore unless of course you were silly enough to work as a salary man instead of consulting for good money.

Re:"Automated" (1)

dkh2 (29130) | more than 4 years ago | (#28459079)

... I left IT because I found it impossible to get a COBOL job after Y2K.

Never fear my friend. We'll need you COBOL geeks again on 19-Jan-2038 when the UNIX system clock rolls over. Hope you're still available then.

Re:"Automated" (1)

Migala77 (1179151) | more than 4 years ago | (#28458897)

Have you read the article? The reason they did this had nothing to do with lack of proper skills; it was to reduce licensing costs by moving to an open source stack. In fact, they deliberately chose to do a 1-to-1 conversion, instead of rebuilding the system:

  - to keep the cobol-developers on-board, who know not just how the software works, but also why it does what it does
  - to prevent the project from becoming a big-bang-lets-fix-everything-project, doomed to fail, and instead stay focused on the savings it should bring
  - to be able to fully automate it, including all tests

I was skeptic when I read the summary, but from the presentation it looks like they handled it very well, and are now in a very good position to continue the improvements they started.

Money (1)

mac1235 (962716) | more than 4 years ago | (#28458971)

3 millions Euros a year can hire some good Java programmers. Hey Strawberryfrog, you doing anything right now?

Re:"Automated" (1)

nurb432 (527695) | more than 4 years ago | (#28459693)

Took the words out of my mouth..

It makes no sense to me to convert from cobol to most anything, especially when cobol is still a viable product from several vendors. Just get your people some training and start digging thru what you have, and clean it up. Cobol isn't that bad/hard once you know how to code in it.

Re:"Automated" (1)

JamesP (688957) | more than 4 years ago | (#28459875)

to something totally unmaintainable due to lack of readability is not a good trade off.

I'm not sure what you meant. But I second it.

(Automatically) converted code is usually _a_huge_mess_. You lose context, (may lose) variable names, general structure of code, the converter doesn't "think java", some things may be converted to overly complicated pieces, etc, etc Also, the original programmers are subject to restrictions that today we don't have.

Think: string operations, db operations, etc

Re:"Automated" (3, Insightful)

ADRA (37398) | more than 4 years ago | (#28457805)

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" (3, Insightful)

plopez (54068) | more than 4 years ago | (#28457859)

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" (0)

Anonymous Coward | more than 4 years ago | (#28458377)

Not really,

      I am 50 years old. If you hired me to maintain code that was originally developed 20 years ago with severe hardware and software limitations possibly also odd regulatory rules the likelihood that I alone could learn them just because I know COBOL compared to a JAVA programmer is not a fair assumption.

If you have silly reasons for doing process 1, 3,4,2 it does not matter if I can write in COBOL or JAVA ... I - or Mr. Java himself - will still have to figure out why you skipped over #2 the first time around ...

    Hiring a new COBOL programmer will require training on the code. You can just as easily teach a Java guy why you do silly things. The difference ?
The java guy will laugh at you while you are standing there . The Cobol guy will laugh at you when you have left the cube farm.

Cheaper Programmers (1)

nurb432 (527695) | more than 4 years ago | (#28459739)

And they will get what they pay for..

I just hope its not my bank that tries to go that route.

Re:"Automated" (0)

Anonymous Coward | more than 4 years ago | (#28458145)

Who will be able to maintain this Java code?
It's still procedural (sorry, I read TFA), only with a Java syntax.
This makes it hard to maintain for both Cobol programmers AND Java programmers.

At the current state of the art, making it object-oriented in a reasonable way is not possible in a fully automated way. I think that's the only real explanation why they kept the generated Java code procedural.

Re:"Automated" (0)

Anonymous Coward | more than 4 years ago | (#28458441)

IMHO, they would have been far better off converting the mainframe Cobol code to Cobol on Linux (e.g. MicroFocus Cobol) or another open platform.
That way, their current programming staff wouldn't need much retraining, the changes would be far simpler (=less migration and testing costs) and they would still have the same benefits from moving to a much cheaper platform.

Re:"Automated" (1)

farmkid (15226) | more than 4 years ago | (#28457979)

My first thought, exactly. But it turns out that human-maintainable code was a high priority.

Re:"Automated" (1)

Nutria (679911) | more than 4 years ago | (#28459651)

But it turns out that human-maintainable code was a high priority.

Then use a Linux COBOL compiler, and convert the code module-by-module to something decent like COBOL-85.

I sense a modest disturbance in the job market... (5, Funny)

fuzzyfuzzyfungus (1223518) | more than 4 years ago | (#28457839)

As though a few hundred cobol coders cried out in terror, and were suddenly obsolete...

Re:I sense a modest disturbance in the job market. (0)

Anonymous Coward | more than 4 years ago | (#28457941)

A few hundred cobol coders???? I had no idea there were that many left!

Re:I sense a modest disturbance in the job market. (0)

Anonymous Coward | more than 4 years ago | (#28459417)

Always 2 there are. --Yoda

Re:I sense a modest disturbance in the job market. (1)

popo (107611) | more than 4 years ago | (#28457981)

Actually that disturbance was all 9 of the world's still-living Cobol coders.

Re:I sense a modest disturbance in the job market. (2, Interesting)

mikael_j (106439) | more than 4 years ago | (#28458507)

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.


Re:I sense a modest disturbance in the job market. (1)

caluml (551744) | more than 4 years ago | (#28459445)

And was it?
I don't even think I've seen any COBOL. Is it more obtuse than Erlang looks?

Re:I sense a modest disturbance in the job market. (1)

mikael_j (106439) | more than 4 years ago | (#28459621)

I'd have to say that I've seen worse languages (x86 asm, I'm looking at you) but it sure wasn't pretty.


Re:I sense a modest disturbance in the job market. (1)

fermion (181285) | more than 4 years ago | (#28458151)

I suspect that someone will still need to fine tune the Java, and that will require an understanding of the original Cobol. Given the undeserved disparaging comments I hear around here on Cobol, Fortran, even C, I suspect the average modern developers feels overwork if they have to deal with anything more complex than Python, not saying anything bad about Python, or, even worse, does not fit into their preferred IDE. I find that if you have a basis in the original computer coding methods, all the new stuff is just a simple walk in the park.

Re:I sense a modest disturbance in the job market. (4, Insightful)

realeyes (1565211) | more than 4 years ago | (#28458707)

Actually, a few hundred cobol coders announced their retirement, and a few dozen PHBs cried out in terror.

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

No change in the job market (1)

VampireByte (447578) | more than 4 years ago | (#28458717)

This looks like a cute toy that will auto-generate some bloated code. No way big iron financial systems are moving to Java, especially auto-generated Java that will perform like crap and be harder to maintain than the COBOL it replaced.

Re:I sense a modest disturbance in the job market. (1)

nurb432 (527695) | more than 4 years ago | (#28459709)

Nope, we do not fear the dark side for we have seen the light. ( of course that light came from a 3270 in a dark basement 20 years ago... )

Automated Migration (-1, Troll)

Anonymous Coward | more than 4 years ago | (#28457857)

Automated Migration from Africa to America!*

*The Fine Print - Lots of Cotton-Picking Will Be Involved. Also, future historians will pretend like only white people had black slaves.

But can it... (0)

Anonymous Coward | more than 4 years ago | (#28457861)

convert Java to COBOL?

Cobol was crap and JAVA is crap; a marriage (1)

fregare (923563) | more than 4 years ago | (#28457905)

What a freakn waste. These code translators never work. Try to change something and good luck. I assume that everything was written perfectly in Coobol and there never was any maintenance correct? Go the land of the past lost -- Coobol and then go to the land of the current lost -- Jaava. Structured programming shiit and object programming shiit. Coobol is a past dinosaur and Jaava is a current dinosaur. Welcome to the LAND OF THE LOST.

Re:Cobol was crap and JAVA is crap; a marriage (0)

Anonymous Coward | more than 4 years ago | (#28458233)

Jaava is a current dinosaur.

<Sarcasm>Yes, because Java is an unsupported language and hasn't made any improvements for performance.</Sarcasm> Java is a viable solution in many situations, but like any tool, it should be evaluated against others for a particular situation.


Maintenance Maintenance Maintenance (1)

Tablizer (95088) | more than 4 years ago | (#28458267)

I generally agree. Perhaps the translated result will "run" at first, but the subject of maintenance cannot be ignored because it's usually the largest cost factor. The generated code is likely to be very verbose and filled with ugly translation artifacts. Machine translators are very literal in their technique to ensure compatibility.

A human translator may use knowledge of the domain or common sense to dump certain idioms or artifacts that are not likely to be necessary any more in the new language. They may take small but rational risks in order to toss some ugly nitty gritty code, for example. Machine translators are not smart enough to evaluate such risks, doing it the long way to "make sure".

One must find a way to read all that machine-generated fluff to make any changes or fixes. This makes maintenance costly and error-prone.

It would be more effective to gradually manually convert one program or module at a time.

Plus, as somebody else pointed out, Java may become a "dead" language also. I've seen about 4 language fad eras in my years in IT. The chance of Java surviving as a non-legacy language is not very big based on past patterns. Thus, one is mostly just converting one legacy language to another.

And Java has some really annoying features that I feel future languages will avoid, including putting type declarations on the left side of statements, keeping C's ugly switch/case syntax, lack of stand-alone functions, and others.

Re:Maintenance Maintenance Maintenance (3, Interesting)

Maxo-Texas (864189) | more than 4 years ago | (#28458419)

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:Maintenance Maintenance Maintenance (1)

Tablizer (95088) | more than 4 years ago | (#28458537)

I wrote an RPG3 to RPG4 converter back in 2000.

What, did IBM pull a VB6 and make RPG3 code non-migratable to 4?

Re:Maintenance Maintenance Maintenance (1)

Maxo-Texas (864189) | more than 4 years ago | (#28459175)

Sort of.

There was a free converter that converted RPGIII to RPGIV if you wanted to have "Rpg3 in Rpg4 format".

But if you wanted improved error handling, files as objects, support for external calls to java, embedded SQL, better transaction control boundaries, you needed to do a more complete conversion.

Re:Maintenance Maintenance Maintenance (1)

VGPowerlord (621254) | more than 4 years ago | (#28459991)

So, in other words... you leveled up your RPG using custom hacks?

I don't know why, but companies like Blizzard hate that!

Well, convert it, first. (0)

Anonymous Coward | more than 4 years ago | (#28457999)

"we could convert of our own application (4 million lines of code) through the tools that we developed"

Well, convert it, first.

Sign of the times (0)

Anonymous Coward | more than 4 years ago | (#28458005)

Replace something that has a proven track record with something that is a fad.

Whoever the project lead is on this must have supreme bullshitting skills; to be able to convince an entity that has the cash for an IBM/compiled program route to switch to an OSS/interpreted program route.

I can't imagine Linux and Java lasting nearly as long as IBM and COBOL.

Re:Sign of the times (2, Interesting)

umghhh (965931) | more than 4 years ago | (#28458223)

If you are right there may be a cascade of converters to run and lucrative converters market full of consultants. If things go really ugly the more conversions are done more skills will be needed to find out why converted code malfunctions. These skills could possibly even include cobol just in case one has to look at original to find out ow did it work when it did:)

Re:Sign of the times (1)

iluvcapra (782887) | more than 4 years ago | (#28459753)

An AC writing like an old codger. I think I bought my first Java book in 1995... By this standard of "fad," C was a fad when Windows NT came out.


Anonymous Coward | more than 4 years ago | (#28458139)

I didn't see any references to ALTER statements

I looks like this only supports more recent versions of COBOL II.

What do transcoders really buy you? (2, Insightful)

davidwr (791652) | more than 4 years ago | (#28458177)

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.

Per slide 25 (4, Insightful)

Seakip18 (1106315) | more than 4 years ago | (#28458255)

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:Per slide 25 (2, Interesting)

phantomfive (622387) | more than 4 years ago | (#28459815)

That would probably be scary, except the original code was like (from slide 26):


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.

The King is Dead! Long live the King! (0)

Anonymous Coward | more than 4 years ago | (#28458357)

What? Someone had to say it.

Serious Question Here (4, Interesting)

filesiteguy (695431) | more than 4 years ago | (#28458367)

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:Serious Question Here (2, Interesting)

Seakip18 (1106315) | more than 4 years ago | (#28458687)

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.

Re:Serious Question Here (0)

Anonymous Coward | more than 4 years ago | (#28459341)

There I modded you troll you dumb bitch. Keep doing the karma martyrdom, and I will keep modding you down.

Inline documentation? (1)

Rix (54095) | more than 4 years ago | (#28458387)

What happens to the commenting? Won't this turn into an unreadable turd?

Re:Inline documentation? (1)

rockNme2349 (1414329) | more than 4 years ago | (#28458529)

The fools, if only they had figured out a way to translate the COBOL comments into Java comments. WHEN WILL THEY LEARN?

Re:Inline documentation? (0)

Anonymous Coward | more than 4 years ago | (#28459033)

The fools, if only they had figured out a way to translate the COBOL comments into Java comments. WHEN WILL THEY LEARN?

I think the point is the positioning (location) and meaning (semantics) of the comments DON'T translate

What about the grey-beards? (1)

MBCook (132727) | more than 4 years ago | (#28458391)

But now what will the poor grey-beards do for a living?

Wont' someone please think of the grey-beards?

The greybeards will be... (0)

Anonymous Coward | more than 4 years ago | (#28458969)

...conducting your next annual performance review, beyotch!

Scary Thot (0)

Anonymous Coward | more than 4 years ago | (#28458429)

Oh oh, I envision something like:

  ArithmeticManager am = new math.ArithmeticManager();
  opA = new math.Operand((float) a);
  opB = new math.Operand((float) b);
  am.operator = new math.operators.Addition();

Not sure that's a step up.

Re:Scary Thot (2, Funny)

larry bagina (561269) | more than 4 years ago | (#28458889)

CobolEngine cobol = new CobolEngine();

cobol.AddLine("ADD A TO B GIVING RESULT");
cobol.AddLine("PRINT RESULT.");


Re:Scary Thot (1)

VGPowerlord (621254) | more than 4 years ago | (#28459941)

I know you were joking, but have you used Java's decimal library before?

BigDecimal opA = new BigDecimal(a);
BigDecimal opB = new BigDecimal(b);
BigDecimal result = opA.add(opB);

Not quite as bad as your fake code, but the difference is... BigDecimal [sun.com] is actually a real class that exists in the Java standard library.

The same code in C#:

decimal result = a + b;

(provided you don't overflow the decimal value)

Been there, done that. (0)

Anonymous Coward | more than 4 years ago | (#28458439)

Back around 1997 I worked for a company that did much the same thing: used automated tools to convert gigantic COBOL programs into something that would run on distributed UNIX boxes. (We used ANSI-C as the target language. [Except that JCL was translated to Perl.]) We charged millions of dollars, but it was worth it to our customers. For example, one big utility company had merged with the utilities of a neighboring state, and their mainframe simply wasn't big enough to hold the combined customer data.

The final code was damn ugly, because it was a close translation of the original Cobol. And Cobol control flow has some concepts not easily reproduced in C, so some of the library functions we wrote to handle those were quite bizarre. You'd have a hell of a time adding new functionality in "clean" C, but programmers familiar with Cobol could maintain it.

It was never fully automated (we'd get the contract, then finish customizing the tools to work with whatever flavor of Cobol the particular customer had), but we'd finish a typical engagement in less than a year.

Hmmmm. (3, Funny)

Tablizer (95088) | more than 4 years ago | (#28458631)

I hacked into their source code, and found something a little odd:

while (f = getFiles(srcDir)) {
  result = getFromBangalore();

Not so fast (1)

scorp1us (235526) | more than 4 years ago | (#28458691)

This will just carry forward and old bugs and give them life a new in a new executing environment, where no one knows what will happen. Seems like makings for several DailyWTFs to me...

They're all going to be consultants (1)

gr8_phk (621180) | more than 4 years ago | (#28458725)

we believe that we succeeded in our project because we clearly demonstrated very early on to the people in place that they would find a new interesting job in the final constellation. That generated their full commitment to the project!

Every person involved can now go out and be a consultant to other companies that want to migrate off their old Cobol codebase.

Is it certified as a conforming COBOL compiler? (2, Interesting)

Ungrounded Lightning (62228) | more than 4 years ago | (#28458727)

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.

I have automatic translation to machine code (1)

obarel (670863) | more than 4 years ago | (#28458803)

Now I just have to train my staff to read and write machine code, and it's bye bye COBOL forever!

OpenCOBOL on Linux (1, Informative)

Anonymous Coward | more than 4 years ago | (#28458907)

Cobol apps from mainframes easily runs on Linux when you just simply recompile using the free, open source, GPL'ed OpenCobol [opencobol.org] compiler. I've moved a bunch of old IBM mainframe cobol stuff to Linux with OpenCOBOL and so far, I've run into very few issues, none of which weren't solvable with a minimal amount of code changes.

OpenCOBOL also works great if you have any Oracle Cobol apps (that used the Oracle Pro*Cobol precompiler). I'm in the middle of moving a bunch of Cobol-on-Oracle stuff from an old RS/6000 AIX box to 64-bit Linux right now. I'm using Oracle's free "Oracle Enterprise Linux" which is basically a repackaged RHEL distro, and you can even buy formal support contract from Oracle for OEL. So far everything is working out great. The commodity hardware (HP Proliant DL580) server costs a mere fraction of what a new AIX box of comparable power would've cost, and I'm also benefiting from Oracle's free Virtual Server stuff (Xen-based) so I've got the functional equivalent of IBM's LPAR virtual machine technology going on commodity hardware with 10 times the speed, and 1/10th the hardware cost.

COBOL Does Not Support F/OSS, Java Does (0)

Anonymous Coward | more than 4 years ago | (#28459061)

There are no good open-source COBOL compilers. The GCC COBOL project is dead. TinyCOBOL is very incomplete. Then, the one I like, OpenCOBOL simply transcodes COBOL-85 to C and then compiles the C-code.

The COBOL, i.e. Business, community does not support F/OSS compilers. There is a great deal of money involved in hardware/COBOL systems still.

The main article describes a migration from an IBM/zOS mainframe running COBOL to Linux on Intel hardware. There is no professional-grade COBOL available for Linux so that they must convert to another language. They chose to transcode COBOL into Java.

I don't see anything bad about COBOL, or good about Java here. The issue is closed-standards, and the cost savings of cheaper hardware.

Programmer's Cut (1)

Nom du Keyboard (633989) | more than 4 years ago | (#28459725)

"We save 3 millions euros / year after this migration!"

And what cut of this savings have your given your programmers who have made it all possible?

We did this with a bunch of pascal code (1)

mzs (595629) | more than 4 years ago | (#28459769)

We used p2c to migrate a bunch of pascal code to C many years ago. It was not perfect, but not that bad. You got pretty good at figuring-out the likely places that screwed-up. Also save for the with statements in pascal being translated to accesses to structures, it made relatively readable C.

AnonymousCoward (0)

Anonymous Coward | more than 4 years ago | (#28459973)

I can't think of a way to automate a procedural thingie to a OO thing.

i work in a place where Cobol developers were sne t to a fast "java school", came 3 weeks after and were supposed to write java. Sure they did. It was procedural Java. And theri programs requested huge CPU load to work.
In the end, one year after, all the code the had written was erased, the app completely re-thought.

Same thing here : for a time it's good, the app is working.
But it will not only need a smart " multi-pass pretty-formatter". The app will require proper OO conception FIRST, and the sooner the cheaper.

The 3M$ are a short sighted benefit.
In the long run _provided the application si supposed to continue to live_ (to be exact : if the needs it covers still exists and cannot be done elsewhere), it will reveal more expensive.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account