Attributing these problems to COBOL is short sighted. While COBOL is obsolete for good reasons, it does provide high performance and makes it relatively easy to

Attributing these problems to COBOL is short sighted. While COBOL is obsolete for good reasons, it does provide high performance and makes it relatively easy to construct new batch-processing tasks quickly, due to its built-in data model (a concept which is largely absent from modern programming languages but does pop up from time to time in forms like MS LINQ - historically it was far more common, see also MUMPS). Because COBOL applications run predominantly in batch-mode they are also fairly robust and easy to troubleshoot compared to many modern systems, isolating a problem being a matter of running the batch jobs individually and finding the bad intermediary state, and recovering from a failure being a matter of just restarting the job. Intermediate state is almost always persisted to storage so it's easy to work back to where the problem occurred, unlike in e.g. a microservice architecture where doing so can require a dedicated tracing system and still be quite difficult. Consider that we could write a headline like "Amazon runs on a 50-year-old operating system, and now it's falling apart." The sentence is not entirely untrue but rather misses the point. The problem is this: these systems are old and, more significantly, have received extremely limited maintenance and enhancement over their lifetimes. This means that there are few people familiar with each system (a "bus factor" problem) and, more broadly, that the talent-base of COBOL programmers has been allowed to recede to near-zero. While a common modernization (or "recapitalization," a term preferred in government contracting) route in the tech industry might be to take a legacy system written in e.g. Java and progressively reimplement it in e.g. Python with a simplified architecture, a common recap route in government is to take a legacy system written in COBOL or s/370 assembly and transition it to an s/370 emulator running on HPUX on NonStop. I've been involved in such processes a couple of times. It has the advantage of maintaining the reliability properties of the legacy system at relatively low-cost since very little software work is involved. It has the tremendous disadvantage of allowing the organization to continue to not touch the software, with much of the work often outsourced to a vendor who need not be very familiar with the codebase either You certainly wouldn't write anything in COBOL in 2020, but COBOL itself does have a robust and even fairly maintainable design. The problem is that any application written 20 years ago or more, regardless of language, is going to be tremendously difficult to modify to meet changing requirements and increased demand. Unemployment insurance applications reaching six million per week, for example, would strain a system designed using the most modern methodology which was specified for a few hundred thousand. The difference is that, with a newer system, there are likely to be in-house engineers or vendors who are very familiar with the system and will be able to expand its capacity more rapidly. Another underlying problem is that legacy systems designed using a mainframe methodology are intended for vertical scaling - to process more records you buy a bigger machine (or expand the LPAR or what have you). While horizontal scaling has its own disadvantages there's a reason it's so popular today - it's a lot faster to buy more capacity from a cloud provider than to requisition a larger mainframe^w midcomputer^w emulation host. There are few vendors and government acquisitions are slow at the best of times, even under emergency sole-source rules. In a way the whole thing is ironic, because a lot of COBOL application interfaces are faster than any software we use today. From the perspective of a human operator they can be absolutely outstanding once you get over a learning curve. However, the lack of any enhancements made to these systems mean that requirements changes are often "patched in peopleware" if you will, and you end up with clerks that can enter data an order of magnitude more efficiently than with a likely modern solution, but they then have to send the records to a virtual printer to be ingested into a Java EE solution... this kind of "enterprise patching" rapidly adds up to an extremely inefficient system.