Skip to content

Mainframe performance testing

Mainframe systems process the majority of the world’s largest financial transactions, insurance policy updates, and airline reservations — not because of legacy inertia, but because they continue to deliver unmatched throughput and reliability at scale. IBM z/OS systems running CICS, IMS, and DB2 handle hundreds of millions of transactions per day at major banks, insurers, and carriers. Before a release, before a capacity change, or before a month-end batch window, performance testing those systems is mandatory.

This section covers how to author JMeter-based load tests for mainframe workloads and run them at scale through MaxoPerf’s JMeter engine.

Why mainframe performance testing still matters

Section titled “Why mainframe performance testing still matters”

Banking core ledgers, insurance policy administration, and airline passenger service systems (PSS) share a common profile: they cannot be offline, they must sustain bursts (morning peak, end-of-day settlement, month-end batch), and a performance regression can mean missed SLAs with regulatory consequences. On-premises IBM Z hardware is sized for a peak load profile — validating that profile requires realistic load tests before it arrives in production.

Mainframe workloads are not plain HTTP. The performance characteristics you need to measure depend on the interface your application exposes:

InterfaceUsed forHow you test it
TN3270 / TN5250 green-screenCICS transactions via terminal emulationJMeter RTE Plugin (TN3270/TN5250 sampler)
CICS Web Services / HTTPCICS services exposed over HTTP or SOAPStandard JMeter HTTP sampler
IMS Connect / IMS SOAPIMS message regions via TCP or SOAPJMeter HTTP or TCP sampler
IBM MQ (MQI / JMS)Message queueing, batch trigger messagingJMeter JMS Point-to-Point sampler
DB2 via JDBCDirect SQL to DB2 for batch or reporting workloadsJMeter JDBC Request sampler
Batch jobs (JCL / REXX)Long-running batch processing windowsSoak-style test against the orchestration layer

MaxoPerf runs Apache JMeter natively. You author a .jmx test plan in JMeter Desktop — adding the appropriate mainframe plugin or sampler for your target interface — then upload it to MaxoPerf. From there, MaxoPerf handles distribution across its runner fleet, real-time metrics collection, and results visualization. The mainframe specifics live entirely in your JMX; MaxoPerf executes it at whatever scale you need.

The JMeter ecosystem has mature plugins for TN3270/TN5250 terminal emulation (the RTE plugin), and JMeter ships with JMS and JDBC samplers out of the box. Combined, these cover the most common mainframe performance testing scenarios.

Decision table — which page to read first

Section titled “Decision table — which page to read first”
Your scenarioGo to
You want to understand which JMeter plugins handle mainframe protocolsJMeter plugins for mainframe
You are testing green-screen CICS transactions via TN3270TN3270 terminal emulation testing
You are measuring CICS or IMS transaction response time under loadCICS/IMS transaction testing
You are testing IBM MQ message throughput and queue depthMQ and messaging testing
You are running DB2 queries or validating batch windowsDB2 and batch testing
You want ready-to-use scenario descriptions for real workloadsDaily mainframe scenarios
You want a do/don’t list specific to mainframe load testingMainframe do and don’t

If you are new to mainframe performance testing with MaxoPerf, follow this order:

  1. JMeter plugins for mainframe — understand the tools before picking a scenario.
  2. The page matching your target interface (TN3270, CICS/IMS, MQ, or DB2).
  3. Daily mainframe scenarios — end-to-end examples for real workload patterns.
  4. Mainframe do and don’t — safety and coordination guidance before you run anything.

Last updated: