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."
Anyone? (Score:5, Funny)
A stake and garlic? Anyone?
Re:Anyone? (Score:5, Funny)
mmmm, steak and garlic. Oh, wait...
Re: (Score:2)
Clearly COBOL will never die. As I recall, the civilization of Battelstar Galactica [wikipedia.org] had an entire religion devoted to the "Lords of COBOL [wikipedia.org]." Not just the colonists, but I'm pretty sure I saw in one of the deleted scenes an older-model Cylon Raider trailing punch cards from a hull breach.
Re:Anyone? (Score:5, Funny)
PERFORM 3 TIMES
DISPLAY "Die!" WITH NO ADVANCING
END-PERFORM.
STOP RUN.
The enhanced utility of Fortran (Score:4, Informative)
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.
Not Entirely Correct (Score:2)
Re: (Score:2)
One great innovation is the combination of python and fortran.
Huge agreement here!
I advocated the same Ruby/Fortran synergy back in 2006, with a working example:
http://marc.info/?l=ruby-talk&m=115619337609191&w=2 [marc.info]
Completely agree that this is a great way to use the best tool for the job. I'd go so far as to claim that Python(or Ruby)-with-Fortran is a better tool for most jobs than C#-for-everything, which is kinda mediocre at all tasks..
Re: (Score:3, Insightful)
Re:Anyone? (Score:5, Interesting)
I hate to admit knowing this, but modern COBOL lets you omit most of that. Depending on the exact compiler used, you might be able to omit all the boilerplate. But even stricter ones let you keep it to 3 or 5 lines, something in that ballpark. Not really less boilerplate than most compiled languages.
That said though, it was a snippet not a program so nothing was forgotten or omitted.
Re:Anyone? (Score:5, Interesting)
Re: (Score:2)
Fresh out of college my first job was as a C0807[1] programmer. About the only thing I remember (apart from what an utterly horrid language it was) was that, according to the (c) message the compiler printed before the inevitable ten dozen syntax errors, it was older than me.
Some of the micro guys used these Fisher-Price variants you speak of. Still, unless they're so different as to be effectively something else, I can't think of anything less suitable for graphics.
[1] I will not utter it here.
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: (Score:2)
OK, but... who the heck wants 20 boxes of paper reports?
Re:Anyone? (Score:4, Insightful)
who the heck wants 20 boxes of paper reports?
Pretty much anyone trying to hide something.
Re: (Score:2)
A few off the top of my head; car registration and renewal notices, bank statements, credit card statements, paper checks for people who don't like direct deposit. Pretty much any organization with thousands or millions of customers (mostly banks, insurance companies, governments, etc.)
Re: (Score:3)
"next" is less explanatory that something like "endfor".
That "i" variable goes unused.
You have to know what that comma means, and actually I think you should have written print "Die!";
Re: (Score:3)
Re: (Score:2)
Re: (Score:2, Funny)
What's hilarious, is that as a not a developer, that was perfectly readable. Is that actually COBOL?
COBOL was designed so that PHB's could look at the code and imagine that they understood what the program did.
God help us all.
We can... (Score:2)
Nuke it from orbit. It's the only way to be sure.
Re: (Score:3)
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.
Re: (Score:2)
Elizabeth Taylor's phone number was BUtterfield 8.
The IRS can be reached at VAmpire 9-1040
Re: (Score:2)
I'd have thought that, with a name like that, anti-zombie techniques would be more effective. Let's be careful with which type of undead we are killing here!
Re:Anyone? (Score:5, Funny)
COBOL on the other hand has well designed base of apps that have stood the test of time and still process the most important financial transactions
Not to mention a mean developer age of 73...
Re:Anyone? (Score:4, Funny)
Not to mention a mean developer age of 73...
Get off of my lawn, sonny. If it was good enough for Grace Hopper, it's good enough for me. BTW, do you want to get paid next month, or should I put a bug fix into that code I wrote 40 years ago?
Re:Anyone? (Score:5, Funny)
Not to mention a mean developer age of 73...
Get off of my lawn, sonny. If it was good enough for Grace Hopper, it's good enough for me. BTW, do you want to get paid next month, or should I put a bug fix into that code I wrote 40 years ago?
I thought "mean" referred to the arithmetic average, rather than personality...
Re: (Score:2)
In my company I'd be very surprised if the mean age of the COBOL developers is over 35. But yes, of course, I work in a bank.
Re: (Score:2)
Re: (Score:2)
Not to mention a mean developer age of 73...
And this is the problem with misunderstanding statistics. If you take the more informative median developer age, you'll see it's closer to 80.
Ugh (Score:5, Funny)
Extended COBOL lifespan?!
THANKS OBAMA! :(
Re:Ugh (Score:5, Funny)
Never a death panel when you need one.
Re:Ugh (Score:5, Funny)
The damned thing's immortal.
IBM has found the secret to everlasting life!
Surely, there is some money to be made here?
Re:Ugh (Score:4)
The damned thing's immortal.
IBM has found the secret to everlasting life!
Surely, there is some money to be made here?
Old COBOL programmers made a fortune with the year 2000 problem.
The exact same ones will make a fortune with the year 10000 problem. So, yeah, there must be some secret to everlasting life in all that COBOL stuff somewhere . . .
Re:Ugh (Score:5, Interesting)
The damned thing's immortal.
And C is so much different? COBOL may be 54 years old, but C is not exactly a kid at 44. Sure we've had updated versions and C++, but so has COBOL (COBOL 2002 is OO). BTW, I've loved C since I first started using it, and I'm not sure I'd even recognize COBOL if it fell on me (not just a figure of speech if you're using big card decks), but just saying.
Old programming languages never die (at least once entrenched), but this zombie effect wasn't appreciated when COBOL was first spec'd, because HLL's hadn't been around long enough. The fact that in 1959 COBOL was supposed to be just the first of three successive language definitions is instructive. From Wikipedia:
it was decided to set up three committees: short, intermediate and long range (the last one was never actually formed). It was the Short Range Committee, chaired by Joseph Wegstein of the US National Bureau of Standards, that during the following months created a description of the first version of COBOL. The committee was formed to recommend a short range approach to a common business language. The committee was made up of members representing six computer manufacturers and three government agencies. ... The intermediate-range committee was formed but never became operational. In the end a sub-committee of the Short Range Committee developed the specifications of the COBOL language.
Re: (Score:3)
The damned thing's immortal.
IBM has found the secret to everlasting life!
Surely, there is some money to be made here?
Have you seen how much a maintenance contract on a Z-Series runs?
Re: (Score:3)
Have you seen how much a maintenance contract (aka Health Insurance) on YOU runs?
At the rate we're going in the US, they can afford to put your Z-series hardware on your health insurance premium as an inexpensive rider.
Re: (Score:2)
You prefer that everybody in this industry earns a precarious income and operates dirt-cheap stuff ? No high-end equipment whatsoever ? Yeah, that makes sense if you earn about as much as a McDonalds worker. Unfortunately, I do think your wish will come true. Regarding IBM mainframes, they are worth their money and if you cannot see the difference to the cheap x86 stuff from Dell, that's your fault. Finally, every skilled factory worker stands in front of 500k Euros/dollars worth of hardware these days. You prefer that 10k$ Dell "server" ??
I never said that the Z series wasn't worth the money, just that that they are expensive.
What? (Score:3)
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.
if it aint broke (Score:4, Funny)
hook it up to javascript so that the 20 somethings fresh out of college can use it
Re: (Score:2)
It's lived a vibrant, fruitful life.
Well now it'll live another one! Like the sporocarp of a fungus growing on a bag of rotting garbage.
Truly, there can be no greater evil than COBOL and enterprise Java in the same bucket, united by an unholy sludge of XML.
Re: (Score:2)
COBOL and enterprise Java in the same bucket..........Biology questions?...Car and computer analogies available for most concepts!
How is it that a biologist has such a strong opinion on COBOL Java and XML in an enterprise environment?
Re: (Score:2)
You have no idea how many biologist you can find, working with COBOL Java and XML, because they were are very few jobs in Biology, and a lot more in Computer Engineering.
Re: (Score:2)
Re: (Score:2)
biology does involve a lot of Java and XML.
That is fascinating.
Re: (Score:2)
Re: (Score:2)
If we just run with it and add a few more languages, we can bridge this thing into the next millennium.
Re: (Score:3)
It's lived a vibrant, fruitful life.
Well now it'll live another one! Like the sporocarp of a fungus growing on a bag of rotting garbage.
Truly, there can be no greater evil than COBOL and enterprise Java in the same bucket, united by an unholy sludge of XML.
If it ties to a cluster of back-end Oracle databases servicing SAP you could be right. Satan himself probably wouldn't touch that much evil.
Re: (Score:2)
I've heard there are disgusting perverts on the internet, but I never believed it until I saw this post. To even think of such foulness you must be deeply disturbed.
Re: (Score:2)
Re: (Score:2)
COBOL is a great language for it's specific domain. There's a special Hell waiting for PHBs who mandate C/C++ and Java for record-oriented business applications.
Re: (Score:2)
I think that's sort of the appeal of combining COBOL and Java in one server product. Now, PHBs can use Java for record-oriented applications and COBOL for everything else. Prior to that, they'd have to pick one or the other.
How does COBOL stack up against classic VB for record handling? Or older BASICs for that matter? The BASIC family is generally held to be pretty good in that department.
Re: (Score:2)
I think that's sort of the appeal of combining COBOL and Java in one server product. Now, PHBs can use Java for record-oriented applications and COBOL for everything else. Prior to that, they'd have to pick one or the other.
How does COBOL stack up against classic VB for record handling? Or older BASICs for that matter? The BASIC family is generally held to be pretty good in that department.
Having fought mainframe-style records in DB/2 in Java, what I wonder is how they are managing the fundamental data format issues.
COBOL didn't support variable-length strings for ages. The optimal record in COBOL consisted of fixed-length fields.
Java, on the other hand, can only support fixed-length character strings (semi-)properly when they are done as character arrays, and they didn't spend excessive amounts of time making character-array manipulation as easy as fixed-length string handling is in COBOL.
DB
Re: (Score:2)
Actually, the Currency datatype provides a fixed decimal. It was removed in VB.NET for no clear reason, but provided a 64-bit value with a constant 4 base 10 digits in the fraction.
And I believe the official abbreviation is "PL/I". :)
Re: (Score:2)
Re: (Score:2)
You know I never understood the hate for COBOL
In 1984 it was:
1) Comp Sci snobbery.
2) Horrible textbooks.
The painful contortions that Shelly & Cashman twisted COBOL-74 into so as to be GOTO-less meant that no one liked the language.
It was only when I got a Real Job in the Real World that I appreciated the power of COBOL.
Re: (Score:2)
Re: (Score:3)
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.
Re: (Score:3)
Structured programming and objects are afterthoughts. Arbitrary data structures likewise.
No first-class functions. No lambdas.
Not that your typical business report program has any use for those things.
Re: (Score:3)
Not that your typical business report program has any use for those things.
Exactly.
It's also one of the many reasons you get such incredible performance out of COBOL.
Adding objects was a stupid marketing-driven mistake.
Re: (Score:3)
In the hands of a capable professional, objects can be at least as efficient as structures+procedures
That makes my point, doesn't it? To say that, under the best of circumstances, objects can sometimes be as efficient isn't much of a defense. (Let's not forget that you often trade far more than just performance for objects.)
No reasonable person would dispute the claim that objects have no business in code where performance is essential. I suspect that you'd agree with me here. That it's absurd to add objects to a language for no reason other than OO was the hot buzzword at the time (clearly ignoring al
Re: (Score:3)
Structured programming ... are afterthoughts.
You haven't actually written production COBOL, have you?
No first-class functions. No lambdas.
Not that your typical business report program has any use for those things.
Exactly. COBOL and FORTRAN were targeted domain-specific languages before the term was invented, and the targets weren't Edsger Dykstra.
Re: (Score:2)
Why? (Score:2)
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.
Re: (Score:2)
vory[sic] Tower Academics Inc
Ah, it's chip-on-the-shoulder time again!
I like how, with your use of inc there even manage to blame most of the corporate driven computer language fads on "Ivory Tower Academics".
Well done.
Very Disingenious (Score:3, Interesting)
But just recently I realized that Map-Reduce and "record-oriented processing" are actually very similar in that they do NOT consume voracious am
Re: (Score:2)
So the mainframers have that capability since 1955 and the C++ guys just discover this in the year 2005 or so ??
Not sure I follow. The C++ library I/O model has been around since the beginning. It's always been a stream based model, not a "load the whole file and then process it" model. It's basically an improvement over the similar but (for no good reason[1]) less flexible C stdio model.
The latter, coming from C, was designed specifically by people who liked pipes: the model has always been good for troggi
Re: (Score:2)
Re: (Score:2)
The cloud is just the 21st century rehashing mainframe concepts so why not use COBOL for it?
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: (Score:2)
However I disagree that COBOL scales cheaply or efficiently. You could practically build a datacenter for the price of IBM's mainframes.
Re: (Score:2)
However I disagree that COBOL scales cheaply or efficiently. You could practically build a datacenter for the price of IBM's mainframes.
True...assuming you don't already have an IBM mainframe.
Re: (Score:2)
Hogwash! COBOL only worked well on mainframes that had instruction sets that were designed for it. As an example of COBOL on a machine that was NOT designed for it I offer up the following. I learned COBOL on a Control Data Cyber 170-730 (yes, a successor to Seymour Cray's CDC 6000-series beasts from the 1960's). COBOL on this poor man's supercomputer was a dog and slow. But the university administration used this machine for many years and its database support was more than adequate for their needs.
No
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 applic
Re: (Score:2)
COBOL is similar to assembler because it lacks native block structure and recursion.
Which isn't that similar.
I've used recursion in assembler code plenty of times, not sure what you mean here.
Re: (Score:2)
Re: (Score:2)
Bull. You can't be sure your code will work next week, IBM or not. You think the IBM websphere code I'm working on now is guaranteed in 30 years time to work? Never.
Re: (Score:2)
But compare that to Apple's system, where absolutely no software compiled before 2005 will run on the current OSX.
Re: And this is why people choose IBM (Score:2)
Huh? The only thing that changed was what happened when an invalid sign digit was detected. In both cases a program check - data exception was raised, and the instruction counter in the old program psw pointed to the next sequential instruction. The difference was that in 360 the operation was terminated, and ln 370 it was suppressed. Terminated meant the state of the output operand and condition code were unpredictable. Supressed meant that the operand and condition code were the same as they were wh
Re: (Score:2)
Which is why perfectly fine programs for the 360 crashed on the 370, because the ZAP instruction's semantics had changed?
I.e., in S/370, invalid signs in decimal numbers suppressed, rather than terminating, the operation [uni-stuttgart.de]? (A change not unique to ZAP.)
Rebranding (Score:4, Funny)
IBM should take to calling it Cloudframe. Because everything needs a cloud based marketing spin.
Re: (Score:2)
Oooooh! Better register that trademark! Cloudframe. That even sounds like an IBM type of market speak.
Re: (Score:2)
You are lagging a little behind our market speak.
It would be CloudFlex or PureFrame.
Re: (Score:2)
Don't you mean CloudFlxr, or pyUrFramely?
COBOL code is not too different (Score:5, Interesting)
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.
Re:COBOL code is not too different (Score:5, Funny)
Anytime you use VB your are using a form of COBOL.
Anytime you use Visual Basic, you are incrementing the counter keeping track of exactly which Circle of Hell you'll eventually be deposited into.
Re: (Score:2)
Re: (Score:2)
Or a Series 4000 mechanoid.
Re: (Score:2)
The OO paradigm has been supported since Fortran 90, albeit somewhat primitively. Dying? I finished writing my latest Fortran program last week!
Concerning backwards compatibility though, there are some features of Fortran 77 that have been deleted in the latest versions. Not anything that anyone will (or should, for that matter) miss, since I am talking about very archaic features here. I am sure that compilers will still support them though.
Also, kudos to the gfortran people for the good work on the compil
Re: (Score:2)
but try replacing a Fortran job once you lose it.
A good programmer can write Fortran code in any language.
Re: (Score:2)
Basically what I mean is that the use of OO is primitive in the code I was speaking of. The code monkey was writing code which could have been done, sometimes better, using COBOL. The flexibility and extensibility of an OO paradigm was lost to the programmer.
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: (Score:2)
Dang that brings back memories. MPEX was the 3rd or 4th OS I learned. That was back in the early 80s. But the IBM OS's even now have their roots back into at least the 70s, and it's still applicable now.
I learned COBOL back in the 70s as the second language I learned, after BASIC. If I wanted to, I could probably still get a decent job doing COBOL now, I would think. Some things don't change enough for it to matter. But I wouldn't want to do COBOL. I always considered it boring after learning assembler.
COBOL: Cloud Oriented Business Objective Language? (Score:4, Funny)
4GLs - language of choice, sometimes (Score:2)
Support COBOL for our elder's jobs (Score:2)
Re: (Score:2)
I agree, Java / EE is just warmed over c++ and makes for the most bloated set of pigware known to man.
Let's not weigh the mature base of COBOL apps that is moving our money and processing our insurance claims with that rubbish
Re: (Score:2)
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. [dilbert.com]
Re: (Score:2)
You must still be in diapers.