Sheila
You raise the matter of the use of the gethostid() call by DB2. I have an
ancient scar associated with gethostid() - and DB2 may have been the
reason - "may" because my memory is failing not because the complaining
software wasn't identified.
In another thread recently I suggested that gethostid() is an UNIX thing
which doesn't fit well into MVS. Since the matter has arisen again so
shortly I thought I should take another look at the conclusions I reached 14
years ago when I put together my socket programming presentation.
The description of gethostid() I found by Googling is quite consistent. It
seems I paid attention to the first sentence which defined what gethostid()
was supposed to be but insufficient to the second. Perhaps the manual from
which I took my notes didn't bother to include the second!
<quote>
DESCRIPTION
The sethostid() function establishes a 32-bit identifier for the current
processor that is intended to be unique among all UNIX systems in existence.
This is normally a DARPA Internet address for the local machine.
This call is allowed only to the super-user and is normally performed at
boot time.
The gethostid() function returns the 32-bit identifier for the current
processor.
This function has been deprecated.
</quote>
The last sentence is clarified a little later as follows:
<quote>
BUGS
32 bits for the identifier is too small.
HISTORY
The gethostid() and sethostid() syscalls appeared in 4.2BSD and were dropped
in 4.4BSD.
</quote>
Note that this is taken from a page identified as "Mac OS X Man Pages" but
is framed by "BSD Library Functions Manual" and "June 2, 1993".
It seems that it is intended that the value returned by gethostid() is
indeed one of the IP addresses associated with the IP node. Trawling the
Communications Server (CS) manuals for references to the gethostid() call
does rather indicate that the rationale for the PRIMARYINTERFACE statement
in the PROFILE data set is in order to provide a value for the gethostid()
call to return - and nothing else.
The "second thoughts" that "Berkeley System Distribution" (BSD) folk had
about this function happened *after* it was taken up by TCP/IP for VM, the
predecessor product for TCP/IP for MVS, now the IP component of CS. If there
was an user council overseeing changes to BSD and if there was an IBM
representative on it, he or she must have been asleep when the voting on
ditching "gethostid" took place.
However I believe the support for use of IP by DB2 may have been implemented
*after* 1993 and, had the developers been sufficiently diligent, they should
have noticed that they were thinking of using a "deprecated" function and
stayed well away from it.
You said finding an explanation of the use of the gethostid() call in DB2
was difficult but I get the impression you found it. Would you please
provide an URL where I can read about this?
For now, I'm picking up your comment "The IP address assigned to this link
in the HOME statement is used to get the host name." This indicates that
perhaps that DB2 needs to get a name for the IP node on which it is running.
In order to do this it uses the gethostid() call and is provided with the IP
address which is identified by the PRIMARYINTERFACE statement. Then it uses
the gethostbyaddr() call and the returned structure points to an "official"
"host name" - and, in fact, also a pointer to a list of "aliases". Possibly
it is in order to get at this "official" "host name" that DB2 - thinks it -
needs to use the gethostid() call.
I added the "thinks it" because - having checked my sockets presentation -
wouldn't you know it? - on that same page as I describe gethostid() I find
gethostname()!
But I may have an explanation. What the gethostname() call does is extract
the local version of the "host name". What a gethostby<something>() call
does is is launch a request into the "resolver" system. This can result in
looking up the local data set which associates names and address or it can
result in a request into the name server system. Definitely in the latter
case, the name returned will be more "official" than the local version of
the "host name".
On review of this post I realised something else - rather obvious really
although that DB2 error message is plain misleading and completely puts one
off the scent! It is quite impossible for the gethostid() call to fail if
you have just one interface defined correctly. Just one interface
necessarily provides a default for the PRIMARYINTERFACE statement and so
provides a value for the gethostid() call to return. I even checked the CS
IP Sockets Application Programming Interface Guide and Reference manual and,
as I suspected, there are no error returns possible.
However, it is possible that the *gethostbyaddr()* call could fail and it is
a failure of this call which is documented by the "gethostid failed" I very
strongly suspect. This ties in with your report that you needed to be sure
that your name to address mapping, strictly address to name mapping in this
case - in the shape of the file identified by your DEFAULTIPNODES statement
under the influence of a COMMONSEARCH statement - was set up appropriately.
Chris Mason
----- Original Message -----
From: "Sheila Weissborn" <[EMAIL PROTECTED]>
Newsgroups: bit.listserv.ibm-main
To: <IBM-MAIN@BAMA.UA.EDU>
Sent: Wednesday, September 05, 2007 7:30 PM
Subject: Re: CA to IBM TCP Conversion
...
For IPV4 links, there is a relationship between links, IP addresses and host
names that you will need to know if you are using DB2 or anything else that
uses the gethostid function. This may not apply to your environment, but I
mention it here because it is hard to track this down in the manuals. In
the
TCPIP profile there is a parameter "PRIMARYINTERFACE" which defaults to the
first link in the HOME statement. The IP address assigned to this link in
the
HOME statement is used to get the host name. There is discussion of local
host name files in the IP Configuration Guide. We use a sequential file
that is
referenced by DEFAULTIPNODES in the resolver configuration file. If this is
not
set up correctly, the resulting error message in DB2 states that "gethostid
failed".
...
Sheila Weissborn
Ohio Casualty Insurance
----------------------------------------------------------------------
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
