VSAM CI Size (CISZ)

CISZ is the DEFINE CLUSTER parameter that sets the control interval size for your VSAM data component (and you can think separately about index CI sizing for KSDS). A control interval is the fundamental unit that VSAM reads and writes from disk: it contains a small fixed control section at the front, then slot descriptors and the stored logical records packed according to compression and spanned record rules. When beginners first learn VSAM, they often focus on RECORDSIZE and KEYS because those are obvious in COBOL copybooks, but CISZ quietly determines how many records fit near each other on disk, how often CI splits occur when inserts land in full intervals, and how large each I/O transfer is when your program requests a record. Choosing CISZ is therefore a performance and capacity decision, not merely a default you accept without reading the manual. IBM documents minimum and maximum CISZ values and alignment requirements for each device and release; your storage administrator may also publish standard values so that all application clusters on a volume class behave consistently in the buffer pool.

How CISZ Appears in IDCAMS

You specify CISZ on the cluster or on the DATA clause depending on how your DEFINE is structured. A typical pattern is DEFINE CLUSTER with RECORDSIZE, KEYS, and FREESPACE at the cluster level, then DATA(NAME(...) CISZ(4096) ...). The number is in bytes. Some examples use powers of two such as 2048, 4096, or 8192 because they align cleanly with hardware block sizes and make mental arithmetic about multiples easier, but VSAM allows other sizes within the supported range. If you omit CISZ, the system chooses a default based on attributes like RECORDSIZE and allocation unit; defaults are convenient for prototypes but production files usually pin CISZ explicitly so that behavior is stable across refreshes of test catalogs. Index CI size is a separate concern for KSDS: the index component has its own intervals and may use a different size optimized for key entries rather than full logical records.

1
2
3
4
5
6
7
8
9
10
11
12
13
  DEFINE CLUSTER ( -
    NAME(USERID.INVENTORY.KSDS) -
    INDEXED -
    RECORDSIZE(200 200) -
    KEYS(8 0) -
    FREESPACE(20 10) -
    CISZ(4096)) -
  DATA (NAME(USERID.INVENTORY.KSDS.DATA) -
    CYLINDERS(10 5) -
    VOLUMES(SYSDA)) -
  INDEX (NAME(USERID.INVENTORY.KSDS.INDEX) -
    CYLINDERS(1 1) -
    VOLUMES(SYSDA))

Anatomy Reminder: What Must Fit in a CI

Each CI begins with a control interval definition field and related control information. Free space follows the control portion, then stored records with their slot descriptors. When you specify FREESPACE as a percentage of CI space to leave empty at load time, that reserved area is inside the CI, so the number of records that can be loaded before splits begin is lower than if FREESPACE were zero even though CISZ is unchanged. Spanned records that cross CI boundaries add complexity: parts of a logical record live in consecutive CIs, and CISZ still governs each physical piece. For variable-length records, CI capacity depends on the distribution of lengths, not only on RECORDSIZE maximum. Application designers therefore communicate both average length and worst-case length when asking a DBA to pick CISZ and FREESPACE.

Trade-offs in Plain Language

No single CISZ is universally best. A data warehouse style KSDS that is mostly read sequentially during month-end reporting might tolerate or prefer larger intervals to reduce I/O count. An online CICS file with many concurrent transactions doing narrow keyed reads might prefer a CISZ that matches buffer pool tuning so that each read does not pull an unnecessarily large CI into cache, displacing other files. RRDS and ESDS have their own CI considerations: RRDS fixed slots relate CISZ to slot size and slots per interval, while ESDS appends bytes and still stores data in CIs for physical I/O. Always revisit CISZ when you change RECORDSIZE or compression, because what fit comfortably before might no longer be optimal.

CISZ and Splits

CI splits occur when VSAM must insert or expand a record in a CI that cannot accommodate the change even after using remaining free space inside that CI. Splitting rewrites part of the CI chain and updates the index for a KSDS. A larger CISZ with well-chosen FREESPACE reduces how often you reach the split threshold during insert phases, but when a split does happen, more bytes may move because the interval is bigger. CA splits, which are even more expensive, become more likely if CI splits exhaust reserved free CIs within a control area; tuning CISZ and FREESPACE together is how you keep both split types rare. Monitoring tools and EXAMINE/LISTCAT diagnostics over time tell you whether your chosen CISZ is too small in practice.

Step-by-Step Reasoning for Beginners

1. Start from RECORDSIZE(average max) and whether records are fixed or variable.
2. Decide insert vs read-heavy behavior and whether sequential scans dominate.
3. Pick a trial CISZ that satisfies IBM minimums and comfortably holds at least one max record with overhead.
4. Set FREESPACE for expected insert pattern; rerun estimates of logical rows per CI.
5. Validate with a realistic load test and compare split counters or elapsed time against an alternative CISZ if unsure.

Explain Like I'm Five

Think of each CI as a lunchbox. CISZ is how big the lunchbox is. If the lunchbox is huge, you can fit many sandwiches before you need a second lunchbox, but each time you open it you lift a heavy box. If the lunchbox is tiny, you lift a light box, but you need new lunchboxes all the time. CISZ is the size of the lunchbox; RECORDSIZE is how big each sandwich can be.

Test Your Knowledge