A major new CICS performance issue is the Task Control Block (TCB) switching required to access VSAM data sets when supporting threadsafe applications running DB2. Prior to the announcement of VSAM threadsafe support in CICS Transaction Server (TS) V3R2, any threadsafe application running on an L8 or L9 TCB would have to do a TCB switch to the Quasi-Reentrant (QR) to service the VSAM request because file control wasn’t threadsafe code. Unfortunately, although VSAM threadsafe was announced with CICS TS V3R2, only the Record-Level Sharing (RLS) portion was available at general availability of the product. A subsequent Program Temporary Fix, PTF UK37688, and VSAM APAR OA20352 were released last year to provide support for threadsafe VSAM support.
File control VSAM threadsafe requires a minimum level of z/OS V1 R9. PTF UK37688 affected the default setting of the System Initialization Table (SIT) parameter FCQRONLY. This parameter determined whether file control requests were serviced on the QR TCB only, regardless of the program concurrency setting, or on any TCB (QR/L8/L9) on which the task was running. To activate file control VSAM threadsafe support, you must code FCQRONLY=NO explicitly in the SIT for both RLS and Local Shared Resource (LSR) data set threadsafe support. This setting allows CICS to dispatch file control VSAM commands under another TCB that may or may not be the QR (discussed later). This parameter originally defaulted to “NO,” but with the application of PTF UK37688, the default was changed to “YES,” which effectively forces all file control commands to run on the QR TCB regardless of whether the program is threadsafe.
The threadsafe portion applies only to local file control VSAM requests and not through function shipping (remote files) to another region such as a File Owning Region (FOR). This can be considered a major weak point by installations that use FOR regions. The local file control VSAM support is available only for Local Shared Resource (LSR) data sets. In other words, file control VSAM threadsafe support isn’t available for Non-Shared Resource (NSR) data sets. This only confirms what we’ve expressed many times in several articles and conferences: NSR data sets should be converted to LSR to gain better performance because of the superior lookaside algorithm LSR uses. Other file control areas not threadsafe include Coupling Facility Data Tables (CFDTs), Shared Data Tables (SDTs), and Basic Direct Access Method (BDAM). Will any of these be supported in the future? Who knows. For now, we can only take advantage of the available support. With the exception of the INQUIRE FILE, all file control System Programming Interface (SPI) commands aren’t threadsafe. However, local VSAM file control commands that are threadsafe include: