HP-UX SNAplus2 R7 NOF Programmer's Guide

Introduction to the NOF API
Client-Server Operation
1.4 Client-Server Operation
The computers on the SNAplus2 LAN are of two types: servers and clients. A server contains a SNAplus2 node and
its associated connectivity components; a client does not contain these connectivity components, but accesses them
on the server by means of the LAN. Servers are HP-UX computers; clients can be running HP-UX or Windows. (A
HP-UX 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 LAN using Berkeley Software Distribution (BSD)
Sockets.
Each SNAplus2 LAN system, referred to as a domain, is identified by a domain name. This name is specified during
the installation of each SNAplus2 computer (server or client), so that all computers in a single SNAplus2 LAN
system have the same domain name. To install two separate SNAplus2 domains on the same physical network, you
simply use two different domain names to identify the domain in which each computer belongs. A single SNAplus2
domain can correspond to a TCP/IP subnet, can be part of a TCP/IP subnet (so that there are two or more separate
SNAplus2 domains in the same subnet), or can span multiple subnets.
Each server maintains information about its own node configuration in a node configuration file. You can use the
SNAplus2 administration tools or the NOF API to examine the node’s configuration. This can be done either from
this server or from any other computer in the domain, as long as the SNA software is running (whether or not the
node is started). You can also use the SNAplus2 administration tools or the NOF API on this server or on any other
server to modify the node’s configuration or to start or stop resources on the node. However, you cannot use the
NOF API on a client to modify configuration or to start or stop resources.
Information about the configuration of domain resources for the complete SNAplus2 LAN is held in a domain
configuration file. If you have more than one server on the LAN, SNAplus2 ensures that this information is
consistent across all servers.
1.4.1 Master Server and Backup Servers
If you are using SNAplus2 with all programs on one computer or on a LAN that contains only one server, you do
not need to read this section.
At any time, one server on the LAN, known as the master server, holds the master copy of the SNAplus2 domain
configuration file. You can define other servers on the LAN to be backup servers; the domain configuration file
is copied to backup servers (either when they are started or when the master copy is changed) so that all backup
servers hold a copy of the latest information.
If the master server fails or if the SNA software on that computer is stopped, a backup server takes over as the
master. The domain configuration file on this server is used as the master copy and is copied to other servers as
necessary. When the master server is restarted, it receives a copy of the domain configuration from the backup
server currently acting as master and then takes over as the master.
In general, define at least one backup server in addition to the master server. Any remaining servers can be defined as
additional backup master servers or they can be left as peer servers. A peer server obtains configuration information
from the master server as required but cannot act as a backup server.
If at any time the master server and all backup servers are inactive, a node on a peer server can still operate, and you
can still change the node’s configuration. However, you cannot access the domain configuration file and therefore
cannot access the configuration of domain resources (as opposed to node resources). This means that you will not
be able to start the 3270 emulation program, start RJE programs, or allocate CPI-C conversations using symbolic
destination names defined in the configuration file.
There is one situation in which SNAplus2 cannot maintain a consistent configuration of domain resources across
the LAN; it is your responsibility to maintain the configuration in this case. This situation occurs when the LAN
is split by a network failure into two noncommunicating domains, each containing one or more backup servers.
In this situation, there will be an acting master server in each domain, which will hold any changes made to the
domain configuration file in that domain but will be unaware of any changes made in the other domain. When
the LAN connection is re-established, the domain configuration file from the original master server (or from the
48