The cataloging process
The fourth stage of the INSTALL process is to produce a catalog record that is written to the CICS® global catalog data set. This record is used on a subsequent restart to re-create the TCTTE, but in a different way from the BUILD process as described.
A CEDA INSTALL means that the TCTTE lives across CICS restarts, avoiding the necessity of rerunning the installation.
A RESTORE from the CICS catalog is a faster operation than a CEDA INSTALL because there is no conversion of the CSD definition to a builder parameter set, and less I/O involved.
In summary, a catalog record is produced by recalling each of the builders asking for the address of the data that they want to be recorded on the catalog. Each subcomponent of the TCTTE is then copied and concatenated into one record, which is then written to the catalog. This process is known as FLATTEN. The FLATTEN process occurs in the DFHTBSS module during syncpoint processing. During phase 1 syncpoint processing, DFHTBSS searches the action elements for a nonzero CCRECP and calls DFHTBSLP on detection of it, passing the reference to the pattern as given in the action element. The storage “segments” are returned to DFHTBSSP which extracts the address and length from each segment and copies them into the recovery record.
A CATALOG call is made when significant events change the state of a TCT entry which would be needed on a subsequent emergency restart. An example is the recording of the member name of a generic z/OS® Communications Server resource connection when a bind has occurred for the first time.
On the restart, the record is read from the catalog, and presented back to each of the original builders. Each builder performs a GETMAIN, and copies its section of the recovery record into the acquired storage. This process is known as UNFLATTEN. It is also called the RESTORE process. The recovery record header contains the pattern name which is used to find the main pattern in DFHZCQRT. This is then passed to DFHTBSR to drive the recovery process by calling each builder's UNFLATTEN entry. Each segment is extracted from the recovery record and is passed to the associated builder's UNFLATTEN entry point. These routines usually obtain some storage and copy the segment into it.
At shutdown, auto-installed entries are removed from the catalog with an UNCATALOG call (if they were cataloged as a result of AIRDELAY=0). This drives DFHTBS and the builders to produce similar records to those for a DELETE call, but only to take action to delete the catalog record. This is significantly more efficient than calling the builders to DELETE each entry, as the copy in storage remains untouched.
The key and the recovery record
When the build process in DFHTBSBP has finally finished, this module makes a call to the main builder at the MAKEKEY entry point. The builder produces a key that is used to index the associated recovery record. See Figure 1.
- Information that allows access to the catalog
- The recovery record header
The audit trail
Figure 2 shows the layout of an audit trail. Internally it is known as an action block, which consists of action elements. As each builder is invoked by DFHTBSBP or DFHTBSDP, an action element is appended to the action block. Each element has a reference to a pattern (PATT). This is to allow DFHTBSS to enter the associated builder at the READY or DESTROY entry points.
