PMDF System Manager's Guide
PMDF-REF-6.0

42.6.1 Configuring a DISOSS node

Each SNADS node must be configured to know about the PMDF-XGS transport bridge and about every host or mail system on the PMDF side which is to be directly addressable from the SNADS side. That is, at a minimum, each SNADS node must be configured to believe that the PMDF-XGS transport bridge is another SNADS node and that the PMDF system is a SNADS node reachable through the PMDF-XGS transport bridge. Once the PMDF system is reachable from SNADS, then any host or mail system reachable by PMDF may be made reachable from SNADS via aliased or embedded addressing; however, it is usually preferable to add additional routing information to the SNADS nodes to allow direct addressing from SNADS of other commonly addressed hosts or mail systems. The PMDF-XGS transport bridge looks to other SNADS nodes just like an AS/400 running OV/400. Other systems reachable through PMDF appear to the SNADS nodes as remote AS/400 systems.

The simplest way set up the SNADS nodes is to define directory information on each of the SNADS nodes so that users *ANY at PMDFnodeDGN, and users *ANY at othersystemreachedthroughPMDF, are all at the PMDF-XGS transport bridge (which appears to be another SNADS node), and then to define to the SNADS nodes how to send mail to the PMDF-XGS transport bridge system. PMDFnodeDGN is technically the PMDF node's DGN, from the SNADS point of view; however, as we consider the PMDF node's REN to be the same as its DGN, it is the same value as the PMDF node's REN (and thus effectively is the PMDF node name from the SNADS point of view).

There are three parts to configuring a DISOSS node to connect to PMDF-XGS. On each DISOSS node, you must add directory information specifying that the user location for the PMDF system (and any other system reachable through PMDF that you wish to add) is on the PMDF-XGS transport bridge; see Section 42.6.1.1 . You must inform each DISOSS node how to route distributions to the PMDF-XGS transport bridge; see Section 42.6.1.2 . And you must configure tha SNA connection, including both the VTAM and CICS definitions; see Section 42.6.1.3 .

42.6.1.1 Adding directory information on a DISOSS node

For a DISOSS node, the user location information is configured using the commands in Figure 42-2 .

Figure 42-2 Defining SMTP Hosts to DISOSS

ADD    USERTYPE='REMOTE' 
       DDN='PMDFnodeDGN' 
       SA='*' 
       RGN='        ' 
       REN='bridgeREN'. 
ADD    USERTYPE='REMOTE' 
       DDN='anothersystemreachedthroughPMDF' 
       SA='*' 
       RGN='        ' 
       REN='bridgeREN'. 
ADD    USERTYPE='REMOTE' 
       DDN='yetanothersystemreachedthroughPMDF' 
       SA='*' 
       RGN='        ' 
       REN='bridgeREN'. 
...

where PMDFnodeDGN is the name you will use on the SNADS side for the PMDF system, and where bridgeREN is the name you will use on the SNADS side for the PMDF-XGS transport bridge.

42.6.1.2 Adding routing information on a DISOSS node

Each DISOSS node needs to be told how to route messages to the PMDF-XGS transport bridge. Exactly where a particular DISOSS node should route a distribution eventually intended for the PMDF-XGS transport bridge will depend upon the topology of your SNADS network. The SNADS node directly adjacent to the PMDF-XGS transport bridge will need a new entry in its routing table coordinating the REN (or SNADS node name) of the PMDF-XGS transport bridge with the SNADS node's CICS definition of the PMDF-XGS transport bridge LU (Logical Unit). A SNADS node which is not adjacent to the PMDF-XGS transport bridge, but which presumably does already have an entry specifying how to get to the SNADS node which is adjacent to the PMDF-XGS transport bridge, will also need a new entry in its routing table for the PMDF-XGS transport bridge similar to its current entry for the SNADS node adjacent to the PMDF-XGS transport bridge.

If the DISOSS node is directly adjacent to the PMDF-XGS transport bridge, then it will need a new routing table entry along the lines of Figure 42-3 . Here bridgeREN is the name of the PMDF-XGS transport bridge, and bridgeCICSname is the CICS name for the LU for the PMDF-XGS transport bridge, matching the name to be used during the CICS configuration step as described in Section 42.6.1.3.2 below; see particularly Figure 42-7 and Figure 42-8 .

