Chokalingam

Ideally, you would be posting in IBMTCP-L rather than IBM-MAIN since that is 
where you will find the greater concentration of folk who know and use the IP 
component of z/OS Communications Server - and also "TCP/IP for VM".

I'm going to assume IPv4 from this point on.

This is a tricky topic - mixed in with another tricky topic - so it's best to 
be 
very clear over what you have done.

> We have changed the IP address of our test mainframe ...

First to clear away possibly incorrect terminology. An IP address belongs to an 
IP *interface*. An IP address does *not* belong to an IP node. You may have 
established a static VIPA and you may consider that this IP address 
represents the IP logic in the test LPAR, the IP node, to be referenced by 
applications which are necessarily associated with the IP node such as the 
SNMP agent. Or your IP node may have only one IP interface and so you have 
got into the habit of thinking of the interface address as belonging to the 
node - quite understandable.

Actually whether the IP address is actually that of an interface or a static 
VIPA you logically associate with the node doesn't in fact affect the remaining 
discussion so very much.

Incidentally, the above was neither of the trick topics!

> We have changed the IP address of our test mainframe and the DNS names 
for the same.

So you have changed the IP address which you associate with the IP node 
and you have added an entry in the name server to which you refer which 
includes the new IP address and you have defined a name for it. You have 
removed the entry in the name server which contained the old address with 
which another name was associated.

What do you mean by

> we check the hostname in OMVS segment still showing old DNS name ... ?

and

> ... but MVS side it showing the new DNS name. ?

In other words what command is it that you enter and what is the output. Or 
perhaps it was not a command but some other operation which reveals a name 
which you imagine is the name stored with the IP address in the name server.

This is the first *tricky* topic: from where does the name in your tests come?

A. Some operations in an IP context take an IP address and, using whatever 
information is provided in order to perform the translation of IP addresses 
into 
names, use the gethostbyaddr() API call for the translation.

B. Other operations discover an IP address using the gethostid() API call and 
use that IP address, identified explicitly or by default as the 
PRIMARYINTERFACE and, using whatever information is provided in order to 
perform the translation of IP addresses into names, use the gethostbyaddr() 
API call for the translation.

C. Yet other operations simply acquire the name using the gethostname() API 
call without any reference to IP addresses or, of course, information provided 
in order to perform the translation of IP addresses into names.

All these operations now depend on the other *tricky* topic: where is your 
generically named "TCPIP.DATA" file?

Incidentally, it is here that Patrick Lyon's extremely sparse contribution 
fits, 
possibly relevant since it highlights where the "UNIX" and "MVS" paths have a 
divergence.

The relevance of the TCPIP.DATA file is that it contains the character string 
which satisfies the gethostname() API call as the HOSTNAME statement[1] - 
and - the statements used to access the name server - or a local file.

There is a search order which, if you have customised your "resolver" function, 
can involve merging parameters from two data sets - I did say *tricky*!

The search order is as follows:

<notes>

Base resolver configuration files
---------------------------------

Resolver - GLOBALTCPIPDATA

plus the first of the following%

* Environment variable - RESOLVER_CONFIG
* /etc/resolv.conf
  //SYSTCPD DD statement
# x.TCPIP.DATA
  SYS1.TCPPARMS(TCPDATA)
  Resolver - DEFAULTTCPIPDATA
  TCPIP.TCPIP.DATA

* only UNIX

# x is userid for UNIX and userid/jobname/procname for MVS
 
% If GLOBALTCPIPDATA used, the following are completely specified there:

DomainOrigin/Domain
NSInterAddr/NameServer
NSPortAddr
ResolverTimeOut
ResolverUDPRetries
ResolveVia
Search
SortList

The following may be found in the "search order" data set:

ALWAYSWTO
DATASETPREFIX
HOSTNAME
LOADDBCSTABLES
LOOKUP
MESSAGECASE
OPTIONS
SOCKDEBUG
SOCKNOTESTSTOR
SOCKTESTSTOR
TCPIPJOBNAME
TCPIPUSERID
TRACE RESOLVER
TRACE SOCKET

</notes>

You see that Patrick Lyon's /etc/resolver.conf file just about fits in here 
although it is more accurately /etc/resolv.conf.

