![]() |
![]() |
This section describes how to set up communications for enterprise configuration, enterprise event logging, and command routing. Communication setup for server-to-server virtual volumes is described in Setting Up Source and Target Servers for Virtual Volumes.
When you set up communications among servers for any purpose, ensure that servers have unique names. At installation, a TSM server has the same name as that of the machine. You can change the server name if necessary before setting up communication with other servers. For example, enter this command to name the server TUCSON:
set servername tucson
The communication setup for enterprise configuration and enterprise event logging, which is through TCP/IP, is identical. The examples shown here apply to both functions. If you are set up for one, you are set up for the other. However, be aware that the configuration manager and event server are not defined simply by setting up communications. You must identify a server as a configuration manager (SET CONFIGMANAGER command) or an event server (DEFINE EVENTSERVER command). Furthermore, a configuration manager and an event server can be the same server or different servers.
The following examples of setting up communications could be used to create these configurations:
For a pair of servers to communicate with each other, each server must be defined to the other. For example, if a configuration manager manages three managed servers, there are three server pairs. You can issue separate definitions from each server in each pair, or you can "cross define" a pair in a single operation. Cross definition can be useful in large or complex networks. The following scenarios and accompanying figures illustrate the two methods.
Using separate definitions -- Follow this sequence:
On STRASBOURG: Specify the server name and password of STRASBOURG.
On HEADQUARTERS: Specify the server name and password of HEADQUARTERS.
On MUNICH and STRASBOURG: Define HEADQUARTERS (whose password is AMETHYST and whose address is 9.115.4.177:1823).
Figure 76. Communication Configuration with Separate Server Definitions
Using Cross Definitions -- Follow this sequence:
On STRASBOURG: Specify the server name, password, and high and low level addresses of STRASBOURG. Specify that cross define is permitted.
On HEADQUARTERS: Specify the server name, password, and high and low level addresses of HEADQUARTERS.
Figure 77. Communication Configuration with Cross Definition
Security for this communication configuration is enforced through the exchange of passwords (which are encrypted) and, in the case of enterprise configuration only, verification keys. Communication among servers, which is through TCP/IP, requires that the servers verify server passwords (and verification keys). For example, assume that HEADQUARTERS begins a session with MUNICH:
This section describes how to set up communications for command routing. You must define the target servers to the source servers, and the same administrator must be registered on all servers. Using enterprise configuration, you can easily distribute the administrator information to all the servers.
For command routing in which one server will always be the sender, you would only define the target servers to the source server. If commands can be routed from any server to any other server, each server must be defined to all the others.
The example in this section shows how to set up communications for administrator HQ on the server HEADQUARTERS who will route commands to the servers MUNICH and STRASBOURG. Administrator HQ has the password SECRET and has system privilege class. Here is the procedure:
register admin hq secret grant authority hq classes=system define server munich hladdress=9.115.2.223 lladdress=1919 define server strasbourg hladdress=9.115.2.178 lladdress=1715
register admin hq secret grant authority hq classes=system
The examples in this section show how to set up communications if the administrator, HQ, can route commands from any of the three servers to any of the other servers. You must define all the servers to each other. You can separately define each server to each of the other servers, or you can "cross define" the servers. In cross definition, defining MUNICH to HEADQUARTERS also results in automatically defining HEADQUARTERS to MUNICH.
Follow this sequence:
On STRASBOURG: Specify the server name and password of STRASBOURG. Register administrator HQ and grant HQ system authority.
On HEADQUARTERS: Specify the server name and password of HEADQUARTERS. Register administrator HQ and grant HQ system authority.
On MUNICH: Define HEADQUARTERS (whose password is AMETHYST and whose address is 9.115.4.177:1823) and STRASBOURG.
On STRASBOURG: Define HEADQUARTERS and MUNICH.
Figure 78. Communication Configuration with Separate Server Definitions
On STRASBOURG: Specify the server name, password, and high and low level addresses of STRASBOURG. Specify that cross define is permitted. Register administrator HQ and grant HQ system authority.
On HEADQUARTERS: Specify the server name, password, and high and low level addresses of HEADQUARTERS. Register administrator HQ and grant HQ system authority.
Figure 79 shows the servers and the commands issued on each:
Figure 79. Communication Configuration with Cross Definitions
You can update a server definition by issuing the UPDATE SERVER command.
To allow replacement, update the definition at the managed server by issuing the UPDATE SERVER command with the ALLOWREPLACE=YES parameter. When a configuration manager distributes a server definition, the definition always includes the ALLOWREPLACE=YES parameter.
You can delete a server definition by issuing the DELETE SERVER command. For example, to delete the server named NEWYORK, enter the following:
delete server newyork
The deleted server is also deleted from any server groups of which it is a member. See Setting Up Server Groups for information about server groups.
You cannot delete a server if either of the following conditions is true:
You must first issue the DELETE EVENTSERVER command.
A target server is named in a DEFINE DEVCLASS (DEVTYPE=SERVER) command. You must first change the server name in the device class or delete the device class.