COBOLing Together Unemployment Insurance Benefits: How Delays in Fiscal Stabilizers Impact Aggregate Consumption (ssrn.com) 116
Abstract of a paper written by Michael Navarrete of University of Maryland: The United States experienced an unprecedented increase in unemployment insurance (UI) claims starting in March 2020, mainly due to layoffs caused by COVID-19. State unemployment insurance systems were inadequately prepared to process these claims. Those states using an antiquated programming language, COBOL, to process UI claims experienced longer delays in benefit disbursement. Using daily card consumption data from Affinity Solutions, I employ a two-way fixed effects estimator to measure the causal impact of COBOL-induced delays in UI benefits on aggregate consumption. The delays caused a 4.4 percentage point relative decline in total card consumption in COBOL states relative to non-COBOL states. Performing a back-of-the-envelope calculation using 2019 data, I find that real GDP declined by $181 billion (in 2012 dollars).
COBOL isn't a delay (Score:5, Insightful)
COBOL may be antiquated in age but it is not outdated or archaic. It still works. Next up is someone going to whine that we're still using wheels which were invented in the stone age?
What will break things is if some misguided fool decides to convert all that legacy COBOL into Python and then there are years of delays trying to do the porting. The only delay with the current method is with having programmers who understand COBOL, and those are out there and well paid. And to learn COBOL? What self respecting programmer would say "I can't learn anything new, this programming stuff is hard!!"
I'm tired of the lame thinking of "it's antiquated" without any evidence being provided that this is a bad thing.
Re:COBOL isn't a delay (Score:4)
Re: (Score:3)
In the paper, the author pretty much admits that he's using "COBOL states" as a proxy for representing poorly-functioning departments. Essentially, the correlation is logical: if the state is still using COBOL, there's a high likelihood that it's also running on ancient hardware, whose systems may not have been modernized for many decades. Naturally, a department like this is likely to be less efficient at processing claims than a well-run and more modernized department, which are likely better funded.
Re: (Score:2)
This is simple math. How much hardware do you need? It's probably IBM based and running on modern hardware.
Re: (Score:3)
Exactly WHAT makes you think that 'using COBOL' equates to 'ancient hardware not updated in many decades'? Are you completely oblivious to the fact that many organizations are still using COBOL because the same programs keep working even though the hardware is continually upgraded?
Re: (Score:3)
I'm well aware of that fact. But I figure, simply by nature of it's probable age (new systems are not likely to be written in COBOL), a COBOL-based system is MORE LIKELY to be running on old hardware. Newer systems tend to be written in more modern languages, and would have been placed on more modern hardware.
It's really nothing more than noting that COBOL is a pretty old language and waning language, and extrapolating probabilities from there. Feel free to read the paper and find holes to poke in the au
Re:COBOL isn't a delay (Score:4)
I see nothing in the paper that indicates old hardware. But lets assume the bottleneck is actually hardware performance, and these systems are running on mainframes. What you have to understand about mainframes is that both hardware and software is priced by performance. For this reason, mainframes are offered in a WIDE variety of configurations. For instance, the Z15 is the most recent generation of IBM mainframes. It is available in hundreds of performance configurations, with the fastest machine having almost 1800 times the performance of the slowest. Customers with a fairly steady usage of their machines can therefore select a configuration that closely matches their normal requirements. This is the most cost-efficient choice.
However, what happens when a sudden, possibly unexpected, peak happens? The solution to this is called On/Off Capacity on Demand. The customer can purchase additional capacity instantly, and the additional resources are added to the system while it is running. He can then remove those additional resources when they are no longer required. Of course, this does cost money. So it is likely that the 'cause' of this problem has nothing to do with either COBOL or 'ancient' hardware, but is simply bureaucratic processes and budgetary concerns in getting the approval to add the required capacity.
Re: (Score:2)
There comes a point when running big IBM hardware - minis and mainframes - where annual maintenance starts to cost more than upgrading the hardware.
If companies or govt departments are running seriously outdated hardware, then they're not looking at the costs.
Re: (Score:2)
Please explain your belief that COBOL means IBM and that IBM means old hardware.
Re: (Score:2)
I believe neither of those things.
I was trying make the point that *old* IBM stuff like CISC AS400s and pre-Z-series mainframes probably cost a lot more to maintain, than it would cost to upgrade.
I'm fully aware that Z-series mainframes are modern, as are POWER systems running IBM i (the current name for OS400).
And COBOL runs on many platforms. Even Windows PCs.
Re: (Score:2)
Essentially, the correlation is logical: if the state is still using COBOL, there's a high likelihood that it's also running on ancient hardware, whose systems may not have been modernized for many decades.
I'm curious - does the California Unemployment system use COBOL? I bet they don't... Then again, California had $11BN in Fraudulent Unemployment Claims and $29BN in questionable unemployment claims [msn.com] so those scamming the system didn't have to wait so long for their ill-gotten-booty.
That's good, I guess.
IBM will do COBOL for $$$$$! (Score:2)
IBM will do COBOL for Big $$$!
Re: (Score:2)
"COBOL" is still around because we had no meaningful alternatives for along time
Re: (Score:2)
Very much THIS. Any organization, state government or otherwise, that willfully allows their systems infrastructure to stagnate for decades, has very little room for complaint about throughput performance or when they have difficulties hiring new code maintainers and system operators.
Today's IT world does not run on PDP-11's, and for many good reasons. Modern IT will always be iterating onto the next thing, nonstop. At this point, it is built into the nature of the beast. If you don't like that fact, I reco
Re: (Score:2)
This is it right here. Languages are rarely *the problem*. Yet, they are an indication of the overall system.
It may not be ideal, but projects in large organizations tend to dictate things. They spend a lot of money on a project in the 80s. That system works. They don't really touch it. Maybe by the time the 2000s come, there's demand to make it web accessible. That's gets another round of funding... Sometimes they just plunk a modern web front in front of the legacy system because they don't want to touch
Re: (Score:2)
I'm tired of the lame thinking of "it's antiquated" without any evidence being provided that this is a bad thing.
It's antiquated, and based on Michael Navarrete's LinkedIn profile it's been running for more than twice his lifespan.
If this stuff was easy to move it would have moved my now. But it's not.
Re:COBOL isn't a delay (Score:4, Insightful)
Also, try to spend the money to upgrade it and you'll be accused of wasting the taxpayer's money on a boondoggle.
Re: (Score:2)
Also, try to spend the money to upgrade it and you'll be accused of wasting the taxpayer's money on a boondoggle.
If the upgrade program is run with the usual meddling, bumbling incompetence of such efforts, it will legitimately be a boondoggle. Such migrations are hard to do well, as numerous carcasses of failed attempts littered across the landscape can attest.
Re: (Score:2)
Don't blame government alone on this. Plenty of commercial entities love to suckle at the government teat and will intentionally overcharge and overcomplicate things. Ie, Cisco, IBM, etc.
By design (Score:2)
Absolutely companies charge the government more - a lot more. Sometimes orders of magnitude more. That actually means the system is work as designed. It's what we're aiming for.
Partly, this is because the government requires a thousand pages of BS to get the contract. There's often over $100,000 worth of time spent just to get the contract. If you get the contract, after having spent the time/money. And that's not entirely a bad thing.
Government in US is supposed to be fair, accountable, transparent, etc.
Re: (Score:2)
By government, I mean at any level. These companies will cheat even school boards in small towns.
Re: (Score:2)
Absolutely companies charge the government more - a lot more. Sometimes orders of magnitude more. That actually means the system is work as designed. It's what we're aiming for.
Remember the Obamacare Website fiasco? Probe exposes flaws behind HealthCare.gov rollout [apnews.com]
Re: (Score:2)
Also, try to spend the money to upgrade it and you'll be accused of wasting the taxpayer's money on a boondoggle.
From 2015: Is This FAA Program The Worst Bureaucratic Boondoggle Ever? [dailycaller.com]
Re:COBOL isn't a delay (Score:5, Interesting)
Re: (Score:2)
If this stuff was easy to move it would have moved my now. But it's not.
Complete nonsense.
COBOL uses decimal math. No special handling is needed to keep it from screwing up financial calculations.
It is also compiled, and efficient. And really good at generating "reports," which includes for example XML data, or SQL statements.
The big part of the cost is that none of the replacements are actually as good at financial tasks, even if they have less boilerplate.
Re:COBOL isn't a delay (Score:4, Insightful)
Re: (Score:2)
Re: (Score:3)
Naw, those COBOL programmers are already on staff. They have to be because every year there is some tweak to financial rules, unemployment rules, or other change that needs to be incorporated. Programming for this sort of stuff is like being a mortician - there is always work to be done.
More likely the machines aren't keeping up, throughput problems on databases, etc. Now it's possible that such older systems are also inherently linear in their data processing and are getting overwhelmed, but that's not
Re: (Score:2)
I can't imagine a workload so large that it would "slow down" processing of unemployment claims.
California recently reported it suspected it paid $20BN in fraudulent unemployment claims during the Pandemic - I suspect their unemployment system is based on glorious graphical user interfaces, fabulous layers of data abstraction, and runs on the latest model x86 server with a mind-numbing array of CPU cores - but their "efficient" system "blew" an estimated $20BN in 18 months. (There are 39.5 Million people in
Re:COBOL isn't a delay (Score:4, Interesting)
with COBOL systems, the hard part is finding people who can do the modifications
No, the hard part is finding HR personnel willing to hire people to modify COBOL systems. The ones they have say, "well, COBOL has been around for 100 years so we want at least 30 years of experience." But most people with 30 years of experience don't write code, they're either VPs, or parked wherever the Peter Principle landed them in lower management. And if they do write code, they're as nearly as expensive as a VP, because that's the job keep turning down.
The reality is that old languages will not have lots of programmers with recent experience in the language, but that tells you nothing about if competent programmers are available to write the code.
Re:COBOL isn't a delay (Score:5, Insightful)
COBOL may be antiquated in age but it is not outdated or archaic. It still works.
COBOL is often a bogeyman for people who want to sound cool but don't actually understand how computing works.
Re: (Score:2)
Being a bogeyman in and of itself is a liability, even if not well justified.
It's a tall order to find people willing to update a COBOL solution when 99% of developers know of it only by reputation as a bogeyman.
But COBOL is awfully verbose. It's workable but kind of tedious to work in. I don't blame even an informed person from shying away from COBOL work when they can.
Re: (Score:2)
If the task involves filling templates (SQL statements) with the output of decimal math, the COBOL is often less verbose than the C or Java would be. And more straightforward.
Re: (Score:2)
FTFY.
While it is perfectly possible to write awful COBOL which no one could understand, there is no way it would pass any kind of peer review (People shouting "WTF?" in meetings is very embarrassing).
OTOH, Java that makes no sense can easily be self-obfuscating.
Also, few C (C++) programmers seem to know how to use macros to make code readable these days.
Re: (Score:3)
Very true.
I never understood the reputation. COBOL is very well-designed, certain modern additions notwithstanding. If I were asked to redesign COBOL, I wouldn't change very much.
Part of what made the design good was how easy it was to use. It's simple enough that we were still teaching the language to business majors into the 2000's. COBOL code is designed to be highly readable, and it shows. Working with well-written COBOL feels almost effortless. It also protects the under-qualified from doing stu
Re: (Score:2)
Although most universities wouldn't want to lower themselves to teaching technical/trade school material, I think most computer science programs should have a mandatory 200-level course with a name something like Maintaining legacy applications.
I know this is already too real-world for most university faculty to stomach, but yes Virginia, its true that you're not always the one turning 'Hello World' into a major corporate application. And most companies are not sanguine about rewriting a major application j
Re: (Score:2)
I never understood the reputation. COBOL is very well-designed, certain modern additions notwithstanding.
Kind of: it was certainly well designed for the time. What makes a good language in 1960 isn't the same as what makes a good language today. The COBOL of 1960 does not make a well designed language today. That's fine of course because COBOL has many additions that learn from at least some of the last 60 years.
However, you might still find 60 year old code written in the styles and practices of 60 years a
Re: (Score:3)
I think one fallacy that is often seen in computing is that newer is definitely not better in many instances. Code is code, algorithms are algorithms. Replacing some code in COBOL with Javascript doesn't mean that the new stuff will be better. It just means that some developer or their company is getting their pockets lined to reinvent a wheel... one perhaps that was more than good enough, and the replacement will definitely consume far more resources, require more libraries (which means easier supply ch
You must be (Score:2)
new to Slashdot.
Re: (Score:2)
Replacing some code in COBOL with Javascript doesn't mean that the new stuff will be better.
Anybody selecting Javascript for any purpose that isn't a browser has already failed to select the correct tool for the job. Javascript's mathematical behavior in particular is atrocious. Likewise so is its performance. COBOL co-evolved with the hardware it ran on. IBM's mainframes were the next best thing to COBOL processors, for many years. Anyone attempting to replace COBOL who doesn't select a similarly performant language has also already failed. For that matter, anyone who doesn't create a data-
Re: (Score:3)
COBOL is not a fun language and it does not run in fun environments. It is not used to do fun things, so learning it in this day and age suggests a career path many do not want. Many believe that even putting it on your resume under "other skills" can get you passed over anywhere that doesn't have a burning need for COBOL programmers. That means the few that do will likely command salaries that under-funded state IT departments aren't prepared to pay.
That doesn't make old software written in COBOL bad, just
Re: (Score:2)
The problem with COBOL is that COBOL jobs don't pay very well. I would be happy to program in COBOL, but that is what I found when I looked into such jobs.
Replacing things with Javascript won't make a bit of improvement, because the Javascript programmers won't be paid well, either. It's just going to be some bad code in a different language.
Re: (Score:3)
It's an old story in many professions "Pay peanuts, get monkeys". Management often seems impervious to that truth.
Re: (Score:2)
That doesn't make old software written in COBOL bad, just expensive to update.
Though my limited experience of legacy code is FORTRAN rather than COBOL, it appears that these older languages could encourage bad coding style, due to lack of encapsulation. Algol, and then C, encouraged using functions to encapsulate sequences of operations, using data with limited scope or visibility. I understand some FORTRAN, still in use today, is serious spaghetti code. It works well, but because it was designed by mathematicians, definitely a case of "here be dragons".
Re: (Score:2)
A lot of old FORTRAN code brings it's own problem set. Much of it is impossible to prove correct, so instead it has been compared to actual outcomes and to the output of other FORTRAN programs for years and found to be sufficiently accurate when compiled with the right compiler with the right optimization settings. Much of it was written by grad students whose primary interest was physical sciences rather than CS.
Re: (Score:2)
Much of it was written by grad students whose primary interest was physical sciences rather than CS.
I get the impression that Computing Science was a very specialist subject when this legacy FORTRAN code was written. People just made stuff that got the right results at far higher speed than hand calculations. That was considered to be a considerable achievement in itself. When programmes were not too big, because of hardware limitations, I suppose you could get away with spaghetti code.
Much of it is impossible to prove correct
You could say that about a great deal of software written in modern computer languages. I still verify computations again
Re: (Score:2)
That is true. At that time, CS was not typically offered as a major. Most programmers that even had a degree were EEs. Very few principles of maintainability or design existed yet.
It's also true that even the most modern code written to best practices may operate flawlessly and as specified to produce the wrong answer.
Re: (Score:2)
Re: (Score:3)
It has a handful of major problems.
1) It's expensive as hell to learn.
2) Universities don't teach it anymor
Re: (Score:2)
I'm having a hard time with these two statements of yours:
I actually, for person entertainment learned basic mainframe programming. It took a few hours
and
1) It's expensive as hell to learn.
Technical schools used to take in people with no computer experience and churn out Mainframe Assembler and COBOL programmers with sufficient skills to draw a paycheck and support their family in six months. I don't understand why it would take longer to accomplish the same thing today.
Re: (Score:2)
Re: (Score:2)
I wonder if the reason that "COBOL states" are slower to process UI is that they've cheaped out for years and are using horrendously outdated computing hardware that's far slower than most of would tolerate. Put that "legacy" COBOL on a modern bit of hardware and I suspect many of those "COBOL states" wouldn't have these slow UI processing times.
Re: COBOL isn't a delay (Score:2)
Back in the 90s, I saw a news report on an air traffic control system which was running on a very outdated mainframe.
"Just take a look at this old computer. It's got less memory than a laptop! In fact it's so old they can't find parts for it anymore." (IIRC) said the reporter.
If a system that lives depend on can be allowed to lapse like this, then I am sure some 1992 era 486 held together with chicken wire and duct tape and other zombified trash are still being used in some state offices.
Re: (Score:2)
> Next up is someone going to whine that we're still using wheels which were invented in the stone age?
I mean, if somebody tried to put hand carved stone wheels on my car I would whine.
Personally I dislike the - all languages can be used to write good or bad code mentality.
Aren't languages code? Can't a language itself be bad code?
> What self respecting programmer would say "I can't learn anything new, this programming stuff is hard!!"
Very few, but many would say - I don't want to learn something old
Re: (Score:2)
Sure, a language itself can be bad. For example, Javascript. COBOL may not have modern features but it's not stuck in the 60s either. It has real design goals and was never anyone's personal project or intended for just a particular application. That is, the primary design goal is that the managers and vested interests who are not experts in programming can understand what the code is trying to do.
Re: (Score:2)
And yes, that does imply that, if you as a skilled and experienced programmer can't figure out what (a) the the program is supposed to do, and (b) what it actually does, then you should attend the nearest hospital for a brain check (no, not a rain check - that is something else).
I agree that there are quite a number of modern features that would make
Cause vs Effect (Score:2)
I skimmed the paper, and yes: the author believe that COBOL was the limiting factor here.
Not one mention, though, on the underlying IT infrastructure. A big COBOL system running on a mainframe will hit a limit at some point, and simply bottlenecks in I/O or something. The self-same system, running in a scalable cloud infrastructure, can have additional resources thrown at it to push it over the hump (and yes, COBOL on Azure is a thing [microfocus.com].
Re: (Score:2)
I skimmed the paper, and yes: the author believe that COBOL was the limiting factor here.
Not one mention, though, on the underlying IT infrastructure. A big COBOL system running on a mainframe will hit a limit at some point, and simply bottlenecks in I/O or something. The self-same system, running in a scalable cloud infrastructure, can have additional resources thrown at it to push it over the hump (and yes, COBOL on Azure is a thing [microfocus.com].
I suspect that at least some of the agencies in question are also using hardware of the same generation. I live in Missouri, where incompetent state IT is a feature and people who point it out are denounced as hackers.
Re: (Score:2)
And if the 'researcher' didn't control for hardware (or for procedures), then there's no real "scientific experiment" that would isolate COBOL as the cause of the problem.
(Scaling is hard, INDEPENDENT of programming language.)
Re: (Score:2)
Re: (Score:2)
Your point is correct, but
(Scaling is hard, INDEPENDENT of programming language.)
Batch processing is embarrassingly parallelizeable. There are no shared resources (ie, variables/data) and no dependencies between tasks, so you don't need locks. Just spin up a bunch of threads and plow through the task.
Re: (Score:2)
Not necessarily true! You have to implement transactions, requiring you to set up the appropriate DBMS schema and locking.
I agree that batch processing tends to be much easier to serialize. But setting up a transactional system that can handle 'transactions at scale' is still a tough job.
Re: Cause vs Effect (Score:5, Insightful)
COBOL running on a mainframe is precisely designed for MASSIVE amounts of batch data processing, which, I suspect, is exactly what it is doing when processing UI claims.
IT IS HIGHLY unlikely that the COBOL language is responsible for processing delays.
Re: (Score:2)
Re: (Score:3)
That is everywhere. It may not be COBOL, but I've seen mountains of steaming, rotten JavaScript, C#, Python, Java, and other mainstream languages which were often deliberately obfuscated, so the developer writing it won't have their job outsourced/offshored.
Programming languages matter less than the quality of code.
Re: (Score:2)
Re: (Score:2)
I was surprised how many 20-somethings are in the field doing COBOL stuff at a previous job I had which still used a core mainframe. There is still a ton of mainframe stuff out there. It isn't mainstream, but it is a definite niche, and there is something to be said about having a position that can't really be offshored or outsourced.
Re: (Score:2)
It's a system that deals with other people's money. You NEVER want to just hire anyone!
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The contention seems to be that computers are somehow bias by the programs being written in a language that is no longer in fashion. That is preposterous. Correlation != causation.
Re: (Score:2)
It's like the Waffle House Index. Sure, directly it may not seem a sane thing, but it is a decent approximation of those various cited potential issues.
Re: (Score:2)
Despite the fact that most here know COBOL to be an widely-used language in legacy computing that almost nobody knows anymore
Fixed that for you.
legacy computing = government computing, business processes, old scientific.
Re: (Score:2)
If there is widescale new COBOL implementation in government computing, business process, or scientific that would surprise me. Granted it wouldn't be the first time I've been surprised.
Re: (Score:2)
The fact that you think a mainframe will hit 'an I/O bottleneck ot something' processing some unemployment claims leads to the conclusion you know absolutely nothing about mainframes or the environments they are used in.
The fact that you think 'the self-same system' could be run in a scalable cloud means you probably don't have any experience doing that. You think you can just take a COBOL program (which no doubt uses middleware like CICS and maybe IMS) and move it to the cloud? You think you can 'scale'
Re: Cause vs Effect (Score:3)
Perfect response. Mainframes are designed with I/O in mind. COBOL codes stand the test of time. And, mainframes handle large batch jobs very wellâ¦far better than most modern day systems.
I suspect the bigger issue are the front end systems that have to integrate with the mainframe systems. I suspect they were getting overwhelmed and the mainframe wasnâ(TM)t clearing the queue fast enough. So, they blame the mainframe and COBOL.
IBM and other mainframe vendors ensure backwards compatibilit
Re: (Score:2)
Ever heard of "capacity on demand"? You buy/lease a mainframe with capacity that exceeds your day-to-day needs. Processor, memory, I/O, storage, whatever.
You pay for the capacity used by your day-to-day operations.
Experiencing a surge? Call your sales rep and authorise additional capacity. IBM flips a switch (I don't know exactly how it's done but they probably connect and authorise using a software key) and suddenly your system is handling the surge. When things return to normal, the extra capacity is swit
Re: (Score:2)
A big COBOL system running on a mainframe will hit a limit at some point, and simply bottlenecks in I/O or something. The self-same system, running in a scalable cloud infrastructure, can have additional resources thrown at it to push it over the hump (and yes, COBOL on Azure is a thing [microfocus.com].
Bullshit.
You literally have no idea what the I/O capacity of a mainframe is - mainframes are built for phenomenal throughput, for example, processing countless phone call records, credit card transactions, and so on. The ability to "spin up" more resources "in the cloud" is cute, but it is no replacement for the I/O capacity of any recent vintage mainframe.
He is an economist (Score:2)
Re: He is an economist (Score:2)
Economists opining on programming languages.
Physicians issuing edicts on allowable economic activity.
What's next? Code monkeys performing brain surgery on economists?
Re: (Score:2)
Politicians offering medical advice about vaccinations.
Don't hire programmers based on Programming Langs. (Score:2)
I often see a lot of job requirements that put the Language you want the programmers to program in, also it is common and expected in your resume to list the languages that you have experience in.
I don't think this is an effect of a fault in the COBOL programming language (as I would expect a lot of new coders when exposed to COBOL, may be surprised how suited for its job it actually is) But a factor that you are hiring Existing COBOL coders, who know they cannot be replaced, so their career for the past 3
Re: (Score:2)
So they may have a fancy Web UI for fast filling out forms, but then have someone sit down and copy and paste what the webpage has into the terminal of the COBOL program to process further. Where if they worked together, the Web Team may be able to generate a fixed space flat file that they COBOL coders can import and process very easily and quickly.
Are you kidding?
Is there a reason the mythical "web team" couldn't write a "fancy web UI" that populates a relational database the mainframe can read?
Re: (Score:2)
The reason is ME - The COBOL programmer.
The data the Web team delivers will almost certainly be inadequately validated, if not plain wrong. I want it to pass MY WELL-TESTED validation suite (with at least 10 years of bug fixes) before it gets into the database.
The most important part of the article (Score:5, Informative)
However, anecdotal evidence suggests that COBOL states have struggled more to process initial claims, Longer delays in filing could be a result of the state UI website being down, call centers being overwhelmed, or claimants having to go in person to their local UI office. Even controlling for historical recipiency rates and benefit amounts, COBOL states could discourage eligible claimants from filing their initial claim because of the additional time costs. I cannot disentangle the contribution of these mechanisms to the effect that I find on aggregate consumption.
He uses COBOL in the title but in the article he slips in that he has no idea what the problem was.
How well can the old code cope with new rules? (Score:2)
How well can the old code cope with new rules?
Like the old code base works well if the state rules as is but the new COVID-19 rules add an lot of overrides to the old the rules that are not really that easy to code in?
Re: (Score:2)
How well can the old code cope with new rules?
Like the old code base works well if the state rules as is but the new COVID-19 rules add an lot of overrides to the old the rules that are not really that easy to code in?
The code has been tweaked for what, 50 years now? Why suddenly fall over now?
Re: (Score:2)
Yes this is true, and has always been true with programming for data processing - it always needs updating, each and every year. You need full time programers for this stuff. I remember back at a defense contractor int he 80s that their HR and payroll stuff (all of it was in-house in those days) was largely written in Fortran (ha!) and had a full staff of dozens to maintain it and tweak it based on very precise specifications and requirements.
Re: (Score:2)
What about the "new rules" are beyond the capabilities of a modern mainframe, DB/2, and COBOL?
The logic of the unemployment system is frighteningly simple, the bulk of it could be distilled down to a single one-page document.
Re: (Score:2)
If written in a clear and unambiguous language - like COBOL.
However its far more likely to be delivered as 10 pages of ambiguous waffle written by political aides, needing weeks of "clarification", which the programmer has to disambiguate without offending his paymasters. (Which is the real art of COBOL programming).
I wonder how many were fraud submissions? (Score:2)
Delays (Score:2)
Re: (Score:2)
The vast majority of unemployment claims are filed on-line by the claimants, and those that cannot be filed by the claimant are completed in-person by UI staff.
Not sure a delay in in-person claims can be blamed on the programming language that drives the batch processing system, COBOL.
Re: (Score:2)
I suspect a lot of delays were simply bureaucratic and had nothing to do with computers.
In the UK, GP surgeries still tend to get behind with the basic admin, due to the massive impact of dealing with Covid-19. I allow at least an extra day to get my prescription authorised. Good luck trying to get an appointment with a doctor. You maybe get a phone consultation. They are simply snowed under with all the patients coming back with their usual problems, after holding off during lockdown.
I have no idea what software my GP surgery us using, or the local hospital for that matter. I don't suppose it
Compiled cobol isn't horrible (Score:2)
It isn't great, sure, and Cobol compilers haven't exactly had a lot done to them. Neither have PL/I compilers (which cost a fortune, btw). But I wouldn't have expected such a large drop. Unless, of course, they can't recompile their code (didn't renew the license after Y2K, used Cobol extensions that don't work on newer compilers, etc).
Given the amount lost, buying a second mainframe and using one to add/delete entries, the other to print checks, would still be cheaper than the losses.
Not that I have a grea
Re: (Score:2)
after I got a fine for not attending a session on how to succeed at job interviews
What lol. That sounds like a great/hilarious story.
Cobol is a compiled language (Score:2)
... therefore, it's machine-native executable code that is executing at run-time. What language it was compiled from (Cobol, Fortrans, RPG...) matters very little, other than minor differences in runtime library performance. Put another way, the power of a car's engine (processor, memory, storage) matters far more than its paint color (Cobol, Fortran, RPG).
Re: (Score:2)
That is a real thing, but it doesn't explain the UI delays in California.
Re: (Score:2)
Please define "antiquated unemployment insurance systems" - what is it about processing unemployment claims that would benefit from being written in a more popular language, on "modern" architecture hardware? COBOL, DB/2, and any fairly recent vintage mainframe is more than capable to process unemployment benefits for any state.
The CA Unemployment system, while a democrat-run state with likely very "up-to-date" systems, paid out an estimated $20BN in fraudulent unemployment insurance claims during the pande
Re: (Score:2)
You could see that most republican led states have fewer public services compared to non-republican led states.
Citation?