|
|
|
|
|
When coding the network map in the IOA.PARM library member with the name specified in the ECAPARM NETWMAP parameter, BMC recommends that you code the network map for the whole network and distribute this member to all sites that run IOAGATE. Each IOAGATE is able to extract the relevant information for itself from the same global map definitions.
All the parameters in the network map are mandatory.
The following are sample coded network maps that correspond to the sample configuration illustrated in Example.
Figure 55 Sample coded network map for SNA
LOCAL APPL=CONTROLO,NODE=GATE01
PARTNER APPL=CONTROLO,NODE=GATE02,LUNAME=LU02
PARTNER APPL=CONTROLO,NODE=GATE03,LUNAME=LU03
LOCAL APPL=CONTROLO,NODE=GATE02
PARTNER APPL=CONTROLO,NODE=GATE01,LUNAME=LU01
LOCAL APPL=CONTROLO,NODE=GATE03
PARTNER APPL=CONTROLO,NODE=GATE01,LUNAME=LU01
Figure 56 Sample coded network map for TCP
LOCAL APPL=CONTROLO,NODE=GATE01
PARTNER APPL=CONTROLO,NODE=GATE02,HOST=HOST2,
PORT=2760,CONNECTOR=LOCAL
PARTNER APPL=CONTROLO,NODE=GATE03,HOST=HOST3,
PORT=2760,CONNECTOR=LOCAL
LOCAL APPL=CONTROLO,NODE=GATE02
PARTNER APPL=CONTROLO,NODE=GATE01,
CONNECTOR=PARTNER
LOCAL APPL=CONTROLO,NODE=GATE03
PARTNER APPL=CONTROLO,NODE=GATE01,
CONNECTOR=PARTNER
Each LOCAL statement defines a specific IOAGATE in the network. Each PARTNER statement under the LOCAL statement defines another remote IOAGATE with which this specific IOAGATE will communicate.
When an IOAGATE starts, it reads the network map member specified in the ECAPARM member and locates the LOCAL statement that corresponds to that IOAGATE. This LOCAL statement is the one that has the same value in the NODE parameter as the value coded in the NODE parameter of the ECAPARM member.
In the sample network map in Figure 43, because the IOAGATE on MF01 in Figure 42 has NODE set to GATE01 in the ECAPARM member, that IOAGATE locates the first LOCAL statement in the network map. That IOAGATE establishes a connection with each partner IOAGATE specified in the PARTNER statements under that LOCAL statement.
Considerations For SNA — The connection to the partner IOAGATE is the LUNAME specified on the PARTNER statement. This LUNAME must match the APPLID in the ECAPARM member of the partner IOAGATE. Each IOGATE initiates a connection to its partner IOAGATEs, so that between each pair of IOAGATEs there are two connections.
For example, in the configuration illustrated in Figure 42, the IOAGATE on MF01 connects to both LU02, which is the IOAGATE on MF02 (because it has APPLID=LU02), and LU03, which is the IOAGATE on MF03.
Note: Each connection must be defined in both directions. If a connection is defined between CONTROLO on GATE01 and CONTROLO on GATE02, define both CONTROLOs as LOCALs connecting to each other as PARTNERs. A connection defined only in one direction cannot be established by IOAGATE.
Considerations For TCP — The connection to the partner IOAGATE is to the host and port specified by the HOST and PORT parameters, but only if CONNECTOR is set to LOCAL. If CONNECTOR is set to PARTNER, IOAGATE waits for the partner IOAGATE to initiate the connection. Therefore, you must define one IOAGATE with CONNECTOR set to LOCAL and the other with CONNECTOR set to PARTNER.
The PORT parameter defined in the MAP must match the port on which the partner IOAGATE listens for incoming connections. That port is defined in the ECAPARM CHANNEL statement of the partner IOAGATE.
Note: In TCP, only one side initiates the connection.
For example, in the configuration illustrated in Figure 42.
Note: The CHANNEL definition on the connection initiator side requires a port to be defined for listening to incoming connections, even though this IOAGATE may never receive any connection from any client or peer. This port can be shared with a Control‑D/Page on Demand Application Server, in which case the port will be used to receive incoming connections from Control‑D/WebAccess Server.
The value of APPL can be any of the following:
Parent Topic |