PMDF System Manager's Guide
PMDF-REF-6.0

There are a number of aspects to configuring the PMDF-XGS transport bridge: configuring the SNA connection to the adjacent SNADS node(s); configuring the transfer programs to run on the transport bridge; and if using an OS/2 system as the transport bridge (NT systems normally have TCP/IP already configured), configuring the TCP/IP connection to the PMDF/PMDF-XGS system. The following sections describe the steps involved.

42.6.3.1 Configuring the SNA connection on the PMDF-XGS transport bridge

• The local node definition. The local node, or control point, is the SNA name of the OS/2 transport bridge, and a type 6.2 LU. (As the control point is a type 6.2 LU, note that this is the only local resource that needs to be defined.)
• i.e., the definition of the link to the immediately adjacent SNADS node. The link defines how to find the immediately adjacent SNADS node; for instance, by LAN address.
• The partner LU definition for the immediately adjacent SNADS node. The partner LU is the host APPL (CICS for DISOSS), or location name for the AS/400.
• The CPI-C side information (i.e., symbolic destination) definition. The symbolic destination is a name used by the gateway to refer to the set of values needed to make the outbound connection.
• The transaction program defaults settings. On an OS/2 transport bridge system, although not strictly required for PMDF-XGS transport bridge operation, changing certain default settings is strongly recommended.

On OS/2, after configuring the SNA connection for the PMDF-XGS transport bridge system using Communications Manager, you should have a Node Definition File, (a .ndf file), in Communications Manager's cmlib directory which should be similar to that shown in Figure 42-14 ; you may wish to look over your Node Definition File for comparison.

On NT, there is no text file version of the configuration (no equivalent of the Node Definition File on OS/2).

Finally, after configuring your SNA connection, make sure to shadow the appropriate icon or icons to your system's startup folder: on OS/2 shadow Communications Manager's "Start Communications" icon to your system's startup folder; on NT shadow its equivalent icons to your system's startup folder.

42.6.3.1.1 Parameters for the local node definition

Network ID

All nodes and LU's (Logical Units) have what is called a fully qualified name. This consists of a network id and a name. Usually all nodes within a network have the same network name, generally consisting of two characters representing the country followed by three characters representing the organization. The PMDF-XGS transport bridge should use the same network name as the immediately adjacent SNADS node, that is, the SNADS node to which it is connecting. If this immediately adjacent SNADS node is a mainframe, i.e., a DISOSS system, then the network id will be defined in the VTAM start parameter list (typically member name ATCSTR00 in SYS1.VTAMLIST). The VTAM keyword for this parameter is NETID=. If the immediately adjacent SNADS node is an AS/400, then the network name is the parameter LCLNETID, and can be found using the DSPNETA command. It is a name of up to 8 characters, upper case alphanumeric or #, @ or $. The first character must not be a digit. This parameter corresponds to the field marked (1) in Figure 42-14 .

Local Node Name

This forms the second part of the fully qualified node name. The local node is the PU (Physical Unit), and a type 6.2 LU (Logical Unit) as well. This must match the CPNAME= parameter in the PU definition of VTAM (if there is one), and the label on the LU definition. On the AS/400 this must match the controller name and the device name defined for this node. The node name can have up to 8 characters, upper case alphanumeric or #, @ or $. The first character must not be a digit. This parameter corresponds to the field marked (2) in Figure 42-14 .

Local Node ID

In some VTAM configurations, nodes are recognised by number instead of name. In this case the parameters IDBLK= and IDNUM= will appear on the PU definition in the VTAM listing. If these parameters are present, then the three hexadecimal digit IDBLK value and the five digit IDNUM value make up the Node ID and must be specified in the Communications Manager definition. This parameter corresponds to the field marked (6) in Figure 42-14 .

42.6.3.1.2 Parameters for the SNA connection definition

LAN Destination Address

Whatever type of connection you are using between the PMDF-XGS transport bridge and the adjacent SNADS node, you have to tell the Communications Manager how to find the adjacent node. Typically you will be using a LAN connection, in which case the LAN address to which you connect to reach the remote machine has to be provided. This may be the address of the FEP (Front End Processor) or the AS/400, but in more complicated networks it could be the address of some other communications controller. This parameter corresponds to the field marked (9) in Figure 42-14 .

Partner Network ID

This will usually be the same as the local node Network ID, described above in Section 42.6.3.1.1 . This parameter corresponds to the field marked (7) in Figure 42-14 .

Partner Node Name

