[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

583.0. "FLUSHUSER / Reset Unread Count" by UTRTSC::BOSMAN (We're just sugar mice in the rain) Tue Apr 28 1992 11:20

    Hi,
    
    I've a question about the image FLUSHUSER. It will reset the unread
    usage count of the user (or at least this is what happens if you run
    this image through the RUC option).
    
    Why is the unread count set to zero, and not to the value of correct
    unread messages? A customer does have problems after a disk crash with
    the shared areas on it. After running TRM everthing except for the
    unread count was correct. Now it takes a lot of hand-work to correct
    it (inform users to read all posible unread messages and not send new
    message and RUC for each user or RUC from a little script).
    
    He has an ALL-IN-1 V2.3 system. Is TRM and/or FLUSHUSER in ALL-IN-1
    V3.0 improved to *correct* (not reset) the unread count?
    
    Thanks in advance, Sjaak.
T.RTitleUserPersonal
Name		DateLines
583.1FlushUser hasn't changed, but . . .TRON::SHOVEDave Shove -- REO-D/3CTue Apr 28 1992 15:4315
    There is now a user function MAIL RESET_MAILCOUNT, which can be called
    by the user to correct their unread count. It's quite slow (as it has
    to search the filecab for unread/noted messages), so you wouldn't want
    to call it too often. However, you could either -
    
    	provide a menu option so users can call it themselves
    
    or
    
    	write a batch job which went round all the users and did it for
    	them
    
    This might be easier than what you're doing now.
    
    Dave.
583.2I'm not doing anything yetUTRTSC::BOSMANWe're just sugar mice in the rainTue Apr 28 1992 16:2415
�    	write a batch job which went round all the users and did it for
�    	them
�    
�    This might be easier than what you're doing now.
    
    The problem is that the unread count will *ALWAYS* be set to *ZERO*,
    and not the the actual count of unread messages. I mean, if there were
    5 unread messages before the crash, 3 at the day the crash occurs then
    after the restore you'll have an unread count of 8 whilst it should be
    5. RUC will set the unread count to 0.
    
    As I understand (but I'm not sure) FLUSHUSER only removes the record
    from PENDING.DAT.
    
    Sjaak.
583.3Mail Reset gets it right (in v3.0)IOSG::SHOVEDave Shove -- REO-D/3CWed Apr 29 1992 12:469
    Yes, FlushUser just deletes the record(s) from Pending.
    
    MAIL RESET actually counts the number of unread/noted messages, and the
    number of pointers in the Pending record, and adds them all together.
    So it does get the correct answer. However, as it has to scan the whole
    fielcab (sequentially - mail_status not being a key field) it does take
    a while.
    
    Dave.