I've been doing a lot of work with mainframes lately after several decades of less frequent use, and I noticed that a lot of my colleagues and software industry peers seem to incorrectly believe that mainframes are outmoded legacy technology. They often believe the only reason that they still exist is because of inertia or outsized switching costs. This couldn't be further from the truth.
There is a kernel of truth, though, in some of what my colleagues believe about mainframes: that they're difficult for the uninitiated to understand, that the integration mechanisms are less open and sometimes less accessible than in distributed systems such as web applications, and that, due to the specialization of the niche they inhabit, fluency with these technologies has become something of a dark art.
But with the increase in workflow automation capabilities brought on by the rise of agentic technologies, this niche is moving increasingly into the spotlight.
The Big Iron of Big Business Workloads
Mainframes established dominance in specific niches of big businesses with huge and demanding workloads. Some reasons why:
Enormous transactional throughput
Mainframes are designed to handle sustained high-volume transaction processing, capable of the world's largest workloads in banking, card processing, insurance, airline reservations, securities processing, and so on. If you have a workload where vertical scaling is advantageous, no other platform even comes close.
Very high availability
Mainframes are built for long stretches of continuous operation. Uptime is essentially counted in years. (To those in the know: Sure, there’s a clean IPL now and then, but you get my point.)
Extremely fast single code path execution
For decades, IBM has designed processors to make certain serial latency-sensitive enterprise code paths extremely fast. This involves a rather unusual combination of:
- a high clock speed
- a very large and low-latency cache hierarchy
- a specialized instruction set
- enormous memory bandwidth
- hardware acceleration
- a tightly integrated operating system, database, and transaction stack
Unmatched transactional semantics
Some workloads really should not be “eventually consistent.” That is a performance trade-off that is unacceptable in finance, banking, and transactions involving multiple counterparties.
Workload management
Imagine that you could size and scale your workloads all the way down to prioritization of processes in CPU scheduling, based on the actual quantifiable latency and throughput outcomes required by the business.
These capabilities, sometimes individually but definitely in combination, exist only on the big iron.
The Integrations Are the Platform
Because mainframes were the only platform capable of handling the most critical workloads of serious businesses, they were one of the first systems to be heavily integrated throughout distributed computing architectures. There are a variety of ways that mainframes expose functionality to web and other distributed systems in ways that today's software engineers would recognize:
- z/OS Connect - Exposes functionality over HTTP, JSON, and OpenAPI, accessing transactions or data in CICS, IMS, MQ, Db2, or other business logic.
- Native CICS web services - Typically REST/JSON or SOAP/XML interfaces to CICS transactions and programs.
- z/OSMF - Control the actual z/OS operating system via HTTP and REST/JSON.
- IBM MQ - Message queue integration with asynchronous business operations and events.
- SQL/JDBC/ODBC - Query Db2.
- Many more: CICS Transaction Gateway / JCA; IMS Connect; SOAP web services; etc.
Essentially, in businesses that rely on mainframe workloads as a core transactional platform for the most serious aspects of their business, the mainframe remains a uniquely capable hub, with integration spokes extending to every system in every area of their business.
Beyond the Official API
Despite this high degree of integration, there remains a limitation. The official integration mechanisms only cover what someone chose to expose. Some workflow steps are not exposed via any API. Many of the most frequent transactions were exposed for use and consumption by calling systems. But what about ad hoc usage? And what about newly emerging integration points brought about by a change in a business, or by a merger or acquisition, or a change in the structure of lines of business? In these situations, integration workflows often remain tied to a terminal user interface. Talk to any company that's staying competitive in their industry with significant workflows in terminal-based applications. You'll meet teams of business and data experts working tirelessly to pull together the information they need, as they clean, repair, and integrate detailed account and transaction data.
In addition to the gaps, the terminal applications are often the main way that the most knowledgeable business users who are designing integrated workflows understand and verify the system that they're working with. Automating at the terminal avoids having to translate those familiar application concepts into abstract system concepts that the expert business users can't easily verify.
For business users who work in these terminal applications, seeing and verifying the result there is an important part of completing the workflow. Throughout the years, there have been attempts to automate this, some more successful than others, most of which involve a certain degree of flakiness because the automation system is trying to emulate how a human user would use the terminal application.
The Agents Press Enter
At Monarch, we're enabling this type of automation directly through the terminal to close exactly those types of gaps. We're bringing agentic workflow development and execution to the mainframe. Monarch dynamically explores each application to build a Product Graph. It detects drift and change, and self-heals business actions that fail. It's great to see that we have something to contribute to this rich legacy of consequential business technology. But on a personal level, it's also really nice to be working in a paradigm that was one of my first loves in the technology world. You might say I like my machines big, reliable, and running since 1974. Talk JCL to me, and show me a job that finishes without an abend, and I'm yours.
More coming soon about our adventures in building mainframe dev, test, and demo environments, and what it's been like to vibecode an entire example banking application in COBOL and 370 Assembler!