Previous topic |
Next topic |
Contents |
Contact z/OS |
Library |
PDF
Session route setup at an end node z/OS Communications Server: SNA Network Implementation Guide SC27-3672-01 |
|
During session establishment, the end node provides a list of TG
tail vectors to the network node server used in the computation of
the session route. Because HPR is required for the recovery of a
multinode persistent session, the EN tries to ensure the session route
will transverse an HPR connection, by only providing to the NN server
the endpoint TGs that connect the EN to RTP-capable nodes. This guarantees
that the portion of the session path ending at the end node is HPR-capable
and, therefore, the session is potentially recoverable. This might
result in indirect routes when routing outside the sysplex. For example,
in Figure 1, assume that APPL1 wishes to
establish a session with APPL2.
Figure 1. Session routes
Note: If APPL2 requests a session with APPL1 and VTAM1 sends the request
directly to MDH1 using subarea protocols, the session is established
without an HPR connection and is not recoverable. You might want
to modify your search order to force the session requests for multinode
persistent application programs to go through APPN over an HPR connection.
See Controlling searches for additional information.
If during the APPN search no route is found, VTAM® will establish the session using subarea routes if available. In this instance, the session is not recoverable even if the application program is multinode persistent-enabled. After the session path has been established, VTAM can force a path switch to select a better
session route. This is necessary because during the setup for the
original path, the EN reports only HPR-capable links to the network
node server. During session establishment:
A path switch is performed if an HPR-capable route is found and a different end node TG is selected for the route. After the path is determined and the session is established, VTAM places the appropriate information in the multinode persistent session coupling facility structure. For example, in Figure 2 the session is established between APPL1 and APPL2 using EN1-NN1-NN3-EN3. The TGs considered when establishing the route were TGA, TGC, and TGD, because they guaranteed an RTP connection. Figure 2. Path switch processing
After the session is established, EN1 attempts to find a better session route by initiating path switch processing. This time, TGB is included as a possible transmission group, and as a result the session route EN1-NN3-EN3 is selected. Because a different TG is used than in the original session route calculated, the data path for the HPR connection is switched to the better route. If a better session path exists, and the data (or physical) path of the connection is switched to that path, the nonmultinode persistent partner is not told of the new path. The nonmultinode persistent partner remains unaware of the new path so that subsequent sessions will reuse the established HPR connection, because those sessions will, like the first, have their routes calculated using the subset of connections to RTP-capable nodes. Because the nonmultinode persistent partner is not aware of the real data path, when the second session is set up, there appears to be an HPR connection already established for the route (EN1-NN1-NN3-EN3). Therefore, the connection is reused. The MNPS EN, which is aware of the different physical path being used, will compare new session routes against the computed session path, and not the physical path, and will also be able to reuse existing HPR connections that traverse the same computed session path. The DISPLAY ID=RTP_PU_resource command can be used to display the
session path information known at a given node:
|
Copyright IBM Corporation 1990, 2014
|