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
It does what it was designed to do - mega scale batch processing of flat files - fantastically well. Just because a language doesn't have curly brackets and the latest fad paradigm championed by vory Tower Academics Inc doesn't mean its day has passed.
For the record , no , I'm not a Cobol coder, but I'm old enough to know that when something works well in its sphere of operations its worth holding on to.
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+
Kill it with fire!!!
In Brazil, a Cobol Senior Analist have a average $174k anual. I guess that tech goes more 30 years, yet. IBM have a lot of money for sake Cobol, so why give up? There is no problem when a lot of profit in revenue in legacy technology comes easy, stable, sure, and right. Money, please welcome!!!
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.
... 3, 2, wait, wrong spelling, nevermind.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
COBOL is for real men. I can see how it would scare off all the kids who don't know real computing before that newfangled MS-DOS.
COBOL is for wimps. Real mean write machine code.
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.
Well, men use FORTRAN. Real men are not beancounters, they work on some lethal machinery. Semi-real men like me at least use C++ to do beancounting, which they call "statistics".
Nuke it from orbit. It's the only way to be sure.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
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.
Factoids... "200 Billion lines of COBOL code in existence" eWeek "5 Billion lines of COBOL code added yearly" Bill Ulrich, TSG Inc. "Between 850K and 1.3 Million COBOL developers" IDC "Majority of customer data still on mainframes" Computerworld "Replacement costs $20 Trillion" eWeek Researchers at Aberdeen Group recently found that about 70% of the world's business data is still processed by mainframe applications written in Cobol. According to Gartner Group, that number is closer to 75%. "Although most people are blissfully unaware of CICS, they probably make use of it several times a week, for almost every commercial electronic transaction they make. In the whole scheme of things, CICS is *much* more important the Microsoft Windows." Martin Cambell-Kelly, "From Airline Reservations to Sonic Hedgehog" (a History of the Software Industry), MIT Press 2003 COBAL is not dead and won't die :)
You want a signature? You can't handle a signature!!
I'm aware of two 4GLs that themselves write code in COBOL - so you'd write the code in LDL+, and press a button/turn a handle and it spits out COBOL (and ALGOL, and C I think... who cares). It's rare when us folk used to get down to the COBOL level.
"The greatest lesson in life is to know that even fools are right sometimes" - Winston Churchill
This is good news. After EU insane move to push retirement age in member countries, a well-alive COBOL market will means that some elder will actually be employed. Now we just need to find a solution for all the unlucky that cannot enjoy that.
You can keep your COBOL code closed for modification and OPEN for extension using the cloud services model. Then more recent languages can extend the tested and proven COBOL business layer through web services. COBOL can rest comfortably behind the scenes without one bit of modification save a rare bug fix.
http://landofthefreeish.com/code/the-terminator-was-written-in-cobol/
Cobol in the cloud - Sounds like Skynet to me...
Keuffel and Esser (K+E) have just announced their new electronic, cloud-accessible slide rule. Made of recycled circuit boards and faced with titanium recycled from old Soviet submarines, these babies can do just about anything with at least three-digit accuracy. Give-or-take a power of 10.
System/Z can run Linux, or various web platforms on the several common mainframe OS. you could have all kinds of so-called "cloud" computing on a mainframe with no COBOL in sight
And I just figured out why it's *not* a good idea.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
There isn't anything better than ASCII. If it was good enough for Ovid, Jesus Christ, and Shakespeare it's good enough for the likes of you.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."