CI size tuning (VSAM performance)

Control interval size (CISZ) is one of the few DEFINE CLUSTER knobs that permanently shapes how many bytes move every time VSAM touches the disk. Pick a CISZ too small for your maximum record and DEFINE fails or forces awkward spanned-record designs. Pick it too large for random workloads and every GET drags neighbors you never needed into the buffer pool. Pick it too tight for insert-heavy KSDS segments and CI splits multiply. This page is a beginner-friendly tuning guide: it connects CISZ to the anatomy of a CI, contrasts sequential and random goals, explains how FREESPACE cooperates, and outlines a rebuild path when you must change geometry after go-live.

What CISZ really controls

A control interval is the unit of physical transfer between DASD and VSAM buffers. Inside the interval VSAM stores logical records, free space, and descriptor fields that describe where each record begins. CISZ therefore caps how much data fits before VSAM must split or chain. Larger intervals mean fewer intervals per control area but heavier each read. Smaller intervals mean finer granularity but more index pointers per megabyte of user data. You are balancing I/O weight, split frequency, and cache footprint—not chasing a mythical universal best number.

Start from record geometry

Maximum logical record length

Gather the largest possible row your application can write, including variable-length maximum and any expansion fields you plan to add. CISZ must leave room for VSAM overhead bytes; consult your shop standards for the exact slack. If you compress, remember the physical CI still obeys CISZ while logical expansion happens inside VSAM services.

Average occupancy

If average rows are tiny compared to maximum, sequential scans still read whole CIs. That may be acceptable for month-end batch but painful for OLTP. Sometimes splitting business data into hot versus archive clusters yields better CISZ choices than forcing one geometry on both workloads.

Workload matrix

CISZ thinking by dominant pattern
PatternCISZ hintWatch out
Heavy sequential reportingPrefer larger CISZ aligned to half-track multiples for 3390 efficiencyStill respect maximum record + RDF overhead
Random online GETs by keyModerate CISZ so each I/O does not over-fetch unrelated rowsHot keys in one CI create latch-like contention on that CI
Volatile inserts in key orderBalance CISZ with generous FREESPACE CI percentTiny CISZ plus low free space maximizes splits

FREESPACE as the other half of the equation

FREESPACE reserves empty bytes inside each CI (first number) and free CIs inside each CA (second number). A perfectly chosen CISZ with zero CI free space still splits the moment inserts arrive. Conversely, enormous FREESPACE with a tiny CISZ cannot save you because there is not enough contiguous room per interval. Tune both: pick CISZ large enough for multi-record occupancy, then reserve CI percent for insert corridors predicted by key clustering analysis.

Half-track alignment culture

Many performance guides recommend aligning CISZ to half-track boundaries on 3390-class devices to reduce wasted track space and channel overhead. Modern storage virtualizes devices, yet the habit remains because modeling tools and senior reviewers expect it. When in doubt, ask capacity planning for the preferred multiples; document the decision in your data dictionary entry for the cluster.

Changing CISZ after production

Expect an outage window or carefully orchestrated application quiesce. Steps usually include DEFINE of the new cluster with desired CISZ and FREESPACE, IDCAMS REPRO from old to new, verification reads, name swap via ALTER or catalog procedures, and retirement of the old cluster after smoke tests. Capture EXCP counts and elapsed time from SMF before and after so tuning debates use evidence instead of opinions.

jcl
1
2
3
4
5
6
7
8
//DEFINE EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE CLUSTER (NAME(NEW.KSDS) - KEYS(10 0) RECORDSIZE(80 80) CISZ(18432) - FREESPACE(20 10) ... ) REPRO INFILE(OLD) OUTFILE(NEW) /*

Practical exercises

  1. On a sandbox KSDS, vary only CISZ between two clones and compare SMF-driven EXCPs for the same batch read.
  2. Graph CI splits from LISTCAT statistics after a synthetic insert workload for small versus large CISZ.
  3. Write a one-page decision record stating dominant access mode and chosen CISZ/FREESPACE pair with rationale.

Explain like I'm five

CISZ is the size of the moving box you use when you pack toys. A huge box carries many toys in one trip (good for moving everything to the attic at once) but is heavy to lift for just one toy (bad when you only need one doll). A tiny box is easy to lift for one toy but you need many boxes and tape (splits) if you keep adding toys. Pick the box size that matches how you play.

Test your knowledge

Test Your Knowledge

1. Why might huge CISZ hurt random access?

  • VSAM forbids random access
  • Each GET may read a large CI to return one small record, wasting cache bandwidth
  • CISZ is ignored for KSDS
  • Only RRDS reads CIs

2. What is a typical reason to rebuild when changing CISZ?

  • IDCAMS loves extra work
  • VSAM cannot magically rearrange existing CIs to a new size; REPRO to a new cluster enforces the fresh geometry
  • ALTER always changes CISZ live
  • LISTCAT performs the resize

3. Which pair should be tuned together?

  • CISZ and FREESPACE
  • CISZ and JOBCLASS
  • CISZ and SMF type 6 only
  • CISZ and UNIX umask
Published
Read time12 min
AuthorMainframeMaster
Reviewed by MainframeMaster teamVerified: IBM VSAM DEFINE CLUSTER guidanceSources: IBM z/OS DFSMS Using Data Sets; VSAM Demystified (Redbooks)Applies to: z/OS VSAM KSDS primary focus; concepts extend to other types