Slashdot Mirror
COBOL Celebrates 50 Years
oranghutan writes "The language used to power most of the world's ATMs, COBOL, is turning 50. It also runs about 75 per cent of the world's business applications, so COBOL should be celebrated for making it to half a century. In cricketing terms, that's a good knock. The author says: 'COBOL's fate was decided during a meeting of the Short Range Committee, the organization responsible for submitting the first version of the language in 1959. The meeting was convened after a meeting at the Pentagon first laid down the guidelines for the language. Half a century later, Micro Focus published research which showed people still use COBOL at least 10 times throughout the course of an average working day in Australia. Only 18 per cent of those surveyed, however, had ever actually heard of COBOL.'"
Though, to be fair, 50 years isn't quite as long as the average cricket game.
We were taught COBOL at college 25 years ago and i'm still a grumpy old git
identification division.
program-id. birthday.
environment division.
data division.
procedure division.
main section.
display "get off my lawn!"
stop run.
If all else fails, immortality can always be assured by spectacular error.
I worked at a company that had a Cobol-based program that went live back in 1969. A team of programmers had kept it going ever since. Shortly after I started (mid 1995), I was in a meeting when one of the Cobol programmers mentioned that so-and-so had died over the weekend. Everybody started talking about her, what a great person she was, etc. After the meeting, I asked who she was, and was told that she was the last surviving member of the original team that wrote and deployed the application. When the system was finally shut down back in 2003 or so (I had long since left, but still had some contacts there to tell me what was going on), I really felt weird about hearing it; here was this thing that had outlived its creators (and some of the later maintainers), and now it was gone too.
Isn't it strange how computer software is both unbelievably ephemeral, yet also incredibly long-lived. I've worked on both sides and I'm not sure which is more fulfilling; it apparently took several years to write the aforementioned Cobol program, but it outlived its creators. I wonder what a programmer on something like, say, Madden, would feel, knowing that this thing they're working so hard on will be totally supplanted by the next version, next year.
Strange business, this computing machinery. Strange indeed.
they will soon exist only in cases where you need very fast access to all of very large data sets.
Which is quite often.
And honestly, clustering filesystems and databases are solving that problem too.
Except that clustering filesystems almost always have to compromise on one of the ACID properties. For example, Amazon's Dynamo and CouchDB are highly available, redundant, and fast, but allow conflicts, assuming the application will correct for them. Ok, but that fails for a banking application -- if I were to withdraw my entire balance from two different nodes simultaneously, I'd have a massive overdraft, but I'd also have the money.
You could imagine trying to shard it instead, but what happens when you transfer money between two shards? You still need a transaction, only now it needs to be synchronized between two nodes. What do you do? Do you lock both nodes at once? Now you've got a possibility of deadlocks.
Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.
Reliability can be defined in several ways. Clusters are more available than a mainframe -- if your mainframe goes down, you're down. But clusters are less consistent than a mainframe, unless you're willing to take such massive hits from synchronization that the performance advantage is gone.
For the vast majority of applications, some inconsistency is acceptable. Take Amazon's example -- if you tell one node to add item A to your cart, and another node to add item B, producing two conflicting versions of your cart, the cart application should be smart enough to merge them. The only synchronization needed is checkout, and here, all you'd need to do is refer to a specific version of that record in the form that's submitted.
But for applications which can't tolerate that inconsistency, unless there's some clustering method I'm unaware of, you're still going to want something like a mainframe.
Don't thank God, thank a doctor!
Stable, reliable, well-understood, and bug-free are true of many more recent languages.
<sarcasm>I didn't know that more modern languages had a 50 year history of reliability, scalability, and security to process transactions 24/7. Live and learn I guess...</sarcasm>
Further, the cost of developing, debugging, and testing the replacement in any language (including redeveloping the system from the ground up in COBOL) is quite expensive, no matter what language you choose. Likely more expensive than the big iron and software environments necessary to run the old code that has worked reliably for the last 20 to 40 years.
Stable, reliable, well-understood, and bug-free are true of many more recent languages.
Yup, JAVA never crashes, C# is easily understood, C++ is free of bloat, and interpreted languages run faster. /s
I dispute that it's the best suited to the purpose for which it's used. Show me a construct in COBOL that wouldn't be much easier in something modern -- even Java, if we have to.
COBOL isn't used because it's easier to write than your JAVA or other new language. It's used because it was designed with business transactions in mind and is reliable. If you have to give up reliability or predictability to gain readability or 'modern-ness' (as has often been my experience with JAVA), it's not a good fit for businesses who can hire additional programmers to produce reliable code.
Regardless, if COBOL works well for the application already, then some modern language would have to one hell of a lot better to rewrite these applications for the incremental improvement to be worth the cost and risk involved with a complete rewrite.
Write your representatives! Repeal the 2nd Law of Thermodynamics!
Jack was a COBOL programmer in the mid to late 1990s. After years of being taken for granted and treated as a technological dinosaur by all the Client/Server programmers and website developers, he was finally getting some respect. He'd become a private consultant specializing in Year 2000 conversions. Several years of this relentless, mind-numbing work had taken its toll on Jack. He began having anxiety dreams about the Year 2000. All he could think about was how he could avoid the year 2000 and all that came with it. He tried getting a job with an Orange County web development firm, but couldn't hack it in the end. Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life. He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "Is it over?" he asked. "Is the year 2000 already here? Are all the millennial parties and promotions and crises all over and done with?" The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. Technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet. "That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in me?" "Well," said the spokesman. "The year 10000 is just around the corner, and it says in your files that you know COBOL".