Improving VSAM performance

Your system programmer is most likely responsible for tuning the performance of COBOL and VSAM. As an application programmer, you can control the aspects of VSAM that are listed in the following table.

About this task

Table 1. Methods for improving VSAM performance
Aspect of VSAM What you can do Rationale and comments
Invoking access methods service Build your alternate indexes in advance, using IDCAMS.  
Buffering For sequential access, request more data buffers; for random access, request more index buffers. Specify both BUFND and BUFNI if ACCESS IS DYNAMIC.

Avoid coding additional buffers unless your application will run interactively; then code buffers only when response-time problems arise that might be caused by delays in input and output.

 The default is one index (BUFNI) and two data buffers (BUFND).
Loading records, using access methods services Use the access methods service REPRO command when:
  • The target indexed data set already contains records.
  • The input sequential data set contains records to be updated or inserted into the indexed data set.

If you use a COBOL program to load the file, use OPEN OUTPUT and ACCESS SEQUENTIAL.

 The REPRO command can update an indexed data set as fast or faster than any COBOL program under these conditions.
File access modes For best performance, access records sequentially. Dynamic access is less efficient than sequential access, but more efficient than random access. Random access results in increased EXCPs because VSAM must access the index for each request.
Key design Design the key in the records so that the high-order portion is relatively constant and the low-order portion changes often. This method compresses the key best.
Multiple alternate indexes Avoid using multiple alternate indexes. Updates must be applied through the primary paths and are reflected through multiple alternate paths, perhaps slowing performance.
Relative file organization Use VSAM fixed-length relative data sets rather than VSAM variable-length relative data sets. Although not as space efficient, VSAM fixed-length relative data sets are more run time efficient than VSAM variable-length relative data sets.
Control interval sizes (CISZ) Provide your system programmer with information about the data access and future growth of your VSAM data sets. From this information, your system programmer can determine the best control interval size (CISZ) and FREESPACE size (FSPC).

Choose proper values for CISZ and FSPC to minimize control area (CA) splits. You can diagnose the current number of CA splits by issuing the LISTCAT ALL command on the cluster, and then compress (using EXPORT, IMPORT, or REPRO) the cluster to omit all CA splits periodically.

 VSAM calculates CISZ to best fit the direct-access storage device (DASD) usage algorithm, which might not, however, be efficient for your application.

An average CISZ of 4K is suitable for most applications. A smaller CISZ means faster retrieval for random processing at the expense of inserts (that is, more CISZ splits and therefore more space in the data set). A larger CISZ results in the transfer of more data across the channel for each READ. This is more efficient for sequential processing, similar to a large OS BLKSIZE.

Many control area (CA) splits are unfavorable for VSAM performance. The FREESPACE value can affect CA splits, depending on how the file is used.

Related tasks  
Specifying access modes for VSAM files  
z/OS® DFSMS: Using Data Sets (Building a resource pool, Selecting the optimal
   percentage of free space)

Related references  
z/OS DFSMS: Access Method Services for Catalogs