You can dance with the mainframe dinosaur
Several years ago, experts predicted that IBM mainframes would die a quiet death as most businesses moved to PC-based networks. But time has proven that mainframe hosts continue to play a mission-critical role in the enterprise. Today, about 70 percent of business data--from Wall Street firms to fast-food chains--resides on mainframes. However, business has changed the way it accesses mainframes. Business now uses Windows on the desktop to access networks instead of coaxing old dumb terminals to mainframes. In addition, the computer industry is developing GUI and Web-based applications, letting users interface with mainframe information intuitively.
Microsoft SNA Server is an SNA gateway service that can link your IP-based Windows NT network to the SNA-based glass house (i.e., mainframe data center). Although IBM mainframe and AS/400 operating systems (OSs) can speak TCP/IP now, SNA Server lets you offload TCP processes from mainframe and AS/400 hosts to prevent performance degradation. SNA Server also lets you integrate your traditional mainframe programs with modern NT applications via Microsoft's component object model (COM) and ActiveX technologies without having to rewrite the host applications to understand TCP.
As soon as you add SNA Server to your network, you'll likely find that almost everyone in your company wants to access it and requires 24 * 7 availability. Therefore, before you deploy SNA Server in your enterprise, consider how the SNA Server service's fault tolerance and high availability will function within your network design. Fortunately, Microsoft has done a good job of incorporating fault-tolerant features into SNA Server. In this article, I'll help you understand these fault-tolerant features, and I'll discuss how you can build fault-tolerant SNA services within and across SNA servers and subdomains for your NT network. (See the sidebar "A Quick Glance at SNA Server 4.0 Features," page 178, for a listing of additional SNA Server features and functions.)
SNA Subdomains
SNA Server uses a domain concept that's similar to NT's domain concept. An SNA subdomain is a group of SNA servers within an NT domain. An SNA subdomain comprises a primary server, backup servers, and member servers. One primary server (similar to a Primary Domain Controller--PDC) contains the entire subdomain's master configuration file, which reflects the SNA resources in the subdomain (e.g., SNA servers, link services, physical units--PUs, logical units--LUs, users, and security information). You must designate the first SNA server in a subdomain as the primary server. A backup server (similar to a Backup Domain Controller--BDC) keeps a read-only copy of the configuration file. The backup server starts the SNA Server service by loading this local configuration file. You can promote the backup server to primary server if the primary server fails. Therefore, in order to provide a fault-tolerant configuration file, you must have at least one backup server in an SNA subdomain. An SNA member server doesn't have a local copy of the configuration file. It receives the configuration information from the primary server or a backup server and loads the information in memory. A maximum of 15 SNA servers can exist within an SNA subdomain, but you can create as many SNA subdomains within an NT domain as you want. If you have 15 or fewer SNA servers, you can group them in the same subdomain on the same LAN.
When you need to make a change to your SNA subdomain configuration, you can modify the master configuration file on the primary server from any SNA server or an SNA Server Manager workstation (an optional component in the SNA Server Client). The primary server will replicate the configuration file to all backup servers after it commits the change. All SNA servers in the same subdomain communicate with one another through server broadcasts to update the configuration information and status of SNA resources. Server broadcasts occur every 60 seconds by default. Microsoft refers to the protocol you choose for server broadcasts (e.g., TCP/IP) as the server-to-server protocol.
Client to Subdomain Access
SNA Server Client, which runs on a workstation as a service or program, lets the workstation use a client-to-server protocol (e.g., TCP/IP, IPX, and Net BUI) to communicate with SNA servers in the subdomain. Most third-party terminal emulators, Advanced Program-to-Program Communications (APPC) applications, and Microsoft's COM Transaction Integrator (COMTI) running on remote computers use SNA Server Client to connect to SNA servers. A client can search for SNA servers by subdomain name or by server name. To search by subdomain name, the client must specify the subdomain name; however, the client workstation must reside on the same subnet as the SNA
servers the client is searching for. This condition is often not the case in a multisubnet network. Searching for SNA servers by server name doesn't carry the same-subnet requirement.
When a client searches by server name, the client needs to specify one or more SNA server names or IP addresses in the SNA Client Configuration dialog box, as Screen 1 shows. A server defined in the client configuration server list, a sponsor server, can be any SNA server in an SNA subdomain. When a client needs to establish a 3270 session with a mainframe, or an APPC session with a mainframe or AS/400 host, the client sends the request to a sponsor server the client chooses from the server list, either randomly or by progressing through the list in order. The server receiving the request sets up a special sponsor connection with the client and returns a list of all available SNA servers in the subdomain. The client can try to connect to every server in the list until it finds a server that can establish the requested 3270 or APPC session.
An option on the Client Mode tab in the Client Configuration dialog box lets the SNA server update the sponsor server list dynamically so clients have a maximized selection range of sponsor servers. When you select this option, the sponsor server that establishes the sponsor connection will add all available SNA servers in the subdomain to the client configuration server list, including any new SNA servers you added to the subdomain after the initial SNA Server implementation.