This is the name of the remote node. If the remote node is running VTAM, then this is the SSCP (System Services Control Point) name of VTAM. This can be found in the start parameter list with the keyword SSCPNAME=. If the remote node is an AS/400, then this is the Control Point Name (LOCCPNAME) of the AS/400, and can be found by using the DSPNETA command. This parameter corresponds to the field marked (8) in Figure 42-14 .

42.6.3.1.3 Parameters for the partner LU definition

Network ID

This will be the same as the local node Network ID. This parameter corresponds to the field marked (13) in Figure 42-14 .

LU Name

If the remote node is running VTAM, then this is the APPL id of CICS. If the remote node is an AS/400, then this will be the Default Local Location Name (LCLLOCNAME) of the AS/400, and can be found by using the DSPNETA command. This is a name of up to four characters, and must match the value specified where CICS is shown in Figure 42-6 . This parameter corresponds to the field marked (14) in Figure 42-14 .

Alias

The Alias for the partner LU has no external significance in the SNA network, but it is very significant for the PMDF side as it determines which SNADS channel PMDF will use for incoming connections from that node. When using a single snads_local channel to connect to the SNADS world, specify this parameter as LOCAL, or as a name that starts with a non-alphabetic character. In a configuration with multiple SNADS channels in use, each additional channel, say snads_nodex, would require an additional partner LU definition with this parameter specified as NODEX.) This is a case sensitive field; for PMDF-XGS operation, this must be entered in upper case. This parameter corresponds to the field marked (15) in Figure 42-14 .

42.6.3.1.4 Parameters for the CPI-C side information (symbolic destination)

Symbolic Destination Name

This must match the Alias for the partner LU, described above in Section 42.6.3.1.3 . This is a case sensitive field; for PMDF-XGS operation, this must be entered in upper case. This parameter corresponds to the field marked (18) in Figure 42-14 .

Partner LU Fully Qualified Name

This is the Network ID and LU Name of the partner LU, discussed in Section 42.6.3.1.3 . The parameter corresponds to the field marked (19) in Figure 42-14 .

Partner TP

This is a service TP. On an NT transport bridge, it must be set to the value 21002. On an OS/2 transport bridge, it must be set to the value X'21'002. The parameter corresponds to the field marked (21) in Figure 42-14 . Note also that the Service TP option must be set.

Security

This must be set to NONE. This lack of a value for this parameter corresponds to the location marked (22) in Figure 42-14 .

Mode Name

You should generally use the mode #BATCH for SNADS connections. The mode name #BATCH is predefined in VTAM and in the AS/400. (Conceivably you could define and use some other mode of similar priority that, for instance, would not interfere with interactive terminal sessions.) This parameter corresponds to the field marked (20) in Figure 42-14 .

42.6.3.1.5 Parameters for the transaction program defaults definition on OS/2

Directory For Inbound Attaches

This should be set to nothing; i.e., delete the regular default * value in this field. This lack of a value for this parameter corresponds to the location marked (17) in Figure 42-14 .

42.6.3.1.6 OS/2 transport bridge node definition file format

