Dave
Back at the end of August, Lizette Kohler - in effect - had a similar problem.
She needed something in her name server fixed - preferably quickly - but the
time-scale was out of her control. If that also applies to you in that you
would
prefer the "damage" to be repaired right now rather than at the end of the
change cycle - and you are in charge of the Resolver-related members,
perhaps you should follow up what I am about to mention.
It may be that in Lizette's case, she did not have a customized Resolver
address space. There's every indication that you do, so you're, say, 90 % of
the way there - in comparison with someone who needs to get a customized
Resolver set up first.[1]
Assuming you are not using an old-fashioned HOSTS.LOCAL file with the
irritating MAKESITE command conversion, the easiest way to repair
the "damage" is to change NOCOMMONSEARCH to COMMONSEARCH in your
Resolver setup file and specify a DEFAULTIPNODES('TCPIP.WSUMVS1.PARMLIB
(IPNODES)') statement.
Then you need to create member IPNODES as the following:
127.0.0.1 localhost
And, just to be sure, add the following statement to member TRESDATA:
LOOKUP LOCAL DNS
Note: Member name "IPNODES" is only a suggestion, It can be whatever suits
you.
This is all according to section "Configuring the local host table (optional)"
in
Chapter 5, "TCP/IP Customization" in the Configuration Guide, specifically the
last section "Creating ETC.IPNODES and /etc/ipnodes" where ETC.IPNODES
and /etc/ipnodes are just two of many ways to identify the file - obviously!
Chris Mason
-
[1] This is for any reading who may need to create a customised Resolver.
There is a Technote(FAQ) "Customizing the z/OS RESOLVER"
http://www-01.ibm.com/support/docview.wss?uid=swg21066874
which, to my mind falls a long way short of really useful.
I tried to post this on IBMTCP-L but I see it failed so I am going to have to
try
again. I had hoped simply to provide an URL here but, since it's missing,
here's
the whole "proposed replacement Technote. I believe I sent it to
Communications Server development for consideration - to me it's a "no-
brainer" but, as they say, there's no accounting for taste:
<proposed Technote>
Customizing the z/OS Communications Server IP Resolver
Technote (FAQ)
Question
How do I control the z/OS Communications Server IP Resolver functions
introduced with z/OS V1R12?
Answer
Background
In z/OS V1R12, the Communications Server IP Resolver takes on three new
functions. All three new functions are active and providing benefits whether or
not you have customized the Resolver address space which you have been
using ever since it was introduced with z/OS V1R4. For one of these
functions, Extension Mechanisms for Domain Name System (DNS) (EDNS0)
standards, no customization is appropriate since support for the enhanced
capabilities of the name server is determined dynamically. On the other hand,
in order to be able to control the operation of the other two functions,
caching of information from resolved DNS queries and monitoring
responsiveness level of DNS name servers, the Resolver function needs to be
customized.
Customizing the Resolver
In the z/OS V1R4 Communications Server IP component the resolver function
was generalized and operates by default through a newly introduced address
space. This address space has the name RESOLVER but, unusually, no
procedure with the name RESOLVER is provided in SYS1.PROCLIB. This is
because the Resolver address space is initiated with the following command:
START IEESYSAS.RESOLVER,PROG=EZBREINI,SUB=MSTR,REUSASID=YES
This command uses the general purpose procedure IEESYSAS which provides
only for the specification of the name of the program to be executed, in this
case EZBREINI, the Resolver. No DD-statements can be specified. This has the
effect that the Resolver executes with only default values for its execution
parameters.
It is your objective to be able to specify a DD-statement in a procedure
specifically for initiating the Resolver address space. The data set or file to
which the DD-statement refers will contain parameters with values specific to
your installation.
This default behaviour is caused by the following specification in the
BPXPRMxx member responsible for z/OS UNIX System Services (OMVS)
functions:
RESOLVER_PROC(DEFAULT)
As always there are a number of choices available. In what follows, what is
suggested conforms to what is expected to be a popular set of such choices.
For alternatives, please see the appended manual references.
Names which can be chosen freely have been shown in lower case but often
with, in effect, a suggested value.
In order to customize the resolver, you first need to create a procedure. The
following is suggested:
SYS1.PROCLIB member name: resolver
//resolver PROC PARMS='CTRACE(CTIRES00)'
//EZBREINI EXEC PGM=EZBREINI,REGION=0M,TIME=1440,PARM=&PARMS
//SETUP DD DISP=SHR,FREE=CLOSE,DSN=hlq.pds(resolver)
Use of a partitioned data set in order to gather together sets of statements
for the definition of Communications Server components is just one of many
options for the data set or file to which the DD-statement SETUP refers.
In order to cause z/OS UNIX to enter the command
START resolver,SUB=MSTR,REUSASID=YES
in place of the command mentioned above, it is necessary to edit the
RESOLVER_PROC statement in your BPXPRMxx member as follows:
RESOLVER_PROC(resolver)
Finally, you can create a data set or file containing the Resolver setup
statements to which the DD-statement SETUP in the procedure refers. An
example is the following containing the statements with the default values, in
other words, those values which would be used if you had not actually
created the scaffolding for a customized Resolver address space:
hlq.pds member name: resolver
NOCOMMONSEARCH
CACHE
CACHESIZE(200M)
MAXTTL(2147483647)
UNRESPONSIVETHRESHOLD(25)
Note that this sample does not show two types of resolver statement:
1. The statements which negate the values of two of the statements shown,
namely, NOCACHE in order not to use the caching function specified by the
CACHE statement and COMMONSEARCH in order to allow the use of a local
hosts table in the "ipnodes" format
2. The statements which specify the names of data sets or files which can
join the search hierarchy for the generically named TCPIP.DATA data set or
file containing the Resolver parameters in use before the change to introduce
the Resolver address space, namely GLOBALTCPIPDATA and
DEFAUILTTCPIPDATA, and for a local hosts table in "ipnodes" format, namely
GLOBALIPNODES and DEFAULTIPNODES
For details of how to control the operation of the two functions, caching of
information from resolved DNS queries and monitoring responsiveness level of
Domain Name System (DNS) name servers, please see the appended manual
references.
Having now created a customized Resolver address space, you may like to
benefit from two other possibilities which have been available to you ever
since the Resolver address space was introduced with z/OS V1R4.
The two possibilities are the following:
1. Minimally TCPIP.DATA statements relating to the use of name servers can
be concentrated in the data set or file to which the Resolver setup statement
GLOBALTCPIPDATA refers, thus avoiding problems of change control possibly
caused by proliferation of other means to specify TCPIP.DATA statements,
typically by means of SYSTCPD DD-statements. Additionally the remaining
TCPIP.DATA statements can be specified in the data set or file to which the
Resolver setup statement GLOBALTCPIPDATA refers. Alternatively and
additionally, TCPIP.DATA statements can be specified in the data set or file to
which the Resolver setup statement DEFAULTTCPIPDATA refers where it is
desired to have a common source to supplement TCPIP.DATA statements
specified for individual users of the Communications Server IP component base
address space.
2. One very popular use of a customised Resolver address space is to be able
to specify the Resolver setup statement COMMONSEARCH so that
the "ipnodes" format can be used for a local hosts table rather than the
original RFC 952 format. The RFC 952 format imposes the requirement to
convert the source data set into two files in a format which allowed early
implementations of IP support product in first VM and then MVS to process
queries more efficiently than the source data set itself would have permitted.
This consideration applies less today but the use of the function based on the
RFC 952 format was already established so a change of use of local hosts
table needs explicitly to be specified.
If COMMONSEARCH is specified in your Resolver setup data set or file, there is
also the opportunity to use the Resolver setup statements GLOBALIPNODES or
DEFAULTIPNODES in order to refer to a local host table in "ipnodes" format in
addition to other means provided by the search order rules.
Note that, if a local host table is used, whether derived from the RFC 952
format or using the "ipnodes" format, the order of name and address resolution
defined by the TCPIP.DATA statement LOOKUP may need to be changed from
LOOKUP DNS LOCAL, the default, to LOOKUP LOCAL or LOOKUP LOCAL DNS.
Note also that, if a local hosts table in "ipnodes" format is needed
exclusively
by programs using the z/OS UNIX environment, namely, using the XL C/C++
Run-time Library or UNIX callable services, which, in general terms, means
programs newly available in the last few years implementing new functions, it
is possible to use a local hosts table in "ipnodes" format using the
file "/etc/hosts". A guide to whether a program uses the z/OS UNIX
environment or the generally older alternative, the native MVS environment, is
that a program which implements "environment variables" uses the z/OS UNIX
environment.
Again, please see the appended manual references for full details of these
other possible uses for a customized Resolver address space.
-
The manual references for this topic are the following:
- Chapter 14, "The resolver", in z/OS V1R12 Communications Server IP
Configuration Guide
- Chapter 5, "Resolver setup and TCPIP.DATA configuration statements" in
z/OS V1R12 Communications Server IP Configuration Reference
</proposed Technote>
On Mon, 25 Oct 2010 15:52:18 -0700, Gibney, Dave <[email protected]>
wrote:
>Thanks Chris, it appears that we DID finalize our implementing of new
>DNS servers and software since the last time these server address spaces
>rolled. Now, I get to close another ETR that perhaps I shouldn't have
>opened. :)
>
>Dave Gibney
>Information Technology Services
>Washington State University
>
>
>> -----Original Message-----
>> From: IBM Mainframe Discussion List [mailto:[email protected]] On
>> Behalf Of Chris Mason
>> Sent: Monday, October 25, 2010 3:26 PM
>> To: [email protected]
>> Subject: Re: EntireX and LOCALHOST
>>
>> Dave
>>
>> It appears that "localhost" is conventionally mapped to 127.0.0.1 by
>> the name
>> server. If suddenly this mapping no longer seems to operate, it looks
>> like
>> someone has messed about with your name server and somehow lost the
>> statements which perform this mapping.
>> ...
----------------------------------------------------------------------
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
