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:

• For autostarted invokable TPs, registry or environment variables identify a TP name containing a maximum of eight characters, and can specify an associated LU. This information is sent from the client to the server that sponsors the client. A client learns about the domain through a sponsor connection to a server; clients must establish the sponsor connection before proceeding with any other tasks.
• For operator-started invokable TPs, a TP name (with a maximum of 64 characters) is specified in Specify_Local_TP_Name (or, for OS/2 only, by setting APPCTPN=TPname). The TP name is truncated to eight characters and sent from the client to the server that sponsors the client, along with the alias of an associated LU if one has been configured through a registry or environment variable.

Note  If you want a TP name to be unique, it is recommended that you limit the name to eight characters or fewer, or make the name unique within the first eight characters. This is because the preliminary routing of allocation requests is carried out using the first eight characters. Although further matching is later carried out between the full TP names, it is inefficient to allow the preliminary routing to succeed when in some cases the later matching will fail.

The next step in the matching of invoking and invokable TPs is the creation of a side information table from the parameters in the symbolic destination name. Then the invoking TP issues the Allocate call, and an allocation request flows to the partner LU specified in the side information table, stating the name of the invokable TP that has been requested (also listed in the side information table).

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:

• Although the TP name requested in the symbolic destination name can be as long as 64 characters, any name received through a registry or environment variable is eight characters or less. Therefore, only the first eight characters of TP names are used in comparisons.
• The comparison is carried out first on both the TP name and the LU alias. An invokable TP for which there is a match on both TP name and LU alias will be chosen ahead of a TP for which no LU alias has been configured through a registry or environment variable. A TP for which no LU alias has been configured can be matched with any request that specifies that TP name, since there cannot be a mismatch based on LU alias.
• The comparison of requested and available TP names is carried out in a specific order:
  1. The SNA server first checks for operator-started invokable TPs on the local system (the SNA server itself).
  2. If no match is found, the SNA server checks for autostarted invokable TPs on the local system (the SNA server itself).
  3. If no match is found, the SNA server checks for operator-started invokable TPs on other SNA servers or clients.
  4. If no match is found, the SNA server checks for autostarted invokable TPs on other SNA servers or clients.

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 CPI-C works, an allocation request will not flow until local data buffers are full, or a Confirm or Flush call is made. This may mean that the allocation request does not flow until some time after the Allocate call is made. 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 call with one of the allocation failure return codes.