A Faster and Safer Recoup - JUL 1996
by Anita Cheung and John Tarby, IBM TPF Development, and Alex Renko, formerly of IBM

If there is any one task that can cause a database administrator to lose sleep, it is recoup. There are war stories about how a bad directory rollin ended up corrupting databases and causing extensive down times. Even when things are carefully managed, you will find a bleary-eyed coverage programmer who was up all night on Sunday waiting for recoup to be completed, analyzing the record counts and, finally, putting their reputation on the line by authorizing a pool directory roll-in.

After discussions with concerned customers, IBM has enhanced TPF recoup with APAR PJ21224, which is designed to improve your recoup phase 1 and phase 2 performance while, at the same time, preventing the most common instances of database corruption caused by human error.

The following lists the highlights of APAR PJ21224:

• Use of tape blocking and control unit buffering for the RCP (and RCI) tapes.
• A revised restart checkpoint mechanism to prevent potential loss of data because of IPLs during phase 1 or tape errors.
• A larger recoup logging block (4 K instead of 1 K). This reduces the amount of tape I/O required during phase 1 and phase 2.

In addition to offline program sequence checking for the RCP tapes, there are additional checks to ensure that RCP tapes are complete (last tape not omitted, first tape missing) and are all from the same recoup run.

A time stamp from phase 1 is placed on the RCP tapes and will be propagated back to all RPE tape pseudo directories for checking during phase 3. This will ensure that the correct RPE tape has been mounted. The same time stamp is placed on the input RCI tape.

The pre-phase 1 descriptor writer (BKDR) has been enhanced to return a nonzero error code for any warnings and errors.

Tape error handling is much different from before. The tedious "tape write immediate" operation has been removed and replaced with fast buffered tape I/O. Tape errors will be reported by the tape support code and recovery of data will be performed as needed. In the unlikely event that the data cannot be recovered, some problems will require a ZRECP ABORT. For other tape device errors, you can use a ZRECP RESTART to restart the processing.

The time stamping of RCP, RCI, and RPE records (in addition to sequence checking) prevents database corruption that results from the mishandling of tapes. Coverage programmers should still be aware that incorrectly defined descriptor records or the use of the wrong general file can cause database corruption.

Some migration considerations need to be mentioned:

Old RCP and RCI tapes cannot be used with APAR PJ21224.

Apply APAR PJ21224 to all loosely coupled processors at the same time before running a loosely coupled chain chase. Because all of the changes made were made to real-time segments, this can easily be accommodated via the E-type loader without any down time.

Issue ZTLBL commands for all processors and all subsystem users to change the tape labels for the RCP and RCI tapes to blocked mode.

A change to the RCI tape format to support 4 K input blocks also requires a change to the descriptor segment that describes the RCI tape item.

New JCL is needed for RCI and RCP tape processing because of the changes from the 1055 byte to 4 K logging block.

If TPFDF 1.1.3 is installed, you need to apply TPFDF APAR PN78979.

Customer experience and our own estimates show that applying APAR PJ21224 may improve your phase 1 and phase 2 times by as much as 40% while reducing the number of tape cartridges required.

We hope that your bleary-eyed coverage programmer will be able to get home earlier because of faster turnaround times and sleep better knowing that the tapes used were, indeed, the correct ones.