View figure.
SNA defines the standards, protocols, and functions used by devices--from mainframes to terminals--to enable them to communicate with each other in SNA networks.
SNA functions are divided into a hierarchical structure of separate layers, each performing a specific set of functions. This division of network functions into layers enables network devices to share information and processing resources without having detailed information about each device on the network. A user at a workstation can communicate with another user without knowing anything about the physical devices on the network or the connections between those devices.
SNA supports the following types of networks:
| Note: | AIX workstations running CS/AIX can act as a peripheral node in a subarea network, as a peer node in a peer network, or both at the same time. |
In SNA networks, a node is a system, workstation, or other device--with associated software components--that implements SNA protocols and has at least one communication path to another node in the network. Each node manages its end of the network communication paths, and uses SNA protocols to communicate with the node at the other end of each path.
Because subarea networks and peer networks define the relationships among nodes differently, they also use different terms for node types (to describe the roles that nodes play in the network).
SNA subarea networks support the following node types:
| Note: | AIX workstations running CS/AIX can function as type 2.1 or type 2.0 nodes. |
A type 4 or 5 subarea node to which a peripheral node is attached acts as a boundary node. It performs a boundary function by translating between the network addresses used by a subarea node and the local addresses used by a peripheral node.
A simple subarea network includes the following components:
As shown in Figure 1, a diagram of a subarea network looks like an inverted tree.
| View figure. |
The root of the tree (at the top of the diagram) is the computer controlling the network. The branches are the communications links from the host to the other computers in the network (terminal controllers); the leaves (at the bottom of the diagram) are the terminals or printers attached to these computers, which are accessed by users.
The traditional subarea SNA set-up described here enables the users to use the resources of a single host system. The terminals provide only simple data entry and display functions to and from the terminal controller; the terminal controller is responsible for handling SNA communications between the terminals and the host.
The terminal controller and its terminals can be replaced by an SNA node using a product such as CS/AIX. From the host's point of view, the node appears as a terminal controller. However, it provides the users with additional functions, such as the ability to access more than one host system and facilities for customizing screen displays. In addition, CS/AIX runs on AIX computers that can also be used for other tasks not related to SNA (unlike the terminal controller, which is used solely for communications with the host).
Peer networks do not classify nodes hierarchically, as is done in a subarea network. Exchanges with other nodes are not controlled by a host or other centralized processor. Instead, any node can establish communication with any other node.
A peer network is composed of type 2.1 nodes. The nodes in a peer network can serve the following roles:
For more information about peer-oriented node types, see APPN Node Types.
For two nodes to communicate, each node must have a combination of hardware and software that supports data flow between the nodes. The hardware component consists of an adapter at each node and the transmission medium that connects the two adapters. The software component provides control of the hardware and the data exchanged over it.
Each node connected to a network has one or more link stations, which are the hardware and software in a node that control data flow to a specific adjacent node. To establish communication between two adjacent nodes, one of the link stations must first activate the link between the nodes.
Programs that exchange information across the SNA network are called transaction programs (TPs).
Following are examples of application programs that can include SNA TPs:
The TP accesses the network through a logical unit (LU) that establishes and maintains a session with a partner LU on another node. For more information about logical units, see Logical Units.
| Note: | CS/AIX includes sample TPs for most supported APIs. For more information on sample TPs, refer to the programmer's guide for the API. You can also purchase SNA TPs as part of other products or create your own TPs (see Application Programming Interfaces). |
SNA TPs are written using application programming interfaces (APIs). APIs provide specific subroutines that enable SNA TPs to access SNA functions, such as those for exchanging data and performing control functions. These subroutines enable an SNA TP to communicate with another SNA TP on a remote node.
CS/AIX includes the following APIs:
In addition, CS/AIX includes the following proprietary programming interfaces:
The following back-level APIs are included to provide support for existing TPs. Because these APIs may not be supported in future releases, it is recommended that you do not develop new applications using these APIs:
For an overview of the APIs provided with CS/AIX, see Application Programming Interfaces.
Communication between a TP and the SNA network occurs through network accessible units or NAUs (formerly called "network addressable units"), which are unique network resources that can be accessed (through unique local addresses) by other network resources.
SNA provides the following types of NAUs:
| Note: | Because TPs are considered users of the network, not components, they are not classified as NAUs. |
Each SNA node contains a physical unit (PU). The PU manages resources (such as link resources) and supports communication with a host.
| Note: | On type 2.1 nodes (which can be APPN nodes), the control point provides PU services in addition to providing other services (see Control Points). Two type 2.1 nodes (such as CS/AIX nodes) can communicate directly, without requiring the services of a host to establish communications. |
Each SNA node contains one or more logical units (LUs). An LU provides a set of functions that are used by TPs and end users to provide access to the network. LUs communicate directly with local TPs and devices.
SNA defines several types of LUs, each optimized for a specific class of applications. LUs of different types cannot communicate with each other, but LUs of the same type can communicate even though they reside on different kinds of systems.
For example, a TP running on a workstation that uses the AIX operating system can communicate with a TP on an AS/400 computer as easily as it can with a TP on another AIX workstation, as long as both TPs use the same LU type.
CS/AIX supports the following LU types:
This LU type provides more functions and greater flexibility than any other LU type. Unless you are constrained by existing hardware or software, LU 6.2 is the logical choice when developing new applications.
| Note: | Only LU 6.2 can provide independent LU functions. |
For example, LU 3 can support an application program running under Customer Information Control System (CICS) and sending data to an IBM 3262 printer attached to an IBM 3174 Establishment Controller.
For example, the LU 2 protocol can support 3270 emulation programs, which enable workstations to perform the functions of IBM 3270-family terminals. In addition, LU 2 is used by other programs to communicate with host applications that normally provide output to 3270 display devices. Such TPs enable the workstation to achieve a form of cooperative processing with the host.
For example, LU type 1 can support an application program running under Information Management System/Virtual Storage (IMS/VS) and communicating with an IBM 8100 Information System. This enables a workstation operator to correct a database that the application program maintains.
Applications that use LU 1 are often described as remote job entry (RJE) applications.
| Note: | For information about the data streams used by SNA logical units, refer to Systems Network Architecture Technical Reference. |
A control point (CP) is an NAU that manages network resources within its domain, controlling resource activation, deactivation, and status monitoring. The CP manages both physical resources such as links, and logical information such as network addresses.
SNA defines the following types of network control points:
The SSCP also provides an interface to network operators at the host system, who can inspect and control resources in the network.
In a subarea network, the CP on a CS/AIX node acts as a type 2.0 PU. It communicates with an SSCP on a host and does not communicate with other CPs in the subarea network.
When participating in an APPN network, the CP exchanges network control information with the CPs in adjacent nodes. The CP can also function as an independent LU of type 6.2. The CP acts as the default LU for TPs on the local node. For more information about the APPN control point, see APPN Control Point.
NAUs communicate with NAUs in other nodes over temporary logical communication channels called sessions. Before two TPs can communicate, their LUs must establish a session. The LU that manages the session on the local node is the local LU; the LU that manages the session on the remote node is the partner LU.
CS/AIX is primarily concerned with the following types of sessions:
Logical units have attributes that determine how they interact during LU-LU sessions. These attributes are determined by the architecture of SNA. LUs can be primary or secondary, and dependent or independent.
To establish a session, one LU requests session activation by sending a BIND request to another LU:
Peer networks do not use a fixed hierarchy of nodes and do not have predetermined primary or secondary LUs.
| Note: | In a peer network, an independent LU that is participating in multiple sessions (see Multiple and Parallel Sessions) can act as a primary LU for one session and a secondary LU in another. |
All type 0, 1, 2, and 3 LUs are dependent LUs. Type 6.2 LUs can be configured as either dependent or independent LUs.
A dependent LU can be in session only with LUs on an SNA host. Because of this restriction, dependent LUs usually use subarea networks (also known as host-mediated networks). However, the dependent LU requester (DLUR) function enables session traffic from dependent LUs to flow over APPN networks. For more information about DLUR, see Accessing Subarea Networks from APPN Networks.
A dependent LU on a peripheral node is always the secondary LU.
An independent LU can act as a primary or as a secondary LU when establishing a session.
An independent LU can participate in sessions with more than one remote LU at the same time (multiple sessions).
An independent LU can also participate in parallel sessions, or multiple concurrent sessions with the same remote LU.
Dependent LUs (including dependent LU 6.2) cannot have multiple sessions.
LUs with multiple and parallel sessions are shown in Figure 2. LUA and LUB have parallel sessions. LUA also has multiple sessions: two with LUB and one with LUD. LUD has multiple sessions with LUA and LUC.
Figure 2. Multiple and Parallel Sessions
 View figure. |
