To manage the agents, use the top menu to navigate to the AGENTS tab. The top section of the AGENTS tab contains details regarding the health and status of the server as well. See Server status for more details.
Enter the required input as shown in the example above:
Test the connection from the management server to the new agent:
An error message is displayed if an error is detected when attempting to communicate with the agent:
The agent statistics section is divided to two as seen the image above. The left side provides information about the agent containing:
- The connection status. Note that the green 'CONNECTED' indicator above.
- Host IP or DNS
- Agent group name
- Address space name
- Object storage information
- License information
The right side contains two pie charts that calculate the total zIIP offload. The calculation is performed each time the page is refreshed and starts from the time the address space started. The information is taken from the z/OS Resource Measurement Facility (RMF).
The left-hand pie chart, which describes the zIIP eligible workload, indicates how much work was actually offloaded to the zIIP engine(s). In the example above, 92.63% of the total CPU time was offloaded to zIIP engine(s). The right-hand pie chart, that describes the zIIP on CP workload, shows the percentage of workload that was zIIP eligible but got dispatched on the CP engine(s) for example due to the zIIP engine(s) being busy.
An agent is associated with an agent group in the agent configuration file. By default, each agent is part of an agent group in the name of the Sysplex. When associating a policy with an agent group, the tasks are executed by the agents in the group in a round-robin fashion. By default, the server sends 10 tasks per agent simultaneously.
At the beginning of an activity, the run log identifies all the agents that are available for executing tasks. Upon completion of the task, the specific executing agent for every backup/archive operation is identified.
If an agent has more than 5 communications failures, the server stops sending it tasks during that activity. The number of allowed failures can be configured on the server.
The first phase of identifying the resources for processing is performed by a single agent.
Agent group load balancing can be used for sharing work, but also for limiting it to specific LPARs. It may be defined, for example, that all LPARs in the same Sysplex share the same resource complex, allowing them to recall and restore the same resources. However, the archive and backup policies are defined to work with an agent group containing only a subset of the LPARs.
Recall / Restore from CLI
Recall and Restore can be performed by any agent sharing the same resource complex as the agent that performed the original backup, dump or archive. By default, the resource complex is shared by all agents in the same Sysplex, but note that only agents on LPARs that also share the same z/OS Unix System Services can be candidates for this action.
Automatic recall is executed on the same LPAR that initiated the request. If there are several agents on the same LPAR, any of them may pick up the request.
Recall from the UI The server will attempt to use the original agent that executed the archive operation. If that specific agent is not available, the action will fail.
Restore from the UI The server will search for the first available agent from the agent group that was used for the archive. If no agents are available, the action will fail. If there are no agents connected to the agent group, the action will also fail.
Export from the UI The server will search for the first available agent from the agent group that was used for the archive. If no agents are available, the action will fail. If there are no agents connected to the agent group, the action will also fail.
When done editing, click “Save” to update the agent settings.
Deleting an agent requires that it will not be associated with any policy.
Confirm the deletion.