IBM E027SLL-H - Tivoli Monitoring - PC, Руководство по устранению неисправностей, Страница: 117 / 310

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