2 Feb 1995

XID (Defining Nodes and Connections)

The best designed network must still recovery from mistakes when some telephone repair crosses the wires and a Teller Machine is now connected to what used to be a printer port. To address this problem, SNA expands on the eXchange ID (XID) message. A trivial version of XID is required by the international standards for all devices connected to a LAN or a phone line. The original SNA made slight extensions to XID, and APPN substantially extended it. Understanding the XID exchange when two SNA nodes first connect can explain important parameters used to define each node.

There are two categories of SNA devices. The older "dumb" devices (printers and terminals) are limited to certain commands and operations. SNA design protects such devices from receiving inappropriate requests. More modern devices are more flexible, so APPN may need to verify the identity of a peer node.

SNA communication occurs between two nodes connected by a LAN or by an SDLC link. LAN connections use the IEEE 802.2 standard for message formats. Both SDLC and IEEE 802.2 define an XID message. There is a short form with just the XID command itself, and a longer version that can contain vendor specific extensions. XID is always a valid operation. If an XID is transmitted and no reply is received, the other node is not communicating.

Messages on a LAN are addressed by a six byte "MAC address" in the message header. While other protocols (NETBEUI, IPX, IP) locate a server computer by broadcasting a message to all machines on the network, SNA messages are only sent to designated machines. This means that either the end user or the system administrator must configure every SNA workstation with the LAN addresses of other SNA nodes. In the APPN network, each End Node is just configured with the address of its Network Node, and the Network Node knows all the other addresses.

SDLC lines are technically obsolete. New IBM equipment is replacing them with Frame Relay. However, there are still an enormous number of SDLC lines in use. On an SDLC line, each station was identified by a one-byte poll address.

So each SNA node will be configured with a set of LAN addresses and/or a set of SDLC lines that represent a connection to specific other network nodes. When the node starts up, it sends a short-form XID to each node just to see if the other machine is running. A connection between peers can be established only when both nodes are ready. A connection to the mainframe network can be established only when the mainframe operator enables it.

If the short form of the XID has been successfully exchanged, then a longer SNA XID follows. The mainframe-based subarea network uses a form of XID that contains an identifying number: a 4 byte value split into two fields. The first 12 bits (3 hex digits) are a product ID (called IDBLK in VTAM). The product ID for OS/2 is, for example, "05D" and it is not subject to reconfiguration. The last five hex digits (called the IDNUM in VTAM) are any number uniquely assigned to this node by the network administrators.

A old dumb node is classified by SNA as a "PU 2.0" while a new peer node is a "PU 2.1". The "PU" part standard for Physical Unit, but this is where IBM begins to screw things up big-time.

A PU 2.1 does not have a PU.

In the official SNA definition of terms, a Physical Unit is the component that manages a node on behalf of the mainframe. When PC's, workstations, and minicomputers connect over APPN SNA, there is no mainframe involved and, therefore, (from the precise, legal definition of the SNA manuals) there is no Physical Unit. In common use, ordinary people will use the term "Physical Unit" to refer to any box that is a node on the SNA network, but this is not technically correct use of the term.

APPN nodes have something else called a CP (Control Point). What is the difference? To ordinary people, the terms "PU" and "CP" are interchangeable. There is one "gotcha" worth considering. No matter what most people may think, the Physical Unit name does not flow as data through the network. PUNAME is not part of the XID, BIND, or any other mainstream SNA message. It may appear in network management traffic (alerts, NETVIEW), but it is never checked. The CPNAME, on the other hand, is exchanged as part of the APPN XID.

All this comes together for a few seconds when the workstation programmer is asked to configure node information. The same data is needed on all operating systems, but the OS/2 communications manager is the nicest looking:

There are fields to define both the CPNAME (called the Local Node Name) and the numeric Node ID. The values entered into these fields are important only if this machine must talk directly to another node configured to check them. The Network ID (NETID) is a bit more complicated. It is explained in a separate document .

The VTAM parameters dataset on the mainframe identifies remote nodes through a "PU" definition statement. This definition can identify an APPN node by CPNAME and it can identify any node by number ("IDBLK=05D,IDNUM=xxxxx"). Some levels of VTAM require that one of these values be coded for every remote node. If this is true, then the workstation should be defined with the values that the mainframe programmer has assigned.

Mainframes tend to be heavy on management and security. Peer workstations (RS/6000, OS/2) tend to be more laid back. These machines often will not check the CPNAME of another peer workstation, even when that name has been configured. Nevertheless, it is generally a good idea, and not much effort, to get the names straight everywhere. In OS/2, the CPNAME configured on the Node Information panel of the other machine should be configured as the Partner Node on this machine (and conversely).

This example shows a connection to another machine named OTTO. Since this is a LAN connection, the six byte MAC address of OTTO is entered into the panel. The Address Format indicates if the value is interpreted high bit first (Token Ring) or low bit first (Ethernet). On the OTTO node, this machine will be configured as a partner with (from the previous panel) CPNAME "GILBERT".

In summary, in order to talk to another SNA node directly, it is necessary to configure the hardware address of that node into the network definition tables. When this node starts up, it sends a simple XID to see if the partner node is up. If it is, it sends a more complicated SNA-only XID.

Old SNA nodes were identified by a number that indicated the type of IBM product and contained a serial number. VTAM could be configured to check this number and reject any device with a bad ID (presumably because it had been misconnected or the phone lines were switched).

Newer APPN SNA assigns a name to workstations. The name will be placed in the SNA XID. Some systems will be configured with their partner names and will check the XID value to make sure that the name presented matches their configuration tables. However, workstations frequently do not check this field and assume that any node that has the correct LAN address of a partner device must be OK no matter what CPNAME it chooses to use.

Return to SNA Crossroad

Copyright 1995 PCLT -- XID (Defining Nodes and Connections) -- H. Gilbert

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