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

Conference iosg::all-in-1_v30

Title:	OLD ALL-IN-1 (tm) Support Conference
Notice:	Closed - See Note 4331.l to move to IOSG::ALL-IN-1
Moderator:	IOSG::PYE

Created:	Thu Jan 30 1992
Last Modified:	Tue Jan 23 1996
Last Successful Update:	Fri Jun 06 1997
Number of topics:	4343
Total number of notes:	18308

528.0. "DOCDB.DAT corrupted can not do a convert or edit/tpu" by GIDDAY::SETHI (Man from Downunder) Tue Apr 21 1992 09:11

    G'day,
    
    Another one of those nasty DOCDB.DAT problems.  A customer ran the TRU
    housekeeping routine and it came up with a few error, it's the first
    time the customer has run the HK.
    
    One user had a problem with the DOCDB.DAT when the customer did a
    analyze/rms/check docdb.dat the following errors was displayed -> Record
    too long (7 times).
    
    I asked the customer to do the following
    
    CONVERT/NOSORT/NOTRUNCATE/EXCEPTIONS_FILE=LONGREC.DAT -
        /FDL=OA$LIB:DOCDB.FDL DOCDB.DAT DOCDB.NEW
    
    The process was logged out when the customer pressed return the
    Username: prompt came up.
    
    I also tried it with /nosort it created an output file 18 blocks long
    the input is 330 blocks nothing was found in the exceptions file.
    
    I asked him to do the following 
    
    1. EDIT/TPU DOCDB.DAT
    
    The process was logged out when the customer pressed return the
    Username: prompt came up.
    
    I have read in note 120 that a tool is available from the Atlanta CSC
    ONLY if you are trained.  Or there is a home made DOCDB fixer and I
    have to buy it with a few beers.  I am not sure if these tools would
    work in this case because the process is logged out, if I am wrong can
    I get a hold of these tools ?  Or what else can I do ?
    
    Thanks
    
    Sunil

T.R	Title	User	Personal Name	Date	Lines
528.1	Corruption crashing RMS	IOSG::TALLETT	Just one more fix, then we can ship...	`Tue Apr 21 1992 09:26`	9
	I think it is an ACCVIO tye of error in RMS that is causing your process to get killed (due to the elevated processor mode). I seem to remember this being discussed in either the old ALL-IN-1 conference or VMSNOTES, but it might be hard to locate... Regards, Paul
528.2	RECOVER fixed it for us	IOSG::CHAPLIN	Andy Chaplin	`Tue Apr 21 1992 12:01`	4
	FYI we had the same problem with a DOCDB on our system once - the RECOVER tool fixed it. Andy
528.3	Call the CSC	AIMTEC::PORTER_T	Terry Porter, ALL-IN-1 Support, Atlanta CSC	`Tue Apr 21 1992 16:13`	20
	If the customer has a contract call the CSC and we will fix it. For us to run the tool we need dial-in and Kermit (to transfer the tool). If Kermit is not available there are alternatives, but we do need dial-in. The restrictions of the distribution of this tool are imposed by the 'owners' which is the ATIT team, if you feel you have a need for this tool you should approach them for a copy. Since the re-organisation of CSSE I am not sure who is the correct person to contact, maybe someone in the know will post it here. The problem with the tool is that it can not always detect how much of the file it has recovered (it recovers all it can find, but the nature of the corruption may be such that the tool thinks it has found the whole file when it has not). You need to understand how RMS is structured and the internals of the tool in order to determine if it has worked properly in the cases where the size of the output file is significantly smaller than the size of the input file but no errors have been reported. Terry
528.4	DOCDB was recovered by using RECOVER	GIDDAY::SETHI	Man from Downunder	`Thu Apr 30 1992 09:24`	10
	G'day, The RECOVER tool did work the DOCDB.DAT had a record that was too long. The problem that I had with the analyze/rms/check docdb.dat logging out my process was caused by a non-fatelbugcheck from RMS. To find out I did a analyze/error_log/since=today/include=bugcheck and this pointed to a RMS problem. Sunil