Figure 42-3 Defining the route to the PMDF-XGS transport bridge on an adjacent DISOSS node

ADD    RGN='        ' 
       REN='bridgeREN' 
       TRANSID='DSVE' 
       SSL='*' 
       QUEUE=bridgeCICSname

If the DISOSS node is not adjacent to the PMDF-XGS transport bridge, then it will need a new routing table entry on how to get to the PMDF-XGS transport bridge similar to its current routing table entry on how to get to a SNADS node that is adjacent to the PMDF-XGS transport bridge. So to add the necessary routing information on a DISOSS node, first inspect the routing table entry for how to get to a node adjacent to the PMDF-XGS transport bridge. Then add a similar entry for the PMDF-XGS transport bridge itself. For instance, if the routing table entry on a DISOSS node for a SNADS node adjacent to the PMDF-XGS transport bridge is as shown in Figure 42-4 ,

Figure 42-4 Existing routing table entry on a DISOSS node not adjacent to the PMDF-XGS transport bridge

ADD    RGN='        ' 
       REN='SNADSnodeadjacenttobridge' 
       TRANSID='DSVE' 
       SSL='*' 
       QUEUE='queuename'.

where SNADSnodeadjacenttobridge is the name of the SNADS node adjacent to the PMDF-XGS transport bridge and queuename is the name of a queue, then you would add a routing table entry such as that shown in Figure 42-5 ,

Figure 42-5 New routing table entry on a DISOSS node not adjacent to the PMDF-XGS transport bridge

ADD    RGN='        ' 
       REN='bridgeREN' 
       TRANSID='DSVE' 
       SSL='*' 
       QUEUE='queuename'.

using the SNADS name of the PMDF-XGS transport bridge where bridgeREN is shown. The effect is to instruct the SNADS node to route distributions intended for the PMDF-XGS transport bridge along the existing path to the SNADS node which has the direct link to the bridge.

42.6.1.3 Defining the SNA link in VTAM and CICS on an adjacent DISOSS node

It is not possible to give a completely prescriptive procedure of exactly what is needed to configure the VTAM connection between the PMDF-XGS transport bridge and a directly adjacent DISOSS node, as too much depends on what is already defined. However, the PMDF-XGS transport bridge will need to be defined in VTAM, and then there needs to be a definition in CICS that refers down to this VTAM definition. Once these definitions are in place, then the DISOSS definition that refers to the CICS definition --- created as shown above in Section 42.6.1.2 ; see in particular Figure 42-3 --- completes the configuration on this adjacent DISOSS node; that DISOSS definition tells DISOSS to send distributions to the PMDF-XGS transport bridge using the CICS connection bridgeCICSname, where that CICS connection uses the VTAM control point bridgeCPname, to make the actual link.

42.6.1.3.1 The VTAM definition for the SNA link on DISOSS

The VTAM definition will look somewhat like the one shown in Figure 42-6 .

Figure 42-6 VTAM definition of the PMDF-XGS transport bridge on an adjacent DISOSS node

bridgeLKname PU  ADDR=04, 
                 CPNAME=bridgeCPname
                 XID=YES,RESSCB=2 
bridgeCPname LU  LOCADDR=0, DLOGMOD=#BATCH, 
                 LOGAPPL=CICS
... 
CICS         APPL  ACBNAME(CICS)

Here bridgeLKname is the PU (Physical Unit) name given to the PMDF-XGS transport bridge, and does not have to match any definition on the PMDF-XGS transport bridge itself bridgeCPname is the Local Node Name (i.e., control point name) of the PMDF-XGS transport bridge. This must match the SNA VTAM node name, i.e., the Local Node Name, specified in the Communications Manager definition on the PMDF-XGS transport bridge described in Section 42.6.3.1.1 . (That is, note that bridgeCPname is the SNA VTAM layer name for the PMDF-XGS transport bridge, as contrasted to the SNA CICS layer name for the PMDF-XGS transport bridge represented by bridgeCICSname or as contrasted to the SNADS e-mail layer name for the PMDF-XGS transport bridge represented earlier bridgeREN.) CICS is the VTAM application name (APPL) for the CICS region where DISOSS is running, and must match the LU Name specified in the Communications Manager definition of the partner LU on the PMDF-XGS transport bridge described in Section 42.6.3.1.3 . Note that the line

