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.
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.
What's wrong with using COBOL? (Score:5, Insightful)
Re: What's wrong with using COBOL? (Score:5, Funny)
It's not webscale you see
Re: What's wrong with using COBOL? (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.
Re: (Score:3)
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.
Re: (Score:3)
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)
Everything new is web scale. [youtube.com]
Re: What's wrong with using COBOL? (Score:5, 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.
Re: (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.
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:3)
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.
Re: (Score:3)
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.
Re: (Score:2)
They pay real money for 8" floppies? Even used ones? I have one of those desktop floppy boxes full of them, left over from my PDP-11 days. Maybe I can boot up the old -11 and wipe a few...
Re: (Score:2)
I really hope that the floppies used for the Nuclear codes are not being purchased on eBay. This is one case where its OK for them to spend $100 for the $1 part so that it doesn't come with a virus.
Re: (Score:2)
Re: (Score:2)
Original CP/M machines that DOS was based on used 8" floppies. Back then was the days of autorun.bat because it was so convenient.
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:2)
I was at a government department that rebuilt a small utility from C to Java because all applications had to be Java as they were a Java shop. They had the original developer do the conversion and even he built the replacement wrong. It had to handle multiple customers and the replacement was built only able to handle with one customer hard coded in it. So not only was it documented, the code was available (I know since I had access to it), and the person with the domain knowledge was building it. When ask
Re: (Score:2)
Yes. Since almost all the NSA does is to manipulate strings, it is *THE* language for the job. They should be praised for using it.
String manipulation is why they use SNOWDEN, a variant of SNOBOL [wikipedia.org].
it's not what you say, it's how you say it. (Score:5, 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.
Re: (Score:3)
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.
Re: (Score:3)
Re: (Score:2)
There's something funny in there about COBOL surviving because it has object inheritance going for it.
Re: (Score:2)
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?
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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!
Re: (Score:2)
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
Re: (Score:2)
What's wrong with it? Global GOTOs.
Other than that COBOL does what it was designed for pretty well.
Re: What's wrong with using COBOL? (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.
Re: (Score:3)
Re: What's wrong with using COBOL? (Score:5, Interesting)
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.
COBOL programs running under MVS operating systems on MAINFRAME hardware doesn't imply old hardware - IBM is still releasing new mainframes every few years.
Re: (Score:2)
I wonder more about how old of hardware is it running on.
That is a separate issue. Cobol will run just fine on modern hardware. There are open source compilers available, and yes, it runs on Linux.
Years ago, I did some work with Cobol. It is easy to learn, and for the type of application described in TFA, it is fine. I wouldn't recommend Cobol for a new project, but if you have an existing code base, there is no particular reason to stop using it, or maintaining it.
Re: (Score:2)
Re: (Score:2)
Other posters have pointed out some ways to do this but I will mention virtualization. IBM created an OS called "VM" which stands for..... wait for it.... "Virtual Machine". In the 1970s .
Re: (Score:2)
I've often thought about it myself. I've monkeyed around with it a few times over the years. And really, it's just a language. Yes, there are is a certain kind of "primitiveness" to it, but then again, even K&R C is a pretty old language. But it strikes me that if the systems work, why spend the astronomical sums rewriting them, and then have to go through the lengthy process of working out the bugs. The one thing about a forty or fifty year old COBOL system, it's been through the ringer a lot of times.
Re: What's wrong with using COBOL? (Score:4, 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.
Re: (Score:2)
Re: (Score:2)
Your former teacher should join the ACM and read through the archives of the HOPL committee (History of Programming Languages)
sPh
Re: (Score:3)
"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
Re: (Score:2)
Re: (Score:2)
My consulting service can replace your mainframe, and the 3 coders who maintain it! You just need the space for 200 PC servers and 75 IT personnel. And my fee of course.
Re: (Score:2)
Non sequitur (Score:2)
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.
Re: (Score:2)
Yeah, and said younger banks have been getting cracked left and right over the last year, serving as the base for attacks on the SWIFT global payment clearing system.
sPh
Hey, that's me! (Score:4, Funny)
Re: (Score:3)
Re: (Score:2)
And making big bucks. ;)
Re: (Score:2)
Let's hear it for Fortran, COBOL, PL/1. I don't use them any longer but in their time, they got the job done.
If legacy code still works and is maintainable, there needs to be a good economic case for conversion, otherwise leave it alone. Sometimes an old language will only run on very old hardware, but that certainly isn't true for COBOL.
Converting to any of the "kewl" modern languages, just for the sake of getting away from COBOL, hardly makes sense, and you'll end up with something that is probably slower
Re: (Score:2)
And unsurprisingly, programs written last year in modern fashionable languages are probably broken already.
Discarding a language merely because it is old is stupid, but stupid is the modern fashion. We used to use computers to send people to the moon, now we use computers to broadcast pictures of our lunch.
Oh my God! an article that states the obvious (Score:2)
Re: (Score:2)
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
Solve what needs to be solved... (Score:2)
.
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.
Re: (Score:2)
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.
Re: (Score:3)
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.
Upcoming... (Score:5, Insightful)
(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".
Re: (Score:2)
Re: (Score:2)
Lots of places use COBOL (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:3)
Re: (Score:3)
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
Re: (Score:2)
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.
Re:Lots of places use COBOL (Score:5, 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.)
Re: (Score:2)
Great idea! Let's hope more people start doing that.
Staggering (Score:2, Informative)
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
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.
Re: (Score:2)
Sounds like "Wayland" :)
It's getting more and more of that hated X Windows "complexity" as the project matures.
Re: (Score:2)
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.
So what? (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.
Re: (Score:2)
Re: (Score:3)
Nah, I think they should upgrade to COBOL's object oriented successor. I believe it was called ADD 1 TO COBOL GIVING COBOL.
It's even worse than COBOL... (Score:2)
Javascript fanatics take notice... (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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
That sounds more like the problem is creating languages that aren't general purpose than anything else.
Re: (Score:2)
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
Re: (Score:3)
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 program
COBOL works (Score:3)
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.
Tires of this BS thread trend... (Score:3)
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.
Re: (Score:2)
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.
Blaming the wrong organization (Score:2)
"Still uses COBOL" is not the point (Score:2)
By the time the DHS was formed, COBOL was already obsolete. They should've never used it in the first place.
Re: (Score:3)
Since when is COBOL obsolete?
Migrations are costly and newer is not better (Score:5, 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"???
Re: (Score:2)
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
Re: (Score:2)
Op still uses Slashdot. (Score:3)
Probably migrating due to lack of available coders (Score:2)
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 still using incandescent bulbs (Score:2)
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
And your average puppy (Score:2)
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.
Nobody making money here (Score:2)
Of course it would be slower, lacking features, years late and way over budget, same as any other modern government software programme
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
or even "sort" from a command line) is not portable.
Yeah it is: it's in the POSIX spec, so if you're on a POSIX compatible system it'll work which is precisely equivalent to saying "any system that has a COBOL compiler". Not that it's not good, but overselling it, or rather underselling the competition, detracts from the point you're trying to make.
Re: (Score:2)
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.