| Previous | Next | Contents | Index |
It is possible to define links to several SNADS nodes from PMDF. This can improve the efficiency of the SNADS side of your mail network. It can 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 can 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.
4.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 4.6.1.2; for each additional AS/400
node, see Section 4.6.2.2.
4.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.
4.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.
4.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 4-15 on NT, or the format shown in Figure 4-16 on OS/2.
Figure 4-15 Format of the xgs.cmd File 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 4-16 Format of the xgs.cmd File 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 can want 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.
4.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.
4.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 ... |
snadsnode1.yourdomain is the pseudo domain
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.yourdomain |
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 ... |
4.8.3.2 Additional Channel Option Files
Each new channel must have its own corresponding option file. See
Section 4.6.4.2.
4.8.4 Example Configuration with Multiple snads_ Channels
If the connection to BLUE is channel
snads_local, the connections to AZULE and
INDIGO might be defined as channels
snads_azule and snads_indigo. The important
point to remember about the <SNADS\smallcaps) channel names is that
for a channel snads_snadsnodename, the
snadsnodename is converted to uppercase, and is used as
the CPI-C symbolic destination name to reach that node. Mail arriving
from the SNADS nodes is associated with the appropriate
channel by the partner LU alias from which the mail arrived. This means
that the partner LU alias for node AZULE must be
azule because the channel name is snads_azule.
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.
| Previous | Next | Contents | Index |