Using Alternate Communications Paths

Edit online

Use the ALT.COMM parameter to set up alternate communications paths. To see an example of using alternate communications paths in a IBM® Connect:Direct®/Plex environment, see Strategies for Communicating with Non-Plex Servers.

Note the following:

  • The protocol and number of alternate communications paths depend on the capability of the remote node.
  • If you use alternate communications paths, the remote IBM Connect:Direct node must have the capability to support the ALT.COMM parameter and have a defined method of performing network map checking for these alternate paths.
  • If you are using either the SSL or TLS protocol with IBM Connect:Direct Secure Plus, all communications paths must be TCP.
  • Since each ALT.COMM entry varies in size and each ALT.NODE and ALT.ADDR entry is also variable, the number of entries that may be added to a single ADJACENT.NODE varies. The limit will be determined by how many entries fit within a single Netmap record and it may vary from 20 to 30 entries, depending on parameters and values for each entry.

Alternate Communications Paths with Current Node as Primary Node

The adjacent node record defines a communications path. You can use the ALT.COMM parameter in the adjacent node record to define alternate communications paths.

When a Process is submitted, the primary communications path is selected based on the alternate.direction subparameter. If alternate.direction=BAL, all communications paths are scanned to find the least used path, including the path defined in the adjacent node record, and all paths defined in the alternate.address subparameters. The least used path becomes the primary path. If alternate.direction=TOP, the communications path defined in the adjacent node record is used as the primary path.

If the Process fails to establish a session using the primary communications path, the network map is processed to determine the next eligible communications path. This is repeated until the session is successfully established or the number of communications paths is reached. When this number is reached, the primary communications path is restored and the Process is placed in timer retry (TI RE) status. After all session retries (MAXRETRIES) are reached, the original communications path is restored and the Process is placed in hold (HO WC) status.

Each failed attempt to establish a session produces the following result:

  • Message SVTM310I SESSION NOT ESTABLISHED WITH SNODE=xxxx
  • Session Begin statistics record that identifies the communications path used at the time of the failure
  • Diagnostics to RPLERRCK
  • When the MAXRETRIES is reached and the Process is placed in the HOLD queue, the following message is issued in addition to the previous message(s): 
    SVTM105I PNAME=pnam, PNUM=pnum MOVED TO Q=HOLD, QSTATUS=WC

When the Process establishes a session, the Session Begin statistics record identifies the communications path that was successfully used. That communications path is used for the life of the Process, unless ALTernate.RESTART is coded for the node, in which case the communications path may change if the Process restarts. For more information on ALTernate.RESTART, see the description for the ALTernate.COMMinfo parameter.

Alternate Communications Paths with Current Node as Secondary Node

When the current IBM Connect:Direct node is the secondary node (SNODE), the ALT.COMM parameter is used for network map checking purposes only.

Outbound Processes

The ALT.COMM parameter is used for outbound Processes when following conditions are true:

  • The current IBM Connect:Direct is the PNODE.
  • The Process is not in restart (the default ALT.RESTART=NO is in effect).
    Note: If you specify ALT.RESTART=YES, IBM Connect:Direct considers alternate communications paths if the path used to establish a session fails and the Process restarts. For an example, see Restarting Processes using an Alternate Communications Path
  • The Process is not PNODE=SNODE.
  • The Process is not SNODE=TCPNAME=.