gtps2m2y | ACF/SNA Data Communications Reference |
TPF attempts to activate VR0 to the destination subarea when the NCP is activated after explicit route 0 has been reported operative and activated.
If the explicit route associated with the virtual route being activated is operational and active, then an "activate virtual route" request (ACTVR) is sent from this subarea to the other end of the virtual route. On receipt of a positive response, the virtual route is marked active. It is now available for sessions to be assigned to it.
The virtual route deactivation (DACTVR) can only be requested by the primary virtual route end. This is the end that initiated the activation. However, if the other end denies the deactivation, then it becomes the primary.
To activate a selected virtual route, TPF first insures that the associated explicit route is active as described above. Then, an ACTVR request, which includes the maximum VR pacing window size, is sent to the physical unit at the other end of the route. On receipt of a positive response to the ACTVR request, the virtual route is "active," but in a "hold" state as the network flow control mechanism has not yet opened the route for traffic. The positive ACTVR response includes a "VR Pacing Response" which drives the TPF flow control logic and causes the route to be opened for traffic and so able to support a session. If the ACTVR response does not include a "VR Pacing Response" then the VR remains in "Hold" state until an isolated response arrives. Upon receiving the ACTVR response, TPF sends an isolated VRPRS to open the route for traffic from the other side. The route remains active unless TPF deactivates the virtual route, or the associated explicit route becomes inoperative.
TPF checks pacing window sizes, enabling it to set the window sizes necessary for TPF to connect to the network. Remember, TPF only supports ER0, VR0 to a channel attached SNI NCP.
With SNA CTC, activation of the virtual route is slightly different. Here, TPF supports VR0, VR1, and TP1 (transmission priority 1).
After the channel contact procedure is completed, but before sessions can be established, the virtual route(s) must be activated. TPF initiates sending ER_OP and ER_ACT immediately after channel contact. ACTVR is then sent after ER activation. Next, TPF checks an incoming ACTVR to ensure that:
This checking permits TPF-to-TPF CTC connections. TPF can now be the secondary side of the VR and any ACTVR meeting the previously described checks is accepted, if the VR is not already active.
Contention can occur if both sides send ACTVRs simultaneously. The contention winner is the node with the higher subarea (SA) value.
TPF does not take down a virtual route when the session count becomes zero (as VTAM does). Further, it responds negatively to any attempt to deactivate the virtual route by an orderly DACTVR from NCP. Only the primary end of the virtual route can deactivate the route. TPF ensures that it is the primary side of the virtual route by denying any ACTVR request. However, in accordance with the architecture, TPF does respond positively to a DACTVR forced, and cleans up any sessions associated with the virtual route.
When the explicit route associated with a virtual route becomes inoperative, the associated virtual route becomes inactive regardless of the number of sessions assigned to it. Appropriate notification is given to the endpoints of sessions using the virtual route.
When the operator requests deactivation of an NCP, after all the sessions through the NCP have been brought down, a channel discontact is sent for the normal, immediate and force options of ZNETW INACT. This causes the ER and VR to be reset by NCP.
In SNA CTC, VTAM deactivates the VR when the session count reaches zero. TPF denies the request with a sense indicating that a session is waiting to use the VR, and thereby becomes the primary side of the virtual route.