Matching Invoking and Invokable TPs

Each SNA server maintains a list of available invokable TP names and any LU aliases to be associated with the TP names. This information is obtained as follows:

The next step in the matching of invoking and invokable TPs is that the invoking TP issues the ALLOCATE or MC_ALLOCATE verb. After an invoking TP in an SNA Server domain successfully issues this verb, an allocation request flows to the partner LU specified in the ALLOCATE or MC_ALLOCATE verb, stating the name of the invokable TP that has been requested.

When an allocation request arrives, the SNA server compares the requested invokable TP name and LU alias to the list of available invokable TPs (which can include associated LU aliases). The comparison can be modified by registry variables, but by default is carried out as follows:

This comparison can be modified somewhat by registry entries for the SnaServr service. The entries are called DloadMatchTPOnly and DloadMatchLocalFirst, and are described in the Microsoft SNA Server Reference.

If a match is found, the SNA server signals the system containing the requested TP to connect to that SNA server. If no match is found, the SNA server rejects the incoming request.

For suggestions about specific ways to handle TP names and LU aliases, see Arranging TPs Within an SNA Network.

Note  Because of the way APPC works, an allocation request will not flow until local data buffers are full, or a confirm or flush verb is issued. This can mean that the allocation request does not flow until some time after the ALLOCATE or MC_ALLOCATE verb is issued. Therefore, any allocation failure caused by the rejection of the allocation request at the partner LU will be observed as the failure of a later verb with one of the allocation failure return codes.