This chapter provides an overview of the communications functions supported by Communications Server and of the methods that you can use to configure your systems to accomplish these functions. Later chapters in this book describe the functions and the configuration methods in more detail.
This section describes the following Communications Server functions:
Communications Server can act as a Systems Network Architecture (SNA) type 2.0 and SNA type 2.1 node. This support lets you write programs to communicate with many other IBM SNA products.
Communications Server provides Advanced Peer-to-Peer Networking (APPN) end node and network node support for workstations, enabling them to communicate more flexibly with other systems in the network. Additionally, a branch extender function enables you to isolate branches to avoid unnecessary CP-CP traffic.
Communications Server provides advanced program-to-program communications (APPC) to support communications between distributed processing programs, called transaction programs (TPs). The TPs can be located at any node in the network that provides APPC. APPC uses the LU 6.2 protocol for exchanging data between programs located at different logical units (LUs). In addition, APPC supports multiple concurrent links and parallel sessions. Conversation or session security between the communicating programs
is also supported through APPC.
Communications Server provides APPC throughput in
performance-critical LAN environments. Communications Server
supports the following connectivities:
Table 1. Supported APPC Connections
|IP||SNA over IP||IP-provided connections|
|IP||HPR over IP||IP-provided connections|
|Note:||APPC/APPN also has data compression capability. Refer to Data Compression for more information on data compression. Also, refer to SNA Session-Level Encryption for information on encryption.|
LU 6.2 is an architecture for program-to-program communications. Communications Server supports the following optional SNA LU 6.2 features:
Refer to Communications Server Programming Guide and Reference for a complete list of features.
Basic end node configuration requires as few as four parameters: network ID, local node name, link type, and destination address. System definition is reduced by:
Because the SNA configuration is stored as a text file, you can quickly and easily modify the file by using an editor or a program written by a user. You can then verify and dynamically update an active configuration (without stopping Communications Server).
You can now configure connections to multiple hosts, and multiple host connections can be active at the same time. Connections can be set to start on demand, or as a result of a hot standby failure.
Communications Server support of Discovery enables a node to dynamically find the control point name, medium access control (MAC) address and service access point (SAP) address of another Communications Server network node server on a Token-Ring or Ethernet LAN. This means the user does not have to know the control point name, MAC and SAP address of a partner machine before being able to define a connection to it. Currently, Client Access/400, Host On-Demand 4.0 and Personal Communications users can use this facility.
This section introduces APPC concepts and terms.
A transaction program (TP) is a program, or part of an application program, that uses APPC communications functions. Application programs use these functions to communicate with application programs on other systems that support APPC.
Communications Server provides the APPC API and supports the IBM Systems Application Architecture (SAA) Common Programming Interface for Communications (CPI-C) calls for transaction programs.
Transaction programs issue APPC parameters to invoke APPC functions. A parameter is a formatted request that a transaction program issues and APPC executes. A program uses APPC parameter sequences to communicate with another program. Two programs that communicate with each other can be located at different systems or on the same system. The APPC API is the same in both cases.
When a transaction program exchanges data with another transaction program, the other transaction program is called a partner transaction program.
Transaction programs can issue CPI-C calls. These calls let application programs take advantage of the consistency that SAA provides.
Every transaction program gains access to an SNA network through a logical unit (LU). An LU is SNA software that accepts parameters from your programs and acts on those parameters. A transaction program issues APPC parameters to its LU. These parameters cause commands and data to flow across the network to a partner LU. An LU also acts as an intermediary between the transaction programs and the network to manage the exchange of data between transaction programs. A single LU can provide services for multiple transaction programs. Multiple LUs can be active in the node simultaneously.
Communications Server supports LU types 0, 1, 2, 3, and 6.2. LU types 0, 1, 2, and 3 support communication between host application programs and different kinds of devices, such as terminals and printers.
LU 6.2 supports communications between two programs located at type 5 subarea nodes, type 2.1 peripheral nodes, or both, and between programs and devices. APPC is an implementation of the LU 6.2 architecture.
Before transaction programs can communicate with each other, their LUs must be connected in a mutual relationship called a session. A session connects two LUs, so it is called an LU-LU session. Figure 1 illustrates this communication relationship.
Figure 1. A Session between Two LUs (LU-LU)
Sessions act as conduits that manage the movement of data between a pair of LUs in an SNA network. Specifically, sessions deal with things such as the quantity of data transmitted, data security, network routing, and traffic congestion.
Sessions are maintained by LUs. Normally, transaction programs do not work with session characteristics. You define session characteristics when you:
The communication between transaction programs is called a conversation. Like a telephone conversation, one transaction program calls the other, and they "converse", one transaction program talking at a time, until a transaction program ends the conversation. A conversation starts when a transaction program issues an APPC parameter or CPI-C call that allocates a conversation. Conversations occur across LU-LU sessions.
Allocating a conversation to a session establishes a send-receive relationship between the transaction programs connected to the conversation. One transaction program issues parameters to send data. The other transaction program issues parameters to receive data. When the sending transaction program finishes sending data, it can transfer send control of the conversation to the receiving transaction program. Conversations can exchange control information and data.
Figure 2 shows a conversation between two transaction programs occurring over a session.
Figure 2. Transaction Program Conversation Occurring over a Session
A session can support only one conversation at a time, but one session can support many conversations in sequence. Because multiple conversations can reuse sessions, a session is a long-lived connection compared to a conversation. When a program allocates a conversation and all applicable sessions are in use, the LU puts the incoming attach (allocation request) on a queue. It completes the allocation when a session becomes available.
Two LUs can also establish parallel sessions with each other to support multiple concurrent conversations. A parallel session occurs when either transaction program allocates a conversation and a session exists, but is being used by a conversation. The LU can request a new session to satisfy the allocation.
Figure 3 shows three parallel sessions between two LUs; each session carries a conversation.
Figure 3. Parallel Sessions between LUs
Advanced peer-to-peer networking (APPN) is a set of functions, formats, and protocols that greatly enhances the managing of an SNA network and the usability of APPC applications running in the network. APPN does this through reduced configuration requirements, dynamic directory searches, route calculation capabilities, and intermediate session routing.
With APPN, you can write programs without knowing the details of the underlying network. All you need to know is the name of the partner LU; you do not need to know its location. SNA determines the partner LU location and the best path for routing data. A change to the underlying network, such as a physical address change, the addition of a new adapter, or the relocation of a machine, does not affect APPC programs.
Communications Server provides APPN end node and network node support for workstations, enabling them to communicate more flexibly with other systems in the network. Additionally, a branch extender function enables you to isolate branches to avoid unnecessary CP-CP traffic.
This capability enables a node to establish a link connection directly to another node with no LAN destination address configured.
Communications Server supports a wide range of 32-bit application programming interfaces (APIs) on the server for the application program developer. These APIs provide convenient ways for application programs to access Communications Server functions and allow applications to address the communication needs of connections to both IBM and other computers. In addition, the provided interfaces support SNA protocols so that standardization is ensured.
The APIs supported include:
On the clients, the Enhanced APPC (EHNAPPC) API is also provided.
The Communications Server Software Developers Tool Kit (which can be separately installed from the Communications Server CD-ROM) is also available for application developers to use. This tool kit contains samples, header files, library files, and online manuals for each of the APIs.
For more information on Communications Server programming interfaces, refer to Client/Server Communications Programming and System Management Programming.
High performance routing (HPR) is an enhancement to APPN that increases data routing performance and reliability and establishes a virtual link between rapid transport protocol (RTP) nodes. HPR replaces intermediate session routing, which is the routing technique used in APPN.
HPR provides faster transmission at intermediate nodes, nondisruptively reroutes sessions around failed nodes and links, and regulates traffic flow by predicting and reducing congestion in the network.
Communications Server supports HPR connections over Enterprise Extender (IP), synchronous data link control (SDLC), LAN, WAN, channel, Multi-Path Channel (MPC), and X.25 connections.
Data compression at the session level increases throughput for large amounts of data across communication links, resulting in the following benefits:
SNA data compression is compatible with the S/390 and AS/400 implementations and can be used with all LU types.
Discovery is a LAN address resolution protocol that can be used by a node on the LAN to find another node that matches given search criteria. By adjusting the search parameter, a node can search for APPN network nodes, nodes that provide SNA boundary function, AS/400s, SNA gateways, or user-defined classes of server. A Communications Server for Windows NT server can respond to requests from clients as a network node server, a PU 2.0 gateway, or as a user-defined class of server. A Communications Server can also use discovery to find APPN nodes and SNA gateways.
Communications Server provides dependent LU requester (DLUR) end node and network node support for workstations, enabling them to take advantage of the enhanced system services control point (SSCP) support provided by a dependent LU server (DLUS). DLUS is supported by VTAM V4R2 and later. With this support, traditional SNA dependent LUs, such as emulators and even printers, can gain the many advantages of an APPN network.
Some of these benefits include:
See Dependent Logical Unit Requester Support for more information about DLUR.
A gateway permits communication between hosts that support PU 2.0 workstations and workstations that use different DLC types. An SNA gateway can do the following things:
The SNA gateway enables an S/390 family host to support workstations that implement LU 0, 1, 2, 3, or dependent LU 6.2 (APPC). The SNA gateway also supports LU 0, 1, 2, or 3 to an AS/400 host. The AS/400 host passes the data through to an S/390 family host.
Each host views the SNA gateway as an SNA PU 2.0 node, supporting one or more LUs per workstation. As far as the host is concerned, all LUs belong to the SNA gateway PU. The SNA gateway can have multiple host connections simultaneously and direct different workstation sessions to specified hosts. However, only one host (and it must be on a link with a CP PU) can act as the focal point, and the control point name is appended to all network management vector transports (NMVTs) routed through the gateway.
To the supported workstations, the SNA gateway looks like an SNA PU 4 communications controller and forwards such host messages as BIND and UNBIND. The network LUs are not aware of the SNA gateway. The SNA gateway, however, is aware of all LUs at the workstations.
In reality, the SNA gateway is a special type of PU 2.0. As long as a dependent workstation is inactive, the SNA gateway implements the LU functions for the workstation, just as a real PU 2.0 would. However, as soon as a workstation is online to the host, the SNA gateway enables the workstation to implement LU functions and merely passes data between workstations and the host.
An SNA gateway enables supported workstation applications to access remote supported applications on a subarea network without requiring a separate direct connection to each host in each workstation. From a host point-of-view, the host has a single connection to the gateway.
See Chapter 7, Planning for SNA Gateway for more information about using an SNA gateway.
Figure 4 shows an example of a connection using an SNA gateway.
Figure 4. Example of SNA Gateway Connections
Communications Server incorporates the SNA over TCP/IP and Sockets over SNA functions from the AnyNet product family. This support enables you to extend and simplify your network by allowing SNA applications to communicate across a TCP/IP network and Sockets applications to communicate across an SNA network without changes to the applications.
The SNA over TCP/IP access node function allows SNA applications residing on an IP network to communicate. This function supports independent LU6.2 and dependent LU 0, 1, 2, 3, or 6.2 either with or without dependent LU requester (DLUR). In addition, the SNA over TCP/IP access node can be used in conjunction with SNA gateway to enable SNA gateway sessions over TCP/IP.
The SNA over TCP/IP gateway function extends the reach of SNA applications by allowing SNA applications in an SNA network to communicate with SNA applications in an IP network. The SNA over TCP/IP gateway supports independent LU 6.2 sessions.
Figure 5 shows SNA applications communicating through an SNA over TCP/IP Gateway across IP and SNA networks.
Figure 5. SNA over TCP/IP Gateway
The Sockets over SNA access node function enables TCP/IP application programs using the WinSock 1.1 and WinSock 2.0 socket interface to communicate over an SNA network.
The Sockets over SNA gateway function enables sockets applications in SNA and TCP/IP networks to communicate. Sockets over SNA gateways are often used to connect isolated TCP/IP networks using an SNA backbone network.
Figure 6 shows Socket applications communicating through a Sockets over SNA gateway across IP and SNA networks.
Figure 6. Sockets over SNA Gateway
The TN3270E server function enables TCP/IP users to access applications on a host machine in an SNA network. Any industry-standard TN3270 or TN3270E client workstation can connect to the TN3270E server for access to SNA networks. The TN3270E server supports ATTN and SYSREQ key handling and enables users to print from host applications to printers attached to their workstation. These printers may be locally-attached or network-attached.
Communications Server supports load balancing for client connections of a TN3270E server that connects to the same host resources, if the client is enabled for load balancing.
TN3270E server supports IP and hostname filtering that allows controlled access to LUs without modifying client configurations.
TN3270E server also supports Secure Sockets Layer (SSL) authentication and encryption, providing secure access across the TCP/IP network. If you specify security, the server must have an authenticated certificate provided by a certificate authority such as IBM Vault Registry or Verisign. Communications Server provides a utility that generates and manages keys and certificates used by SSL Version 3. For more information on using SSL authentication and encryption, refer to Chapter 10, Planning for Secure Sockets Layer-based Security.
Figure 7 shows an example of TN3270E server connections.
Figure 7. TN3270E Server Connections
The TN5250 server function enables TCP/IP users to access applications on an AS/400 in an SNA network. Any industry-standard TN5250 client workstation can connect to the TN5250 server for access to SNA networks.
Communications Server supports load balancing for client connections of TN5250 servers that connect to the same AS/400s, if the client is enabled for load balancing.
TN5250 server supports IP and hostname filtering that allows central administration of client access to the server, as well as directing clients to specific AS/400s.
TN5250 server also supports Secure Sockets Layer (SSL) authentication and encryption, providing secure access across the TCP/IP network. If you specify security, the server must have an authenticated certificate provided by a certificate authority such as IBM Vault Registry or Verisign. Communications Server provides a utility that generates and manages keys and certificates used by SSL Version 3. For more information on using SSL authentication and encryption, refer to Chapter 10, Planning for Secure Sockets Layer-based Security.
Figure 8 shows an example of TN5250 server connections.
Figure 8. TN5250 Server Connections
Communications Server provides access to data on host machines, AS/400s, and workstations on SNA networks through the following functions:
Applications that use OLE DB or ActiveX can communicate through Communications Server for record-level access to files on an AS/400. Documentation for this function, as well as information about developing these applications using Client Access, is provided in the ibmcs\sdk\pubs\oledb directory.
The AS/400 system uses a structure called a folder to store and organize documents, mail, and other related objects. Communications Server enables you to create disk devices on the server that communicate with AS/400 folders through the AS/400 Integrated File System (IFS). Additionally, if the server shares these disk devices, clients can NET USE to them. Multiple clients can connect to folders on the AS/400 system as if they were drives on their workstations.
You can use shared folders to:
Communications Server provides support for SNA API clients (available on the CD-ROM,) and for Novell NetWare for SAA clients.
The Communications Server SNA API client support allows TCP/IP- and IPX-attached clients to access SNA APIs without requiring SNA protocols to flow between the clients and the server. This allows most SNA configuration to take place at the central server.
Communications Server supports SNA API clients on Windows 95, Windows 98, Windows NT, Windows 2000, Windows 3.1, and OS/2.
The SNA clients provide support for CPI-C, APPC, EHNAPPC, LUA RUI, JCPI-C, and HACL API interfaces, while providing the actual SNA processing at the server. These clients are delivered as part of the server but are actually installed and configured at the client.
The 32-bit Windows and OS/2 clients have additional enhancements:
The Windows 95, Windows 98, Windows NT, and Windows 2000 clients run from the same executable. This executable can be installed on a shared drive; any fixes apply to all clients. The 32-bit Windows client can communicate with either Communications Servers or Novell NetWare for SAA servers.
For more information about the API clients in Communications Server, see Chapter 4, Planning for Client/Server Communication.
Communications Server supports IPX- or TCP/IP-attached clients running emulator software packages that implement Novell's Queue Element/Message Unit (QEL/MU) architecture for 3270 emulation, enabling the clients to access mainframe host data. This includes support for popular client features, including dedicated, pooled, and public LU categories (sometimes referred to as resource types).
Communications Server supports Novell NetWare for SAA clients on Windows 95, Windows NT, Windows 3.1, and OS/2.
Refer to Novell NetWare for SAA 3270 Client Interface Guide and Reference P/N 100-002018-001 for more information about developing these clients.
Communications Server now supports load balancing for all client types. Load balancing enables you to distribute LU 0 to 3 and LU 6.2 sessions across Communications Server and NetWare for SAA servers. The server advertises services including load factors, which the clients or servers can gather and organize to select a server.
You can configure multiple clients from a central location using the Lightweight Directory Access Protocol (LDAP) to simplify the configuration process.
For information about using directory exploitation, refer to Chapter 4, Planning for Client/Server Communication.
Communications Server provides facilities for the configuration and administration of resources.
This section provides an overview of the Communications Server configuration components and the methods used to create or change them. The configuration is composed of a single file (ACG) stored in the PRIVATE subdirectory of the directory where you installed the product (for example, C:\IBMCS\PRIVATE). The ACG file can be created using SNA Node Configuration. You can modify the ACG file using SNA Node Configuration, Web Administration, or by using an ASCII editor. A verification program is available to check the validity of the ACG file prior to use.
You can use the following methods to create or change a Communications Server configuration:
Communications Server provides the SNA Node Configuration application (PCSCFG) that enables you to configure the Communications Server functions using a graphical interface and supplies defaults so you can configure them easily using a minimum number of parameters. During configuration, each definition you create is checked to ensure that it is valid. When you save the configuration, the required configuration files are created.
Local configuration is supported at both the client and server level. Remote configuration of the server is supported from Windows 95, Windows 98, Windows NT, and Windows 2000 clients.
Most configurations can be created using SNA Node Configuration. However, a few keywords and some keyword parameters are not supported by SNA Node Configuration.
Web Administration provides the capability to modify your configuration.
Response file configuration enables you to customize a template configuration file to meet the needs of specific users. For more information on using response files for configuration, refer to "Configuration with Template and Response Files".
SNA Node Operations provides the capability to create and modify select resources.
Communications Server provides the following facilities for administration of resources.
For more information about the capabilities of these facilities, refer to Chapter 16, "System Management Facilities".
Load balancing is a function of Communications Server that dynamically balances dependent LU (host-to-workstation) sessions and independent LU 6.2 sessions by distributing them to the communications server with the smallest load. Communications Server performs load balancing for Communications Server API programs and third-party 3270 emulators that connect over TCP/IP protocols, or third-party TN3270 and TN5250 emulators. The resources across which balancing occurs depend on the session type:
The load balancing capabilities of Communications Server are built into the SNA client APIs. Load balancing is configured for the clients using SNA Client Configuration.
For dependent LU sessions, emulators that use SNA client APIs can participate in load balancing. Otherwise, you must purchase third-party 3270, TN3270, or TN5250 emulator software that supports load balancing.
For LU 6.2 sessions, the initial connection established by a SNA API client determines which server manages all subsequent LU 6.2 sessions.
For more information on load balancing, refer to Chapter 11, Planning for Load Balancing.
Communications Server provides basic and enhanced security support at session and conversation levels. There is security in limiting which Windows NT or Windows 2000 users may access SNA resources through the SNA API clients. Conversation security includes support for password substitution. There is also enhanced LU-LU security.
Communications Server provides support for Secure Sockets Layer-based (SSL-based) security on connections between TN clients and the TN3270E server or TN5250 server. This security uses SSL Version 3 to provide data encryption and server authentication using signed certificates.
Communications Server provides an open interface for adapter manufacturers to build connectivity solutions. A shallow (nonprogrammable) adapter interface is provided for adapter manufacturers to work with Communications Server's SDLC and X.25 protocol stack. A deep (programmable) adapter interface is provided for adapter manufacturers to build connectivity solutions using manufacturer-supplied data link controls.
Communications Server enables communications over the following DLCs:
For more information about the AnyNet SNA over TCP/IP DLC, refer to "SNA over TCP/IP".
The Multi-Path Channel (MPC) DLC provides high-capacity, high-availability fiber connections to one or more S/390 MPC-capable hosts over the ESCON channel adapter card (P/N 9663 001). MPC connections provide high data transmission rates with transparent backup when physical connections break or become temporarily unavailable. This channel-to-channel connection enables you to provide LAN clients ready access to S/390 resources and services.
Communications Server now provides HPR connections on IP networks, using UDP/IP packets. To the HPR network, the IP backbone appears to be a logical link. To the IP network, the SNA traffic appears to be UDP datagrams. These datagrams are routed without changes to the IP backbone. Because there is no protocol transformation and because packaging takes place at the routing layer without the overhead of additional transport layers, this results in efficient use of the intranet infrastructure for IP clients that access SNA-based data (TN3270 clients or Web browsers using IBM Host on Demand, for example), as well as for SNA clients.
Communications Server supports simple network management protocol (SNMP) requests for APPN management information from any SNMP management system.
In Communications Server, you can configure certain host links to activate automatically if a specified critical server fails. Configured connections to a host can continue to function by activation of alternative connections on a backup server. This function is known as hot standby.
The connections named in a critical server configuration on the backup server are activated when the backup server detects a loss of contact with the critical server and licensing charges for the critical server are managed on the backup server.
|Note:||The hot standby feature only provides for activation of host connections on a backup server and depends on the use of emulator software that supports alternate routing to the backup server when a critical server becomes inactive.|
For more information about using hot standby for backup connections, refer to Chapter 12, Planning for Backup Host Connections.
Communications Server includes an entry-level version of the popular Personal Communications 3270 and 5250 emulator for administrative purposes. This emulator provides basic 5250 and 3270 support on the server that includes a subset of the features and functions that are in the full-function IBM Personal Communications family of emulators.
The entry-level emulation functions provided include:
Although graphical keyboard remapping is not supported for the entry-level emulator, you can use the remap files generated by the full-function emulator.