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

Conference iosg::all-in-1

Title:ALL-IN-1 (tm) Support Conference
Notice:Please spell ALL-IN-1 correctly - all CAPITALS!
Moderator:IOSG::PYECE
Created:Fri Jul 01 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:2716
Total number of notes:12169

2473.0. "Help Understanding What TRM is Doing?" by AIMTEC::GRENIER_J (Jean Grenier) Sun Jan 19 1997 19:28

T.RTitleUserPersonal
Name
DateLines
2473.1SOMEONE - Please ReplyAIMTEC::GRENIER_JJean GrenierTue Jan 21 1997 14:335
2473.2Sorry, but we don't have that many people here any more....IOSG::PYEGraham - ALL-IN-1 Sorcerer's ApprenticeTue Jan 21 1997 14:439
2473.3IOSG::MAURICEBack in the eggTue Jan 21 1997 14:5719
2473.4AIMTEC::ZANIEWSKI_DTaking bids on Andrew's Alphatraz cellTue Jan 21 1997 18:139
2473.5It can't check for bizarre things or it would take daysSHRMSG::HOWARDBenWed Jan 22 1997 15:2713
2473.6Entered?RTOMS::ADAMSONC[email protected]Thu Jan 23 1997 12:026
2473.7One of life's mysteriesSHRMSG::HOWARDBenMon Jan 27 1997 16:0312
>Had the file been ENTER'ed? i.e. SET FILE/ENTER?
    
    Presumably, but by whom?  I can't see anyone with privileges picking on
    a mail file to practice this command.  Most people never use SET
    FILE/ENTER since it is so dangerous.  I have only used it when fixing
    VMS$COMMON.DIR and with dump files.
    
    In our case, it had been going on for quite a while before I found it,
    so it would have been useless to ask.  It is the only one I have ever
    found like it.  
    
    Ben
2473.8IOSG::CHAPLINAndy ChaplinThu Jan 30 1997 16:4541
    Hi Jean,
    
    I think I can explain what happened.
    
    When TRM is in phase 3, before it deletes an SDAF record which has a
    zero usage-count it checks to see if the record has any attachments. 
    It keeps a list of these attachments, since their usage counts will
    need to decremented accordingly.
    
    When TRM has finished its initial pass through the SDAFs (in this case
    it just did SDAF C), it then has to go back and repair the usage counts
    of attachments which it corrupted by deleting records with zero usage
    counts.
    
    These attachments may be in any SDAF -- not just SDAF C -- so TRM will
    process *all* the SDAFs.  (And it may have to repeat the loop if any of
    the attachments' usage counts go to zero).
    
    So this is why TRM went back and cycled through all the SDAFs after
    completing SDAF C.
    
    As to the SMLOG3 log file being truncated: when TRM writes messages to
    the log file the messages get buffered and are written to the log file
    in chunks.  It looks as though the last few messages from procesing
    SDAF C were waiting to be written to the file whilr TRM was doing the
    attachment corrections.  But because the process was killed before it
    completed these messages never got written to the log file.
    
    (smlog4.tmp and smlog5.tmp will have been empty because TRM never got
    as far as writing to them.)
    
    So, in summary I think TRM was behaving as expected.  It's just taking
    a long time to complete phase 3, but that's due to the size of the
    system.
    
    If you were to run it again, then it should complete a little quicker
    since the zero usage count records have now been deleted from SDAF C. 
    But if/when you repair the other SDAFs you will probably see the same
    behaviour -- you'll just have to give it enough time to complete.
    
    Andy