Mainframe Testing with HyperExecute

Why Enterprises Still Rely on Mainframes

Though we are living in an Agentic era where autonomous agents are reshaping how software gets built and tested, mainframes still hold their relevance. Businesses including banks, airlines, healthcare, utilities, insurance firms, and government systems still run on mainframes.

Mainframes are still the preferred choice, as mainframes have the capacity of processing huge volumes of transactions every day. Enterprises depend heavily on these systems because they offer non-negotiable ACID compliance, which ensures absolute reliability for managing transactions, records, and core business functions.

Mainframe computers can routinely process close to a billion transactions^[3] a day in real-time. Beyond their exceptional processing speeds, mainframes deliver the hardened security architectures, advanced encryption, and robust audit capabilities accumulated over decades, satisfying the demands of government and financial regulators.

To meet strong security objectives, mainframe customers normally add a sophisticated security manager product^[4] to transform the company's security policy into a usable plan. The Z family of mainframes provides a highly secure system for processing large volumes of heterogeneous applications that access critical data^[4].

Mainframes exhibit scalability both on software and hardware fronts, with many enterprises able to lower their Total Cost of Ownership (TCO)^[5] which includes machine and execution costs.

Batch processing and Online Transaction Processing (OLTP) are the two main categories (including web applications) of enterprise workload demands. As the name suggests, batch workloads efficiently process large volumes of data and help generate critical business outputs such as financial statements and sales reports. OLTP workloads support high-volume, mission-critical transactions with exceptional scalability, reliability, and sub-second response times.

Figure 1: Typical mainframe workloads [Image Source]

An ATM transaction is a classic example of high-volume and low-latency workload that can be efficiently handled by mainframes. As per IBM, IBM zSystems (or IBM Z)^[6] is used by 44 of the top 50 banks and all top 10 insurers worldwide. This is over and above its usage in government, healthcare, airline, and retail sectors.

Challenges With Mainframe Testing

Apart from challenges around modernization of mainframe applications, testing also remains one of the critical challenges for enterprises that leverage IBM Z for business-critical applications. As per a report, close to 60 percent^[7] mainframe specialists are over the age of 50 and many of them are nearing retirement. Most IBM Z applications still run on green screen interfaces, which in some cases are considered as technical debt^[8].

These 3270 terminal sessions are built around fixed-position text fields and function keys, with no accessible UI elements for automation! Hence, the challenge is two-fold, as there is a dearth of mainframe specialists who understand these systems and the underlying technology to test them.

Figure 2: Sample 3270 terminal session [Image Source]

Here are some of the major technical challenges associated with testing legacy mainframe applications:

Session-based, stateful terminal sessions

As stated in the official IBM documentation, many traditional green screen programs (or applications) are accessed through 3270 terminal sessions. These applications run on CICS (Customer Information Control System), IMS (Information Management System), or TSO (Time Sharing Option).

Conversational and stateful in nature, the host maintains the user's interaction state throughout the terminal session. The context of the transaction, user inputs, and prior navigation collectively dictate the layout and state of each subsequent screen.

Figure 3: Where state actually lives in a 3270 / CICS application [Image generated using AI]

As the tests are dependent on the previous step, any deviation in the application flow or synchronization causes test flakiness, eventually resulting in test failure. Owing to this, state management is one of the prime challenges in mainframe test automation.

As cloud computing, AI, and other digital transformation technologies advance, mainframe operators are increasingly forced to modernize to avoid technical obsolescence. As stated earlier, mainframe modernization projects come with its own set of challenges since the backend still runs on the same shared IBM Z capacity.

What HyperExecute Brings to Mainframe QA

Be it a modernized service built on the identical z/OS backend, or a slow legacy green-screen application that continues to execute COBOL transactions from decades ago, changing the interface does not eliminate the infrastructural overhead required to deploy, distribute, and validate tests.

HyperExecute from TestMu AI closes the mainframe QA infrastructure gap, regardless of whether you have a green-screen application or a modernized one that communicates over REST or SOAP. Akin to a cloud grid that can be leveraged for manual and automated testing, HyperExecute for mainframe testing brings on-demand test orchestration via which you can provision fresh VMs and install s3270/x3270 emulators on demand!

HyperExecute automatically provisions a clean VM for each run, dynamically installing all required suite components, including mock servers, emulator binaries, and Python dependencies. Enterprises running mainframe tests at scale can shed that infrastructure burden, since HyperExecute takes it on for them. Check out the official HyperExecute documentation to learn about its key benefits.

Green-screen mainframe test suites are inherently slow to run, as each test opens its own terminal session and navigates a multi-screen flow. The smart auto-split strategy from HyperExecute is instrumental in distributing tests across multiple VMs efficiently for parallel testing. This ensures optimal utilization of concurrency by allowing you to split tests based on various levels, such as files, modules, and scenarios.

Figure 4: Key benefits of auto-split strategy in HyperExecute [Image Source]

