Shared LU name groups for Telnet servers

SNA architecture requires every LU in a VTAM® network to have a unique name. Multiple Telnet servers create added administrative effort to ensure that LU names are unique among the servers. However, if your environment uses multiple Telnet servers running on a single system or in a sysplex, then you can designate one Telnet server to be the LU name server (LUNS). The LUNS manages LU name assignments from LU groups among the group of Telnet servers, each known as an LU name requester (LUNR).

Shared LU groups are defined at each LUNR and sent to the LUNS. Shared LU group definitions can be the same or different at each LUNR. The LUNS allocates an LU name to a particular LUNR only if that LUNR defined the LU in a shared LU group. The LUNS manages LU names by ensuring that only one LUNR at a time is using a particular LU name. You can use load balancing to distribute Telnet client connections across several LUNR Telnet servers that have identical shared LU name configurations.

A single Telnet server can support both shared and unshared LU groups. Existing unshared LU group definitions continue to be managed at the local Telnet level.

You can configure a Telnet server to be only a LUNS, or a Telnet server can be a LUNS and also function as a regular Telnet server. Running Telnet as only a LUNS in its own address space has the following advantages:

Telnet port server functions will not compete with the LUNS for resources within the address space.
You can separate Telnet roles, which makes problem diagnosis easier.
You can stop and restart the Telnet LUNS without stopping the Telnet ports, and you can stop and restart the Telnet port servers without stopping the Telnet LUNS.
You can set the Telnet LUNS priority to a different priority than that of Telnet port servers.

Telnet uses XCF local group services to define the set of Telnet servers that participate in a shared LU name management group. You specify the level of participation of a particular Telnet server with shared LU name management by specifying or omitting the XCFGROUP block. For configuration details, see Steps for defining a LUNS and a LUNR.

Classic Telnet server
If you do not specify the XCFGROUP block for a server or you specify NOJOIN in the XCFGROUP block, the server does not join the XCFGROUP and cannot participate in shared LU name management.
- The server does not join an XCF group
- The server is not included in the Telnet XCF,GROUP display
- Shared LU group Objects cannot be defined on the server
This is the default behavior of a Telnet server.
XCF Telnet server
If you do specify the XCFGROUP block for a server and you specify JOIN in the XCFGROUP block, the server joins the Telnet XCF group and is able to participate in shared LU name management.
- The server is included in the Telnet XCF,GROUP display that can be issued for any XCF Telnet server that is in the same sysplex group
- The health of the Telnet server is monitored by XCF
- The server supports shared LU group Objects
- The server can be an LU name requester (LUNR)
  The LUNR is in standby state; it becomes active when shared LU group Objects are found while processing a profile. If you issue a VARY OBEYFILE command and there is no active profile that has shared LU group Objects, then the LUNR reverts to standby state.
XCF LUNS Telnet server
If you specify the XCFGROUP block for a server and include the appropriate statements, you can configure the server to have LUNS capability.
- The server has all the characteristics of an XCF Telnet server
- The server is an LU name server (LUNS)

After you have configured the level of participation, you can use the VARY OBEYFILE command to move the Telnet server to a higher level; however, you cannot use the VARY OBEYFILE command to move the server to a lower level.

There can be only one active LUNS in a sysplex; that LUNS manages requests for shared LU names so that the names are used by only one Telnet server at a time. The remaining Telnet servers are LU name requesters (LUNRs) that request LU names from the LUNS. The LUNR Telnet server connects to an administration listener socket that is created by the LUNS Telnet server. This TCP connection transmits all LU name requests and responses; this connection is not used for status signalling between the XCF Telnet servers. XCF services including XCF user state field updates, XCF status monitoring, and XCF group events are used to communicate LUNS and LUNR state changes and health.

You can configure a LUNS as a primary or a backup LUNS. When the Telnet server is started, a primary LUNS checks to determine whether there is already an active LUNS in the XCF group. If there is not, that primary LUNS attempts to become the active LUNS. If there is already an active LUNS, the primary LUNS becomes a standby LUNS. If several Telnet servers that are designated as a primary LUNS are started concurrently, then the race winner becomes the active LUNS and the others become standby. A backup LUNS always becomes a standby LUNS.

When an active LUNS fails, the following sequence of events automatically occurs:

All the LU name servers that are in standby mode examine the list of LU name servers that are in standby mode.
The standby LUNS that has the highest configured rank, regardless of whether that LUNS was started as a primary or backup LUNS, automatically becomes the active LUNS.
If several standby LU name servers have the same rank, then all those servers attempt to take over. The race winner becomes the new active LUNS and the others return to standby.

You can initiate manual takeover of a Telnet LUNS at any time. You can direct an operator command to any LUNS that is in standby or joined mode and tell it to start and become the active LUNS. The current LUNS will change to standby mode.

You can define all the Telnet servers in a sysplex that participate in shared LU name management to join the same XCF group. However, if your environment has one or more of the following characteristics, then you should partition the sysplex into Telnet subplexes:

All Telnet servers in a Telnet XCF group must have IP connectivity to each other. If your sysplex is partitioned into TCP/IP subplexes that do not have connected routes to each other, then you should partition the sysplex into Telnet subplexes along the same TCP/IP boundaries.
All Telnet servers in a Telnet XCF group should run on VTAMs in the same network. If your sysplex is partitioned into VTAM subplexes and the VTAMs are in different networks, then you should partition the sysplex into Telnet subplexes along the same VTAM network boundaries.
If you use several Telnet ports, each with a large set of shared LU names that do not overlap, and you load balance these ports across several Telnet servers, you might want to partition the sysplex into Telnet subplexes along the Telnet port boundaries. Subplexes reduce the shared LU name management workload on the LUNS and provide operational independence of the LUNS. All Telnet servers that are DVIPA targets of the same distributed port should be members of the same Telnet subplex.

A static VIPA is the best type of IP address to use for the LUNS administrative listener socket. Dynamic VIPA can work for the LUNS administrative listener, but there are cases in which dynamic VIPA can cause confusion.

If VIPADEFINE moves the IP address away from the LUNS, LUNRs already connected to the LUNS will continue to be able to send requests and receive replies. However, a new LUNR attempting to connect will be directed to the new TCP/IP stack, and the LUNS will not be there.
VIPARANGE will work if you can guarantee that each LUNS is supported by a different TCP/IP stack, and that the LUNS is the application that creates the IP address. If not, and the creating application ends, the LUNS socket will be closed. A standby LUNS on the same stack would be a problem. The standby LUNS sets up its listener before the original LUNS finishes cleanup. When the original LUNS finishes, the new LUNS listener socket will be closed.

For information about the XCFGROUP block, see z/OS Communications Server: IP Configuration Reference. For information about Telnet LUNS display, XCF display, and LUNS VARY commands, see z/OS Communications Server: IP System Administrator's Commands.