Categories
Computers IBM

The Day the Last Mainframe Went Dark

Note: I literally grew up during the heyday of the IBM mainframe era. My first real job was working for IBM in San Francisco beginning in 1968. Iโ€™m a โ€œbig ironโ€ kind of guy. But this post was imagined after reading the following in a July 14, 2026 announcement from IBM: When we discussed our expectations with you in April, we noted that we would be wrapping on the launch of z17 in the second quarter. Given this was the strongest start to a mainframe program in our history, we expected Infrastructure revenue to decline low-single digits for the year, beginning this quarter. What played out was worse than our expectations, driven by a shortfall in our Z performance and the associated software stack, primarily in Transaction Processing. In the last few weeks of June, we saw clients shift their quarterly capex spend toward servers, storage, and memory purchases to secure supply-constrained infrastructure ahead of expected price increases. This dynamic impacted client buying patterns. While we anticipated some supply chain related impact in our expectations, we did not anticipate the magnitude of the capex reprioritization.


It won’t arrive with fanfare. No countdown, no viral video of engineers raising a glass. One morningโ€”sometime in the 2040s, perhaps laterโ€”a small team in a climate-controlled data center will complete the final cutover. They’ll flip the switches, watch the lights dim, and listen as the hum of the last production IBM mainframe fades to silence. An era that began with the System/360 in 1964 will end. Not with a crash. With the soft click of obsolescence.

We’ve been predicting the mainframe’s death for decades. In the early 1990s, pundits declared it doomed. They were wrong. Those systemsโ€”reliable, secure, capable of staggering transaction volumes with near-perfect uptimeโ€”became the invisible backbone of modern life. Your last bank transfer, airline reservation, insurance claim, or government benefit likely touched one. They endured because they solved hard problems well: high-volume, mission-critical processing where failure was never an option.

The path to that final power-down was never a rupture. It was a long, uneven evolutionโ€”driven by economics, technology, talent shifts, and the patient work of modernization. AI tools accelerated the transition. They didn’t cause it.

Lessons from Earlier Transitions

Steam engines dominated railroads for generationsโ€”powerful, reliable, deeply integrated into the industrial economy. Diesel won through incremental advantages: better efficiency, lower maintenance, longer trains with less labor. Railroads rebuilt infrastructure and retired the old iron as the economics aligned, route by route.

Prop planes opened the skies to mass travel. Jets brought speed and range that transformed global connectivityโ€”but airlines didn’t scrap fleets overnight. They ran hybrids during the overlap, invested in new airports and training, and retired props as jet economics and passenger demand made the case irresistible.

The mainframe followed this pattern. AI coding agentsโ€”Claude Code, Cursor, OpenAI models, AWS Transform, IBM watsonxโ€”transformed the brutal manual work of understanding undocumented COBOL, extracting buried business logic, generating tests, refactoring safely. What once demanded scarce veteran experts for months or years could now be accelerated, with rigorous human oversight and equivalence testing.

Platforms like Visa’s Pismo showed a smarter path: incremental modernization. Cloud-native microservices layered alongside legacy cores, rather than rip-and-replace. Banks demonstrated real progress. Hybrid strategies wonโ€”AI inference running close to sensitive data on evolved mainframes (IBM’s z17 and successors, with on-chip accelerators), while new applications and analytics moved to elastic cloud environments.

IBM positioned the platform as an “AI factory” for low-latency, secure workloads. But pricing pressure was constant. High, capacity-based software licensing made the economics harder to defend as cloud offered predictable, usage-driven costs and younger talent gravitated toward modern stacks. For CFOs weighing rising maintenance against retiring COBOL expertise and AI-assisted migration, the scales tipped.

By the mid-2030s, competitive and regulatory forces intensified. Fujitsu’s exit from mainframes created a cliff in affected markets. Skills shortages accelerated. Even the most conservative holdoutsโ€”ultra-high-volume, regulated systems in finance, government, specialized industriesโ€”began serious moves, as simulation environments and exhaustive parallel testing brought the risk down to manageable size.

The Final Act

The last systems to go were the stubborn ones, where disruption carried outsized consequences. When the final cutover succeededโ€”after months of flawless parallel runningโ€”the team powered down the machine. A global bank, a payments processor, a government entity. Maybe a small ceremony: engineers who’d kept it alive for decades, trading stories of the iron that never failed when the world needed it most.

Picture the aircraft boneyards outside Tucson or Victorville, retired 747s sitting in rows under the sun, giving up parts to new generations before they’re recycled. Mainframes will meet a similar fate, more climate-controlled. Some linger in warehouses as insurance, still humming faintly in test or archival roles. Others get dismantled by IT asset disposition teamsโ€”data wiped to standard, processors and I/O cards harvested for niche markets. The bulk gets recycled, metal and circuitry returning to the supply chain. Like the jets, the iron won’t vanish in disgrace. Its lessons in reliability and disciplined engineering at scale live on, embedded in whatever comes next.

The world didn’t stop. Transactions kept flowing, now on distributed, elastic, AI-augmented platforms that had absorbed the best of what came before. The mainframe era didn’t end in failure. It ended because better options finally existed for every workload.

What Endures

We’ll look back with respect and nostalgia. The mainframe wasn’t flashy, but it taught something durable: some problems reward obsessive focus on reliability and scale; disciplined engineering outlasts hype cycles; the wisest transitions are rarely clean breaks. They’re patient evolutions that carry forward what matters.

