2 Feb 1995

PU 2.1

Systems Network Architecture was first developed to provide reliable, secure communications on centrally managed nationwide networks for the largest US companies. The central network was based on dedicated controllers running a program called the NCP. Since minicomputers were controlled, managed, and programmed by end users, they were not allowed to be part of the trusted central network. A minicomputer could contain client and server programs. It could be the source or destination of messages. But it could not route messages on behalf of other machines and could not participate in network management.

Workstations and PC's inherited the minicomputer role as a "peripheral node." As the name suggests, such a node is outside the network itself. The architecture called for a layer of protection between the peripheral nodes and the NCP's called "boundary function." For example, the peripheral node could not generate or even see real network addresses. The NCP stripped the network address off each message and replaced it with a one byte token before passing it through the boundary to a peripheral node. This ensured that the minicomputer could not generate counterfeit messages or communicate with anyone except through session permitted and established by the mainframe.

IBM began to number the node types. A mainframe was a Type 5 node, an NCP was type 4, and peripheral nodes were Type 2. In some notation, this became "PU 2." While the mainframe was very important, IBM also sells minicomputers. In recent years, the AS/400 systems have been a monster hit. Networks of minicomputers are essential, but if SNA required a mainframe then the smaller IBM customers would be forced to use other protocols. The compromise was to permit two minicomputers to exchange data over a modified version of the SNA protocols called "PU 2.1". The traditional behavior of peripheral nodes was then renamed "PU 2.0" to avoid confusion.

Traditional SNA and PU 2.1 share a common vocabulary. However, the rules are entirely different. Image walking through a Contract Bridge tournament past a table where they are playing Seven Card Stud. Bridge and Poker use the same deck of cards, but they are not different versions of the same game. In the same sense, mainframe SNA and PU 2.1 share common message names, but they have two types of XID, two types of BIND, two meanings to LUNAME, and entirely different rules for node management, network management, and routing.

In the classic SNA network, a PU 2 node may not communicate until it receives an "Activate PU" message from the mainframe. Each individual terminal may not communicate until it receives an "Activate LU" message. Nodes and terminals are generally activated automatically when the network starts up. Otherwise, they are activated in response to an operator command. SNA calls them Dependent LU's because they need a mainframe to operate. All 3270 sessions are base on the Dependent LU rules.

A PU 2.1 node and its programs require no message from the host. They activate themselves and can immediately transmit requests on LAN or SDLC (modem) connections. Two PU 2.1 nodes first eXchange ID (XID) to swap node names and configure basic parameters (maximum message size, etc.). They can then create sessions. SNA refers to these programs as Independent LU's. It is an implementation decision to limit Independent LU's to programs using the APPC (LU 6.2) protocol.

The 3270 user generally believes that by issuing the command to Logon to the host, he or she initiates the session. In technical SNA terms, however, the Logon message is sent to VTAM. The session does not begin until the application program, having been told by VTAM about the Logon, responds by sending a BIND message to the terminal. In classic SNA, the dependent LU cannot send a bind and therefore cannot start a session.

Under the PU 2.1 rules, a client program in any machine simply sends a BIND message to a server program on any other node. The name is the same, but the PU 2.1 BIND is a different message format than the one sent by a mainframe program. If the server accepts the BIND, then a session is established.

The PU 2.1 protocol does not state how the client knows which node contains the server program. IBM refers to a node that runs only PU 2.1 by itself as a LEN. Generally, LEN requires the user to configure a table that associates each LUNAME with a node and its link or address.

In classic SNA, each display, printer, and application program has a Network Address number. Messages flow through the network from node to node based on the Network Address of their ultimate destination.

In PU 2.1, each session has a Session ID. When the BIND is processed, the Session ID is associated with a route from node to node through the network between the client and the server. Messages flow on that session. If the two programs establish a second session with a second BIND, it will acquire a completely different session ID, and (though this is unlikely in practice) all of its traffic could be sent over a different route. The Session ID is local to a particular pair of nodes. There is no way to determine from this local session ID where the message started or where it is going. At each point, the session ID only indicates the next node to which the message will be sent.

PU 2.1 opened the door a crack, then the AS/400 designers blew it wide open. Using just the minimal function permitted here, the minicomputer programmers created APPN. In APPN, there are communication subsystems on each minicomputer. When a system comes up, its local subsystem establishes some utility sessions with the subsystems on adjacent nodes. The minicomputer now uses these sessions to create a distributed directory of services, to determine the routing to any node or to external networks, and to provide basic network management.

For many years, the IBM Communications Division maintained the fine distinction that while "PU 2.1" was part of SNA, "APPN" was just something that AS/400 computers did among themselves and was outside the architecture. However, as minicomputers and workstations became more common, and as large companies began to look for ways to "downsize," this distinction became insupportable. APPN was clearly a design with a future, while classic SNA was a legacy system that needed to be preserved but would not address future needs.

IBM rolled APPN into SAA as part of "Common Communication Services". The original PU 2.1 behavior was reclassified as LEN (Low End Networking). An LEN node has no communications subsystem and exchanges no supervisory messages, but it can do the XID and BIND. Today, PU 2.1 is buried in the much larger and more complicated APPN documentation.

Summarizing PU 2.1 (and excluding the APPN function added on top of it):

Return to SNA Crossroad

Copyright 1995 PCLT -- PU 2.1 -- H. Gilbert

This document generated by SpHyDir another fine product of PC Lube and Tune.