Conference iosg::all-in-1_v30

Sunil,

	If the files prolog is corrupt then save using $PATCH I know of
	no utility to fix it.

	Best bet is to go back to BACKUP. Shared documents will have entries
	in an SDAF and should have no PDAF entries. 

	Private documents can be located via the DOCDB and dummy PDAF entries
	built.  For example :-

		<FOR CAB$ WITH .DAPOINTER = "P" DO GET FILENAME

		Create a temporary PDAF record (C from WP etc)

		$ OPEN/READ/WRITE/SHARE DAF DAF.DAT !($BACKUP DAF)
		$ READ DAF DUMMY_REC !(Record for temporary PDAF record)

	Then for each filename identified above

		$ NREC = DREC
		$ NREC[0,40]:==filename
		$ WRITE DAF NREC

	This only needs to be done for private documents created since the 
	last $BACKUP.

	Hope this helps ...

Cheers,

Iain.

    Iain,        
    
    I read the ALL-IN-1 Management Guide ALL-IN-1 Housekeeping page 9-31.
    
    In table 9-13 it say's the following 
    
    Error			Repair
    
    DOCDB record without        PDAF record created
    PDAF record
    
    So was I wrong to assume the following
    
    1. CREATE/FDL=OA$LIB:PDAF DAF.DAT
    2. Then run the TRU only for that user so that all the DAF pointers are
       recovered as stated.
    
    I did just that and I got the problem as in point 3. in the base note.
    
    >3. create/fdl=oa$lib:pdaf daf.dat and customer ran the TRU HK. I was
    >   hoping that the procedure would rebuild PDAF when run for that user,
    >   it didn't work.
    >
    >       The following error message was written to the logfile :-(
    >
    >       %OA-W-SUBTERM, Error occured in subprocess "000006B4"
    >       %NONAME-W-NOMSG, Message number 6F228E80
    >
    >       The lexical function f$message does not give any more
    > 	    information.
    >
    >       Phase 2 and 3 did not run due to the error in Phase 1.
     
    Have I misunderstood something ?  Because it looked to me to be the
    best and easiest solution to the problem and the customer would not
    find it too difficult to do.  I am not doubting your solution at all I 
    just thought that an empty DAF.DAT would do the job reading the
    documentation.
    
    Thanks
    
    Sunil

    Sunil,
    
    	Yes. What's in the manual should work (ish). However, any useful
    	extended document attributes (TOs, CCs, etc.) will be lost. It
    	may be that all the entries in the PDAF were for documents rather
        than unsent mail etc. In this case there are few extended
    	attributes to lose (LANGUAGE).
    
       	As to why it isn't working for you - I'm not sure. Here's some
    	things to check :-
    
    		o	Make sure that you created the new PDAF in the 
    			correct location (OAUSER:DAF.DAT) with the right
    			protections etc.
    
    		o	Check that the DOCDB is sound ($ANAL/RMS)
    
    		o	Check for errors in the A1SUB.LOG created by 
    			TRU ([ALLIN1.MGR]A1SUB.LOG)
    
    		o	If necessary turn all tracing on and post a pointer
    			to the trace log.
    
    Cheers,
    
    Iain

    G'day,
    
    I could not recover DAF.DAT because the files PROLOG was missing and
    RECOVER failed.  Could someone explain what is PROLOG ?
    
    Now here is the story of the creeping death !!
                        
    See note 528 deals with the DOCDB.DAT problems on the same customer
    site.
    
    I had asked the customer to do a analyze/disk/repair <disk_with_probs>:
    a file was recovered.  The customer ran the PT Housekeeping procedure
    and no problems were reported.  However when he ran the TRU
    Housekeeping procedure it died as reported in this topic.  More user
    filing cabinets and pdaf's were getting corrupted.  The customer was
    convinced that it was the TRU HK that had caused the problem (blame it
    on DEC).
    
    However he informed us later that he had 3rd part disks installed and
    the hardware engineers said that analyze/disk/repair may not have
    worked.   They asked the customer to do analyze/disk/read and the
    following error showed up :-(
    
    	    17 x forced errors
            5 x bad headers
            5 x bad highwater
            100s bad fidnum
            100s bad dir entries
            blocks incorrectly allocated
            deleted files marked busy
     
    The customer had a corrupted disk drive.  I hope he feels a bit
    embrassed now because TRU HK certainly did not corrupt the DOCDB's and
    PDAF's.
    
    I just thought that I would let you know what happened it might be
    useful to check the disk using analyze/disk/read if this ever occurs.
    I'll let you all know what happens when you run the TRU to recover the
    PDAF.DAT.
    
    Sunil

    Sunil,
    
    	The PROLOG of an indexed file is located in the first block of the
    	file. It contains pointers to the file's area and key descriptors
    	and therefore is absolutely required for any RMS processing.
    
    	If the PROLOG is corrupt I know of no tool to fix it apart from
    	$PATCH.
    
    Cheers,
    
    Iain.

    G'day
    
    The final chapter, the DAF.DAT is unrecoverable.
    
    I talked to one of the RMS gurus we did the following :-
      
      $ dump/blocks=(count:1) daf.dat as per the Stars Article and the
       PROLOG entry was beyond repair.
    
    Therefore PATCH could not fix the problem.
    
    The Stars article is called :-)
    
    83-Error message "Prolog block checksum is invalid" in indexed file 
    
    Sunil