It's a Fucking Mainframe

The Moment It Clicked

Driving past Scammonden reservoir heading west on the M62 I was bashed from the right by a big cross-wind that pushed my van onto the hard shoulder. As I battled to get back into the first lane, and all the cars to my right avoided me, I shouted: “It’s a fucking mainframe!”

But it can’t be, can it? Not after 30 years of progress. Not after client-server, web, virtualization, cloud, mobile, serverless, and whatever we’re pretending edge computing is this week.

But here we are, hands trembling on the steering wheel, eyes wide open. Staring at the most hyped technology in a generation — LLMs, AI agents, “the future of work” — and I’m looking at it thinking: I’ve seen this before.

Once my bum had stopped gripping the seat, I realised this isn’t a grand revelation. No lightning bolt. It was quieter than that. More annoying. I’ve been “feeling” this for ages (not the seat). I’ve been watching people build “AI workflows” — chains of prompts, tools, retries, conditions — and I always had this uncomfortable feeling in my gut that I couldn’t shake for days.

I’ve seen, done, and written this before.

Not in Python. Not in YAML.

In JCL. Job Control Language.

The thing that once was physically expressed in punch cards. The language we used to orchestrate work on IBM mainframes in the 1980s and 1990s, and which — if you know where to look — is still orchestrating the world’s banking, insurance, and airline reservation systems right now, today. While you read this and think I’m talking bollocks.

I spent the first five years of my career (aged 21-26) as a systems programmer on IBM mainframes at a Bank in Scotland. 3090s before z/OS, MVS, VM/CMS — the big iron.

I tuned parmlib members, managed CICS regions, ran the Connex upgrade to parallex sysplex, debugged ABEND dumps, dreaded the sound of Tarreja on my Nokia at 2am in the morning, and fought with SMP/E when PTF applies went sideways.

Then I spent the next two decades watching the industry try to escape that world. Client-server was going to kill the mainframe. The web was going to kill the mainframe. Cloud was definitely, absolutely, this time for real going to kill the mainframe.

I believe the last words from my old Glesga mates in the mainframe team were, as I flounced down to London to join the internet generation, “The internet is a fad, it’ll never last!”.

How I laughed at them. What did they know?

Well, surprise surprise, they were wrong about the internet, but right about the mainframe.

The mainframe is still there. And now, so is its architecture. Wearing a different outfit. It’s hard to see in a crowd. But once you see it, you can’t unsee it.

Let me spoil your view of today, but at the same time share a cheat code with you.

They Didn’t Invent Something New. They Reverted.

Let me be blunt in a friendly Yorkshire way. “I say what I like, and I like what I say.”

“They” didn’t invent a new computing paradigm. They never left. We’re still in centralized paradigm, but it’s wrapped in new APIs, better documentation, with a friendlier interface.

And because most of the people building this stuff never lived through the last version — never sat in front of a 3270 terminal waiting for a batch job to finish, never fought for TSO time on a shared system, never had their job bumped because someone else’s cost centre had higher priority — they think it’s new.

It isn’t.

I know that sounds like “old man shouts at cloud.” Maybe it is. But I’d posit that this frame of reference — understanding that LLMs recapitulate patterns we spent decades refining — is critical for getting LLM applications right… to understand them… to adopt them… for building, operating, securing, and financing them.

If you don’t recognise this pattern on the carpet I lay before you, you’ll reinvent every solution and repeat every mistake, and you’ll do it at the cost of time and money that the pattern could have saved you. And I will put an arm around you and console you, whilst sniggering like Mutley who’s got a new badge.

This isn’t a takedown of LLMs — I’m a HUGE user (that is, my usage is huge, not me physically…).

I’m not here to diminish what LLMs can do. They’re extraordinary. But extraordinary things still need to be operated, and the operating model is older than most of the people building it.

And operations is where people have their blindest of eyes.

The Parallels Between Mainframes and LLMs Are Not Subtle

Once you see it, you can’t unsee it. So let me open your eyes forever.

I’ve put together every parallel I can find between the mainframe era and the LLM era. Some are surface-level. Most are structural. A few are so exact they made me check whether someone at Anthropic had been reading IBM Redbooks. Some might be for fun. You have to work that out!

