Resource definition for user-maintained data tables

You use the DEFINE FILE command to define a file as a user-maintained data table.

You can also change the definition of an existing file by the:

The source data set for a user-maintained data table can be open in RLS access mode. You might want to make an RLS-mode data set the source of a user-maintained data table if you have other file definitions that access the data set and the data set is updated by other CICS regions.

You can load multiple user-maintained data tables from the same source data set by using a separate command or macro to define each data table and making all the definitions refer to that data set.

Although a data table must be loaded from a VSAM KSDS, an application can then copy records to a user-maintained data table from any data source that is accessible from the CICS address space. This could be an IMS™ or DB2® file. The KSDS that is used as the source data set for the data table can be empty; it is needed only to define the maximum record length and the key length and position.

Variable-length record format must be specified for a user-maintained data table. The maximum record length that is supported by SDT is 32KB. This length exceeds that supported by CICS file management, which imposes the actual limit. See the topic dealing with lengths of areas passed to CICS commands in the CICS Application Programming Guide. The maximum number of records supported is 16 777 215.

For more information, see Resource definition for data tables.

Data integrity

Start of changeA user-maintained data table can be defined as a recoverable resource. Changes to the data table are not recorded in the system log, but they are held internally in CICS memory. Thus the data table can be recovered after a transaction failure (by dynamic backout) but not after a system failure. This is because the CICS Shared Data Table facility manages its own recovery and does not use the services of the log manager or the recovery manager. The exception is when changes are made to a recoverable data table as part of a distributed unit of work. In this case, as with other recoverable resources, a record of the link is written to the system log as part of the two-phase commit process. However, the changes themselves are not recorded in the system log.End of change

After a system failure, the data table is reloaded from the source data set when the file is reopened. Remember that, at the time of failure, the contents of the source data set and data table would not have been the same unless you had ensured that:

Automatic journaling is supported only for requests that access the source data set during loading. The records that are accessed by the loading process are journaled before user exit XDTRD, and the records that are accessed due to application requests are journaled after user exit XDTRD.

Related concepts
Resource definition for data tables
User-maintained data tables
Application programming for user-maintained data tables
Operations with user-maintained data tables
CICS-maintained data tables
[[ Contents Previous Page | Next Page Index ]]