I Told You So - 8 March 2025

Well... this is one of those "take a victory lap" reveals. Many's the time, during the MAGAnaut assault, that these missives have said that the DOGEmorons are messing with compute tech they have no idea about. It might as well be in Zulu. It's the wonder of COBOL. Now, there's nothing inherently wrong with COBOL, esp. for an organization like Social Security Administration. It's the sort of application that COBOL was designed for.

While I was a worker bee at CSC (where I took the job because I was told "we're going to be doing heavyweight database development"), the job, it turned out was putting a pretty face on ancient (70s vintage) COBOL code. This process is widely known as 'putting lipstick on a pig'. I suspect the phrase originated in computer. Let's go see... Well, one source says it was baseball. Which is chronologically before the GUI problem. Close enough.

So, now we have the DOGE intent on breaking SS. Of course they are. Dropping multiple wrenches into the computers which run SS is a plausible deniable method of destroying SS. Which is the point, of course.

"This system needs a lot of maintenance, and the concern is that if they're not careful with their firing — and they're obviously not — these people who are experts in COBOL tend to be retirement age," said Nancy Altman, president of Social Security Works, an advocacy group.

You're not likely to be able to run SS on webservers running java, or even C++. The best hope is to keep the COBOL and leverage the relational power of z/OS DB2 (most likely what's available on the IBM Big Iron). Now, here's the real kick in the balls. While at CSC, when it tried, with shitty results, to both put webGUI lipstick on its pig COBOL by creating a java applet front end (the aforesaid lipstick), it also attempted to transition from the original VSAM files for the COBOL code to z/OS DB2. That was an even bigger clusterfuck: the clients got the worst of all worlds - the overhead of database transaction control coupled with the olde fashioned bespoke transaction monitoring in their COBOL and a bit of secret sauce from CICS. SS is likely in that situation, and likely for a couple of decades, if not more.

So, let's send some PHP kiddies over there to fix the problem. At least CSC had the sense to bring in a brigade of Indian Freshers to maintain the COBOL. Oh, and one client demurred from the 'upgrade' to GUI and DB2. They've been running just fine.

"Right now, they're driving these people that understand the IT architecture, understand how things are connected, understand how things work — and they're driving them out of the agency as quickly as they can, with absolutely zero transfer of knowledge," he said. "We looked at attrition as the fire breathing dragon at the gate that needed to be defended against. These guys think it's a fire upon which to douse kerosene and to give people incentives to leave."

And, of course, the reason it all got this way

The computer system is old enough that its monochromatic green screen upon loading says "welcome to the future" — an irony given the age of the technology.

"There had been talk about removing it, because it seems so ridiculous, but that would have cost money and required more staff that they didn't have," O'Malley said. "So they've never done that."

Neither java nor C++ is an easy replacement language for COBOL logic. They just aren't, which is why most of American Big Bidnezz still runs on COBOL. With webGUI lipstick. The further irony: back some years ago, xml stormed on to the scene, and the PHP and javacript kiddies decided that it would make for really new, modern, and cool database stores. Dumber than a sack of hair. xml as datastore is just a clear text implementation of the hierarchical 'database' IMS from IBM before DB2. At least VSAM fit nicely with COBOL.

And, yes, there are myriad COBOL to C/C++ converters/translators on the market. In general, the result is mixed, and not just a push-the-damn-button process.