[z/OS]

Planning for administrative agents

An administrative agent provides a single interface to administer multiple standalone application servers.

Before you begin

Make sure that the nodes that you want the administrative agent to manage have the same products as the administrative agent, and the products are at the same version levels on these node and the administrative agent. This requirement is enforced because the administrative agent must have a matching environment in order to handle all of the administrative capabilities of the registered node. A node is not allowed to register with an administrative agent unless that node has an identical set of products and versions.

Note: If you were previously running on Version 7.0.0.11 or earlier and have an administrative agent with a managed node that has mismatched products or versions, when you migrate to Version 8.5, that administrative agent will not be able to start the subsystem for any mismatched nodes. You must update these nodes to have the same products and versions as the administrative agents, restart the servers on the node and then restart the administrative agent, before the administrative agent can resume managing these registered nodes

About this task

An administrative agent can monitor and control multiple application servers on one or more nodes. By using a single interface to administer your application servers, you reduce the overhead of running administrative services in every application server.

Use the WebSphere Customization Toolbox or the zpmt command and the customization jobs that they generate to configure an administrative agent on z/OS. The administrative agent must run on the same z/OS system as the application server nodes that it manages, and it must use the same SAF configuration group as the nodes to be managed.

After the administrative agent is up and running, you can use the following commands to register and unregister a node with the administrative agent:
  • registerNode

    Run the registerNode command to register a node with the administrative agent. When you run the command, the standalone node is converted into a node that the administrative agent manages. The administrative agent and the node being registered must be on the same system. You can only run the command on an unfederated node. If the command is run on a federated node, the command exits with an error.

    Any node registered with the administrative agent automatically becomes eligible to register with the job manager.

  • deregisterNode

    Use the deregisterNode command to deregister a node from an administrative agent so that you can use the node standalone or register the node with another administrative agent. The node must have been previously registered with the administrative agent. When you deregister a node, the node configuration is retained but is marked as not registered with the administrative agent.

An administrative agent can register any of the profiles that it manages with a job manager.

For more information, read the Administering nodes using the administrative agent article in the information center.

Procedure

  1. Print a copy of the customization worksheet.
  2. Fill out the worksheet as described in z/OS customization variables: Administrative agents.
  3. Save the worksheet for use during administrative agent customization.
Task topic    

Terms and conditions for information centers | Feedback

Last updated: April 20, 2014 09:59 PM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=phil&product=was-nd-zos&topic=tins_planningaacell
File name: tins_planningaacell.html