Mainframe (Then)	LLM (Now)	The Punchline
3270 terminals	Claude Code, Cursor, ChatGPT	It’s a terminal with better CSS.
JCL batch jobs	Prompt chains / agent workflows	We’re writing JCL again. We just call it YAML.
ACF2 / RACF	RBAC, guardrails, content filters	Same access control, new acronyms, same meetings.
CICS transaction sandboxing	Container sandboxing / code execution	”Sandbox” hasn’t even changed its name.
Time-sharing (TSO, VM/CMS)	Token rate limits / TPM quotas	You’re being rationed CPU cycles. Again.
Operators / sysprogs	Prompt engineers / AI ops	The priesthood is back, baby.
Spool / JES output queues	Streaming responses / output buffers	The output queue survived 60 years.
ABEND codes	Hallucination detection / output validation	The system still lies to you. It’s just more polite now.
Chargeback / MIPS billing	Token-based pricing / FinOps for AI	You’re metering compute time. Again.
MVS system commands	System prompts	You’re still whispering instructions to the machine before the user gets near it.
SMP/E (System Modification Program)	Model fine-tuning / RLHF	Patching the system without breaking it is still the hardest job.
GRS (Global Resource Serialization)	Context window management / rate limiting	Contention for shared resources. The eternal problem.
SMF (System Management Facility)	LLM observability / logging / telemetry	You’re still writing Type 30 records. You just call them spans now.
VM/CMS	Virtual machines / cloud instances	VMs all the way down, 50 years running.
ISPF	VS Code / IDE + terminal	Same IDE. Better fonts.
WLM (Workload Manager)	AI request routing / load balancing	Classifying and routing work. Still.
Sysplex coupling	Multi-region / multi-cloud	Same high availability. Worse tooling. More YAML.

Seventeen parallels. I stopped not because I ran out, but because the point was made somewhere around row five and I kept going out of a kind of horrified fascination.

Let me take you through each one.

Terminals with Botox

In the 1990s, I sat in front of a 3270 terminal, and an odd-looking keyboard. Twenty-four lines by 80 characters. Green phosphor on black. Block-mode data transfer — you filled in a screen of fields, hit Enter, and the entire screen was transmitted to the mainframe for processing. This was explained to me by an elderly mainframe sysprog sporting a penguin jumper. I was the graduate trainee, he was the senior. I started questioning my career choice.

What he said was: “The whole buffer is sent to the mainframe. The mainframe thinks about it, builds the response, and sends back a new screen. You and the mainframe take turns. It’s civilised, in its way. Because the mainframe is always in charge. And who controls the mainframe? WE DO.”

After that encounter, I saw the industry spend the next 30 years desperately trying to escape that interface and any talk of penguins.

GUIs. Browsers. Mobile apps. Touch screens. Voice assistants. Every few years, a new paradigm arrived to liberate us from the tyranny of the blinking cursor and the remote brain we didn’t control or understand.

And where are we today? The hottest developer tools of 2026 are terminals. CLIs or TUIs. That’s it. The new hotness. Like it never existed before.

Claude Code is a TUI — a terminal user interface, built with TypeScript and Ink, which is React for the terminal. You sit in your terminal. You type instructions. You hit Enter. You wait. The system responds.

Cursor is an editor with a chat pane bolted on.

Gemini CLI — Google went CLI-first. The broader TUI renaissance — lazygit, k9s, btop — has been building for years, but AI tools turbocharged it.

The 3270 was a “dumb terminal” connected to a powerful centralized computer.

Claude Code is a terminal interface connected to a powerful centralized model.

The 3270 sent blocks of data to the mainframe for processing.

Claude Code sends blocks of text to the API for processing.

The 3270 couldn’t do anything useful without the mainframe.

Claude Code can’t do anything useful without the model.

Here’s the detail that makes my eye twitch: the 3270 was a block-mode terminal. You didn’t send characters one at a time like a VT100. You composed your entire input — tabbing between fields, filling them in — and then hit Enter to transmit the whole screen as a single block. That’s exactly how a prompt works. You compose your entire input, hit Enter, and it gets sent as a block to a centralized system for processing. The character-at-a-time terminal was the historical anomaly. We’ve gone back to block mode.

A 3270 ISPF terminal screen — green phosphor on black, 24 lines by 80 characters. The visual ancestor of every modern AI coding terminal.

We spent 30 years escaping the dark-mode green screen (which I love, btw). We had infinite colours, brightness and sunshine… and what did people choose? Dark mode and green screen.

You just can help some people. :)

We’re Writing JCL Again

This is the parallel that should make people uncomfortable. It will also be fun for history buffs.

JCL — Job Control Language — was the language you used to tell the mainframe what to do. Not the application logic. It was once PUNCHED on CARDS.

The orchestration. JCL told the system: what program to run, what data to use as input, where to put the output, what resources to allocate, and what to do if something failed. Does this sound familiar?

Here’s a JCL job:

//MYJOB    JOB  'ACCT123',CLASS=A,NOTIFY=&SYSUID
//STEP1    EXEC PGM=MYPROGRAM
//INPUT    DD   DSN=MY.INPUT.DATA,DISP=SHR
//OUTPUT   DD   DSN=MY.OUTPUT.DATA,DISP=(NEW,CATLG,DELETE)
//SYSPRINT DD   SYSOUT=*

And here’s a modern agent workflow definition:

job: analyse-customer-feedback
model: claude-sonnet-4
input: s3://feedback/q1-2026.csv
output:
  format: markdown
  destination: slack://channel/insights
on_failure: retry 3 then notify ops@company.com
constraints:
  max_tokens: 4096
  temperature: 0.3

Same. Bloody. Thing.

