Switching domain managers
This section describes the mechanism that keeps the agent for z/OS connected to your HCL Workload Automation network when you switch to a backup manager.
Understanding how the agent responds to a domain manager switch
Whenever you change the domain manager (or master) associated with the dynamic workload broker instance to which the agent for z/OS is connected, the link between the agent and its dynamic workload broker counterpart is interrupted. The HTTP client of the agent for z/OS is designed to search the next available dynamic workload broker instance (that is, the one running in the newly activated domain manager) and to establish a connection as soon as it acknowledges the interruption.
Following its initialization, the agent for z/OS pings the dynamic workload broker at regular intervals. Each ping is an HTTP post request where the agent sends its identification and other attributes as a dynamic workload broker resource. After the dynamic workload broker accepts and processes the HTTP request, it responds by sending the list of currently defined backup dynamic workload broker instances. This list is based on the list of HCL Workload Automation agents defined as backup domain managers.
After the first successful ping, the agent for z/OS has the list of all the backup dynamic workload broker instances available in the HCL Workload Automation network. This list is refreshed at each following ping request. If the agent cannot successfully ping the target dynamic workload broker when it is started, then no list of backups is available at all and no switch to a backup dynamic workload broker can occur.
- If this dynamic workload broker instance is available, and a connection is established, it becomes the new target dynamic workload broker that the agent for z/OS interacts with. The new dynamic workload broker also provides an updated list of backup dynamic workload broker instances.
- If the instance is unavailable, the HTTP client pings the next instance in the list, and so on. After trying the last instance without success, it starts over from the first. This process goes on until one of the dynamic workload brokers is pinged successfully.
Stopping and restarting the agent after the primary dynamic workload broker has changed
From the first time the connection with the dynamic workload broker is established, the list of backup instances is stored in the agent memory for the duration of the agent runtime. It is lost when you stop the agent. When you stop and restart the agent, the agent pings the original dynamic workload broker instance specified in its configuration parameters. If this instance is unavailable because you have operated a switch or because it has gone down in the meantime, the agent cannot connect with a backup instance since it has no list yet. So, if you do stop and restart the agent after the primary dynamic workload broker has changed, remember to update the agent configuration with the TDWBHOSTNAME and TDWBPORT values of the new primary dynamic workload broker. After connecting with the new dynamic workload broker, the agent will be sent the list again.