|
|
|
|
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:
A subarea network is a hierarchically organized network consisting of subarea nodes and peripheral nodes. Subarea nodes, such as hosts and communication controllers, handle general network routing. Peripheral nodes, such as terminals, attach to the network without awareness of general network routing.
A peer network is a cooperatively organized network consisting of peer nodes that all participate in general network routing.
A mixed network is a network that supports both host-controlled communications and peer communications.
Solaris workstations running SNAP-IX 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:
Subarea nodes control communication and network resources for all attached nodes. SNA classifies subarea nodes according to their capabilities and the amount of control they have over other nodes:
Type 5 nodes provide SNA functions that control network resources, support transaction programs, support network operators, and provide end-user services. Because these functions are often provided by host processors, type 5 nodes are also known as host nodes. The devices and resources controlled by a type 5 subarea node constitute the domain of that node.
Type 4 nodes provide SNA functions that route and control the flow of data in a part of the network. Because these functions are often provided by communication controllers, type 4 nodes are also known as communication controller nodes.
Peripheral nodes serve subordinate roles in subarea networks. For example, a peripheral node can support 3270 emulation or dependent LU 6.2 communication. Peripheral nodes are devices such as distributed processors, cluster controllers, or workstations; they are also classified into type 2.0 and type 2.1 nodes:
Type 2.0 nodes are always controlled by a type 4 or 5 node. They cannot establish communication with other nodes without the participation of a type 4 or 5 node. Type 2.0 nodes are referred to as dependent nodes.
Type 2.1 nodes can act as dependent nodes, but they can also communicate directly with other type 2.1 nodes.
Solaris workstations running SNAP-IX 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:
A host is a mainframe computer compatible with the original IBM System/370. A host is a type 5 node.
A communication controller, also known as a front-end processor (FEP), is a separate processor attached to the host. It manages the host's communications with other computers.
A communications link connects the host site with an end-user site. The users are usually on a separate site from the host, so the two sites need to be connected by a communications link.
At the remote end of the communications link is a terminal controller, also known as a cluster controller. It is responsible for controlling the use of the link, and routes data to the terminals. The most well-known IBM terminal controllers are the 3174 and 3274.
Users run host applications or submit work to the host from terminals. The best-known IBM terminal is the 3270. A terminal can be connected through a terminal controller or directly connected to a communication controller.
Printers such as the IBM 3287 can also be attached to the terminal controller. They can receive output from the host.
As shown in SNA Subarea Network, a diagram of a subarea network looks like an inverted tree.
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 SNAP-IX. 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, SNAP-IX runs on Solaris 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:
APPN network nodes (NNs) identify the locations of network resources, determine routes for sessions between these resources, route sessions, and serve end nodes (EN) and low-entry networking (LEN) nodes directly attached to the network node. The domain of an APPN network node consists of itself and any end nodes for which it provides network services.
APPN end nodes can access remote resources without requiring that those resources be configured on the end node. An end node can communicate with adjacent nodes on its own, but requires the services of a network node server to access nonadjacent nodes. The domain of an APPN end node includes only itself.
APPN branch network nodes allow the APPN network to be separated into branches to simplify its topology and reduce network management overheads. They provide network node functions to end nodes in a branch separated from the main APPN network, while acting as end nodes in the main network itself. For more information, see Branch Extender.
Low-entry networking nodes (LEN nodes) are type 2.1 nodes that do not support APPN functions. They can communicate with adjacent nodes in an APPN network, but do not participate in the APPN network. In a LEN node, all potential sessions with remote LUs must be predefined, either specifically or through a single default entry indicating that all remote LUs reside in an adjacent network node that can be accessed using a certain link. The domain of a LEN node includes only itself.
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:
Emulation programs
File transfer
Database transaction processing
Network management
Centralized data services
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.
SNAP-IX 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.
SNAP-IX includes the following APIs on all platforms:
APPC-LU type 6.2 only
CPI-C (Common Programming Interface for Communications)-LU type 6.2 only
CSV (Common Service Verb) API
HLLAPI (high-level language application programming interface)-as part of the SNAP-IX 3270 emulation program
LUA API
In addition, SNAP-IX includes the following proprietary programming interfaces (only for Solaris systems):
For an overview of the APIs provided with SNAP-IX, 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:
Physical units (see Physical Units)
Logical units (see Logical Units)
Control points (see Control Points)
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.
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 SNAP-IX 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 Solaris operating system can communicate with a TP on an AS/400 computer as easily as it can with a TP on another Solaris workstation, as long as both TPs use the same LU type.
SNAP-IX supports the following LU types:
LU 6.2 supports program-to-program communication in a distributed data processing environment. The LU 6.2 data stream is either an SNA general data stream (GDS), which is a structured-field data stream, or a user-defined data stream. LU 6.2 can be used for communication between two type 5 nodes, a type 5 node and a type 2.0 or 2.1 node, or two type 2.1 nodes. (Type 2.1 nodes can serve as APPN nodes.)
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.
Only LU 6.2 can provide independent LU functions.
LU 3 supports application programs and printers using the SNA 3270 data stream.
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.
LU 2 supports application programs and display workstations communicating in an interactive environment using the SNA 3270 data stream. Type 2 LUs also use the SNA 3270 data stream for file transfer.
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.
LU 1 supports application programs and single- or multiple-device data processing workstations communicating in an interactive, batch-data transfer, or distributed data processing environment. The data streams used by LU type 1 conform to the SNA character string or Document Content Architecture (DCA).
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.
LU 0, an early LU definition, supports primitive program-to-program communication. Certain host database systems, such as IMS/VS (Information Management System/Virtual Storage) and some point-of-sale systems for the retail and banking industries (such as the IBM 4680 Store System Operating System) use LU 0. Current releases of these products also support LU 6.2 communication, which is the preferred protocol for new applications.
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:
On a type 5 node, the CP is called a system services control point (SSCP). It manages and controls the network resources in a subarea network. For example, an SSCP can use a directory of network resources to locate a specific LU under its control, and can establish communication between two LUs in its domain. An SSCP can also cooperate with other SSCPs to establish connectivity between LUs in different subarea domains.
The SSCP also provides an interface to network operators at the host system, who can inspect and control resources in the network.
On type 4 nodes and type 2.0 nodes in a subarea network, the control point is called a physical unit control point (PUCP).
On type 2.1 nodes, the control point provides both PU and LU functions, such as activating local link stations, interacting with a local operator, and managing local resources. It can also provide network services, such as partner LU location and route selection for local LUs.
In a subarea network, the CP on a SNAP-IX 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.
SNAP-IX is primarily concerned with the following types of sessions:
In order for two TPs to communicate, the LUs that support the TPs must first establish an LU-LU session. In general, a session is established when a TP in one SNA node tries to communicate with a TP in another node and no existing session between the LUs on the two nodes is available.
A dependent LU (see Dependent and Independent LUs) must have an active SSCP-LU session with an SSCP on a type 5 node before it can have a session with an LU in the subarea network. Once an SSCP-LU session is active, a dependent LU can solicit an LU-LU session.
Before an SSCP-LU session can be established, the PU controlling the LU must have an active SSCP-PU session with an SSCP on a type 5 node. The SSCP-PU session is used to pass control data and network management data between the PU and SSCP.
In an APPN network, adjacent nodes establish CP-CP sessions. These sessions are used to search for a resource in the APPN network and to maintain topology information (see APPN Control Point).
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.
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 (also known as an SSCP-dependent LU) requires the services of an SSCP to establish a session with another LU. An SSCP-LU session must be established before a dependent LU-LU session can be established.
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 establish sessions with other independent LUs without the aid of an SNA host. LU 6.2 is the only LU type that can be independent.
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 Multiple and Parallel Sessions. 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.
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 Communication between Transaction Programs and Logical Units, 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.
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 SNAP-IX and the TP.
In a basic conversation, data must be formatted by the TP as logical records before being presented to the SEND function.
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.
In a mapped conversation, information is passed to the SEND function as a pointer to a single, unformatted block of data; the length of the block is passed as another parameter. The block cannot be received as one or more logical records; the receiving TP must do whatever record-level formatting is required.
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:
For subarea networks, you must predefine all routes between subarea nodes.
For peer networks that do not support APPN, type 2.1 nodes can support sessions only with adjacent nodes; their sessions cannot be routed through intermediate nodes.
For APPN networks, SNA can compute routes dynamically at the time of session initiation, using a class of service specified for the mode used by the session (see Class of Service).
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.
|
|
|
 |
|