Workload not distributed to a particular application

Use the following checklist to determine why workload is not being distributed to an application:
  • Verify that the Advisor is running and that an Agent is running on the MVS™ system that contains the application. If they are not running, start the Advisor or Agent.
  • If you are using sysplex subplexing, verify that the Advisor and Agents are in the same subplex. If there are multiple TCP/IP stacks in a subplex, ensure the IP addresses used by the Advisor and Agents are DVIPAs defined within a VIPARANGE statement on each of the stacks in the subplex. Review the syslog for the Advisor and Agents for messages indicating what subplex had been used. Each subplex must have an active Advisor associated with it, and each subplex in a z/OS® system must have an Agent associated with it.
  • Issue display commands on the Advisor to determine whether any LBs have registered the application. Verify that the LB is connected to the Advisor. If you are using sysplex subplexing, ensure that the load balancers have connectivity to the Advisor's subplex.
  • Verify that the Advisor's lb_id_list statement includes the IP address of the LB in question if not using AT-TLS.
  • Verify that the IP address and protocol of the member on the LB match the IP address and protocol of the application. If the IP addresses or protocols do not match, correct the definition at the LB.
  • Verify that the Advisor's agent_id_list statement contains the IP address and port that the Agent is bound to on the system where the application exists, if not using AT-TLS. If it does not match and you are not using AT-TLS, correct the agent_id_list statement on the Advisor or the advisor_id statement on the Agent.
  • Verify that network connectivity exists between the Advisor and the Agent in question. Unexpected loss of network connectivity between the two should result in an immediate action console message and related messages in the Agent and Advisor log. Issue NETSTAT CONN or NETSTAT ALLCONN commands on the Advisor system to see which Agents have connections to the Advisor, and by omission, which do not. Issue the MODIFY DISPLAY command on the Agents in question to verify that the connection to the Advisor is still active. The DISC flag is shown on the MODIFY DISPLAY command when the Agent is not connected to an Advisor. Correct the underlying network connectivity problem. For more information, see Diagnosing network connectivity problems.
  • If using AT-TLS with SERVAUTH access control checks to validate connections between the Advisor, Agents, and external load balancers, see Diagnosing Application Transparent Transport Layer Security (AT-TLS). In addition, ensure that the SERVAUTH class is active. Ensure that the EZB.LBA.LBACCESS.sysname.tcpsysplexgroupname resource profile is defined and that the user ID associated with the external load balancer has READ access to it. Ensure that the EZB.LBA.AGENTACCESS.sysname.tcpsysplexgroupname resource profile is defined and that the Agents have READ access to it. On the system console where the Advisor is running, look for message EZD1280I which indicates that a connection attempt using AT-TLS failed. This message has specific reason codes which indicate the reason for the failure.
  • Issue display commands on the Advisor and Agent in question to verify that the application is available and enabled (not quiesced). Start the application or enable the application using the Agent MODIFY ENABLE command.
  • Check the log file for ERROR or WARNING messages and take the appropriate corrective action. If ERROR and WARNING level log messages are not enabled, enable them and recheck the log file later.
  • Verify that the LB has connectivity to the IP address of the member in question.
Parent topic: Diagnosing Advisor and Agent problems