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 commandResolver address space" in the IP System Administrators 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 Administrators 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 commandResolver 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
