> > You were correct. Thanks for that. with NSLOOKUP I have tested. > > What is surprising that I did not have to REFRESH the RESOLVER. I just > changed the SYS1.TCPPARMS(TCPDATA) NSINTERADDR address and then issued the > TSO NSLOOKUP and it was taking that new IP address value. > > Whatever IP address I mentioned same was being queried while performing > operations related to NSLOOKUP. > > I could not find anything like this in manual. My OS is z/OS 1.7, is it > that for 1.7 you just need to change the NSINTERADDR parm it will work ? No > need to refresh RESOLVER. > > JAcky >
> > > On Wed, Oct 15, 2008 at 10:34 AM, Chris Mason <[EMAIL PROTECTED]>wrote: > >> Jacky >> >> With the introduction of the resolver function a few releases back, you >> got a >> new configuration data set called the resolver setup data set. It is the >> only >> data set which is used directly by the resolver procedure and, as I >> indicated >> before, it is optional since you can accept all the default values. The >> statements in this data set, even by default, refer in turn to the >> TCPIP.DATA >> [1] data set and the means by which you have defined it. >> >> Fear not, the new specifications you have entered into your TCPIP.DATA set >> are now in effect. The process of "refreshing" the resolver procedure >> causes >> the TCPIP.DATA data set to be "revisited". The description under "MODIFY >> command—Resolver address space" in the IP System Administrator's >> Commands manual specifically assures us that the TCPIP.data information is >> refreshed. >> >> I tried to see if there was a command in the IP System Administrator's >> Commands which showed the current NSINTERADDR statement specifications - >> and failed! I do know that, when you use the NSLOOKUP command, you are >> told the name server - or, I believe, name servers - which are referenced >> in >> order to resolve the query. I also know that you get typically far more >> information than you thought you needed when you slip the TRACE RESOLVER >> statement into your TCPIP.DATA data set. >> >> As this is the first time you have encountered the revised "resolver" >> function, >> you have some reading to do. You should start with the >> section "Understanding resolvers" in Chapter 2, "Configuration overview" >> in the >> IP Configuration Guide manual. You will need a quick visit to the UNIX >> System >> Services Planning manual in order to find out precisely how to get your >> own >> RESOLVER procedure which will enable you to specify your own resolver >> setup >> statements, the ones you find so confusing! >> >> Of course, as usual, you will find details about the statements in the IP >> Configuration Reference manual - just before the TCPIP.DATA statements are >> explained. >> >> [1] You are probably aware that the TCPIP.DATA data set can be specified >> in >> a number of ways, including as SYS1.TCPPARMS(TCPDATA). The way to refer >> to the data set generically is to use the original name used by TCP/IP for >> VM, >> the product from which CP/IP for MVS was derived which, in turn became the >> Communications Server IP component. >> >> Chris Mason >> >> On Wed, 15 Oct 2008 07:43:36 +0100, Jacky Bright >> <[EMAIL PROTECTED]> wrote: >> >> >Chris thanks for that but I am getting some strange ouput when I am >> >displaying the resolver stat >> > >> >F RESOLVER,DISPLAY >> >EZZ9298I DEFAULTTCPIPDATA - None >> >EZZ9298I GLOBALTCPIPDATA - None >> >EZZ9298I DEFAULTIPNODES - None >> >EZZ9298I GLOBALIPNODES - None >> >EZZ9304I NOCOMMONSEARCH >> >EZZ9293I DISPLAY COMMAND PROCESSED >> > >> >The GLOBALTCPIPDATA is not at all mentioning the SYS1.TCPPARMS >> (TCPDATA) >> >member. How do I know which all DNS Servers I am using and where is is >> >mentioned .. >> > >> >JAcky >> > >> >On Tue, Oct 14, 2008 at 5:21 PM, Chris Mason >> <[EMAIL PROTECTED]>wrote: >> > >> >> Jacky >> >> >> >> If you go to the description of the NSINTERADDR statement in the IP >> >> Configuration Reference, as with most statements, you will find a >> >> section "Steps for modifying". However, unlike most of the statements >> in >> >> the >> >> manual with which I am familiar, the information here is just pathetic! >> All >> >> it >> >> does is point you to the MODIFY command in the IP System >> Administrator's >> >> Commands manual. It really should have gone the extra centimetre and >> >> mentioned that the particular flavour of MODIFY was "MODIFY command— >> >> Resolver address space" since not everyone will know that all these >> >> TCPIP.DATA statements fall under a topic called "Resolver". >> >> >> >> Under "MODIFY command—Resolver address space" you will find the >> command >> >> John suggested described. >> >> >> >> John has a locally created RESOLVER started task procedure so he can >> start >> >> it >> >> with the S RESOLVER command. In case you do not have a locally created >> >> RESOLVER started task procedure, you can still stop and start the >> provided >> >> RESOLVER started task. You stop it with the P RESOLVER command, just as >> >> John again mentioned, but it all gets a bit subtle when you need to >> start >> >> it >> >> again. >> >> >> >> The command you need is START >> >> IEESYSAS.RESOLVER,PROG=EZBREINI,SUB=MSTR >> >> >> >> Not so very obvious is it? >> >> >> >> The reason for this command is twofold: >> >> >> >> 1. You are using only default values for the resolver configuration >> file so >> >> no >> >> configuration file DD-statement is needed and, when no DD-statement is >> >> needed, the only logical statement which is needed in the started task >> >> procedure is >> >> >> >> // EXEC PGM=EZBREINI >> >> >> >> 2. z/OS - not Communications Server - very kindly provides a >> generalised >> >> started task procedure with the name IEESYSAS which I think does >> absolutely >> >> nothing - have a look at it, I can't - except to enable some "tricks" >> >> permitted >> >> by JCL, one of which is to override the value of the PGM operand and >> >> another >> >> is the ability to change the procedure name - thereby frustrating some >> who >> >> have searched their procedure libraries in vain for a member named >> >> RESOLVER! >> >> >> >> This subtlety is described in the IP Configuration Guide under >> "Managing >> >> the >> >> resolver address space". >> >> >> >> Chris Mason >> >> >> >> On Tue, 14 Oct 2008 16:09:55 +0100, Jacky Bright >> >> <[EMAIL PROTECTED]> wrote: >> >> >> >> >Is it possible to change NSINTERADDR dynamically without IPL ? How >> can >> we >> >> >achieve that ? >> >> > >> >> >I have to change SYS1.TCPPARMS(TCPDATA) NSINTERADDR parm as the >> >> DNS server >> >> >has crashed. >> >> > >> >> >JAcky >> >> ---------------------------------------------------------------------- >> For IBM-MAIN subscribe / signoff / archive access instructions, >> send email to [EMAIL PROTECTED] 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
