gtps2m1xACF/SNA Data Communications Reference

HPR Control Blocks

The following control blocks were created for HPR support:

RTPCB Table

The rapid transport protocol control block (RTPCB) table contains hash buckets, the RTPCB header, and one entry for every RTP connection. Each RTPCB entry is made up of three parts. The following figure shows an example of the RTPCB table layout:

Figure 75. RTPCB Table Layout




In Figure 75 an RTPCB entry is referenced using its RTPCB index, which is a direct index into the RTPCB table. For example, the RTPCB index of the first RTPCB entry is 1. Because RTP connections do not have names like other SNA resources (like LUs, CPs, ALSs, and so on), they are identified by their RTPCB index. Therefore, the RTPCB index is used as input to some of the SNA commands, including the ZNRTP commands, and shows up in the PIU trace table.

When an RTP connection is started, an RTPCB entry is assigned and added to the appropriate hash bucket based on the control point name of the remote RTP endpoint. When the RTP connection ends, the RTPCB entry is removed from whatever hash bucket it is in and the RTPCB entry is returned to the system.

For performance reasons, all RTPCB entries that represent RTP connections going to the same remote RTP endpoint are chained together using the hash bucket mechanism. When an HPR LU-LU session is starting, the TPF system needs to know if there are existing RTP connections that can be used. Rather than sequentially searching every RTPCB entry for a matching route, the hash bucket algorithm allows for a quick and effective search of the RTPCB table.

Each RTPCB entry is broken into three parts for the following reasons related to keypointing:

The RTPCB header contains statistical information about HPR support. It also contains the anchor for the various chains involving RTPCB entries. For example, all RTPCB entries for RTP connections that are doing a path switch are chained together. In another example, all RTPCB entries that have their short request timer running are chained together. This allows the TPF system to perform the necessary RTP endpoint functions effectively without having to scan the entire RTPCB table.

Defining the RTPCB Table

After you have determined the maximum number of HPR LU-LU sessions, the next step is to decide how to spread those sessions across RTP connections and determine how many RTP connections (RTPCB table entries) will be needed on each TPF processor. This becomes the value of the MAXRTPCB parameter on the SNAKEY macro in CTK2. See TPF ACF/SNA Network Generation for more information about the SNAKEY macro.

You need at least one RTP connection for each remote RTP endpoint that has HPR LU-LU sessions with a TPF processor. If there are many LU-LU sessions between a TPF processor and a given remote RTP endpoint across different routes, or many sessions using different class of service (COS) values, there will be multiple RTP connections between the TPF processor and remote RTP endpoint.

The URTP user exit allows you to control how many LU-LU sessions are assigned to an RTP connection. See TPF System Installation Support Reference for more information about the URTP user exit.

Defining Fixed File Records for the RTPCB Table

Parts 1 and 2 of the RTPCB table are keypointed. Based on the number of RTPCB entries defined, you need to define the necessary number of #RT1RI and #RT2RI fixed file records. These are processor unique records. To determine how many records you need to define for a TPF processor, use the following formulas:

Displaying RTPCB Entries

The ZNRTP DISPLAY command displays the contents of an RTPCB entry. The display can be either raw data or formatted. You can also use the ZDDCA command with the RTP dump tag specified to display the RTPCB table and its entries. See TPF Operations for more information about the ZNRTP DISPLAY and ZDDCA commands.

Initializing RTPCB Entries

You can use the ZNRTP INITIALIZE command to initialize RTPCB entries. However, do not initialize RTPCB entries in a production environment. Doing so resets SNA control blocks in the TPF system without informing the network. Inconsistencies will occur. Therefore, use the ZNRTP INACT command, rather than the ZNRTP INITIALIZE command, whenever possible.

See TPF Operations for more information about the ZNRTP INITIALIZE and ZNRTP INACT commands.

HPRSAT

The high-performance routing session address table (HPRSAT) contains one entry for every active HPR LU-LU session. Each entry contains the following information:

The HPRSAT is primarily used by the PIU trace code at read interrupt completion when NLPs are received from the network. Its purpose is to provide an effective way to map the SA received in the NLP to its corresponding LU RVT entry. The HPRSAT does for HPR sessions what the network address table (NAT) does for PU 5 LU-LU sessions, and what the session identifier table (SIT) does for PU 2.1 LU-LU sessions. All of these tables enable the TPF system to quickly find the LU RVT entry for a given PIU.