Both specify a unit of work. Both declare inputs and outputs. Both set resource constraints. Both define failure handling. The syntax changed. The semantics didn’t.

But the parallels go deeper than the job card, and this is where only someone who actually wrote JCL would catch it.

JCL had PROCs — reusable procedures.

Stored in a system library called SYS1.PROCLIB. You wrote a JCL procedure once, catalogued it, and called it from multiple jobs with different parameters. A system prompt is a PROC.

A prompt template is a PROC. We’re storing reusable instructions in a library and calling them with parameters. SYS1.PROCLIB has been rebranded as your “prompt library” and nobody noticed.

Does this sound like an agent or skill to you?

JCL had COND codes

Conditional execution based on the return code of a previous step. COND=(0,EQ) meant “skip this step if the previous step returned zero.”

Agent workflows have conditional branching based on the output of previous steps. Tool-use decisions. Retry logic. We reinvented COND codes and called them “agentic decision-making.”

JCL had DD statements — Data Definition.

Every step declared its data sources and sinks explicitly. //INPUT DD DSN=MY.DATA told the system where to find the input.

Every agent framework has its own version of DD statements: tool definitions, function calling schemas, MCP server configurations. You’re still defining your data sources before you run the job. The DD statement is now a JSON schema, but it’s still a DD statement.

JCL was ugly, rigid, and unforgiving. But it worked. Sometimes, constraints are beautiful. AND RELIABLE. It orchestrated the world’s transaction processing for decades. And when it failed — which brings us to the next point — it had the decency to tell you why.

But it wasn’t all moonlight and roses. We planned and built for disaster, because we (then) ran 70% of the UK’s ATMs and processed a LOT of transactions. Failure wasn’t really an option.

How many LLM app builders think like that?

What can they/we/us learn from the “olden days”?

The System Still Lies to You

On a mainframe, jobs failed. We expected it, they didn’t hide it.

You got an ABEND — Abnormal End — with a system completion code that told you exactly what went wrong. S0C7: data exception, you tried to do arithmetic on something that wasn’t a number. S0C4: protection exception, you accessed storage you weren’t authorised to touch. S322: time limit exceeded, your job ran too long and the system killed it. S806: module not found, you asked for a program that doesn’t exist. S0C1: operation exception, you tried to execute an invalid instruction.

Brutal. Precise. Unambiguous. You might need a reference manual to decode the specific code, but the system never lied about the category of failure. An ABEND was a contract: something went wrong, here’s the classification, go fix it.

One of the biggest complaints I had when moving from “the old backwards mainframe” to “the new exciting Solaris and internet” was the lack of consistent logging. No dates. NO MESSAGE CODE. No Quickref. People were flying blind by the seat of their pants. And they thought mainframes were crap? Mainframes were light years ahead of unix/windows.

But what about 2026? When you run your business on an app that uses an LLM, what happens?

The system fails politely.

It gives you a confident, well-structured, grammatically perfect answer that is completely wrong.

It doesn’t crash. It doesn’t throw an error. It doesn’t give you a code.

It hands you a hallucination with the same tone and formatting as a correct answer, and it’s on you to figure out which is which.

We didn’t eliminate failure. We made it harder to detect.

A SOC4 ABEND was honest. A hallucination is gaslighting.

Let that land for a moment. We replaced a system that failed loudly and precisely with a system that fails silently and confidently.

In what universe is that progress? The mainframe respected you enough to tell you it broke. The LLM smiles and serves you fiction with the same confidence it serves fact.

Yes, we’re building hallucination detection, output validation, grounding checks. We’re rebuilding the error-handling discipline that mainframes had from day one.

We’re just doing it after the fact, bolting it on, instead of having it baked into the architecture from the start. We’re treating it as a feature to add rather than a property to guarantee.

We’ve regressed. And we’re spending money to climb back to where we started.

You’re Being Rationed Again

TSO — Time Sharing Option — was how you got interactive access to a mainframe. The name tells you everything: it was a time sharing option. You weren’t getting the machine to yourself. You were getting a slice of it, allocated according to your priority class, your cost centre’s budget, and whatever the sysprogs had decided your fair share looked like.

If the system was busy, you waited. If your priority was low, you waited longer. If your session was idle too long, you got bumped. Resources were finite, demand exceeded supply, and somebody had to make allocation decisions. That somebody was usually a grumpy sysprog with a spreadsheet and opinions.

That was me, but we didn’t have spreadsheets back then, just banter.

But does this sound familiar to you?

LLM access in 2026 runs on the same model.

Tokens per minute.
Requests per day.
Priority tiers.
Rate limits.
Usage caps.

The billing unit changed from MIPS to tokens, but the underlying economics are identical: a powerful shared resource, more demand than capacity, and an allocation system that decides who gets how much.

Anthropic has usage tiers. OpenAI has rate limits.

Enterprise customers get dedicated capacity — the modern equivalent of a dedicated LPAR.

Everyone else shares and waits.

TSO literally stands for “Time Sharing Option.”

