Proposal for enhanced z/TPF DNS Client behavior and alerting

On June 13, 2025 at our site, we again experienced a similar issue with the z/TPF DNS Client's access to the DNS server in our datacenter.  Within our datacenter, we have two redundant DNS servers, which we target from our TPF mainframes by their respective IPs in the z/TPF DNS Client 'ZDTCP DNS PRI/SEC' table.  During a planned network change, the path from the z/TPF hosts to the Primary DNS server was disrupted for a time.  No connection failures were observed, since 'gethost' API attempts to target the Primary would experience timeout, but would be satisfied in the re-attempt to the Secondary DNS server.  We do cache hostname resolutions, and have an adequately sized IDNSHOSTNAME cache to contain all the resolutions we want.  However, these will of course timeout in cache periodically and eventually require a resolution anew.  When that occurs, we do have some applications that are sensitive to the latency encountered when the 'gethost' resolution must first undergo the timeout on the call to the Primary before it is satisfied on the re-attempt to the Secondary.  Once again, it would be helpful if 1) There was some sort of statistic, monitoring, or alert that was provided to indicate that 'gethost' resolution attempts to the Primary were failing and having to be re-attempted to the Secondary, or 2) As is under consideration in this RFE TPF-I-1062, if the z/TPF DNS Client did have some means of tracking the success of calls to the Primary and, when some failures are observed, temporarily perform first attempts to the Secondary; there is still interest and merit to such a feature.  At the least, visibility that failures on calls to the Primary is occurring would be a helpful thing - providing options for Automation to reverse the order of the ZDTCP NDS PRI/SEC, at least for some interval.  On this latest incident, it would have been helpful if alerts could have pointed out this was occurring, although we figured it out fairly quickly.

If you look too close at the information from last year where we experienced a DNS server incident, leading to a submission of a Support Case and subsequently this RFE being submitted, you might see that occurred just over a year-to-the-day of this incident - 06/12/2014 last year, 06/13/2025 this year.  That is merely a coincidence.

Anyway, wanted to provide some additional testimony about the interest in this RFE TPF-I-1062.

Regards,

Brent Worden - DXC Technology - Tulsa, Oklahoma

One additional item to add to the RFE.  Within the aforementioned Support Case TS016560816, there was some discussion of whether the existing hard-coded 2-second Timeout wait for a response from the DNS Server could instead be made a configurable value, and what that would require.  In the wake of the recent DNS server incident that occurred at our site, the follow-up discussions have produced considerable interest in whether that timeout value could be made configurable - including sub-second.  Opinions have been expressed that 2 seconds is an overly generous amount of time for such a response.  As part of this RFE, we do also ask that IBM explore whether the timeout value for requests to the DNS server could be made configurable - including a sub-second value.