IBM Communications Server for Data Center Deployment on Linux

IBM Communications Server for Data Center Deployment on Linux connects applications across SNA and TCP/IP networks. It converts a System z VM or LPAR running Linux into an SNA node by equipping it with SNA resources and protocols; this enables it to communicate with other computers in an SNA network. It also provides TCP/IP functions to allow IBM Communications Server for Data Center Deployment on Linux to be used within your TCP/IP network or at the boundary between TCP/IP and SNA networks.

Where CS Linux is communicating with an SNA host computer, it can operate in many different ways. Figure 1 illustrates two examples of how CS Linux could be deployed:

  • In the first example, CS Linux is installed on a separate z800 system to offload the main z/OS system. An Enterprise Extender link using IP, or an LLC2 link, is used to connect the two systems.
  • In the second example, CS Linux is installed on one or more VMs or LPARs in the main z/OS system. Although CS Linux and z/OS Communications Server are on the same mainframe, they are two separate SNA nodes, and so an Enterprise Extender link using HyperSockets IP or an LLC2 link is still required between them.
Figure 1. CS Linux for System z Host Communications

The two arrangements illustrated are conceptually the same, and the same CS Linux configuration (including the communications link between CS Linux and the SNA host) is required for both. For clarity, the diagrams in this book show the first arrangement, with CS Linux and the SNA host on separate computers.

CS Linux provides the following services:

Network Support
CS Linux supports subarea and peer-to-peer networks:
SNA Subarea Networks
These networks (also known as host-mediated networks) are hierarchically organized, with one or more host computers controlling communication between computers, managing the network, and providing processing services and high-capacity data storage. All other nodes in the network are dependent on the control of a host.

Linux computers can participate in a subarea network by being configured as host-dependent nodes.

Peer-to-Peer Networks
For distributed processing environments, CS Linux supports APPN networks. In these peer-to-peer networks, Linux computers retain processing functions and communicate directly with each other as peers.

An APPN network consists of peer nodes of the following types:

  • APPN network node (which provides traffic control, dynamic route computation and selection services, and network management services)
  • APPN end node (which uses APPN network node services to communicate with peer nodes)
  • LEN node (which communicates directly with adjacent nodes or nodes configured to appear adjacent)
Note: Host computers can function as peer nodes in an APPN network by using independent LU 6.2 to communicate with Linux computers and other hosts in the network.
Providing Subarea Functions in an APPN Network
The dependent LU requester (DLUR) function enables traffic between hosts and host-dependent nodes to be carried in an APPN network.
Data Link Control Options
At the link level, CS Linux offers different connectivity options to help you meet your network's size, speed, security, and cost considerations. (For a detailed list of the link types supported, see Installation requirements.) It supports data links for different network types, as follows:
Local Area Networks
For LAN connectivity, you can install the appropriate links to communicate using token ring, standard Ethernet, and 802.3 Ethernet protocols.
Wide Area Networks
CS Linux supports SDLC and X.25 (QLLC) connectivity. This depends on the OEM adapter support on each platform.
Local Attachment
CS Linux supports Channel-to-Channel Multipath Channel (CTCMPC) connectivity for local attachment (CS Linux for System z only).
IP Integration
If your corporate backbone network is based on IP, you can use the Enterprise Extender (HPR/IP) feature of CS Linux to integrate this with SNA, allowing your SNA applications to communicate over the IP network. The client/server support also provides SNA over TCP/IP connectivity for support of cloud, mobile and high availability across data centers.
LU Support
Logical units (LUs) are application-specific network resources that reside on each node in an SNA network. Each LU acts as an interface that applications use to access links in order to communicate over the network with partner applications on other nodes.

CS Linux supports different types of LUs for different classes of applications.

  • In a subarea network, CS Linux supports dependent LUs, which can be any of the following types:
    • LU 0
    • LU 1
    • LU 2
    • LU 3
    • LU 6.2

    LU 0 supports primitive program-to-program communication, typically used at point-of-sale transactions in retail and banking. LU 2 supports terminal emulation applications that enable the Linux computer to emulate an IBM 3270-family terminal. The other LU types enable applications to participate in distributed processing or to communicate with various printers or interactive display terminals.

    CS Linux supports host systems that use dynamic definition of dependent LUs (DDDLU), a host feature that enables dependent LUs on the SNA system to be added to the host configuration when the communication link from the SNA system to the host is established. With DDDLU, LUs do not have to be configured statically at the host. (You must still define dependent LUs on the CS Linux node.) This reduces the initial configuration required at the host, and makes later expansion easier.

    CS Linux can communicate with both DDDLU-capable and non-DDDLU-capable hosts, with no difference in the configuration required. When the communications link from the CS Linux node to the host is established, a DDDLU-capable host informs the node that it supports DDDLU; the node then sends the required information to define the dependent LUs that use the link. If the host is not DDDLU-capable, CS Linux does not send this information; it assumes that the LUs have already been defined statically at the host.

  • Independent LU 6.2 supports independent traffic in APPN networks. Independent LU 6.2 supports autonomous communication and network management, as well as distributed processing.

    In addition, the DLUR function of CS Linux enables traffic from dependent LUs to travel over an APPN network.

  • Primary RUI support provides the ability for a CS Linux application to manage downstream LAN/WAN attached dependent LU devices as though it were a mainframe. This function has some restrictions for connectivity, but allows applications to pass data between dependent LU devices without the need for a full mainframe application.
