Re: Isolate lpar to resolver process
Chris Chris Mason wrote: Jorge Well, I'm glad you've worked it all out. Now the only mystery for those following this thread in the list is how your F RESOLVER,DISPLAY and //SYSTCPD DD DSN=...(TCPDATA) do *not* correspond to the "resolver trace" output you posted before! I even found where that output is explained - the z/OS Communications Server IP Diagnosis Guide manual - just to make sure I had interpreted it correctly. but it depends were the resolver trace came from. As I hinted at in a previous post, the quoted resolver trace appears to come from the TCPIP address space. If it was the user AS, then it would also contain details of the lookup.. plus the T99TCPIP userid .. unlikely to be a TSO user at 8 chars! Cheers Roy -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge Well, I'm glad you've worked it all out. Now the only mystery for those following this thread in the list is how your F RESOLVER,DISPLAY and //SYSTCPD DD DSN=...(TCPDATA) do *not* correspond to the "resolver trace" output you posted before! I even found where that output is explained - the z/OS Communications Server IP Diagnosis Guide manual - just to make sure I had interpreted it correctly. Chris Mason On Mon, 10 May 2010 03:02:09 -0500, Jorge Garcia wrote: >Hello Chris: > >>An example from the z/OS Communications Server IP System Administrators >>Commands description of the "MODIFY command: Resolver address space": > >Sorry. The command works. > >F RESOLVER,DISPLAY >EZZ9298I DEFAULTTCPIPDATA - SYS2.TCPIP.TCPPARMS(TCPDATAT) >EZZ9298I GLOBALTCPIPDATA - None >EZZ9298I DEFAULTIPNODES - None >EZZ9298I GLOBALIPNODES - None >EZZ9304I COMMONSEARCH >EZZ9293I DISPLAY COMMAND PROCESSED > > >>If you use the DEFAULTTCPIPDATA statement, you do not need to have a >>SYSTCPD DD-statement in the TSO LOGON procedure used for the >>TSO "session" in which you enter the NSLOOKUP command. Maybe I'm >>misunderstanding something here. > >Chris, we have got it. Our SYSTCPD DD in our logon procedure was >allocating TCPDATA member (production member), not TCPDATAT. We have >changed in our logon procedure and it didnt' found the dns server. > >Thanks a lot!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Hello Chris: >An example from the z/OS Communications Server IP System Administrator’s >Commands description of the "MODIFY command: Resolver address space": Sorry. The command works. F RESOLVER,DISPLAY EZZ9298I DEFAULTTCPIPDATA - SYS2.TCPIP.TCPPARMS(TCPDATAT) EZZ9298I GLOBALTCPIPDATA - None EZZ9298I DEFAULTIPNODES - None EZZ9298I GLOBALIPNODES - None EZZ9304I COMMONSEARCH EZZ9293I DISPLAY COMMAND PROCESSED >If you use the DEFAULTTCPIPDATA statement, you do not need to have a >SYSTCPD DD-statement in the TSO LOGON procedure used for the >TSO "session" in which you enter the NSLOOKUP command. Maybe I'm >misunderstanding something here. Chris, we have got it. Our SYSTCPD DD in our logon procedure was allocating TCPDATA member (production member), not TCPDATAT. We have changed in our logon procedure and it didnt' found the dns server. Thanks a lot!!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge Thanks to a very sensible suggestion from Roy, we can see that the active RESOLVER SETUP file has neither a GLOBALTCPIPDATA file allocated nor a DEFAULTTCPIPDATA file allocated. So what has happened to your RESOLVER procedure? We see only a TCPIP.DATA file allocated using a SYSTCPD DD-statement, SYS2.TCPIP.TCPPARMS(TCPDATAT), and that that file specifies the following: ALWAYSWTO NO DATASETPREFIX SYS2.TCPIP HOSTNAME HES90004 LOOKUP LOCAL MESSAGECASE MIXED (default) NSPORTADDR 53 (default) OPTIONS NDOTS:1 (default) RESOLVERTIMEOUT 30 (default) RESOLVERUDPRETRIES 1 (default) RESOLVEVIA UDP (default) SOCKNOTESTSTOR (default) TCPIPJOBNAME TCPIP TRACE RESOLVER As far as I can see this TCPIP.DATA file allocated with a SYSTCPD DD- statement and not complemented in any way by a DEFAULTTCPIPDATA file or a GLOBALTCPIPDATA file cannot possibly be allowing any reference to a name server. Would you please post the output of the NSLOOKUP command - which is using the same TCPIP.DATA file - which demonstrates that a name server is being used - and, if you can find it, post the associated TRACE RESOLVER output. > Yesterday We specified the same DD in the PROC and we haven't seen nothing wrong. I don't understand what this might mean. Chris Mason On Fri, 7 May 2010 06:30:07 -0500, Jorge Garcia wrote: >Roy, this is the SYSTCPT sysout: > >Resolver Trace Initialization Complete -> 2010/05/07 13:16:33.754109 > >res_init Resolver values: > Global Tcp/Ip Dataset = None > Default Tcp/Ip Dataset = None > Local Tcp/Ip Dataset = //DD:SYSTCPD >==> SYS2.TCPIP.TCPPARMS(TCPDATAT) > Translation Table = Default > UserId/JobName = T99TCPIP > Caller API = LE C Sockets > Caller Mode= EBCDIC > (L) DataSetPrefix = SYS2.TCPIP > (L) HostName = HES90004 > (L) TcpIpJobName = TCPIP > (*) DomainOrigin = None > (*) NameServer(s) = None > (*) NsPortAddr= 53(*) ResolverTimeout= 30 > (*) ResolveVia= UDP (*) ResolverUdpRetries = 1 > (*) Options NDots = 1 > (L) Trace Resolver(*) SockNoTestStor > (L) AlwaysWto = NO(*) MessageCase= MIXED > (L) LookUp= LOCAL >res_init Succeeded >res_init Started: 2010/05/07 13:16:33.780215 >res_init Ended: 2010/05/07 13:16:33.780219 > > >Yesterday We specified the same DD in the PROC and we haven't seen nothing >wrong. > >Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge, so this shows that your resolver parameters are coming from the local TCPDATA dd statement but is not showing the actual address resolution Where did you allocate the SYSTCPT?.. it needs to be in the address space that is doing the nslookup/ping etc.. Is T99TCPIP the userid of the TCPIP address space? Cheers Roy Jorge Garcia wrote: Roy, this is the SYSTCPT sysout: Resolver Trace Initialization Complete -> 2010/05/07 13:16:33.754109 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = //DD:SYSTCPD ==> SYS2.TCPIP.TCPPARMS(TCPDATAT) Translation Table = Default UserId/JobName = T99TCPIP Caller API = LE C Sockets Caller Mode= EBCDIC (L) DataSetPrefix = SYS2.TCPIP (L) HostName = HES90004 (L) TcpIpJobName = TCPIP (*) DomainOrigin = None (*) NameServer(s) = None (*) NsPortAddr= 53(*) ResolverTimeout= 30 (*) ResolveVia= UDP (*) ResolverUdpRetries = 1 (*) Options NDots = 1 (L) Trace Resolver(*) SockNoTestStor (L) AlwaysWto = NO(*) MessageCase= MIXED (L) LookUp= LOCAL res_init Succeeded res_init Started: 2010/05/07 13:16:33.780215 res_init Ended: 2010/05/07 13:16:33.780219 Yesterday We specified the same DD in the PROC and we haven't seen nothing wrong. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
> MODIFY RESOLVER,D > EZZ9294I INCORRECT COMMAND SYNTAX Chris, Appears that it wants DISPLAY instead of just 'D', so F RESOLVER,DISPLAY works OK Jack Kelly 202-502-2390 (Office) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge > >MODIFY xxx,D > It doesn't work > MODIFY RESOLVER,D > EZZ9294I INCORRECT COMMAND SYNTAX An example from the z/OS Communications Server IP System Administrators Commands description of the "MODIFY command: Resolver address space": Examples The following example is the command and messages returned to display the current values. f resolver,display EZZ9298I DEFAULTTCPIPDATA - None EZZ9298I GLOBALTCPIPDATA - SYS1.TCPPARMS(TCPDATA) EZZ9298I DEFAULTIPNODES - USER55.ETC.IPNODES EZZ9298I GLOBALIPNODES - None EZZ9304I NOCOMMONSEARCH EZZ9304I CACHE EZZ9298I CACHESIZE - 200M EZZ9298I MAXTTL - 600 EZZ9293I DISPLAY COMMAND PROCESSED The command is described as follows - with some effort reformatting in order to reproduce the "look" of the text! - be sure to use a nonproportional font: >>---MODIFY---procname-,->< ||| | -F-- |-Display-| |-REFRESH-| | | | | | -,SETUP=---xxx--- | | |-xxx(yyy)-| | |-'/xxx'--- | | | -FLUSH--- | | -,ALL- I'd imagined that the fact that all characters after the "D" were in lower case meant that they were unnecessary. Perhaps the manual is wrong and you need to enter "display" not simply "D", as is - sort-of - indicated in the example. Just to be sure you appreciate that the/a RESOLVER procedure has "seen" the MODIFY command, the following is an explanation of the error message: EZZ9294I INCORRECT type SYNTAX Explanation: The MODIFY RESOLVER command entered did not have correct syntax. type will be one of the following: COMMAND The syntax of the command is not correct. FILENAME The syntax for the filename specified as the setup file is not correct. System action: The MODIFY RESOLVER command is ignored. Operator response: Correct the MODIFY RESOLVER command and re-enter it. See the z/OS Communications Server: IP System Administrators Commands for more information about Resolver commands. System programmer response: None. Module: EZBREINI, EZBRECFG Procedure Name: EZBREINI, EZBRECFG > //SYSTCPD DD statement --> The TCPDATA attached in the post If you use the DEFAULTTCPIPDATA statement, you do not need to have a SYSTCPD DD-statement in the TSO LOGON procedure used for the TSO "session" in which you enter the NSLOOKUP command. Maybe I'm misunderstanding something here. Chris Mason On Fri, 7 May 2010 08:02:03 -0500, Jorge Garcia wrote: >Hello Chris > >>In order to start a procedure which you have taken trouble to create with a >>SETUP DD-statement you need to change the BPXPRMxx member >>RESOLVER_PROC statement to, say, RESOLVER_PROC(RESOLVER) and store a >>procedure named RESOLVER similar to the following: > >>//RESOLVER PROC >>//* See SEZAINST(EZBREPRC) for comments >>//EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM='CTRACE >>(CTIRES00)' >>//SETUP DD DSN=TCPIP.TCPPARMS(SETUPRES),DISP=SHR,FREE=CLOSE > >>Then you can stop and start your new RESOLVER procedure according to the >>instructions in the section "Managing the resolver address space". You should >>see the following message: > >>BPXF224I THE RESOLVER_PROC, xxx, IS BEING STARTED where xxx is the >>name of your resolver procedure. > > >I start our RESOLVER with RESOLVER name. I've changed the RESOLVER_PROC >statement from DEFAULT to RESOLVER > > >>If you then enter the command > >>MODIFY xxx,D > > >It doesn't work > >MODIFY RESOLVER,D >EZZ9294I INCORRECT COMMAND SYNTAX > > >>Something I noticed in the z/OS Communications Server IP System >>Administrators Commands manual when checking on the above is that you >can >>also enter the command > >>DISPLAY OMVS,O > > >It's right. The RESOLVER PROC = RESOLVER > > >>The TSO NSLOOKUP command uses the MVS search order for the >TCPIP.DATA >>data set. This is the following: > > >Resolver - GLOBALTCPIPDATA --> Removed > > >>plus the first of the following: > > >//SYSTCPD DD statement --> The TCPDATA attached in the post >x.TCPIP.DATA --> It doesn't exist >SYS1.TCPPARMS(TCPDATA) --> It doesn't exist >Resolver - DEFAULTTCPIPDATA --> The TCPDATA attached in the post >TCPIP.TCPIP.DATA --> It doesn't exist > > >Thanks a lot Chris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Hello Chris >In order to start a procedure which you have taken trouble to create with a >SETUP DD-statement you need to change the BPXPRMxx member >RESOLVER_PROC statement to, say, RESOLVER_PROC(RESOLVER) and store a >procedure named RESOLVER similar to the following: >//RESOLVER PROC >//* See SEZAINST(EZBREPRC) for comments >//EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM='CTRACE >(CTIRES00)' >//SETUP DD DSN=TCPIP.TCPPARMS(SETUPRES),DISP=SHR,FREE=CLOSE >Then you can stop and start your new RESOLVER procedure according to the >instructions in the section "Managing the resolver address space". You should >see the following message: >BPXF224I THE RESOLVER_PROC, xxx, IS BEING STARTED where xxx is the >name of your resolver procedure. I start our RESOLVER with RESOLVER name. I've changed the RESOLVER_PROC statement from DEFAULT to RESOLVER >If you then enter the command >MODIFY xxx,D It doesn't work MODIFY RESOLVER,D EZZ9294I INCORRECT COMMAND SYNTAX >Something I noticed in the z/OS Communications Server IP System >Administrator’s Commands manual when checking on the above is that you can >also enter the command >DISPLAY OMVS,O It's right. The RESOLVER PROC = RESOLVER >The TSO NSLOOKUP command uses the MVS search order for the TCPIP.DATA >data set. This is the following: Resolver - GLOBALTCPIPDATA --> Removed >plus the first of the following: //SYSTCPD DD statement --> The TCPDATA attached in the post x.TCPIP.DATA --> It doesn't exist SYS1.TCPPARMS(TCPDATA) --> It doesn't exist Resolver - DEFAULTTCPIPDATA --> The TCPDATA attached in the post TCPIP.TCPIP.DATA --> It doesn't exist Thanks a lot Chris -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge My apologies! >...> 1. Create a separate TCPDATA member removing all reference to dns. I now realise that this included removing "DNS" from the LOCAL statement. >...> We attach the TCPDATA member and SETUP member in RESOLVER proc. I didn't appreciate that this - why we? what was wrong with I? - meant that the text of the members was part of the post. Once I saw the lines automatically added - about subscribing and so on - I stopped looking any further. I don't think this is affected by the fact that I use the archives rather than e-mail. - Now, taking things one step at a time, you need to work out why the BPXPRMxx member RESOLVER_PROC statement isn't working as it should. You need to be aware that RESOLVER_PROC(DEFAULT) causes an address space with the name RESOLVER to be initiated but that the name of the procedure member started is the general purpose procedure IEESYSAS and that the name is changed to RESOLVER by adding ".RESOLVER" to the internally submitted start command. This is covered - in a way - in the sections "Setting up a resolver address space" and "Managing the resolver address space" in the z/OS Communications Server IP Configuration Guide. In order to start a procedure which you have taken trouble to create with a SETUP DD-statement you need to change the BPXPRMxx member RESOLVER_PROC statement to, say, RESOLVER_PROC(RESOLVER) and store a procedure named RESOLVER similar to the following: //RESOLVER PROC //* See SEZAINST(EZBREPRC) for comments //EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM='CTRACE (CTIRES00)' //SETUP DD DSN=TCPIP.TCPPARMS(SETUPRES),DISP=SHR,FREE=CLOSE Then you can stop and start your new RESOLVER procedure according to the instructions in the section "Managing the resolver address space". You should see the following message: BPXF224I THE RESOLVER_PROC, xxx, IS BEING STARTED where xxx is the name of your resolver procedure. If you then enter the command MODIFY xxx,D where xxx is the name of your resolver procedure, you should see messages explaining the contents of your SETUP DD-statement. Something I noticed in the z/OS Communications Server IP System Administrators Commands manual when checking on the above is that you can also enter the command DISPLAY OMVS,O and somewhere there will be a line which says RESOLVER PROC = yyy where yyy is the name that the system obtained - and it should have been from your BPXPRMxx member - as the name of the resolver procedure. If it still says DEFAULT, you need to check why. And, of course, yyy ought to be the same as xxx! - Once all that is sorted out, we can concentrate on how it is that your LOOKUP statement still appears to cause reference to a name server. - It was while puzzling over whether nslookup was the best way to test your changes - because some functions can avoid using the resolver we have been discussing or something like that - that I realised something rather obvious we have all been missing! The following is from my notes on the subject "distilled" from the manuals: The TSO NSLOOKUP command uses the MVS search order for the TCPIP.DATA data set. This is the following: Resolver - GLOBALTCPIPDATA plus the first of the following: //SYSTCPD DD statement x.TCPIP.DATA SYS1.TCPPARMS(TCPDATA) Resolver - DEFAULTTCPIPDATA TCPIP.TCPIP.DATA where x is userid/jobname/procname The z/OS UNIX nslookup command uses the MVS search order for the TCPIP.DATA data set. This is the following: Resolver - GLOBALTCPIPDATA plus the first of the following: Environment variable - RESOLVER_CONFIG /etc/resolv.conf //SYSTCPD DD statement x.TCPIP.DATA SYS1.TCPPARMS(TCPDATA) Resolver - DEFAULTTCPIPDATA TCPIP.TCPIP.DATA where x is userid And common to both MVS and UNIX: if GLOBALTCPIPDATA used, the following are completely specified there: DomainOrigin/Domain NSInterAddr/NameServer NSPortAddr ResolverTimeOut ResolverUDPRetries ResolveVia Search SortList and the following may be found in the "search order" data set: ALWAYSWTO DATASETPREFIX HOSTNAME LOADDBCSTABLES LOOKUP MESSAGECASE OPTIONS SOCKDEBUG SOCKNOTESTSTOR SOCKTESTSTOR TCPIPJOBNAME TCPIPUSERID TRACE RESOLVER TRACE SOCKET Thus you will see that, in order to force the LOOKUP statement to be used, you need to change from using the DEFAULTTCPIPDATA statement to the GLOBALTCPIPDATA statement in the SETUP file. Chris Mason On Fri, 7 May 2010 04:25:14 -0500, Jorge Garcia wrote: >Chris: > > >>Do you really want not to have any name to address (or address to name) >>conversion or do you just want to avoid using a name server? > >I want to avoid any name to address (or address to name) conversion. > >>DEFAULT is what the RESOLVER_PROC statement specifies "as shipped", "by >>default". In your next step you indicate having set up a RESOLVER SETUP >>file. >>You need still to specify RESOLVER_PROC(something) where "something" - >>anything except DEFAULT !!! - is the name of your resolver procedure which >>will use t
Re: Isolate lpar to resolver process
Roy, this is the SYSTCPT sysout: Resolver Trace Initialization Complete -> 2010/05/07 13:16:33.754109 res_init Resolver values: Global Tcp/Ip Dataset = None Default Tcp/Ip Dataset = None Local Tcp/Ip Dataset = //DD:SYSTCPD ==> SYS2.TCPIP.TCPPARMS(TCPDATAT) Translation Table = Default UserId/JobName = T99TCPIP Caller API = LE C Sockets Caller Mode= EBCDIC (L) DataSetPrefix = SYS2.TCPIP (L) HostName = HES90004 (L) TcpIpJobName = TCPIP (*) DomainOrigin = None (*) NameServer(s) = None (*) NsPortAddr= 53(*) ResolverTimeout= 30 (*) ResolveVia= UDP (*) ResolverUdpRetries = 1 (*) Options NDots = 1 (L) Trace Resolver(*) SockNoTestStor (L) AlwaysWto = NO(*) MessageCase= MIXED (L) LookUp= LOCAL res_init Succeeded res_init Started: 2010/05/07 13:16:33.780215 res_init Ended: 2010/05/07 13:16:33.780219 Yesterday We specified the same DD in the PROC and we haven't seen nothing wrong. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge, rather than guess what might or might not be happening, just allocate the SYSTCPT DD and it will tell you exactly what resolver information you are using and also show where the nslookups are being resolved against from TSO just do ALLOC FI(SYSTCPT) DA(*)or allocate to sysout and see in SDSF Cheers Roy Jorge Garcia wrote: Chris: Do you really want not to have any name to address (or address to name) conversion or do you just want to avoid using a name server? I want to avoid any name to address (or address to name) conversion. DEFAULT is what the RESOLVER_PROC statement specifies "as shipped", "by default". In your next step you indicate having set up a RESOLVER SETUP file. You need still to specify RESOLVER_PROC(something) where "something" - anything except DEFAULT !!! - is the name of your resolver procedure which will use the SETUP file you spent so much effort creating. If you the test LPAR has a procedure library separate from your other LPARs, you might simply call the procedure RESOLVER - as is conventional and the BPXPRMxx member RESOLVER_PROC statement can specify RESOLVER. If you share the procedure library, you can call the procedure TSTRSLVR and specify the same name in the BPXPRMxx member RESOLVER_PROC statement. We have a RESOLVER_PROC in a separate library from our others LPARs and the first time we used the RESOLVER_PROC with RESOLVER name (without DEFAULT) and I didn't work Probably it's going to be least potential trouble if you set up a DEFAULTIPNODES data set with nothing in it - until you decide you might like, for testing purposes, to have a conversion capability. Now what you need to do is investigate what the LOOKUP statement in the data set named in the DEFAULTTCPIPDATA statement can do for you. Specify LOOKUP LOCAL We've specified LOOKUP LOCAL and it doesn't work If you ever want to try some name to address conversion, you can always just set up the conversion in the data set named by the DEFAULTIPNODES statement using the so comfortable - compared to the antediluvian HOSTS.LOCAL format - IPNODES format. In the future We'll do it, but now we don't want to try name to address conversion Patrick: what are you NSLOOKUPing? an internal name or an external name? If it is an internal name it may be specified in the TCPIP.HOSTS.* files. When we enter the nslookup command the system respond with the dns server address. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Chris: >Do you really want not to have any name to address (or address to name) >conversion or do you just want to avoid using a name server? I want to avoid any name to address (or address to name) conversion. >DEFAULT is what the RESOLVER_PROC statement specifies "as shipped", "by >default". In your next step you indicate having set up a RESOLVER SETUP >file. >You need still to specify RESOLVER_PROC(something) where "something" - >anything except DEFAULT !!! - is the name of your resolver procedure which >will use the SETUP file you spent so much effort creating. >If you the test LPAR has a procedure library separate from your other LPARs, >you might simply call the procedure RESOLVER - as is conventional and the >BPXPRMxx member RESOLVER_PROC statement can specify RESOLVER. >If you share the procedure library, you can call the procedure TSTRSLVR and >specify the same name in the BPXPRMxx member RESOLVER_PROC statement. We have a RESOLVER_PROC in a separate library from our others LPARs and the first time we used the RESOLVER_PROC with RESOLVER name (without DEFAULT) and I didn't work >Probably it's going to be least potential trouble if you set up a >DEFAULTIPNODES data set with nothing in it - until you decide you might >like, >for testing purposes, to have a conversion capability. >Now what you need to do is investigate what the LOOKUP statement in the >data set named in the DEFAULTTCPIPDATA statement can do for you. >Specify LOOKUP LOCAL We've specified LOOKUP LOCAL and it doesn't work >If you ever want to try some name to address conversion, you can always >just set up the conversion in the data set named by the DEFAULTIPNODES >statement using the so comfortable - compared to the antediluvian >HOSTS.LOCAL format - IPNODES format. In the future We'll do it, but now we don't want to try name to address conversion Patrick: >what are you NSLOOKUPing? an internal name or an external name? If >it is an internal name it may be specified in the TCPIP.HOSTS.* files. When we enter the nslookup command the system respond with the dns server address. Thanks -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
When we load the lpar and we enter the nslookup command, it's works and respond with a dns (¡¡not right!!). Jorge - what are you NSLOOKUPing? an internal name or an external name? If it is an internal name it may be specified in the TCPIP.HOSTS.* files. Also when you do an NSLOOKUP it will show you what nameserver and it's address it is getting it from first. HTH, Pat Lyon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
Jorge > We want to execute a test in a lpar without name-to-address or address-to- name resolution (no access to resolver). Do you really want not to have any name to address (or address to name) conversion or do you just want to avoid using a name server? Either way, I can provide a means. > 1. Create a separate TCPDATA member removing all reference to dns. In principle, this was unnecessary - but you do need to *add* something - see later. > 2. Set RESOLVER_PROC to DEFAULT in BPXPRMxx member. DEFAULT is what the RESOLVER_PROC statement specifies "as shipped", "by default". In your next step you indicate having set up a RESOLVER SETUP file. You need still to specify RESOLVER_PROC(something) where "something" - anything except DEFAULT !!! - is the name of your resolver procedure which will use the SETUP file you spent so much effort creating. If you the test LPAR has a procedure library separate from your other LPARs, you might simply call the procedure RESOLVER - as is conventional and the BPXPRMxx member RESOLVER_PROC statement can specify RESOLVER. If you share the procedure library, you can call the procedure TSTRSLVR and specify the same name in the BPXPRMxx member RESOLVER_PROC statement. > 3. The SETUP statement in RESOLVER proc specifies a member without GLOBALTCPIPDATA, GLOBALIPNODES or DEFAULTIPNODES statements. We have specified in this member DEFAULTTCPIPDATA (step 1 member) and COMMONSEARCH statements. Probably it's going to be least potential trouble if you set up a DEFAULTIPNODES data set with nothing in it - until you decide you might like, for testing purposes, to have a conversion capability. Now what you need to do is investigate what the LOOKUP statement in the data set named in the DEFAULTTCPIPDATA statement can do for you. Specify LOOKUP LOCAL I hope you'll note there is no "DNS" specified! If you ever want to try some name to address conversion, you can always just set up the conversion in the data set named by the DEFAULTIPNODES statement using the so comfortable - compared to the antediluvian HOSTS.LOCAL format - IPNODES format. Chris Mason On Thu, 6 May 2010 10:00:55 -0500, Jorge Garcia wrote: >Hello: > > We want to execute a test in a lpar without name-to-address or address-to- >name resolution (no access to resolver). >We want to isolate the lpar from dns access. > We have done the follow steps: > > 1. Create a separate TCPDATA member removing all reference to dns. > 2. Set RESOLVER_PROC to DEFAULT in BPXPRMxx member. > 3. The SETUP statement in RESOLVER proc specifies a member without >GLOBALTCPIPDATA, GLOBALIPNODES or DEFAULTIPNODESstatements. We >have specified in this member DEFAULTTCPIPDATA (step 1 member) and >COMMONSEARCH statements. > >When we load the lpar and we enter the nslookup command, it's works and >respond with a dns (¡¡not right!!). > >Is there any step omitted? > >We attach the TCPDATA member and SETUP member in RESOVER proc. > >Thanks > >Jorge García Juanino >Técnico de Sistemas Z/Os >DGTP Departamento de Técnica de Sistemas >MAPFRE >Gobelas 47 - 49 2ª C y D >28023 Madrid >Tfno: 91 581 27 34/ 618 33 35 59 >Fax: 91 581 24 01 >jgarc...@mapfre.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
No Mark. We don't have any configuration in USS. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Isolate lpar to resolver process
>>> On 5/6/2010 at 11:00 AM, Jorge Garcia wrote: > Is there any step omitted? Is there a /etc/resolv.conf file in your HFS? Mark Post -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
