Anson > The application to use resolver is DB2 DDF... Regarding to DDF resolving, it > get information from TCPIP stack directly. > DDF get the hostname from //SYSTCPD dd in TCPIP stack.
Getting the value of the HOSTNAME statement from a generically named TCPIP.DATA data set where the generically named TCPIP.DATA data set, specifically in your reported case the SYSTCPD DD-statement, used by the main address space of the IP component of Communications Server (CS) - what I gather you mean as the "tcpip stack" - looked wrong - but actually it is right! Thanks for pointing something out I hadn't realised - until now! It turns out that the value of the HOSTNAME statement - as long as the program logic used to access it is the gethostname() call - is that held by the main CS IP address space and not the "client" address space. All other - until someone points out another exception! - statements of the generically named TCPIP.DATA data set are obtained from the data set assigned to the address space itself. First this prompted a review of all your posts - and my replies - in order to see if you knew all along but hadn't expressed it clearly enough or confidently enough. But no, I think everything I have said has been an accurate response to your queries - until >...> I'm curious why the tcpip stack couldn't get the hostname in tcpip.data >file. What you are reporting is that DDF manages to find the value of the HOSTNAME statement from a generically named TCPIP.DATA data set where the generically named TCPIP.DATA data set is that assigned to the main CS IP address space - ***but HOMETEST doesn't***. We'll look at this inconsistency in a moment. The references in the z/OS CS IP Configuration Guide which touch on this point as the following: <quote> 1.5.2 Configuring TCPIP.DATA The TCPIP.DATA configuration data set is the anchor configuration data set for the TCP/IP stack and all TCP/IP servers and clients running in z/OS. With a z/OS TCP/IP stack, you can define the TCPIP.DATA parameters in a z/OS UNIX file or in an MVS data set. The TCPIP.DATA configuration data set is read during initialization of all TCP/IP server and client functions. All functions must access this data set in order to find basic configuration information, such as the name of the TCP/IP address space, the TCP/IP host name, and the data set prefix to use when searching for other configuration data sets. </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3a0/1.5.2 Actually, in the light of what has just been revealed - to me anyhow! - it might have been better if the manual author had left out "the TCP/IP host name" since, as we are about to have documented, "the TCP/IP host name" is an exception. <quote> 1.2.6.2 TCPIP.DATA search order The TCP/IP stack's configuration component uses the TCPIP.DATA configuration file during TCP/IP stack initialization to determine the stack's host name. To find the TCPIP.DATA information, the z/OS UNIX environment search order is used. For a description of this search order, see "Search orders used in the z/OS UNIX environment" in topic 2.5.9.1. This host name value is the value that is returned on gethostname socket function calls processed by this stack. </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1b3a0/1.2.6.2 I've split all the sentences above into separate paragraphs as an aid to reading and digesting them individually. Well, that helps me focus on the "hidden messages"! In case it's not clear "this stack" in the final sentence is the main CS IP address space as described in the first sentence as "The TCP/IP stack". So there we have it. As must universally be that case unless someone can point out another means to obtain the value of the HOSTNAME statement, if you use the gethostname() call you are going to rely on the value of the HOSTNAME statement or the default specified by the generically named TCPIP.DATA data set assigned to the main CS IP address space and *not* the value specified by the generically named TCPIP.DATA data set assigned to the address space where the program issuing the gethostname() call is running. Hands up all who didn't know that! Returning both hands to the keyboard ... Alternatively I have misunderstood something somewhere and there is another explanation for the observation reported. Having suggested that the regular classes for the IP component of CS may have failed you, I rather wonder if they manage to point up this exception. Myself I never took a class and have learned everything I know from reading the manual and testing with the MVS systems I used for the classes I taught. I used to say that I needed students to make mistakes so that unusual problems occurred which would need to be thought through. On one famous occasion I had to call development in order to work out what a famous Brian from Ireland had done based on a misunderstanding but which sort-of worked! It's revelations such as this "HOSTNAME statement behaviour" which puts me in mind of those "mistakes" by my students! Incidentally the way a gethostname() call discovers the value returned can be compared to the "sister" gethostid() call which obtains its information not from a generically named TCPIP.DATA data set assigned to the address space where the program issuing the gethostid() call is running (nor from the generically named TCPIP.DATA data set assigned to the main CS IP address space) but from the IP address referenced by the PRIMARYINTERFACE statement in the PROFILE data set, information necessarily held by the main CS IP address space. Now why does HOMETEST fail to find the value of the HOSTNAME statement from a generically named TCPIP.DATA data set where the generically named TCPIP.DATA data set is that assigned to the main CS IP address space? The explanation must be that it doesn't use the gethostname() call. This is possible - indeed simply true - since the HOMETEST program is written in Pascal and Pascal uses calls different from the calls originally inspired by the C implementation of sockets. Now I needed to dip into the z/OS CS IP Sockets Application Programming Interface Guide and Reference manual in order to discover what a Pascal program might use. There is no gethostname() call as such but there is a GetIdentity call documented as follows: <quote> 3.6.8.10 GetIdentity This procedure returns the following information: - The user ID of the MVS user - The host machine name - The network domain name - The user ID of the TCP/IP address space The host machine name and domain name are extracted from the HostName and DomainOrigin statements, respectively, in TCPIP.DATA. If a HostName statement is not specified, then the default host machine name is the name specified by the TCP/IP installer during installation (the name from the line containing the definition, VMCF,MVPXSSI,nodename, in the IEFSSNxx member of PARMLIB). The TCP/IP address space user ID is extracted from the TcpipUserid/TcpipJobname statement in TCPIP.DATA; if the statement is not specified, the default is TCPIP. See z/OS Communications Server: IP Configuration Reference for information about TCPIP.DATA search order. </quote> http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/F1A1D490/3.6.8.10 Note that, if you are using Pascal, you have necessarily configured VMCF/TNF and so there is no need to describe the default which will be used if there is no VMCF parameter available. Furthermore none of the development authors has bothered over the years to describe other than the original technique for specifying the VMCF parameter, so much work for the poor lambs! So here we see the key difference: - If a program - nearly all programs these days - uses the sockets interface and the gethostname() call, it will receive the value of the HOSTNAME statement in the generically named TCPIP.DATA data set assigned to the main CS IP address space - If a program - just a very few antique programs dating from the time that "TCP/IP for VM" was a graduate student project (I guess) in the University of Wisconsin University in the late 1980s, including HOMETEST of course - uses the Pascal interface and (I assume) the GetIdentity call, it will receive the value of the HOSTNAME statement in the generically named TCPIP.DATA data set assigned to the address space where the program issuing the GetIdentity call is running. That finally answers the implied question: >...> I'm curious why the tcpip stack couldn't get the hostname in tcpip.data >file. I'm sorry it took so long but I've learned something myself! Incidentally, you may have some problems with this DB2 use of these sorts of calls. Because there has been/is a similar discussion in the IBMTCP-L list, I recently dug up the following reference with which you should be familiar in the "7.6.7 Starting TCP/IP support" section of the DB2 Version 9.1 for z/OS Installation Guide manual: http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/dsnigk17/7.6.7 Chris Mason On Wed, 27 Jul 2011 21:40:05 -0700, Anson Ye <[email protected]> wrote: >Chris, I can say nothing but thank you for your excellent and patient explanation.. It's a very valuable lesson to me... Sorry for some missing background information in the previous mails... The application to use resolver is DB2 DDF... Regarding to DDF resolving, it get information from TCPIP stack directly. So the approach should be different from HOMETEST command... In this case, DDF get the hostname from //SYSTCPD dd in TCPIP stack. So even HOMETEST doens't work or show different name resolving, DDF get the desired hostname (ABC) and works fine. >.. Since you have changed your VMCF customisation in order to specify SYSA, >assuming that the generically named TCPIP.DATA data set can be located, it >should be that the HOSTNAME statement is processed and the value is set as "ABC". .... I found out it didn't work for HOMETEST if there is not global tcpip data specified. It always show hostname with SYSA. btw, sorry for my not articulate in English as 2nd language... Best Regards! Anson ---------------------------------------------------------------------- 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
