Interoperability with IBM Host Systems
Interoperability with IBM Host Systems |
|
Once you have determined a suitable deployment model and subdomain configuration, you must determine:
This section explores how to connect computers running SNA Server to IBM mainframe and AS/400 host systems.
In SNA Server terms, a host connection is the data communications path between SNA Server and a host system. For a mainframe, this connection corresponds to a physical unit definition in the Virtual Telecommunications Access Method (VTAM). A physical unit (PU) is a combination of hardware and software that provides the services needed to use and manage a particular device. On the AS/400, this connection corresponds to an Advanced Program-to-Program Communications (APPC) controller definition. For more information about IBM host connection methods and other background information about SNA networking, see "IBM SNA Interoperability Concepts" in this book.
For each physical adapter or connection, an appropriate link service is installed and configured within SNA Server. The link service is a Windows 2000 service or device driver that is used to control server-to-host communication adapters supported by SNA Server. Once configured, the link service is available for use not only on the configured SNA Server, but on any SNA Server in the subdomain using the Distributed Link Service feature of SNA Server.
Once you configure your link services, you create connections over a defined link service. As mentioned previously, a connection is the data communication path between a computer running SNA Server and the IBM host. Using a host connection, a client computer on a LAN can communicate with the mainframe system. For some link services, it is possible to define multiple connections over a single host link.
In SNA terms, the combination of a connection and the link service it uses is equivalent to a PU. In SNA networks, SNA Server provides PU 2 or PU 2.1 functionality similar to a cluster controller. For more information about cluster controller functions, see "IBM SNA Interoperability Concepts" in this book.
To understand the connectivity options, you should first examine the different physical connections and network protocols that SNA Server supports. Table 10.5 summarizes all common connection methods that can be used with SNA Server.
Table 10.5 SNA Server-to-Host Connection Methods
| Method | Throughput | Characteristics |
|---|---|---|
| Token Ring 802.2 Data Link Control (DLC) | 4 or 16 Megabits per second (Mbps) | Mainframe or AS/400.
Midrange performance using DLC protocol. Supports multiple host connections using a single adapter. Easy and inexpensive to implement. Suitable for a wide range of purposes. |
| Standard Ethernet 802.2 DLC | 10 Mbps | Mainframe or AS/400.
Midrange performance using DLC protocol. Supports multiple host connections using a single adapter. Easy and inexpensive to implement. Suitable for light to medium network traffic conditions. Ethernet contention can degrade performance under heavy loads. |
| Fast Ethernet 802.2 DLC | 100 Mbps | Mainframe or AS/400.
High performance using DLC protocol. Supports multiple host connections using a single adapter. Easy and inexpensive to implement. Suitable for higher performance connections. Ethernet contention can degrade performance under heavy loads. |
| Fiber Distributed Data Interface (FDDI) 802.2 DLC | 100 Mbps | Mainframe or AS/400.
High performance using DLC protocol. Supports multiple host connections using a single adapter. Relatively expensive to implement. Suitable for higher performance connections. |
| Synchronous Data Link Control (SDLC) | 9,600 - 19,200 bps | Mainframe or AS/400.
Generally low performance using SDLC protocol. Supports 256 sessions over a single host connection. Easy and inexpensive to implement. Suitable for low-traffic WAN connections. |
| X.25 | 9,600 - 19,200 bps | Mainframes and AS/400.
Generally low performance using Qualified Logical Link Control (QLLC) protocol. Supports 256 sessions over a single host connection. Easy and inexpensive to implement. Suitable for low-traffic WAN connections. |
| Distributed Function Terminal (DFT) | 2.35 Mbps | Mainframes only.
Low to midrange performance. Supports only five sessions over a single host connection. Inexpensive. Suitable for test environments or small networks with an existing DFT-based infrastructure. |
| Twinax | 1 Mbps | AS/400 systems only.
Low performance. Supports five sessions over a single host connection. Inexpensive. Suitable for AS/400 host environments with an existing Twinax infrastructure. |
| Channel - Bus & Tag | 4.5 megabytes per second | Mainframes only.
High performance. Supports a high number of host connections.. Expensive. Suitable for high-performance connections. |
| Channel - ESCON | 17 megabytes per second | Mainframes only.
Highest performance. Supports a high number of host connections. Expensive. Suitable for conditions where maximum throughput is required. |
When you choose a connection method, you should keep in mind several factors:
In general, a high-speed Token Ring connection is a good choice when the same connection is used to connect a LAN to an SNA network that includes both a mainframe and AS/400 system. For greater performance in a dedicated mainframe environment, channel-type connections are generally recommended.
For some link services, multiple host connections are possible using a single adapter, most notably DLC and channel-type link services. Each instance of SNA Server supports up to 250 host connections, and up to four instances of SNA Server are supported on a single computer.
The hierarchical SNA network model provides access to a centralized processing resource from elements throughout the network. This model is most frequently associated with mainframe environments in which centralized applications are accessed from remote terminals across a network.
Devices in a hierarchical SNA network, such as terminals or cluster controllers, are called physical units (PUs). Each class of device is designated by a number. For example, the mainframe itself is known as a PU 5 device. For background information about hierarchical SNA networks, see "IBM SNA Interoperability Concepts" in this book.
SNA Server participates in a hierarchical SNA network by emulating a standard IBM PU 2, or cluster controller, and multiple LUs, which are protocols that provide a standardized format for delivery of data for specific applications, of type LU 0, LU 1, LU 2, and LU 3. This allows client computers that emulate IBM terminals and applications to communicate with the IBM host (PU 5).
SNA Server can connect to a mainframe computer in one of two ways: either directly to the PU 5, the host; or through a PU 4, a front-end processor (FEP).
You can make a direct physical connection (a connection that does not involve an FEP) between computers running SNA Server and a mainframe system using any of the following physical connection methods:
Indirect physical connections between SNA Server–based computers and a mainframe system (connections through an FEP) are also supported. These connections might be easier to implement depending on your existing infrastructure and the physical proximity of the computers running SNA Server to the mainframe. For this type of connection, one of the following methods can be used:
Figure 10.5 illustrates both direct and indirect physical connections to a mainframe.
Figure 10.5 Direct and Indirect Physical Connections to a Mainframe
In a hierarchical SNA network, SNA Server emulates a cluster controller and supports all standard protocols:
Any combination of these protocols can be used over a given physical connection, as illustrated in Figure 10.6.
Figure 10.6 Logical Connections to a Mainframe
In the peer-oriented SNA network model, all computers on the network can communicate directly with each other. Advanced Peer-to-Peer Networking (APPN) is the architecture developed by IBM that enables distributed data processing. APPN defines how components communicate with each other, and the level of network-related services, like routing sessions, that are supplied by each computer in the network. For background information about SNA APPN, see "IBM SNA Interoperability Concepts" in this book.
In an APPN network, SNA Server emulates a type 2.1 physical unit device (PU 2.1). SNA Server operates as an APPN low entry network (LEN) node and communicates with other APPN nodes using the Advanced Program-to-Program Communications (APPC) or LU 6.2 protocol.
Computers running SNA Server can connect directly to an AS/400 using several connection methods, as shown in Figure 10.7:
Figure 10.7 SNA Server Connections in a Peer-Oriented Network
After your SNA Server–based computer-to-host connection is determined, you must choose the protocol or protocols to use for two additional SNA Server communication paths: between clients and SNA Server–based computers, and between different SNA Server–based computers.
You can use one protocol for both, or you can use a combination of different protocols, provided that all servers share at least one client/server protocol and use it for server-to-server communication.
Deploying a single protocol across your WAN is the easiest way to manage your network communications.
However, you might decide to gradually implement SNA Server throughout your enterprise. In this case, you need to use existing protocols for certain connections. For example, you could use TCP/IP for server-to-server communications and use IPX/SPX for client-to-server communications. Similarly, other combinations of supported protocols can be used, provided that all the SNA Server–based computers share one protocol and use that protocol for server-to-server and client-to-server communication.
Computers running SNA Server Client software can communicate through a number of LAN protocols:
TCP/IP is quickly becoming the standard network protocol for client/server applications. Its high performance and support for sophisticated routing features make it suitable for many WAN environments. In many cases, TCP/IP is the best protocol choice for your network, especially if TCP/IP is already deployed to some degree in the LAN segment on which servers and clients running SNA Server reside.
If you deploy TCP/IP, it is recommended that you assign static IP addresses to SNA Server–based computers because it is easier to administer workstations that have a fixed SNA Server address. For computers that run SNA Server Client software, you can use the Dynamic Host Configuration Protocol (DHCP) to dynamically allocate client IP addresses without difficulty.
For more information about TCP/IP and DHCP, see the Microsoft® Windows® 2000 Server Resource Kit TCP/IP Core Networking Guide.
SNA Server Client software allows workstations to support SNA Server advanced host integration features. SNA Server Client software also provides application programming interfaces (APIs) that are used by third-party vendors to gain access to IBM host systems and applications. Third-party vendors provide 3270 and 5250 terminal emulators and additional host integration utilities.
SNA Server Client software creates network transport independence, allowing clients and applications to communicate using any of SNA Server's programmatic interfaces.
At this time, client software is available for the following platforms:
Note
SNA Server Client software is not required for clients that use TCP/IP for services such as TN3270, TN5250, and AFTP. Applications, such as TN3270 emulators, communicate directly with these services rather than using the SNA Server client/server interface.
For information about the host communication services and SNA application programming interfaces that SNA Server can support for each client platform, see "Heterogeneous Clients Services" later in this chapter.
Computers running SNA Server can communicate with each other using any of the following methods:
For more information about configuring protocols and optimizing server-to-server network traffic, see the SNA Server version 4.0 documentation.
