Control flow and the RAUX control task

RAUX control task overview

If integrated auxiliary utility processing has been requested, the recovery auxiliary utility (RAUX) control task is started. The MAS then starts the number of recovery sort subordinate (RSS) address spaces corresponding to the SORTPARM(NUM(xx)) parameter.

The RSS restores the ICs, sorts the log and CA records sent to it by the MAS, and applies the database updates to create a restored database data set or, alternatively, an incremental image copy (ICR).

As the database blocks are updated and written to the recovered database, they can also be processed in parallel by the IC and pointer checker (PC) tasks. Blocks need only be read once, but can be processed by both IC and PC in parallel. This is more efficient than running IC and PC as separate job steps after the recovery job step.

The MAS attaches the number of log and CA read tasks that corresponds to the LOGNUM parameter. These tasks:

• Determine the correct RSS to send the database update records to,
• Buffer them,
• Send them to the RSS where they are sorted,
• Apply the records as updates to the database blocks restored from the ICs.

For offsite storage, remote site recovery, or testing purposes, recovered databases can be written to:

• The production database,
• An ICR, or
• A duplicate copy database.

If ICs of the restored database are requested, the blocks for them are written in parallel. Any ICs created are registered in the RECONs during MAS termination.

Instead of ICs, ICRs can be created by restoring the most recent IC and applying all log and CA database update records. The difference in this case is that the output of the recovery is an IC rather than a restored database.

The resulting IC may be a Batch-IC or Concurrent-IC, depending on whether the database was online at the time of the ICR. The IC created by the ICR process is registered in the RECONs and is usable in subsequent database recovery.

RAUX control task results

The RAUX control task in the MAS serves to initialize, monitor, drive processing for, and collect results from the integrated auxiliary utilities running throughout the address spaces participating in the recovery.

Results include:

• SYSOUT reports,
• Return codes, and
• Write To Operator (WTO) messages issued to consoles or job logs.

RAUX services are provided via z/OS® cross-memory services to all address spaces that require them. The RAUX allocates its major control block to store the results of the integrated auxiliary utilities. Updates to that control block may be done from any address space involved in the recovery.

When the MAS arrives at its termination logic, the RAUX organizes all of the integrated auxiliary utility results and stores them as directed by the MAS JCL and its parameters.

Image copy and pointer checker processing

If pointer checking was selected for a full function database data set, then the RAUX starts the IMS High Performance Pointer Checker DMB Analyzer (PC-UAS) procedure FABPATHx.

If image copy or pointer processing was requested for any database data set, then the RAUX control task starts IMS High Performance Image Copy or IMS High Performance Pointer Checker in the RSS.

In the RSS, IMS HP Image Copy, IMS HP Pointer Checker, and DEDB Pointer Checker run under separate tasks so that their services can be multi-threaded for the purpose of efficiency. For example, IMS HP Pointer Checker can be in the process of collecting information on the database pointers in a block at the same time that the database block is being written by IMS HP Image Copy to the IC data set.

HALDB support

IMS Database Recovery Facility also has the capability of rebuilding the PHIDAM primary index and ILDS data set for a HALDB partition.

This is accomplished by starting the procedure identified by the DRFIAX control statement. This PR-UAS is started just before MAS termination and after all recovery processing for the HALDB partitions has completed.

A new PR-UAS is started for each HALDB partition database data set. This is because DFSPREC0 is not able to operate on more than one of these HALDB partition database data sets in a given execution.

Once again, the services of the RAUX are used to capture the reports and return codes from DFSPREC0, and they are communicated back to the master address space for inclusion on the reports.

Index build processing

IMS Database Recovery Facility can also invoke IMS Index Builder to build the primary and secondary indexes for Full Function databases and secondary indexes for HALDB partitioned databases.

IMS Index Builder can build HALDB primary indexes and ILDSs. To rebuild these HALDB components, IMS Database Recovery Facility uses DFSPREC0, and not IMS Index Builder.

You can use the Build Index function of FPA to rebuild secondary indexes for Fast Path DEDB databases.

When index rebuilding has been requested, the MAS starts either the utility address space for IMS Index Builder (IB-UAS) or the utility address space for the Build Index function of FPA (FS-UAS) just before its own ending.

In IMS Index Builder, the IB-UAS starts the IBSS for running IMS HP Image Copy and IMS HP Pointer Checker / DEDB Pointer Checker when requested by the MAS. The indexes themselves are built in the IB-UAS.

Again, the RAUX is active to capture reports, return codes, and WTO messages so they can be communicated back to the master for organization.

Note that IMS Database Recovery Facility is able to recover most types of indexes, provided an image copy has been kept and the indexes are registered as RECOV in DBRC. If an image copy has been kept, it is more efficient to let IMS Database Recovery Facility recover the index during the recovery in the RSS than it is to run IMS Index Builder or the Build Index function of FPA at the end of all recovery processing as a separate process.

However, if a corrupted index was copied or the copy was destroyed, running IMS Index Builder or the Build Index function of FPA can be the only option.

Verification by IMS Library Integrity Utilities

IMS Library Integrity Utilities verifies that the DBD library being used in the recovery (the one allocated to the IMS DD in the MAS JCL) is correctly matched to the database data sets being recovered and processed by the other integrated auxiliary utilities.

This verification prevents database corruption that can happen by allocating the wrong DBD library, such as one being used for new application testing.

IMS Library Integrity Utilities runs in the MAS and dynamically allocates its library control (LICON) data set based on information in the IMS Library Integrity Utilities load library concatenated to the STEPLIB DD.

All IMS Library Integrity Utilities messages are written to the MAS job log. There is no specific IMS Library Integrity Utilities SYSOUT report data set written or appended to the MAS REPORT DD.

However, there is an IMS Library Utilities Final Return / Reason Code in the Utility section of that report. If you see a non-zero return code, you should examine the Master job log for FABLxxxxE messages. If IMS Library Integrity Utilities determines that an incorrect DBD library has been allocated, the recovery is halted to prevent database corruption.