Re: Changing the MF IP Address
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
Re: Changing the MF IP Address
Would you expand a bit on why you think you have to change the IP address? I didn't really understand the firewall comment. I think I agree with others that it's more graceful to add a second IP address first and then monitor any use of the old IP address. If anyone uses the old address, you can trace it back and notify that user that a loss of service is imminent without an address change. Run double for as long as you need, then retire the old address when you feel comfortable. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [EMAIL PROTECTED] -- 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
Re: Changing the MF IP Address
On Fri, 21 Mar 2008 10:02:09 -0500, Steve Grimes wrote: Question for the list: What should we be checking or looking for relative moving our MF behind a firewall and changing its IP address? Can you, as a test, change the IP address, not necessarily to its final value, before moving behind the firewall? This should be easier to back out if unexpected problems arise. No SMTP? What about sendmail? -- gil -- 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
Re: Changing the MF IP Address
Does your shop do anything with NJE over IP? How about Telnet connected sessions? Peter -- 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
Re: Changing the MF IP Address
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Grimes Sent: Friday, March 21, 2008 10:02 AM To: IBM-MAIN@bama.ua.edu Subject: Changing the MF IP Address Hello, I'm going to a meeting next week where I will advocate moving our MF behind the firewall, which means changing its IP address. The advance discussion has turned up an argument that this could (would) break a lot of stuff. I suspect that argument is based on FUDSI. But, I'm not the one in the systems group either. Here's what I do know: SNIPPAGE Question for the list: What should we be checking or looking for relative moving our MF behind a firewall and changing its IP address? SNIP I'd look for applications that have hard coded IP addresses w/in your z/OS environment (one application that talks to another via IP). Also, applications can use your IP stack that can have their own IP addresses (VIPA is one way). Depending on how your system is set up, you can also have more than one IP stack, meaning that you can have more than one address to your system (e.g., IPv4 or IPv6 stack, multiple NICs). Just a few things to look at and think about. Regards, Steve Thompson -- All opinions expressed by me are my own and may not necessarily reflect those of my employer. -- -- 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
Re: Changing the MF IP Address
In a message dated 3/21/2008 10:25:22 A.M. Central Daylight Time, [EMAIL PROTECTED] writes: (VIPA is one way). Depending on how your system is set up, you can also have more than one IP stack, meaning that you can have more than one address to your system (e.g., IPv4 or IPv6 stack, multiple NICs). Just a few things to look at and think about. Make sure your customers know! We did this about four years ago and was pretty painless. But we missed the 'Athletic Department' switch(couldn't send them the Academic progress reports) and the big Cisco switch that blocks incoming SMTP(23) from Open Gateway. **Create a Home Theater Like the Pros. Watch the video on AOL Home. (http://home.aol.com/diy/home-improvement-eric-stromer?video=15?ncid=aolhom000301) -- 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
Re: Changing the MF IP Address
We have changed ours several times over the past 12-15 years. We always published a name, never a number. Some people demanded a number anyway, some did their own lookup but either way, if THEY had problems, they were at the bottom of the triage list. You could do a netstat to see what ports are listening to see if you have missed any services. You might be able to get connection reports to see who is using those ports from your network or from SMF depending on the application. You need to ask if any client firewalls have your address in their allow list, they will need to add the new one as well. Printers can be a problem, the mainframe initiates the connection. Oracle was always a problem for us, for some reason the ORANAMES values had to be numbers, not names. Len Rugen -- 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
Re: Changing the MF IP Address
I have found that our network and support desk guys sometimes put in the ip address instead of the MF's canonical name in the tn3270 profiles. Either way you need to make sure that if the MF address is natted that the dns reflects the new ip address. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Steve Grimes Sent: Friday, March 21, 2008 10:02 AM To: IBM-MAIN@bama.ua.edu Subject: Changing the MF IP Address Hello, I'm going to a meeting next week where I will advocate moving our MF behind the firewall, which means changing its IP address. The advance discussion has turned up an argument that this could (would) break a lot of stuff. I suspect that argument is based on FUDSI. But, I'm not the one in the systems group either. Here's what I do know: --The MF is not an FTP server. We cannot ftp to the MF. We have never been able to. So, there's nothing in this area to break. (We can initiate FTP's in jobs on the MF.) --We aren't running SMTP on the MF, much to my chagrin. --Our 3270 terminal emulators (of which I have personally set up scores for various people over the years) all reference the MF by (one of) its domain names, never the IP. I think this is true for the hundreds that are out there accessing our on-line CICS applications TSO/ISPF. --Our MF environment is a single machine with 2 LPARS (plus a test LPAR) in a ring mode with GRS (whatever that means.) Question for the list: What should we be checking or looking for relative moving our MF behind a firewall and changing its IP address? Thanks! Stg -- 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 == This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. -- 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
