It is possible to define links to several SNADS nodes from PMDF. This may improve the efficiency of the SNADS side of your mail network. It may also be suitable if your SNADS network is not particularly hierarchical or if there is no natural main hub SNADS node to place adjacent to the PMDF-XGS transport bridge; in such a case it may be more natural to have a number of nodes directly adjacent to the PMDF-XGS transport bridge, and to let those nodes have their own direct connection to the PMDF-XGS transport bridge and through it, to the PMDF system itself.
Each SNADS link will need a separate PMDF channel associated with it, snads_snadsnodename. The snadsnodename part of the channel name is quite significant here; this (lower case) string will be converted to upper case and used as the CPI-C Symbolic Destination Name to reach the specified SNADS node. For mail arriving from SNADS nodes, PMDF will look at the partner LU alias for the node from which the message is arriving and process the message with the correspondingly named channel. (Indeed, this is true for the snads_local channel as well, which is why the Symbolic Destination Name for that channel must be LOCAL.) The snads_local channel is used for messages arriving from SNADS nodes which haven't been defined, or from nodes whose alias does not start with an alphabetic character.
42.8.1 Configuring the additional adjacent SNADS nodes
Each additional SNADS node which is to have its own channel to PMDF
must have its routing information updated so that it routes
distributions directly to the OS/2 transport bridge. For each
additional DISOSS node, see Section 42.6.1.2 ; for each additional AS/400
node, see Section 42.6.2.2 .
42.8.2 Adding additional definitions and servers on the PMDF-XGS transport bridge
To use multiple channels, the PMDF-XGS transport bridge Communications
Manager configuration and xgs.cmd must be modified.
42.8.2.1 Adding additional definitions on the PMDF-XGS transport bridge
You must edit the Communications Manager configuration to define the
additional partner LU's as symbolic destinations.
42.8.2.2 Adding additional servers on the PMDF-XGS transport bridge
The startup procedure on the PMDF-XGS transport bridge will need to
start up additional send processes on additional ports; e.g.,
the xgs.cmd file should have the format shown in
Figure 42-15 on NT, or the format shown in Figure 42-16 on OS/2.
Figure 42-15 Format of thexgs.cmdfile for multiple
send processes on NT
start sendsrv bridgeport1 [loghost1] start sendsrv bridgeport2 [loghost2] start sendsrv bridgeport3 [loghost3] ... start recvsrv PMDFhost dispatcherport bridgeREN size [loghost]
Figure 42-16 Format of thexgs.cmdfile for multiple
send processes on OS/2
start xcontrol start sendsrv bridgeport1 [loghost1] [SNMPport] [senddirectory1] start sendsrv bridgeport2 [loghost2] [SNMPport] [senddirectory2] start sendsrv bridgeport3 [loghost3] [SNMPport] [senddirectory3] ... start recvsrv PMDFhost dispatcherport bridgeREN size [loghost] [SNMPport] [recvdirectory]
sendport1, sendport2,
sendport3, etc., are distinct port
numbers corresponding to the port numbers that the snads_ channels'
option files specify, where senddirectory1,
senddirectory2,
senddirectory3, etc., are a capture
directory or directories on the PMDF-XGS transport bridge to which
copies of messages from PMDF to SNADS will be written, where
PMDFhost is the TCP/IP name of the PMDF system
where dispatcherport is the port that the
snads_slave server on the PMDF system is configured to
listen on in the dispatcher.cnf file, where
bridgeREN is the TCP/IP name of the PMDF-XGS
transport bridge, and where size is the maximum
size of SNADS distributions accepted, and where
recvdirectory is the capture directory to which
copies of messages from SNADS to PMDF are written.
Note that no additional xcontrol or recvsrv
processes are needed. However, for performance reasons, you may wish to
enable several additional recvsrv servers to enable the
PMDF-XGS transport bridge to have multiple connections open to the PMDF
system at the same time, thereby allowing more throughput. Note that
such additional recvsrv servers would all use the same
PMDF Service Dispatcher port number.
These new SNADS send servers on the PMDF-XGS transport bridge know the proper SNADS destination from the name of the snads_snadsnodename channel which connects to their port; they use the snadsnodename of the channel which connects to their port as the Symbolic Destination Name.
42.8.3 Adding additional channels to the PMDF configuration
You will need to add additional channels and corresponding rewrite
rules to your PMDF configuration file, and create corresponding
additional option files.
42.8.3.1 Adding the channel definitions and rewrite rules
The additional channel definitions should be along the lines of:
snads_snadsnode1 defragment 733 header_733 maxheaderaddrs 1 addrsperfile 256 \ charset7 US-ASCII charset8 ISO-8859-1 snadsnode1.yourdomain SNADS-name-for-PMDF-system snads_snadsnode2 defragment 733 header_733 maxheaderaddrs 1 addrsperfile 256 \ charset7 US-ASCII charset8 ISO-8859-1 snadsnode2.yourdomain SNADS-name-for-PMDF-system ...where
snadsnode1.yourdomain is the pseudodomain
name associated with snadsnode1, i.e.,
the name by which that SNADS node is known from the PMDF side, and
where SNADS-name-for-PMDF-system is the name by
which the PMDF system is known from the SNADS side. And the additional
channels should have corresponding rewrite rules:
snadsnode1 $U%snadsnode1.yourdomain snadsnode1.yourdomain $U@snadsnode1.yourdomain snadsnode2 $U%snadsnode2.yourdomain snadsnode2.yourdomain $U@snadsnode2.yourdomainand to handle the SNADS side's short form names for the PMDF system and any other explicitly addressable systems, additional rewrite rules:
PMDFnode $U%PMDFdomainname$Msnads_snadsnode1 othernodeonPMDFside1 $U%otherdomain1$Msnads_snadsnode1 othernodeonPMDFside2 $U%otherdomain2$Msnads_snadsnode1 ... PMDFnode $U%PMDFdomainname$Msnads_snadsnode2 othernodeonPMDFside1 $U%otherdomain1$Msnads_snadsnode2 othernodeonPMDFside2 $U%otherdomain2$Msnads_snadsnode2 ...
42.8.3.2 Additional channel option files
Each new channel must have its own corresponding option file. See
Section 42.6.4.2 .
42.8.4 Example configuration with multiple snads_ channels
Thus if the connection to APPLE is channel snads_local, the connections
to BANANA and CHERRY might be defined as channels snads_banana and
snads_cherry. The important point to remember about the SNADS channel
names is that for a channel snads_snadsnodename, the
snadsnodename is converted to upper case, and is used as the
CPI-C symbolic destination name to reach that node. Mail arriving from
the SNADS nodes is associated with the apropriate channel by the
partner LU alias from which the mail arrived. This means that the
partner LU alias for node BANANA must be BANANA because the channel
name is snads_banana. This was just as important for the snads_local
channel, which is why the symbolic destination had to be LOCAL, but for
mail arriving from SNADS, the snads_local channel is also used for mail
coming from nodes which haven't been defined. Any mail arriving from a
node which have an alias which does not start with an alphabetic
character will be processed through the snads_local channel.