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 wher
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 -
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
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-st
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 TCPI
> 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 / arc
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
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
>//*
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 wi
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
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
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"
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
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.
>
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/a
>>> 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...@b
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
17 matches
Mail list logo
