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.'"

20 of 277 comments (clear)

  1. A good knock in deed.. by bsDaemon · · Score: 5, Funny

    Though, to be fair, 50 years isn't quite as long as the average cricket game.

  2. 75% of apps? Shaa, right! by Adeptus_Luminati · · Score: 4, Interesting

    "It also runs about 75 per cent of the world's business applications"

    Gee, I didn't know Windows Apps were coded in COBOL.

    Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%.

    Adeptus

    --
    No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
    1. Re:75% of apps? Shaa, right! by duffbeer703 · · Score: 4, Informative

      Do you accept or make payment via credit card, check or ATM debit? Congratulations, you (indirectly) use COBOL.

      --
      Conformity is the jailer of freedom and enemy of growth. -JFK
    2. Re:75% of apps? Shaa, right! by Archtech · · Score: 4, Informative

      "It also runs about 75 per cent of the world's business applications"

      Gee, I didn't know Windows Apps were coded in COBOL.

      They can be, using the excellent Microfocus COBOL or many other implementations.

      But actually, only a very few of the world's (important) business applications run on Windows. Seriously. Big heavy-duty transaction-processing apps run overwhelmingly on mainframes, because they just work.

      --
      I am sure that there are many other solipsists out there.
    3. Re:75% of apps? Shaa, right! by Old97 · · Score: 4, Insightful

      The wording is misleading. Perhaps it's more accurate to say that 75% of business computing by value depends on COBOL. I've worked at a number of places in the financial services industry and have a lot of friends who do as well. All of our core business functions are still in COBOL. A lot of the data is still in VSAM, IMS and Model 204 legacy stores. A lot of what is in DB2, an RDBMS, is VSAM files converted directly to tables instead of truly relational databases.

      The fun stuff (Java, .NET, Web) runs the outward facing services and peripheral functions, but claims processing, credit card reconciliation, billing, accounting, etc. is still in COBOL. The computer industry press spends a lot of time admiring the new chrome and fins and that new built-in radio with FM, but business is still powered by the COBOL drive train running on mainframes.

      Even the clued in managers want to get off of it and onto more flexible systems and more productive languages, but it's too scary (risky) because they are afraid to break something. No one knows what the business rules are because they are embedded hither and yon in COBOL programs.

      --
      Very often, people confuse simple with simplistic. The nuance is lost on most. - Clement Mok
    4. Re:75% of apps? Shaa, right! by PhunkySchtuff · · Score: 4, Insightful

      Can we get rid of it? Surely COBOL has developed faults over time, just like a train that's been running since 1850 would have.

      Or, just maybe, it's proven itself to be stable, reliable, well-understood, suited to the purpose for which it's used and relatively bug free?

      Nah, of course not. It's old and busted. Bring on the new hotness.

    5. Re:75% of apps? Shaa, right! by MBGMorden · · Score: 4, Insightful

      I have to agree. We recently switched parts of our tax billing software from an old COBOL system running on an AS400 to Windows. There were some legitimate concerns involved - creating a graphical sketch wasn't possible on a text-mode system, and tax laws change very frequently, and the old system was just becoming difficult to maintain.

      So, we switched to a Windows app with a SQL Server backend. FWIW the database backend has been rock-solid, but the actual client? It's junk. That old clunky COBOL system might have been awkward to use and a bit long in the tooth, but it NEVER crashed, and its mistakes were minimal to say the least. This new Windows system crashes constantly (including crashing if you work too fast - yeah I literally have to do a "one one-thousand" count when switching between properties or the client will lock up), and it goofs up the data frequently enough that in another 5 years I think our data will be reduced to an unreliable mess.

      Truthfully though, it's not the fault of Windows, or whatever language the newer apps are written in (Visual Basic in the case of our new pile o' junk). You can certainly write good stuff in new languages on new systems. I think it's a two-fold problem. One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone), but also, programmers today look at problems differently. They program for "features" first so they can give a good sales presentation. In the old days it seems like a reduced feature set was fine so long as your code was done right. That's not the case anymore, which is a shames, because on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.

      --
      "People who think they know everything are very annoying to those of us who do."-Mark Twain
    6. Re:75% of apps? Shaa, right! by SanityInAnarchy · · Score: 5, Insightful

      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!
    7. Re:75% of apps? Shaa, right! by MasterOfMagic · · Score: 5, Insightful

      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.

    8. Re:75% of apps? Shaa, right! by Bakkster · · Score: 5, Insightful

      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!
    9. Re:75% of apps? Shaa, right! by orzetto · · Score: 4, Insightful

      Visual Basic

      I think I see your problem here...

      One, the complexities of a GUI makes codes many times more intricate [...]

      Here's the rest of your problem. A GUI must never bump into a difficult or mission-critical algorithm. That's supposed to be its own library, which is accessed by the GUI through a clean and solid software interface. This is a major architectural fault: a Big Ball of Mud, and some languages encourage that more than others.

      My suggestion would be: get a language with a lower density of script kiddies, sufficiently popular and object-oriented (Python, C++, Java, ...), get some good programmers with proven track record, and rewrite the client. Specify that you want all functions and variables documented, and test suites; if they say "that will cost you more", show them the door. If they say "we do it anyway", that's a good sign.

      --
      Victims of 9/11: <3000. Traffic in the US: >30,000/y
  3. COBOL by mcgrew · · Score: 4, Funny

    Happy birthday, Crappy Old Bad Obsolete Language! You need to take better care of yourself, you look a lot older than fifty.

  4. COBOL made me what I am today by walkoff · · Score: 5, Funny

    We were taught COBOL at college 25 years ago and i'm still a grumpy old git

  5. Typo by winnitude · · Score: 4, Funny

    "COBOL Celebrates 50 Years"

    Should read:

    "COBOL Bemoans 50 Years"

  6. Not So Bad by Ancient_Hacker · · Score: 4, Insightful

    COBOL did a lot of things right, things that a lot of modern languages ignored.

    Little things like:

    * Having a manufacturer and machine and OS-independent standard.
    * Quasi human-readable code.
    * "MOVE CORRESPONDING"

    that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

  7. Lack of knowledge by zoomshorts · · Score: 4, Interesting

    Most businesses did not see any need to port mainframe stuff to WinDoze.
    COBOL is solid. WinDoze is flakey. RM COBOL extended COBOL to modern
    programmers. If it isn't broke, you don't 'fix' it.

    Get a grip, and learn. I suggest going back to school. Just my opinion
    though.

    "Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%."

    I suggest YOU go to work for any major business and work on their accounting software. Highly dubious? Hardly. Your business 'Apps' are probably front ends for a real language on a mainframe.
    Visual this or that.

  8. Happy 50th by CharlyFoxtrot · · Score: 5, Funny

    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.
    1. Re:Happy 50th by Anonymous Coward · · Score: 5, Informative

      000100 IDENTIFICATION DIVISION.
      000200 PROGRAM-ID. CONGRATS.
      000300
      000400*
      000500 ENVIRONMENT DIVISION.
      000600 CONFIGURATION SECTION.
      000700 SOURCE-COMPUTER. RM-COBOL.
      000800 OBJECT-COMPUTER. RM-COBOL.
      000900
      001000 DATA DIVISION.
      001100 FILE SECTION.
      001200
      100000 PROCEDURE DIVISION.
      100100
      100200 MAIN-LOGIC SECTION.
      100300 BEGIN.
      100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
      100500 DISPLAY "Congratulations with your 50th birthday" LINE 15 POSITION 10.
      100600 STOP RUN.
      100700 MAIN-LOGIC-EXIT.
      100800 EXIT.

  9. Longevity by wandazulu · · Score: 5, Insightful

    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.

  10. COBOL Joke by Haxzaw · · Score: 5, Funny

    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".