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 <jgarc...@mapfre.com> 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
