Ask where assembler actually runs in production today and most answers default to the abstract: banks, insurers, "legacy systems," a vague gesture at the government. That's true and also useless, because it doesn't tell you anything you could check. The more interesting answer names names: the IRS still calculates tax refunds on a system whose core logic dates to the Kennedy administration, Visa and a meaningful share of the airline industry still route transactions through an operating system that grew up as a System/370 assembly environment, and a chunk of the code doing that work is quietly running toward a timestamp overflow in 2038 that almost nobody outside mainframe circles has heard of. None of this is nostalgia. These are working systems with GAO audit numbers, documented outages, and modernization budgets attached to them, and they're worth looking at directly instead of gesturing at "legacy" as a category.
The tax system built in 1962, still running your refund
The IRS's Individual Master File, or IMF, is the system of record for more than 100 million American taxpayers — names, identification numbers, addresses, income, deductions, credits, payments, and refunds, for essentially every individual filer in the country. IBM built it in the 1960s, and per the U.S. Government Accountability Office's own 2018 audit, it still runs on assembly language and COBOL processing VSAM files in batch.
“IRS reported that it used assembly language code and Common Business Oriented Language (both developed in the 1950s) for IMF and IDRS, which exposes these investments to a rise in procurement and operating costs, and a decrease in staff available with the proper skill sets.”
U.S. Government Accountability Office, GAO-18-298
That's not a throwaway line from a blog — it's a federal audit finding, in a report titled "Information Technology: IRS Needs to Take Additional Actions to Address Significant Risks to Tax Processing," published June 28, 2018. The consequences of that exposure aren't hypothetical either. IMF suffered a hardware failure on April 17, 2018 — the day after Tax Day that year — that disrupted processing during peak season, and during the COVID-19 stimulus disbursement effort, the system's difficulty absorbing rapid code changes contributed to real taxpayers receiving incorrect payment amounts or being unable to check their payment status.
The IRS isn't sitting still on this — the Customer Account Data Engine was supposed to replace IMF starting back in 2000, that first attempt was scrapped, CADE 2 has been underway since 2009 with major functionality not expected until 2023, and full implementation is currently targeted for 2030. Read those dates in sequence and the actual lesson isn't that the IRS is negligent, it's that replacing a system this size, this old, and this thoroughly load-bearing is a multi-decade project even for an agency with a mandate and a budget line to do it. That timeline is the honest answer to "why don't they just rewrite it" — they're trying, it's been thirty years, and it still isn't done.
The transaction rails: TPF, Sabre, Visa, and the airlines
If IMF is the single most-cited example of assembler in government, the Transaction Processing Facility is the closest thing to an equivalent in the private sector — except it's not one system, it's the operating system underneath a meaningful slice of global travel and payments infrastructure. TPF is IBM's real-time operating system purpose-built for extreme-volume, simple transactions across geographically dispersed networks with minimal response time, and it grew up as an assembly-language environment for exactly the reason you'd expect: at the volumes these systems run, performance wasn't a nice-to-have.
Modern TPF versions support C and C++, and z/TPF's current toolchain runs on 64-bit GNU development tools with GCC — so this isn't a museum piece frozen at 1970s tooling either. But that modernization sits on top of, not instead of, decades of working assembler: "TPF was traditionally an IBM System/370 assembly language environment for performance reasons, and many TPF assembler applications persist." The word doing the real work in that sentence is "persist." Nobody rewrote the assembler routines that already worked just because newer languages became available for the ones that didn't exist yet. Visa's card network is reported to lean on this same infrastructure specifically during peak load — holiday shopping season — which is exactly when a payment network can least afford to discover a scaling problem in code nobody's touched in years.
The maintenance work nobody sees
None of this is a story about programmers sitting down to write new assembler routines from a blank screen in 2026. Almost nobody does that anymore, and that's not actually the interesting omission. The real, ongoing work is smaller and less dramatic than either "still writing assembler" or "just maintaining a museum piece" suggests: it's exits. RACF security exits that decide whether a given user can open a given data set. SMF exits that decide what gets logged and how. DADSM functions — create, rename, scratch, extend — that manage the physical allocation of datasets on DASD, and that still fail in ordinary, undramatic ways: a CREATE or RENAME can fail because a dataset's SMS-managed status disagrees with what the catalog thinks it should be, or because its cataloged status doesn't match its actual DSCB on the volume. A tape volume can get rejected during OPEN or EOV processing because its label doesn't match, because it's password- or RACF-protected and the job requesting it doesn't have the right credentials, or because of a duplicate mount. None of this is abstract system architecture. It's the kind of thing that shows up as a return code in a message log at 2 a.m., attached to a job that has to run before the business day starts, and somebody with actual assembler and JCL fluency has to read that return code, find the failing function, and fix the mismatch before the batch window closes.
That's the actual shape of "real world" assembler work in 2026: not writing new logic, but keeping decades-old exits, security checks, and dataset-management routines correctly wired into systems that get extended constantly around them — new interfaces added, new compliance requirements layered on, new integrations bolted onto the transaction rails described above — without anyone touching the assembler core doing the actual work underneath. It's unglamorous by design. The one time this layer becomes visible outside the operations team is when it fails, which is exactly why IEC-prefixed message codes — the ones the system emits when a DASD, tape, or dataset management operation goes wrong — are some of the most consistently searched reference material on sites like this one. Somebody is troubleshooting one of these codes against a live production incident right now, not out of academic interest.
The 2038 problem hiding in old timestamp math
Most people who've heard of a millennium-scale date bug know Y2K. Far fewer have heard of Y2K38, and the reason it matters here is that it's a live, dated, technically specific problem sitting directly in code of the same vintage and often the same language as everything above. At 03:14:07 UTC on January 19, 2038, any system still representing time as a 32-bit signed integer counting seconds since 1970 will overflow. Uday Prasad, founder of MainframeZskill and developer of the SEZ-38 framework aimed specifically at this problem, laid out why it's a worse problem than Y2K rather than a smaller, later rerun of it.
“The real danger of Y2K38 is not just a catastrophic shutdown — it is the gradual erosion of trusted chronology.”
Uday Prasad, Lead Architect, MainframeZskill Pvt. Ltd.
Y2K was fundamentally a display and comparison bug — "00" meaning 1900 instead of 2000. Y2K38 is a hardware-level arithmetic overflow, and it lands on systems that are now far more interconnected than anything running in 1999: event sequencing, authentication tokens, financial transaction ordering, and blockchain validation all depend on a timestamp actually being trustworthy, not just present. A lot of the oldest code carrying that risk was written in an era, and often in a language, where nobody had a 64-bit integer to reach for and time arithmetic got hand-rolled directly against whatever word size the hardware gave you — which on a lot of mainframe systems of that vintage meant hand-written assembler, not a library call. That's the throughline connecting this back to IMF and TPF: none of these systems are static archives. They're live code, still being extended and patched, and a fixed calendar date is now bearing down on some of it whether anyone's scheduled a rewrite or not.
Why none of this gets replaced on anyone's convenient timeline
CICS is worth a last mention here, not for its transaction-volume numbers — those get cited plenty elsewhere — but for what its own history says about why assembler specifically survives inside it. CICS applications were originally written entirely in IBM 360 Assembler, and per its own documented history, programmers kept writing new CICS applications in assembler "even after COBOL and PL/I support became available," because hardware resources were expensive and scarce enough that the performance difference mattered. That decision, made when hardware cost drove the calculus, is still embedded in production code decades after the hardware economics that justified it stopped applying — because the code kept working, and working code making money is a bad argument for a rewrite, whatever originally motivated writing it.
Put IMF, TPF, and CICS's own history side by side and the pattern isn't "nobody wants to modernize this." The IRS has been actively trying since 2000. TPF has genuinely modernized its toolchain to C and C++ where it made sense. The pattern is that the specific assembler code already running, already correct, and already handling volumes at a scale that's expensive to fully re-test, keeps surviving every modernization pass aimed at the layers around it. Rewriting is expensive and risky in a way that's easy to underestimate from outside: a hand-rolled routine written in 1975 rarely comes with a specification document, a test suite, or an author still available to explain an edge case, which means a faithful rewrite has to reverse-engineer behavior from the code itself before it can safely replace it. That's a slower, more expensive project than porting a language, and it's why the systems above are still running the parts of themselves nobody's found a safe enough reason to touch.
- The IRS's Individual Master File still processes tax returns for 100+ million people on assembly-language-and-COBOL code the GAO has been flagging as a risk since at least 2018, with a full replacement not targeted until 2030.
- TPF, born as a System/370 assembly environment, still underlies a meaningful share of global airline reservations and card-network payment processing, including at Visa and American Express, with modern language support added around a persisting assembler core rather than replacing it.
- The real day-to-day assembler work at most shops isn't new development — it's RACF, SMF, and DADSM exits that keep decades-old security and dataset-management logic correctly wired into systems built up constantly around them.
- The Year 2038 problem is a real, dated arithmetic overflow, not a hypothetical — and a nontrivial share of the code exposed to it is old enough to have been written before 64-bit time handling was ever an option.
- CICS's own history shows assembler surviving past the hardware economics that originally justified writing it, simply because working code is a weak target for discretionary rewrites.