Skip to content
MaxoPerf MaxoPerf docs

Mainframe do and don't

Mainframe performance testing carries risks that do not apply to cloud workloads. CPU is billed in MIPS per month; shared LPARs host production-adjacent workloads; and a runaway test can trigger CICS abends, MQ channel saturation, or DB2 lock storms that affect unrelated workloads on the same system. Follow the guidance on 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 must have 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 not a learning exercise — it is a potential compliance incident. Obtain 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 should have 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 monitor CICS monitoring data, DB2 accounting, and MQ channel statistics during the run. Their monitoring gives 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 a LPAR dedicated to testing, isolated from production workloads. If you must use a shared LPAR (common in mid-size organizations), ensure 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 sufficient justification. Even read-only load can exhaust DB2 buffer pools or consume CICS region storage, affecting production users. The change management process exists for this reason.

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 your mainframe ops team has a way to 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; 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) rather than jumping immediately to peak concurrency. This gives ops time to observe MIPS consumption and intervene if it is higher than expected. Increase in stages: 10 → 25 → 50 → 100 VUs, validating 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 will cause WLM to throttle your test, throttle the other workloads, or both — making both the test results and the co-resident workloads unreliable.

Don’t — run multi-hour soak tests without scheduling them during low-activity windows: Month-end batch soak tests and extended DB2 soak tests should run during known low-activity periods (overnight, weekends) when the LPAR has headroom and no production-critical workloads are co-resident.

Test design

Section titled “Test design”

Do — model realistic think time: Real terminal users pause between screen submissions; 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 will make 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, not just MaxoPerf metrics: MaxoPerf measures end-to-end client-side latency. Mainframe performance analysis requires server-side data: DB2 accounting (SMF 101), CICS SMF 110, WLM reports, and RMF CPU utilization. Collect both sides. Client latency shows you what users experience; 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 accumulate stale messages; CICS dynamic storage may be in a different state. Clear residual messages from MQ queues, verify DB2 buffer pool state with ops, and allow a cooling period between runs to ensure each test starts from a comparable baseline.

Don’t — use production JCL or production MQ queues in tests: Even if production data is not involved, 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 building a test that relies on the RTE plugin, IBM MQ JMS JAR, or DB2 JDBC driver, confirm with MaxoPerf support that the required components are in the runner image. If they are not, request their addition — 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 uploading to MaxoPerf. Catch connection errors, wrong JNDI names, incorrect terminal coordinates, and SQL syntax issues locally where iteration is fast, not in a MaxoPerf run where 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) will 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”