|
|
United States-English | |
|
|
 |
|
HP-UX SNAplus2 API NOF Programmer's Guide: HP-UX 11.0, 11i v1, and 11i v2 > Chapter 1 Introduction
to the NOF API
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 must be HP-UX computers; clients may be running HP-UX or Windows systems. 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 which domain 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 and modify 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). 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. 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 or RJE programsor 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 highest backup server available in either of the two domains if the master is inactive at this point) will become the domain configuration file across the LAN; this will overwrite any changes made to the domain configuration file in the other domain while the network was split. Because of this, do not attempt to make any changes to the domain configuration file in either of the two domains while the LAN connection is broken. Changes can be made to the configuration of individual nodes. SNAplus2 stores information about the master server and backup servers in the file sna.net, known as the SNA network data file. The master copy of this file is stored on the master server; any changes made to it are automatically copied to all other servers, in the same way that changes to the domain configuration file are copied to backup servers. You cannot edit the contents of the file directly; instead, SNAplus2 provides NOF verbs to access the file. For more information about the SNA network data file, refer to the HP-UX SNAplus2 Administration Command Reference. A client computer does not contain any configuration file or the SNA network data file; it holds only the information it needs to access servers on the SNAplus2 LAN and relies on a server to provide the necessary configuration information. The SNA network information required is held in the file /etc/opt/sna/sna_clnt.net. For more information about this file, refer to the HP-UX SNAplus2 Administration Command Reference. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