We’re back to fighting for our slice of a shared computer, and the only thing that changed is that the queueing happens over HTTPS instead of VTAM.

The Immortal Spreadsheet

On a mainframe, every CPU cycle was accounted for. Every job ran under an accounting code. Every MIPS consumed was attributed to a cost centre, logged by SMF, and turned into a line item on a chargeback report that landed on someone’s desk at the end of the month.

This wasn’t optional. This was how the machine paid for itself. If your department used 15% of the MIPS, your department paid 15% of the bill.

The chargeback meeting was a ritual.

Department heads would argue about whether their batch window was too small, whether production support was eating too much of their allocation, whether the new CICS region should be charged to development or operations. The spreadsheet was the battleground. The spreadsheet was always the battleground.

Now look at AI FinOps. (If you do this at all.)

Your token costs go to your department. Your API spend gets attributed to teams, projects, features. Someone builds a dashboard. Someone else argues that the RAG pipeline is consuming more tokens than it should. A meeting gets scheduled to discuss cost allocation. The spreadsheet appears.

It’s the same spreadsheet. I recognise the font, and the Leeds United joke in J14.

The chargeback model works because centralized resources need centralized cost management. That was true when the resource was MIPS and it’s true now that the resource is tokens.

The FinOps-for-AI discipline that’s emerging in 2025-2026 isn’t new — it’s the third generation of the same practice. Mainframe chargeback begat cloud FinOps begat AI FinOps. The lineage is direct. The spreadsheet is immortal.

The Priesthood Is Back

Every centralized computing system in history has created a class of people who understand it and a much larger class who don’t. “Prompt/Context Engineers/Whisperers” anyone?

Mainframes had sysprogs — systems programmers. We were the ones who knew how the machine actually worked (because we read paper manuals. Imagine that.).

How to tune the parmlib members that controlled system behaviour.
How to diagnose a WAIT state.
How to apply maintenance without taking down production.
How to read a dump.

The specifics were arcane enough that most application programmers never learned them, and obscure enough that management certainly didn’t. You needed us, and we knew it.

The dynamic was unmistakable.

A developer would come to you with a problem.

You’d take a sharp intake of breath. You’d look at their JCL, sigh, change one parameter, and the job would run. They’d ask what you changed. You’d explain it in terms they didn’t quite follow. They’d thank you and leave, cursing you down the corridor as they left.

Both of you understood the unspoken hierarchy: they could write the application, but they couldn’t run the system.

“Don’t touch that — you’ll break it.”

Now look around. We have prompt engineers. AI ops teams. Model specialists. People who understand how to tune a system prompt, how to structure a context window, how to debug a misbehaving agent, how to configure guardrails. The specifics are arcane enough that most developers are still figuring them out, and obscure enough that management definitely hasn’t.

A developer comes to the AI team with a problem. The prompt engineer looks at their system prompt, takes a sharp intake of breath, sighs, changes one instruction, and the model behaves. The developer asks what they changed. The prompt engineer explains it in terms that don’t quite land. The developer thanks them and leaves.

Different job titles. Same dynamic. Same mystique. Same “don’t touch that” energy.

And the truth is — they’re not wrong. Then or now. Centralized systems are complex. Expertise matters. The priesthood exists because the complexity is real, not because the priests manufacture it. The question isn’t whether we need specialists — we do. The question is whether we recognise that we’re recreating a social structure we’ve seen before, and whether we can learn from how that structure evolved the first time.

Whispering to the Machine

On 3090s and z/OS, the system’s behaviour was shaped by a collection of parameter libraries — parmlib members — that the sysprog configured before the system was IPL’d (booted). IEASYSxx controlled core system parameters. IEAPAKxx controlled pageable storage. SMFPRMxx controlled what got logged. Dozens of these members, each tuning a different aspect of the operating system’s behaviour. We ran multiple LPARs with different configs and constantly tested them, failed over: we were as paranoid as fuck.

Because do you know how nice people are when they can’t get their money? Not nice at all.

The end user never saw them. The application programmer rarely knew they existed. But everything the system did — how it allocated memory, how it scheduled work, what it recorded, how it recovered from failure — was shaped by these invisible configurations. The sysprog whispered instructions to the machine, and the machine listened, and nobody else in the building knew the whisper had happened.

A system prompt is a parmlib member.

It’s configuration that shapes everything the model does, invisible to the end user. It sets the personality, the constraints, the response format, the safety boundaries. The user types their question. The model answers. The user has no idea that 2,000 words of system prompt preceded their input, shaping the response they received. The prompt engineer whispered to the machine before the user got anywhere near it.

IEASYSxx + IEAPAKxx + SMFPRMxx = your system prompt. The parallel is exact. And the skill of writing a good system prompt — balancing constraints against flexibility, being specific enough to prevent bad behaviour without being so rigid that the system can’t adapt — is the same skill a sysprog needed when tuning parmlib. Too tight, and the system choked. Too loose, and it misbehaved. The art was in the balance.

Protection by Default

