Conference iosg::all-in-1

No, there is nothing wrong with having multiple Senders and Fetchers; this is
standard functionality in ALL-IN-1 V3.2.  As that is the version you have, has
something happened on your system to make you think otherwise?

There is one cluster-wide Sender queue, to which all outgoing messages (except
some sent by local VT users) are added.  All the Senders use this one queue, and
take it in turns to pull messages off the queue.  So the load is shared amongst
all the Senders.

I think the Fetchers take it in turns to fetch messages from the mail backbone
(Message Router or MAILbus 400), so again there is automatic load sharing.

This is probably all described in more detail in the Mail Management Guide.

Scott

    Scott,
    
    The reason for the questions has to do with note 2645 also.
    We have sites that are running ALL-IN-1 on a cluster.  These
    sites also have UCX (or other TCP/IP software) installed.  
    However, UCX or whatever is not running on all nodes of the
    cluster.  TeamLinks users that connect to their IOS accounts
    if connecting via TCP/IP using Windows Sockets do not get 
    their mail notifications.  They connect to one of the nodes
    running TCP/IP.
    
    Now documentation states that for new mail notification to work
    UCX or whatever must be running on all nodes of the cluster.
    If a VT user sends mail to the TeamLinks user they get the
    notification.  It is just if a TeamLinks user sends mail to
    another TeamLinks user.  When sending from TeamLinks to TeamLinks
    the mail is going through the sender if a VT user sends the
    mail it does not.  
    
    I found that the sender was running on the node without TCP/IP.
    If I had the customer start a sender on one of the nodes running
    TCP/IP then mail notification worked.  So the reason for my question
    is if senders are running on the TCP/IP nodes and a sender on a 
    node running TCP/IP processes the mail then notification should
    work.  If a sender on a node not running TCP/IP processes the 
    mail then notification will not occur.
    
    I just need to verify that there is really no way to control
    which sender will process the mail if running multiple senders.
    
    Thanks,
    
    Beth
    

Hi Scott,

I have a couple of questions related to Beth's replies.

Does the Sender and Fetcher use the same mechanism to broadcast new mail 
notification to a TeamLinks client?

As I understand it, one of the customer's issues now is that mail, arriving 
from outside the cluster, does not seem to trigger new mail notification to 
the TeamLinks client.  Am I correct in assuming that only incoming mail 
serviced by a fetcher running on a UCX enabled node will trigger new mail 
notification?  I ask this because UCX is only running on two of the three 
nodes in the cluster.

Thank you for your assistance.

Joe

I have mentioned this note to people more knowledgeable in these areas than me,
but here's an initial answer.

I don't think you can control which Sender or Fetcher processes a particular
message.  It will be random depending on which Sender/Fetcher becomes free when
the message in question is at the top of the queue.

The notification issue I think you've answered yourselves.  The documentation
makes it clear, as Beth observes in .2, that UCX (or equivalent) must be running
on all nodes in a cluster for New Mail Notification to work reliably.  The
reasons for this are obvious: if the service ain't there, we can't use it!

But the customer does not have UCX on all nodes, therefore they can't expect the
notifications to work.  If they want the notifications, it would seem that they
must install UCX on the other node(s).

Scott

    Scott is correct in saying that UCX needs to be running on all nodes
    for notification to work consistantly. There is what I perceive as a
    design flaw here in that while multiple sender and fetchers can now be
    run on a cluster all working on the same cluster-wide queue of
    messages, the PC Broadcast Server only handles messages generated by
    either the Sender/Fetcher or VT Client on each individual node. Hence
    the scenario that Beth pointed out:
    
    If message is processed for a TCP/IP Teamlinks client on a node where
    UCX is not installed, no notification will be generated as the Broadcast
    Server cannot use TCP/IP to connect to the PC. 
    
    There is no method for using a different network transport for the
    delivery of mail and the delivery of notifications. Also there is no
    current method for shunting notifications to a node enabled to send
    messages via particular network transport.
    
    The best we can do in this scenario is to advise that either:
    
    1. Sender/Fetchers and Broadcast Handlers are only run on nodes which
    have all network transports available.
    
    2. That UCX be installed on all nodes but to have incoming connection
    methods disabled on none-active nodes. Effectively this means not
    starting FCS and Aida on these nodes and the various TCP/IP
    services not be started.
    
    I'm not a licensing expert but if this is a cost issue then might this
    be a case where a UCX Client license for the none-active nodes would be
    a cost-effective solution and a full Server license only for the active
    node?
    
    Ian

Re: .1
    
    > There is one cluster-wide Sender queue, to which all outgoing messages 
    >(except some sent by local VT users) 
    
    I could have sworn I saw node$MAIL$QUEUE records for each node in a
    cluster where A1_FIX047031 was applied.
    
    Dan
    

>> node$MAIL$QUEUE records

Where were/are these records?  Are you thinking of the VMS execution queue on
which each Sender runs?  These are node-specific, but all the Senders still
access the same cluster-wide queue of mail messages to process.

Scott

    Hi Dan,
    
    Yes, ICF 47 is different.  Each node has its own Sender queue with its
    own dedicated Sender.  All remote and 2nd class messages sent from the
    VT interface will go to the queue on that node. (Note that the FCS
    wasn't changed, because the customer doesn't use Teamlinks, and it
    continues to use the old queue which has its own dedicated Sender).
    
    I should point out that in Office Server things will be much the same
    as in ICF 47, except that the file cabinet server will also use the
    node specific queues.
    
    Cheers,
    Andy