[an error occurred while processing this directive]

HP OpenVMS Systems

ask the wizard
Content starts here

Corrupted RMS sequential file?

» close window

The Question is:

 
We have a corrupted file with
 
used size = 1281315397 blocks and
allocated size = 8343 blocks
 
---------------------------------
Check RMS File Integrity                      6-DEC-1998 14:22:44.81   Page
 
DSA1323:[SKESPE2.DATA]FCPN_L45.OLD;1
 
 
FILE HEADER
 
	File Spec: DSA1323:[SKESPE2.DATA]FCPN_L45.OLD;1
	File ID: (160,478,0)
	Owner UIC: [OPAP,SMANAGER]
	Protection:  System: RWED, Owner: RWED, Group: RWED, World: RE
	Creation Date:    4-DEC-1998 15:32:19.34
	Revision Date:    6-DEC-1998 14:15:13.83, Number: 652
	Expiration Date: none specified
	Backup Date:     none posted
	Contiguity Options:  none
	Performance Options: none
	Reliability Options: none
	Journaling Enabled:  none
 
 
RMS FILE ATTRIBUTES
 
	File Organization: sequential
	Record Format: variable
	Record Attributes:
	Maximum Record Size: 32767
	Longest Record: 3397
	Blocks Allocated: 8343, Default Extend Size: 0
	End-of-File VBN: 1281315397, Offset: %X'0000'
	File Monitoring: disabled
	Global Buffer Count: 0
***  Attempt to read block with invalid VBN 8345.
Unrecoverable error encountered in structure of file.
 
 
The analysis uncovered 2 errors.
 
 
ANAL/RMS DSA1323:[SKESPE2.DATA]FCPN_L45.OLD;1/OUT=DIGITAL.RMS
 
---------------------------------
 
How this error occured ?
Can we read/recover this file ?
 
 
 
 


The Answer is :

 
  : used size = 1281315397 blocks and
 
  That is a rather large number.
 
  Actually, it looks like a piece of string.  Let's throw it at DCL:
 
    $ x = "1234"
    $ x[0,32] = 1281315397
    $ show sym x
      X = "ER_L"
 
   Considering that allocation and end-of-file are stored as two words
   out of order, this would become the string "_LER".
 
   So this appears to not be a file DATA corruption, but rather a file
   HEADER corruption.  Depending on how widespread the corruption is,
   some or none of the data might be there.
 
   Start with DUMP/HEAD/BLOCK=COUNT=0 to see some details.
 
   You may want to DUMP/BLOCK=(COUNT:1,START:xxx) INDEXF.SYS to
   see the 'raw' file header.
 
   You might need LOGICAL BLOCK QIOs to reconstruct the file data.
 
   The Wizard will not further mention the need for a review of the
   application and system BACKUP schedule.
 

answer written or last revised on ( 15-DEC-1998 )

» close window