IBM E027SLL-H Troubleshooting Guide - Page 117

Name Resolution IBM Tivoli Monitoring V6.1 depends on IBM's HPNS EZASMI getaddrinfo and EZASMI getnameinfo calls for resolver services. These calls are used to find the symbolic name and dotted-decimal IP address of the default network interface for the z/OS image. A failure in either EZASMI call results in failure to initialize the TCP/IP service for the z/OS address space. Confirming that the Name Resolution calls are successful: The following message indicates Name Resolution was successful: kdebprc.c,661,"interface_discovery") IPV4 interface list: 'SYSL' 9.42.46.26: source=hostname:0, seq=0, flags=0441 In this example, the interface 'SYSL' is found and source=hostname indicates that the host name SYSL was successfully resolved to an IP address. Repairing the Name Resolution failures: The following messages illustrate a Name Resolution failure: kdebprc.c,661,"interface_discovery") IPV4 interface list: 'WINMVS2C' 9.20.138.199: source=GE1, seq=0, flags=0441 kdebprc.c,214,"register_string") Unable to resolve interface address: WINMVS2C In the messages above, the absence of source=hostname indicates an interface was discovered but the name is not resolvable to an address. Typically, this error results when the z/OS image does not contain a TCP/IP resolver setup file that provides either GLOBAL or DEFAULT configuration data. Consequently, native z/OS address spaces are not enabled for name resolution by default. By adding a DD statement for SYSTCPD to the started task JCL of the IBM Tivoli Monitoring task (pointing to a usable file in USER.PARMLIB(TCPDATA)), resolver support can be enabled. The following messages illustrate a variant of name resolution failure: kdebprc.c,661,"interface_discovery") IPV6 interface list: 'NULL' "KDE1I_OpenTransportProvider") Status 1DE00048=KDE1_STC_NOINTERFACESREGISTERED The messages above indicate that no (IPV6) interface is registered. This can also result in TCP/IP service initialization failure for the IBM Tivoli Monitoring address space. The absence of an interface can only be fixed by the z/OS TCP/IP administrator. The First SEND This section provides information about confirming whether or not First SEND was successful as well as how to repair failures in the First SEND. Confirming that he First SEND was successful: The sequence of the following communication messages indicate the first SEND operation (an lb__lookup RPC request) and the first RECEIVE operation: "KDCR0_Send") request FFFF/0.0 (200): ip.pipe:#9.42.46.26[1918] "KDCR0_InboundPacket") response FFFE/0.0 (320): ip.pipe:#9.42.46.26[1918] "KDCL_GetBinding") Using LLB at ip.pipe:#9.42.46.26[1918] When the first network I/O is successful, the response indicates link and transport connectivity with the hub computer. Repairing the failures in the First SEND: There are two consideration specific to OS/390 and z/OS platforms: v RACF permission to the started task for the OMVS segment Chapter 5. Installation and configuration troubleshooting 99