I agree that he can look thru the documentation link that I provided and figure out what file(s)/data sets are being used to control name resolution from zUnix. Rather than beating the horse of my own opinions..
I would look at these... if it is not apparent how the configuration is working Search orders used in the z/OS UNIX environment Base Resolver Configuration Files: 1. GLOBALTCPIPDATA If defined, the resolver GLOBALTCPIPDATA setup statement value is used. 2. RESOLVER_CONFIG The value of the environment variable is used. This search will fail if the file does not exist or is allocated exclusively elsewhere. 3. /etc/resolv.conf 4. //SYSTCPD DD card The data set allocated to the ddname SYSTCPD is used. In the z/OS UNIX environment, a child process does not have access to the SYSTCPD DD. 5. userid.TCPIP.DATA userid is the user ID that is associated with the current security environment 6. SYS1.TCPPARMS(TCPDATA) 7. DEFAULTTCPIPDATA If defined, the resolver DEFAULTTCPIPDATA setup statement value is used. 8. TCPIP.TCPIP.DATA 9. NOTE: Any TCPIP.DATA statements that have not been found will have their default values, if any, assigned. And this list if the above list doesn't lead you to the solution. 1. X_SITE environment variable 2. X_ADDR environment variable 3. /etc/hosts 4. userid.HOSTS.xxxxINFO 5. jobname.HOSTS.xxxxINFO 6. hlq.HOSTS.xxxxINFO (probably HLQ = TCPIP) 7. GLOBALIPNODES 8. RESOLVER_IPNODES environment variable 9. userid.ETC.IPNODES 10. jobname.ETC.IPNODES 11. hlq.ETC.IPNODES 12. DEFAULTIPNODES 13. /etc/ipnodes HTH Rob Schramm Rob Schramm Senior Systems Consultant Imperium Group On Fri, Oct 11, 2013 at 12:59 PM, Jon Perryman <[email protected]> wrote: > David doesn't have the problem with various users coding different > TCPDATA. His problem is programs running UNIX for z/OS versus native z/OS > programs are getting different results. I agree that he should configure it > how he wants but I think he is misunderstanding some things that have been > said. > > Since David doesn't want to use RESOLVER, here is how I would fix this in > his specific situation: > > > 1. Choose which common TCPDATA you want to use. I've typically used > TCPIP.TCPIP.DATA. > > 2. Modify the TCPIP proc DD SYSTCPD to point at your choice. I doubt that > this DD is needed but I've always coded it. > > 3. Eliminate the other common TCPDATA files. In UNIX for z/OS, rename the > config file for TCPDATA in directory /etc (I can't remember it's name). > Rename SYS1.TCPPARMS. And any of the other common. > > I would avoid using SYSTCPD unless there is a situation where the common > TCPDATA can't be used. > > If a user reports a problem with TCP, then have them temporarily add a > SYSTCPD to the common TCPDATA as verification they are using the correct > TCPDATA (note that UNIX for z/OS programs have a couple of situations where > SYSTCPD DD does not check. > > Jon Perryman. > > > > > > >________________________________ > > From: Rob Schramm <[email protected]> > >To: [email protected] > >Sent: Thursday, October 10, 2013 11:07 PM > >Subject: Re: NSLOOKUP on MVS vs OMVS > > > > > >Jon, > > > >The problem always comes up.. someone has a name resolution problem in TSO > >or they have one in OMVS. Or worse there is one with SMTP. Each of the > >environments uses different "paths" for resolving names. And in order to > >be sure.. I have to go through each one to figure out where the problem > is. > >But by coding up RESOLVER there can be ONE way of doing things. So much > >easier.. no manuals to consult when someone has partially configured one > of > >the files that interferes with how it normally works. This is a perfect > >example for Comm Serv being really flexible and really a pain in the > >backside. Personally, I think the default should be a RESOLVER proc that > >actually is configured for common search. The funny thing is .. that > >RESOLVER always runs anyways. > > > >FWIW .. this is just my opinion. Configure your system however you want. > >But for systems I am working on .. I'll be an advocate for common search. > > > >Rob Schramm > > > >Rob Schramm > >Senior Systems Consultant > >Imperium Group > > > > > > > >On Tue, Oct 8, 2013 at 6:09 PM, Jon Perryman <[email protected]> > wrote: > > > >> Are you saying that DD SYSTCPD pointing to TCPIP.TCPIP.DATA or > >> SYS1.TCPPARM fixes your problem? These datasets should be picked up > without > >> a SYSTCPD DD. I'm confused why you feel using these requires the > resolver. > >> > >> Jon Perryman. > >> > >> > >> > >> >________________________________ > >> > From: Rob Schramm <[email protected]> > >> >To: [email protected] > >> >Sent: Monday, October 7, 2013 11:49 PM > >> >Subject: Re: NSLOOKUP on MVS vs OMVS > >> > > >> > > >> >Because that may or may not fix the issue. > >> > > >> >Setting up RESOLVER is not super hard. With the biggest benefit of > never > >> >coding SYSTCPD in a proc ever again!!! > >> > > >> >Rob Schramm > >> >On Oct 7, 2013 5:24 PM, "Jon Perryman" <[email protected]> wrote: > >> > > >> >> Is there a reason you can't update TCPIP.TCPIP.DATA or SYS1.TCPPARMS > >> with > >> >> the change? > >> >> > >> >> Jon Perryman. > >> >> > >> >> > >> >> > >> >> >________________________________ > >> >> > From: David G. Schlecht <[email protected]> > >> >> > > >> >> > > >> >> >We have a solution, or at least a workaround. We'll continue to add > >> >> SYSTCPD to every job that needs RESOLVER and will someday build an > MVS > >> proc > >> >> for RESOLVER that can use GLOBALTCPDATA. > >> >> > > >> >> > > >> >> > >> >> > ---------------------------------------------------------------------- > >> >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> >> send email to [email protected] with the message: INFO > IBM-MAIN > >> >> > >> > > >> >---------------------------------------------------------------------- > >> >For IBM-MAIN subscribe / signoff / archive access instructions, > >> >send email to [email protected] with the message: INFO IBM-MAIN > >> > > >> > > >> > > >> > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to [email protected] with the message: INFO IBM-MAIN > >> > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to [email protected] with the message: INFO IBM-MAIN > > > > > > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
