Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Military Data Storage Programming United States

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

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.
This discussion has been archived. No new comments can be posted.

Department of Homeland Security Still Uses COBOL

Comments Filter:
  • by tolydude ( 1080033 ) on Saturday May 28, 2016 @09:34AM (#52201083) Journal
    That's all I have to say.
    • by Anonymous Coward on Saturday May 28, 2016 @09:36AM (#52201089)

      It's not webscale you see

      • by Lorens ( 597774 ) on Saturday May 28, 2016 @11:21AM (#52201455) Journal

        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.

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

        • 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++

    • Re: (Score:2, Informative)

      by Anonymous Coward

      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.

      • by mlts ( 1038732 )

        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.

    • by Hognoxious ( 631665 ) on Saturday May 28, 2016 @09:43AM (#52201121) Homepage Journal

      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.

    • by Imrik ( 148191 )

      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.

      • by swalve ( 1980968 )
        They probably inherited it from one of the agencies they absorbed.
        • by rbrander ( 73222 )

          There's something funny in there about COBOL surviving because it has object inheritance going for it.

      • Why not? More efficient than modern solutions. And developers who understand computers and computing, unlike today's kiddies. Should the Department of Homeland Security worry more about security or coding fashion?

    • by Z00L00K ( 682162 )

      Cobol is used in many major systems by many government agencies and also many major corporations in various sectors.

      The big problem with Cobol is that it's expensive to run and maintain, but the corporations are locked in by vendors and a huge non-portable codebase.

      • Isn't a fleet of nuclear missiles inherently expensive to maintain - how is cobol the big problem here ? It sounds to me as if some sales guy is using scare tactics to sell a new expensive and difficult to maintain replacement system.
      • Yes but look at modern replacements, also designed for lock in, requiring the use consultants to keep it running (consultants which are coincidentally supplied in bulk by the makers of the modern software). SAP/R3, Oracle, etc.

    • Remember, C is a language from the 70s, and Unix is an operating system from the 70s, so anyone who uses those is a hopeless Luddite more interested in efficiency and getting the job done than in arguing about methodologies like real coders!

    • Well...

      The software ends up extremely rigid and hard to change. Changing the length of a field from 9 to 10 characters can cost hundreds of thousands of dollars of development time, as you update VSAM or ISAM files and copybooks across a zillion different places. Hopefully you have enough padding everywhere if you want to add something to a request.

      It has all sorts of annoying legacy limitations. CICS transactions are limited to 4 character names. Was it S320 I was supposed to call or H614? Did anyone bo

    • What's wrong with it? Global GOTOs.

      Other than that COBOL does what it was designed for pretty well.

  • What's the use of COBOL got to do with leaks?

    If anything COBOL is more secure, because you can't transport a wad of punch cards via the internet.

  • by 14erCleaner ( 745600 ) <FourteenerCleaner@yahoo.com> on Saturday May 28, 2016 @09:39AM (#52201105) Homepage Journal
    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...
    • 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...
    • by antdude ( 79039 )

      And making big bucks. ;)

  • All large US government organizations still rely on COBOL systems in one way or the other. They are slowly being replaced, but they process a large amount of data, and have been doing so for a long time. With modern hardware, the number of people who are required to support them dropped from a few hundred per large system to 30-50 people. Hard to replace all the effort that went into making them do what they do.
    • Replacements will not reduce costs or personnel, and most likely will not improve efficiency. Look at the massive infrastructure that keeps modern complex systems running. Replace a system that you know and understand and replace it with some modern commodity hardware chosen for being cheap (rooms full of them). Replace the army of IBM drones with an army of Oracle drones. After all the massive expense of converting over the final overhead costs will likely be identical, only you're stuck with a differe

  • ... and not what you can solve. - or- When all you know about is a hammer, everything looks like a nail.

    .
    The major problem facing the Dept of Homeland Security is not its working COBOL system. The major problem facing the Dept of Homeland Security is that it cannot get enough candidates for its jobs.

    Maybe the focus should be more on how the Department can attract more qualified candidates, and less on fixing its working computer systems.

    • by plopez ( 54068 )

      BS. COBOL is easy to pick up. In addition most of the code is in "maintenance" mode meaning no real scratch development which gives a person time to learn it.

      In addition many of the "commodity" programmers I have met are bound and determined to write in COBOL idioms in [JAVA | C# | C++ | Python| programming flavor of the month] .

      I am speaking from direct experience.

  • Upcoming... (Score:5, Insightful)

    by Art Challenor ( 2621733 ) on Saturday May 28, 2016 @09:59AM (#52201185)
    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".
  • Yes its an old language and not very sexy by today's standards. What COBOL does really really well is process huge sums of data very quickly and efficiently. The Payroll systems I work on today use COBOL and NOBODY touches them. Why? Because they work. Being around so long, the language is pretty much air tight in terms of bugs, etc.

    The biggest challenge is trying to find someone that can code in COBOL. Universities these days don't teach it anymore.

    • by Livius ( 318358 )

      I hate COBOL with a passion - it seriously hurts my brain - but even I will grudgingly admit it's good for the things within its area of specialization.

      An attempt to get rid of a COBOL system that works is an obvious attempt to uselessly re-write something with the fad of the week in order to funnel money to contractors.

      • 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?
      • by hey! ( 33014 )

        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 w

    • The biggest challenge is trying to find someone that can code in COBOL.

      Not really. The process works like this:

      1. Hire someone who can program.
      2. Train the person in COBOL.

      • by Bowfinger ( 559430 ) on Saturday May 28, 2016 @03:13PM (#52202273)

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

  • Staggering (Score:2, Informative)

    by DaMattster ( 977781 )
    The incompetence of the federal government is absolutely staggering! It's time to get rid of Homeland Security. The Department of Homeland Security is the asshole of the executive branch of government.
    • by gtall ( 79522 )

      Incompetence of the federal government? Let's assume you are referring to the executive branch since that's what's usually meant by that term. Lessee, which branch of government has refused to put money into infrastructure so that we have a country with unsafe bridges? That's only the tip.

      The FDA keeps your food and drugs safe from Joe's Fish and Drug Company. SS keeps grandma from moving in with you, but I'd rather she did just so she wasn't subject to "incompetence" any more. Planes? Federal oversight. Cl

  • So what? (Score:5, Insightful)

    by kenh ( 9056 ) on Saturday May 28, 2016 @10:01AM (#52201201) Homepage Journal

    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.

    • Re:So what? (Score:5, Insightful)

      by somenickname ( 1270442 ) on Saturday May 28, 2016 @11:19AM (#52201451)

      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.

      • Scripting languages. It's all they've ever known. They're coders, not programmers, engineers, or computer scientists.

        Personally, I don't use algebra anymore, it was invented centuries ago so I'm waiting for something new to use.

      • by dbIII ( 701233 )

        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"

        Sounds like "Wayland" :)
        It's getting more and more of that hated X Windows "complexity" as the project matures.

  • So what? (Score:5, Insightful)

    by Anonymous Coward on Saturday May 28, 2016 @10:04AM (#52201209)

    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.

  • Comment removed based on user account deletion
  • I hear their computers still use binary
  • by Junta ( 36770 ) on Saturday May 28, 2016 @10:16AM (#52201263)

    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.

    • The same can be said (to an extent) about PHP as well. PHP was originally basically a more powerful replacement for SSI. If you think of it in that context, it's historical flaws like register_globals are really not so bad.

    • So if that's the case, why is it the case that anytime COBOL is mentioned, people will mock it?

      Fucking hipsters, Donny. They think just because some group with a .io site crapped out a new language yesterday that everything else that came before it is old and worthless.

      It's nothing to worry about - these men have never written real software before.

    • That sounds more like the problem is creating languages that aren't general purpose than anything else.

    • there isn't anything wrong with COBOL at a fundamental level

      There are many things wrong with COBOL, but there's one thing that's very right with it: support. You can take COBOL code written in the '60s and run it unmodified on modern hardware with toolchains provided by multiple vendors. Even FORTRAN doesn't have that - it's very hard to get support for anything older than FORTRAN '77 from a modern Fortran toolchain (and even F77 support is only there because of a certain codebase that can't be modified without needing re-validation, which can't happen as long as

  • by Lawrence_Bird ( 67278 ) on Saturday May 28, 2016 @10:16AM (#52201265) Homepage

    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.

  • by RedLeg ( 22564 ) on Saturday May 28, 2016 @10:30AM (#52201297) Journal
    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.

    • Calling it obsolete is the same as kids calling checking accounts obsolete, or desktop computers, or wearing underwear. Just ignore them and try not to stand downwind.

  • The article, like so many others, is blaming the wrong organization. (1) Agency budgets are micro-managed by Congress. There's no money to spend on system replacement unless Congress says so. (2) Congress, like legislatures in general, is extremely reluctant to appropriate money to replace something that works, even if it is just barely limping along. Shiny new toys for killing people a possible exception. (3) When procurement does finally happen, it's done under rules set by Congress that work reasona
  • By the time the DHS was formed, COBOL was already obsolete. They should've never used it in the first place.

  • by cowtamer ( 311087 ) on Saturday May 28, 2016 @12:01PM (#52201605) Journal

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

    • by Ckwop ( 707653 )

      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.

      This is absolutely the case. Software projects are still incredibly risky. You only have to read the Standish Group's CHAOS report [infoq.com] to see how risky these sorts of projects from a management perspective.

      The fact that the system is still there doing it's job mean

    • by dbIII ( 701233 )
      The most hilarious migration I've seen was taking a system for several university libraries from a large number of fairly cheap terminals to a small number of expensive PCs with MS Windows running a terminal emulator application. Of course they were all down a few days each year due to virus incidents.
  • by AgNO3 ( 878843 ) on Saturday May 28, 2016 @12:09PM (#52201633) Homepage
    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.
  • Look, I don't like COBOL as a language, never have. I dislike it almost as much as I do Python (for diametrically opposite reasons). Thing is, it has worked for a very long time, and governments around the globe are still using it to this day. I know up here in "where you're moving when Trump wins" Canada, we have a lot of gov't projects to migrate off of old COBOL systems. It's not because the old system is broken: it ain't. It's because the people who can maintain such systems are dying of old age.

    It

  • Millions of Americans (hundreds of millions, really) are still using incandescent light bulbs, a technology that is almost 150 years old.

    Millions of Americans are still driving cars powered by internal combustion engines, a 150 year old technology.

    What's the problem with a 60 year old programming language? Should these agencies re-write to run on a 40 year old operating system using a language based on another 40 year old language? Hell! maybe they should re-write the whole stack in Rails! We've seen ho

  • Still uses its tongue to lap up water. So, was there a point to this piece of "sheer genius" expressing concern on Cobol. And lest we forget the fun systems run by Fortran.

  • Someone could be making mega bucks to sell them a system that does the same thing.

    Of course it would be slower, lacking features, years late and way over budget, same as any other modern government software programme

"Engineering without management is art." -- Jeff Johnson

Working...