IBM Takes System/z To the Cloud With COBOL Update 256
hypnosec writes "IBM is taking its COBOL server platform to the next level by updating the mainframe platform in a bid to extend and enable its mainframes to host cloud based applications and services. The latest update is looking to add XMLS Server as well as Java 7 capabilities to the System/z COBOL platform and this update would extend the overall lifespan of COBOL by taking it up a notch and gearing it towards the cloud computing arena."
And this is why people choose IBM (Score:5, Insightful)
Re:And this is why people choose IBM (Score:5, Insightful)
Agree, never my snarky post higher up in this discussion. The fact is COBOL is proven to scale and does the things its really good at; probably better than anything else. IBM mainframe MVS platforms are probably the best damn environment to run it in to with the longest stretch of forward and backward compatibility to maximize your software development investment. Generally the calls to kill off COBOL come from the ignorant.
Re:What? (Score:5, Insightful)
Are you kidding? There's sixty years worth of legacy applications programs out there in COBOL.
Yeah, it sucks from a Computer Science perspective, but business programming ain't Computer Science.
Have any of the people griping USED COBOL? (Score:5, Insightful)
The 2002 version of the standard added object features. While not my first choice of languages, it is typically not cheaper nor safer to rewrite large amounts of working tested code. Yes, you might do better with a clean sheet of paper and a decade or so, but most IT organizations don't have that luxury.
My favorite COBOL nerdy feature died many versions of the Standard ago (MOVE CORRESPONDING). It was my favorite not because it was a terrific feature, but it was just so unique to COBOL.
Cloud computing is, as a business model, a return to mainframe timesharing services such as dominated in the original COBOL and PL/I eras. It really is not a stretch to see IBM update their zSeries environment to easily enable leveraging the COBOL code base.
Yes, you can (and more cheaply per IBM MIP) run Linux on your zSeries hardware, so you can mix and match (write new applications, or layers in newer environments) ... but there is no need to toss out dull boring functional code that just happens to be business critical.
No doubt the sufficiently intrepid IT staffer could rewrite all the COBOL in Haskell or Perl .. (or for extra credit in REXX) but would it really be an improvement? Indeed, just validating that the new code is logically equivalent to the original code for ALL input sets would be a huge investment ... never underestimate the cost (or importance) of Test and Validation.
Re:Anyone? (Score:3, Insightful)
You really don't know what you're talking about (Score:2, Insightful)
The reason that COBOL was slower than FORTRAN on CDC machines was the result of the superior code generating efficency of the FORTRAN compiler and some fine floating-point hardware.
CDC mainly targeted users who had floating-point compute-intensive applications (the scientific and engineering crowd) and provided a COBOL compiler so that those target users could say to their bean counters "yes, and you can use the hardware, too".
IBM, on the other hand, was targeting business users who had I/O-intensive applications and who really wanted the reliable multiple digit accuracy of integer math, not the "pretty good until you get to 17th decimal digit" accuracy of floating point. So there was high emphasis on COBOL performance and not so much on FORTRAN performance.
Both companies knew their target audiences and spent time and money on compiler optimization where it made the most sense.
Re:Anyone? (Score:5, Insightful)
is that as a not a developer, that was perfectly readable. Is that actually COBOL
Pretty much. Try translating it into any other language and making it readabe. That's something that all of the snarkers will never know about COBOL .. it actually encourages the use of extremely self explanatory variable names and code which is easily readable. File format definitions in COBOL far surpass anything which has happened since (in terms of configuration readability and changability) and printed output can be generated like butter. 88 levels (by definition) make code more readable .. and no other language has ever integrated this concept.
.. there is nothing to replace COBOL.
.. 50 YEARS.
If you have a look at reporting today, there's nothing as capable as COBOL at spitting out reams upon reams of reports. The kind of regulatory reporting required by governments and tax agencies. Trying pushing 30,000 pages out of any modern reporting software and see how far you get. COBOL systems chew up and spit out this kind of work. It's not a question of the cost of upgrading to something better, if you need 20 boxes of paper reports
The haters will hate and there's 2 bazillion idealistic programmers all lined up behind them laughing at COBOL's flaws. If you want it to die, you'll need to replace it first. Because to date, nobody's done that
And BTW: If you want to earn a shedload of cash as a contractor, there's no better language to learn.
Re:Anyone? (Score:4, Insightful)
who the heck wants 20 boxes of paper reports?
Pretty much anyone trying to hide something.