For the record, I would like to correct what I had written earlier regarding this topic.
COMMONSEARCH has little or more likely nothing to do with the problem. However, the RESOLVER function of TCP/IP can provide a resolution to the problem. You can choose to put appropriate default values in the DEFAULTTCPIPDATA location as pointed to by the RESOLVER function. These values would become "last resort" values unless overridden by the other search order values. For example, on my system, the IBM default last resort location TCPIP.TCPIP.DATA does not exist. When I run with no RESOLVER DEFAULTTCPIPDATA set, and I run a job which does not specify SYSTCPD DD, then my job which does a PING (MVS API) or TSO command FTP (z/OS UNIX API) fails. You can test this in a similar way that I did. RESOLVER is probably already running on your system. First, find out what RESOLVER is configured to do: F RESOLVER,DISPLAY EZZ9298I DEFAULTTCPIPDATA - None EZZ9298I GLOBALTCPIPDATA - None EZZ9298I DEFAULTIPNODES - None EZZ9298I GLOBALIPNODES - None EZZ9304I NOCOMMONSEARCH EZZ9293I DISPLAY COMMAND PROCESSED This is what I started with. Then, you can create two files - one with RESOLVER parms (I started with one line): In /etc/setup.resolver: DEFAULTTCPIPDATA(/etc/defaulttcpip.data) The second file is /etc/defaulttcpip.data and looks something like this (use the settings in *your* SYSTCPD DD file as your starting point for defining site wide defaults): TCPIPJOBNAME TCPIPMVS DATASETPREFIX your.prefix.TCPIP DOMAINORIGIN yourco.com NSINTERADDR xx.xx.xx.xx NSINTERADDR yy.yy.yy.yy RESOLVEVIA UDP RESOLVERTIMEOUT 30 RESOLVERUDPRETRIES 1 Then, the following to activate: F RESOLVER,REFRESH,SETUP='/etc/setup.resolver' EZZ9298I DEFAULTTCPIPDATA - /etc/defaulttcpip.data EZZ9298I GLOBALTCPIPDATA - None EZZ9298I DEFAULTIPNODES - None EZZ9298I GLOBALIPNODES - None EZZ9304I NOCOMMONSEARCH EZZ9293I REFRESH COMMAND PROCESSED Make sure the permissions for /etc/defaulttcpip.data are 644 so that everyone can read it. Now, after these changes, standard resolver search for all TCP/IP APIs includes, as a last resort, the values specified in /etc/defaulttcpip.data for all address spaces in your system. To harden these values and have them take effect at the next IPL, create RESOLVER JCL as described in manual z/OS IP Config Guide topic 1.2.5.2 Resolver customization, and in particular, include the following DD statement in the RESOLVER JCL: //SETUP DD PATH='/etc/setup.resolver',PATHOPTS=(ORDONLY) While I certainly apologize to all for my incorrect posts earlier in this thread, I am grateful to this list because I sure learned a lot today about RESOLVER! Brian On Mon, 30 Oct 2006 14:31:18 -0600, Brian Peterson wrote: >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 > >On Mon, 30 Oct 2006 11:22:10 -0800, Gibbons, Mark wrote: > >>As far as I can tell. Internet retrieval creates and uses a unix process >in another address space to retrieve orders. The systcpd dd statement is >not passed to the new address space. The only method I've found that works >is to have the data be found in the standard tcp search order. I'm not >sure what the standard search order is (tcp config reference lookup a while >back) but it will find: >> >> userid.TCPIP.DATA >> SYS1.TCPPARMS(TCPDATA) >> something in /etc/ >> >>IBM needs to let us specify this data for the receive. Much like they do >the other information for client and orderserver. I'd be very happy if I >was wrong however. We don't have our tcpd data in the standard search >order. >> >>Mark >> >> >>>>Date: Fri, 27 Oct 2006 15:33:02 -0500 >>>>From: Brian Peterson >>>>Subject: Re: Receive Order Error >> >>>>OK - This result shows that the SYSTCPD DD statement is required for your >>>>RECEIVE job, and should fix your problem where RECEIVE is unable to >resolve >>>>the inetsd01.boulder.ibm.com address - the "unknown host" error. >>.... >>0:04 -0500, Dick Renneke wrote: >> >>>With the SYSTCPD DD statement, we got this response - >>> >> ---------------------------------------------------------------------- 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
