Daily mainframe scenarios

Mainframe systems face predictable, high-stakes load events. The performance tests you build should reflect these real patterns — not synthetic uniform load — because the timing, sequencing, and concurrency profile of each event type determines which bottlenecks you find. This page describes the four most common mainframe load scenarios for banking, insurance, and similar industries, and explains how to build and run each one in MaxoPerf.

Scenario 1: Month-end batch window soak

What it is

Month-end batch is the highest-risk scheduled event for core banking and insurance systems. Statement generation, interest calculation, GL close, and policy renewals run as a sequence of batch jobs, all of which must complete before the online banking window opens. A batch overrun is a business incident.

Performance testing the batch window validates two things: (1) the individual batch SQL and program logic runs at the required throughput rate, and (2) the end-to-end batch sequence fits within the allowed window under realistic data volumes.

What to model

• Workload type: DB2 bulk update/insert/select at the throughput the batch program must sustain.
• Duration: Match or exceed the actual batch window (typically 4–10 hours overnight). A soak test that runs for the full window duration reveals resource exhaustion that a short test would miss.
• Concurrency: Batch jobs are typically low-concurrency but high-throughput — 2–10 JMeter VUs running SQL at maximum throughput is more realistic than 200 VUs.
• Transaction type: DB2 via JDBC Request sampler (see DB2 and batch testing).

How to run it in MaxoPerf

execution:
  - executor: jmeter
    concurrency: 5
    ramp-up: 1m
    hold-for: 8h
    scenario: month-end-batch

scenarios:
  month-end-batch:
    script: month-end-batch.jmx

• Upload month-end-batch.jmx as Entrypoint, the YAML as Test asset — or flip it so the YAML is the Entrypoint and the JMX is the Test asset.
• Schedule the run to start at the same wall-clock time as the real batch window (e.g., 22:00 UTC) if you want to share infrastructure-level conditions.
• Watch throughput and latency for drift in the second half of the run — a latency increase after hour 4 of an 8-hour window indicates buffer pool saturation, log space exhaustion, or growing lock waits that will cause real batch overruns.

What to look for in MaxoPerf

• Throughput flat line — the batch program is sustaining its required SQL rate throughout.
• Latency drift — p95 climbing in the back half of the run signals a resource that degrades over time (DB2 buffer pool, log archive speed, or JVM heap in a Java batch framework).
• Error rate uptick — SQLCODE -911 (deadlock) or -904 (resource unavailable) errors indicate contention under sustained load.

---

Scenario 2: Online banking morning peak

What it is

When the online banking window opens — typically early morning — a large fraction of daily users log in and transact within the first 1–2 hours. This produces a sharp ramp followed by a sustained peak. The CICS transactions handling account inquiry, balance check, and fund transfer must maintain sub-second response times throughout.

What to model

• Workload type: CICS transaction mix via TN3270 (RTE plugin) or CICS Web Services (HTTP sampler), depending on your interface.
• Load profile: Rapid ramp (5–10 minutes) to peak VU count, then a 60–90 minute hold at peak, then gradual decline.
• Transaction mix: Weight transactions by real production ratios (e.g., 50% account inquiry, 30% balance, 15% transfer, 5% other). See CICS/IMS transaction testing.
• Think time: 3–8 seconds between transactions per VU.

How to run it in MaxoPerf

Use a Taurus YAML with staged execution to model the ramp and hold:

execution:
  - executor: jmeter
    concurrency: 500
    ramp-up: 10m
    hold-for: 90m
    scenario: morning-peak-cics

scenarios:
  morning-peak-cics:
    script: morning-peak-cics.jmx

• 500 concurrent VUs represents 500 simultaneous terminal sessions or HTTP connections to CICS.
• The 10-minute ramp mirrors the natural ramp of real users logging in progressively.
• The 90-minute hold covers the full morning peak window.

What to look for in MaxoPerf

• p95 CICS transaction latency — must stay within SLA (e.g., 95% of all ACCT inquiries under 200ms) throughout the full hold period, not just at the start.
• Error rate — CICS abends or session rejections indicate CICS region running at capacity.
• Throughput stability — a throughput plateau that drops mid-run without VU reduction indicates a bottleneck (CICS region running low on tasks, DB2 thread exhaustion, or MQ channel saturation).

---

Scenario 3: End-of-day settlement

What it is

End-of-day (EOD) settlement in banking and securities involves reconciling all day’s transactions, posting to the GL, and generating confirmations and position reports. It runs as a hybrid workload: a burst of online transactions (settlement instructions arriving from trading desks and counterparties) overlapping with the start of batch settlement processing. The window is typically 2–4 hours in the late afternoon.

What to model

