The 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. CICS coupling facility
data table support is designed to provide rapid sharing of working
data across a sysplex, with update integrity. The data is held in
a coupling facility, in a table that is similar in many ways to a
shared user-maintained data table. A coupling facility data table
is different from a UMT in one important respect in that initial loading
from a VSAM source data set is optional . You can specify LOAD(NO)
and load the table by writing data directly from a user application
program. The API used to store and retrieve the data is based on the
file control API used for user-maintained data tables. Read access
and write access to CFDTs have similar performance, making this form
of table particularly useful for informal shared data. Informal shared
data is characterised as:
- 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 usually very 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.
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 ways in
which applications use informal shared data, and most of these could
be implemented using coupling facility data tables. Coupling facility
data tables are particularly useful for grouping data into different
tables, where the items can be identified and retrieved by their keys.
For example, you could use a record in a coupling facility data table
to maintain the next free order number for use by an order processing
application. Other examples are:
- 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.
Note the following comparisons with user-maintained data tables:
- 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.
There are two models of coupling facility data table:
- 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 may 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:
- Non-recoverable
- For updates to non-recoverable CFDTs, locks do not last until
syncpoint (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 in-doubt and backout failures:
if a unit of work fails when backing out an update to the CFDT, or
if it fails in-doubt during syncpoint 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.
[[ Contents Previous Page | Next Page Index ]]