LOGAPPL=CICS

in the bridgeCPname LU (Logical Unit) definition is required for PMDF-XGS operation.

There may be other parameters, but these will largely be the same as for a 3270 connection from the PMDF-XGS transport bridge to the DISOSS node.

42.6.1.3.2 The CICS definition for the SNA link on DISOSS

For the CICS configuration both a connection definition and a session definition have to be configured in CICS. This is achieved using the CEDA commands:

CEDA DEFINE GROUP(group) CONNECTION(bridgeCICSname)

and

CEDA DEFINE GROUP(group) SESSION(session)

Here bridgeCICSname must match the QUEUE value specified in Section 42.6.1.2 , in particular in Figure 42-3 above; group and sesssion are locally chosen names, and do not have to match any definition on the PMDF-XGS transport bridge itself. Running these commands result in the screens shown in Figure 42-7 and Figure 42-8 .

Figure 42-7 CICS CONNECTION definition

 CEDA DEFine 
  bridgeCICSname
  Group 
  DEscription  ==> PARTNER LU 
 CONNECTION IDENTIFIERS 
  Netname      ==> bridgeCPname
  INDsys       ==> 
 REMOTE ATTRIBUTES 
  REMOTESystem ==> 
  REMOTEName   ==> 
 CONNECTION PROPERTIES 
  ACessmethod  ==> Vtam  Vtam|IRc|INdirect|Xm 
  Protocol     ==> Appc  Appc | Lu61 
  SInglesess   ==> No    Yes | No 
  DAtastream   ==> User  User|3270|SCs|Strf|Lms 
  RECordformat ==> U     U | Vb 
 OPERATIONAL PROPERTIES 
+ AUtoconnect  ==> No    No | Yes | All 
  INService    ==> Yes   Yes | No 
 SECURITY 
  SEcurityname ==> 
  ATtachsec    ==> Local Local|Identify|Verify 
                         |Persistent|Hixidpe 
  BINDPassword ==>       PASSWORD NOT SPECIFIED 
  BINDSecurity ==> No    No | Yes

As described above, bridgeCICSname is the name CICS uses to identify the LU and bridgeCPname is the name VTAM uses to identify the LU and must respectively match the Local Node Name and the LU Name for the partner LU configured in Communications Manager on the PMDF-XGS transport bridge; see Section 42.6.3.1.1 and Section 42.6.3.1.3 . group is a name chosen locally and is not significant outside of the DISOSS node.

Figure 42-8 CICS SESSION Definition

 CEDA DEFine 
  Sessions       : session
  Group          : group
  DEscription  ==> SESSIONS for PARTNER LU 
 SESSION IDENTIFIERS 
  Connection   ==> bridgeCICSname
  SESSName     ==> 
  NETnameq     ==> 
  MOdename     ==> #BATCH 
 SESSION PROPERTIES 
  Protocol     ==> Appc        Appc | Lu61 
  MAximum      ==> 002 , 000   0-999 
  RECEIVEPfx   ==> 
  RECEIVECount ==>             1-999 
  SENDPfx      ==> 
  SENDCount    ==>             1-999 
  SENDSize     ==> 1920        1-30720 
  RECEIVESize  ==> 1920        1-30720 
+ AUtoconnect  ==> No    No | Yes | All 
  INService    ==> Yes   Yes | No 
 SECURITY 
  SEcurityname ==> 
  ATtachsec    ==> Local Local|Identify|Verify 
                         |Persistent|Hixidpe 
  BINDPassword ==>       PASSWORD NOT SPECIFIED 
  BINDSecurity ==> No    No | Yes

Here bridgeCICSname is the name CICS uses to identify the LU, and must match the LU Name for the partner LU configured in Communications Manager on the PMDF-XGS transport bridge; see Section 42.6.3.1.3 . group and session are names chosen locally and are not significant outside of the DISOSS node.

Previous | Next | Contents