gtps2m2z | ACF/SNA Data Communications Reference |
The initial state of the virtual route once the ACTVR has been issued is "held waiting for a virtual route pacing response." On receipt of the positive response to ACTVR then the virtual route is active and, if that positive response contains a VR pacing response, is open as well (for example, not held).
Once the virtual route is open each PIU is transmitted as a singly segmented PIU. TPF sets the pacing request bit on in the first PIU of the window and suspends transmission on the virtual route if a pacing response is outstanding and the window size has been exhausted. This should be an extremely rare case, as TPF sets the minimum and maximum window size to a user-defined value. The recommended value is 42 for NCPs, but the user can set them up to the maximum (255). The tradeoff is NCP buffer utilization versus TPF performance. NCP allocates buffers equal to 3 times the minimum value, so that a large value may cause buffer depletion. TPF queues messages waiting on a blocked virtual route in main storage until the VRPRS is received. A small value may cause extra delay in response time and cause congestion in TPF due to the length of time TPF buffers are committed to an entry.
Because TPF sets the minimum and maximum window size to the same value, TPF requires that the adjacent NCP contain the SNA network Interconnect (SNI) function and that all TPF traffic that is routed through intermediate nodes cross the gateway in the adjacent NCP. TPF checks that any ER activated is limited to a hop count of 1 to ensure the SNI connection.
Virtual route pacing responses received by TPF open the VR. When a VR pacing request is received, TPF must generate a VRPRS to the other end of the virtual route.
After receiving a VR pacing request TPF returns an isolated VRPRS PIU on that virtual route, including the transmission priority and virtual route number in the TH. TPF does not set "congestion detected" indicators.
TPF explicitly withholds the VR pacing response, based upon the values you can set in CTK2 for the different block types. The values indicate the percentage of available blocks that are needed for a VR pacing response to be sent. VR pacing responses can be withheld based upon 4K, 1055, 381, and ECB block types. A value of 0 indicates that VR pacing should not be withheld based upon this block type. (See TPF ACF/SNA Network Generation for additional details.)
For example, if there are 1000 4K blocks in the system and the SNAKEY parameter ILWP4 is set to 35, there must be at least 350 4K blocks available for the system to respond to the VR pacing request. When setting these values, the input list shutdown values for the different block types should be the values you want to keep from reaching. Using the previous example of ILWP4 set to 35, if the input list shutdown value for 4K blocks is 200, the difference is 150 4K blocks. This should be enough 4K blocks to handle the next window's worth of PIUs. If the amount of remaining 4K blocks is not correct, the specified value for ILWP4 should be changed.
While a virtual route is "blocked" (waiting for a pacing response) the output message data is held in storage buffers that were associated with the application sending the message.