This section applies to LU 6.2 only.
Once a session is established between two LUs, the LU-LU session supports the exchange of information between two TPs, which have the exclusive use of the session to execute a transaction. This exchange of information is called a conversation. Only one conversation can use a particular session at a time, but sessions are serially reusable (many conversations can use the same session, one after another).
To initiate a conversation, a source TP sends a request to its LU, asking it to allocate a conversation with a remote TP. The invoking TP (or source TP) initiates the conversation, like the calling party in a telephone conversation. The invokable TP or target TP (the remote TP) is the partner in the conversation, like the party who receives a telephone call.
As shown in Figure 3, information is exchanged between TPs and LUs to enable one node to communicate with another. Although the TPs appear to be communicating directly, the LUs on each node are the intermediaries in every exchange.
Figure 3. Communication between Transaction Programs and Logical Units
 View figure. |
SNA defines two types of conversations: basic and mapped. These two types of conversations use different methods to indicate the length of transmitted or received data packages to be passed between CS/AIX and the TP.
A logical record consists of a two- or four-byte header starting with a two-byte length field, often represented as "LL," followed by up to 32,765 bytes of data. Logical records can be grouped together and sent as a block, transmitting more than one logical record with a single call to the SEND function.
Each LU-LU session has an associated mode that defines a set of session characteristics. These session characteristics include pacing parameters, session limits (such as the maximum number of sessions between two LUs), message sizes, and routing parameters.
Each mode is identified by a unique mode name. The mode name must be the same on all SNA nodes that use that mode.
To establish an LU-LU session, a route must be calculated between the nodes where the two LUs reside. A route is an ordered sequence of links and nodes that represents a path between the two nodes.
SNA networks support the following methods of route selection:
The High-Performance Routing (HPR) feature of APPN provides the following functions:
Class of service (COS) is a definition of the transport network (data link control and path control) characteristics--such as route security, transmission priority, and bandwidth--that the local node can use to establish a particular session. The COS definition assigns relative values to factors such as acceptable levels of security, cost per byte, cost per connect-time, propagation delay, and effective capacity.
In a subarea network, a COS is derived from the mode associated with a session, as defined in the host system.
APPN network nodes use the COS to compute session routes between independent LUs. For more information about session routing in APPN networks, see Session Routing.