The first shared resource LSR uses is the buffer space. CICS supports only 11 different buffer sizes (in KB): 0.5, 1.0, 2.0, 4.0, 8.0, 12.0, 16.0, 20.0, 24.0, 28.0 and 32.0. If a file has a CISZ of 2.5KB, then this data set must use a 4.0KB buffer to accommodate this CISZ. We use the term “CISZ” to describe the VSAM file “block size” definition, and “buffer size” to describe the LSR pool area where the CI is processed. Whenever the data set CISZ isn’t one of the 11 selected sizes, buffer fragmentation occurs that may or may not be acceptable. CICS allocates buffers to one of the 11 possible sizes depending on the file’s CISZ. You can define up to 32KB buffers for each of the 11 sizes CICS supports.
A second shared resource is the number of strings allocated to the pool. Strings are allocated using the SHARELIMIT percentage up to a maximum of 255 strings. The final shared resource is the key length. The key length specified must be sufficiently large to accommodate the largest key belonging to the files in the shared LSR pool. If a file has a longer key length than the one specified to the pool, the file won’t open.
Dynamic pool allocation is easy to implement and reduces the systems programmer’s intervention because there’s no need to inventory the files to determine the largest key size, the number and size of buffers required, or the number of strings needed. However, there are some major disadvantages to dynamically creating an LSR pool. The first disadvantage is that the dynamic allocation algorithm creates only one buffer pool that’s shared between data and index buffers. Having only one buffer pool for both can create a contention between similar CI sizes in the data and index. In other words, mixing indices and data CIs in the same buffer pool tends to flush indices out of the pool; these tend to have a more concentrated access pattern because there are fewer index CIs than data CIs in files. This is especially true in a pool that contains heavily browsed files.
Another disadvantage is that the number of buffers selected is based mainly on the number of strings and not by file activity. You would need to increase the number of strings allocated to a file in order to increase the number of buffers allocated to one particular CISZ. This technique also would increase the number of strings allocated up to a pool maximum of 255, wasting virtual storage that could have been allocated to other purposes such as additional buffer space. Finally, dynamically creating the pool takes a lot of time because the catalog is accessed for every file in the pool to determine the key length and CI sizes of the data and the index. Since the pool is created when the first file is opened, all the other data sets are closed and require CICS to access the catalog to get the required information. The real clunker is that you will have to pay the price to access the catalog for the files again when you reference them for the first time.
The best practice is to statically predefine the LSR pools through CEDA. To obtain a static LSR pool definition, you must provide the buffer definitions, string, and key length information. Buffer definition includes the number of buffers desired by size. If any of the elements are missing, then a dynamic allocation for the missing piece occurs and the advantages of predefining the pools may be fully attained. Static definition allows for a faster initialization because the catalog need not be queried. This avoids the overhead associated with having to “open” the files to determine the key length and CI sizes involved. In addition, you can now individually tune the buffer pool based on activity basis and also separate the data and the index buffers to avoid contention for the same CI sizes. You also can optimize the number of strings assigned to the pool.
Static definition requires systems programming intervention to determine the buffer sizes and quantity to be allocated, the number of strings required, and the maximum key length. The process requires planning and exposes a systems programmer to errors. For example, if you forget to allocate a particular buffer size a file requires, the file will use the next larger buffer size, if one is available. However, if there’s no larger size, then the file won’t open. So all pools should have at least three 32KB buffers defined to ensure that files will open even though performance isn’t optimum. The process to tune LSR pools is repetitive. Changes occur, the pool is re-initiated, and new results measured.
LSR pool effectiveness is measured by the look-aside hit ratio. Generally accepted ratios are:
• Data: 80 percent or better