Control interval splits are the price VSAM pays to keep keys ordered when a CI runs out of room. In healthy systems splits happen occasionally and quietly. In troubled systems they cluster around bad FREESPACE choices, tiny CISZ values, or application insert patterns that hammer one key range. This troubleshooting page helps beginners tell split storms apart from other performance villains, read the operational signals, and choose mitigations that do not trade away all sequential scan efficiency. It assumes you already understand what a CI split is mechanically; here the focus is diagnosis, business communication, and an ordered response playbook.
Applications rarely log "CI split occurred." Instead users feel uneven response times or batch steps that used to finish in twenty minutes now finish in forty. Without LISTCAT trending, teams blame network or database tiers first. Building a habit of monthly split counters for volatile clusters turns those mysteries into measurable regression lines you can attach to releases, marketing events, or regulatory filing spikes.
| Symptom | Check | Likely lever |
|---|---|---|
| End-of-month batch doubles duration | LISTCAT CI splits; compare to prior month same calendar window | FREESPACE CI percent or CISZ versus insert volume |
| Online response spikes only on one key range | Key histogram; duplicate key chains | Hot CI; consider key leading field or partition |
| Splits jump after application release | Release notes for extra columns or REWRITE length growth | Record expansion; variable length max |
Both can slow inserts, but CA splits move roughly half the CIs in a control area and cost more I/O. If LISTCAT shows CA splits climbing while CI splits look modest, your second FREESPACE number may be zero or your CA geometry may be mismatched. If CI splits dominate, focus on intra-CI slack and record expansion first. Jumping straight to CA tuning when the real issue is CI-level packing wastes time.
Programs that widen variable-length rows on every update consume free bytes inside CIs faster than static rows. Even perfect FREESPACE from initial load can be exhausted if REWRITE patterns grow payloads. Work with developers to log maximum observed lengths after releases.
Two jobs inserting into the same hot key range serialize through the same CIs, amplifying splits. Scheduling changes sometimes mitigate more cheaply than structural redefine.
Escalate to storage architecture when split counters accelerate after hardware migration, when CA splits appear on clusters that never had them before, or when LISTCAT and SMF disagree because of catalog duplication suspicions. Bring charts, not adjectives.
While LISTCAT is the home base for split statistics, SMF record types your site enables can correlate channel busy time with insert windows. RMF or equivalent monitors may show DASD service times climbing without CPU growth—a hint that structural I/O dominates. None of those tools label a spike "CI split" directly, but aligning timestamps across LISTCAT snapshots, batch schedules, and SMF dashboards builds a credible story for change boards. Beginners should partner with performance analysts instead of screenshotting a single counter in isolation.
When you change FREESPACE or CISZ after diagnosing splits, paste before-and-after LISTCAT excerpts into the change record with the business date range covered. Future you will thank present you when someone asks why values look generous three years later. Institutional memory decays faster than DASD wears out.
A CI split is like refolding a stuffed drawer when you add another sock. A problem is when you must refold every minute because nobody left any empty folds—then getting dressed takes forever. Fix the drawer rules (FREESPACE and size), not the child's feet (the key), unless the feet suddenly grew (record expansion).
1. What is the first data point to collect for suspected CI split pain?
2. Which change often reduces CI split rate for insert-heavy KSDS?
3. CI split versus CA split: which is cheaper?