Conference iosg::all-in-1_v30

    I can't reproduce this sorry - I created two account
    
    ABB
    and 
    ABC 
    
    Did a gold L and got both of them.
                     
    Winton (ALL-IN-1 V3.0)

    The problem seems to be slightly different from what he first said:
    
    Assuming you have two users in NETWORK.DAT, JOSM and JOSI. JOSM is
    on your own node, and JOSI on another node. Then when doing SM MM
    MAD SEL and type JO and Find, you get both. But when doing EM C and
    type JO Find, you only get JOSI from the remote node, not JOSM 
    from your own.  ALLIN1/NOCUSTOM gives same result.
    
    Anyone care to test this?
    
    Hans

>    Assuming you have two users in NETWORK.DAT, JOSM and JOSI. JOSM is
>    on your own node, and JOSI on another node. Then when doing SM MM
>    MAD SEL and type JO and Find, you get both. But when doing EM C and
    
    I think this is intended behaviour. ALL-IN-1 does not display
    NETWORK.DAT entries from local users. An entry is local when
    the NODE field equals OA$PRIMARY_NODE...
    
    When you create an entry in NETWORK.DAT ALL-IN-1 is a little
    inconsistant. SYS$NODE logical is used by default instead of 
    OA$PRIMARY_NODE...
    
    Hope this helps,
    
    Jan

    Thanks Jan,
    
    It seems this customer can't get what he really wants:
    
    The users should be able to find any other user directly from
    EP C To: whether they enter part of surname (via DDS) or part
    of ALL-IN-1 username (via NETWORK.DAT).
    
    With OA$DDS_PRIME set to 1 the users had to use Gold M to search
    DDS database, so he thought that with OA$DDS_PRIME = 2 you could
    avoid using Gold M. But what you say is that in this case you miss
    out on the local node ALL-IN-1 usernames, and still have to do
    Gold M to find those. Correct?
    
    Hans
    

First, the "inconsistency" noted in .3 is known about and "may be considered
for a PFR", to use the official jargon.

Next, yes everything is working as intended, the reasoning being this:

If you aren't using DDS, then ALL-IN-1 searches the profile, followed by
NETWORK.DAT (plus other stuff irrelevant to this discussion).  As local users
are stored in NETWORK (so that other nodes can pick them up as remote addressees
via the UA housekeeping job) as well as Profile, you'd see all local users
twice if you did a FIND for mail addresses.

Obviously this isn't very good, so the searching code ignores all local users
in NETWORK, based on the NODE field as already described.

If you *are* using DDS, setting OA$DDS_PRIME to 2 tells ALL-IN-1 that you want
to use DDS, in preference to the ALL-IN-1 profile, to find local users.  The
profile isn't searched, and local entries are excluded from NETWORK in the same
way as above.  Thus the customer is wrong to put local users into NETWORK, and
expect them to be found "automatically".  They should put these users into DDS,
as that is where they've told ALL-IN-1 to look for them!

What your customer wants is to search DDS *and* the ALL-IN-1 files automatically
for local users, a combination not supported.  If we were to provide this, we'd
get a lot of customers complaining about NETWORK records showing up as
duplicates of entries already found in DDS.

Scott

    Hans,
    
    I think you are getting a little confused with the difference between
    OA$DDS_PRIME set to 1 and set to 2. You have to remember what the key
    field is:
    1) For PROFILE it is the ALL-IN-1 username
    2) for NETWORK it is the ALL-IN-1 username *AND* the Node name.
    3) for DDS it is "assumed to be" the surname.
    
    So with OA$DDS_PRIME set to 1 you are searching the Profile looking
    for a username match and you have to use GOLD M to access databases
    that that support a surname match i.e DDS.
    
    With OA$DDS_PRIME set to 2 you are searching DDS loking for a surname
    match and you have to use GOLD M to access databases that support a
    username match i.e Profile
    
    At no time and in no option are all databases searched for a surname
    match (PROFIL.SURNAME1 is never looked at) and at no time and in no
    option are all databases searched for a username match (there is no
    DDS field that is directly accessible that stores and ALL-IN-1 account
    name).
    
    It sounds as if you are looking for one of these functions.
    
    .5 (scott)
    
    The inconsistency noted in .3 was actually a changed inconistency
    from previous ALL-IN-1 releases in that it used to used OA$NODE and
    now it use SYS$NODE - let us hope that it ends up in some release using
    OA$PRIMARY_NODE. 
    
    Your description of how OA$DDS_PRIME set to 2 works is wrong as the
    ALL-IN-1 profile is in fact search to pick up those profiles such as
    X400 which have the MDFLAG set to N. 
    
    It is also perfectly valid for customers to enter addresses into
    NETWORK.DAT on a system where OA$DDS_PRIME set to 2 Entries that point to 
    places on Internet or even other parts of a customers network that do not 
    have DDS running can be stored in NETWORK and both NETWORK and DDS can 
    live together quite happily.
    
    The customers only mistake is to expect all of ALL-IN-1's address
    databases to behave consistently which I think would have been a good
    suggestion for incorporation into a PFR when PFR stood for v2.3 or
    v3.0 but we all know what happened to the Mail code in those releases
    don't we ??
    
    Regards,
    
    Andrew.D.Wicks

	Thanks guys for your comments!
    
    Andy, maybe I am confused, let's see now:
                                              
 >   I think you are getting a little confused with the difference between
 >   OA$DDS_PRIME set to 1 and set to 2. You have to remember what the key
 >   field is:
 >   1) For PROFILE it is the ALL-IN-1 username
 >   2) for NETWORK it is the ALL-IN-1 username *AND* the Node name.
 >   3) for DDS it is "assumed to be" the surname.
   
    Fair enough, that's just as I assumed. 
    
 >   So with OA$DDS_PRIME set to 1 you are searching the Profile looking
 >   for a username match and you have to use GOLD M to access databases
 >   that that support a surname match i.e DDS.
    
    Right, they don't like Gold M.....
    
 >   With OA$DDS_PRIME set to 2 you are searching DDS loking for a surname
 >   match and you have to use GOLD M to access databases that support a
 >   username match i.e Profile
    
    Seems you're omitting NETWORK? The way I've understood it you enter a
    name (of some kind), first DDS is searched for a surname match, then
    NETWORK is searched for a username match (that is not on your local
    node). Then you have to Gold M to search PROFILE.
    
 >   At no time and in no option are all databases searched for a surname
 >   match (PROFIL.SURNAME1 is never looked at) and at no time and in no
 >   option are all databases searched for a username match (there is no
 >   DDS field that is directly accessible that stores and ALL-IN-1 account
 >   name).
    
    I understand that, but the customers rationale is that a user might
    know either a surname or a username, and should be able to find the
    adressee directly from To: without Gold M. He figures all three
    databases, DDS, NETWORK and PROFILE, should be searched, in which
    order is not important. But I think with the reasons given here I
    can explain to him why this is not implemented.
    
    Thanks again,
    Hans