Hi Chris, One final question. It seems to me, that for my purposes, GLOBALIPNODES is a better choice than DEFAULTIPNODES. The only purpose I know I have for the file at all is to resolve LOCALHOST. Everyone else should be using DNS.
Dave Gibney Information Technology Services Washington State University > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On > Behalf Of Chris Mason > Sent: Monday, October 25, 2010 5:35 PM > To: IBM-MAIN@bama.ua.edu > Subject: Re: EntireX and LOCALHOST > > 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 <gib...@wsu.edu> > 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:ibm-m...@bama.ua.edu] On > >> Behalf Of Chris Mason > >> Sent: Monday, October 25, 2010 3:26 PM > >> To: IBM-MAIN@bama.ua.edu > >> 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 lists...@bama.ua.edu 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 lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
