Get Your Whole Index In Memory!

If data is being processed directly, using sufficient buffer space in a VSAM LSR pool so that repeated index I/O operations are minimized can pay great benefits.

There are several key parts to this:

• You need to ensure that the size of the Control Areas (CAs) used for your file are as large as possible. The CA size VSAM will use is the smallest of:
  • The Primary Space Allocation amount
  • The Secondary Space Allocation amount
  • One Cylinder (for logical devices, it is the equivalent of one cylinder of the simulated device, such as 3390)

  This means it is important to specify primary and secondary allocation amounts with this in mind.

• You need to ensure that the size of your Index Control Intervals (CIs) are as small as possible. It is possible to make these too large, which only wastes space on disk and in in-storage buffers.

  For VSE environments, if you specify a CI size smaller than needed, VSAM will promote the size to a higher size sufficient to contain the needed data. I recommend:

  • Do NOT specify a CONTROLINTERVALSIZE (CISIZE or CISZ) on any DEFINE CLUSTER command. Only specify this on DATA component definitions. Many vendor application package sample installation jobstreams contain CISZ definitions on the CLUSTER and omit it on the components. You should feel free to change those specifications to more appropriate values.
  • Do not specify CONTROLINTERVALSIZE on an INDEX component definition, and allow the Access Method Services utility to calculate the size it wants.
  • Use LISTCAT to review the results of the DEFINE command, and if the INDEX CI size is a value which does not fit nicely into an LSR buffer size, add the CONTROLINTERVALSIZE specification for the INDEX to increase the INDEX CI size to the next LSR buffer size.

  For zOS and MVS environments, DFP/VSAM does not automatically promote the index CI size as the VSE implementation does, and it is possible to have significant wasted disk space if the index CI size is too small.

• Then, you need to specify enough index buffers of the applicable size in your LSR pool. See the discussion on LSR pool specifications for more details, but the maximum number of buffers you need for any one file's index buffers would be the number of index records shown in the listcat output for that file. The optimum number would be one buffer for each high-level index record -- plus at least one or two additional buffers for each string.
• Monitor the buffer hit/miss ratio for the file, and increase the number of index buffers until that ratio becomes favorable.