Rex I used to tell my students "There's no substitute for understanding what you are doing." In this case I feel tempted to replace it with "There's no substitute for reading the 'fine' manual."
In z/OS Communications Server IP Configuration Reference Version 1 Release 8, SC31-8776-10, section 1.2.29, "HOME", we find the following: <quote> Steps for modifying To modify the HOME statement, use a VARY TCPIP,,OBEYFILE command with a data set that defines a new HOME statement. Rules: If you use the HOME statement to change the IP addresses of any links, you should stop and restart the affected devices. Furthermore, if the OSPF dynamic routing protocol is being used over an affected interface, you should wait between stopping and restarting the device to enable the OSPF protocol to fully propagate the deletion of the old IP address. The duration of this wait should be at least three times the dead router interval configured for the interface. The first HOME statement of each configuration data set executed replaces the existing HOME list with the new list; subsequent HOME statements in the same data set add entries to the list. However, dynamically defined HOME list entries created by XCF dynamics, or a VIPADEFINE statement, or by bind() specifying an IP address within a currently valid VIPARANGE statement, are not deleted by a new HOME statement. Dynamically created HOME list entries can be displayed with the Netstat HOME/-h command. A dynamic XCF HOME list entry can be recognized by a link name of EZASAMEMVS or beginning with EZAXCF. A dynamic VIPA HOME list entry can be recognized by a link name beginning with VIPL followed by the hexadecimal value of its IP address. If the first HOME statement of a profile contains no entries, then all IP addresses that were specified in a HOME statement from a previous profile are removed from the HOME list. If you change the IP address of a link that was used by previously specified default routes and you want to maintain those default routes, you must include your GATEWAY or BEGINROUTES statements in the VARY TCPIP,,OBEYFILE command data set that contains the new HOME list. If you do not include your GATEWAY or BEGINROUTES statements, the static routes using that link are deleted. If you had previously specified the PRIMARYINTERFACE statement and want to preserve the primary interface that was previously specified, you must include your PRIMARYINTERFACE statement in the VARY TCPIP,,OBEYFILE command data set that contains the new HOME list. If you do not include the original PRIMARYINTERFACE statement, the primary interface is reset to the first entry in the new HOME list. </quote> I have made a small but significant change which is to remove the revision bars in order not to have a messy presentation of the text in received e-mails. Without checking minutely, the changes appear to be a major rewrite of the previous text probably for greater clarity rather than in order to reflect some new function. I leave it to you to check the "HOME" section all the way back to the z/OS V1R4 manual. Before I read through this text my first reaction was as follows: 1. You don't need to include the LINK and DEVICE statements in your OBEYFILE since nothing changes there. 2. I was nervous about not providing the whole HOME statement, that is all the HOME entries, but I wasn't sure - and I hoped the manual would rescue me. 3. Since this is making a change to the interface, I would expect a prior STOP to be necessary as well as a final START. Then I checked the text quoted above and I see I was essentially right about the STOP and START. However, I had a niggling doubt over whether or not simply putting STOP at the top of the OBEYFILE and START at the end would work. I found the following in section 1.2.54, "STOP": <quote> The START and STOP statements are processed after all other statements within the initial profile or VARY TCPIP,,OBEYFILE command data set. </quote> This means I was right to be nervous and you probably had in mind to issue a VARY TCPIP,,STOP command before processing your OBEYFILE command but you thought this was so obvious you didn't bother to mention it. Having read the text relating to modifying the HOME statement I see I was also right about not providing all the HOME statement entries in the OBEYFILE. The text above also - sort-of - answers your questions regarding the BEGINROUTES/ENDROUTES statement. Probably when the IP address of an interface is changed all routing table entries relating to that interface are removed. Thus you need to ensure that any static routes which specify that interface also appear in your OBEYFILE. And, because of the following paragraph from the text from section 1.2.10, "BEGINROUTES", you need to respecify *all* your static routes: <quote> The first BEGINROUTES statement of each configuration data set executed replaces all static routes in the existing routing table with the new route information. All static routes are deleted, along with all routes learned by way of ICMP/ICMPv6 Redirects and ICMP Fragmentation Needed. Routes created by OMPROUTE and router advertisements are not deleted. Subsequent BEGINROUTES statements in the same data set add entries to the routing table. </quote> Because the "HOME list" is completely replaced, you may need to include the PRIMARYINTERFACE statement. While composing this I see Pat has given you a reply. Nevertheless I think this may still have some use for you. Incidentally, you get Pat and myself with a post to IBMMAIN, but you may get more Communications Server IP experience if you post to the IBMTCP-L list. Chris Mason ----- Original Message ----- From: "Pommier, Rex R." <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Friday, 12 January, 2007 5:34 PM Subject: Simple TCPIP OBEYFILE question > Hi Listers. > > This is one of those "I think it works this way but I want to verify it" > type questions. > > > I have a z9BC box running z/OS 1.4. I have 2 OSA adapters defined to > TCPIP and I need to change the IP address on one of them. It is used as > a backup port so if I bounce the port I won't impact anybody. > > A section of my TCPIP.PROFILE looks like this: > > DEVICE GIGADEV0 MPCIPA > LINK GIGA00 IPAQENET GIGADEV0 > DEVICE GIGADEV1 MPCIPA > LINK GIGA10 IPAQENET GIGADEV1 > HOME > 172.16.0.1 GIGA00 > 172.16.0.2 GIGA10 > START GIGADEV0 > START GIGADEV1 > > I have an OBEYFILE that looks like this: > > DEVICE GIGADEV0 MPCIPA > LINK GIGA00 IPAQENET GIGADEV0 > HOME > 172.16.0.7 GIGA00 > START GIGADEV0 > > This OBEYFILE only contains the configuration information for the port I > want to change. I should be able to feed this OBEYFILE into TCPIP and > get the IP address changed without impacting the other OSA port, right? > If I don't put the unchanged information for the other port into the > OBEYFILE, TCPIP will leave it alone, right? Also, do I need to feed the > BEGINROUTES/ENDROUTES block into the OBEYFILE since that isn't changing > either? > > > Thanks in advance. > > Rex ---------------------------------------------------------------------- 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
