Checking Data Source Integrity: The CHECK Subcommand

In this section:

How to:

It is rare for the structural integrity of a FOCUS data source to be damaged. Structural damage will occasionally occur, however, during a drive failure or if an incorrect Master File is used. In this situation, the REBUILD CHECK command performs two essential tasks:

Although CHECK is able to report on a good deal of data that would otherwise be lost, it is important to remember that frequently backing up your FOCUS data sources is the best method of preventing data loss.

CHECK will occasionally fail to uncover structural damage. If you have reason to believe that there is damage to your data source, though CHECK reports otherwise, there is a second method of checking data source integrity. This method entails using the ? FILE and TABLEF commands. Though this is not a REBUILD function, it is included at the end of this section because of its relevancy to CHECK.

Procedure: How to Use the CHECK Subcommand

The following steps describe how to use the CHECK subcommand:

  1. Initiate the REBUILD facility by entering:
    REBUILD

    The following options are available:

    1. REBUILD        (Optimize the database structure)
2. REORG          (Alter the database structure)
3. INDEX          (Build/modify the database index)
4. EXTERNAL INDEX (Build/modify an external index database)
5. CHECK          (Check the database structure)
6. TIMESTAMP      (Change the database timestamp)
7. DATE NEW       (Convert old date formats to smartdate formats)
8. MDINDEX        (Build/modify a multidimensional index)
  2. Select the CHECK subcommand by entering:
    CHECK or 5
  3. Enter the name of the data source to be checked.

    On z/OS, enter the ddname.

    On UNIX, Windows, and OpenVMS, enter filename. The data source to be rebuilt will be referenced by a USE command. If no USE command is in effect, the data source will be searched for using the EDAPATH variable.

Statistics appear during the REBUILD CHECK procedure:

  • If no errors are found, the statistics indicate the number of segments retrieved.
  • If errors are found, the statistics indicate the type and location of each error:

    DELETE indicates that the data has been deleted and should not have been retrieved.

    OFFPAGE indicates that the address of the data is not on a page owned by this segment.

    INVALID indicates that the type of linkage cannot be identified. It may be a destroyed portion of the data source.

Example: Using the Check Subcommand (File Undamaged) in Windows

The following procedure:

1. REBUILD 
2. CHECK 
3. EMPLOYEE
  1. Initiates the REBUILD facility.
  2. Specifies the CHECK subcommand.
  3. Provides the name of the data source to check.

    The data source will be checked and the appropriate statistics will be generated.

Confirming Structural Integrity Using ? FILE and TABLEF

How to:

When you believe that there is damage to your data source, though REBUILD CHECK reports there is not, use the ? FILE and TABLEF commands to compare the number of segment instances reported after invoking each command. A disparity indicates a structural problem.

Procedure: How to Verify REBUILD CHECK Using ? FILE and TABLEF

  1. Issue the following command:
    ? FILE filename

    where:

    filename

    Is the name of the FOCUS data source you are examining.

    A report displays information on the status of the data source. The number of instances for each segment is listed in the ACTIVE COUNT column.

  2. To ensure that the TABLEF command in the next step counts all segment instances, including those in the short paths, issue the command:
    SET ALL = ON
  3. Enter:
    TABLEF FILE filenameCOUNT field1 field2END

    where:

    filename

    Is the name of the Master File of the FOCUS data source.

    field1...

    Are the names of fields in the data source. Name one field from each segment. It does not matter which field is named in the segment.

    The report produced shows the number of field occurrences for those fields named and thus the number of segment instances for each segment. These numbers should match their respective segment instance numbers shown in the ? FILE command (except for unique segments which the TABLEF command shows to have as many instances in the parent segment). If the numbers do not match, or if either the ? FILE command or TABLEF command ends abnormally, the data source is probably damaged.

Example: Checking the Integrity of the EMPLOYEE Data Source

User input is shown in bold. Computer responses are in uppercase: 

? FILE 
STATUS OF FOCUS FILE: c:employee.foc   ON 01/31/2003 AT 16.17.32
                ACTIVE  DELETED    DATE OF    TIME OF    LAST TRANS
SEGNAME         COUNT   COUNT      LAST CHG   LAST CHG   NUMBER
 
EMPINFO           12             05/13/1999   16.17.22      448
FUNDTRAN           6             05/13/1999   16.17.22       12
PAYINFO           19             05/13/1999   16.17.22       19
ADDRESS           21             05/13/1999   16.17.22       21
SALINFO           70             05/13/1999   16.17.22      448
DEDUCT           448             05/13/1999   16.17.22      448
TOTAL SEGS       576
TOTAL CHAR      8984
TOTAL PAGES        8
LAST CHANGE                      05/13/1999   16.17.22      448 
SET ALL = ON
TABLEF FILE EMPLOYEE
COUNT EMP_ID BANK_NAME DAT_INC TYPE PAY_DATE DED_CODE
END 
 
PAGE     1
 
 EMP_ID  BANK_NAME  DAT_INC  TYPE   PAY_DATE  DED_CODE
 COUNT   COUNT      COUNT    COUNT  COUNT     COUNT
 ------  ---------  -------  -----  --------  --------
     12         12       19     21        70       448
NUMBER OF RECORDS IN TABLE=      488 LINES= 1

Note that the BANK_NAME count in the TABLEF report is different than the number of FUNDTRAN instances reported by the ? FILE query. This is because FUNDTRAN is a unique segment and is always considered present as an extension of its parent.