II14515: DSNL512I DSNLILNR GETADDRINFO FAILED WITH RETURN CODE=1 AND REASON CODE=78AE1004

APAR status

• INTRAN

Error description

• Description:
  **********************************************************
  The following message may be issued during DB2 9 for z/OS DDF
  startup when DB2 9 for z/os
  is not able to obtain an IP address for DB2
  DDF because there was a failure in resolving the host name that
  was learned on TCP/IP startup.
  This may also be seen at DB2 10 for z/os.
  
  
  DSNL512I  -DBP1 DSNLILNR TCP/IP GETADDRINFO(hostname)
  FAILED WITH RETURN CODE=1 AND REASON CODE=78AE1004
  
  The hostname indicated in the parenthesis of the DSNL512I
  message is usually not an expected hostname. However, this is
  what was learned by TCP/IP on startup.
  
  The following information is explained further detail in the
  publication titled
  "DB2 9.1 for z/OS Installation Guide" (GC18-9846-xx).
  Chapter 8. Working with additional capabilities for DB2 see the
  section titled "Starting TCP/IP support".
  
  DB2 obtains the user-specified IP addresses by resolving the
  host name. If the host name can not be resolved, the above
  message is issued. Until the local host information is
  available, DDF TCP/IP services are not available to local and
  remote applications. If a failure occurs obtaining the local
  host information, DDF periodically attempts to get the local
  host information until successful or until DDF is stopped. When
  DDF encounters a getaddrinfo failure, it still comes up for SNA
  connectivity but it can't accept any TCP/IP requests until
  getaddrinfo is successful.
  
  During DDF TCP/IP initialization, DB2 first determines its host
  name using a GetHostName socket call. DB2 must then determine
  its IP address. If an IP address is specified in the BSDS using
  the DSNJU003 utility, or on the PORT statement in the TCP/IP
  profile, then DB2 uses this IP address. Otherwise, DB2 executes
  a GetAddrInfo(host-name) socket call, using the host-name that
  was returned on the prior GetHostName socket call, which returns
  the first matching IP address listed in the name server or local
  host table.
  
  An additional symptom which may be seen if
  the IP address can not be resolved back to a fully
  qualified hostname.
  The following message may be issued:
  DSNL512I   DSNLILNR TCP/IP
  GETNAMEINFO(dotted ip address) FAILED WITH
  RETURN CODE=1 AND REASON CODE=78AB1004
  
  
  
  DIAGNOSTICS
  *************************************************************
  The following steps should be taken to determine what the
  correct hostname should be as well as why it will not resolve to
  an IP address.
  
  Step #1) Use the OMVS/UNIX command hostname -g to determine the
  hostname returned for the LPAR
        Is this the correct hostname you expect? If YES, then skip
  to bullet 2, otherwise
     continue reading.
  " The TCPIP started task determines its host name when it is
  started. Its configuration component issues a LE __iphost() call
  to get the value of the stack's TCPIP.DATA HOSTNAME statement.
  The z/OS UNIX search order is used to find the stack's
  TCPIP.DATA statements. The host name is determined in the
  following order:
  1. If the found TCPIP.DATA contains a valid HOSTNAME statement,
  its value is returned.
  2. If there is no valid HOSTNAME statement, the VMCF node name
  with which VMCF was started is returned.
  3. If VMCF was not active when the stack was started, the
  CVTSNAME value (this is the SYSNAME=value in IEASYSxx that was
  IPLed) is returned.
  
  If the host name came from TCPIP.DATA, it is in the message case
  it was specified on the HOSTNAME statement. For VMCF or CVTSNAME
  the name is upper case.
  If you cannot determine why TCPIP has the wrong name, add a
  SYSTCPT DD to the TCPIP proc and restart TCPIP.  This will
  enable resolver tracing of TCPIP.
  
  Once you fix the hostname issue, TCPIP will have to be recycled
  to pick up this change.
  NOTE: If you recycle TCPIP for this change, DB2 will
  also need to be recycled once TCPIP is up.
  
  Step #2) If this hostname is correct, does it resolve to a valid
  IP address?
  " Use the OMVS/UNIX command host.
  host host-name
  What does this return? Do you get an error that the host is
  unknown?
  EZZ8342I junk: Unknown host
  
  Has this hostname been added to the DNS?
  If YES and the name still does not resolve to an IP address,
  enable a resolver trace for the OMVS session and issue the host
  command again:
  Export RESOLVER_TRACE=stdout
  host host-name
  If you make any changes to the DNS or local host file, then you
  need to refresh the resolver.
  
  
  Step #3) Does the ip address resolve to a fully
  qualified domain name?
  Use the following command to verify that a fully qualified
  domain name is returned and it is the fully qualified domain
  name expected for DB2.
     host <ip_address>
  where <ip_address> is the ip address the host command returned
  in prior steps
  Ensure this resolves to the expected hostname
  
  
  NOTE: The DSNL512I message will attempt retry every 3 minutes.
  Once the issue on the host-name resolution is corrected, the
  DSNL512I should stop on the next successful retry. However, if
  it does not, a recycle of DDF may be required.
  
  
  NOTE: If you make any changes to the DNS or local host file,
  then you need to refresh the resolver. If the refresh of the
  resolver is not done, then DB2 will have to be recycled to
  pick up this information. A start and stop of DDF will not
  pick up the information.
  
  
  ADDITIONAL KEYWORDS AND SYMPTOMS:
  *************************************
  5740XYR00
  DB2 DB2DDF DDF
  DSNL512I
  78AE1004 78AB1004
  

Local fix

• no local workaround
  

Problem summary

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels