Yanick

This is a bit confused!

Why do you suppose that the address space where the main z/OS Communications 
Server IP program runs should contain a table mapping all IP addresses you 
might happen to have in your program to the corresponding names?

If the IP address you have is one of those corresponding to one of the 
interfaces of the instance of the main z/OS Communications Server IP program, 
then the corresponding "hostname" is that of the IP node on which the program 
is running.

If that is so, you can retrieve a value using the GETHOSTNAME API call - and 
there need be no reference to the value of whichever IP address you happen to 
have.

However, the value returned is the value, specified or default, of the HOSTNAME 
statement in the generically named TCPIP.DATA data set. This is *not* the 
"fully qualified domain name" - the flavour of the "hostname" where the last 
token is "COM" or "ORG" or "CA". In order to obtain the "fully qualified domain 
name" you need to use the GETHOSTBYNAME API call or the GETHOSTBYADDR API call.

If you use the GETHOSTBYNAME API call, you will need to use a name as an input 
argument. That name can be the name obtained by the GETHOSTNAME API call or any 
other possibly truncated name.

If you use the GETHOSTBYADDR API call, you will need to use an IP address as an 
input argument. Obviously that IP address can be the IP address you already 
know whether it happens to be one of the interfaces of the instance of the main 
z/OS Communications Server IP program or any other IP address.

For the GETHOSTBYNAME or GETHOSTBYADDR call to return a result, you will need 
to have your generically named TCPIP.DATA data set specified so that the 
possibly truncated name to "fully qualified domain name" translation or the IP 
address to "fully qualified domain name" translation can can be performed using 
information in a local data set or a, possibly "the", name server system.

> I'm wondering if it is possible to do an assembler cross-memory program to 
> talk to the address space of TCP/IP and only retrieve the hostname associate 
> with IP address.

It may be that you suffer from a misunderstanding here. It is possible for any 
address space supported by a z/OS which also supports a "resolver" address 
space - which obviously has a dependency on a z/OS Communications Server IP 
main address space if a name server system needs to be accessed and may have a 
less obvious dependency on a z/OS Communications Server IP main address space 
generally - to use the mentioned API calls. Thus there is no need for your 
program to refer to the z/OS Communications Server IP main address space.

> How do I do to issue an DNS query to retrieve only the hostname and return 
> the result to the caller.

In principle, this question has already been answered!

Before passing to the next point, I should mention yet another API call, 
GETHOSTID. This may be how you obtained your IP address - or maybe not! The 
GETHOSTID API call returns the IP address of the interface of the instance of 
the main z/OS Communications Server IP program which is identified, specified 
or default, by the PRIMARYINTERFACE statement of the PROFILE data set.

-

We now need to concern ourselves with any prerequisites there may be which you 
might need to consider before being able to use any of the mentioned calls.

I have only ever actually used the old C sockets library, the one which has 
been deprecated ever since OpenEdition - called z/OS UNIX System Services this 
week! - burst upon the scene in the mid-1990s.

Checking the manuals briefly, for example, the "z/OS Communications Server IP 
CICS Sockets Guide" manual:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/f1a1g170/

I can't see any dependencies. However you know your CICS (and IDMS) products 
way better than I do.

The reason I would not expect there to be any dependencies on other calls 
related to "sockets programming" is that all the mentioned API calls, 
GETHOSTNAME, GETHOSTID, GETHOSTBYNAME and GETHOSTBYADDR, do *not* rely upon 
having established any sockets communication.[1] The calls themselves perform 
some sort of "cross-memory" trick, to the z/OS Communications Server IP main 
address space in order to obtain the values returned by the GETHOSTNAME[2] and 
GETHOSTID calls, and to the "resolver" main address space in order to obtain 
the values returned by the GETHOSTBYNAME and GETHOSTBYADDR calls.

-

For advice on how to make the API calls in a CICS environment, you might like 
to try the CICS-L list:

http://www.listserv.uga.edu/archives/cics-l.html

For advice on how to make the API calls in an IDMS environment, I hope someone 
reading this might be able to provide you with the necessary assistance, 
perhaps to point you to a relevant list or other type of "forum".

-

[1] Clearly the "resolver" address space needs to use the sockets API if it is 
to communicate with an external name server system via "adjacent" name server 
nodes but that is a matter for the "resolver" program to manage.

[2] Only earlier this year courtesy of Anson Ye in a thread in IBM-MAIN I 
discovered that the GETHOSTNAME API call retrieves the value of the HOSTNAME 
statement in the generically named TCPIP.DATA data set which is identified to 
the z/OS Communications Server IP main address space and *not* the generically 
named TCPIP.DATA data set which is identified to the address space from which 
originated the call.

-

Chris Mason

On Wed, 21 Dec 2011 09:36:15 -0600, Yanick Jacques 
<yanick.jacq...@saaq.gouv.qc.ca> wrote:

>Hi,
>   We run application in IDMS and CICS and we have the IP address in one 
> storage. Now we need more, I need the hostname. I'm wondering if it is 
> possible to do an assembler cross-memory program to talk to the adress space 
> of TCP/IP and only retrieve  the hostname associate with IP address.How do I 
> do to issue an DNS query to retrieve only the hostname and return the result 
> to the caller.

----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: INFO IBM-MAIN

Reply via email to