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.

Comments

Re:What's wrong with using COBOL?

[TimSSG]

I agree; but, I wonder more about how old of hardware is it running on. And, does the hardware and Operating System still have good support at a good price. Tim S.

That's all I have to say.

Re: What's wrong with using COBOL?

[kenh]

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.

Javascript fanatics take notice...

[Junta]

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.

Re: What's wrong with using COBOL?

[jcochran]

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.