IBM will have completed its own transformation by thenโ€”software, services, hybrid orchestration, AI tools that work across environments. The company that built the platform helps close the book on it.

The last mainframe going dark won’t feel like loss. It will feel like the natural close of a chapter that powered the digital economy through its most formative decades. The iron did its job. Now the next architecture takes the stage, standing on shoulders built to last.

Categories
Computers FORTH IBM Programming

The Architecture of the Stack

Back in the early 1980โ€™s when I worked for IBM, I was able to acquire my own IBM PC and experience my own form digital frontierism. Today I really wish I had a logbook at hand with a record of everything I did as my ability to recall those details has faded with age. A couple of those memories that still do remain with me involve two obscure languages: APL and FORTH. And then there was Borland Turbo Pascal.

In those early days of the 1980โ€™s, memory wasn’t an infinite field; it was a precious, finite resource. While most of us were content living with the structured guardrails of BASIC, there was a subset of us drawn to the elegant, stripped-back world of FORTH.

Learning FORTH felt less like coding and more like learning a new way to breathe. It was lean. It was efficient. It stripped away the overhead of high-level syntax until it was just you, the dictionary, and the stack. There was an honesty to itโ€”no hidden abstractions, just a direct conversation with the hardware.

Then, of course, there was the hurdle of Reverse Polish Notation (RPN). Grokking the stack meant rewiring your brain. You couldn’t just state an operation; you had to prepare the world for it first. You pushed your data onto the stack, one piece at a time, and only then did you call the action. It was a rhythmic, almost percussive way of thinking: Input, input, act.

“In FORTH, you don’t just write programs; you build a language to solve the problem.”

This “bottom-up” philosophy changed the relationship between the creator and the machine. You weren’t just a user; you were an architect of your own vocabulary. To define a new “word” in FORTH was to permanently expand the capabilities of your environment. It was a recursive journey where every small success became a building block for the next complexity.

Looking back, those days with the IBM PC and the stack weren’t just about efficiency. They were about the discipline of clarity. When resources are limited, your thinking must be precise. The difficulty of RPN wasn’t a bugโ€”it was a feature that forced you to understand the flow of data at its most fundamental level.

Categories
AI Audio ChatGPT Computers iPhone Tools

Voice is not what I needโ€ฆ

Itโ€™s been a busy week of announcements in tech land what with Microsoft Build, Google I/O, and yesterdayโ€™s tease of an announcement by OpenAI and itโ€™s acquisition of Jonny Iveโ€™s company โ€œioโ€.

Industry pundits are all a Twitter speculating about what kind of device Ive and his team might make to deliver an amazing AI experience to users. Ive seems to regret how โ€œhisโ€ iPhone has created such an addiction to screens and seems to want to repent by bringing us something new and โ€œbetterโ€. For more, see this tweet: https://x.com/mingchikuo/status/1925543472993321066?s=46

I have one simple request: donโ€™t make voice the primary interface to some new magical device.

Iโ€™ve had an iPhone with some serious voice input capabilities for years and the reality is that I rarely use voice. Perhaps if my life was just โ€œbowling aloneโ€ Iโ€™d find it natural to just talk out loud to a piece of technology. But Iโ€™m mostly around other people all day and out of respect for them I simply prefer being silent.

Until some new magical device can capture my thoughts without either voice or keyboard input, I will remain a skeptic. Skeptics like me will reduce the market size opportunity for any such new device. Just sayinโ€™โ€ฆ

Categories
Apple Computers Mac

My First Mac

This week was the 40th anniversary of the announcement of the Apple Macintosh. I still remember the day I got my first Macintosh. It was a Mac SE/30, a compact all-in-one computer with a 9-inch monochrome display. It was the fastest (Motorola 68030 powered) and most powerful of the original black-and-white Macs, and I loved it.

Up until that point I was an IBM PC user having bought my first IBM PC as part of the employee purchase program IBM offered. By the time I got my first Mac I had moved on from IBM and my son had inherited by PC. I remember him being a fan of Borland’s Turbo Pascal on the PC where he really learned programming.

The SE/30 was released in January 1989, and I got mine a few months later at Fry’s in Palo Alto. It came with a 16 MHz 68030 processor, 4 MB of RAM, and an 40 MB hard drive.

The SE/30 was a versatile machine. It had a Processor Direct Slot (PDS) that allowed me to add expansion cards, but I never opted to install any. It could also support up to 128 MB of RAM, which was a huge amount at the time, but it required a ROM swap or a system extension to enable 32-bit addressing.

The SE/30 was my faithful companion for many years. I used it for the usual applications: word processing, spreadsheet, graphics, and games. I also used it to connect to the Internet, using a dial-up modem and a web browser. I was amazed by the amount of information and entertainment that was available online especially on CompuServe where I became a forum sysop responsible for managing several online forums.

The SE/30 was not only a powerful computer, but also a beautiful one. It had a sleek and elegant design, with a platinum-colored case and a friendly smiley face icon on the startup screen. It was easy to use, with a graphical user interface and a mouse. It was also reliable and durable, with no problems needing repairs. I had a carrying case for it and took it on several airplane trips storing it up in the overhead compartment!

The SE/30 was more than just a machine. It was a part of my life during those years. It was my first Macintosh, and it will always have a special place in my heart!