Architectural components of the SNA network

A resource in an SNA network is a network accessible unit, which is either an origin or a destination of information transmitted by the transport network (the data link control and path control layers). You already read about control points and system services control points, which are network accessible units. Other network accessible units are:

Physical units
Logical units

Physical units

Physical units are components that manage and monitor resources such as attached links and adjacent link stations associated with a node. SSCPs indirectly manage these resources through physical units.

Physical units (PUs) exist in subarea and type 2.0 nodes. (In type 2.1 peripheral nodes, the control point performs the functions of a PU.) The PU supports sessions with control points in type 5 nodes and also interacts with the control point in its own node.

A physical unit provides the following functions:

Receives and acts upon requests from the system services control point (SSCP), such as activating and deactivating links to adjacent nodes
Manages links and link stations, while accounting for the unique aspects of different link types

Logical units

End users and applications access SNA networks through logical units (LUs), which are the entry point through which users and applications access the SNA network. Logical units manage the exchange of data between end users to applications and application to application, acting as an intermediaries between the two session partners on the two endpoint LUs.

Because SNA is a connection-oriented protocol, prior to transferring data the respective logical units must be connected in a session. In SNA hierarchical networks, logical units require assistance from system services control points (SSCPs), which exist in type 5 nodes, to activate a session with another logical unit. A session between a logical unit (LU) and an SSCP is called SSCP-LU session. Control information flows from the SSCP to LU session.

A session between two logical units either in the same node or in two different nodes is called an LU-LU session. The session between two LUs is used for application data flows.

All node types can contain logical units. In SNA hierarchical networks, the logical unit has sessions with only one control point in type 5 nodes and with logical units in other nodes. A control point assists in establishing a session between its managed LU and an LU it does not manage in a different node.

Figure 1 shows LUA, which is managed (owned) by the SSCP in HOSTA and is in session with an application in HOSTB that is not the host that manages the LU.

The control point assists in establishing the session between the two LUs and does not take part in the data transfer between the two LUs.

Figure 1. LU-LU and SSCP-LU session

Logical unit types

SNA defines different kinds of logical units called LU types. LU types identify sets of SNA functions that support end-user communication. LU-LU sessions can exist only between logical units of the same LU type. For example, an LU type 2 can communicate only with another LU type 2; it cannot communicate with an LU type 3.

The LU types that SNA defines, the kind of configuration or application that each type represents, and the hardware or software products that typically use each type of logical unit are listed here:

LU type 1

This is for application programs and single-device or multiple-device data processing workstations communicating in an interactive or batch data transfer. An example of the use of LU type 1 is an application program running under IMS™ and communicating with a 3270 printer.

LU type 2

This is for application programs and display workstations communicating in an interactive environment using the SNA 3270 data stream. An example of the use of LU type 2 is an application program running under IMS and communicating with an IBM® 3270 display station at which an end user is creating and sending data to the application program.

LU type 3

This is for application programs and printers using the SNA 3270 data stream. An example of the use of LU type 3 is an application program running under CICS/VS and sending data to a 3270 printer.

LU type 6.2

This is for transaction programs communicating in a client/server data processing environment. The type 6.2 LU supports multiple concurrent sessions. LU 6.2 can be used for communication between two type 5 nodes, a type 5 node and a type 2.1 node, or two type 2.1 nodes.

Examples of the use of LU type 6.2 are:

An application program running under CICS® in a z/OS® system communicating with another application program running under CICS in another z/OS system.
An application program in a Microsoft® Host Integration Server (HIS) or AIX® Communications Server communicating with a CICS in a z/OS system.

LU types 1, 2, and 3 are referred to as dependent LUs. An SSCP-dependent LU (or simply dependent LU) requires assistance from a system services control point (SSCP) in order to activate an LU-LU session; therefore, it requires an SSCP-LU session. All non-6.2 LUs are dependent; some type-6.2 LUs are dependent and some are independent. A type 2.0 node supports only dependent LUs. A type 2.1 node can support any combination of dependent and independent LUs.

LU 6.2 can act either as a dependent or independent LU. An SSCP-independent LU (or simply independent LU) is able to activate an LU-LU session (that is, send a BIND request) without assistance from an SSCP; therefore, it does not have an SSCP-LU session. Only a type-6.2 LU can be an independent LU. A type 2.1 node supports independent-LU protocols to other directly-attached independent LUs in type 2.1 nodes.

SNA messages

In an SNA network, messages flowing through the network contain either a request or a response. Requests are message units that contain:

End-user data, called data requests. Examples of end-user data include payroll data, personnel data, insurance policy data, and inventory data.
Network commands, called command requests. Network commands initiate and terminate sessions and control communication between network accessible units.

Responses are message units that acknowledge the receipt of a request. Responses are either positive or negative.

Positive responses indicate that a request was received and is acceptable.
Negative responses indicate that a request was received, but is unacceptable; they also contain error codes that explain why the request is unacceptable.