This is where it stops being funny.

In 1978, a man named Barry Schrager designed a mainframe security product called ACF2. He designed it on a principle he called “protection by default.” The idea was elegantly simple: everything is locked down unless explicitly permitted. Whitelisting, if you will.

If you haven’t been granted access to a resource, you can’t touch it. Not because someone remembered to protect that specific resource, but because the default state is denial.

This was a direct response to IBM’s RACF, which used what Schrager called “protection by itemization.” In RACF, you had to specify what to protect, resource by resource. If you forgot to protect something — or if a new resource was added and nobody updated the rules — it was open. The default state was access. Security depended on the administrator’s diligence and memory.

Sounds a bit like the hated-by-pros AWS IAM and other things. Powerful and painful, two words you don’t want to mix.

Schrager saw the flaw immediately. If you have to enumerate what to protect, you’ll miss something. The only safe default is denial. Protection by default. Everything locked. Explicit permissions for what you actually want to allow.

He was right in 1978. He’s still right in 2026. And you’re still arguing about it. I’m not.

LLM security today is overwhelmingly “protection by itemization.” We add guardrails for the attacks we know about. Content filters for known bad prompts. Blocklists for specific patterns. We play whack-a-mole with prompt injection techniques, adding defences as new attacks are discovered, always one step behind.

What we need is ACF2 thinking. Deny by default. The model can only do what it’s been explicitly permitted to do. Not “block the bad stuff” but “allow only the good stuff.” The difference sounds semantic until you’re the one who missed an attack vector because your blocklist was a version behind.

IBM created SAF — the Security Access Facility — as a standardised middleware interface that let any security product plug into the operating system. RACF used it. ACF2 used it. Top Secret used it. It was security as middleware: a layer that sat in the request path, between the user and the resource, product-agnostic and intercepting every access attempt. That pattern — security as middleware — is exactly what modern API gateways and edge security platforms implement. Cloudflare Workers sitting in the request path, intercepting every call, checking credentials and policies before the request reaches the model. SAF with TLS certificates.

The mainframe security model matured because it had to. Banks ran on it. Governments ran on it. Airlines ran on it. When the system you’re protecting processes trillions of dollars in transactions, you figure out security or you lose the contract. LLM security is immature because we’re still pretending these systems are consumer toys, not critical infrastructure. When the first bank runs its core lending decisions through an LLM — some already are — they’ll need ACF2-grade security.

Barry Schrager figured out “protection by default” in 1978. We’re still arguing about it in 2026. The man was 48 years early. As I write this, I’m 53.

Sandbox Hasn’t Even Changed Its Name

CICS — Customer Information Control System

This the parallel that most people will miss, and it might be the most important one.

CICS did something extraordinary for its era. It ran thousands of simultaneous transactions in a single address space, each isolated from the others, with shared access to resources — files, databases, transient data queues — all managed by a transaction monitor that handled security, recovery, and resource allocation. A single CICS region could process thousands of concurrent requests, each believing it had the system to itself.

Transaction isolation was achieved through z/OS subspaces. An application program running in one transaction couldn’t accidentally read or overwrite data belonging to a different transaction. The storage was partitioned. The boundaries were enforced by the hardware. If your program tried to reach across the boundary, you got an ABEND. Clean. No ambiguity.

Container isolation does the same thing. One container can’t access another container’s memory or filesystem. They share the host kernel and can access shared resources through defined interfaces — networks, volumes, services — but the boundaries are enforced. If your container tries to reach across, it gets denied.

LLM code execution sandboxes do the same thing again. When Claude or ChatGPT executes code on your behalf, it runs in an isolated environment. The code can’t access other users’ data. It can access defined resources — files you’ve uploaded, APIs you’ve configured — through controlled interfaces. The boundaries are enforced. The isolation is the point.

Three generations of the same architecture. CICS transaction isolation. Container isolation. LLM sandbox isolation. The nouns changed. The architecture didn’t.

But here’s the bit that only someone who ran CICS would know: CICS regions ran for months without restarting. We called it “warm starting” — the region came up, loaded its programs, opened its files, established its connections, and then ran. And ran. And ran. A cold start — shutting down completely and coming back up fresh — was painful. It took time. It disrupted users. It was avoided at all costs.

Modern Inference infrastructure has the same property.

Inference servers run continuously. The models are loaded into GPU memory and kept warm. A cold start — loading a 70-billion-parameter model into VRAM from scratch — is expensive and slow. So you keep the servers running. You avoid cold starts. You design around warm state. CICS ran for months without restarting in 1985. Your inference server runs continuously in 2026. We’re still avoiding cold starts, 40 years later.

And CICS’s quasi-reentrancy requirement — that application programs had to be written so they could be shared across concurrent transactions without modification — is the same constraint as writing stateless functions for serverless platforms. Your Lambda function can’t rely on persistent local state because multiple invocations might share the same runtime. Your CICS program couldn’t rely on persistent working storage because multiple transactions shared the same load module. We reinvented quasi-reentrancy and called it “stateless.”

