How can the LU names differ?

There are several circumstances that may cause the name returned in the SLU's BIND response to differ from the name specified on the PLU's BIND request. For example, in VTAM®, the partner LU may be known by a generic resource name or a USERVAR. The following scenarios explain how name translations are managed by VTAM's name mismatch detection for LU 6.2 applications.

Partner LU known by multiple names

In VTAM, for example, when the LUALIAS keyword is specified on a CDRSC definition statement, the name of the target LU may be altered.

For example, if LUALIAS=LUX is specified on the CDRSC definition statement for an LU whose real name is NETA.LU2, then when an APPCCMD CONTROL=OPRCNTL, QUALIFY=CNOS is issued specifying LUNAME=LUX, the BIND response will contain NETA.LU2 in the user data field. In this case, VTAM maintains both LU names in the LU-mode table. The name specified on the APPCCMD (LUX) becomes a SUPPLIED_NAME entry and the name returned on the BIND response unit (NETA.LU2) becomes a VARIANT_NAME entry. In this example, VTAM does not allow the local application to start any sessions using the name NETA.LU2. This prevents possible errors that could occur when an LU attempts CNOS negotiations with what appears to be different partners.

Name changes while sessions are active

After a session is established, VTAM saves the partner name specified on the LUNAME parameter and the name that was returned by the partner in the BIND response unit. These names are not required to be identical. However, if a second session request is sent to the same partner (as is shown in Figure 1), it is possible that the partner returns a name in the BIND response unit that is not identical to the name returned on the first session.

Figure 1. Name mismatch in two BIND responses for the same partner LU

Two possible explanations are that the partner LU changed its name between sessions or the second session was directed to a different LU. In either case, VTAM terminates the second session and returns an error code with an RCPRI type of X'00B0' to the APPCCMD macroinstruction.

Partner LU initiates the session

In Figure 2, assume that VTAM is the target of a partner LU's CNOS request.

Figure 2. Name mismatch when the partner LU is the PLU

1

A remote LU issues an APPCCMD CONTROL=OPRCNTL, QUALIFY=CNOS and specifies the local application (LU1) as the SLU. After a successful CNOS negotiation, VTAM reports the results, including the partner's name (as specified on the BIND request unit) and the LOGMODE used to the local application by scheduling the ATTN(CNOS) exit. In this case, the name reported to the local application is LUB. VTAM enters LUB as a RCVD_NAME entry in the LU-mode table.

2

The partner LU then sends an FMH-5 to initiate a conversation. VTAM reports these results, again including the partner's name (LUB) and the LOGMODE used to the local application by scheduling the ATTN(FMH5) exit.

3

The local application then issues an APPCCMD CONTROL=RCVFMH5, which completes the initiation of the conversation.

Note that in the preceding steps, the local application has not specified the partner's LU name (LUB) on any APPCCMD macroinstruction.

4

The local application then issues an APPCCMD CONTROL=OPRCNTL, QUALIFY=CNOS containing LUNAME=LUA. If there exists an LUALIAS definition that converts LUA to LUB, then the following conditions occur:

The APPCCMD CONTROL=OPRCNTL, QUALIFY=CNOS completes with an RCPRI, RCSEC combination of X'0000', X'000C' or X'0000', X'000D', which indicates a name change.
VTAM changes the record of LUB in the LU-mode table to a VARIANT_NAME entry. LUA becomes a SUPPLIED_NAME entry for the partner LU. All subsequent APPCCMD macroinstructions that specify LUB will be rejected with an RCPRI, RCSEC combination of X'00B0', X'0001', NAME_RESOLUTION_ERROR— LUNAME_FOUND_IN_A_VARIANT_NAME_ENTRY.
If the application requested APPCCMD vector information, a name-change vector is returned that reports the "passive" name, LUB, and the "active" name, LUA. The local application should examine the name-change vector to obtain the name that was returned.
All subsequent reporting of actions formerly attributed to LUB, such as ATTN exit scheduling, will now be attributed to LUA.

For information about the types of LU entries, see LU entries in the LU-mode table.