Brian COMMONSEARCH affects only the name to address and address to name function of the "resolver". It does *not* affect where the "client data set" (TCPIP.DATA) is to be found. The influence of COMMONSEARCH, one of the "resolver setup statements", can be seen when the SETUP statement, one of the "client data set" (TCPIP.DATA), statements, specifies LOCAL, namely that a file is to be used to perform the conversion of name to address or address to name rather than or in addition to using the name server which is indicated by specifying DNS.
If a file is to be used, the following rules determine which file and, consequently, which format. Here are more of the notes I created for that earlier post I mentioned in my response to Mark's post: <quote> Local host tables ================= Used if specified by - LOOKUP LOCAL in "client data" file - TCP/IP C/C++ API applications with a RESOLVE_VIA_LOOKUP symbol in source - a testing facility IPv4 with NOCOMMONSEARCH ------------------------ * Environment variable - X_yyyy -> x.HOSTS.yyyyINFO * /etc/hosts # x.HOSTS.yyyyINFO hlq.HOSTS.yyyyINFO TCPIP.HOSTS.yyyyINFO * only UNIX # x is userid for UNIX and userid/jobname/procname for MVS yyyy is ADDR for address information and SITE for site information Format: "HOSTS.LOCAL" (RFC 952) CS IP Configuration Guide. section 1.5.4.2.2, "NET and GATEWAY entries" "hosts" CS IP Configuration Guide. section 2.5.5.7, "Configuring host resolvers: onslookup considerations". Used for IPv4 addresses confirmed in section 1.5.4.1, "Why configure a local host table?" IPv6 or IPv4 with COMMONSEARCH ------------------------------ Resolver - GLOBALIPNODES * Environment variable - RESOLVER_IPNODES # x.ETC.IPNODES hlq.ETC.IPNODES TCPIP.ETC.IPNODES Resolver - DEFAULTIPNODES /etc/ipnodes * only UNIX # x is userid for UNIX and userid/jobname/procname for MVS Format: "ipnodes" CS IP Configuration Guide. section 1.5.4.4, "Creating ETC.IPNODES and /etc/ipnodes" </quote> Because IPv4 with NOCOMMONSEARCH, the default, requires the creation of the HOSTS.ADDRINFO and HOSTS.SITEINFO files from the HOSTS.LOCAL file using the MAKESITE utility - which is very irritating - specifying the COMMONSEARCH "resolver setup statement" and using an "ipnodes" formatted data set - which can be edited and used straight away is massively to be preferred. But "chacun à son goût". Still keeping in mind why we are here, Dick may succeed once he has got access to the public name servers sorted out[1]. However if there is still some hang-up over using name servers, he may prefer to use a local file, at least in the interim, in which he may wish to use a local file. If he sets himself up to use the "ipnodes" format in, say, TCPIP.ETC.IPNODES, he can set up minimally the statement 207.25.253.62 inetsd01.boulder.ibm.com Well, I checked back and actually, whatever is in the file which Dick specified in the SYSTCPD DD-statement works since, although the PING failed, the name lookup succeeded. It's just a matter of specifying that file as the universal "client data file" (TCPIP.DATA) using the GLOBALTCPIPDATA "resolver setup statement" - and everything should work. Chris Mason [1] Maybe, also Dick can find out how to authorise the use of PING commands but that's not the immediate problem. ----- Original Message ----- From: "Brian Peterson" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Monday, 30 October, 2006 9:31 PM Subject: Re: Receive Order Error > Mark, you're absolutely right. I've been looking at the books and they can > set up a global search order using the RESOLVER function of TCP/IP. That > way, every address space would get the right set of TCPIP.DATA values, no > matter what they happened to specify. > > According to the books, one of the defaults within RESOLVER is > NOCOMMONSEARCH. Apparently, setting this to COMMONSEARCH allows the > installation to move away from the so-called "standard search order" and > instead have one place to define their TCPIP.DATA parameters. I use the > phrase "so-called" because the "standard search order" is ugly and hard to > understand (in my opinion) because it reflects the evolution of TCP/IP on > z/OS - based upon the API used, a totally different "standard search order" > for TCPIP.DATA parameters applies. COMMONSEARCH overcomes this by imposing > a new site-wide value. > > At least, that's what I've learned so far. Now, I'm off to try it! > > Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