It is actually an extension of the TCPIP.DATA tricky topic to be sure whether 
the IP function uses the "UNIX environment" or the "MVS environment". My 
notes on the "resolver", from which the above notes were taken, have 17 - I 
just counted them - *unresolved* questions concerning confusion in what is 
stated in the manual.

Just to "muddy the water", I believe there are some commands which distort 
the story just given by insisting on performing name to address and address to 
name translation in "non-standard" ways. When you have explained what tests 
you perform in order to discover your "names", we will be in a position to 
clarify whether you were using "standard" or "non-standard" commands.

So a summary is that "HOSTNAME" as it appears in the z/OS Communications 
Server IP component context is ambiguous. Either - a "HOSTNAME" might have 
resulted from an IP address to name lookup in a name server (or local, say, 
ipnodes, file), my case A above where an IP address is definitely used as input 
and case B above where the IP address is not evident - or - a "HOSTNAME" 
might have resulted from a direct reference to the relevant "TCPIP.DATA" file. 
That's why it's important to know what your tests were.

Chris Mason

[1] z/OS Communications Server IP Configuration Reference, Chapter 
5, "Resolver setup and TCPIP.DATA configuration
statements", "Configuration statements in TCPIP.DATA", HOSTNAME - Specify 
the TCP host name of the z/OS
communication server:

<quote>

host_name

The host name. If not specified or if not valid, the value is determined as 
follows:

- The system name specified in the IEFSSNxx PARMLIB member or on the P 
parameter of the EZASSI started procedure used for restartable VMCF. See 
z/OS Communications Server: IP Configuration Guide for details about 
configuring VMCF.

- If VMCF was not active at the time the TCP/IP stack was started, the 
CVTSNAME value (this is the SYSNAME=value in the IEASYSxx PARMLIB 
member A).

If the host name came from TCPIP.DATA, it is in the message case it was 
specified in on the HOSTNAME statement. For VMCF or CVTSNAME, the name 
is upper case.

The TCP/IP stack’s configuration function uses the z/OS UNIX search order to 
locate the TCPIP.DATA HOSTNAME statement to determine the stack’s host 
name. See search orders used in the z/OS UNIX environment in the z/OS
Communications Server: IP Configuration Guide for a description of this search 
order. This host name value is the value that is returned on gethostname 
socket function calls processed by the stack.

</quote>

I include the above in order to indicate that there are some *tricky* defaults 
in possibly unsuspected hiding places.

On Thu, 20 May 2010 15:24:34 +0100, Chokalingam Thangavelu 
<thangavelu.chokalin...@wipro.com> wrote:

>Hi,
>
>We have changed the IP address of our test mainframe and the DNS names
>for the same. But when we check the hostname in OMVS segment still
>showing old DNS name but MVS side it showing the new DNS name.
>
>Please let me know 1. From where 'hostname' command in OMVS picks the
>hostname information
>                   2. Do we need to change anything in OMVS side as part
>of this IP address changed activity
>
>Regards,
>Chokalingam
>
>Wipro Limited (Company Regn No in UK FC 019088)
>Address: Level 2, West wing, 3 Sheldon Square, London W2 6PS, United 
Kingdom. Tel +44 20 7432 8500 Fax: +44 20 7286 5703
>
>VAT Number: 563 1964 27
>
>(Branch of Wipro Limited (Incorporated in India at Bangalore with limited 
liability vide Reg no L99999KA1945PLC02800 with Registrar of Companies at 
Bangalore, India. Authorized share capital  Rs 3550 mn))
>
>Please do not print this email unless it is absolutely necessary.
>
>The information contained in this electronic message and any attachments to 
this message are intended for the exclusive use of the addressee(s) and may 
contain proprietary, confidential or privileged information. If you are not the 
intended recipient, you should not disseminate, distribute or copy this e-mail. 
Please notify the sender immediately and destroy all copies of this message 
and any attachments.
>
>WARNING: Computer viruses can be transmitted via email. The recipient 
should check this email and any attachments for the presence of viruses. The 
company accepts no liability for any damage caused by any virus transmitted 
by this email.
>
>www.wipro.com
>
>----------------------------------------------------------------------
>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

Reply via email to