• Workload type: A combination of online CICS/IMS transactions (settlement instruction posting) and MQ message processing (confirmation messages sent to counterparties). Model both concurrently.
• Profile: A spike in online VUs at the start of the window (trading desks submitting final instructions), followed by declining online load as batch takes over.
• MQ component: Settlement confirmations and position updates published to MQ queues, processed by downstream systems.

How to run it in MaxoPerf

Because this scenario mixes CICS HTTP and MQ, it is best represented as two separate MaxoPerf tests run concurrently during the same test window — or as two Thread Groups within a single JMX with different concurrency and timers:

JMX Thread Group 1 — CICS settlement instructions (HTTP):

• 200 VUs, 30-minute hold for the instruction submission burst.
• Transaction: POST to CICS Web Service endpoint, assert HTTP 200 + SOA success code.

JMX Thread Group 2 — MQ confirmation messages:

• 20 concurrent MQ producers, 2-hour hold (MQ continues after CICS load drops).
• JMS Point-to-Point, request-only mode, 50 messages/second target.

execution:
  - executor: jmeter
    concurrency: 200
    ramp-up: 5m
    hold-for: 2h
    scenario: eod-settlement

scenarios:
  eod-settlement:
    script: eod-settlement.jmx

What to look for in MaxoPerf

• MQ put latency — should remain stable as the CICS load declines. A latency increase during the CICS burst indicates MQ channel contention with the CICS internal MQ usage.
• CICS transaction SLA during burst — the first 30 minutes (instruction submission window) are the critical period.
• Error rate on MQ — message expiry timeouts indicate the consumer cannot keep pace with settlement confirmation volume.

---

Scenario 4: Insurance claims surge

What it is

Catastrophic events — storms, floods, large recalls — trigger a sudden surge in insurance claim submissions. Claims systems running on CICS or IMS must process the increased load without degradation, and the claim intake pipeline (often backed by MQ) must handle the burst without queue depth growth that delays acknowledgments.

What to model

• Workload type: CICS or IMS transaction for claim intake (policy lookup + claim record creation + DB2 insert). Possibly MQ-triggered downstream adjudication.
• Profile: A spike test — rapid ramp to 3–5× normal VU count over 2–5 minutes, a hold at peak for 30–60 minutes, then decline. See Spike test for the general spike pattern.
• Data: Each VU submits a claim for a different policy number — use CSV Data Set Config with a large CSV of policy IDs to avoid cache effects.

How to run it in MaxoPerf

execution:
  - executor: jmeter
    concurrency: 1000
    ramp-up: 3m
    hold-for: 45m
    scenario: claims-surge

scenarios:
  claims-surge:
    script: claims-surge.jmx

1,000 VUs represents a 5× surge over a normal 200-VU load.

What to look for in MaxoPerf

• Claims intake latency under spike — how quickly does p95 latency degrade when the VU count jumps? A fast, large latency jump indicates limited elasticity.
• DB2 insert throughput — new claim records are written to DB2; watch for insert latency growth indicating lock contention on the claims table.
• MQ queue depth (monitored externally by your MQ team during the MaxoPerf run) — queue depth growth during the surge indicates downstream adjudication cannot consume messages fast enough.
• CICS region capacity — if the CICS region rejects sessions at the peak (error rate spike), the system has a hard limit that needs an architectural response (additional CICS regions, horizontal scaling of the gateway layer).

---

Common setup steps for all scenarios

1. Author the JMX locally in JMeter Desktop with your target interface configured (RTE sampler, HTTP sampler, JMS sampler, or JDBC sampler). Validate it with 1–5 VUs against a test LPAR.
2. Remove listeners (View Results Tree, Summary Report) before uploading.
3. Upload to MaxoPerf: open the test → Files tab → upload JMX as Entrypoint (or the Taurus YAML as Entrypoint with JMX as Test asset).
4. Upload CSV data files as Test assets if your JMX uses CSV Data Set Config elements.
5. Configure failure criteria on the test to match your SLAs.
6. Notify mainframe ops before starting — give them the start time, VU count, target LPAR, and expected duration.
7. Run and monitor both MaxoPerf results and mainframe ops’ monitoring tools in parallel.

Where to go next

• TN3270 terminal emulation testing — building the JMX for CICS green-screen scenarios.
• CICS/IMS transaction testing — transaction mix and SLA configuration for scenarios 2 and 4.
• MQ and messaging testing — MQ configuration for scenarios 3 and 4.
• DB2 and batch testing — DB2 JDBC setup for scenario 1.
• Soak / endurance test — general soak guidance for month-end batch.
• Spike test — spike pattern for the claims surge scenario.
• Mainframe do and don’t — authorization, MIPS cost, and coordination rules for all scenarios.