[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference vmszoo::rms_openvms

Title:	RMS asks, 'R U Journaled?'

Moderator:	STAR::TSPEERUVEL

Created:	Tue Mar 11 1986
Last Modified:	Wed Jun 04 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	3031
Total number of notes:	12302

3030.0. "Corrupt index file, good data extract tool??" by KERNEL::PULLEY (Come! while living waters flow) Tue May 13 1997 10:52

    Hi,
    
    I've a customer using VMS v5.5-2, & ACMS.
    His ACMS queue file, (which is indexed on a single key), got corrupted.
    So he tryed converting it to a sqeuential file but got the same RMS
    bucket format check error that he gets when ACMS trys to dequeue from
    the file.
    I think the file is of the order of 300000 blocks, so he's interested
    in recovering as many records as he can.
    His idea was to write something that goes through the file sequentially
    till it hits the error, then switch to the index, to read from the next
    key of the last successfully read record, and then go back to
    sequential reads after the error has stopped.
    One trouble is that he hasn't got the complete layout of the file, just
    the FDL.
    
    Is there any kind of tool that can go through a file, and pull out the
    good bits?
    
    Thanks for any comments/suggestions,
    Steve.
    P.s., base on ACMS notes 4165.*.

T.R Title User Personal
Name Date Lines

3030.1 EPS::VANDENHEUVEL Hein Tue May 13 1997 13:21 29

T.R	Title	User	Personal Name	Date	Lines
3030.1		EPS::VANDENHEUVEL	Hein	`Tue May 13 1997 13:21`	29
	The ACMS queue file has a binary key no? It is a fairly straighforward to write a program to start reading, then upon error binary seacrh for the next larger value which returns a valid record and continue reading from there. Manually walking the index buckets with ANAL/RMS/INT can also help you to quickly find the next key value beyond an error. The CSC alledgedly has programs to do just this. I wish they'd share them with the world. Thilo Lauer is also working on a more or less automated recovery tool exploiting the index information to know where to be in the file. > I think the file is of the order of 300000 blocks, so he's interested > in recovering as many records as he can. I seem to recall that the acms queue file at the 'end of the day' should be (nearly) empty. Thus you task may well be complete if you recover 5 records. Supposedly they failed to re-convert this file in a timely fashion. DO charge them for your efforts. Cheers, Hein.

    
    The ACMS queue file has a binary key no? 
    It is a fairly straighforward to write a program to start reading,
    then upon error binary seacrh for the next larger value which 
    returns a valid record and continue reading from there.
    Manually walking the index buckets with ANAL/RMS/INT can also 
    help you to quickly find the next key value beyond an error.
    
    The CSC alledgedly has programs to do just this.
    I wish they'd share them with the world.
    
    Thilo Lauer is also working on a more or less automated recovery tool
    exploiting the index information to know where to be in the file.
    
   > I think the file is of the order of 300000 blocks, so he's interested
   > in recovering as many records as he can.
    
    I seem to recall that the acms queue file at the 'end of the day'
    should be (nearly) empty. Thus you task may well be complete if you
    recover 5 records. Supposedly they failed to re-convert this file
    in a timely fashion.
    
    DO charge them for your efforts.
    
    Cheers,
    	Hein.