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! :(
NOOOOOOOOO!!!!! :-(
Can't we just let COBOL die with dignity? It's lived a vibrant, fruitful life. It's time to let go. It's time for COBOL to go to the great nulll device in the sky... and not the "cloud", please. The "cloud"? Seriously? It's time to move on... for everybody's sake.
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
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.
The term is "loop reordering". Essentially, you can iterate matrices row-wise or column-wise. If your matrix is stored row-wise, you better iterate it row-wise, or your cache locality will be very bad. Typical use case is matrix multiplication and solving linear equation systems. So that Mr Kuck of the uni of Illinois (now at Intel, still working !) created optimizing compilers which can do impressive things, including estimating how long a typical Fortran program run will take (surely that does not work for all categories of Fortran programs). In addition to that Mr Kuck developed compilers which would automatically exploit parallelism of "vector" hardware like the machines designed by Seymour Cray. Note that there is no need to explicitly say "parallelize this loop" as you need to do with OpenMP; the compiler can figure that itself ! Again, this proves that new != better. Fortran still beats C++ in numerical processing and that is quite interesting, considering the fact that Fortran is one of the very first programming languages ! Google Mr Kuck and his papers regarding Fortran compilers - it's an impressive part of computer science from the CDC6600 to the present day !
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.
You must still be in diapers.
It's really quite a simple choice: Life, Death, or Los Angeles.
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.
Nuke it from orbit. It's the only way to be sure.
You sure about that? I hate to be the one to break this to you, but the people using COBOL are the same people who pay insane amounts of money for a backup site thousands of miles away and offsite backups in nuke-proof shelters. If you want to get rid of COBOL, make something better. A nuke certainly won't do it.