Figure 42-14 The NDF file on the transport bridge system

  DEFINE_LOCAL_CP  FQ_CP_NAME(NetworkID.LocalNodeName     )  (1) (2)
                   CP_ALIAS(LocalNodeAlias)  (3)
                   NAU_ADDRESS(INDEPENDENT_LU)  (4)
                   NODE_TYPE(EN)  (5)
                   NODE_ID(X'LocalNodeID')  (6)
                   NW_FP_SUPPORT(NONE) 
                   HOST_FP_SUPPORT(YES) 
                   MAX_COMP_LEVEL(NONE) 
                   MAX_COMP_TOKENS(0); 
 
  DEFINE_LOGICAL_LINK  LINK_NAME(LINK0001)   (7)               (8)
                       FQ_ADJACENT_CP_NAME(PartnerNetworkID.PartnerNodeName   ) 
                       ADJACENT_NODE_TYPE(LEARN) 
                       DLC_NAME(IBMTRNET) 
                       ADAPTER_NUMBER(0) 
                       DESTINATION_ADDRESS(X'LANDestinationAddress')  (9)
                       ETHERNET_FORMAT(NO)  (10)
                       CP_CP_SESSION_SUPPORT(NO)  (11)
                       SOLICIT_SSCP_SESSION(NO)  (12)
                       ACTIVATE_AT_STARTUP(YES) 
                       USE_PUNAME_AS_CPNAME(NO) 
                       LIMITED_RESOURCE(USE_ADAPTER_DEFINITION) 
                       LINK_STATION_ROLE(USE_ADAPTER_DEFINITION) 
                       MAX_ACTIVATION_ATTEMPTS(USE_ADAPTER_DEFINITION) 
                       EFFECTIVE_CAPACITY(USE_ADAPTER_DEFINITION) 
                       COST_PER_CONNECT_TIME(USE_ADAPTER_DEFINITION) 
                       COST_PER_BYTE(USE_ADAPTER_DEFINITION) 
                       SECURITY(USE_ADAPTER_DEFINITION) 
                       PROPAGATION_DELAY(USE_ADAPTER_DEFINITION) 
                       USER_DEFINED_1(USE_ADAPTER_DEFINITION) 
                       USER_DEFINED_2(USE_ADAPTER_DEFINITION) 
                       USER_DEFINED_3(USE_ADAPTER_DEFINITION); 
 
  DEFINE_PARTNER_LU  FQ_PARTNER_LU_NAME(NetworkID.LUName      )  (13) (14)
                     PARTNER_LU_ALIAS(Alias)  (15)
                     PARTNER_LU_UNINTERPRETED_NAME(LUName   )  (16)
                     MAX_MC_LL_SEND_SIZE(32767) 
                     CONV_SECURITY_VERIFICATION(NO) 
                     PARALLEL_SESSION_SUPPORT(YES); 
 
  DEFINE_PARTNER_LU_LOCATION  FQ_PARTNER_LU_NAME(NetworkID.LUName      ) (13) (14)
                              WILDCARD_ENTRY(NO)  (7)               (8)
                              FQ_OWNING_CP_NAME(PartnerNetworkID.PartnerNodeName   ) 
                              LOCAL_NODE_NN_SERVER(NO); 
 
  DEFINE_DEFAULTS  IMPLICIT_INBOUND_PLU_SUPPORT(YES) 
                   DEFAULT_MODE_NAME(BLANK) 
                   MAX_MC_LL_SEND_SIZE(32767)  (17)
                   DEFAULT_TP_OPERATION(NONQUEUED_AM_STARTED) 
                   DEFAULT_TP_PROGRAM_TYPE(BACKGROUND) 
                   DEFAULT_TP_CONV_SECURITY_RQD(NO) 
                   MAX_HELD_ALERTS(10); 
 
  DEFINE_CPIC_SIDE_INFO SYMBOLIC_DESTINATION_NAME(SymbolicDestinationName   ) (18)
                         FQ_PARTNER_LU_NAME(NetworkID.LUName         )  (13) (14)
                         MODE_NAME(ModeName  )  (19)
                         SNA_SERVICE_TP_NAME(X'21',002);  (20)
                                                          (21)
  START_ATTACH_MANAGER; 

1. The NetworkID value corresponds to the Network ID field described in Section 42.6.3.1.1 .
2. The LocalNodeName value corresponds to the Local Node Name field described in Section 42.6.3.1.1 .
3. The LocalNodeAlias does not matter to PMDF-XGS.
4. The value in the NAU_ADDRESS field should essentially always be INDEPENDENT_LU, as shown.
5. The value in the NODE_TYPE field depends upon what sort of node this is. With PMDF-XGS, the bridge transport node is essentially always an end node, corresponding to the value shown here, EN.
6. The LocalNodeID value corresponds to the Local Node ID field described in Section 42.6.3.1.1 .
7. The PartnerNetworkID value corresponds to the Partner Network ID field described in Section 42.6.3.1.2 .
8. The PartnerNodeName value corresponds to the Partner Node Name field described in Section 42.6.3.1.2 .
9. The first twelve characters of the LANDestinationAddress value correspond to the Lan Destination Address field described in Section 42.6.3.1.2 ; the last two characters in this value are the SAP address, which is usually 04.
10. The correct value for a site's ETHERNET_FORMAT field depends upon the sort of network in use, Ethernet or token ring. The value shown here, NO, would be correct for a token ring network.
11. The correct value for a site's CP_CP_SESSION_SUPPORT parameter depends upon whether the link is end node to end node, or end node to host, or end node to network. The value shown here would be correct for an end node to end node link.
12. The correct value for a site's SOLICIT_SSCP_SESSION parameter depends upon whether the link is to support dependent LU's, such as a 3270 session. The value shown here, NO, implies no dependent LU support.
13. The NetworkID value corresponds to the Network ID field for the partner LU described in Section 42.6.3.1.3 .
14. The LUName value corresponds to the LU Name field described in Section 42.6.3.1.3 .
15. The Alias value corresponds to the Alias field described in Section 42.6.3.1.3 ; for the case of a single snads_local channel, this parameter value will be LOCAL or a value starting with a non-alphabetic character.
16. The Uninterpreted Name is almost always set to the same value as the LU Name for the partner LU; that is, this is almost always the same as .
17. Note that there is no DIRECTORY_FOR_INBOUND_ATTACHES field in this section, since the default * value was deleted.
18. The SymbolicDestinationName value corresponds to the Partner Node Name field described in Section 42.6.3.1.4 . This value should match the value shown in .
19. The ModeName value corresponds to the Mode Name field described in Section 42.6.3.1.4 .
20. Note that the SNA_SERVICE_TP_NAME field is set to X'21',002 as required for the Partner TP field described in Section 42.6.3.1.4 . (During the configuration with Communications Manager, this value the value should be entered without a comma; the comma will then appear in the actual file.)
21. Note that there is no SECURITY field, as required and described in Section 42.6.3.1.4 .

