If you’ve been anywhere near a news site in the last month, you know that Elon Musk and his army of teenage coders are rampaging through Federal IT systems looking for waste.  It’s axiomatic that there is some waste in any large system the size of the Federal government.  How wide-spread it is, how it should be identified, how it should be trimmed, etc. are largely political questions we won’t go into here.

But one thing that is noteworthy is the table to the right.  It purports to be stats on people who are receiving Social Security benefits.  Looking at it, it appears millions of people aged 120+ are drawing checks, and that can only be due to incompetence on the part of the Social Security Administration, combined with fraud on the beneficiaries’ part…right?

Elon tweeted about this:

According to the Social Security database, these are the numbers of people in each age bucket with the death field set to FALSE!

There’s another possibility: Musk’s fleet of boy geniuses have never worked with COBOL before.

Ye Olde Database

The Federal government has plenty of systems that go back to the dawn of computing.  When you hear people talk about millions of lines of COBOL code still in use, a huge percentage of that is Federal and state government systems.  The mainframe is alive and well in Washington, D.C. and while no one would start a new greenfield project using that platform and its associated technologies in 2025, these systems continue to work.  “If it ain’t broke” applies aptly to complex IT systems which have had decades of bugs shaken out of them and are very well understood.

Not long after Y2K (which involved fixing tons of COBOL code), ISO 8601:2004 was released.  It codified conventions that had already existed, and used May 20, 1875 as its zero point (epoch).  In other words, all dates count from 1875.

The Epoch

May 20, 1875 may seem a strange zero point, but every system has them:

• Linux/Unix’s “epoch” is  January 1, 1970.  Internally, it tracks “seconds since the epoch” (1,740,088,474) as of this writing.
• In .NET, it’s January 1, 1 A.D.
• UUID version 1 uses 15 October 1582, which is the date of the Gregorian reform of the calendar.
• MUMPS, a programming system used in some US health care environments, uses December 31, 1840.
• DOS-era filesystems (FAT16, FAT32, etc.) use January 1, 1980.

The reason this is done is that computers don’t store “February 16, 1976” for dates but instead store a single number (an integer) which represents a time since a fixed point in time.  In Unix, it was famously a 32-bit integer (leading to the “Y2038 problem“), but is now is generally a 64-bit integer, some digits of which are used to give sub-second precision.

COBOL

COBOL has no specific date type or format.  It has some functions (USAGE DISPLAY) to store dates as numeric or alphanumeric strings (e.g., PIC 9(8) for YYYYMMDD).  Date manipulation generally requires custom code or third-party libraries.  This is why Y2K was such a big deal: often, in an era of systems with 16K RAM, dates were stored as YYMMDD, which lead to overflow risk.

Post-Y2K, most systems adopted the ISO 8601 standard, specifically the 2004 version.  And many of these systems likely interpret missing dates as zero point.  This leads to a date of 1875 and 150-year-old people.

So picture this: the death field is null for whatever reason (remember, we’re talking about hundreds of millions of people, many of whose records date from a pen-and-paper era).  Someone naively queries the database – which likely is not SQL, but rather a mainframe dataset.  Not knowing what they see, they program some kind of “death – birth = lifespan” logic, which is fouled up because the death date is null.  If you’re born in 2025 and died in 1875, that’s -150 years but perhaps your code just assumes it must be a positive number.

Or imagine it’s the birth date that is null for whatever reason.  Same result.

This doesn’t explain everything, but there’s been some chatter in COBOL circles about this.  You’d think all of these issues we wrestled through 25 years ago with Y2K would have fixed these kinds of problems, but tech debt is a beast that is surprisingly hard to tame.

• Author
• Recent Posts

raindog308

Dread Lord of LowEnd Content at LowEndBox

I'm raindog308, techno polymath and long-time LowEndTalk community Administrator. My technical interests include all things Unix, perl, python, golang, shell scripting, vintage operating systems such as MVS, and relational database systems such as Oracle, PostgreSQL, and MySQL.

I also enjoy using LEBs! I have an empire of little guys for VPNs, larger guys for apps, and big guys for databases and storage. When I'm not in front a screen I'm into German Shepherd dogs, quality knives, target shooting, theology, tabletop roleplaying games, and forest hiking.

I enjoy writing technical articles here on LowEndBox to help people get more out of their systems. You can find me on LowEndTalk @raindog308

Latest posts by raindog308 (see all)

• About Those Social Security Zombies…are Elon’s Teens Just Unfamiliar with COBOL? - February 20, 2025
• Will You Glimpse the Future Watching “What’s Next? The Future with Bill Gates”?No. - February 19, 2025
• Need a Fast 10Gbps Uplink with Unlimited Bandwidth on a Cheap VPS?Check Out This Offer From MetWeb! - February 18, 2025