Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 1: Base Functions, Connectivity, and Routing

Chapter 2. The Resolver 43

contents of this trace will be explained in Diagnosing the Resolver address space

environment.

2.4.5 Diagnosing the Resolver address space environment

To diagnose Resolver problems we can use two kinds of trace tools: The TRACE

RESOLVER, which provides information that can be helpful in debugging problems an

application program could have with using Resolver facilities (for example, GetHostByName

or GetHostByAddr); and the Component Trace RESOLVER (SYSTCPRE) for diagnosing

Resolver problems that cannot be isolated to one particular application.

In this section we provide a brief explanation of when to debug, which trace has to be used,

and how to use these trace facilities. To find more information about Resolver diagnosis, refer

to the z/OS Communications Server: IP Diagnosis Guide, Version 1 Release 7,

GC31-8782-06.

Deciding which tool to use to diagnose a Resolver problem

The first thing to do when diagnosing a possible Resolver problem is to check the symptoms

to verify if it is indeed a Resolver problem (see Table 2-2).

Table 2-2 What to do if the host name cannot be reached

TRACE RESOLVER

The Trace Resolver tells what the Resolver looked for (the questions) and where it looked

(name server’s IP addresses or local host file names).

The following situations can be checked in the trace output:

򐂰 Fix or check any problems reported at the top of the trace. These are errors in the

Resolver data sets.

򐂰 Are the data sets being used by the Resolver the ones you expected? If not, see the

search orders for data sets in the z/OS Communications Server: IP Configuration Guide,

Version 1 Release 7, SC31-8775-07.

򐂰 Check if the data sets defined to be used are authorized by RACF and can be read by the

application, TCP/IP stack, or user.

When we ping a host name,

the ping command:

What is the problem? Solution

Succeeds, but another

application fails when resolving

the same host name.

The problem is with the

Resolver configuration for the

application in the users

environment.

Use the Trace Resolver

statement on the local

TCPIP.DATA used by the

application, which has the

problem.

Fails, but the host name is

converted to an IP address.

The resolution is successful but

the host is not reachable or

active.

This problem is related to

connectivity, not a resolver

problem.

Fails to convert the name to an

IP address.

The problem might be with the

resolver configuration,

searching local host files, or

using DNS.

Use Trace Resolver to solve the

problem.

Tip: If the problem seems to be related to the DNS, use the LOOKUP statement to define

to check the local files first.

44 Communications Server for z/OS V1R7 TCP/IP Implementation, Volume 1 - Base Functions, Connectivity, and Routing

򐂰 Check the TCPIP.DATA parameter values, especially Search, NameServer,

NSINTERADDR, and NsPortAddr.

򐂰 Check the questions posed by the Resolver to DNS or in searching the local host files. Are

these the queries you expected?

򐂰 Look for errors or failures in the trace.

򐂰 Did DNS respond (if you expected it to)? If not, see whether DNS is active at the IP

address you specified for NameServer and NSINTERADDR and what port it is listening

on. Also, DNS logs can be helpful. Ask the DNS administrator for help.

To set up the trace Resolver, define the statement TRACE RESOLVER or OPTIONS DEBUG

in the first line of the TCPIP.DATA data set being used by the application that has the

problem you want to diagnose (see Example 2-15).

Example 2-15 Using the OPTIONS DEBUG to get a trace of the resolver

OPTIONS DEBUG

TCPIPJOBNAME TCPIPA

HOSTNAME WTSC32A

DOMAINORIGIN ITSO.IBM.COM

DATASETPREFIX TCPIPA

MESSAGECASE MIXED

NSINTERADDR 10.12.6.7

NSPORTADDR 53

The resulting messages for a failing request are shown in Example 2-16.

Example 2-16 Failing local search

Resolver Trace Initialization Complete -> 2005/10/14 17:22:44.795904

res_init Resolver values:

Global Tcp/Ip Dataset = TCPIPA.TCPPARMS(GLOBAL)

Default Tcp/Ip Dataset = None

Local Tcp/Ip Dataset = //DD:SYSTCPD

==> TCPIPA.TCPPARMS(DATAA32)

Translation Table = Default

UserId/JobName = CS03

Caller API = TCP/IP Sockets Extended

Caller Mode = EBCDIC

(G) DataSetPrefix = TCPIP

(L) HostName = WTSC32A

(L) TcpIpJobName = TCPIPA

(G) Search = ITSO.IBM.COM

IBM.COM

(*) NameServer(s) = None

(G) NsPortAddr = 53 (G) ResolverTimeout = 10

(G) ResolveVia = UDP (G) ResolverUdpRetries = 1

(*) Options NDots = 1 (L) Options Debug

(*) SockNoTestStor

(*) AlwaysWto = NO (G) MessageCase = MIXED

(G) LookUp = LOCAL

GetAddrInfo Started: 2005/10/14 17:22:44.810254

GetAddrinfo Invoked with following inputs:

Host Name: HOST1

No Service operand specified

Hints parameter supplied with settings:

ai_family = 0, ai_flags = 0x00000062

ai_protocol = 0, ai_socktype = 0

No NameServers specified, no DNS activity