HP 3000 Manuals HP 3000 Manuals
SITUATIONS IN WHICH RECOVERY IS REQUIRED
Whenever the file cannot be reopened (error #192 is issued), you must run
KEYINFO to recover the file. The following four cases are typical of the
reasons for file damage. In each case, the suggested action is
discussed.
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.)
If you want to determine how many key values are missing and the file has
more than one key, you can compare the number of values in each B-Tree as
listed by KEYINFO. These values should be identical. When there is only
one key in the file, you can use FCOPY to determine the number of
non-deleted records in the batch file. The number of key values for any
key in the file should exactly match the number of valid data records.
The FCOPY command to determine this value is:
>FROM=filename;TO=$NULL;KEY=0
If your file is very large, using this FCOPY command can be time
consuming and you may prefer to reload the file without checking the
number of missing keys.
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:
![[]](../../pic3k/M010088/F0E01F3c50.gif)
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.
![[]](../../pic3k/M010088/F0E01K3c50.gif)
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).