ADNR not communicating with the Global Workload Manager

ADNR communicates with only one GWM. Use the following information to diagnose why ADNR fails to communicate with the GWM.

• Verify that ADNR is running. If it is not running, then start ADNR.
• Verify that the GWM is running. If it is not running, then start the GWM. See Diagnosing problems with the z/OS Load Balancing Advisor for more on z/OS Load Balancing Advisor problems.
• Verify network connectivity exists between the GWM and ADNR.
  • See Diagnosing network connectivity problems for guidance on the diagnosis process for network connectivity problems.
  • Issue display commands on the GWM (by using the MODIFY command) to determine whether ADNR is connected to the GWM and has registered its group and member data. For more information about the MODIFY command see z/OS Communications Server: IP System Administrator's Commands. If not using AT-TLS, verify that the z/OS Load Balancing Advisor's lb_id_list statement includes the IP address on the host_connection_addr parameter in the gwm statement in the ADNR configuration file. The eventual action message, EZD1272E will persist on the console if communication with a GWM does not exist.
  • If using AT-TLS with SERVAUTH access control checks to validate connections between the Advisor and ADNR, 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 load balancer and ADNR 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.
  • If you are using sysplex subplexing, ensure that the ADNR application does the following:
    • Has connectivity to the Advisor's subplex.
    • Is using one of the TCP/IP stacks in this subplex; when in a common INET (CINET) environment with multiple TCP/IP stacks on one MVS™ system, either by establishing affinity to one of the stacks in the subplex or by binding to a VIPA that is only defined on stacks that are in that subplex. See the adnrproc.sample for an example of the JCL to establish affinity.
  • Verify that network connectivity exists between ADNR and the GWM in question. Issue Netstat COnn/-c or Netstat ALLConn/-a commands on the ADNR system to see whether a connection exists between ADNR and the GWM. Correct the underlying network connectivity problem. For guidance on using Netstat commands see z/OS Communications Server: IP System Administrator's Commands.
  • Issue a display command on ADNR to determine whether there are indications that any groups and members are known to exist within the sysplex. For more information about the MODIFY command see z/OS Communications Server: IP System Administrator's Commands.
• Check the syslogd output file where ADNR writes its log data for ERROR or WARNING messages and take the appropriate corrective action. If ERROR and WARNING level log message are not enabled, then enable them and recheck the log file later. The current ADNR debug level can be displayed by issuing the MODIFY procname,DISPLAY,DEBUG command at the MVS console. The debug level can be dynamically changed by issuing the MODIFY procname,DEBUG,LEVEL=n command at the MVS console. The procname is the JCL procedure name for ADNR and n is the new debug level. For more information about the MODIFY command, see z/OS Communications Server: IP System Administrator's Commands.