The HPRSAT is not keypointed. Instead, the table is always rebuilt after an IPL of the TPF system from information in the LU RVT entries.

Defining the HPRSAT

The HPRSAT is a single table shared by all RTP connections. The MAXHPRSA parameter on the SNAKEY macro in CTK2 defines how many entries there are in the HPRSAT, which is the maximum number of HPR LU-LU sessions that can be active at any time. An HPRSAT entry is assigned when an HPR LU-LU session starts, and the entry is cleared when that LU-LU session ends. The HPRSAT entry assigned to an LU-LU session is based on a hashing algorithm for performance reasons.

When defining the HPRSAT, you need to consider the existing APPN or PU 5 LU-LU sessions that will be migrated to HPR support as well as new LUs that will be added to the network.

See TPF ACF/SNA Network Generation for more information about the SNAKEY macro.

Displaying the HPRSAT

Use the ZDDCA command with the HSA dump tag specified to display the HPRSAT. See TPF Operations for more information about the ZDDCA command.

HPRMT

The high-performance routing message table (HPRMT) is used to save the data portion of HPR output messages (NLPs) until they are acknowledged by the remote RTP endpoint. A message is added to the HPRMT just before the NLP is placed on the SOUTC queue to be transmitted. A message is removed from the HPRMT when an NLP is received containing a STATUS segment that acknowledges receipt of the message.

If one or more NLPs sent by the TPF system become lost (for example, because of a failure in the network), the remote RTP endpoint will detect that data was lost and request that the TPF system retransmit the missing data. For this condition, the TPF system will find the necessary data in the HPRMT and build another NLP to resend that data to the remote RTP endpoint. All of the data and other important information about the message is saved in the HPRMT so that the message can be retransmitted without accessing the LU RVT entry because the LU-LU session may no longer be active. For example, the TPF system sends a data message followed by an UNBIND, causing the LU RVT entry to be cleaned up. The data message and UNBIND NLPs are both lost and must be retransmitted. The data message and UNBIND NLPs are rebuilt using only the information that was saved in the HPRMT.

Defining the HPRMT

The HPRMT resides only in core memory. You can define the size of the HPRMT by using the HPRMTSIZ parameter on the SNAKEY macro in CTK2. You must decide if the TPF system will save HPR output messages until they are acknowledged by the remote RTP endpoint. Saving messages requires additional storage. However, not saving messages can cause RTP connections (and the sessions through them) to be taken down when there is a failure in the network. For example, if data becomes lost in the network and the TPF system is requested to retransmit that data, the RTP connection will be broken because there is no saved copy of the data to retransmit. If you do not want the TPF system to save HPR output messages, set the value of the HPRMTSIZ parameter on the SNAKEY macro in CTK2 to 0, which means that the HPRMT is not defined. See TPF ACF/SNA Network Generation for more information about the SNAKEY macro.

If you want the TPF system to save HPR output messages, you need to define the size of the HPRMT. Some key factors to consider are:

If the HPRMT is defined but becomes full, HPR output messages cannot be saved until space becomes available in the table. Again, if the TPF system is requested to retransmit a message that cannot be found in the HPRMT, the RTP connection will be broken. The HPRMT does not and cannot use an aging algorithm. For example, if the HPRMT is full and a new HPR message is being sent out, throwing away the oldest message in the HPRMT to make room to save the new message will not work because messages that have been in the HPRMT the longest time are the ones that most likely will need to be retransmitted.

Because of the volume of data, it is not practical to keypoint the HPRMT. Across a software IPL of the TPF system, the HPRMT remains as is. Across a hardware IPL of the TPF system, the HPRMT is initialized and the RTP connection resynchronization process is started. See Host IPL Considerations for more information about how HPR support handles IPLs of the TPF system.

On a given TPF system, the average output message size and network turnaround time should be relatively constant regardless of the message rate. For example, when your TPF system is in a steady state and sending 500 HPR output messages per second, assume that the percentage of the HPRMT that is in use stays near 40%. Because the message rate and amount of HPRMT in use are directly proportional, you can predict that at 1000 messages per second, about 80% of the HPRMT would be in use.

Displaying Information about the HPRMT

