Conference iosg::all-in-1

    Probably better for Dave Lennig to answer this, but meanwhile, what
    sort of DECnet are you using - Phase IV or V I think that might affect
    the answer.

    HI Graham,
    
    I thought of Dave Lennig as well but he is on vacation this week. I
    sent him mail. The customer is running with DECNET Phase IV. 
    
    The Message Router configuration guide recommends that you use a
    cluster alias but does not require it. ALL-IN-1 documentation is
    unclear. It says to use either but we cannot seem to get it to work
    without one. Could just be operator error :-).
    
    But for the sake of what we tell customers, I wanted to know once and 
    for all what is required.
    
    Thanks, 
    
    Cheryl

    Hi Graham,
    
    I talked to Dave and he confirmed my thoughts. You do not have to have
    a cluster alias to run Message Router and DDS even if you are accessing
    them remotely.
    
    What is the requirement for using remote Message Router and DDS if one
    node is an ALPHA and the other is a VAX? There is some confusion on the
    settings in a1config. What is the setting for the Remote MR field? 
    I understand that you run dds$startup and pass the DDS node name and 
    systemid number. If I do not have to have a cluster alias this
    will make my customer very happy.
    
    Cheryl
    

    Sort of on vacation :-)
    
    Cheryl called me; I'll reiterate what I told her.
    
    As of V3.3 we do not require a cluster alias for DDS any more.
    
    However we do require that a Messager Router 'instance', whether it be
    a single node or a cluster, be known to the rest of the MR network by
    a single nodename. (You'll see the term "primary MR node" in the docs).
    What this means is that if you choose not to have (or tell MR not to 
    use) an alias, the 'primary MR node' will be the source and destination 
    for all MR related network traffic for the cluster.
    
    This model fits quite nicely for a number of cluster configs; for
    example LAVC's with a single boot node and some number of satellites
    (run full MR on the boot node, avoid the overhead on the satellites; 
    see MB$CONTROL MINSTART option) or a mixed architecture cluster. 
    
    The key element is that applications running in this environment be 
    well-behaved; for example if XXX is running on a non-primary node and
    creates a mail message, it needs to put the correct return address in
    the From field in the content (the envelope isn't as much of an issue
    since MR manages it). The node term needs to be the name of the primary 
    MR node, not the name of the node XXX is running on. Similarly XXX
    needs to put the correct nodename in DDS entries it creates/manages.
    
    Some applications don't have this flexability; for example, MRX, MRP,
    and MRS all have to run on the 'primary MR node'. Some applications do;
    ALL-IN-1 has supported using a remote MR Transfer Service (not DDS)
    for a long time; ie it has support for putting something other than its
    local nodename into mail addresses. And as of V3.1 (and MR V3.3) there
    is also support for remote DDS access (albeit read-only, for security
    reasons, which ALL-IN-1 gets around by using the script symbiont in a
    mixed arch cluster to execute add/mod/del ops on the VAX/MR member).
    
    However I believe ALL-IN-1 imposes some constraints in these cases. If
    ALL-IN-1 is running on more than one node of a cluster, I think they
    require the use of a cluster alias; for example, they include a node
    term in the name of the UA object in DDS. Graham, you can jump in here...
    
    Dave

    <<<< However I believe ALL-IN-1 imposes some constraints in these
    <<<< cases. If ALL-IN-1 is running on more than one node of a cluster,
    <<<< I think they require the use of a cluster alias; for example, they
    <<<< include a node term in the name of the UA object in DDS. Graham,
    <<<< you can jump in here...
    
    Splash :-)
    
    We've always had the logical name OA$PRIMARY_NODE which is used to
    create return addresses and stuff like that (I think it's used for the
    DDS ibject Dave mentions) but you have to be careful that it gets
    defined correctly in the absence of a cluster alias. Correctly means it
    needs to be the same thing on all nodes, or confusing things happen. By
    default A1V3nSTART defines it to the alias or current node, so things
    can get complicated in a cluster without an alias.
    
    In V3.2 I tightened all this up (mostly because we needed one node for
    sure with MAILbus 400) and I added a new field to A1CONFIG to hold the
    node that is acting the part of the cluster alias.
    
    Graham
    

In a two-node cluster, one Alpha, one VAX, no cluster alias, with MR running on
the VAX and ALL-IN-1 running on both nodes, then:

- OA$PRIMARY_NODE should be the name of the VAX node.
- the A1CONFIG field 'Remote MR' should be NO.

I'm sure this is all spelt out in the docs?

Scott