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.
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.
That's all I have to say.
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.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
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?
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."
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.
.
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.
... are like people complaining when someone does not use an electric pie knife! Or, like people who complain about the fact that not all kettles are connected to the Internet yet.
You get it.
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.
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.
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
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.
Geez, COBOL? OMG that's sooo 1960s. They need to upgrade to something modern instead... like...
P
H
P
Muhwahhaahahahah!
You are not alone. This is not normal. None of this is normal.
I hear their computers still use binary
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.
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.
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.
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 reasonably well for paper clips and snowplows. Not so well for software.
I spent three years on staff trying to explain IT things to a state legislature. Educational. Frustrating as hell.
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.
Back in the 1990s, on the comp.lang.c or comp.os.unix USENET news group, there was a knowledgeable poster who also was a COBOL evangelist. He once posted a 4-line, portable COBOL program that sorted a file. (All those divisions people make fun of are optional in COBOL..) Let me repeat: 4 lines to sort a file and portable to any system that has a COBOL compiler. You can't do that in C; remember that system("sort ...") (or even "sort" from a command line) is not portable. Of course, COBOL has a standard, internal SORT function. As with any language, COBOL is useful in the appropriate circumstances.
By the time the DHS was formed, COBOL was already obsolete. They should've never used it in the first place.
Yup, this exactly. If those damned whippersnappers would spend half the energy understanding the business problem supported by the old code that they spend complaining about it, the rewrites might work. The problem is all they see is the technology, and not the problem it's solving (and usually solving well). You can teach someone to write COBOL - I've taught myself over the last five years because after a mass layoff, I was the only one left who stood a chance of figuring it out because I already *understood the business problem the code solved* and therefore could figure out what it was trying to do and more importantly, why. It's also why I've recently completed a migration to python that does everything and more that the original did, and it's worked almost flawlessly since implementation.
Seriously, what language or environment isn't a thing. Understanding the problem is the thing, the language/environment is just a stick with which to lay smackdown on the problem. There are lots more sticks in the world - some of them more expensive, some of them more durable, some less so. Pick one and get to stabbing the problems.
I say this as a crusty greybeard. Now get off my lawn. *smirk*
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"???
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
I did a one-night IT job at a branch office of a financial institution to convert Token Ring to Ethernet in 2005. That was my first and last time that I ever saw Token Ring in the field. The building was brand new and wired for Ethernet, but the financial institution had coaxial cable installed. Never mind that all the workstations had Token Ring cards that could use twisted pair cabling to plug into the wall. I guess install coaxial cables was cheaper than buying new switches for twisted pair cabling. If you think COBOL is ancient, some financial institutions are probably still using Token Ring today.
30+ years ago, I learned a little COBOL (thinking it would get my 15 year old ass a tiny bit of respect from the mainframers). I would never admit it IRL.
In college (decades ago) I listed the languages I could code in for a prof. It tailed off with me looking at the ground and mumbling 'cobol'. The professor noted at the time that everybody who can code in COBOL is embarrassed by that fact.
John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
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's not a simple matter of watching a Youtube video made by a 12 year old. The language itself is quite simple, it's the fifty years of legacy code that make it a nightmare to find new blood, and the few who can pull it off get to charge whatever they want. On paper, this becomes a steep liability, which is why departments are making the largely financial decision to migrate.
Problem is, governments are legendary at hiring the most incompetent, 7000% over budget, milk-the-cash-cow-dry kind of contractors. Whether it's due to corruption or ineptitude, it's true up here in Apologyland. It's true down there in Gunfreakland. It's probably true across the pond in Thataintfoodland.
Don't blame COBOL, that old dog has done us well for most of our lifetimes. Blame these idiots who can't manage their contractors, and the contractors who can't manage their idiots.
-Billco, Fnarg.com
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 how successful that has worked out.
That old code, with some new code too, running on modern mainframes forms the backbone of the worlds business. Mainframe technology, though seemingly dated and arcane, is extremely robust and supports exceptionally high volumes using COBOL and in many cases, mainframe assembler.
You don't replace something because it is old, you replace it when the economics of not fixing it demand replacement.
there are 3 kinds of people:
* those who can count
* those who can't
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
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.
Absolutely. I completely understand their motivations. I've re-invented wheels many times but, I tend to do it at home as a hobby. That's the appropriate venue for re-inventing wheels because nothing is at stake if/when you fail. In a business environment, you need a genuine business case for re-writing a piece of working software. "It's in COBOL" is not a valid reason to re-write it.
Token-ring on coax? Don't think so.
Looked like coaxial. May have been Type 1 shielded twisted pair cable. That was my first and last time I dealt with Token Ring in the field.
Sounds like "Wayland" :)
It's getting more and more of that hated X Windows "complexity" as the project matures.
That's all I have to say.
from-Slashdot-dev dept
Slashdot, fix the reply notifications... You won't get away with it...
Many banks also use cobol. Nothing to see here, move along. Side note: Note a big fan of using an extremely old, well established, yet un-maintained language (except by a small niche, don't believe what you read on wikipedia, most of the cobol code out there has existed for longer than the average north american lifespan,) I've dealt with it before, I've watched companies dump hundreds of thousands or millions into it...only to discover a bazillion security holes or performance issues in whatever product was being offered (ERP in the cases mentioned above)
Sounds like someone wants a big juicy contract to migrate a bunch of properly working Cobol code to something else. Probably something windows based with all the security holes that come with Windows.
If it's working, don't mess with it. I know other agencies that use Cobol running on Unix/Linux boxes. Works fine.
Department of Homeland Security Still Uses COBOL
So does your Bank ! So what?
"using COBOL" is different from "using compiled code which was originally written in COBOL."
Star Trek transporters are just 3d printers.
30+ years ago, I learned a little COBOL (thinking it would get my 15 year old ass a tiny bit of respect from the mainframers). I would never admit it IRL.
In college (decades ago) I listed the languages I could code in for a prof. It tailed off with me looking at the ground and mumbling 'cobol'. The professor noted at the time that everybody who can code in COBOL is embarrassed by that fact.
40+ years ago, I learned a little LISP (thinking it would get my 20 year old ass a tiny bit of respect from the cutting edge developers). 40+ years later, the folks who learned a little COBOL probably have a better chance of getting hired than the folks who learned a little LISP.
Star Trek transporters are just 3d printers.
If only Americans knew how much of their financial institutions still ran on COBOL, and the outrage that would ensue... ... but seriously, come on. These stories are nothing new, and they'll continue for decades. IT projects are always looked at with a sense of dollars - with band aids being particularly cheap.
Given the 20-28% failure rate of IT projects.... http://my.gartner.com/portal/s...
Star Trek transporters are just 3d printers.
Token-ring on coax? Don't think so.
Looked like coaxial. May have been Type 1 shielded twisted pair cable. That was my first and last time I dealt with Token Ring in the field.
You had token ring? Ha! You had it good! My generation had to deal with Tolkien Ring! On the other hand, it totally ruled. see also https://en.wikipedia.org/wiki/...
Star Trek transporters are just 3d printers.
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's not a simple matter of watching a Youtube video made by a 12 year old. The language itself is quite simple, it's the fifty years of legacy code that make it a nightmare to find new blood, and the few who can pull it off get to charge whatever they want. On paper, this becomes a steep liability, which is why departments are making the largely financial decision to migrate.
Problem is, governments are legendary at hiring the most incompetent, 7000% over budget, milk-the-cash-cow-dry kind of contractors. Whether it's due to corruption or ineptitude, it's true up here in Apologyland. It's true down there in Gunfreakland. It's probably true across the pond in Thataintfoodland.
Don't blame COBOL, that old dog has done us well for most of our lifetimes. Blame these idiots who can't manage their contractors, and the contractors who can't manage their idiots.
Indeed. An advantage of COBOL is that any shmuck with a minimum of general programming instruction and a good manual can maintain existing code; and it isn't likely to dig into the OS and do serious damage the way erroneous C code, for instance, might.
As you say, the problem is the ancient code with decades of patches of various quality applied and documentation mostly shredded. I've seen code written in "modern" languages within the previous few years which was unmaintainable, mostly because the original specs, if there ever were any, are lost in the mists of time. One particular such is burned into my mind to this day; the correct function of the program depended on a semicolon which should have been there being missing; when that error was fixed, the program always crashed. And it was of such structure that there was no way to despaghetti the code.
Star Trek transporters are just 3d printers.
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.
and don't forget, the modern manager. "I need to impress my superiors, tout suite. Hmm. I will take something old that works about 90% of the time and redo it. All the free industry management magazines are talking about _____ I will have the programming staff rewrite it in that."
months later: "I must whip the programmers harder"
Star Trek transporters are just 3d printers.
Can code from other languages be converted to COBOL automatically? Can someone write in C, Java or Basic, for that matters, and have it translated to a valid COBOL code via some translator? The younger languages should certainly have the power to cover the concepts available in COBOL?
Is this approach sensible? Does anyone use it nowadays?
...a stunned silence fell upon the hall.
Any decend coder should not have any real problems with learning COBOL, otherwise go flip some burgers.. Mostly it's due coders thinking languages like C# or JavaScript are the uber languages (as they don't know any other languare/framework)..