Session Support
A session is a temporary logical channel between partner LUs. Ordinarily, partner applications associated with each LU communicate over the session. CS Linux can support thousands of sessions. CS Linux can also support U-shaped sessions (also known as local/remote transparency), in which both primary and secondary LUs reside in the same Linux computer. This enables you to develop and test a pair of source and target transaction programs in one computer without requiring a link connection.

The data flowing on a session between two partner LUs may be compressed, to reduce the bandwidth required.

  • For LU type 6.2, CS Linux allows you to specify the use of compression in the configuration of the mode that the session uses. You can specify different compression algorithms to be used, each of which provides a different level of compression (RLE, LZ9, or LZ10). You can also specify different compression levels for data flowing in different directions on the session, or specify compression in one direction but not the other.
  • For LU types 0-3, CS Linux allows you to specify the use of compression in the configuration of the link station or PU that the session uses. RLE compression is used for the inbound direction, and LZ9 for the outbound direction.
API Support
CS Linux includes application programming interfaces (APIs) for developing applications for certain types of LUs, for distributed processing, for network management, and for administration of CS Linux itself. CS Linux provides a range of APIs that are compatible with the APIs provided by members of the Communications Server family running on other operating systems.

An API is an interface that enables a transaction program (TP) to communicate with its supporting LU. It consists of a library of verbs (also called functions, calls, and subroutines) from which the TP selects those it needs to pass to its LU to request an action, such as SEND_DATA. The LU, in turn, processes the verbs and builds a data stream according to the appropriate protocol, appends a header indicating the destination address, and sends the data over the link to partner LUs.

Common Programming Interface for Communications (CPI-C) is one of the most powerful of the APIs because of its portability. Introduced to support dependent and independent LU 6.2, CPI-C complies with Systems Application Architecture (SAA) mandates to unify different platforms and operating systems. CPI-C uses a set of syntax rules that is common to all systems. It has thus become a standard.

As well as the standard C-language CPI-C API, CS Linux also includes a CPI-C API for use by Java applications. For more information, refer to IBM Communications Server for Data Center Deployment on AIX or Linux CPI-C Programmer's Guide. In the CS Linux books, all references to CPI-C include Java CPI-C unless stated otherwise.

Other CS Linux APIs include:

  • APPC API for peer-to-peer communications between application programs using LU 6.2. The API has the option of being nonblocking. When a TP uses nonblocking verbs, the API can return control to the TP before the requested action has completed. Later, the TP is informed when the action has completed.
  • LUA API for communications with host applications.
  • CSV (Common Service Verb) API for utility functions such as character translation and application trace control.

In addition, CS Linux includes the following proprietary programming interfaces:

  • MS (Management Services) API for network messaging functions.
  • NOF (Node Operator Facility) API for applications that configure and manage CS Linux resources.

For more detailed information about an API, refer to the programming guide for the API (see the Bibliography).

Client/Server Support
Computers running CS Linux can be configured to communicate using client/server protocols. When client/server protocols are used in a network, all the computers using client/server protocols to communicate in that network are referred to as a domain.

The computers running CS Linux in a client/server configuration can take the following roles:

  • A server contains an SNA node and its associated connectivity components. The server provides SNA connectivity to applications on the local system or on other computers in the CS Linux domain. Servers must be Linux systems.
  • A Remote API client does not contain SNA node components, but accesses them through a server. A client can access one or more servers at the same time, and can run concurrent applications as needed. Clients can be running AIX, Linux, or Windows. Clients can run in Linux or AIX containers or AIX WPAR partitions. (A Linux computer can be either a server or a client, but not both; you cannot install both the server and the client on the same computer.)

Servers and clients communicate across the CS Linux domain using TCP/IP. Alternatively, they can communicate using HTTPS via a WebSphere server, which uses security certificates to authenticate the client connections. You will normally want to use HTTPS if the clients connect across a public network.

In a domain with multiple CS Linux servers, one server holds the controlling copy of the CS Linux domain configuration file. This server is known as the controller server. You can define other servers in the domain to be backup servers, or leave them as peer servers. The domain configuration file is copied to backup servers - either when they are started, or when the controller copy is changed - so that all backup servers hold a copy of the latest information. A peer server obtains domain configuration information from the controller server as required, but cannot act as a backup server.

If the controller server fails, the first backup server on the list of servers defined for the domain takes over as the controller. The domain configuration file on this server is used as the controlling copy, and is copied to other servers as necessary. When the controller server is restarted, it receives a copy of the domain configuration from the backup server currently acting as controller, and then takes over as the controller.

Support for Distributed Applications
In a Client/Server CS Linux system, applications running on Remote API Clients cooperate with connectivity resources on servers to execute a single task. Applications running on other (non-CS Linux) computers can also cooperate with applications on CS Linux computers to perform distributed processing.

CS Linux supports distributed applications using APPC (also known as LU 6.2).