|
HP OpenVMS Systemsask the wizard |
|
The Question is: We are experiencing corrupted data in our files. We are receiving errors involving Bad VBNs. We have followed all of the steps for recovery involving "Convert/Sort", creating a sequential file and doing a "Convert/Key", etc. We are now on the option of trying to take the data and read each record sequential and create a separate file of the good records. We have to attempt to do a keyed read on a file where the key has two parts: Order base (8 character field with a leading zero) and Location (2 character field). An example of the key may look like this: 04857546 or 0487546A We have been provided some information that suggests the we do a sequential read on the file, when it hits the bad block, then go to a 'keyed' read until you are past the bad blocks, then continue with the sequential read. We are unclear on the proper format of the 'keyed' read. We have attached our code. Can you see what we may be doing wrong with the definition of the key? $ OPEN/READ INPUT_FILE 'P1' $ OPEN/WRITE OUTPUT_FILE 'P2' $! $ READ_LOOP: $! $ READ/END_OF_FILE=END/ERROR=BAD_VBN INPUT_FILE THING $ COUNT = COUNT + 1 $! $ WRITE OUTPUT_FILE THING $ COUNT2 = COUNT2 + 1 $ ORDER = F$EXTRACT(1,8,THING) $ LOC = "##" $ RECKEY = ORDER+LOC $! WRITE SYS$OUTPUT "OKAY RECORD ",RECKEY $! $ GOTO READ_LOOP $ END: $ CLOSE OUTPUT_FILE $ CLOSE INPUT_FILE $ WRITE SYS$OUTPUT "READ ",COUNT," WRITE ",COUNT2 $! $ BAD_VBN: $ WRITE SYS$OUTPUT "BAD RECORD ",RECKEY $! $ LOC = "##" $ ORDER=ORDER+1 $ RECKEY = ORDER+LOC $ READ/END_OF_FILE=END/KEY='RECKEY'/INDEX=0/-MATCH=GE/ERROR=OOPS INPUT_FILE THING $ GOTO READ_LOOP $! $ EXIT The Answer is :
It would initially appear that you have a failing disk, or that
you have a problem with your storage hardware or configuration.
You will also want to move to OpenVMS VAX V6.2 or V7.2, and you
will want to apply all mandatory ECO kits. The ECO kits needed
here specifically include any available ECOs for locking, the XQP,
and RMS, in addition to all mandatory ECO kits.
Your approach toward data recovery appears reasonable, though the
missing component involves determining the next valid key value.
Most obviously, simply try the next key value in sequence -- this
approach will work when the key space is dense; when there are no
large gaps between adjacent key values. If there are large gaps,
this approach can be very slow.
An example:
$bad:
$ ORDER=ORDER+1
$ IF ORDER .GT. MAX_ORDER THEN GOTO GIVE_UP
$ RECKEY = ORDER+"##"
$ READ/END=END/KEY=RECKEY/MATCH=GE/ERROR=bad INPUT_FILE THING
$ ! Back on track
$ WRITE OUTPUT_FILE THING
$ GOTO read_sequential
The best guess for the next good key to try is to read from the
level-1 index records in the RMS file. You can retrieve these values
from ANALYZE/RMS/INTERACTIVE, though this approach will clearly be
rather tedious. Alternative methods include binary search for the
key, or scraping old backups of the file for the keys, or scraping
related business information files that might cross-reference the
valid key values.
|