Parallel execution at scale with JIT (Just-in-time) testing infrastructure provisioned by HyperExecute helps reduce the regression execution cycles by a huge margin. With HyperExecute, you can define the operating system (i.e., via the runson configuration attribute) on which the QA team intends to run the tests.

All the configuration parameters required to execute mainframe emulator tests on HyperExecute are defined in a YAML file. You can find the complete list of supported configuration options in the HyperExecute YAML documentation. A sample stripped-down HyperExecute YAML is shown below:

---
version: 0.1

# Run all tests on Ubuntu Linux VMs (required for s3270 install)
runson: linux

# Automatically split discovered test files across parallel machines
autosplit: true

# Number of parallel VMs to spin up
concurrency: 5

# Retry each failed test suite once before marking it as failed
retryOnFailure: true
maxRetries: 1

# Record a video for each test scenario on HyperExecute
captureScreenRecordingForScenarios: true

# Timeout values in minutes
globalTimeout: 30
testSuiteTimeout: 30
testSuiteStep: 10

HyperExecute records a native video of every test scenario when captureScreenRecordingForScenarios configuration attribute is set to true. This visual evidence is useful for QA & dev teams, compliance teams, and business stakeholders since they provide macro and micro-level insights into the test execution.

Regardless of the testing framework you choose to complete the task, HyperExecute executes it seamlessly. This applies whether you are using the Robot Framework equipped with robotframework-mainframe3270 to handle legacy green-screen workflows, or employing standard API/UI testing frameworks for a modernized layer that operates on the identical backend.

Simply put, the players (test scripts, pipeline, etc.) largely stay the same. What moves is where they run: HyperExecute becomes the new goal post.

Demo: Running Mainframe Test Suites on HyperExecute

In order to demonstrate automation of Mainframe applications, particularly green-screen applications, we would be using the Mainframe3270 Robot framework library.

The library is based on the py3270 project, a Python interface to x3270, an IBM 3270 terminal emulator. It provides an API to a x3270 or s3270 subprocess. You can find more details about it in robotframework-mainframe3270 on PyPi. To execute tests on the TestMu AI cloud, you need access to HyperExecute on TestMu AI.

Execution

Before the local execution, start the mock FNB mainframe TCP server (port 3271) in the background by running the command python mock_server/fnb_mock_server.py & on the terminal.

The mock server is needed so that the Robot framework test suites have something deterministic to test against in CI/HyperExecute, without needing a real z/OS mainframe or an x3270/ws3270 terminal emulator. Once the server is started, it starts listening to the incoming requests at port 3271 (i.e., FNB mock 0.0.0.0:3271).

Run the command robot --outputdir results tests to trigger the tests locally. As seen below, the test execution is successful.

For more details on local execution, we recommend checking out the steps mentioned in the run locally in ReadMe.

For cloud execution on HyperExecute, first download the HyperExecute CLI that aligns with the host OS. Now run the following command on the terminal for triggering the tests on HyperExecute:

./hyperexecute --config yaml/hyperexecute-mainframe-testing.yaml --download-report --download-logs

As seen below, the job was submitted in autosplit mode on Linux runners with a concurrency of 5, uploading the payload, and test code archive successfully. This is inline with the steps mentioned in the HyperExecute YAML.

Core banking transactions are successfully processed end-to-end on the HyperExecute cloud grid, confirming that the mainframe banking GUI functions correctly when driven via the x3270 terminal emulator.

For more details on cloud execution, we recommend checking out the steps mentioned in the Run on HyperExecute in ReadMe.

It's A Wrap

Mainframes still remain the foundational backbone of today's banking, healthcare, and government systems. As the IBM Z platform continuously modernizes by embracing hybrid cloud environments and containerization, the testing methodologies must evolve in tandem. Bringing green-screen 3270 testing into a faster, cloud-based workflow proves that even decades-old interfaces can keep up with modern engineering speed.

With HyperExecute from TestMu AI, teams can run multiple 3270 terminal sessions in parallel, cut down lengthy regression cycles by a huge margin, and get consistent, reliable results across every green screen transaction. All of these benefits without doing any changes in the implementation of mainframe test suites!

Sources and References Used

• [1] Maximizing the value of Z with IBM Apptio Mainframe Total Cost of Ownership (TCO) - IBM (October 2025)
• [2] Server and cyber resiliency with IBM Z - IBM
• [3] What is a mainframe? - IBM Think
• [4] Mainframe strengths: Security - z/OS Basic Skills, IBM Documentation
• [5] Mainframe strengths: Scalability - z/OS Basic Skills, IBM Documentation
• [6] IBM zSystems fundamentals: An introductory Q&A - IBM Developer
• [7] Top 5 challenges of mainframe modernization projects - Amdocs (November 2023)
• [8] The interface to z/OS and the green screen myth - EXECPGM (May 2021)
• [9] Maximizing the value of Z with IBM Apptio Mainframe Total Cost of Ownership (TCO) - IBM Newsroom (October 2025)