[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

2344.0. "TRU Inconsistencies" by AIMTEC::GRENIER_J () Mon Mar 01 1993 19:27

    Customer ran TRU in repair mode.  It seemed to work as documented
    for files with .TXT, .WPL, .WPC - - BUT, for documents with a
    .FGN it just listed them.  It told you there was no corresponding
    DOCDB pointer, or RMS file - but did not delete the DAF record.
    Running TRU a second time on these users, did in fact delete the
    .FGN records????
    
    Is that the way it is suppose to work????
    
    
    Jean
T.RTitleUserPersonal
Name		DateLines
2344.1The dark prince IOSG::MAURICEBecause of the architect the building fell downTue Mar 02 1993 08:2014
    For missing files in the shared areas, the first time it detects them
    it prints a list so that the Manager has a chance of recovering them
    from backup. The second time, with a smug inner feeling of "I did warn
    you", it whops them.
    
    For missing files in the private areas there is no mercy shown. In an
    orgy of wilful destruction the cold dark executioner removes all the
    references. The memorials to these files are sad little epitaphs in the
    log file.
    
    TRU does not care whether the files are lower class .TXT files or noble
    .FGN files. 
    
    Stuart
2344.3Still confusedAIMTEC::GRENIER_JTue Mar 02 1993 12:199
    Stuart - that is what I "thought".  However, these .FGN pointers which
    do NOT get deleted the first time are in the private file cabinet -
    [.DOC6]ZUMYM76UV.FGN.  However, they do get deleted the second time
    around....  There is no corresponding RMS text file nor DOCDB pointer.
    
    
    Still confused......
    
    Jean
2344.4IOSG::MAURICEBecause of the architect the building fell downTue Mar 02 1993 13:2821
    For the first time round what does the log say? It should log the
    deletion of the DOCDB record followed by a message saying that the PDAF
    record has also been deleted. 
    
    Looking at the code it looks as if there is a "feature" that it will
    not delete any PDAF contination records, and so they would be left for
    the next run of TRU. This matches your symptoms. Continuation records
    would happen if there are a signiciant number of attributes on the DAF
    record. These attributes are the set of extended attributes described
    in Table 8-4 of APR Vol 1, and the most common scenario to generate
    continuation records is a plethora of TOs and/or CCs. Could you go to
    one of the .FGN documents and do a 
    
    	<for cab$attributes do get .key " " .value
    
    Pressing GOLD W would show you them all. Perhaps you could let us know
    how many there were.
    
    Cheers
    
    Stuart
2344.5Thanks - I thought we were seeing thingsAIMTEC::GRENIER_JTue Mar 02 1993 16:2220
    Hello Stuart - unfortunately customer ran TRU the second time and
    these .FGN pointers are gone.  However, what you said sounds like
    what her problem was.  She had WordPerfect documents she imported
    as .FGN and then created a procedure to convert the extension from
    .FGN to .WPC - but forgot to change the DAF pointer at that time.
    
    Her log file said:
    
    PDAF record found without DOCDB entry or RMS text file
      Key = [.doc4]zuntb78l7.FGN
    
    
    I was just trying to verify that it could take 2 runs for the pointers
    to get deleted - and it sounds like that is right.  And these
    particular files would have had a large CC list.  So I guess you
    answered my question as to "why". 
    
    
    Thanks a bunch
    Jean