CICS/IMS transaction testing

CICS (Customer Information Control System) and IMS (Information Management System) are the two dominant mainframe transaction processing monitors. CICS handles millions of online transactions per day at large banks and insurers. IMS is common in telecommunications and financial services for hierarchical database workloads. To performance-test these systems, you drive a realistic transaction mix at representative concurrency and measure response time against SLAs. This page shows how to structure that test in JMeter and run it through MaxoPerf.

Before you start

• Understand your transaction profile: which transaction codes run most frequently, what their target response time SLAs are, and what your peak concurrent user count looks like.
• If your CICS transactions are exposed through TN3270 green-screen, read TN3270 terminal emulation testing first. This page focuses on HTTP/SOAP-exposed transactions and on metric strategy, which applies to both.
• Coordinate with your mainframe team to confirm authorized load levels and the test LPAR to use.

CICS and IMS access patterns for load testing

Depending on your architecture, you can reach CICS and IMS transactions through several paths:

Access path	Description	JMeter tool
TN3270 terminal	Classic green-screen via terminal emulation	RTE Plugin (see TN3270 page)
CICS Web Services	CICS transactions exposed as SOAP or REST over HTTP	JMeter HTTP Sampler
CICS Transaction Gateway (CTG)	Java-based access to CICS via CTG’s JCA adapter	JMeter Java Request sampler (custom code)
IMS Connect	TCP/IP or HTTP access to IMS message regions	JMeter HTTP Sampler (IMS SOAP) or TCP Sampler
IBM MQ trigger	Submit a message that triggers an IMS or CICS batch transaction	JMS sampler (see MQ page)

For most teams doing CICS/IMS performance testing today, CICS Web Services (SOAP or REST over HTTP) or IMS SOAP gateways are the most practical access path. They need only JMeter’s standard HTTP sampler and no extra plugins. This page focuses on that path.

Modeling a realistic transaction mix

A single CICS system runs hundreds of different transaction codes. Your load test should model the mix of real usage instead of hammering one transaction. A good transaction mix:

1. Identifies the top-N transactions by volume (from CICS monitoring data or CICS SMF records).
2. Assigns a weight to each transaction proportional to its share of real traffic.
3. Models the sequencing: some transactions always follow others (e.g., account lookup always precedes balance update).

Implementing transaction mix in JMeter

Use a Throughput Controller element in JMeter to weight individual transaction Thread Groups or request sequences. Set each Throughput Controller to Percent Executions mode and assign the percentage of executions each transaction should receive.

For example, a simple banking transaction mix might look like:

Transaction	CICS code	Weight
Account inquiry	ACCT	45%
Balance check	BLNQ	30%
Fund transfer	TRNS	15%
Statement request	STMT	10%

In JMeter, nest four Thread Groups (or use a single Thread Group with four Throughput Controller blocks) and set each Throughput Controller to its percentage.

Transaction response time and SLAs

CICS transactions have clearly defined response time SLAs, often written into banking contracts (e.g., 95% of all ACCT inquiries must complete in under 200ms). These map directly to MaxoPerf failure criteria.

Setting failure criteria in MaxoPerf

After you upload your JMX, configure failure criteria on the test so the run fails automatically when an SLA is breached:

• p95 latency for each named sampler < your SLA threshold (e.g., 200ms for ACCT, 500ms for STMT).
• Error rate < 0.1% (under normal load, CICS should return almost no errors).

See Failure criteria pass/fail gates for the configuration walkthrough.

Think time between transactions

Real CICS users do not submit transactions as fast as the network allows. Between transactions, they read the result, enter data for the next step, or pause. Model this with JMeter timers:

• Constant Timer: a fixed wait between samplers (e.g., 3 seconds). Use it when your SLA analysis assumes a fixed think time.
• Gaussian Random Timer: a random wait drawn from a normal distribution (e.g., mean 4s, deviation 1.5s). It is closer to real user behavior.
• Uniform Random Timer: a uniformly distributed wait within a range (e.g., 2–8 seconds). Use it when production telemetry gives you a defined think-time range.

Position the timer element as the first child of the HTTP Request sampler it follows (or at the Thread Group level to apply it globally).

Running in MaxoPerf

Structure your Taurus YAML wrapper to control the ramp and hold independently of the Thread Group settings inside the JMX:

execution:
  - executor: jmeter
    concurrency: 200
    ramp-up: 5m
    hold-for: 30m
    scenario: cics-transaction-mix

scenarios:
  cics-transaction-mix:
    script: cics-transaction-mix.jmx

With this layout:

• The .yml is uploaded as the Entrypoint.
• cics-transaction-mix.jmx is uploaded as a Test asset.
• MaxoPerf drives 200 concurrent VUs, ramping over 5 minutes and holding for 30 minutes, whatever the Thread Group inside the JMX says.
• The transaction mix percentages defined by your Throughput Controllers still apply.

With this split, you reuse the same JMX for different load profiles (peak, off-peak, stress) and change only the Taurus YAML.

Reading the results

After a run, the MaxoPerf Overview tab shows:

• Per-sampler latency: each named HTTP Request sampler (ACCT, BLNQ, TRNS, STMT) appears as a row in the latency breakdown panel, so you can compare response times across transaction types at a glance.
• Error rate: CICS errors usually show up as non-200 HTTP responses (with CICS Web Services) or SOAP fault bodies. JMeter’s response assertions on SOAP response elements flag these as errors in MaxoPerf’s error panel.
• Throughput: transactions per second across all types combined.

CICS monitoring correlation

MaxoPerf shows end-to-end response time as JMeter sees it. Your mainframe operations team sees CPU time, elapsed time and storage usage per transaction from CICS monitoring facilities (CICS SMF 110 records, or real-time data via IBM CICS Explorer). Compare MaxoPerf’s end-to-end latency with CICS internal CPU time to find out whether the latency sits in the CICS application logic or in the network/gateway layer.

Do / don’t

Do:

• Name each JMeter sampler after the CICS transaction code it exercises. The MaxoPerf per-endpoint breakdown is then readable at a glance.
• Base the transaction mix on real production data (CICS SMF records or CICS monitoring output) instead of guessing.
• Set failure criteria matching your actual SLAs, not round numbers.
• Run a short smoke test (5 VUs, 5 minutes) before the full load run to confirm your SOAP/HTTP connectivity and assertions are correct.

Don’t:

• Run all VUs with the same single transaction. A skewed transaction mix makes results impossible to compare with production behavior.
• Forget think time. Without it, each VU submits transactions as fast as the network allows, which is not a realistic model.
• Ignore error panel content. A CICS abend (transaction abend) usually appears as an error in the body of a successful HTTP 200 response, and you need response assertions on the SOAP body to catch it.

Where to go next

• TN3270 terminal emulation testing: if your CICS/IMS transactions are accessed via green-screen rather than HTTP.
• Daily mainframe scenarios: morning peak, end-of-day settlement, and month-end batch patterns using CICS transaction tests.
• MQ and messaging testing: if IMS transactions are triggered via IBM MQ rather than HTTP.
• Failure criteria pass/fail gates: configuring SLA-gated pass/fail in MaxoPerf.
• Mainframe do and don’t: authorization, MIPS cost, and coordination requirements.