Forgot your password?
typodupeerror
Programming IT

COBOL Will Outlive Us All 318

Posted by Soulskill
from the lords-of-cobol-hear-our-prayers dept.
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."
This discussion has been archived. No new comments can be posted.

COBOL Will Outlive Us All

Comments Filter:
  • Batch (Score:5, Informative)

    by mwvdlee (775178) on Wednesday February 13, 2013 @06:16AM (#42881369) Homepage

    Well... that and the fact that COBOL is actually very good at what it was made to do; batch file processing.

    • Re:Batch (Score:5, Funny)

      by grh_angelone (1269828) on Wednesday February 13, 2013 @06:29AM (#42881427)
      I hate it. Stupidest language of all time. I'm trying to convert all these crap programs to nicely done RPG IV, but its a Don Quijote task. I hate the fact, that file access can only be done in 50 lines of code. String operations are total nonsense, ever tried to get a string rightaligned? RPG file access via chain is done in 5-6 lines including the definition of the file and rightalign via evalr().
      • Re:Batch (Score:5, Informative)

        by mwvdlee (775178) on Wednesday February 13, 2013 @06:52AM (#42881525) Homepage

        Yes, I'm sure it's much easier to code in RPG. In Java/C++/PHP/C# you could probably do it in less than a dozen lines of code as well. But none of those come close to the performance of COBOL for these specific tasks.

        As far as right-aligning a string; it's supported in the data division: http://mainframewizard.com/content/cobol-just-right-clause [mainframewizard.com]. I'm sure if I had to program RPG without any training or a manual, I wouldn't produce very good code either.

        COBOL is bad at a lot of things and in a lot of ways, but it does have a few redeeming qualities. It just turns out those particular qualities are highly sought after in many large companies.

        • Re:Batch (Score:5, Informative)

          by grh_angelone (1269828) on Wednesday February 13, 2013 @07:16AM (#42881637)

          ok, this doesn't bring us any further, but do you really think, that moving something in a right justified variable is the solution?

          this doesn't only need another variable, but if your source value has trailing spaces you will need a ridiculously long INSPECT line and an index variable for a substring.
          since cobol is dumb, you will further need an INITIALIZE for both variables.

          cobol:
          01 var1 PIC X(50)
          01 var2 PIC X(50) justified right
          01 sub PIC 9(2)
          initialize var1 var2 sub
          move "test " to var1
          initialize var1 tallying sub for trailing space
          if sub = 0
          move var1 to var2
          else
          move var1(1:sub) to var2
          end-if

          rpg:
          d var1 s 50a
          d var2 s 50a
          c eval var1='test '
          c evalr var2=%trim(var1)

          seems way more convinient :)
          even tough RPG is ill-reputed as an old static programming language this looks somehow like any other high level language and anyone should understand what's going on here without trying to figure out what that strange INSPECT does

          • Re:Batch (Score:5, Funny)

            by johnnyb (4816) <jonathan@bartlettpublishing.com> on Wednesday February 13, 2013 @09:08AM (#42882319) Homepage

            The real problem with COBOL is that, as Larry Wall has pointed out, you can't write poetry with it. There just isn't any good poetry that starts out with IDENTIFICATION SECTION.

            The one thing I do miss about COBOL is easy access to fixed-point numeric processing. This seems like a no-brainer, but it is still missing from nearly every language.

            • Re:Batch (Score:5, Funny)

              by VortexCortex (1117377) <(VortexCortex) ( ... -retrograde.com)> on Wednesday February 13, 2013 @10:05AM (#42882811)

              There once was an IDENTIFICATION SECTION
              Preceding a formula that defied all reflection.
              Using all the chem-lab's powers,
              it ran longer than four hours,
              To make pills that promoted erection!

              • Re:Batch (Score:4, Funny)

                by Anonymous Coward on Wednesday February 13, 2013 @10:57AM (#42883453)

                There once was an IDENTIFICATION SECTION

                Preceding a formula that defied all reflection.

                Using all the chem-lab's powers,

                it ran longer than four hours,

                To make pills that promoted erection!

                ...Burma Shave

              • Re:Batch (Score:4, Funny)

                by frank_adrian314159 (469671) on Wednesday February 13, 2013 @01:12PM (#42885085) Homepage

                It didn't start with IDENTIFICATION SECTION, so your example doesn't hold. But here's one:

                IDENTIFICATION SECTION delightfully leading to nouns and verbs of magic...
                In COBOL!!!
                A language for managers, a language for all -
                Bits of love, bytes of affection, words of poetry, identifying sections of paradise.
                Programming, motherfucker!
                Do you speak it?

            • Re:Batch (Score:4, Funny)

              by Anonymous Coward on Wednesday February 13, 2013 @11:46AM (#42884041)

              IDENTIFICATION DIVISON.
              PROGRAM ID. A COBOL FABLE.
              SECURITY. INSECURE.
              PROGRAMMER-ID. ARTHUR SHAPIRO.
              REMARKS. SLIGHTLY MORE MANGLED VERSION OF ONE IN JAN., 1968
              DATAMATION.
              DATE WRITTEN. ONCE UPON A TIME.

              ENVIRONMENT DIVISON.
              CONFIGURATION SECTION.
              OBJECT COMPUTER. ANY MUSIC BOX, MEMORY SIZE 8X64 BYTES,
              19 TAPE DRIVES, 11 DISK DRIVES, 1 GOLDILOCKS, 3 BEARS.
              INPUT-OUTPUT SECTION.
              FILE-CONTROL.
              SELECT TAPE DRIVES, ASSIGN THEM TO CREDITOR.
              SELECT DISK DRIVES.
              SELECT GOLDILOCKS, SELECT BEARS, ASSIGN TO ONE COTTAGE.
              I-O CONTROL.
              APPLY RED TAPE TO TAPE DRIVES, APPLY BRAHMS RECORD TO DISK DRIVE,
              APPLY GOLDI, BEARS TO COTTAGE.
              DATA DIVISON.
              FD GOLDI.
              LABEL RECORDS ARE STANDARD
              VALUE OF IDENTIFACTION IS "GOLDILOCKS"
              DATA RECORD IS GOLDILOCKS.
              01 GOLDILOCKS.
              02 HGT SIZE IS 62 INS.
              02 WGT SIZE IS 110 LBS.
              02 VITAL-STATS.
              03 B 38.
              03 W 24.
              03 H 36.
              02 RATING 100%.
              FD THREE-BEARS.
              LABEL RECORDS ARE STANDARD
              VALUE OF IDENTIFICATION IS "BEARS"
              DATA RECORDS ARE DADDY-BEAR, MUMMY-BEAR, BABY-BEAR.
              01 DADDY-BEAR.
              02 HGT 70 INS.
              02 WGT 750 LBS.
              02 COLOR-OF-EYES BLOODSHOT.
              02 DISPOSITION UNBEARABLE.
              01 MUMMY-BEAR.
              02 HGT 65 INS.
              02 WGT 700 LBS.
              02 COLOR-OF-EYES BLUE.
              02 DISPOSITION BEARABLE.
              01 BABY-BEAR.
              02 HGT 40 INS.
              02 DISPOSITION INFANTILE.
              WORKING-STORAGE SECTION.
              01 COTTAGE PICTURE IS COZY.
              02 KITCHEN.
              03 TABLE SIZE IS LARGE, VALUE IS 1.
              03 CHAIRS SIZE IS MEDIUM, VALUE IS 3.
              02 PORRIDGE.
              03 KING-SIZE OCCURS 1 TIME.
              03 QUEEN-SIZE OCCURS 1 TIME.
              03 PRINCE-SIZE OCCURS 1 TIME.
              02 DOOR SIZE IS USUAL, VALUE IS OPEN.
              02 BEDROOM.
              03 BED.
              04 LARGE OCCURS 1 TIME.
              04 MEDIUM OCCURS 1 TIME.

            • Re:Batch (Score:4, Funny)

              by roc97007 (608802) on Wednesday February 13, 2013 @04:08PM (#42887215) Journal

              Ah yes, COBOL poetry. The fourth worst poetry in the universe.

          • Re:Batch (Score:4, Interesting)

            by Dimitrii (958525) on Wednesday February 13, 2013 @12:04PM (#42884285)

            even tough RPG is ill-reputed as an old static programming language this looks somehow like any other high level language and anyone should understand what's going on here without trying to figure out what that strange INSPECT does

            Back in the late 80's early 90's, I was a co-op for IBM. I wrote an RPG program to rearrange some data file. Because of scope, the program had to be reviewed by a senior programmer.
            "This is just a start. Where is the rest of it. Do you need help?"
            "No. It is complete. Sample input and output files right next to it. I used the cycle"
            "The cycle still works?!"

            I had learned RPG II in HS. The cycle is all that was needed. He showed that program to every programmer that walked into his office.

            The deal it that it all keeps working.

          • by markhb (11721)

            Is RPG IV still column-specific, as the version I learned in high school (I don't recall if it was II or III) was? IOW, do you need to use [code] tags around that snippet?

            • Re: (Score:3, Informative)

              by grh_angelone (1269828)

              i ditched the columns for my example :)
              but i don't mind the column-specific syntax.
              in fact, i really like it

              but IBM introduced free format RPG some time ago
              you can start a free block wich /free and end it with /end-free
              http://www.ilerpgprogramming.com/2009/01/code-examples-of-free-format-rpg-iv.html [ilerpgprogramming.com]
              but they did a sloppy job on the implementation
              the definitions in the program header and some operations still have to be done in fixed format

            • by Darinbob (1142669)

              A family friend donated to me all her deceased husband's RPG-II manuals, thinking that they'd be useful to a kid interested in computers. When I read them I almost gave up on the idea of going into computing altogether.

        • by jythie (914043)
          I am skeptical of COBOL actually preforming types of tasks quicker then other languages. Every year the compilers for the most active languages get better and better, while the COBOL one has pretty much stood still for a long time.
          • Re: (Score:3, Interesting)

            by Classic53 (1181959)
            I on the other hand am looking forward to what IBM delivers with their COBOL VNext project (http://www.destinationz.org/Community/Evangelizing-Mainframe/June-2012/Join-the-Enterprise-COBOL-Vnext-Managed-Beta-Progr.aspx)!
          • Re: (Score:2, Interesting)

            by Anonymous Coward

            You probably have not been working with COBOL. The vendors that are supporting it are pushing the technology as much as the C/C++ compiler vendors are.

          • by Darinbob (1142669)

            COBOL compilers don't need to generate fast code. They just need to generate code that is correct. The compilers are getting faster (duh) but that's not their main purpose. The reason COBOL programs are still around isn't about performance, it's about keeping legacy programs running that are cheaper to maintain than rewrite or replace. Making a new program in COBOL would be silly.

            Imagine if your HR department told you that they were going to change all the payroll processing code because they found thi

        • Stop blaming COBOL for the performance. It's not the language. It's the resultant compiled code that matters, and the processor(s) it runs on.
          • by mwvdlee (775178)

            Indeed. And I have yet to see any programming language (excluding assembly) that can do all the things you can do in machine code. And yes, this includes C.

            Why would it be so strange that not all languages cover the same abilities on machine code level?

        • OpenCOBOL.org (Score:5, Informative)

          by emil (695) on Wednesday February 13, 2013 @09:48AM (#42882621) Homepage

          If you have any contact with COBOL in your profession, check out OpenCOBOL.org [opencobolorg].

          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.

        • Re:Batch (Score:5, Funny)

          by telchine (719345) on Wednesday February 13, 2013 @10:36AM (#42883197)

          It just turns out those particular qualities are highly sought after in many large companies.

          It keeps its head down, doesn't rock the boat and never asks for a pay rise?

      • Re:Batch (Score:4, Insightful)

        by sycodon (149926) on Wednesday February 13, 2013 @09:22AM (#42882421)

        You miss the whole point if COBOL, which is to provide a language that clearly explains what's going on while it's doing it. That means that a freshly graduated I.S guy can go in and understand what's going on and make changes.

        Sure, you can wire God Awful code with it and, I have seen it, but it doesn't take much effort to do it right.

      • by sycodon (149926)

        And BTW, nothing, and I mean NOTHING beats COBOL when it comes to slicing and dicing a record of data.

    • Re: (Score:2, Insightful)

      by Nerdfest (867930)

      It is no batter at 'batch' processing than any other language. The reason there's still so much of it around is that the majority is hacked together spaghetti written by people who should not have been writing code in the first place; tightly coupled code that people cannot easily replace a component at a time. Earlier attempts to replace the code generally failed because they attempted to use the same people who wrote the COBOL systems to write the replacements. It is a language that is used to allow syste

      • Re: (Score:3, Insightful)

        by ixarux (1652631)
        ^ This, I would agree with.
        COBOL is not a great programming language, and people who are experts in it are NOT good programmers per se. It definitely worked well back in the days, and we should appreciate its use, but let us not let nostalgia tinge the garbage that was useful a long time ago, and now just sits there as the elephant that no one cares to move around, gently tended by the cheap Asian labour... and has no exploits because it doesn't really move around a lot.
    • Re:Batch (Score:5, Insightful)

      by jellomizer (103300) on Wednesday February 13, 2013 @06:49AM (#42881509)

      No, the language doesn't matter. It is the fact that the COBOL code is old. When it was popular it was common for organizations to write their own software. This custom written software was molded to fit the companies processes and workflow. Then you add decades of alterations and the software gets very complex, however it nearly covers the full operation.

      So now if you are going to replace it, right now it is popular to get these "enterprise" solutions that are so generic that it takes more work to configure it than it does to make new software or port the code in a new language.

      As well most organizations just don't know why they need to upgrade they just think they do, and after the upgrade they want a program to do exactly what the last one did.

      • Re:Batch (Score:5, Insightful)

        by peragrin (659227) on Wednesday February 13, 2013 @07:40AM (#42881777)

        That because the cost of retraining people in new workflows is generally higher than the software package to begin with.

        If you gut and replace software you have to modify every employee's workflow to compensate. EVERY person has to do their job slightly differently, and no one has the answers as to how it all has to be worked out from the beginning for each part.

        That takes months in a small 20 person organization that is flexible and adaptable. It can take years of lost productivity for larger ones.

        I am doing it right now. We are gutting our old ERP system to use a much simplier but ultimately more useful ERP system. Everything from sales, accounting, purchasing, warehousing, inventory, delivery drivers, all have to change how they process their paperwork. We basically had the office staff doing 2 days of nothing as we sorted out bugs with the initial data transfer. Now that is done we begin the task of sorting out workflows, new SOPs, etc.

      • by dywolf (2673597)

        in other words, if ain't broke, don't fix it. just keep the guy that wrote it on retainer (or else he'll retire, then come back as a consultant for 5x the salary), and pay him explicitly to train the new guy.

        or else don't buy generic stuff, but hire a -good- code monkey to go through and develop the new program, in parallel with the old (ie, staff dont see the new one til it's completely done, outside of occasional small group tests...with some classic A/B iterations)

      • by asylumx (881307)

        So now if you are going to replace it, right now it is popular to get these "enterprise" solutions that are so generic that it takes more work to configure it than it does to make new software or port the code in a new language.

        Tell me about it! It doesn't have to be COBOL. Why is our company stuck on 20 year old RPG code? For the same reason that in 5 years it will be stuck on 25 year old RPG code. Because it does what we need and it's a royal pain to try to replace.

      • by crow (16139)

        Yes, companies can spend far more time and effort on customizing an ERP system to meet their needs than the system itself costs. Then, when new releases of the system come out, the customizations need to be done again. The other alternative is to change the company's systems to match the ERP. That's what my employer did when it outgrew the previous system and realized that it was too difficult to keep customizing the system. It meant changing lots of little things throughout the company. For example, e

        • by tlhIngan (30335)

          Yes, companies can spend far more time and effort on customizing an ERP system to meet their needs than the system itself costs. Then, when new releases of the system come out, the customizations need to be done again. The other alternative is to change the company's systems to match the ERP. That's what my employer did when it outgrew the previous system and realized that it was too difficult to keep customizing the system. It meant changing lots of little things throughout the company. For example, every

        • by bws111 (1216812)

          Great if you want your tools to drive your business and not the other way around.

    • Having to write MULTIPLY a BY b GIVING c instead of c = a*b surely prevents the implementation of complex algorithms.
    • Re:Batch (Score:5, Informative)

      by Anonymous Coward on Wednesday February 13, 2013 @07:24AM (#42881687)

      No. COBOL was designed for taking simple decimal (BCD) representations of quantities and financial amounts, conducting basic arithmetic operations on those and transferring the result back to storage or line-printer-style reports.

      It is still the basis of a great many online, interactive applications as a result of the development of OLTP systems that were intended to provide "real time" transactions on top of old legacy batch procedures. CICS in particular is alive and well and nothing to do with batch processing - though its interactivity is largely achieved by having the display terminal emulate the fixed fields of punched cards and line printer columns - and although it has support for several languages, COBOL is where it found its natural home.

      There's nothing magical or mysterious about COBOL (apart, perhaps, from the MOVE CORRESPONDING statement) - it's a procedural programming language that works with simple representations of data. The idea that a modern generation of programmers can't understand it is ludicrous and anyone that suggests rewriting swathes of code simply to change the syntax of its representation doesn't understand the first principles of software engineering.

      COBOL is here to stay in both batch and interactive applications.

      • by LoRdTAW (99712)

        COBOL may be decades old but there are still young people taking up COBOL programming. I have a friend who is around 30 now. He was a CS major in university and one of his professors recommended he learn COBOL. He told me it is the most valuable and useless programming languages you could learn. Out of university he got a job with a company doing contract work for IBM doing guess what? COBOL code maintenance. Now he is living in California making six figures working for a big financial institution maintaini

        • Re: (Score:3, Insightful)

          by camperdave (969942)

          Out of university he got a job with a company doing contract work for IBM doing guess what? COBOL code maintenance. Now he is living in California making six figures working for a big financial institution maintaining and writing COBOL. Not so useless now, is it?

          Money gets paid to lots of people for useless things. Professional athletes, fashion models, and dog groomers for example.

      • Re: (Score:2, Informative)

        by Anonymous Coward

        No, COBOL is magical, in that it supports handling of decimal arithmetic as integer, keeping track of the decimal place as a separate operation until the end. That is one of the main reasons that so many financial institutions used it -- no rounding. As far as I know, only PL/I is the only other language with this built in feature, even to this day. Certain compilers also used occult features of machines that did arithmetic in decimal (like a calculator) instead of binary --again, great (and in the 70's,

  • So Simple! (Score:3, Interesting)

    by Grindalf (1089511) on Wednesday February 13, 2013 @06:21AM (#42881391) Journal
    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!
  • by ixarux (1652631) on Wednesday February 13, 2013 @06:25AM (#42881409)
    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.
    • Re: (Score:2, Insightful)

      by Anonymous Coward
      "The financial sector, the lumbering dinosaur that accepts change only when they have no other option"

      You mean one of the first industries to start using computers commercially? Way before your glorious NASA?

    • by jandersen (462034) on Wednesday February 13, 2013 @08:14AM (#42881917)

      So, you didn't like to work on a mainframe, then?

      But don't slag off the mainframe just because it is 'old' technology - the PC architecture isn't all that young either, and the mainframe, believe it or not, is in fact very VERY much on the technological forefront, hardware wise. Mainframes had fiber attached disks before most modern developers had heard of networking.

      Big to huge institutions don't use mainframes because they are too backwards thinking, but because of reliability. In an industry where downtime costs millions to tens of millions per minute, that counts a lot. On a mainfram you can hot-swap just about everything - not just disks, but everything. And if you wish, you can run Linux on it as well; but it is amazing how often the choice is MVS and COBOL; that is because they are just what you need - not multitools like UNIX and C, just a plain old knife meant for cutting only.

    • by Shivetya (243324) on Wednesday February 13, 2013 @09:35AM (#42882517) Homepage Journal

      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.

  • by ae1294 (1547521) on Wednesday February 13, 2013 @06:35AM (#42881451) Journal

    All of this has happened before and will happen again...

    • Re: (Score:3, Funny)

      by Anonymous Coward

      Not to me it wont! As an ex cobol programmer I have a no resuscitation card for cobol emergencies card to be buried with me.

    • by jrminter (1123885)
      Clever. The Battlestar Galactica reference made my morning.
    • by a_hanso (1891616)

      I came here just to point out that "The scriptures say that COBOL points the way". I'm glad to see someone else had the same idea.

  • If it aint broke... (Score:5, Interesting)

    by detain (687995) on Wednesday February 13, 2013 @06:50AM (#42881515) Homepage
    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.
    • Re: (Score:2, Insightful)

      by jkflying (2190798)

      Why rewrite to something that is modular and well designed? Because it is impossible to add any new features to the old system without inadvertently breaking everything else.

    • by gutnor (872759)

      Do you really want to pretend that all the change we have had in software like browser, os, databases, search algorithm, storage, network algorithm, and countless other area have has no impact at all ?

      The reason the Bank do not change a working software is that by the time the software really works (i.e. 10+ years after the initial design), nobody really knows why it is working - if you are lucky. Most of the time the company has also lost the knowledge of how it is working too. Changing it becomes a hug

      • by DarkOx (621550) on Wednesday February 13, 2013 @08:12AM (#42881905) Journal

        The character set limitations are really platform issues not issues with COBOL or even in most cases the programs written it in. Honestly I have never understood all the COBOL hate. Sure it fails to deliver on its promises of letting business folks write code without any domain specific training in software develop. Just like every other language that has approached that challenge mostly BASIC or Object BASIC dialects.

        That said I'd be actually pretty surprised if a good C/C++/Java/Ruby/Python/PHP/whatever guy could put together a program to do something like print a fifty million decent looking telephone bill statements with accurate summary lines for transaction-data as quickly as a COBOL programer of similar skill and experience can. There really are some problems COBOL solves well. Bulk record processing and account reconciliation is one of those things because that was pretty much THE commercial and military logistics application for computers in the LATE 40's when COBOL was born. COBOL as you might expect is quite fit for that application.

        Its when people start trying to do interactive applications in COBOL be it CICS or web or whatever it gets silly and forced. It brings to mind various analogies about square pegs for round holes, and threaded fasteners to be deployed by hammer. Its sorta like how people tried to CGI applications in C for a long time in the webs early days. Sure it worked and if C was all you knew I suppose you could get the job done. C is good at many things, large amounts of string manipulation is not one of them; but its something you need for a dynamic website. Does that make C a bad tool, no, it just means its the wrong application for it.

        • by gutnor (872759) on Wednesday February 13, 2013 @09:20AM (#42882401)

          BTW, this is not a COBOL hate, that is a "if it ain't broke ..." hate.

          Argument like there is training required, there will be bug, ... are generally not the cause at all. The real cause is that the company lost the very business knowledge that is abstracted by the software. Worse, most of the time that knowledge has been outsourced to other third party completely.

          The 2 problems highlighted could be solved, even in Cobol. They won't be solved, and the reason is not that new software cannot be better, it is that the company has lost the knowledge of its own core business and is unwilling to take any real measure to learn it back. Most of the time, "If it ain't broke ..." is not wisdom, it is a sign of incompetence as bad as "Nobody has ever been been fired for buying IBM".

  • by Required Snark (1702878) on Wednesday February 13, 2013 @06:52AM (#42881521)
    COBOL was defined by the "Short Range Committee". It was never intended to last.

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

    http://en.wikipedia.org/wiki/COBOL [wikipedia.org]

  • by sgrover (1167171) on Wednesday February 13, 2013 @07:08AM (#42881599) Homepage

    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.

    • by mvdwege (243851) <mvdwege@mail.com> on Wednesday February 13, 2013 @07:23AM (#42881681) Homepage Journal

      That's because IT is suffused with a teenage culture that equates 'old' with 'useless'.

      Being able to spew the buzzwords related to the newest fad seems to be a requirement for a dev job these days.

      It doesn't help that the industry as a whole (especially in the US) seems to prey on young naive workers and likes to keep them that way in order to extract the maximum profit out of them.

    • by a_hanso (1891616)

      Every 3 to 5 years this topic comes up... Except it is the same old discoveries couched in modern terms.

      Pythia does say that all this has happened before and will happen again. COBOL is where it all began.

  • I'd swear I read the same article at the end of the 90's, before y2k .
  • by sirwired (27582) on Wednesday February 13, 2013 @07:23AM (#42881679)

    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.

  • It takes a week for a programmer to learn COBOL. A month at most to be proficient. Of course depending on dialect and environment, it can take more to be productive, but that's true also for COBOL programmers coming from other backgrounds. That means there will be no big shortage of programmers as big companies can train in-house in a matter of days.

    The problem with COBOL is that it will erode your sanity with mindless repetition and superfluous verbosity. If you are put to make COBOL programs, make a gene

    • For those teams that actually get a training budget, it'll be 2 days for one member of the 10 strong team per year. I last got training that I didn't pay for myself in 2000.

      • by necro81 (917438)
        That was one of my reactions to the article as well. This line from the end of page 1:

        ...other companies will make the decision to recruit and, if needed, train a new generation of programmers

        We've seen for quite a few years that many companies expect new employees to "hit the ground running", with nothing more than a cursory new employee orientation. Training, especially on-the-job training and formal mentorship/apprenticeship models, have largely fallen by the wayside. In other words, hiring managers

    • 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 wa
  • by fuzzyfuzzyfungus (1223518) on Wednesday February 13, 2013 @08:03AM (#42881859) Journal

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

  • by emes (240193) on Wednesday February 13, 2013 @08:11AM (#42881899)

    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 [itbusinessedge.com]

    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.

    • by jythie (914043)
      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.
  • Aye, but you call that living?

  • by Pope Raymond Lama (57277) <gwidion@mpLISPc.com.br minus language> on Wednesday February 13, 2013 @08:22AM (#42881963) Homepage

    as will Java, the new Cobol. So what?

  • by RabidReindeer (2625839) on Wednesday February 13, 2013 @08:30AM (#42882025)

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

    • That's an important observation. It also explains that other CS joke: "If we built houses like we build software, the first woodpecker that comes along would destroy civilisation". There's some truth to that, but it is not just about how we built software, it is also about what we are building with. Imagine building a house on a foundation that changes significantly over time, using bricks with varying and hidden qualities (and flaws), materials that may fail in surprising ways when used in certain combi
  • by jythie (914043) on Wednesday February 13, 2013 @08:39AM (#42882105)
    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.
    • Actually, I see this in many other IT jobs as well: many companies struggle to fill certain key senior IT positions, because there no longer is a career path that leads to those jobs due to outsourcing. Some companies actually come to realise that they can't outsource everything, then take a long hard look at their current IT career paths, and conclude that they need to start doing some stuff in-house again.
  • by DrogMan (708650) on Wednesday February 13, 2013 @08:43AM (#42882129) Homepage
    The "Input and Validate"
    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

  • by MikeLip (797771) on Wednesday February 13, 2013 @08:55AM (#42882225)
    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.
  • Yep (Score:4, Insightful)

    by Murdoch5 (1563847) on Wednesday February 13, 2013 @09:36AM (#42882521)
    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.
  • The "baby boomers retiring" business is nonsense on two levels:
    1. Any competent programmer can learn to read, write and maintain COBOL or translate it to whatever language is preferred, so there's nothing to fear from the people who are familiar with COBOL retiring. The language is plenty well documented.
    2. COBOL was never the province of baby boomers. It was introduced in 1959, when the youngest boomers were still kids and standardized in '68, when most boomers were still kids and had no access to computers
  • by Greyfox (87712) on Wednesday February 13, 2013 @10:17AM (#42882951) Homepage Journal
    You see a lot of companies make some really, and I mean REALLY, nonsense decisions to upgrade to some shiny cool thing that some manager somewhere read about in PC magazine. Like Citrix. So they add Citrix to their IT infrastructure and it sucks, because Citrix ALWAYS sucks, and everyone hates it, and now all those expensive PCs they put on everyone's desks are nothing more than dumb terminals to slower, less useful environments. Or, for an example closer to home, back in the 90's IBM replaced their mainframe based E-Mail system (Profs) with Lotus Notes, arguably the worst possible system for E-Mail. Just, you know, because... And Profs was so much better than Lotus Notes, it wasn't even funny. I'd have qualified that with "For E-Mail," but really, anything you could shoe-horn into Lotus Notes could probably have been shoe-horned into Profs and been better. But you know, Lotus Notes was shiny.

    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.

  • by tekrat (242117) on Wednesday February 13, 2013 @10:35AM (#42883185) Homepage Journal

    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.

  • by Opportunist (166417) on Wednesday February 13, 2013 @12:13PM (#42884399)

    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.

As the trials of life continue to take their toll, remember that there is always a future in Computer Maintenance. -- National Lampoon, "Deteriorata"

Working...