Thanks Gord, but:
I don't think that a slow DNS lookup is the problem.
- The call that I'm making doesn't even do a lookup AFAIK.
- The lost time, according to the resolver trace, is before my
getaddrinfo() api call even starts. It appears to be something that
happens during initialization of the resolver connection to a z/OS Unix
process.
I don't think that "TRACE RESOLVER" is different from the resolver trace I
did via "RESOLVER_TRACE=" envar.
I found that I can also demonstrate the problem without a test program,
just doing this command:
(note the lost time between "*Resolver Trace Initialization Complete*"
and "*res_init
Started:" )*
- am I the only one who sees this with this simple test command?
> RESOLVER_TRACE=STDOUT host 127.0.0.1
*Resolver Trace Initialization Complete -> 2019/01/23 10:30:10.433856 *
res_init Resolver values:
Setup file warning messages = No
CTRACE TRACERES option = No
Global Tcp/Ip Dataset = VENDOR.TCPIP.DATA
Default Tcp/Ip Dataset = TCPIP.TCPIP.DATA
Local Tcp/Ip Dataset = None
Translation Table = TCPIP.STANDARD.TCPXLBIN
UserId/JobName = KIRK
Caller API = LE C Sockets
Caller Mode = EBCDIC
System Name = S0W1 (from VMCF)
UnresponsiveThreshold = 25
(G) DataSetPrefix = TCPIP
(G) HostName = ZOSDTL22
(G) TcpIpJobName = TCPIP
(G) DomainOrigin = DOVETAIL.COM
(G) NameServer = 8.8.8.8
EDNS0 Support = Unknown
4.4.4.4
EDNS0 Support = Unknown
(G) NsPortAddr = 53 (G) ResolverTimeout = 30
(G) ResolveVia = UDP (G) ResolverUdpRetries = 1
(*) Options NDots = 1
(*) SockNoTestStor
(*) AlwaysWto = NO (*) MessageCase = MIXED
(G) LookUp = DNS LOCAL
(*) Cache
(*) NoCacheReorder
res_init Succeeded
*res_init Started: 2019/01/23 10:30:10.973607 *
res_init Ended: 2019/01/23 10:30:10.973612
***************************************************************************
GetHostByAddr Started: 2019/01/23 10:30:10.973645
GetHostByAddr Resolving Address: 127.0.0.1
res_query(1.0.0.127.in-addr.arpa, C_IN, T_PTR)
Querying resolver cache for 127.0.0.1
EZBRECFR: RetVal = 0, RC = 0, Reason = 0x00000000
Negative Cache data from 8.8.8.8 was retrieved
res_query Failed: RetVal = -1, RC = 1, Reason = 0x78981005
GetHostByAddr Trying Local Tables
ADDRTABLE from dsprefix TCPIP.HOSTS.ADDRINFO
- Lookup for 127.0.0.1
GetHostByAddr Succeeded: Host Name is LOOPBACK
GetHostByAddr Ended: 2019/01/23 10:30:11.153701
***************************************************************************
EZZ8321I LOOPBACK has addresses 127.0.0.1
EZZ8322I aliases: LOCALHOST
This one does do a (reverse) DNS lookup, which is IMO also much slower than
it should be since I did this several times and it should have been cached,
right?
On Wed, Jan 23, 2019 at 9:57 AM Gord Tomlin <gt.ibm.li...@actionsoftware.com>
wrote:
> On 2019-01-23 08:27, Kirk Wolf wrote:
> > I had the same thought Gord.
> >
> > I already tried changing the default "LOOKUP DNS LOCAL" to "LOOKUP DNS"
> > and that didn't change anything.
>
> Did you try the reverse, i.e., "LOOKUP LOCAL DNS"?
>
> TRACE RESOLVER might also provide some additional insight. One of the
> name servers specified with NSINTERADDR could be non-responsive. We've
> been burned by that before.
>
> --
>
> Regards, Gord Tomlin
> Action Software International
> (a division of Mazda Computer Corporation)
> Tel: (905) 470-7113, Fax: (905) 470-6507
> Support: https://actionsoftware.com/support/
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
