Slashdot Mirror
IBM Takes System/z To the Cloud With COBOL Update
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."
A stake and garlic? Anyone?
Extended COBOL lifespan?!
THANKS OBAMA! :(
IBM is more expensive, but you can be sure they have more commitment to backwards compatibility than anyone else. If you build on the right IBM technologies, you can be sure your code will be working 30 years from now. No need to rewrite ever few years with the latest fad.
"First they came for the slanderers and i said nothing."
IBM should take to calling it Cloudframe. Because everything needs a cloud based marketing spin.
I only need the Preview button when I haven't used the Preview button.
hook it up to javascript so that the 20 somethings fresh out of college can use it
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.
from much of the code I have seen written in Java, C#, Python, or Perl. Heck, VB was based Basic which drew on COBOL and Fortran, since it was a teaching language and so it had much of the syntax and idioms of those languages. Anytime you use VB your are using a form of COBOL.
BTW if you want to check out something cool, check out Fortran 2008. It supports the OO paradigm, has built in parallel processing support, and is backward compatible to Fortran 77. It's not dying anytime soon either.
putting the 'B' in LGBTQ+
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.
Ironically the utility of fortran has only grown with time. Modern fortrans embrace parallel computing by having constructs that are inherently parallel; for example loops which announce they are parallel and can be done out of order and matrix operations as language primitives. One great innovation is the combination of python and fortran. You do things with precisely defined memory boundaries that are compiled to maximum efficiency using the simple clean fortran, and you do the messy stuff of memory allocations and references and exotic libraries and user interfaces in the python. No need to extend the fortran language and make is slower-- just put the non-speed critical stuff in the python part. With the rise of GPUs and their rigidly defined memory limits fortran is a nice fit. You actually want a constrained language for that. It's really an ideal combination. Fortran compiles so fast its even possible to have python write the fortran on the fly and then call it.
Some drink at the fountain of knowledge. Others just gargle.
Change the acronym, now relevant to OO-fans.
I am now at the middle of my life expectation and growing a bit smarter. And, I talk to a Cobol programmer then and now in the bus home. He works for an insurance company and will probably retire as a Cobol programmer for that company. He is a mathematician and I am a CS guy; I know much more than he about algorithms, C++, templates, macros, databases and whatnot.
But just recently I realized that Map-Reduce and "record-oriented processing" are actually very similar in that they do NOT consume voracious amounts of main memory. Both perform full-table-scans, in database parlance, which has unique advantages over index-based access for many scenarios.
That's all important if your data set is 100 times larger than your main memory. So the mainframers have that capability since 1955 and the C++ guys just discover this in the year 2005 or so ??
Cobol is here to stay for very systematic reasons very few people understand, including those with a CS degree and those developing in Cobol for a very long time. The latter do Cobol simply because it always paid nicely and there is absolutely no end in sight.