IBM Support

Diagnosing resolver problems

Troubleshooting


Problem

Learn what to do when the data set names you are using do not resolve.

Resolving The Problem

What to do when you think you have a name resolution problem
This document will help you solve name resolution problems. The methods described pertain to the IPv4 environment.

If you think you have a name resolution problem, there are several basic tasks to complete to fix the problem. There are separate sections below for each of these tasks.

  1. Determine what TCPIP.data statements are being used.
  2. Determine why the resolver call failed.

Once you know both of these things, you will be able to fix the name resolution problem.

Think about answers to these question as you begin to investigate:
  • What environment are you in? TSO? Batch? z/OS UNIX?
  • Has anything changed in your environment?
  • What applications are failing? Which ones are not failing?
  • What is the name to the resolver configuration file are you using?
  • What action are you taking as you experience this problem?
  • Are you upgrading?
  • What applications are you running -- DB2, CICS?

Determine whether you experience any of the following symptoms:
  • You receive a message that says "Unknown host" or "Host not found"
  • GethostbyADDR failed, GethostbyName failed, GetADDRinfo failed, or GetNameinfo failed
  • You receive message DSNL512I
  • DNS is not responding; this might not be just a configuration issue
  • You experience long delays in name resolution. (For example, does your ping of a hostname take longer than you expect?)

Actions to take when you think you have a name resolution problem:
Before you begin:
  • Familiarize yourself with the required background information.
  • Read the section about understanding resolvers in z/OS Communications Server: IP Configuration Guide.
  • Read Steps for resolving the hostname in z/OS Communications Server: IP Diagnosis Guide.
  • Research the search order you are using. Because each application obtains its TCPIP.data statement from a resolver configuration file, begin by examining the search order the system is using to find the values for this data set. When you know the search order, you can ensure you are accessing the appropriate files in the correct order. See the information about resolver configuration files in z/OS Communications Server: IP Configuration Guide.

In addition to verifying the search order, you need to ensure the content in the files being accessed is what you expect.
  • Determine whether you have customized the resolver by looking at the RESOLVER PROC value from the system operator command to display OMVS options.
    • d omvs,o
      BPXO043I 11.28.16 DISPLAY OMVS
      OMVS 000E ACTIVE OMVS=(N0)
      CURRENT UNIX CONFIGURATION SETTINGS:

      .................

      RESOLVER PROC = DEFAULT

    If RESOLVER PROC value is:
    • DEFAULT - the name of the resolver start procedure is RESOLVER
    • any other value - the resolver start procedure name is that value

Using the resolver start procedure name, display the resolver setup configuration information.
modify resolver,display
EZZ9298I DEFAULTTCPIPDATA - None
EZZ9298I GLOBALTCPIPDATA - None
EZZ9298I DEFAULTIPNODES - None
EZZ9298I GLOBALIPNODES - None
EZZ9304I NOCOMMONSEARCH
EZZ9293I DISPLAY COMMAND PROCESSED
The values you see in this display are used in the resolver search order.

1. Determine what TCPIP.data statements are being used


1. Run the Trace Resolver in 2 environments. See z/OS Communications Server: IP Diagnosis Guide for instructions on how to perform the trace.
Establish the resolver trace environment:
z/OS UNIX environment
Issue these commands from the z/OS UNIX shell:
  • export RESOLVER_TRACE=stdout
  • netstat -u > /tmp/netstat.restrace
  • obrowse /tmp/netstat.restrace

Native MVS environment
Issue these commands from TSO:
PREALLOCATE a sequential MVS data set (xxxx.RES.TRACE) with RECFM FB and LRECL=128
  • ALLOC FI(SYSTCPT) DA('xxx.RES.TRACE')
  • NETSTAT UP
Browse xxxx.RES.TRACE

