Slashdot Mirror


Department of Homeland Security Still Uses COBOL (softpedia.com)

The Department of Defense has promised to finally stop managing the U.S. nuclear arsenal with floppy disks "by the end of 2017". But an anonymous reader shares Softpedia's report about another startling revelation this week from the Government Accountability Office: Another agency that plans to upgrade is the US Department of Veterans Affairs, which uses COBOL, a programming language from the '50s to manage a system for employee time and attendance. Unfortunately for the VA, there were funds only to upgrade that COBOL system, because the agency still uses the antiquated programming language to run another system that tracks claims filed by veterans for benefits, eligibility, and dates of death. This latter system won't be updated this year. Another serious COBOL user is the Department of Homeland Security, who employs it to track hiring operations, alongside a 2008 IBM z10 mainframe and a Web component that uses a Windows 2012 server running Java.
Personnel files are serious business. A 2015 leak of the secret service's confidential personnel files for a Utah Congressman (who was leading a probe into high-profile security breaches and other missteps) led the Department of Homeland Security to discipline 41 secret service agents.

37 of 217 comments (clear)

  1. What's wrong with using COBOL? by tolydude · · Score: 5, Insightful

    That's all I have to say.

    1. Re: What's wrong with using COBOL? by Anonymous Coward · · Score: 5, Funny

      It's not webscale you see

    2. Re:What's wrong with using COBOL? by Anonymous Coward · · Score: 2, Informative

      There is not a thing wrong with it. It is a lot easier to maintain for record-keeping tasks than some other languages which are in vogue. And Z mainframes are really reliable. My employer had one for years and the only time it went down was for scheduled OS maintenance.

    3. Re: What's wrong with using COBOL? by Anonymous Coward · · Score: 2, Insightful

      Ibm makes a ton of their money selling brand new supported systems that can run code compiled decades ago without modification.

      Now you could independently worry this also implies aging hardware, but isn't that old.

    4. Re:What's wrong with using COBOL? by Imrik · · Score: 2

      I have nothing against continuing to use COBOL for systems that already use it. However, I am a little surprised that a department that's only a decade and a half old is using it.

    5. Re: What's wrong with using COBOL? by swalve · · Score: 2

      Exactly! That's why you buy IBM. They do a lot of shitty things, but keeping business (and government) in business is what they do.

    6. Re:What's wrong with using COBOL? by swalve · · Score: 2

      They probably inherited it from one of the agencies they absorbed.

    7. Re: What's wrong with using COBOL? by Junta · · Score: 4, Funny

      Everyone knows the only webscale language is javascript, and the only webscale way to store data is MongoDB. There is no other approach. This is why, for example, Facebook is not webscale.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    8. Re: What's wrong with using COBOL? by kenh · · Score: 4, Interesting

      Ibm makes a ton of their money selling brand new supported systems that can run code compiled decades ago without modification.

      Microsoft has the same business model - it's called "upward compatibility" and was introduced in the computer industry by IBM in 1964 when the IBM System 360 was released - prior to that every computer model was a snowflake unique and unlike any that preceded it or were to follow it.

      Now you could independently worry this also implies aging hardware, but isn't that old.

      COBOL programs running under MVS operating systems on MAINFRAME hardware doesn't imply old hardware - IBM is still releasing new mainframes every few years.

      --
      Ken
    9. Re:What's wrong with using COBOL? by mlts · · Score: 2

      One advantage about mainframes is how few people are needed to maintain them once they are set up. Of course, one pays dearly to have CPUs execute in lockstep, Parallel Sysplex, and other things, but if you want something to want for five-9s, mainframes may not be stylish, but they will do the job.

    10. Re: What's wrong with using COBOL? by jcochran · · Score: 3, Interesting

      Yep, it's just a language. The thing I find oddest about it is how it handles subroutines. A long time ago, I attempted to figure out how I would translate from COBOL to assembly and figured out that the only way to actually do so and duplicate the behavior I'd see with COBOL would be to not use a stack, but instead have a little epilog at the end of each paragraph that was the last paragraph of a perform statement. In pseudo code, it would look something like this.

      ===========
      PERFORM PARAGRAPH_A THRU PARAGRAPH_B.
      CODE RESUMES HERE.
            Load address of RESUME in register temp1
            Store register temp1 in PARAGRAPH_B_EPILOG
            Jump to PARAGRAPH_A
      RESUME:
          code continues here....

      PARAGRAPH_A
              code....
      PARAGRAPH_B
            code...
            Load register temp1 with contents of PARAGRAPH_B_EPILOG
            Load address of PARAGRAPH_C in register temp2
            Store register temp2 in PARAGRAPH_B_EPILOG
            Jump to address in register temp1
      PARAGRAPH_C:
          code....

      Somewhere in data
      PARAGRAPH_B_EPILOG:
            WORD VALUE initialized to address of PARAGRAPH_C

      ================

      Really odd and didn't require a stack. But would account for the behavior observed whenever some did a PERFORM statement and somewhere within the target paragraphs did a GO TO to some other section of code. If they did that, it would "look" as if things were OK, but if for some reason the code execution path later crossed the boundary between the last named paragraph in the PERFORM statement and the next paragraph, the flow of control would suddenly jump to the statement following the PERFORM statement. It would also account for the situations where PERFORM statements would be used on overlapping ranges of paragraphs. Definitely an odd language, but understandable since the S/360 didn't have a stack.

    11. Re: What's wrong with using COBOL? by Lorens · · Score: 5, Insightful

      Who cares about webscale, we're talking big-data-scale. COBOL is not the problem. COBOL, DB2 for transactions, CICS to connect from web-land, nightly dump changes to Hadoop to run queries faster and cheaper. Been there, done that, saved millions (in USD). But nobody is even thinking of converting the 40000-and-some COBOL programs off the mainframe, not cost-effective at all.

    12. Re:What's wrong with using COBOL? by currently_awake · · Score: 2

      Updating software is a huge hassle. You first must find out exactly what the current software does (probably not fully documented), then make and test new software, then migrate the data over to it, then test the whole system against the old system to prove everything works correctly. It takes lots of time and money and an experienced team. If the old system works why pay lots of money to change it?

    13. Re:What's wrong with using COBOL? by bjohnson · · Score: 2

      here, I'll boil it down: "Is it fucking broken? No? THEN DON'T FIX IT!"

      Depending on severely antique technology (8" floppies!) is stupid and broken. Depending on a language that's just not in fashion because the kool kidz have declared it 'My grandpa used it so it MUST be too old and no good anymore!' is neither stupid or broken.

    14. Re:What's wrong with using COBOL? by gtall · · Score: 2

      Depending upon 8" floppies is not stupid and broken. Check eBay, you get scads of them for $10. Floppy controllers go for $25-50, more if you want better, but certainly reasonable. And the OSes used don't support a lot, so the threat footprint is much smaller than current systems.

    15. Re: What's wrong with using COBOL? by turbidostato · · Score: 2

      "The only real problem with COBOL is inaccessibility to programmers who still know it well."

      Not at all.

      COBOL is easy to grasp. Mindblowingly boring but easy. So if there're no programmers doing it when the need is there it is because plain old corporate greed and nothing else. COBOL is old-fashioned, which means new generations don't go for it by themselves. On the other hand, corporations using it, instead of doing the obvious -train their people, cry "OMG! it's so difficult to find people that know it well!" to see if miraculously somebody else pays the bill for them (it's not only COBOL, of course, go look for any job position and basically all of them go down to "I don't want a programmer, I want somebody with X years of experience on 'program language 2.3' -please, don't waste my time if you only know 'program language 2.2' or 'program language 2.4' because I won't consider you").

      Can you imagine USAF doing the same? Yes, those F-15 Eagle look awesome but, you know, it's very difficult to find pilots that know them well. What do you expect me to do? Nothing like taking selected people out from the street and train them, I hope.

    16. Re: What's wrong with using COBOL? by jandersen · · Score: 2

      But nobody is even thinking of converting the 40000-and-some COBOL programs off the mainframe, not cost-effective at all.

      And more to the point, using any other language would not add any value. COBOL may look incredibly clunky and weirdly underpowered, but it has all the functionality you need for moving accountacy-type data around, and none of the temptations of too many other languages to go into interesting constructions that you may not quite understand the full consequences of. COBOL may not be all-powerful, but it is the right tool for the job.

    17. Re: What's wrong with using COBOL? by lsatenstein · · Score: 2

      Who cares about webscale, we're talking big-data-scale. COBOL is not the problem. COBOL, DB2 for transactions, CICS to connect from web-land, nightly dump changes to Hadoop to run queries faster and cheaper. Been there, done that, saved millions (in USD). But nobody is even thinking of converting the 40000-and-some COBOL programs off the mainframe, not cost-effective at all.

      its much more difficult to make a costly logic with Cobol than it is with OOPS or C. I program in C and C++, and programmed with Cobol.
      And Cobol maintenance is more quickly done because the code is easier to follow. Cobol = great maintainability/performance for commercial/large volume transactions.

      I shudder to think about maintaining a large payroll application in C/C++

      --
      Leslie Satenstein Montreal Quebec Canada
  2. Hey, that's me! by 14erCleaner · · Score: 3, Funny

    Many of the stories about this say their systems "are about 56 years old and use an outdated computer language". That's actually a pretty good description of me! Well, I'm 58 and I use several outdated computer languages, but anyway...

    --
    Have you read my blog lately?
    1. Re:Hey, that's me! by seven+of+five · · Score: 2

      Queer... a department formed in the early 2000s has systems nearly 60 years old. Of course, these are not DHS systems but those they inherited from other depts...

  3. it's not what you say, it's how you say it. by Hognoxious · · Score: 4, Informative

    IDENTIFICATION DIVISION.
    PROGRAM-ID. HELLOWORLD.

    *
    ENVIRONMENT DIVISION.
    CONFIGURATION SECTION.
    SOURCE-COMPUTER. RM-COBOL.
    OBJECT-COMPUTER. RM-COBOL.

    DATA DIVISION.
    FILE SECTION.

    PROCEDURE DIVISION.

    MAIN-LOGIC SECTION.
    BEGIN.
              DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
              DISPLAY "What's wrong with COBOL?".
              DISPLAY "Frosty piss!!!!!! ".
    STOP RUN.
    MAIN-LOGIC-EXIT.
    EXIT.

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  4. Upcoming... by Art+Challenor · · Score: 4, Insightful

    Department of Homeland Security $18B over budget and 5 years late on a software designed to update personnel files. "(Big software consultancy) was supposed to have finished the new project based on (popular technology in 2016) in 8 months for $6M. Six years later the system is not functioning correctly, is full of security holes and is already obsolete."

    (Big software consultancy) noted that there were minor changes in the specification but that they expect money to be thrown at the project more or less indefinitely. "We pay our campaign contribution requirements regularly and so see no reason why we should be held accountable for any delays".

  5. So what? by kenh · · Score: 5, Insightful

    Your bank, your insurance company, and any large corporation likely has COBOL programs running in their environment.

    What it the issue with using COBOL? Is it the age of the language or the fact that all your professors in college choose not to teach it?

    Using a proven tool to solve a problem is called being practical.

    --
    Ken
  6. So what? by Anonymous Coward · · Score: 5, Insightful

    Who cares that they use COBOL? It's still a maintained language. The most recent standard is from 2014, just like C++. There are compilers for the language targeting virtually every platform that exists, including the JVM and .NET CLR, still under active development and support. The language supports object-oriented programming, although admittedly the verbosity certainly skyrockets there. Many of the largest financial institutions in the US rely on COBOL. Many government standardized file formats are very obviously driven by the nature of COBOL's structured I/O.

    The bigger question is whether or not these organizations still retain staff that are capable of maintaining these programs. It doesn't matter if the code was originally written 60 years ago or last year if nobody knows how it works or how to fix it.

  7. Javascript fanatics take notice... by Junta · · Score: 5, Interesting

    So first of all, there isn't anything wrong with COBOL at a fundamental level. It was designed for helping people with a certain sort of problem solving.

    So if that's the case, why is it the case that anytime COBOL is mentioned, people will mock it? Why do people associate it with horribly unmaintainable code? The primary answer is that it was a victim of its own success. As COBOL programmers realized they could solve complex solutions without changing languages, they went ahead and wrote a lot of stuff in COBOL that COBOL wasn't really designed to handle. At the end they would frequently have something that would somehow manage to work, despite being horribly convoluted and unmaintainable. As such COBOL earned a bad reputation, though the language itself bears relatively little of the blame.
    The language that really should take note of this history is Javascript. As people start writing more and more ugly code in Javascript, it actually worsens the language reputation, despite it being relatively serviceable for the intended problem domain. Contrast with something like LISP which most people won't bat an eye at being used, as it never came to be popular outside of the sorts of problems it works well to solve.

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:Javascript fanatics take notice... by Junta · · Score: 2

      I can actually read the stuff (and reflexively reimplement it in Perl

      So readable code is a bug to fix then? ;) Actually I know Perl *can* be readable, but for whatever reason it draws a lot of people who actually relish creating indecipherable code, as if every day was an obfuscated coding contest...

      The same story can be told of Fortran: hated by die-hard CS folks who see anything that isn't a general purpose sort of language as bad. Fortran serves a certain userbase well to this day. Admittedly since Fortran's peak, a lot of folks formerly resorting to developing programs can now use something even more tailored to those needs (e.g. Matlab, R, Spreadsheets, and so on) and python has taken a place as a viable alternative (thanks to scipy, numpy, and ipython), Fortran continues to be good for what it is named for: Formula Translation. Particularly on the front of parallelism, Fortran has *much* easier syntax than other languages. You write a fortran program that looks pretty reasonable/unassuming and run it on a laptop, it will also run on gigantic SMPs and Clusters and take full advantage of the additional resources.

      However, along with COBOL, people tend to snicker when it is mentioned, because it would be a terrible language for a lot of tasks, despite it being very good at what it was designed for.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  8. COBOL works by Lawrence_Bird · · Score: 2

    and has been updated over the decades, just as has FORTRAN, just as has C, C++, JAVA and gasp.. Ruby. No, its not the new shiny, get over it.

  9. Tires of this BS thread trend... by RedLeg · · Score: 2
    Look, old is not necessarily bad. These government systems running "obsolete" languages have been typically meticulously maintained for decades. That means they are close to bug-free, and their weaknesses are well known, documented, and mitigated. Ask a mainframe driver when the last time a critical bug in zOS was corrected.....

    There is an old joke.... if you got run over by a truck, and had to spend the rest of your life on computer-controlled life support, which platform would you choose?

    I want a VAX with VMS.

  10. Re:So what? by somenickname · · Score: 4, Insightful

    The real issue is that younger engineers think that all software needs to be new, shiny and preferably, in their pet language.

    I once worked in a shop where a group of very young engineers spent several years trying to re-write an old and fairly complex build system that was written in perl. They weren't re-writing it because it was slow or buggy or anything like that. They were re-writing it because they didn't like perl. And their reason for not liking perl was that it wasn't spelled "ruby". Years of work by several engineers to replace the perl program and they never got it to the state where it was as fast and reliable as the perl. Eventually the project was cancelled and they just found someone who knew perl and he adds a new feature every once in a while.

    I've also seen scientific shops decide that they need to replace all their fortran code with python for vacuous reasons like "modernization". This is frequently paid for by our tax money and, after years of development, if the python even becomes robust enough to deploy, they are shocked to find that the new code runs an order of magnitude slower than the old code and sometimes gives incorrect answers.

    This is the nature of the modern software industry. If something is written in COBOL/Fortran/perl, it needs to be re-written in python or ruby or whatever the pet language of the week is. Not because the old stuff doesn't work, because the old stuff is old. Younger engineers love to re-invent the wheel as long as they can use their pet language.

  11. Re:Solve what needs to be solved... by plopez · · Score: 2

    And 40 hour work weeks, union like labor rules, all Federal holidays off, etc.

    As opposed to me working for a Fortune 50 tech company with 50 to 60 hours a week, working late on the phn talking to monkey coders in the low cost programmer nation of the moment, working holiday, and sometimes "vacations", and under constant threat of layoff.

    I'd switch.

    --
    putting the 'B' in LGBTQ+
  12. Migrations are costly and newer is not better by cowtamer · · Score: 4, Informative

    For the record -- IANACP -- I've never written or compiled a line of COBOL in my life..

    But I did help migrate an old mainframe based system to a new "client-server based three tier architecture system based on Linux and a Java thin client" back in the very early 00's. The old system was near perfect and did the job, even though it ran on the (then alien to me) mainframe.

    The new system was written by 20-somethings like myself and would (even with WAY more computational resources) conk out at the worst times. This, I believe, is the story of EVERY migration. It's not necessarily that older is better, or "they don't make them like they used to", but that software development is a bug-prone and arduous process that you will not get right the first time.

    So if you're the VA administrator with an established career, you might be forgiven for not taking the risk of jeopardizing employee and patient data and services to satisfy some vague desire for "modernization", especially if you know that the project will be full of errors and WAY over budget.

    What's the solution? I don't know. Start teaching COBOL and commission Google to create "Google Mainframe Migration"???

  13. Op still uses Slashdot. by AgNO3 · · Score: 2

    The OP still uses the archaic Slashdot site used by many 2 decades ago when the web was young. Obviously any technology older then last week should be depricated.

    --
    OMG Ponies!!! with Glitter!!!! I miss Pink :-(
  14. Re:"Still uses COBOL" is not the point by krelvin · · Score: 2

    Since when is COBOL obsolete?

  15. Re:Lots of places use COBOL by TheRaven64 · · Score: 2

    Exactly. Which is easier to maintain, run on modern hardware, and buy a supported toolchain for: COBOL code written in 1965 for OS/360, or Visual Basic code written in 1993 for Windows 3.1?

    --
    I am TheRaven on Soylent News
  16. Re:Next up... by serviscope_minor · · Score: 2

    Nah, I think they should upgrade to COBOL's object oriented successor. I believe it was called ADD 1 TO COBOL GIVING COBOL.

    --
    SJW n. One who posts facts.
  17. Re:Lots of places use COBOL by hey! · · Score: 2

    This.

    It's great when a tool is built to be a pleasure to use; and smart language and system developers try to design stuff that will capture developer enthusiasm and mindshare. But ultimately as a disciplined, professional developer your decisions should not be driven by your enjoyment. That's just a nice to have. They should be driven by doing right by the people who use the system and the people who pay your salary.

    People who don't understand this are a disaster. They run the clock out mucking around with the interesting bits of a system rather than tackling the important stuff first. They throw out old, proven code because it's more fun to write new code than maintain old stuff.

    Sometimes you do have to rewrite from scratch; and it's important to try to incorporate interesting things into every project you undertake because you can never be at your best just going through the motions. But ultimately your job is to make sure needs are met at an affordable price.

    --
    Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
  18. Re:Lots of places use COBOL by Bowfinger · · Score: 4, Insightful

    It's even easier than that:

    1. Put aside your age biases
    2. Hire one of the multitude of experienced COBOL developers who cannot find jobs because they're over 50

    As a hiring manager, I see too many of my peers pass over older professionals in favor of some young hotshot they think is "cheap" and will work long hours. They don't recognize that this hotshot is padding his resume and biding his time until he finds the cool job he really wants, usually within 2-4 years. Meanwhile, those "old" pros would crank out far more quality code in their 40-45 hour weeks than hotshot would in 60, and they'll be happy to stick around for the long haul.

    (And no, I'm not suggesting that all older developers are better than all younger ones. People are people. But rampant age discrimination is one reason this industry struggles to find good people.)