I must have missed where it is defined in the documentation that the SYSTCPD DD in the TCP proc is ignored. Everything I've read says it's used without restriction if it is reached in the search order.
David G. Schlecht | Information Technology Professional State of Nevada | Department of Administration | Enterprise IT Services T:(775)684-4328 | F: (775) 684‐4324 | E:[email protected] -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Rob Schramm Sent: Friday, October 11, 2013 3:30 PM To: [email protected] Subject: Re: NSLOOKUP on MVS vs OMVS 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
