Coupling facility data tables
Coupling facility data tables (CFDTs) provide a method of file data sharing, using CICS® file control, without the need for a file-owning region, and without the need for VSAM RLS support. CICS CFDT support provides rapid sharing of working data within a sysplex, with update integrity.
The data is held in a coupling facility, in a table that is similar to a shared user-maintained data table. You must define the resources required for CFDTs in an MVS™ coupling facility resource management (CFRM) policy.
Because read access and write access have similar performance, this form of table is useful for scratchpad data. Typical uses might include sharing scratchpad data between CICS regions across a sysplex, or sharing of files for which changes do not have to be permanently saved. There are many different requirements for scratchpad data, and most of these can be implemented using CFDTs.
- You can use a field in a CFDT to maintain the next free order number for use by an order processing application.
- You can maintain a list of the numbers of lost credit cards in a CFDT.
To an application, a CFDT appears much like a sysplex-wide user-maintained data table, because it is accessed in the same way, by using the file control API. However, in a CFDT there is a maximum key-length restriction of 16 bytes.
Coupling facility data table models
- The contention model gives optimal performance but generally requires
programs written to exploit it. This is because the CHANGED condition
code (which indicates that the data has changed since the application
program issued a read-for-update request) is specifically for this
model. Programs that are not written for the contention model might
not be able to handle this condition correctly. The CHANGED response
can occur on a REWRITE or DELETE command. There is also a situation
with the contention model in which the NOTFND response can be returned
on a REWRITE or DELETE.
This model is nonrecoverable: CFDT updates are not backed out if a unit of work fails.
- The locking model is API-compatible with programs that conform
to the UMT subset of the file control API (this subset is almost the
full file control API). This model can be one of the following:
- Nonrecoverable.
Locks do not last until syncpoint, and CFDT updates are not backed out if a unit of work fails.
- Recoverable.
CFDTs are recoverable after a unit-of-work failure or a CICS region failure (updates made by units of work that were in-flight at the time of the CICS 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 syncpoint processing, the locks are converted to retained locks and the unit of work is shunted.
- Nonrecoverable.
Server connections
A client CICS region establishes a single cross-memory connection to a server the first time a request refers to the pool for that server. If the server connection fails, there are implications for coupling facility data tables. See Server connection management and Named counter recovery.