This series of articles is intended to help new CICS support people understand the basics of the product, and how it has evolved into the strong, robust software it is. It’s intended to help with basic concepts, underlying components that may not be intuitively obvious, and daily issues that may help everyone support the product. It targets an audience of people who come from distributed systems (UNIX, etc.), recent college graduates with no (or limited) z/OS experience, and applications developers moving into the systems arena.
For a complete explanation of what these articles will contain, and a list of basic prerequisites that are assumed the reader already possesses, go to the first article in the series: CICS 101: The Starting Point—CICS Initialization.
Most applications use file access for transaction processing; the most common files accessed are the customer database or product inventory. These files are potentially huge, and in many installations, contain thousands of records. Some financial installations have a customer database of more than a million records. The challenge is to format these records in a way that provides maximum access and performance with minimum maintenance.
The difference between VSAM data and DB2 data is enormous. VSAM was never designed to be a database; IBM introduced DB2 many years ago to fill that need and has constantly enhanced the product to be a powerful relational database. VSAM fills other needs for customers who need access to their data but don’t need the complicated maintenance associated with supporting that kind of database. This article compares and contrasts the two, but will spend more time covering VSAM. Customers who decide to maintain their data in DB2 will hire full-time DB2 Database Administrators (DBAs), but customers who support data via VSAM files will usually require that their CICS systems programmer take responsibility for maintenance. DB2 DBAs don’t feel that VSAM is truly a database (which it isn’t) and therefore won’t accept responsibility for supporting it. CICS personnel typically support VSAM files and tune them for performance.
VSAM can exist as a Key Sequenced Data Set (KSDS), an Entry Sequenced Data Set (ESDS), or a Relative Record Data Set (RRDS). The most common is the KSDS since the key produces a more efficient, easily accessed file. An ESDS or RRDS, since there’s no key, is more like a “flat” file that’s accessed sequentially from the beginning. A KSDS contains the data component and an index component used to find exactly which record needs to be read. These components are known as the Index Control Interval (CI) and the Data CI. When a request is made for a record, the index is read and contains a “pointer” to which Data CI contains the requested record. The size of these components is important because it influences performance. Since CICS transactions are designed to run in subsecond response times, the file request must be achieved quickly to return control to the task. In the past, since disk space was limited, the CIs were controlled to maximize space. Usually, the CI sizes were standardized to an Index CI size of 4K and a Data CI size of 8K. That’s commonly used by many organizations since it conforms to record sizes. If data records are larger or don’t fit that standard, index and data components can be modified to maximize performance.
CICS supports a facility called Local Shared Resources (LSRs) in each region. LSR pools used to be restricted since virtual storage in each region was limited. Now, customers are encouraged to build adequate LSR pools to support their VSAM files. The pools are built at CICS start-up. As VSAM data is read by an application, the data is read into and retained in the buffer pool. If the same data is requested by that or any other application, no physical I/O is done from the file; the data is read directly from the buffer. This is commonly referred to as the lookaside and is highly efficient since the data is retrieved directly from virtual storage in the CICS region. Customers can view these LSR statistics to tune their buffers for maximum performance. The following Enterprise Tech Journal article contains an excellent review of VSAM LSR tuning: Tuning CICS TS LSR Pools: The Robin Hood Theory in Reverse.
VSAM KSDS Reorganization
VSAM data sets that have a great deal of activity, especially records updated or added, may need to be reorganized regularly. On the other side, some customers have implemented reorganization schedules that may be unnecessary. Data sets that are good candidates for reorganization will display a high number of “splits.” This indicates additional Index or Data CIs were necessary to accommodate the update. This information can be found via the VSAM utility that lists the catalog and returns the status of the particular file. The LISTCAT command returns all the statistics for any file. Figure 1 shows an example of the output this command will display for an entry for both components.
The nn is the current number of splits for this particular file. Any large number in these statistics would indicate that reorganization should be considered. The following Enterprise Tech Journal article contains an excellent explanation of how to analyze and implement this process: VSAM KSDS Data Set Reorganization.
There are still many VSAM files in CICS, and proper care and maintenance is the best route for efficient processing. Few customers have all their data in DB2, so this file structure will continue to be supported.
DB2 Data Accessed via CICS
Since DB2 is a proper database and its own subsystem, the product and its data reside outside the CICS region. There may be three or four address spaces required to support a DB2 subsystem, and they operate independently of CICS since they can be accessed via several non-CICS techniques, batch or online. For CICS applications to access any data in DB2, the region must “connect” to the subsystem so they can communicate. Each DB2 subsystem has a DB2ID, which CICS uses for this connection. The first step is to include a System Initialization Table (SIT) parameter indicating that the CICS region will connect to DB2. DB2CONN=YES specifies this parameter.
The parameter tells the CICS region to find and connect to the subsystem. The name of the subsystem is specified in a resource definition called DB2CONN. In that definition, the DB2ID identifies the subsystem name for that DB2 and several other parameters that can be used for security and options. The definition would look similar to Figure 2. A complete list of the options can be found in the CICS Resource Definition Guide for the version and release of CICS you’re running.
Within the resource definition for DB2CONN is the DB2ID that CICS will connect to. This is the “attachment” that’s created between the two subsystems. The true beauty of the CICS/DB2 attachment is that it’s designed to be a two-phase commit process. That means once an application issues a call to a DB2 resource, and the data is returned, CICS and DB2 must communicate that all ends successfully. If so, the task ends in CICS and the update is committed in DB2. If the task ends abnormally, CICS sends the notification to DB2 and the update isn’t completed and is backed out in DB2. This is totally different from VSAM, where the data may be left incomplete. This feature encourages customers to use DB2 for security and data integrity. For a complete overview of the CICS/DB2 attachment facility, refer to the CICS DB2 Guide for the version and release you’re running.
A DB2 DBA, not the CICS support staff, normally supports DB2 subsystems. Some small installations combine the two responsibilities since the time and energy expended may be minimal. You can use many facilities in DB2 or vendor solutions to review or tune DB2 performance. Some statistics can be found in CICS, but since other systems are probably accessing DB2 simultaneously, they may be deceiving. For that reason, most installations monitor DB2 from the product’s own facilities. A CICS facility that provides information about DB2 is the Master Terminal Facility transaction, CEMT. To view the status of the DB2 connection, use CEMT INQ DB2CONN. The command will return numerous parameters (see Figure 3). A handy feature of this display is that you can overwrite any of these parameters to change the status. To change the DB2id, you would have to disconnect from DB2 first by overwriting the connection status, change the DB2id value, and then reconnect.
Typically, an installation uses both DB2 and VSAM to access data from CICS. They provide totally different functions but deliver the data the CICS application has requested. VSAM is simpler and more straightforward and has been enhanced recently to deliver more availability with Record Level Sharing (RLS), but DB2 delivers a true database with security and recovery.