42.6.3.2 Configuring the programs on the NT PMDF-XGS transport bridge

In the directory on the transport bridge system into which the PMDF-XGS transport bridge programs were installed, typically c:\snadsrv, there is a file xgs.cmd created according to your answers during the (configuration portion of the) installation of the PMDF-XGS transport bridge programs. This is a command file, similar to a DOS .BAT file, which starts three components of PMDF-XGS which must run on the PMDF-XGS transport bridge. These components are:

• sendsrv, which accepts SNADS distributions outbound from PMDF and sends them out into the SNADS network; and
• recvsrv, which accepts SNADS distributions from the SNADS network and sends them to the PMDF system.

Once the xgs.cmd procedure has been created, be sure to shadow the xgs.cmd icon to the system's "Startup" folder so that it will be autostarted.

42.6.3.2.1 Parameters for the NT PMDF-XGS transport bridge programs

sendsrv [bridgeport] [loghost] 

recvsrv has four required parameters as well as one additional optional parameter:

recvsrv PMDFhost dispatcherport bridgeREN docsize [loghost] 

Example 42-1 shows an example xgs.cmd file.

Example 42-1 Samplexgs.cmdfile

start sendsrv 9994 localhost 
start recvsrv apollo.olympus.org 9993 AMBROSIA 10000000 localhost 

42.6.3.3 Configuring the programs on the OS/2 PMDF-XGS transport bridge

• xcontrol, which manages the SNMP requests;
• sendsrv, which accepts SNADS distributions outbound from PMDF and sends them out into the SNADS network; and
• recvsrv, which accepts SNADS distributions from the SNADS network and sends them to the PMDF system.

Once the xgs.cmd procedure has been created, be sure to shadow the xgs.cmd icon to the system's "Startup" folder so that it will be autostarted.

42.6.3.3.1 Parameters for the OS/2 PMDF-XGS transport bridge programs

xcontrol [SNMPcommunity] [SNMPport] 

sendsrv takes up to four parameters:

sendsrv [bridgeport] [loghost] [SNMPport] [directory] 

recvsrv has four required parameters as well as three additional optional parameters:

recvsrv PMDFhost dispatcherport bridgeREN docsize [loghost] [SNMPport] [directory] 

Example 42-2 shows an example xgs.cmd file.

Example 42-2 Samplexgs.cmdfile

start xcontrol 
start sendsrv 9994 localhost 9990 c:/capture 
start recvsrv apollo.olympus.org 9993 AMBROSIA 10000000 localhost 9990 c:/capture 

42.6.3.4 Configuring TCP/IP on an OS/2 PMDF-XGS transport bridge

There are, however a couple of points of which to be aware. You must make sure that the loopback driver is started, and that the hostname localhost is defined. The loopback driver is started by the line

 ifconfig lo 127.0.0.1 

 127.0.0.1   localhost 

The transport bridge component of the PMDF-XGS gateway collects statistics which can be queried from an SNMP network management center. It does this through the dpi interface of the SNMP daemon. This must be configured to start, and to support the dpi interface. This is most easily configured through the configuration notebook. (If you are using Warp Connect, the parameters -dpi shm -dpi tcp must be specified.) Configuring this through the configuration notebook will result in the line

 start /min snmpd 

 start /min snmpd -dpi shm -dpi tcp