Decision 6: How to set up communications between components

Edit online

A number of communication protocols are available for connections between the hub and remote monitoring servers and between each monitoring agent and the monitoring server it reports to. You configure each monitoring server to use one or more of these protocols, and you assign a priority number to each protocol selected. When the monitoring server attempts to communicate with another component, it tries the highest-priority protocol first. In case of failure, it goes on to the second-priority protocol, and so on. Every component configured to communicate with a monitoring server must have at least one communication protocol in common with that monitoring server.

The communication protocols are of two basic types:
SNA
Because some monitoring agents on z/OS® systems require SNA, it must be one of the protocols selected for a monitoring server communicating directly with those monitoring agents. However, SNA does not have to be the highest-priority protocol.
TCP/IP
The TCP protocols available are IP.PIPE, IP.SPIPE, IP6.PIPE, IP6.SPIPE, IP.UDP, and IP6.UDP. For the hub monitoring server, at least one of the protocols chosen must be a TCP protocol to support the SOAP server. If you plan to implement long-term historical data collection, communication with the Tivoli Data Warehouse also requires a TCP protocol.
IP.PIPE is the default protocol. All of the piped protocols (IP.PIPE, IP.SPIPE, IP6.PIPE, and IP6.SPIPE) enable the monitoring software to traverse most firewall configurations. If you choose piped protocols for the monitoring server and monitoring agent, be aware of the following limitations:
  • The maximum number of piped processes per host is 16.
  • The piped protocols use only one physical port per process.

If you are configuring a high-availability hub monitoring server, Dynamic Virtual IP Addressing (DVIPA) is required on the z/OS system. This allows the high-availability hub to be moved and restarted on, for example a different LPAR, without the need for reconfiguration should problems occur or if you have a planned maintenance outage on the LPAR where it was originally running. DVIPA requires a piped TCP/IP protocol to be used and the address of the monitoring server must be resolvable through the Domain Name Server (DNS).

Your communication protocol settings for a monitoring server on a z/OS system are saved in the KDE_TRANSPORT environment variable of the KDSENV member of the rhilev.rte.RKANPARU library for the runtime environment.