CICS ran thousands of isolated transactions in a shared environment, with security, recovery, and resource management. We called it a “transaction server.” Now we run thousands of isolated containers in a shared environment, with security, recovery, and resource management. We call it “cloud native.” Same thing. Worse acronym.

The Output Queue Survived 60 Years

JES2 — Job Entry Subsystem 2 — managed the flow of work into and out of the mainframe. When your job finished, the output went to the spool — a queue managed by JES2. You’d go to SDSF, the System Display and Search Facility, and check whether your job had finished. If it had, you’d browse the output. If it hadn’t, you’d see your job’s position in the queue. “Job MYJOB123 is 47th in the queue.” You knew where you stood. You went for a bacon roll and a cup of tea and talked about how bad Hearts and Hibs were compared to Rangers and Celtic.

Now your LLM streams tokens back to you and you watch them appear word by word. The response is being generated — spooled, if you like — and delivered to your display as it becomes available. If the system is busy, you wait. If your request is complex, you wait longer. The output queue survived. It just got a progress animation.

JES2 was more honest about one thing, though. It told you your position in the queue. It told you how many jobs were ahead of you. You could make an informed decision about whether to wait or come back later. Modern LLM APIs give you a spinner. Or a timeout. Or a rate-limit error with a “retry after” header that might or might not reflect reality. JES2 would have been appalled by the lack of transparency.

You’re Still Writing ‘Type 30’ Records

SMF — the System Management Facility — was z/OS’s telemetry system. It recorded everything. Every job that ran got an SMF record. Every dataset that was opened, every program that was loaded, every security decision that was made, every resource that was consumed. SMF Type 30 records captured job-level accounting data: CPU time, I/O counts, storage usage, elapsed time. Type 80 records captured security events. Type 89 records captured usage data for capacity planning.

The data was comprehensive, detailed, and relentless. You couldn’t turn it off without a very good reason and a very understanding auditor. The SMF dataset was the system’s memory — the complete record of who did what, when, with what resources. When something went wrong, you read the SMF data. When someone asked “who ran that job?”, you read the SMF data. When you needed to do capacity planning, you read the SMF data.

Now look at LLM observability. OpenTelemetry captures spans for every LLM call: model, tokens in, tokens out, latency, status, metadata. Datadog, Langfuse, Arize, Helicone — they all ingest these spans and give you dashboards. Who called the model. What they sent. What came back. How long it took. How much it cost. When something goes wrong, you read the traces. When someone asks “who’s burning all our tokens?”, you read the traces. When you need to do capacity planning, you read the traces.

SMF records are OpenTelemetry spans. The vocabulary changed — “record type” became “span kind,” “job name” became “service name,” “CPU time” became “latency” — but the data model is the same. You’re recording who ran what, when, with what resources, and what happened. You’re writing Type 30 records. You just call them spans now.

Patching Without Breaking

SMP/E — the System Modification Program Extended — was how you applied changes to a z/OS system. PTFs (Program Temporary Fixes), APARs (Authorized Program Analysis Reports), function upgrades — all went through SMP/E. Its job was to maintain the integrity of the system while making changes. It tracked dependencies. It knew which modules were modified by which fixes. It could RESTORE a fix that caused problems, rolling the system back to its previous state.

This sounds simple until you appreciate the stakes. A bad PTF on a production mainframe could bring down the banking system. Not a department. Not a service. The banking system. SMP/E’s job was to make sure that never happened, and mostly it succeeded, through meticulous dependency tracking and the ability to undo what it had done.

Model fine-tuning and RLHF (Reinforcement Learning from Human Feedback) face the same problem at a different layer of abstraction. You’re modifying a running system — applying changes to the model’s behaviour — while trying to maintain its alignment and capability. Fine-tuning changes the model’s responses. RLHF adjusts its boundaries. Both can go wrong in ways that are hard to predict. Both need the ability to roll back when they do.

SMP/E maintained system integrity while applying changes. RLHF maintains model alignment while applying feedback. Both have a RESTORE function for when it all goes wrong. Patching the system without breaking it is still the hardest job in operations, whether the system is an operating system or a neural network.

Contention Is Forever

GRS — Global Resource Serialization — solved one of computing’s oldest problems: two jobs trying to modify the same resource at the same time. On z/OS, GRS managed ENQ/DEQ (enqueue/dequeue) requests to ensure that if Job A was writing to a dataset, Job B had to wait. Resource serialization. Locking. Contention management. The system ensured that shared resources were accessed in an orderly fashion, even when dozens of jobs wanted the same thing simultaneously.

Context window management is resource contention by another name. There’s a finite resource — the context window — and multiple demands on it: your system prompt, your conversation history, your retrieved documents, your tool definitions, and the user’s actual question. They’re all competing for the same limited space. Stuff too much in and something gets truncated or dropped. The context window is a shared resource with more demand than capacity.

