SITUATIONS IN WHICH RECOVERY IS REQUIRED

1. Records were being added to the data file when the system failed. The KSAM end-of-file for the data and key files are current, but the MPE end-of-file precedes the KSAM end-of-file (steps 1-3 completed).

   Solution: Run KEYINFO to reset the MPE end-of-file. You can then run the KSAMUTIL command, VERIFY, to determine where the current KSAM end-of-file for the data file is positioned, and then run the MPE command :LISTF 2 to compare the MPE end-of-file. If you run VERIFY before running KEYINFO, use the NOCHECK option so the file can be opened.

2. Records being added to the KSAM file when the system failed were not written to the data file, but some key entries for the new records had been written to the key file (key blocks written to key file because buffer space in XDS was needed). This means that the key file contains key values pointing to records not in the data file.

   Solution: Run KEYINFO to delete the key values that point to records that were not written to the data file.

3. Records being added to the KSAM file when the system failed caused a key block split. As a result, the key blocks are written, but the new internal KSAM end-of-file for the key file has not been transferred to disc. This places certain key values past the old KSAM key file end-of-file.

   Solution: Run KEYINFO to reset the key file end-of-file to the correct location following the existing key values. It still may have to delete any key values pointing to records past the data file end-of-file.

4. Records were being deleted when the system failed. Some key block buffers have been written to disc, but the data block buffer has not. Since some key entries were deleted from the file on disc, but the deleted records remain, key values appear to be missing.

   Solution: You must run KEYINFO to reset the crash flag so the file can be reopened. When key values are missing, KEYINFO cannot fully recover from the file damage and issues the following message:

   	WARNING! THERE ARE SOME RECORD(S) WITH KEY VALUE(S) MISSING THE KSAM FILE HAS TO BE RELOADED

   To reload the KSAM file, use FCOPY to copy the file to a new KSAM file. As it copies the data records, it writes new key entries for each data record. Only in this way can missing key values be recovered. (Refer to the discussion of Reloading a KSAM File later in this section.)

EXAMPLE OF FILE RECOVERY

Suppose you try to open file TEST and receive error message #192:

 

      SYSTEM FAILURE OCCURRED WHILE KSAM FILE WAS OPENED 

In order to have the most information about the file, first run KSAMUTIL and request VERIFY to list all the file information.

 

HP32208Y.2.4. THU, MAR 8, 1979, 12:53 PM KSAMUTIL VERSION:A.3.0 

>V TEST 



WHICH (1=FILE INFO, 2=KSAM PARAMETERS,  3=KSAM CONTROL, 4=ALL)?4 



SYSTEM FAILURE OCCURRED WHILE THE KSAM FILE WAS OPENED  (1068)

                                                           |

            KSAMUTIL error message--------------------------

Just like any other program, the VERIFY command cannot open the damaged file. So try again using the NOCHECK option that allows such a file to be opened for read-only:

The next step is to run LISTF,2 to see where the MPE end-of-file is positioned. Note that you can request the MPE command without exiting from KSAMUTIL.

 

>:LISTF TEST,2 

ACCOUNT= UTILITY       GROUP= KSAM 

FILENAME  CODE  ------------LOGICAL RECORD-----------  ----SPACE---- 

                  SIZ   TYP        EOF      LIMIT R/B  SECTORS #X MX 



TEST      KSAM    80B   FA         900       1023  10      416  8  8 

                                    | 

                                   MPE end-of-file on data file 

LISTF shows the MPE end-of-file after the first 900 records, whereas option 1 of VERIFY showed the KSAM end-of-file after 990 data records. This is a discrepancy of 90 records. These records actually exist. You only have to run KEYINFO to reset the MPE end-of-file. When you run KEYINFO, however, you may find that there are other problems.

 

>KI TEST 

RECOVERY BEGINS 



DATA FILE EOF DAMAGED 



DATA FILE MPE EOF HAS BEEN RESET TO KSAM EOF <----- MPE end-of-file recovered 

After resetting the MPE end-of-file for the data file, KEYINFO continues. It next displays information on the two keys in the file TESTK.

 

--------- INFO FOR KEY                1 --------- 

# OF LEVELS OF B-TREE                           2

# OF KEY BLOCKS                                16

# OF SECTORS PER KEY BLOCK                      8 <-------KSAM end-of-file should 

# OF KEYS IN ROOT KEY BLOCK                    14         be at least 218

# OF KEYS IN B-TREE                          1000 <----|     | 

% OF KEY BLOCK UTILIZATION                     52.1    |     | 

THE LARGEST KEY BLOCK ADDRESS                 210 <----------|

                                                       |

--------- INFO FOR KEY                2 ---------      | 

# OF LEVELS OF B-TREE                           2         # of key entries in two 

# OF KEY BLOCKS                                11      |  keys do not match

# OF SECTORS PER KEY BLOCK                      8      |  each other; do not match 

# OF KEYS IN ROOT KEY BLOCK                     9      |  # of data records 

# OF KEYS IN B-TREE                           997 <----|

% OF KEY BLOCK UTILIZATION                     68.6 

THE LARGEST KEY BLOCK ADDRESS                 202 



WARNING: THERE ARE SOME RECORD(S) WITH KEY VALUE(S) MISSING 

         OR KEY VALUE(S) POINTING TO DATA RECORD BEYOND EOF 

KEY FILE EOF(INTERNAL) DAMAGED 

KEY FILE (INTERlNAL)EOF Has BFEN RESET <---- End-of-file moved forward 

                                             so all key blocks are included 

Looking at the key information displayed for the two keys, the first thing to check is where the actual end of file should be. The largest key block address for key 1 is 210 and each block requires 8 records, therefore the key file end-of-file should be at least 218. If you look back to option 3 of the VERIFY display, it is listed as 210. Since this is not the real end-of-file, KEYINFO resets the KSAM internal end-of-file to the actual end of file (see VERIFY display, below).

Next, check the total number of key values for each key. The first thing to notice is that they do not match each other. The number of key values for each key should always be the same, and each should equal the number of records in the data file. But, if you look at option 1 of the VERIFY display, the number of records in the data file is 990, less than the number of key values for either key. (Note that if the file contains records marked for deletion, you can run FCOPY to determine the number of active records).

In response to this discrepancy, KEYINFO deletes 10 key values from each key. The values deleted are those that have no matching data record. This completes the KEYINFO functions. Now that it has deleted 10 key values from the key entries for key 2, only 987 are left (997 minus 10). This is three fewer than the number of key values in key 1 (990 = 1000 -10). For this reason, KEYINFO must issue the warning that the file needs to be reloaded:

 

--------- KEY SEQUENCE             1 --------- 

# OF INVALID KEY VALUES DELETED             10<-----10 values deleted that 

                                                    have no matching data record.

--------- KEY SEQUENCE             2 ---------        | 

# OF INVALID KEY VALUES DELETED             10<-------|

RECOVERY ENDS 



WARNING: THERE ARE SOME RECORD(S) WITH KEY VALUE(S) MISSING 

         THE KSAM FILE HAS T0 BF RELOADED 

Before reloading the file, as described below, use LISTF,2 to check the current MPE end-of-file (after recovery); run VERIFY to check the current KSAM end-of-file positions; and run KEYINFO again to see the number of key values left in each key following the previous KEYINFO recovery.

The name of the user who runs KEYINFO to recover the file for the RESET DATE shown by VERIFY is stored in the key file control block, along with his account, group, and home group (refer to Figure B-5 “Control Block and Key Descriptor Block”).