Conference iosg::all-in-1_v30

    Hello Hong,
    
    This looks like "normal" behaviour on a system with DDS prime set
    and a UA with empty MHS fields. <GET OA$DDS_AREA_ROUTE to check this.
    
    Could it be that for some reason the user agent entry in DDS is
    changed  ? Mailbus version 3.2 shows the Update Time of entries 
    in MBMAN. 
    
    Regards,
    
    Jan

    Jan
    
    Thanks for the info but the UA OA$MEL$ALLIN1 was never in operation
    since the system involved hasn't made use of DDS despite of the
    readiness shown with OA$DDS_PRIME value.
    
    I did look in MBMAN and the update time of UA was several months old
    and its MHS fields were indeed non-existent; one more confusing thing
    to me was its DDSID was there but not mapped by form UAPASSWRD.
    
    Also, in what context can I get the value of OA$DDS_AREA_ROUTE ?
    
    Thanks for further comments
    
    Hong
        

    Hong,
    
>    Thanks for the info but the UA OA$MEL$ALLIN1 was never in operation
>    since the system involved hasn't made use of DDS despite of the
>    readiness shown with OA$DDS_PRIME value.
    
    So how did OA$MEL$ALLIN1 get there ? 
    
>    I did look in MBMAN and the update time of UA was several months old
>    and its MHS fields were indeed non-existent; one more confusing thing
>    to me was its DDSID was there but not mapped by form UAPASSWRD.
    
    Looks like OA$LIB:USERAGENT_POST.SCP never ran. 
    
>    Also, in what context can I get the value of OA$DDS_AREA_ROUTE ?
    
    Within the Choice Field in ALL-IN-1 type <get OA$DDS_AREA_ROUTE .
    
>   Thanks for further comments 
    
    Could it be that the problems users are created with MDFLAG set
    to Y ? 
    
    Regards,
    
    Jan
    
            

    

Jan

>    So how did OA$MEL$ALLIN1 get there ? 

My guess would be discontinued use of DDS happened at some stage and its UA 
record was partially/incompletely cleaned up; hence until recently, UA 
definition didn't contain MHS fields
    
>    Looks like OA$LIB:USERAGENT_POST.SCP never ran. 
 
Yes, probably since 3.0 upgrade. In fact, running this script did fix current 
problem. The major problem faced by this site was its incorrect use of Mail 
Directory level when it's not set up the UA properly.

One more query: was the sender's network address NOT built from UA definition 
as were addressees in TO and CC lists (see sample on the base note) ?

>    Within the Choice Field in ALL-IN-1 type <get OA$DDS_AREA_ROUTE 

It slipped my mind in last query about the meaning of this symbol. This site 
didn't run area routing; as a result, the return value of null string prompted 
me asking this question.

>    Could it be that the problems users are created with MDFLAG set
>    to Y ? 

No, this flag has been set to N to date


Again, many thanks

Hong

    Hong,
    
>One more query: was the sender's network address NOT built from UA definition 
>as were addressees in TO and CC lists (see sample on the base note) ?

    Normally the senders address is built from UA . To TO and
    CC addresses are extracted from their Subscriber entry.
    
>>    Within the Choice Field in ALL-IN-1 type <get OA$DDS_AREA_ROUTE 
>
>It slipped my mind in last query about the meaning of this symbol. This site 
>didn't run area routing; as a result, the return value of null string prompted 
>me asking this question.
    
    OA$DDS_AREA_ROUTE is not related to area routing . 
    Contains the UA info. 
    
    Example 
    
    get OA$DDS_AREA_ROUTE result in @A1@SSOIOS for UA:
    
            Name                            : OA$SSOIOS$ALLIN1
            Master copy owning node         : SSOIOS
            MHS/VMS address number          : 1
                    MHS/VMS address part    : SSOIOS
                    MHS mailbox             : A1
                    MHS User identifier     : MANAGER
            Access Time                     :  4-MAY-1992 18:45:37.75
    
    
    

    
    

Jan

>    Normally the senders address is built from UA . To TO and
>    CC addresses are extracted from their Subscriber entry.

Something was amiss here. I first noticed UA wasn't having any MHS definitions
on their cluster MEL and yet the EM was seen on cluster CBR as follows:

                  I N T E R O F F I C E   M E M O R A N D U M

                                        Date Sent:22-Mar-1993 12:49pm
                                        From:     System Manager
                                                  MANAGER@A1@MEL
                                        Dept:     CORPORATE SERVICES
					Tel No:

TO:  Gari Williams                        ( WILLIAMS GARI @ A1 @ CBR )
TO:  felix thecat                         ( FELIXPAPER MAIL )
TO:  PETER HANSEN (03) 604 8705           ( HANSEN PETERPAPER MAIL )

where MANAGER, FELIX and HANSEN PETER are MEL users

Also, there has been no subscribers on DDS on cluster MEL.

Later USERAGENT_POST script did put in a complete UA record and form UAPASSWRD 
was mapped with correct info. It's only then the re-sending of the above msg 
resulted in the correct display of the last 2 addressees on TO field.

