You can use S6BBRPTR to validate the integrity of page images. S6BBRPTR reads in an archive file or offline segment and validates the horizontal and vertical pointers. If multiple segments are contained within the same archive data set, you must run this utility against each segment individually.
The input to the S6BBRPTR utility can be either an archive file from tape or disk or an offline segment. The archive file that you input to this utility must be generated by doing one of the following:
The S6BBRPTR member of the JCL data set distributed with TIBCO Object Service Broker contains sample JCL required to run this utility to check an archive.
This work file holds a small number of pages that must be retained in their entirety. These pages are saved for a select group of page types that are required during processing. It is unlikely that you need to retain more than 50 of these pages for the pointer validation process. This file contains fixed length 4096 byte records. We recommend that you use VIO space for this file.
The index information file is a work file used to retain indexing information during the pointer validation process. The file is a variable length blocked file and should be defined with a maximum record length of 4800 bytes. We recommend that a VIO type unit be used. As a general guideline, allow about 20 records per cylinder of space.
The audit log provides information on each of the tables that exist in the segment, each error condition found, plus a number of summary items. It contains important information for tracing problems and should be retained.
An orphan page is a page that is not available for use and is not referenced by a table. A page that is referenced by a table but is available for use is reported as
REFERENCED BUT INDICATED FREE.
In the orphan file, the ORPHAN pages are listed with the previous and next page pointers as well as the page type.
REFERENCED BUT INDICATED FREE pages are listed as a page number followed by the message text.
The orphan list file must be a sequential file with a record length of 80 bytes, fixed block. Since orphan pages are an operating exception, a static allocation of five tracks should suffice. Retain the orphan list file so you can compare the results with those generated by a future run. Contact TIBCO Support if the number of orphan pages continues to increase. The utility S6BBRPGC can be used to reclaim orphan pages.
The reference log lists each referenced page in the segment. The log identifies the table, forward and backward chain pointers, and parent information. This information helps identify how the page fits in the Pagestore. The reference log has the following format:
The REFLOG file must be a sequential file with an 80 byte record length, fixed block. As a guideline, you should allocate one track of REFLOG for every four cylinders of space. The information in the reference log should be retained. It is intended to help the TIBCO Support identify problems should they arise.
This file contains a list of the header information for each page read. This information is often needed when investigating problems with the structure of the Pagestore.
The error log lists tables with errors. Refer to Audit Log (AUDIT) for more information about how errors are reported. If ERRLOG is to be used as input to S6BBRPGC to reclaim orphan pages, it should be created as a 132-byte FB file. Otherwise, it can be directed to SYSOUT.
S6BBRPTR extracts the timestamp from page 1 and puts it in the ERRLOG in the form
ID=xxxxxxxxxxxxxxxx. S6BBRPGC checks this timestamp against the then current page 1 before acting on any orphan-recovery request. If there is no
ID= line in ERRLOG or if the stamps do not match, the job aborts. If, after checking that the ERRLOG is still valid against the indicated segment, you decide to proceed with the recovery, either insert the following line after the headings in the ERRLOG file, or modify the existing
ID= line, as appropriate: