Overview of the RECON Data Sets

The RECON data set is the most important data set for the operation of DBRC and data sharing. The RECON data set holds all of the resource information and event tracking information that is used by IMS.

The RECON data set can consist of one, two, or three data sets:

1. The original data set

2. A copy of the original data set

3. A spare data set

The original data set and the copy are a pair of VSAM clusters that work as a pair to record information. A third RECON can be used as a spare. IMS normally works with two active RECON data sets. If one becomes unavailable, the spare will be activated if it is available.

The best solution, from an availability point of view, is to use all three data sets. This is strongly recommended. Using three data sets for the RECON causes DBRC to use them in the following way:

• The first data set is known as copy1. It contains the current information. DBRC always reads from this data set, and when some change has to be applied, the change is written first to this data set.

• The second data set is known as copy2. It contains the same information as the copy1 data set. All changes to the RECON data sets are applied to this copy2 only after the copy1 has been updated.

• The third data set (the spare) is used in the following cases:

  - A physical I/O error occurs on either copy1 or copy2.

  - DBRC finds, when logically opening the copy1 RECON data set, that a spare RECON has became available, and that no copy2 RECON data set is currently in use.

  - The following command is executed: CHANGE.RECON REPLACE(RECONn)

  When the third RECON data set starts to be used, the remaining valid data set is copied to the spare. When the copy operation is finished, the spare becomes whichever of the data sets was lost, missing, or in error.

RECON Records

The individual records in the RECON contain the information that DBRC keeps track of.

Types of RECON Records

There are six general types of RECON records:

Control records

Control records control the RECON data set and the default values used by DBRC. This class of records includes the RECON header record and header extension record.

Log records

Log records track the log data sets used by all subsystems. This class of records includes:

• Primary Recovery Log (PRILOG) and Secondary Recovery Log (SECLOG) records (including interim log records), which describe a recovery log data set (RLDS) created by an IMS TM system, a CICS online system, a DB batch job, or the Log Archive utility.

• Log Allocation (LOGALL) record, which lists the DBDSs for which database change records have been written to a particular log.

• Primary OLDS (PRIOLD) and Secondary OLDS (SECOLD) records (including interim OLDS records), which describe the IMS TM online data sets (OLDS) that are defined for use.

• Primary System Log (PRISLDS) and Secondary System Log (SECSLDS) records (including interim SLDS records), which describe a system log SLDS created by an IMS TM system.

Change accumulation records

Change accumulation records track information about change accumulation groups. This class of records includes change accumulation group, execution, and data set records.

DBDS group records

Database data set group (DBDSGRP) records define the members of a DBDS group. The only record type in this class is a DBDS group record.

Subsystem records

Subsystem records contain information about the subsystem and related recovery information, including:

• Subsystem name and type (online or batch)

• IRLM identification

• Abnormal-end flag and the recovery-process start flag

• List of authorized databases

• Time stamp that correlates the subsystem entry with the appropriate log records

Database records

Database records track the state of databases, DBDSs, and resources required for recovery of the DBDSs. This class of records includes:

• Database record (IMS, HALDB, or PARTition)

• Area authorization record

• DBDS record (non-Fast Path or Fast Path)

• Allocation record

• Image copy record

• Reorganization record

• Recovery record

Database-Related Information

A database and its associated data sets should be defined in only one RECON data set.

The fundamental principle behind the RECON data set is to store all recovery-related information for a database in one place. It is not possible to use multiple RECON data sets in the recovery processing for the same database.

IMS Systems and the RECON

An IMS system can be connected to only one set of RECON data sets.

All databases that are accessed by IMS TM systems under the control of DBRC must be registered in the RECON referenced by the online IMS system only if the RECON has the FORCER option set on.

All batch IMS systems that access any database accessed by the online IMS system should reference the same RECON data sets that are referenced by the online IMS system.

Database Names in the RECON Data Set

The database names (DBD names) defined in one RECON data set must all be unique.

The database records stored in the RECON data set are registered with a key based on the DBD name. Therefore, DBRC cannot be used to control both test and production databases that use the same RECON data sets, unless you adopt a naming convention.

As a general rule, more than one set of RECON data sets is necessary if all the following conditions are true:

• Multiple versions of the same database exist (for example, test and production).

• The same DBD name is used for the different versions of the database.

• More than one version of the databases can be used, but only one can be registered to DBRC in the RECON data set. The other versions are treated as not registered (unless the FORCER option is set in the RECON).

The application of the previous rules usually results in the need for at least two different sets of RECON data sets: one shared between the production systems, and one for the test systems.

Note:

On the INIT.DBDS command, which is used to create the database data set record in the RECON, you must supply the database data set name (DSN). When IMS opens the database, DBRC checks the DSN against the name that is registered in the RECON data set. If this name does not match, DBRC treats this database as if it was not registered. In this case, the test database (with a DSN different than the production database, even if with the same DBD name) and data set name, can coexist with the production environment, but not under the control of DBRC.