II10962: DSNL512I RET_CODE=1 REA_CODE=00000000

APAR status

• Closed as canceled.

Error description

• This DSNL512I msg is 100% TCPIP configuration user error.
  We need TCPIP support and Q&A support to help customer checking
  the TCPIP and OMVS configuration to correct the error.
  Recycle DDF to establish the connection after the TCP
  configuation change.
  .
  See II12372 for more install info.
  5740XYR00 R510 R610 msgDSNL512I rc01 rsn0000000
  DDF users encounter the following message at startup:
  
    DSNL512I + DSNLILNR TCP/IP GETHOSTBYADDR FAILED WITH
                RETURN CODE=1 AND REASON CODE=00000000
  DESCRIPTION: The GetHostByAddr() call in DDF tries to resolve
  the FIRST IP address which appears in the HOME list in
  PROFILE.TCPIP to a hostname (or the PRIMARYINTERFACE).  The
  GetHostByAddr() call tries to resolve the name via DNS or if a
  nameserver is not present, or does not have an answer, then the
  local host tables are used.
  See DOC APAR PQ30957 for further explanation of this message.
     A resolver trace is recommended to isolate the problem.  A
  resolver trace can be obtained by coding TRACE RESOLVER in
  TCPIP.DATA.  If the problem is recreated with a resolver trace
  active, then additional trace output will be found in the JES
  DDF started task ssnmDIST.  Please note that a cycle of TCPIP
  or a VARY OBEY is NOT necessary to enable the resolver trace.
     The following sections list possible causes and solutions
  for the DSNL512I message based on the output of the resolver
  trace:
  
  CAUSE:  Resolver configuration dataset cannot be accessed by DDF
  SYMPTOM:  TRACE RESOLVER is coded, but resolver trace output
           does not appear in the JES log for the DDF task
  RESOLUTION:  DDF is most likely using the incorrect resolver
  configuration dataset. The search order for the resolver
  configuration dataset is:
         1. /etc/resolv.conf file
         2. //SYSTCPD dd statement  (not recommeneded)
         3. jobname.TCPIP.DATA
         4. SYS1.TCPPARMS(TCPDATA)
         5. TCPIP.TCPIP.DATA
  The first dataset found in the above list will be used as the
  configuration dataset for the DDF application.  For example, if
  both /etc/resolv.conf AND SYS1.TCPPARMS(TCPDATA) datasets
  exist,  the DDF application will ONLY use the /etc/resolv.conf
  dataset because it appears first on the search list.  Also
  verify the DDF application has READ access to the dataset (or
  read permissions for HFS files if /etc/resolv.conf is used).
  
  CAUSE:  DNS nameserver is not available.
  SYMPTOM: The following message will appear in the resolver trace
                     res_query: send error
  RESOLUTION:  If you are not using DNS, you may skip this section
  If you are using DNS, verify that the IP addresses on the
  NSINTERADDR statements in you resolver configuration dataset (or
  NAMESERVER statements in /etc/resolv.conf) refer to an active
  nameserver.  Also verify the system has network connectivity to
  the nameserver.
  
  CAUSE: The DNS namserver responds, but does not provide an
         answer to satisfy DDF.
  SYMPTOM:  Resolver trace will show the following messages:
                     rcode = 3, ancount=0
                     res_search failed, errno = 0 or 49
  RESOLUTION:  If you are not using DNS, then you may skip this
  section. If you are using DNS, please be aware that DDF requires
  a reverse mapping (PTR record) for the first IP address which
  appears in the HOME list in PROFILE.TCPIP.  If the PTR mapping
  between first IP address in the HOME list and a hostname is
  missing, please add this PTR record to the nameserver.  If you
  do not not wish to have this IP address in DNS, you may add the
  entry the local hosts table (see next section).
  
  CAUSE: Local hosts table cannot be found or required entry is
         not in the hosts table
  SYMPTOM:  Resolver trace will show:
                no nameserver, using hosts.addrinfo
                      OR
                entire addrinfo searched
  RESOLUTION:  DDF is most likely using the wrong host table or
  the hosts table is in the wrong format.  The search order for
  the reverse local hosts table is:
     1.  Value of the X_ADDR environment variable
     2.  HFS file /etc/hosts
     3.  userid.HOSTS.ADDRINFO where userid is the user ID
         associated with the current address space or thread.
     4.  hlq.HOSTS.ADDRINFO where hlq is the value of
    The first dataset found in the above list will be used as the
  table for reverse lookups for the DDF application.
    The /etc/hosts HFS file and the HOSTS.ADDRINFO dataset have
  different formats. A HOSTS.ADDRINFO dataset is generated by
  modifying the HOSTS.LOCAL dataset and then running the MAKESITE
  command.
  The HOSTS.LOCAL dataset has the following format:
    ;  Top of example HOSTS.LOCAL
    ; Comments for HOSTS.LOCAL start with a semi-colon
    ; format of this file is:
    ; HOST : <IP address> : <hostname> ::::
    ; for example:
    HOST : 10.2.3.4 : test
    ; END of example HOSTS.LOCAL
  
  If the HFS file /etc/hosts is used, then the hosts table has
  the following format:
    # Top of example /etc/hosts host table
    # Comments for /etc/hosts start with a hash symbol
    # All entries MUST start in column 1
    # Format of this file is:
    # <IP address>   <Hostname>
    # for example:
    10.2.3.4    test
    # End of example /etc/hosts host table
  .
  /* user tcpip configuration setup error      */
  User has switched OEM Interlink TCPIP stack to IBM stack and
  still has the old Interlink TCPIP definition in the BPXPARM
  Unix Service definition files. When START DDF, user received
  DSNL512I GETHOSTID TCPIP RC122 for EIO for IO error and
  rsnC1000001 for reason code which is not IBM reason code.
  Interlink TCPIP definitions should be removed to avoid this prob
  Workaround is to run the following BPXTCAFF JCL in the DDF start
  task to point to the desired tcpip stack.
  .
  TCPIP RC=122 RC122 RSNC1000001 C1000001 Reason=C1000001
  .
  *** NOTE: SYSTCPD DD statement does not work with CINET ***
  Unix System Services has added a new DD JOB step to allow a DB2
  subsystem to be associated to a specific TCP/IP stack for use
  with CINET. Refer to OE APAR OW40460 for details.
  The use of systcpd dd statement does not work with CINET.
  For DB2, an extra STEP0 to be inserted in front of DB2's started
  task:
    SYS1.PROCLIB(DB2PROC)
        //STEP0    EXEC,PGM=BPXTCAFF,PARM=TPNAME
        //DB2STEP  EXEC,PGM=DB2,PARM='DB2s parms'
        //DB2DATA  DD   DSN=...
  .
  
  ================================================================
  When initializing an TCP stack for use with a VIPA, the TCP
  profile should contain the HOME list with the VIPA, followed
  by the PRIMARYINTERFACE statement pointing at the appropriate
  VIPA to be used by DB2.
  .
  CAUTION: Do not change the stack's HOME list or the
  PRIMARYINTERFACE while DDF is started. The PRIMARYINTERFACE and
  the stack's HOME list may be changed (via the VARY OBEY command)
  while the stack is running, without recycling the stack.
  As far as the stack is concerned, the new profile used with
  VARY OBEY may contain a new PRIMARYINTERFACE statement, a new
  HOME list, both, or neither.  However, if a new HOME list is
  specified via the VARY OBEY file, replacing the former HOME list
  and the same VARY OBEY file does not also respecify
  PRIMARYINTERFACE to be the same VIPA or a different VIPA or
  other link in the new HOME list. then the PRIMARYINTERFACE for
  gethostid() reverts back to the IP address of the first link in
  the HOME list.  In other words, a new HOME list overrides any
  prior PRIMARYINTERFACE unless the PRIMARYINTERFACE is specified
  again as a part of the same VARY OBEY file.  Therefore, customer
  who specify PRIMARYINTERFACE and who also wish to change the
  list via VARY OBEY must ensure that the VARY OBEY file with
  the new HOME list also contains a PRIMARYINTERFACE statement,
  even if the PRIMARYINTERFACE statement simply
  specifies the same virtual link as before.
  ==============================================================
  OS/390 V2R8 Dynamic VIPA support
  .
  DB2 doesn't support Dynamic VIPA. The use of Dynamic VIPA
  (VIPDADEFINE/VIPABACKUP) to force a DB2 susbsystem to override
  the INADDR_ANY configuration breaks DB2's sysplex workload
  balancing and commit resynchronization.
  .
  DB2 is adding support for Dynamic VIPA using the Bind Server
  Control feature in V2R10. The current plan is to deliver
  the fix via an APAR in the 2Q01 timeframe.
  ==============================================================
  Refer to IP Configuration Reference for dealing with
  "Dynamically changing TCPIP.DATA statements".
  After the TCPIP.DATA statements are changed, this operator
  command is needed, ie. MODIFY  RESOLVER,REFRESH. This informs
  the resolver that a change has been made to the TCPIP.DATA
  statements (to be complete this can also be used to change
  resolver local host tables e.g., /etc/hosts and HOSTS.LOCAL
  definitions). The next time a long running program (e.g.
  DDF) does an API call, (ie. gethostbyaddr) the resolver will
  re-read the TCPIP.DATA statements use the values at that time.
  ================================================================
  

Local fix

Problem summary

Problem conclusion

Temporary fix

Comments

• Closing Informational APAR.
  DB2INFO
  for additional DB2 TCPIP info see:  II11164 II11263
  

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