2 Feb 1995
One of the key terms in SNA is the "Logical Unit." Unfortunately, the exact meaning of this term has tended to drift as the architecture was updated and adapted to meet new requirements. It is still necessary to define LU's, and it is not all that difficult to stumble through the definition successfully. However, explaining just what the options mean requires a bit of care. The "Logical Unit" had four major functions:
The SNA architecture requires that data flow on established sessions. There are no isolated messages ("datagrams") as in other communications systems. The sessions that contain user data are established between Logical Units. A smaller number of SNA sessions exist for network management purposes between VTAM and the node (Physical Units), but these sessions contain no user data. Today this requirement for an LU to be at each end of a session still holds.
The LU has a name. Within the subarea network, LUNAMEs are configured in the VTAM parameter datasets for every terminal, printer, or application program. However, these LUNAMEs are frequently used only inside VTAM itself. An application may need to present VTAM with the LUNAME for a printer in order to use the device to print a file. VTAM displays the configured LUNAME for a display when generating messages about the device to the operator console. However, LUNAMEs for a 3270 terminal are not part of network traffic and they are not configured to the control unit that manages the terminal, nor to the PC that runs a terminal emulation program.
In the APPN network, however, LUNAMEs are used to locate servers. The client machine has an LU (because as previously explained there must be an LU at each end of a session). However, the client LUNAME is irrelevant. When the client wants to start a session with the server, it generates a BIND request with the LUNAME of the server, and the APPN network routes this BIND to the machine on which the server is running.
The LUNAME is not a machine name, neither is it a program name. This allows a particular service to move around in the network without requiring all the clients to be configured. In particular, a backup machine can provide services if the primary server goes down. It can be argued that the new peer networks make LUNAME even more important than it was in the mainframe network.
In Classic SNA, an LU is a "Network Addressable Unit" (NAU). When the network comes up, the LU is assigned a network address consisting of a subarea number and a station number. Each NCP governs a subarea. If a message arrives with a different subarea number, the NCP examines its charts for subarea routing to determine which link to use to send the message on to another NCP. If a message arrives with the local subarea number, the NCP consults its local control blocks to determine which node (and therefore which SDLC line or LAN address) to use to deliver the message to the LU.
However, the APPN network does not have global addresses. A session is established by sending a BIND through the network from the client to the server. As the BIND flows, each intermediate node assigns a numeric ID to the session itself, with control blocks indicating the routing of messages on the session in each direction. Subsequent traffic is routed by the session number. Neither the client, the server, nor any node in the middle has any global view of the source or destination of any of the messages. There are no NAU's in an APPN network.
If the workstation user is asked to define Logical Units, there are four possible responses based on context:
For an emulated 3270 display or printer, Logical Units are identified by a one byte number, not by their name. In Communications Manager under OS/2, you only have to specify the number of terminals and the LU's are generated automatically. In other IBM software packages, however, you may have to assign the numbers (2,3,4...) to each terminal or printer session.
For a desktop system that will only be a client to other systems, it is necessary to have one LU, but the name does not matter. Again, the current OS/2 Communications Manager product simplifies things by automatically creating one "default" LUNAME based on the computer name given when the PC node was defined. Other workstation systems may require an explicit configuration step with some chosen name.
If the machine will act as a server, then an LUNAME should be configured for the service. It is possible to use the default name created for the machine, but this is probably not a good practice. Clients will then become dependent on the service remaining on the indicated node. Rather, it is better to create an LUNAME as an alias for some particular function or cluster of databases.
It may also be necessary to configure LUNAMEs for services that you use on other machines. This is not a problem when configuring an APPN End Node with a Network Node. The EN sends all requests to its NN, and the NN has to locate the LUNAME somewhere in the network. However, if there is no Network Node, either because the machine is running in an informal SNA network (PU 2.1 only) or when the machine is connected to a mainframe network, then it is necessary to explicitly configure each server LUNAME and associate it with a route. First, you define the LAN address or SDLC link where you want all requests sent. This would either be the machine that actually runs the service, or it must be a router to the service. In the case of a service running on the mainframe, this is the address of an NCP or communications control unit that provides a gateway to the subarea network.
There is a button to define Partner LUs. Press it to get a panel to define LUNAMEs that will be found on or through the node just defined.
Copyright 1995 PCLT -- SNA ILLOGICAL UNITS -- H. Gilbert
Return to
SNA Crossroad