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
