Steve I'm sorry about the delayed response.
You should know that there is another list which concerns itself specifically with the Communications Server IP component under z/OS. This query might have attracted more attention there. The following is the text attached to the bottom of posts: <quote> For IBMTCP-L subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO IBMTCP-L </quote> - A "mainframe", which you later clarify - to some extent - in your case consists of 2 LPARs, does not posses an IP address. Interfaces to a particular LPAR - as supported by the Communications Server IP component - posses an IP address. I could guess - but it's always better not to have to guess when trying to answer questions - that the IP address which you are faced with changing is assigned to an OSA port. I could also guess that the OSA in question is shared between your 2 LPARs and so is assigned different IP addresses, one for each LPAR. It may be - more guessing - that you adopt the approach to create a static VIPA within each of your CS IP instances which has the purpose to represent your LPAR and is the IP address you use for those applications, such as the SNMP agent, which necessarily are associated specifically with the IP node. This is in contrast to other applications which can run on either of your LPARs or perhaps run on both as a distributed service. In the former case you would use a dynamic VIPA defined with a VIPARANGE statement (and possibly use the BIND parameter of the PORT statement entry) and in the latter case you would use minimally dynamic VIPAs defined with VIPABACKUP statements (or, for one of them, a VIPADEFINE statement) and a VIPADISTRIBUTE statement. I have assumed of course that your 2 production LPARs belong to a sysplex. In any case, whatever the means by which applications in partner IP nodes access the applications on your LPARs, the key consideration, as pointed out by many, is to use names rather than numbers, the actual IP addresses. In the same change slot in which you change the IP address - or addresses - you also change the name serve tables. When having to deal with similar issues with customers, I have been surprised - am I being naive? - by the lack of a comprehensive and current inventory of IP applications (and/or SNA applications). It's at times like these when such an inventory is vital. Regarding using names rather than numbers, when approaching the application folk, I have sometimes been told that numbers have to be used. This may just be ignorance on their part, simply that whoever set up the application followed some samples from a redbook that happened to use numbers because that was easier in the ITSO shop which conducted the "how-to" tests for the redbook. All well-behaved IP applications adopt the following pattern when handling the character string which represents the identity of the communication partner: - Try to convert the string as a dotted decimal address to a 32-bit IP address using the inet_addr() call If this succeeds, job done If this fails, - Try to convert the string as a name to a 32-bit IP address using the gethostbyname() call If this succeeds, job done If this fails, create a message to say the identity is wrong Note that the inet_addr() call is purely an internal subroutine which manipulates the character string in an attempt to convert the generic dotted decimal number into a 32-bit IP address. The generic dotted decimal number may contain 0 to 3 actual period (full stop) characters. By contrast, the gethostbyname() call involves resolving the name to an IP address by reference to either or both of a local file and the name server system external to the IP node. In fact, the address of the structure returned by the gethostbyname() call can contain a pointer to a list of IP addresses, not just one. The well-behaved IP application will try to use each of the addresses, in turn, in the connect() call for the case where the protocol is TCP, in order to try to contact the partner node. If the folk responsible for the application persist - one would hope after possibly eye-opening testing - in insisting that their applications are not well- behaved, you are going to have to go chasing through application parameters looking for hard-coded IP addresses. You are then going to have to make sure that the application parameters are changed during the change slot mentioned above. You also have my permission to put a flea in the ear of the salesman for the vendor who sold you the software suggesting that they smarten up their product! - Incidentally, you mention you do not run FTP servers but do run FTP clients. You suggest that the risk is with the FTP server rather than the FTP client. Actually, as you might suspect from the description I have just given, it is the *client* function which is most at risk. Server functions have historically (prior to using the tricks associated with the PORT statement entry BIND parameter, for example) used INADDR_ANY as the IP address to be used to contact the server rather than a specific IP address. You say "Our 3270 terminal emulators ... all reference the MF (meaning TN3270 server function) by (one of) its domain names, never the IP. I think this is true for the hundreds ..." Well, of course, it's "never" only if you *know* rather than *think*! In any case, this use of a name rather than a number by the *client* function is what matters. Chris Mason ---------------------------------------------------------------------- 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