Rate limiting is GRS for API calls. Token quotas are GRS for compute. Even something as prosaic as “this model can handle N concurrent requests” is a serialization constraint — if request N+1 arrives, it queues. GRS would recognise the pattern instantly.

Resource contention is the eternal problem of computing. GRS managed it with queues and locks. We manage it with rate limiters and context window budgets. The mechanisms changed. The fundamental challenge — coordinating access to shared resources — never will.

VMs All the Way Down

This one is personal.

VM/CMS on the IBM mainframe was literal virtualization. VM/370, released in 1972, gave each user their own virtual machine — a complete, isolated simulation of the hardware. You logged on and got what appeared to be your own computer. It wasn’t. It was a partition of a shared physical machine, managed by a hypervisor (CP — Control Program) that allocated real resources to virtual machines on demand.

After mainframes, I went to VMware via the internet world of webhosting and cloud-before-cloud with Loudcloud. VMware brought the same concept to x86 hardware. THe excellent Chief Scientist, Mendel Rosenblum, stated this all the time and often criticised the x86 chips.. once for not including virtualization, and second for including it badly.

Each virtual machine got what appeared to be its own computer. It wasn’t. It was a partition of a shared physical server, managed by a hypervisor (ESX) that allocated real resources to virtual machines on demand.

Then came AWS. EC2 (open source alternative to VMware, which is how AWS built it’s business on OSS without funding those projects — a separate chat) instances are virtual machines. Each instance gets what appears to be its own computer. It isn’t. It’s a partition of a shared physical server, managed by a hypervisor that allocates real resources to virtual instances on demand.

And now LLM inference servers run on VMs in the cloud, serving requests from users who each believe they have the model’s undivided attention. They don’t. It’s a shared resource, partitioned and allocated on demand.

I spent my career watching the same idea get reinvented with better marketing. VM/370 gave every user a virtual machine in 1972. VMware did it in 2001. AWS did it in 2006. Each time, the industry acted like it was a new idea. It wasn’t. It was virtualization, every time, from the same lineage, solving the same problem: making expensive shared hardware feel like cheap dedicated hardware.

It’s VMs all the way down. It always has been.

The Ones I’ll Spare You the Deep Dive On

I could keep going. I have more.

ISPF → VS Code. ISPF — the Interactive System Productivity Facility — was the mainframe IDE. Editor, file browser, job submission, output viewing, extensible with custom panels. VS Code has an editor, file browser, task runner, integrated terminal, and extensions. ISPF panels were defined in a panel library. VS Code extensions are defined in a marketplace. Same tool. Better fonts. Nobody’s writing a conference talk about it.

WLM → AI request routing. z/OS Workload Manager classified incoming work, assigned service classes based on business importance, and dynamically routed work to achieve service-level goals. Your batch job for month-end reporting got higher priority than your ad-hoc query. Modern AI routing systems do the same thing — classifying requests by complexity, routing simple queries to smaller models and complex ones to larger models, all to optimise cost and latency against service targets. WLM is now your AI gateway.

Sysplex → multi-region deployments. A mainframe Parallel Sysplex coupled multiple systems together for workload distribution and high availability. If one system failed, the others absorbed its work. Multi-region cloud deployments do the same thing with worse tooling and more YAML. The Sysplex had Coupling Facility, which handled shared state across systems. We have distributed caches and consensus protocols. The Sysplex coupling was tighter, better integrated, and had fewer moving parts. We traded elegance for ubiquity.

The Bit Everyone’s Missing

Here’s the uncomfortable truth that none of the “AI will change everything” narrative accounts for.

The mainframe wasn’t wrong. It was just early.

Centralized compute is powerful. It’s efficient — one big system is cheaper to operate than a thousand small ones, if you can share it effectively. It’s controllable — one system to secure, monitor, and manage. It’s shared — the economics work because the cost is distributed across everyone who uses it.

That model never died. It hid behind layers of abstraction for 30 years. Client-server was centralized compute with a graphical frontend. The web was centralized compute with a browser frontend. Cloud was centralized compute with an API frontend. Each “revolution” changed the interface layer and left the architecture intact. The machine room moved from your basement to someone else’s data centre, but the computing model — powerful shared resource, thin client, mediated access — persisted through every paradigm shift.

Now it’s back in the open, undeniable, with LLMs as the most centralized computing model since the mainframe itself. One model. One provider. One API. Shared across millions of users. The client is a terminal (sorry, a “chat interface” or “agent”). The access is mediated by authentication and rate limits. The usage is metered and billed.

And this is where the framing matters. Not for nostalgia. For operations.

If you think LLMs are “new,” … you behave one way. You experiment blindly. You reinvent solutions that already exist. You discover failure modes the hard way. You build without operational discipline because you don’t know what operational discipline looks like for this kind of system. You make mistakes that were solved decades ago, and you make them expensively.

If you recognise the pattern… you behave differently. You apply proven models for workload management. You implement security architectures that we know work. You build observability from day one because you know you’ll need it. You plan for cost management because you know centralized compute always needs it. You design with operational maturity because you’ve seen what happens without it.

