SNA is a data communications architecture developed by IBM to specify common conventions for communication between various IBM hardware and software products. It is specifically designed to address issues of reliability and flexibility of sharing data between components and their peripherals. Many vendors other than IBM also support SNA, allowing their products to interact with SNA networks.
An addressable unit on an SNA network is called a node, and is made up of four functional components forming a hierarchy.
To establish a communications session, SNA uses Logical Units (LUs) as entry points into the network. There are several types of LUs, currently type 0 through type 6.2. Most of the LU types are specific to IBM operating environments, but type 6 is intended for use in a distributed data processing environment.
Generally, an LU can communicate only with another LU of the same type, but specific exceptions to this rule exist with type 6.2. LU6.2 is the least-restrictive of the various LU types, and also supports multiple concurrent sessions. As a result, it is the LU most widely supported by other system vendors.
Like the OSI model, SNA functions are divided into seven hierarchical layers, but the layers are not identical. The Transport Network handles the lower three layers, while the Network Accessible Units (NAU) implement the upper four layers by using the services of the Transport Network to establish communication between nodes.
SNA defines formats and protocols between these layers that allow equivalent layers in different nodes to communicate with each other. Also, each layer provides services to the layer above, and requests services from the layer below.
SNA uses a standard method for the exchange of data within a network. This standard method defines how to establish a route between components, how to send and receive data reliably, how to recover from errors, and how to prevent flow problems.
Originally designed for networks in which a mainframe computer controls the communications relationships, SNA has since evolved to incorporate protocols and implementations to allow two user processes to communicate with each other directly. These two different networking models, or roles, are referred to as hierarchical and peer-oriented, respectively. The peer-oriented model is designed to allow distributed control of the communications process independent of the mainframe.
The peer-to-peer connection between two user processes is known as a conversation, while the peer-to-peer connection between two LUs is known as a session. A session is generally a long-term connection between two LUs, while a conversation is generally of shorter duration.
A User Process is also known as a Transaction Program (TP). Also, the interface between a User Process and an LU is known as Presentation Services.
LU 6.2, also known as APPC (Advanced Program-to-Program Communication), is used for Transaction Programs communicating with each other in a distributed data processing environment. In a CPIC (Common Programming Interface for Communications) implementation, CPIC provides the API that contains the commands, known as verbs, that are used by LU 6.2 to establish communication sessions.
Two types of Presentation Service interfaces are possible with LU6.2: mapped conversations and unmapped, or basic, conversations. The following table summarizes the set of LU6.2 commands for basic conversations. Equivalent commands for mapped conversations have the prefix <MC_> added to the command name. Note that “control operator verbs” are not listed.
Table 1 LU6.2 Commands
Name |
Description |
---|---|
ALLOCATE |
Allocates a conversation with another program. |
CONFIRM |
Sends a confirmation request to the remote process and waits for a reply. |
CONFIRMED |
Sends a confirmation reply to the remote process. |
DEALLOCATE |
De-allocates a conversation. |
FLUSH |
Forces the transmission of the local SEND buffer to the other LU. |
GET_ATTRIBUTES |
Obtains information about a conversation. |
PREPARE_TO_RECEIVE |
Changes the conversation state from SEND to RECEIVE. |
RECEIVE_AND_WAIT |
Waits for information (either data or confirmation request) to be received from the partner process. |
RECEIVE_IMMEDIATE |
Receives any information that is available in the local LU’s buffer, but does not wait for information to arrive. |
REQUEST_TO_SEND |
Notifies the partner process that the local process wants to send data. When a “send” indication is received from the partner process, the conversation state changes. |
SEND_DATA |
Sends one data record to the partner process. |
SEND_ERROR |
Informs the partner process that the local process has detected an application error. |