Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Java Programming IT

Automated Migration From Cobol To Java On Linux 195

Posted by timothy from the so-kids-go-ahead-and-code-in-cobol dept.
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!"
This discussion has been archived. No new comments can be posted.

Automated Migration From Cobol To Java On Linux More

Automated Migration From Cobol To Java On Linux

Comments Filter:

  • "Automated" (Score:3, Insightful)

    by 0100010001010011 ( 652467 ) on Wednesday June 24, 2009 @03:07PM (#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" (Score:5, Insightful)

      by nicolas.kassis ( 875270 ) on Wednesday June 24, 2009 @03:13PM (#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: (Score:2)

        by popo ( 107611 )

        There's something tragically ironic about the spelling error: "skils"

      • Re: (Score:2)

        by stevied ( 169 ) *
        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 p

      • Re: (Score:3, Insightful)

        by Lonewolf666 ( 259450 )

        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.

      • 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: (Score:2)

          by umghhh ( 965931 )
          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: (Score:2)

        by nurb432 ( 527695 )

        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: (Score:2)

        by JamesP ( 688957 )

        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" (Score:4, Insightful)

      by ADRA ( 37398 ) on Wednesday June 24, 2009 @03:14PM (#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" (Score:4, Insightful)

        by plopez ( 54068 ) on Wednesday June 24, 2009 @03:18PM (#28457859) Journal

        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.

        • And they will get what they pay for..

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

        • This was coded in the 80's or 90's, correct? By senior engineers, at that time?

          I'm pretty sure the people that really knew what the code did have long-since retired. ;P

          As Java, it's at least a tad more maintainable. They can hire new coders to map out the functionality, and then eventually create a new version from scratch.

          And in the meantime, it'll run on and take advantage of new servers.

          I don't advocate Java for a lot, but I must say it's one of the best options for webserver craps.

    • Then convert.

      While you are at it, benchmark.

    • The 1990s called... they want their "automated convert Xxxx to Java" idea back.

    • Re: (Score:2)

      by rve ( 4436 )

      Dreamweaver, Word, etc all make some dang ugly HTML.

      So what? HTML is not meant for pleasing the human eye anyway, it's for the browser's HTML rendering engine.

      A modem makes some dang ugly white noise

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

    • Re: (Score:2)

      by popo ( 107611 )

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

      • Re: (Score:3, Interesting)

        by mikael_j ( 106439 )

        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: (Score:2)

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

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

            /Mikael

          • Re: (Score:2)

            by plopez ( 54068 )

            The reason you haven't seen COBOL is that most of it masquerades as JAVA or C# these days. Such are programmers skills (or 5kilz?) these days.

          • Comment removed based on user account deletion

            • Well, with all due respect to wikipedia, in your snippet much of the ugliness is due to (probably intentionally) stupidly named variables. No intelligent developer, of which there are still many in the world, would do anything like naming a variable FOUR-A-C.

              In python: this_var = that_var * 5

              in COBOL: COMPUTE THIS_VAR = THAT_VAR * 5.

              It's verbose, but it's not hugely different, though less feature rich than any modern OOPy language with rich object libs. I work with a bunch of folks for whom COBOL is one o

              • It's also quite straightforward and simple. And it does pretty much exactly what it looks like it does.

                And it doesn't suffer from rounding issues, dropping pennies from a twenty page business ledger due to the inherent issues in representing fractions in binary.

                Disclaimer - I don't actually code in the language, and I will deny knowing about the language if anybody actually tries to force me to program in it.

    • 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 stuf

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

      by realeyes ( 1565211 ) on Wednesday June 24, 2009 @04:05PM (#28458707) Homepage
      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

      • Re: (Score:2)

        by drolli ( 522659 )

        Yes. Automated tools work iff

        a) no external library dependences
        b) programmers stuck to a good style.
        c) the languages are well-suited to be translated into each other (otherwise the code may be unmaintainable)

        and a rewrite of your program every 30 years may save even more future maintainance, because i do not believe that the software will takes the old code *and* split it into classes/sort it to patterns in the same way an (intelligent?) human programmer would. So what you may get is java Code, but very dif

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

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

    • Re: (Score:2, Insightful)

      by Heir Of The Mess ( 939658 )

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

      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: (Score:2)

      by drolli ( 522659 )

      Hey, i based my future plans on learning Cobol and translating it to some of the more modern languges i know.

  • Thank the Lords of Cobol (Score:3, Funny)

    by popo ( 107611 ) on Wednesday June 24, 2009 @03:24PM (#28457961) Homepage

    BSG humor is mandatory whenever Cobol comes up...

  • 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 (Score:5, Insightful)

    by Seakip18 ( 1106315 ) on Wednesday June 24, 2009 @03:42PM (#28458255) Journal

    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: (Score:3, Interesting)

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

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

        by Alpha830RulZ ( 939527 )

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

  • Serious Question Here (Score:5, Interesting)

    by filesiteguy ( 695431 ) <perfectreign@gmail.com> on Wednesday June 24, 2009 @03:47PM (#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: (Score:3, Interesting)

      by Seakip18 ( 1106315 )

      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 i

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

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

    Wont' someone please think of the grey-beards?

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

            They stated clearly they were migrating the people along with it.

            For the post before yours, they stated clearly they were doing this for the money it saves them to move from a mainframe to PC server farms.

            It's not even really an article to read, just a few bullet points.

        rd

  • Hmmmm. (Score:3, Funny)

    by Tablizer ( 95088 ) on Wednesday June 24, 2009 @04:00PM (#28458631) Journal

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

    while (f = getFiles(srcDir)) {
      sendToBangalore(f);
      wait_a_little();
      result = getFromBangalore();
      save(result);
    }

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

  • 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? (Score:3, Interesting)

    by Ungrounded Lightning ( 62228 ) on Wednesday June 24, 2009 @04:08PM (#28458727) Journal

    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.

  • "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?

    • Re: (Score:2)

      by kenh ( 9056 )

      Aside from their paychecks? Why should they get any more than that? Optimizing the environment at all scales $3M/year or $300/year is the job of a good employee. If the people that did this didn't draw a salary but instead asked for a cut of the year-over-year savings then fine, but I suspect they drew a salaey for the conversion.

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

    • Well, to be honest, Pascal and C are similar enough in key respects that translation isn't a big deal. Moving from a procedural language like Cobol to an OOP language like Java is a bit more daunting. Mind you, C++ started out simply as a translater to C with some optimizations, so maybe this problem has been dealt with before.

      • Re: (Score:2)

        by mzs ( 595629 )

        Though it looks from the slides that they did in fact translate line by line and did not use any of the object oriented features of java. That would have been like the opposite of another project I was involved in. I wrote a bunch of python code. later it was deemed that perl was known by more of the devs so I would need to translate that to perl. The python code used classes so I translated that by hand into a subset of python that was very procedural. Then I wrote a python script that translated that into

  • Holy cow, exactly what was the environment they had that cost $3M Euros/year more than the hand full of Linux boxes they replaced it with?

    They could have had a collection of mainframes for $3M Euros, they were vastly under-used if they had that much in savings locked up in that environment.

    Their code matches line for line, so they have the most basic of Java code in place of the COBOL code (it likely looks very similar to COBOL code) I guess.

    As for the transcoding effort, they could also have fired up any

Slashdot Top Deals

As you will see, I told them, in no uncertain terms, to see Figure one. -- Dave "First Strike" Pare

Close