Use the ZNRTP SUMMARY command to display information about how much of the HPRMT is currently in use and the maximum amount of the HPRMT that was in use at any point in time. You can also use the ZDDCA command with the HMT dump tag specified to display the HPRMT table.

The TPF system also automatically sends warning messages to the TPF operator console when the HPRMT becomes at least 90% full or 100% full.

Relationship with Other SNA Control Blocks

For each LU-LU session, one of the LU RVT entries contains the information about the session. This is called the session RVT entry. For LU 6.2 sessions, the session RVT entry is actually a session control block (SCB) entry.

Non-HPR LU-LU Sessions

When a PU 5 or PU 2.1 LU-LU session is started, the session is assigned to a specific link (ALS, CTC, or NCP) and remains assigned to that link for the duration of the session. The session RVT entry points to the CCW area of the assigned link using the CCW index (RV1CCWIN) field. Whenever data is to be sent on the LU-LU session, the CCW index in the session RVT is used to determine the link over which the data will be sent. If a link fails in the network, all LU RVT entries whose CCW index matches that of the failing link are cleaned up.

The following figure shows an example of the RVT and CCW area control blocks for five LU-LU sessions across two links. These could be either PU 5 or PU 2.1 LU-LU sessions:

Figure 76. LU RVT Entries for PU 5 and PU 2.1




In Figure 76:

If a message needs to be sent to LU_B, the CCW index in its RVT entry (RV1CCWIN=01) indicates that NCP1 is to be used.

If the link to NCP2 fails, the RVT entries for LU_A and LU_D would be cleaned up because their CCW index (RV1CCWIN=2) matches the CCW index of the NCP2 link.

HPR LU-LU Sessions

For HPR LU-LU sessions, the session RVT entry does not point to its link (the CCW index field in the RVT entry is not used for HPR LU-LU sessions). Instead, the session RVT entry points to the RTPCB entry of the RTP connection over which the LU-LU session exists. In turn, the RTPCB entry points to the current link assigned to the RTP connection using the CCW index field. Because the link assigned to an RTP connection can change (when a path switch takes place), the CCW index in the RTPCB entry will change. While the path switch process is in progress, there is no link assigned to the RTP connection.

When a non-HPR LU-LU session is started, the session is assigned to a specific link and remains assigned to that link for the duration of the session. When an HPR LU-LU session is started, the session is assigned to a specific RTP connection (not a specific link) and remains assigned to that RTP connection for the duration of the session. The link assigned to an RTP connection does not necessarily remain the same for the duration of the RTP connection; it can change because of a path switch.

The following figure shows an example of the RVT, RTPCB table, and CCW area control blocks for five HPR LU-LU sessions:

Figure 77. HPR LU RVT Entries, RTP Connections Are Active




In Figure 77:

If a message needs to be sent to LU_A, the CCW index field in this RVT entry is not examined because it is an HPR LU-LU session. Instead, the RTPCB index is used to get to the RTPCB entry (which is for RTP connection 1). The RTP connection is in CONNECTED state; therefore, the message can be sent out. The CCW index in the RTPCB entry indicates to send the message through NCP3.

Next, assume that the link to NCP3 fails. Because the current route for RTP connection 1 was through NCP3, this RTP connection starts the path switch process. The following figure shows an example of how the control blocks look at this point:

Figure 78. HPR LU RVT Entries, Path Switch Is in Progress




In Figure 78, RTP connection 1 is now in SWITCHING state and its CCW index is 0 because no route currently exists for this RTP connection. The HPR LU RVT entries are not changed at all when NCP3 fails.

While the path switch is in progress, the TPF application wants to send another message to LU_A. Because the RTPCB entry associated with the LU_A session is in SWITCHING state, the message cannot be sent at this time and is placed on the RTP output queue. See RTP Output Queue for more information about the RTP output queue.

The path switch process for RTP connection 1 is completed successfully and the new route goes through NCP1. The following figure shows an example of how the control blocks look at this point:

Figure 79. HPR LU RVT Entries, Path Switch Is Completed




In Figure 79, the RTPCB entry for RTP connection 1 is back in CONNECTED state and its CCW index has been updated to point to the link to NCP1. Any messages that were queued during the path switch are now sent across the new route. Throughout the entire path switch process, the HPR LU RVT entries are not changed; all of the changes pertaining to the route are made to the RTPCB entries instead.