Slashdot Mirror
COBOL Will Outlive Us All
jfruh writes "Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works. The truth behind that is the reason that so much decades-old COBOL code is out there still driving crucial applications at banks and other huge companies. Many attempts to replace COBOL applications flopped in the 1980s and '90s, and we're stuck with them for the foreseeable future — but the Baby Boomers who wrote all that code are now retiring en masse."
Well... that and the fact that COBOL is actually very good at what it was made to do; batch file processing.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
Writing COBOL is not just easy, it's fun! It takes about a fortnight to work through the manual and become fluent. It uses very English like syntax. It's much easier than FORTRAN or C as it's so small! Lets face it in this world of UNIX massively parallel cloud social web computing, this is hardly a complex problem to solve – it's already been done by the folks that wrote COBOL. A simple database! So get that manual out, and have a try!
The purpose of existence is to make money.
Yup. I was hired into one of those mainframe companies that worked with COBOL and JCL. The work was the most menial of works I had ever done(after they trained me for 6 months in it).
The financial sector, the lumbering dinosaur that accepts change only when they have no other option, and the ones maintaining decades-old mainframes really have no incentive to change technologies at the moment. It's easier to just outsource the maintenance and servicing of the mainframes. There are enough of coders (like in the company I joined) in developing countries across the world who would gladly take it up.
From my experience, there is little development happening any more. I think the day when they run out of people who want to this crappy menial job (which is never) is the day COBOL will go extinct.
All of this has happened before and will happen again...
why bother paying tons of money developing new software, going through the painful growth and ironing out all the bugs of the new software, educating people on the new software, importing your current clients into new software, getting modern hardware to run the new software, installing modern networking equpment for the new hardware to run the new software, etc.. theres just no real reason to upgrade the software. There won't be many new exploits for COBOL based software as well, since its not used by the average person.
http://interserver.net/
http://en.wikipedia.org/wiki/COBOL
Why is Snark Required?
Every 3 to 5 years this topic comes up. It's almost like some new batch of CompSci graduates start to evaluate the state of the industry, and share their "discoveries" with the world. Except it is the same old discoveries couched in modern terms.
Viewed through the eyes of a modern programmer, COBOL is indeed a joke. A horrible one. It violates nearly every single principle of good language design in what appears to be a misguided attempt to make programming "friendly." A CS undergrad would get a poor grade turning in something like COBOL as a Programming Languages 101 project.
But for a language first specified in 1959 (when computing didn't even have the Integrated Circuit yet), it's a work of staggering genius; they didn't HAVE all those rules of good language design to fall back on! At the time, FORTRAN had been out for all of two years and LISP for one; hardly enough time to have much experience with knowing what not to do, and neither of those languages targeted the same problem domain.
COBOL made modern computing accessible and useful to businesses. It's programs have maintained decent backwards compatibility for about half a century. And for all it's foibles, all those hundreds of millions of lines of COBOL actually work. They may be a disgusting kludge, a result of decades of compromises, but these gigantic black boxes of spaghetti Work. And there's no reason to think they'll stop doing so any time soon. Nor any reason to believe that replacing them would be in any way cost-effective.
Does anybody know what language(s) are used for the "Dead Hand" second-strike control system that the Russians were working on during the Cold War? Personally, I'd nominate them as the programming languages that will outlive us all...
It is a bromide perpetrated by ITAA and business groups that we can't find enough programmers to replace the ones who are retiring.
The simple truth is that no one wants to PAY what people are worth, and there is rampant age discrimination:
http://www.itbusinessedge.com/cm/blogs/tennant/yes-age-discrimination-is-worse-in-it-than-in-other-fields/?cs=38549
Be willing to hire, retrain, or do whatever it takes to employ people over 35 and this so-called problem will be
shown to be the chimera that it really is.
as will Java, the new Cobol. So what?
-><- no
"Here's an old computer science joke: What's the difference between hardware and software? If you use hardware long enough, it breaks. If you use software long enough, it works.
Actually, that's not true. COBOL programs are more durable because the COBOL architecture is very simple. Almost all of the work other than raw I/O was done in the COBOL code itself. Modern-day systems are heavily dependent on many external components, almost all of which are constantly evolving. So the "if it ain't broke, don't fix it" approach is actually more of a "how long can you afford to delay upgrading before the whole thing collapses beyond repair?"
Even legacy programs didn't actually get better with time. Once you reach a certain point, it's more like you move the bugs around. The old "pressing on a ballon" analogy goes way back.
Sorry, but I'm going to have to disagree with you. You can learn basic cobol in a week, sure. You can probably even learn all the useful keywords in a month, but almost certainly won't learn all their options or the best way to use them or the caveats of using some of them. You won't learn the various gotchas waiting in the wings when defining data structures either, whether in memory, or on disk.
A month might make you able to write fairly complex stuff, but it won't give you time to learn the best ways to write efficient fast code and COBOL, despite its apparent simplicity, is remarkably easy to write nasty (self modifying if you wish) resource-hogging evilness. If you're on mainframes, it'll be longer than that before you've figured the full intrigues of things like Expediter, or, if you're really unlucky, core dumps, which can be your only way to debug.
I've worked with COBOL since the mid 90s, so I'm still considered a noob in the field, but I've seen some horrors written by people with twice the experience I have and I've rarely seen *good* code written by people with anything less than a year of it on their CV.
Bear in mind also that most COBOL is mainframe still, so chances are that as well as the language itself, you're going to have to learn DB2, JCL, CICS and suchlike. Mainframe assembly will also likely crop up in your radar and in certain financial institutions, PL/1 - all linked into one big horrible mess. You might think you'll learn COBOL in a week, but almost no company using it for mission-critical stuff will let you within a mile of their production systems until you've a couple of years under your belt.
-Never argue with an idiot. They drag you down to their level, then beat you with experience-
Heh. In my job search I have actually been, well, surprised might not be the right word, but amused, at all the COBOL, FORTRAN, and mainframe postings. One thing I think they are getting themselves into trouble with though is all the postings I have seen require decades of experience in the technology, so they seem to be trying to replace retiring boomers with similarly skilled people, but not creating entry level or training paths.
That would help yes, but another part of the problem is, with these older technologies, many companies are only interested in drop-in replacements. There are few (if any) companies out there taking on entry or mid level developers for mainframe stuff, so once the current crop of experienced people run out they are going to be in trouble.
The "Update"
and the "Print"
At least that's what a lecturer told me many years ago when I did COBOL at uny. I didn't get on with it initially, then I got bored and opened the book... Then I learned that what the lecturer was telling me was his idea of what COBOL ought to look like and not generic. It got a little more interesting after that (along with the student competition to see how many errors we could make the compiler generate with the minimal amount of syntax errors - one mis-placed full-stop managed to get it to the limit of 999 once)
I've not written a COBOL program for over 30 years now. I don't miss it.
-G
As a guy who worked on some pretty complex financial software, I can tell you this; If you come to a company and say "Hey, look. Your software is outdated, and just not cool anymore. Let us fix it." They will say "OK, how much will it cost, how many times will you screw up (and you WILL) and how much will it cost in lost productivity, development and training time?" In other words, prove to me that the cost and risk outweighs the benefits of leaving my not-cool but working structure in place? Know what? You can't. When you are talking about financials, companies are justifiably VERY risk-averse. And yeah, people laughed at COBOL when I was coding, and even back in the 70s when I was learning. This is an old argument and the fact is COBOL will be around a very long time whether our new compsci grads like it much or not. They aren't paying the bills and looking at cash flow. They just see all that legacy code and say they could do it better. Maybe you can. But you're not gonna.
It isn't just the financial sector, its the medical sector, major distributors, casinos, and more, who use mainframes and similar (I work on an iSeries which at our scale is very much a mainframe - especially in reliability). COBOL and also RPGLE (looks like C/Pascal now) form the back end of many systems because of their ease of programming and especially because they are good at business math. Front end we have web facing apps; javascript/php/etc; RESTful services, and more. New development occurs everyday and is far more modern in its application that your aware. It isn't a land of green screens and such, but those do have their place.
The technology is anything but outdated, if anything we are as modern if not more. The key difference is dead nuts reliability, both in code and hardware. Downtime usually is when the site fails.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
And this is why it's good to arm yourself with solid languages like COBOL, because in 10 years when something finally needs to be replace your the one guy who can.
If you have any contact with COBOL in your profession, check out OpenCOBOL.org.
With a free COBOL compiler, you have an option of moving this ancient code onto a modern platform with fast CPUs. If you find it lacking, start coding!
I've tested it for Linux and Cygwin, and it works.
http://www.coboloncogs.org/
Yet you really don't see similar kool-aid drinking driving the replacement of COBOL. You'd think by sheer chance some dimwit PHB would come in and arbitrarily decide "Oh let's replace all that COBOL code with something written in Ruby on Rails by an intern," because he'd just read about Ruby on Rails on PC magazine and was impressed with how quickly you could develop a web-based "Hello World" application.
Admittedly a probably largish number of PHBs have attempted that and subsequently been fired by incompetence, but you'd think enough of those projects would limp along because they've already spent so much money, effort and time that to admit defeat would mean admitting gross incompetence at every level of management straight up to the CIO. Which, I'm pretty sure, is why Lotus Notes and Citrix are still around.
Funny story, back in the 90's when IBM was replacing Profs with Lotus Notes, some dim-witted PHB decided "Oh well PCs can do anything that mainframes can do, so let's write a Lotus Notes replacement to RETAIN!" RETAIN being the mainframe-based app they use for trouble ticket tracking and bug fixing across, I'm pretty sure, all their products. Well long story short, that project went on for a couple of years and then quietly disappeared. A decade later, they were still using and actively maintaining RETAIN. I wouldn't be surprised if it were still being used and maintained to this very day, even after IBM's acquisition of Rational.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I work for a large bank. When I mean large, I mean one of the top three. I have to regularly review code changes going into the Mainframe (yes, we have a mainframe). I see programs that not only have comments that go back into 1980, I see ports of programs that appear to come from times even earlier than that.
Management has spent the last 6 years feverishly attempting to get rid of the entire mainframe and everything that goes with it, and bring everything into "a distributed environment", but so far we are still here. And what's more, I see more new programs going in than I see old programs being retired. That tells me we're here for a few more years, and maybe a few more years after that. COBOL isn't going away, at least not until the last Russian programmer dies.
If telephones are outlawed, then only outlaws will have telephones.
I have programed in a couple languages. Nothing serious, just the exposure. I don't think it really matters what language software is written in, it can be done badly. The problem I see with a lot of software is that the modules aren't re-examined when updates or additions are made. After a while, you get bloated modules that are eventually orphaned in favor of another module as another programmer comes along. or worse, another sub contractor comes along and the tie to the original programmer is completely lost along with the notes from the project.
And why did it work? Noooo, not because Cobol is so great, or because programmers back then were so much better. The difference is simply that they had time to test it, and test it, and test it again, before it was finally deemed ready for shipping.
Today you get bananaware. Yes, bananaware. Matures at the customer.
Today, the deadline determines shipping date. Not "when it's done", but when the manager set some arbitrary point in time. Whatever we have at that point, we'll ship.
Now add that they hire the cheapest temps they can find instead of programmers with experience, and whoever has more than 2 years of XP tries to get the hell out and into some management position because the pay, let's face it, stinks, and you know why no program will EVER replace those dinosaurs.
They were programmed in a time when companies accepted that good software costs money.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Great if you can, a nightmare if you can't.
Like some industries have LOOOOOONNNNGGG support cycles. Take a car, for example - by law all parts must be available for 10 years after production stops. Now you do an ERP system upgrade and all the part numbers change. Now you have a problem because people will be ordering with the old part numbers until you can drop it (up to 10 yeras later). (This is why you find special "automotive" hard drives - nothing's changed ,just that you can get that exact part for 10 yeras. Ditto automotive grade ICs)
You can come out with big (printed) books of part number equivalancies, but people will still buy on the old part, so someone will have to do a part number translation and hang around answering questions on why they bought part XXX but got part YYY instead. Or even worse, have the same item listed as two different parts on the ordering system, causing even more confusion as people don't know what they should be ordering.
If your company is small, it's relatively easy to maintain a translation list and if your customer base is equally small, to distribute notices of part number changes. Plus retraining and redoing business practices is much easier (like being able to get rid of certain reports if they're no longer available in the new system - this can be a huge problem if the information is now scattered amongst 10 different reports when previously it was on one nice neat summary report).
But deepen the supply chain and lengthen the time of support, and things get hairy, fast.
Great if you want your tools to drive your business and not the other way around.
So a COBOL programmer is given a 5-year prognosis. He arranges with a hospital to be cryogenically preserved until a cure is found. On the appointed day, they prepare him, and he starts to feel a chill.
Next thing he knows, the chill is fading. The nurse uniforms look all futuristic. Injection devices are like on Star Trek, not piercing the skin. The hospital room decor is like in the 2001 movie.
He grabs a passing doctor and asks "So, did they cure my disease?" "No. The year is now 2999." "Huh? Why on earth did you thaw me out?" "Because you're the only COBOL programmer they could find, and Y3K is about to hit."/P