Most organisations are in the first category. That’s expensive. And avoidable.

We Already Solved Half of This

This is the part that should make you angry — or at least frustrated.

We know how to run centralized computing systems. We have decades of operational knowledge. Workload management. Access control. Observability. Cost allocation. Capacity planning. Disaster recovery. Change management. Security architecture. Performance tuning. Chargeback. Audit. Compliance.

All of it exists. All of it was refined over 40 years of running the most critical computing workloads on the planet. Banks. Airlines. Governments. Healthcare systems. The knowledge didn’t disappear. The textbooks are still on shelves. The practitioners are still alive — many of them still working.

But there’s a gap. The people building LLM applications today are, overwhelmingly, not the people who ran mainframes. They came up through web development, mobile, cloud-native architectures. They know distributed systems and microservices and Kubernetes.

People today know how to build, maybe deploy, but not operate.

They don’t know centralized computing because they never had to. The mainframe was already “legacy” by the time they started their careers.

So they’re solving the same problems fresh. Building cost management frameworks that look remarkably like chargeback. Designing security models that echo RACF. Creating observability systems that recapitulate SMF. Inventing operational roles that map one-to-one with sysprogs. Doing all of it from scratch, without the institutional memory that would tell them it’s been done before.

This isn’t a criticism of those people. They’re smart. They’re capable. They’re building good things. But they’re working without a map that already exists, and the result is wasted effort, repeated mistakes, and operational immaturity that didn’t need to happen.

The Real Opportunity

This is where it flips. Because everything I’ve described isn’t a problem. It’s an advantage — if you recognise it.

If you see the pattern, you don’t have to start from scratch. You can study how mainframe shops managed chargeback and adapt those models for AI FinOps. But that mapping doesn’t easily exist. The old guys are, well, old, and they are often retired. And the ones still around, well they think modern stuff is bollocks.

There is a gap. But in the gap, is value..

You can look at how ACF2 implemented “protection by default” and apply that thinking to LLM security. You can examine how CICS achieved transaction isolation and use those principles for sandbox design. You can read how WLM classified and routed work and build better AI request routing.

You stop treating LLMs like magic and start treating them like infrastructure. Infrastructure that needs to be operated, secured, monitored, and paid for. Infrastructure with known failure modes. Infrastructure with proven management patterns.

The question stops being “What can this model do?” and starts being “How do I operate this system safely, efficiently, and at scale?”

That’s a different conversation. A more productive one. And it’s a conversation that 40 years of mainframe operations already contributed half the answers to, if anyone bothers to look.

The real opportunity isn’t in the model. It’s in the operating model. The companies that figure this out first — that bring operational discipline to AI before their competitors do — will build more reliable systems, spend less money, move faster, and avoid the spectacular failures that come from treating critical infrastructure like a toy.

Treat It Like One

LLMs are transformative. I’m not arguing otherwise. But recognising the pattern isn’t enough. You need a playbook.

That’s what we’re building. We call it the Viewyonder Operational Framework (VOF) — a structured approach to operating AI systems with the discipline that 40 years of centralized computing already figured out. Every domain in the framework maps directly to a lesson from this article:

VOF Domain	Mainframe Origin	What It Means for AI
Security	ACF2 / RACF	Protection by default, not by itemisation. Deny-first guardrails.
Observability	SMF records	Telemetry from day one. Every call traced, every token accounted for.
Cost Management	Chargeback / MIPS billing	Token FinOps. Attribution. The immortal spreadsheet, done properly.
Workload Management	WLM / JES2	Request routing, prioritisation, queue transparency.
Isolation	CICS sandboxing	Execution boundaries. Stateless design. Warm-start architecture.
Change Management	SMP/E	Model updates, fine-tuning, and rollback without breaking production.
Access Control	TSO time-sharing	Rate limits, quotas, tiers. Fair allocation of a shared resource.
Operational Roles	Sysprogs	Who runs this thing? Define the priesthood before you need one at 2am.

Eight domains. Each one a problem that was solved before, being solved again from scratch by people who don’t know the prior art exists.

VOF bridges that gap. It takes proven operational patterns — the ones that kept banks running, airlines flying, and governments functioning on mainframes — and maps them onto modern AI infrastructure. Not as nostalgia. As engineering discipline.

We’re developing VOF now, and we’ll be publishing the full framework soon. Because the hardest part of AI isn’t the model. It’s everything around it.

It’s a fucking mainframe.

Now operate it like one.

Steve Chambers is the founder of Viewyonder, a GenAI consultancy that helps organisations build and operate AI systems with the discipline they deserve. He spent the first decade of his career as a mainframe systems programmer before moving through VMware, cloud, and into AI — watching the same architecture get reinvented with better marketing at every stop. He builds Injectionator, a security tool for AI applications, because some lessons from the mainframe era shouldn’t need relearning. If your organisation is building with AI and wants operational maturity that doesn’t start from scratch, get in touch.