Introduction › Non-Shared Resources (NSR) › Problems Related to Static Buffering

Problems Related to Static Buffering

Specifying BUFFERSPACE at DEFINE time, or BUFFERSPACE, BUFND, or BUFNI at execution time using the AMP DD parameter or the ACB, is a static form of buffering. It is static because the values are not dynamically adjusted for any changes in the environment.

As a file grows, or as new applications process the cluster, or as modifications are made to the types of accesses made by existing applications, the numbers that were specified remain as originally assigned. You must monitor and adjust these parameters manually as the environment changes if optimum performance is desired. The only way that you can adjust these parameters in a dynamic production environment is by continuously monitoring each and every program and cluster. Whenever anything changes, you readjust the number of buffers manually.

Static buffering allows you to tune VSAM for good performance. If you can determine how a particular application accesses a particular file, and then determine an optimum number of data and index buffers for this application to process this cluster. You can tune VSAM for the best possible performance, as long as nothing ever changes.

Examples of Static Buffering:

For example, if an application processes a KSDS file randomly, extra index buffers can reduce the number of I/Os required to search the index component. Buffering the entire index set avoids all read I/Os to the index set, except the first I/O for each index set control interval. Buffering the index set significantly improves the performance of this random application (faster online response times, reduced I/O path congestion, shorter elapsed time for batch, and so forth.)

Assume that a KSDS file has three index levels and that an application accessing this KSDS is currently using the default buffer space (two data buffers, one index buffer) to randomly retrieve logical records. Each retrieval requires at least four I/Os to the disk.

A random access request to a KSDS file requires VSAM to search the index structure to find the key of the requested logical record. VSAM always starts this search with the high level index record. If the high level index record is not already available in virtual storage, VSAM must perform one I/O to read it into an index buffer (first I/O). Since this example assumes a three level index, the first matching-or-greater key that is encountered in the high level index record points to another index record in the middle level of the index.

VSAM must next search this middle level index control interval. This requires an I/O (second I/O), since this second level index control interval is not already in a buffer.

Since we are using the default buffer space in this example, we have only one index buffer, which VSAM filled with the high level index record on the previous I/O. So VSAM must read the middle level index control interval into the only index buffer over the top of the high level index control interval currently resident there. The first matching-or-greater key that VSAM finds in this middle control interval points to a bottom level index control interval, called a sequence set control interval, which must now be read into the only index buffer (third I/O) overlaying the middle level record that is currently in residence.

The first matching-or-greater key encountered in the sequence set record points to the data control interval that contains the logical record that was requested by the application (if it exists at all). This data control interval must now be read into a data control interval buffer which requires at least one I/O, and possibly more if the data record is SPANNED (fourth and subsequent I/Os).

This same process is repeated for each logical record that is accessed randomly by this application. The next random request requires the high level index CI, which causes an I/O, since the copy of the high level index record (obtained by the first I/O) has been overlaid by the subsequent index I/Os, and is no longer resident.

This means that:

• An application waits for at least four I/Os to complete for each logical record accessed. This includes the possibility of up to four waits for a busy I/O path (channel/controller/device), four seeks, four device latencies, and four data transfers, and includes all of the processor cycles required to drive 4 I/Os and to process four I/O interrupts (control block validation, page fixing, channel program construction, SVC overhead, interrupt handler, pagefree, SRBs, and so forth). Online response time and batch throughput suffers because of this additional I/O and processing. This application tends to be I/O bound, and spends most of its time waiting for I/Os to complete, instead of performing the desired processing of the data!
• The disk(s) on which this cluster is defined is busy performing up to four I/Os for each logical record accessed. Device congestion slows down not only the application causing the excessive I/O, but all applications using files on this disk.
• The controller, head of string, and channel are also busy, adding to overall system performance degradation. The I/O subsystem (IOCP) can be forced to delay I/O requests by queuing or suspending them until a path or device is available.

Increasing the number of index buffers reduces the number of I/Os required for each randomly accessed logical record. VSAM finds more of the index control intervals in a buffer and avoids index set I/Os. To reduce the number of index I/Os to a minimum requires as many index buffers as there are index set records, plus one per string for sequence set record buffering.

To buffer the entire index set manually, you must first determine how many index set control intervals exist in the index component, then specify that many index buffers plus one per string in the BUFNI parameter through the ACB, or on the DD card in the AMP parameter. This specification allows

VSAM to keep an 'index set cache' in main storage and to avoid all of the read I/Os to the index set (except the first I/O for each control interval which is required to make that CI resident in a buffer). This improves online response times, reduces path congestion, and reduces batch turnaround times for applications that access this file randomly.

You can specify buffers using the BUFFERSPACE, BUFNI, and BUFND parameters. You can specify some of these parameters at DEFINE time (BUFFERSPACE only), at execution time using the ACB, or on the DD card in the AMP parameter.