Overview

Universal Agent consists of product components distributed throughout the enterprise communicating with each other over the computer network using the TCP/IP communication protocol.

Universal Agent offers reliable, fault tolerant, secure, and efficient communications between its distributed components. In order for product components to effectively meet their communication requirements, z/OS must provide sufficient execution time for the product components.

The execution of the communication protocol is a real-time activity and communication time-outs may be exceeded if product components are not dispatched appropriately while executing the communication protocol.

The following sections provide performance guidelines for Universal Agent for z/OS components.

UNIX System Services and Language Environment

All Universal Agent components are written in C/C++ and utilize z/OS Language Environment (LE) and z/OS UNIX System Services (USS).

The IBM z/OS UNIX System Services Planning manual includes a "Tuning Performance" chapter that should be reviewed to improve USS performance in general.

Universal Agent components do not attempt to use the USS setpriority, chpriority, or nice functions to adjust their performance group or service class.

Universal Agent Managers

Universal Agent Managers consist of Universal Command, Universal Data Mover, and Universal Event Monitor managers. They typically execute in the JES subsystem as a batch job or the OMVS subsystem as a USS shell command.

The managers communicate with remote Universal Brokers and their corresponding Universal Agent Server components on remote systems using the TCP/IP protocol.

In cases where the z/OS workload requires more resources than are available, z/OS will favor workload with a higher dispatch priority over workload with a lower dispatch priority. If a Universal Agent manager is being executed with a lower dispatch priority than other workload competing for resources, it may not be given sufficient execution time to meet its network communication timing requirements. The result will be false network time-out errors in the Universal Agent manager.

The effect of a network time-out condition depends on whether or not the Universal Agent manager is using the Network Fault Tolerant (NFT) feature. If NFT is used, the manager reestablishes the communication session and continues; otherwise, the manager ends with an error.

False network communication time-out errors can be addressed using one or both of the following options:

1. Increase the manager's NETWORK_DELAY configuration option value (default is 120 seconds). NETWORK_DELAY specifies the maximum amount of time to wait for data on a communication session before considering the session timed out. Increasing the value allows for the manager batch job to be swapped out for a longer period of time before the session will be considered timed out.
   However, in cases where a condition truly exists in the network that would result in a true network time-out, a larger NETWORK_DELAY value would result in a longer period of time before the manager would detect and respond to the time-out condition.
2. Raise the Universal Agent manager workload dispatch priority by placing it in a higher performance group or service class. Raising the workload dispatch priority will allow z/OS to provide sufficient CPU resources to the manager to meet network timing requirements.

Universal Broker and Universal Agent Servers

The Universal Broker started task is the center of activity on each system on which Universal Agent is installed. Almost all components communicate with a locally installed Universal Broker during their execution, including managers and servers.

Universal Broker is responsible for managing Universal Agent servers that are performing work on z/OS on behalf of remote Universal Agent managers. Universal Agent servers are created by the Universal Broker using the USS spawn function. The servers run as USS child processes of the Universal Broker started task in the OMVS subsystem.

The Universal Broker started task must execute with a sufficiently high performance group or service class in order to service all manager and server requests in a timely manner to avoid false network time-out conditions.

On heavily loaded systems, it is recommended to make the Universal Broker started task non-swappable to help overall improvement of Universal Broker.

Universal Enterprise Controller

The Universal Enterprise Controller (UEC) started task performs real-time monitoring of Agents distributed throughout the network. UEC communicates with each Agent on a defined polling interval.

UEC is a USS, multi-threaded application written in C/C++ that heavily utilizes TCP / IP. The amount of work that UEC performs depends directly on the number of Agents defined to it. UEC maintains Agent status information and Universal Event Subsystem information in the UEC database. The database is an HFS or zFS database that is mounted in the z/OS UNIX file system.

UEC must execute with a sufficiently high performance group or service class in order to perform its Agent monitoring service effectively. False Agent time-out alerts can result if UEC is not dispatched in a timely manner.

On heavily loaded systems, it is recommended to make the UEC started task non-swappable to help overall performance of UEC.