Conference iosg::all-in-1_v30

    
    	I've seen this a couple of times before. One time the profile
    	had some bogus records which caused some new mail to be put in
    	PENDING.DAT with the wrong key, so if you do GET_PENDING it
    	doesn't find your mail. The other was a filecab server problem
    	(hardly a problem on your V2.4 system, but it might give you some
    	ideas) which delivered the mail to a blank foldername instead of
    	INBOX. Both were system setup problems, not IOS bugs in the cases
    	I saw (not wishing to alarm anyone!)
    
    	Looking at your nodename, could it be something to do with the
    	translation of the INBOX into a local language?
    
    Regards,
    Paul

It appears that this particular problem was caused by the user himself issuing
RFD commands BEFORE he actually read the messages. Previous versions of
ALL-IN-1 did NOT let him do this.

Thanks,

Cb.

    
    	SO actually the mailcount was right, it reflected the number
    	of unread messages in his FC? RFD won't let you refile UNREAD
    	across drawers.
    
    Regards,
    Paul

>
>    
>        SO actually the mailcount was right, it reflected the number
>        of unread messages in his FC? 



Yes and No! Reading these messages from the new folder does NOT decrement the
mailcount (V2.4). After reading any messages in INBOX issuing either RN or II
returns "No messages ..." 

>        RFD won't let you refile UNREAD
>        across drawers.
>    

In V3.0 you cannot RFD an UNREAD message across drawers, but you can RFD them
across folders. Also, in V3.0 reading the RFD'd message does decrement the
unread mailcount. SO your true mailcount is always correct.


Thanks,

Cb.

I want to correct my last reply. 

Reading the RFD'd message does indeed decrement the mailcount. However, neither
RN or II will pick them up. 

So what was happening was that the users would issue II. Then they would RFD
some of the messages to another folder. Then they would deplete the INBOX, but
the mailcount would still be > 0. Issuing RN or II wouldn't pick up these
messages, and since the user has forgotten that he RFD'd them, he mistakenly
thinks that the count is wrong.

Thanks,

Cb.

    
    	Thanks for the clarification. I wanted to see if we had a bug
    	here. The behaviour you describe, whilst possibly confusing, is
    	the way it is supposed to work.
    
    Regards,
    Paul

Paul,

>    
>        Thanks for the clarification. I wanted to see if we had a bug
>        here. The behaviour you describe, whilst possibly confusing, is
>        the way it is supposed to work.
>    

I tend to agree, although the user claims (and I have no way of verfiying this)
that in the previous version of ALL-IN-1 RFD would NOT let him refile an UNREAD
document (much like V3.0 between drawers).

Perhaps, though, it would be more user friendly if RN and II would pick up any
UNREAD messages irregardless of the folder in which they are currently stored.

Thanks,

Cb.

>         <<< Note 3530.7 by TAV02::CHAIM "Semper ubi Sub ubi ....." >>>
>                              -< Wish list .... >-

>I tend to agree, although the user claims (and I have no way of verfiying this)
>that in the previous version of ALL-IN-1 RFD would NOT let him refile an UNREAD
>document (much like V3.0 between drawers).

No, RFD has always worked on Unread messages in the Inbox.

It would be unrealistic to expect RN to find all Unread messages - it would 
have to search the entire drawer sequentially. However, users can use the 
Index form, and select Status = UNREAD to find all of their Unread messages, 
wherever they've hidden them.

g