Troubleshooting
Problem
Connection to Db2 for i can experience longer than normal connection times.
Symptom
Connections to the local database take longer than expected.
Cause
During the connection to the DDM/DRDA server, the host performs a name lookup by using the "getnameinfo" sockets API. This function makes use of the TCP domain configuration settings on IBM i to perform a lookup of the host name for the client IP address. When there are delays in initial connection to the server, it is usually because a misconfiguration of DNS information is causing a delay in the lookup process. Check the configuration by prompting the CHGTCPDMN command (type CHGTCPDMN and press F4). It is atypical to have the 'Host name search priority' value set to *REMOTE. Normally, you want to have the host table searched first before remote DNS lookup.
The delay usually results from having one or more incorrect TCP/IP addresses listed for the 'Domain name server' 'Internet address' values. When one of the values listed here is not an active DNS server, it causes a timeout to occur when the IBM i attempts to connect to the DNS server. Press the F10 key on the CHGTCPDMN screen to view or set the number of retries and initial time interval values to limit the impact of those delays. The initial time interval value is the amount of time in seconds that IBM i waits before retrying the connection. Each retry doubles the timeout interval of the previous request. The number of retries is exactly what it sounds like. As an example, if the number of retries is set to 4 and the initial time interval is 2, and the DNS server is not responding: The first attempt to reach it takes 2 seconds to time out. The second takes 4, the third takes 8, and the final attempt takes 16 seconds. That results in a total of 30 seconds that you must wait for your DRDA connection to be established while waiting for a DNS server response.
Diagnosing The Problem
If this problem is suspected, the callstack of the job in question can be examined (WRKJOB, Option 11). If the last call stack entry shows "getnameinfo", it is an indication that the problem is happening. Alternatively, a job trace can be collected to see whether the calls to "getnameinfo" are taking abnormally long.
Resolving The Problem
Clearly, the best solution to this problem is to not have incorrect or inactive DNS servers listed in the CHGTCPDMN information. But if it is unavoidable, then you can set the timeout values low to reduce the impact.
The NSLOOKUP tool is a quick way to test whether the name resolution through your DNS servers is working. For example,
NSLOOKUP HOSTNAME('1.2.3.4'). While your DNS servers probably can't find a name registered for that address, it should come back with a response immediately. If it takes several seconds to get a response, then your system is trying to reach a DNS server that is not active or does not exist at all. To test out the validity of your DNS server entries, you can test them again using the NSLOOKUP tool and specifying the DNS server address like this: NSLOOKUP HOSTNAME('RCH730A.711.LAB') DMNNAMSVR('172.16.3.4'). This command tests the DNS server at 172.16.3.4 for a record for the host name RCH730A.711.LAB. And in this case that takes several seconds to return the result: ";; connection timed out; no servers could be reached" telling me that 172.16.3.4 is not an active DNS server.Related Information
[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SWG60","label":"IBM i"},"ARM Category":[{"code":"a8m0z0000000CHZAA2","label":"Data Access"}],"ARM Case Number":"","Platform":[{"code":"PF012","label":"IBM i"}],"Version":"All Version(s)","Line of Business":{"code":"LOB57","label":"Power"}}]
Was this topic helpful?
Document Information
Modified date:
01 October 2023
UID
nas8N1020457