Jon, Thanks for the reply. The problem is that I understood the documentation to say that the DD statement in the TCP proc would be used, if nothing else. But that’s not the case. Perhaps it is the case if we had a resolver proc, and perhaps it isn't, but at the moment, we don't have a resolver proc.
This means that if a job doesn't allocate the SYSTCPD DD then nothing gets used and the name resolution fails, even though the DD is defined in the TCP proc. 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 Jon Perryman Sent: Friday, October 11, 2013 10:00 AM To: [email protected] Subject: Re: NSLOOKUP on MVS vs OMVS 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
