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 widely used in telecommunications and financial services for hierarchical database workloads. Performance testing these systems means driving realistic transaction mix at representative concurrency levels and measuring response time against SLAs. This page covers 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 direct 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, CICS and IMS transactions may be reachable via 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 the majority of 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 and require only JMeter’s standard HTTP sampler — no additional 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 that reflects real usage, not just hammer one transaction. A well-designed 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 the appropriate percentage.

Transaction response time and SLAs

CICS transactions have clearly defined response time SLAs, often contractually mandated for banking systems (e.g., 95% of all ACCT inquiries must complete in under 200ms). These translate directly into MaxoPerf failure criteria.

Setting failure criteria in MaxoPerf

After uploading your JMX, configure failure criteria on the test to fail the run automatically if SLAs are breached:

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

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 simply pause. Model this with JMeter timers:

• Constant Timer — a fixed wait between samplers (e.g., 3 seconds). Use 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). More realistic for user behavior.
• Uniform Random Timer — a uniformly distributed wait within a range (e.g., 2–8 seconds). Good when you have a defined think-time range from production telemetry.

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, holding for 30 minutes — regardless of what the Thread Group inside the JMX says.
• The transaction mix percentages defined by your Throughput Controllers still apply.

This separation lets you reuse the same JMX for different load profiles (peak, off-peak, stress) by changing 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. You can compare response times across transaction types at a glance.
• Error rate — CICS errors typically manifest as non-200 HTTP responses (if using CICS Web Services) or SOAP fault bodies. JMeter’s response assertions on SOAP response elements will flag these as errors in MaxoPerf’s error panel.
• Throughput — transactions per second across all types combined.

CICS monitoring correlation

While MaxoPerf shows end-to-end response time as seen by JMeter, your mainframe operations team will see 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). Correlating MaxoPerf’s end-to-end latency with CICS internal CPU time helps isolate whether latency is 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 — this makes the MaxoPerf per-endpoint breakdown immediately readable.
• Model transaction mix based on real production data (CICS SMF records or CICS monitoring output) rather than 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 — skew in the transaction mix will make results incomparable to 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) will typically appear as an error in the body of a successful HTTP 200 response; 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.