Skip to content
MaxoPerf MaxoPerf docs

Mainframe do and don't

Mainframe performance testing carries risks that cloud workloads do not. CPU is billed in MIPS per month. Shared LPARs host production-adjacent workloads. A runaway test can trigger CICS abends, MQ channel saturation or DB2 lock storms that hit unrelated workloads on the same system. Follow this page before and during any mainframe load test run with MaxoPerf.

Authorization and coordination

Section titled “Authorization and coordination”

Do: get written authorization before any test. Every mainframe load test needs explicit approval from the system owner, the mainframe operations team, and (in regulated industries) the change management process. Unauthorized load on a production or production-adjacent LPAR is a potential compliance incident. Get approval that covers the target LPAR and subsystem, the authorized VU count, the time window, and the person responsible for stopping the test if needed.

Do: notify mainframe operations before starting. Even authorized tests need a named contact in mainframe ops who knows the test is running. Give them the start time, expected duration, target LPAR, maximum VU count and your contact information. Ask them to watch CICS monitoring data, DB2 accounting and MQ channel statistics during the run. Their monitoring adds context that MaxoPerf’s client-side metrics alone cannot provide.

Do: run on a dedicated test LPAR where possible. The safest mainframe load test runs on an LPAR dedicated to testing and isolated from production workloads. If you must use a shared LPAR (common in mid-size organizations), make sure your test window does not overlap with production batch jobs, online peak hours or other authorized tests.

Don’t: run against production subsystems without explicit sign-off. “It’s just a read-only query” is not enough justification. Read-only load can still exhaust DB2 buffer pools or consume CICS region storage and hurt production users. That is why the change management process exists.

Don’t: start a test without confirming the stop procedure. Before every run, confirm: who can stop the MaxoPerf run, how quickly MaxoPerf’s runners release connections when a run is cancelled, and whether the mainframe ops team can kill connections independently if needed (e.g., CICS task purge, MQ channel reset, DB2 CANCEL THREAD).

MIPS cost and capacity

Section titled “MIPS cost and capacity”

Do: understand MIPS implications before setting VU count. Every CICS transaction, DB2 query and MQ put/get consumes mainframe CPU cycles measured in MIPS (Million Instructions Per Second). MIPS capacity is finite and shared, and excess consumption can throttle other workloads via WLM (Workload Manager) policy. Ask your mainframe team for the expected MIPS consumption per transaction at your target VU count, and confirm the test LPAR has that headroom.

Do: start with a low VU count and ramp slowly. Begin with 5–10 VUs and a long ramp-up (10 minutes or more) instead of jumping straight to peak concurrency. Ops then has time to watch MIPS consumption and step in if it is higher than expected. Increase in stages (10 → 25 → 50 → 100 VUs) and validate at each step.

Do: monitor MIPS during the test. Ask mainframe ops to report live MIPS consumption from IBM RMF (Resource Measurement Facility) or an equivalent monitoring tool during the MaxoPerf run. If MIPS consumption approaches the LPAR cap, either reduce VUs or accept that you have found the system’s throughput limit.

Don’t: hammer shared LPARs without coordinating the MIPS budget. A test that consumes 80% of an LPAR’s MIPS while other workloads are running makes WLM throttle your test, the other workloads, or both. Neither the test results nor the co-resident workloads can then be trusted.

Don’t: run multi-hour soak tests without scheduling them during low-activity windows. Run month-end batch soak tests and extended DB2 soak tests during known low-activity periods (overnight, weekends), when the LPAR has headroom and no production-critical workloads share it.

Test design

Section titled “Test design”

Do: model realistic think time. Real terminal users pause between screen submissions, and real applications have connection pools that limit concurrency. Without think time, JMeter VUs drive the LPAR far harder than real users would. Add Constant Timer or Gaussian Random Timer elements to model realistic pauses (typically 3–8 seconds for CICS terminal users, near-zero for batch SQL).

Do: use a dedicated test schema and test data. Never load-test against production data. Use a dedicated DB2 schema with representative row counts and realistic data distributions. Test CICS transactions against test accounts, not live customer accounts. If your test data is too small (e.g., a table with 1,000 rows tested as if it had 10 million), caching effects make the results optimistic.

Do: name JMeter samplers descriptively. Use CICS transaction codes, SQL operation names, and MQ queue names as sampler names (e.g., ACCT inquiry, Balance update, Settlement MQ put). These names appear in MaxoPerf’s per-endpoint breakdown and in your results report. Sampler names like JDBC Request or JMS Sampler 1 make results unreadable.

Do: capture MIPS and CPU with ops, in addition to MaxoPerf metrics. MaxoPerf measures end-to-end client-side latency. Mainframe performance analysis also needs server-side data: DB2 accounting (SMF 101), CICS SMF 110, WLM reports and RMF CPU utilization. Collect both sides. Client latency shows what users experience, and server metrics tell you why.

Don’t: run the same test repeatedly without clearing state. DB2 buffer pools warm up over repeated runs. MQ reply queues may collect stale messages, and CICS dynamic storage may be in a different state. Clear residual messages from MQ queues, check DB2 buffer pool state with ops, and allow a cooling period between runs so each test starts from a comparable baseline.

Don’t: use production JCL or production MQ queues in tests. Even without production data, submitting JCL to a production JES subsystem or putting messages to a production MQ queue can trigger real downstream processing. Use dedicated test JES, test MQ queue managers, or test CICS regions where available.

Plugin and driver management

Section titled “Plugin and driver management”

Do: verify JMeter plugin availability in MaxoPerf before designing your test. The JMeter runner image in MaxoPerf includes a defined set of plugins and JARs. Before you build a test that relies on the RTE plugin, IBM MQ JMS JAR or DB2 JDBC driver, confirm with MaxoPerf support that the runner image has them. If it does not, ask for them to be added. Do not work around it by uploading unverified JARs without support guidance.

Do: test locally first. Run every JMX locally in JMeter Desktop with a single thread against the test LPAR before you upload it to MaxoPerf. Catch connection errors, wrong JNDI names, incorrect terminal coordinates and SQL syntax issues locally, where iteration is fast. In a MaxoPerf run, a configuration error wastes a test window.

Don’t: upload JMX files with absolute paths. JMeter test plans that reference CSV files, JAR files or scripts by absolute local path (e.g., /Users/yourname/tests/data.csv) fail in MaxoPerf because the runner does not have that path. Use relative filenames only and upload all referenced files as Test assets.

Don’t: include listener elements in uploaded JMX files. JMeter listeners (View Results Tree, Aggregate Report, Summary Report) add CPU overhead and produce output that MaxoPerf does not use. Remove all listeners before uploading. MaxoPerf’s Taurus reporting overlay captures the metrics instead.

Where to go next

Section titled “Where to go next”