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

Reply via email to