There are several ways to handle VSAM files in CICS/TS using different buffering techniques. The more common buffering technique is Local Shared Resources (LSR), where the file’s buffering is shared in a buffer pool. (We’ll review LSR in a future article.) Another alternative is Record Level Sharing (RLS), where the file’s buffering is handled by SMSVSAM in a separate region and data space. This article explores the tuning associated with Non-Shared Resource (NSR) files running under CICS, where the buffering is defined for the exclusive use of each file.
As a starting point, an important question to ask is, “Why is this file in NSR?” There has to be a strong justification as to why a particular file has been assigned to use NSR buffering instead of LSR because LSR’s more superior look-aside algorithm offers better performance.
This article will concentrate on performance issues associated with VSAM KSDS files in our review of NSR.
The first step is to determine which files are designated as NSR in the CICS partition. You can obtain the information from the CICS statistics, file definitions, or a performance monitor (see Figure 1).
NSR is a means of processing VSAM files in which the resources are dedicated to the file. Specifically, dedicated means the control block structures, including the strings and buffers, are owned by the VSAM file to which they were defined. NSR is the default access for batch jobs and can be optionally selected for online CICS files by placing a NONE when defining the LSR pool id in the file definition under RDO. In this case, all strings and buffers defined are allocated for the file’s exclusive use.
To properly tune an NSR file, you need to know how the file is being primarily accessed because the buffer allocations vary depending on whether the file is accessed directly (random) or sequentially. When accessing the file sequentially, you want to allocate additional data buffers (BUFND) to be able to overlap data I/O operations such as reading ahead. When accessing the file directly, you’d want to have additional index buffers (BUFNI) to be able to get better index look-aside hit ratios. For dynamically accessed files, you would probably want to increase both the data and index buffers.
In a CICS online environment, sequential processing occurs when you browse the file (e.g., STARTBR, READNEXT and ENDBR) or whenever a CA split occurs, as the movement of CIs from one CA to another is a sequential process. In these cases, having defined additional BUFNDs can help improve the time it takes to perform the sequential operation. Online direct processing of VSAM files (e.g., READ) occurs whenever you issue commands requesting a specific record. In this case, additional BUFNIs can improve direct access. The challenge would be to determine how many buffers are required for optimum performance. Let us first review how a VSAM file uses the resources allocated. We will start with direct processing.
An NSR file that has one string assigned requires at least two BUFNDs and one BUFNI. The extra data buffer is used to process splits. Each string requires one data and one index buffer. The data buffer is used to read the appropriate data CI while the index buffer is used to read the entire index CIs associated with locating the proper data CI. In other words, a file that has three index levels requires three index CIs to be read directly before the location of the data CI is identified. Thus, there are potentially four I/O operations possible, three for the index that use the index buffer and one for the data that uses the data buffer. The problem is that there’s only one index buffer. So, subsequent file requests will require that the three index I/O operations be done again, even if the same index CIs are requested. This is because each index read overlays the previous index CI. By the time you read the last index record, all higher-level index CIs would be overlaid and unavailable. More index buffers would help improve this condition. The extra index buffers are used to house the index set records (second and higher-level index). So, if additional BUFNIs were specified, you could avoid reading these CIs in future requests. The extra BUFNI buffers provide additional look-aside capacity to an NSR file.