So does the mystery remain...

>    OA$DDS_AREA_ROUTE is not related to area routing . 
>    Contains the UA info. 
>    Example 
>    
>    get OA$DDS_AREA_ROUTE result in @A1@SSOIOS for UA:

I never got anything but null strings in 2 systems I tried, which therefore 
made me think of its being area routing. 

Do you have to invoke something else before GETting this symbol ?

Also, you can afford a show-off now ! Any comments on other OA$DDS symbols 
defined in OAGBL but not seemingly used anywhere: OA$DDS_NODE_TYPE, 
and OA$DDS_SYSTEM_NODE_NUM, OA$DDS_SEARCH_SCOPE. What does the last symbol do, 
I won't like to guess esp. having been fooled by the naming last time.

Thanks

Hong

    Good morning,
    
>TO:  PETER HANSEN (03) 604 8705           ( HANSEN PETERPAPER MAIL )
>Also, there has been no subscribers on DDS on cluster MEL.
>So does the mystery remain...
    
    For me to. If I am correct, a subscriber with no reversed lookup would
    have resulted in  ( PAPER MAIL ) ... 

>Do you have to invoke something else before GETting this symbol ?
    
    The EM subsystem.

>Also, you can afford a show-off now ! Any comments on other OA$DDS symbols 
>defined in OAGBL but not seemingly used anywhere: OA$DDS_NODE_TYPE, 
>and OA$DDS_SYSTEM_NODE_NUM, OA$DDS_SEARCH_SCOPE. What does the last symbol do, 
>I won't like to guess esp. having been fooled by the naming last time.
    
    OA$DDS_NODE_TYPE and OA$DDS_SEARCH_SCOPE are well explained in Table
    A-2 of the Mail Management Guide.
    
    OA$DDS_SYSTEM_NODE_NUM ?!? I am afraid we will have to wait
    untill the real expert awakes. He will start typing when
    am I enjoying the victory of out national foootball team.
    
    Lets wait for the answers.
    
    Regards,
    
    Jan
    

    jan,
    
    Real expert - never sleeps!! Hopefully Holland can get at least a point
    off San Marino - we don't want england qualifying do we?
    
    Anyway i'll take the blame for OA$DDS_AREA_ROUTE and
    OA$DDS_SEARCH_SCOPE - I'm not sure the description of either is
    accurate in the MMG but from memory.
    
    OA$DDS_AREA_ROUTE is defined as
    @OA$MTI_MAILBX@OA$PRIMARY_NODE@<area-route> last bit optional
    it is used as the FROM field (and hence return address) on all off-node
    mail on systems where the logical OA$DDS_PRIME is set to a noin-zero
    value
    
    [yes I know GASH keeps putting in notes talking about using OA$MTI_AREA
     and OA$PRIMARY_NODE but he's confused - heck he thinks the divison
     1 that Newcastle are top of is the real division one]
    
    OA$DDS_SEARCH_SCOPE has 3 values
    0 do a local search
    1 do a world search
    2 do an escalated search
    the last one I think is undocumented - as it doesn't actually work
    unless you do DEPOSITs whilst in the BLISS debugger. note it is
    not the same escalated search as the one implemented in ALL-IN-1
    v3.0 using DDS breakpoints and all that stuff. (a long story)
    
    OA$DDS_NODE_TYPE is all Vid's fault but I think it's defined as
    0 local node
    1 world node
    
    OA$DDS_SYSTEM_NODE_NUM doesn't really exist outside of Vid's comment
    (do a search of OAGBL yourself) - as I took out after he left 
    ha ha ha
    
    regards,
    
    Andrew.D.Wicks

Andrew

>    OA$DDS_AREA_ROUTE is defined as
>    @OA$MTI_MAILBX@OA$PRIMARY_NODE@<area-route> last bit optional
>    it is used as the FROM field (and hence return address) on all off-node
>    mail on systems where the logical OA$DDS_PRIME is set to a noin-zero
>    value

This seems to be consistent with what's been observed in this case: FROM field 
always had correct network address, but not TO and CC fields until a DDS UA 
has been properly set up.

Are the latter getting their addresses from MHS fields from UA, rather than 
corresponding DDS subs, as suggested by Jan in previous note ?

Thanks

Hong

    Hong,
    
    I'm stealing all my information from a seminar given in April 1989
    in sunny Valbonne in the South of France. Some though not all of the
    information made it into the MMG, a little more exists in Sir David
    Hare's excellent book "DDS the inside story - including the trip
    to Monte Carlo!" the rest exists only in those slides.
    
    Everything is driven from the UA entry.
    USERAGENT_POST builds the MHS bits and it is this that
    OA$DDS_AREA_ROUTE is read from
    SUBSCRIBER_ADD you'll notice also reads from the UA entry when building
    the MHS bits for the SUBSCRIBERS.
    
    So the key is to make sure the UA entry is right.
    
    
    BTW: I still have the slides so I could always do this presentation in
         Australia and Holland on my way back to the U.K???
    
    Regards,
    
    Andrew.D.Wicks