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 stacks configuration function uses the z/OS UNIX search order to locate the TCPIP.DATA HOSTNAME statement to determine the stacks 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
