Conference iosg::all-in-1_v30

Just tried that on our V2.4  system, and the status field shows UNSEEN, so I
have a feeling that the customer is doing something wrong in its customizations.
The OA$_NOTE_UNSEEN has nothing to do with it, its nothing more than a 
special symbol that holds the value 'UNSEEN', it has no relation what
so ever with the current note.

	Ben

    Thanks for your reply Ben.
    
    Unfortunately, I get SEEN on all my unseen notes going in on
    ALLIN1/nocustom.  As I said IU works correctly in that all the 
    notes listed are unseen, however Gold V does show them all in
    the Seen Status field as SEEN.
    
    Are you saying that ALL of yours are unseen?  Can someone else
    try this to, as the customer gets the same results as me going
    in /nocustom.
    
    Thanks
    julia

    re: .2
    
    I think what Ben was saying is that the message symbol is very unlikely
    to be the culprit (unless the customer has changed the message file).
    
    If they are getting incorrect results then it is more likely to be the
    SEEN field in the data set.  Since I am the one who implemented that
    data set I can confirm that this is not too unlikely since the field does
    not work well when users have a large and fragmented seen map.  The
    structure of the seen map is complex and undocumented and it is quite
    possible that it is not always parsed correctly.
    
    If you can isolate the problem to that then I would encourage you to
    submit an SPR so that the problem can be addressed in the future.
    
    John

Julia,

do the following:

IU (Index Unseen)
GOLD F (makes the top one current in the GPC menu)
<GET OA$N$NOTE.SEEN[OA$NOTES_NOTE_IUD]

what is the result?

	Ben

    Hi Ben
    
    If I do a IU of a conference with a relatively small number of unseen
    notes (following .3's theory), I get the following results:
    
    Gold V - Seen Status UNSEEN
    <GET OAN$NOTE.SEEN[OA$NOTES_NOTE_ID] on note where cursor is pointing
    gives N
    Gold F <GET OAN$NOTE.SEEN[OA$NOTES_NOTE_ID] gives N  
    
    IU on a conference with a large unseen map produces:
    
    Gold V - Seen Status SEEN
    <GET OAN$NOTE.SEEN[OA$NOTES_NOTE_ID] on note where cursor is
    pointing gives Y
    Gold F <GET OAN$NOTE.SEEN[OA$NOTE_NOTE_ID] gives Y
     
    So that does tie in with what .3 was saying with regards to a 
    large number of unseen notes.
    
    julia

    Just to clarify one possible point of confusion:
    
    It is the size of the unseen map and not the number of unseen notes
    which is critical.  These are not as correlated as you might think
    since the unseen map is essentially a set of note ranges.  So, for
    example if you do the equivalent of a SET SEEN or SET SEEN/BEFORE you
    will have a very small seen map (1+2*4=9 bytes) even though you may have
    set a million notes seen.
    
    With the normal usage of notes the number of seen note ranges will be
    small and you should not run into a problem until the size of the seen
    map can no longer be held in a byte which should be about 128 note
    ranges.  After that I honestly don't know what happens but I can not
    imagine that it works.
    
    Typically people to not randomly set notes seen so the number of ranges
    is limited and VAX Notes is smart enough to merge note ranges when
    appropriate so the seen map is always reduced to a minimum.  However
    with Group Conferencing you can run into the problem since people may
    make heavy use of the indexes and multiple options to set random (in
    terms of note UID) notes seen either explicitly or implicitly by
    reading the notes.
    
    In any case this is my explanation of the problem.  I haven't verified
    anything so I may be wrong but I did spend a long time a few years ago
    trying to implement this field of the data set and that is how I
    remember it.
    
    John