2. Review resolver output of Netstat. Interpret the resolver trace output using z/OS Communications Server: IP Diagnosis Guide. Example:
                                                                 
 Resolver Trace Initialization Complete -> 2007/10/24 10:45:36.772085        
                                                                             
 res_init Resolver values:                                                    
  Global Tcp/Ip Dataset  = None                                              
  Default Tcp/Ip Dataset = None                                              
  Local Tcp/Ip Dataset   = SYS1.TCPPARMS(TCPDATA)                            
  Translation Table      = Default                                            
  UserId/JobName         = USER178                                            
  Caller API             = TCP/IP Sockets Extended                            
  Caller Mode            = EBCDIC                                            
  (L) DataSetPrefix = TCPCS                                                  
  (L) HostName      = MVS057                                                  
  (L) TcpIpJobName  = TCPCS                                                  
  (L) DomainOrigin  = tcp.raleigh.ibm.com                                    
  (L) NameServer    = x.x.x.x
                                             
  (L) NsPortAddr    = 53            (L) ResolverTimeout    = 30              
  (L) ResolveVia    = UDP           (L) ResolverUdpRetries = 1                
  (*) Options NDots = 1                                                      
  (*) SockNoTestStor                                                          
  (*) AlwaysWto     = NO            (*) MessageCase        = MIXED            
  (*) LookUp        = DNS LOCAL                                              
 res_init Succeeded                                                          
 res_init Started: 2007/10/24 10:45:36.821747                                
 res_init Ended: 2007/10/24 10:45:36.821760                                  
 ***************************************************************************  
 res_init Started: 2007/10/24 10:45:36.823236                                
 res_init Ended: 2007/10/24 10:45:36.823252                                  
 ***************************************************************************  
 MVS TCP/IP NETSTAT CS V1R7       TCPIP Name: TCPCS           14:45:36        
 Tcpip started at 14:45:16 on 10/24/2007 with IPv6 enabled                    
 READY

See the section about the z/OS UNIX batch environment in z/OS Communications Server: IP Diagnosis Guide for an explanation of the fields in the trace and an example of the trace.
The key things to check in the output are:
  • Any error messages (at the beginning of the output)
  • What (if anything) is defined as the global tcpip data set
  • What (if anything) is defined as the default tcpip data
  • What is defined as the local tcpip data
  • What are the values of the different statements and where did they come from?
To determine where the values originated, here is an explanation of the abbreviations you will see :

* Default value (the resolver defined the variable )
    D Default file (not used if the local file is found)

    E Environment variable

    G Global file

    L Local file

    Remember your goal during this task is to detect which TCP/IP data statements are being used and if the values are what you are expecting.

    3. Determine whether you are using the files you expect to be using.
    If No --
    • If using TSO - review the native MVS search order in z/OS Communications Server: IP Configuration Guide.
    • If using the z/OS UNIX shell - review the z/OS UNIX search order in z/OS Communications Server: IP Configuration Guide.
    • If the files are not what you are expecting, you might need to customize the resolver.

    Return to Step 1, retry what originally failed. If it still fails, rerun the resolver trace.

    If Yes -- check that the values picked up in these files are what you want.
    • If they are, then keep on investigating. Go to the next step (Determine why the resolver called failed).
    • If they are not, edit the file and fix it.

    You are done with this task when you have determined that the values of the tcpip.data statements are the ones you want to use.

    2. Determine why the resolver call failed

    To determine why the resolver call failed, investigate whether the resource you are trying to resolve is the correct value. You could be picking up the wrong resource from the TCP/IP stack.
    • If the resource is not correct, answer these questions:
      • Is the resource a hostname? Determine the origin of the hostname. Some applications use the gethostname call to obtain the TCP/IP hostname. The returned hostname is used in gethostbyname/getaddrinfo. To determine how gethostname obtains the hostname, see z/OS Communications Server: IP System Administrator's Commands.
      • Is the resource an IP address? Determine the origin of the IP address. Some applications use the gethostid call to obtain the IP address. The returned IP address is used in gethostbyaddr/getnameinfo. To understand how the IP address is determined, see the PRIMARYINTERFACE statement in z/OS Communications Server: IP Configuration Reference Guide.
    • If the resource is correct, see the z/OS Communications Server: IP Diagnosis Guide.

    You are done with this task when you have determined why the hostname failed to resolve.

    [{"Product":{"code":"SSSN3L","label":"z\/OS Communications Server"},"Business Unit":{"code":"BU054","label":"Systems w\/TPS"},"Component":"All","Platform":[{"code":"PF035","label":"z\/OS"}],"Version":"1.7;1.8;1.9;1.10;1.11;1.12;1.13;2.1;2.2","Edition":"All Editions","Line of Business":{"code":"LOB35","label":"Mainframe SW"}}]

    Document Information

    Modified date:
    15 June 2018

    UID

    swg21288859