Coupling facility data tables
CICS® file control commands can access coupling facility data tables (CFDTs). Coupling facility data tables provide a method of file data sharing, without the need for a file-owning region, and without the need for VSAM RLS support.
- Data that is relatively short term in nature (it is either created as the application is running, or is initially loaded from an external source)
- Data volumes that are not typically large
- Data that needs to be accessed fast
- Data of which the occasional loss can be tolerated by user applications
- Data that commonly requires update integrity.
- Look-up tables of telephone numbers or the numbers of stolen credit cards
- Working data consisting of a few items, such as a subset of customers from a customer list
- Information that is specific to the user of the application, or that relates to the terminal from which the application is being run
- Data extracted from a larger file or database for further processing.
Coupling facility data tables allow various types of access to your informal data: read-only, single updater, multiple updaters, sequential access, random access, random insertion, and deletion.
For many purposes, because it is global in scope, coupling facility data tables can offer significant advantages over resources such as the CICS common work area (CWA).
To an application program, a CFDT appears much like a sysplex-wide user-maintained data table: a CFDT is accessed using the same subset of the API as a UMT (that is, the full file control API except for the MASSINSERT and RBA options). However, a CFDT is restricted to a maximum key-length of 16 bytes.
- Updates to a CFDT, like updates to a UMT, are not reflected in the base VSAM data set (if the table was initially loaded from one). Updates are made to the CFDT only.
- A CFDT is loaded once only, when the table is first created in
the coupling facility data table, and remains in existence in the
coupling facility, even when the last file referring to the CFDT is
closed (whereas a UMT is deleted each time the owning region terminates). You
can force a reload of a CFDT from the original source data set only
by first deleting the table from the CFDT pool, using a CFDT server
DELETE TABLE command. The first file opened against the CFDT after
the delete operation causes the server to reload the table. Note: A coupling facility data table pool is defined as a coupling facility list structure, and can hold more than one data table (see the CICS System Definition Guide for information about creating a list structure for coupling facility data tables).
- The access rules for a UMT that is in the course of loading allow any direct read request to be satisfied either from the table (if the record has already been loaded) or from the source data set, but reject any update request, or imprecise read or browse request, with the LOADING condition. For a CFDT, any request is allowed during loading, but requests succeed only for records that are within the key range already loaded.
Coupling facility data table models
- Contention model
- This gives optimal performance, but requires programs that are
written to handle the situation where the data has been changed since
it issued a read-for-update request. The new CHANGED response can
occur on a REWRITE or DELETE command. There is also a new use for
the existing NOTFND response, which can be returned to indicate to
the application program that the record has been deleted since the
program issued the read-for-update request. Note: It might be possible to use existing programs with the contention model if you are sure they cannot receive the CHANGED or NOTFND exceptions on a REWRITE or DELETE. An example of this could be where an application program operates only on records that relate to the user of the program, and therefore no other user could be updating the same records.
- Locking model
- This model is API-compatible with existing programs that conform
to the UMT subset of the file control API. The locking model can be:
- Unrecoverable
- For updates to unrecoverable CFDTs, locks do not last until sync point (they are released on completion of the file control request) and updates are not backed out if a unit of work fails
- Recoverable
- CFDTs are recoverable in the event of a unit of work failure,
and in the event of a CICS region failure, a CFDT server failure,
and an MVS™ failure (updates made by units of work that
were in-flight at the time of the failure are backed out).
The recoverable locking model supports indoubt and backout failures: if a unit of work fails when backing out an update to the CFDT, or if it fails indoubt during sync point processing, the locks are converted to retained locks and the unit of work is shunted.
CFDTs cannot be forward recoverable. A CFDT does not survive the loss of the CF structure in which it resides.
You specify the update model you want for each table on its file resource definition, enabling different tables to use different models.