See imbedded. Note: I make the statement 'we have never had an LPAR failure' which is not completely true. We have had a machine failure, and we have had catastrophic failures of our most loved online application. In each case we simply IPL'ed and we were back on the air in much less time that it would take to move to another LPAR. That said, we *are* moving to some sort of 'hot takeover' strategy and we expect VIPA to be an important component.
So, the statement is meaningful in this specific context. Hal -----Original Message----- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Chris Mason Sent: Thursday, February 23, 2006 7:45 AM To: [email protected] Subject: Re: TCP/IP over Cisco router CIP Hal, I'm pretty sure you are using VIPA as I would expect but a couple of clarifications might help. I think you may have missed a word out in your sentence "So, you assign as many VIPA addresses as you need to each application." Perhaps this should be "So, you assign as many VIPA addresses as you need, one to each application." I can't see you would need multiple VIPAs for one application. >>All depends on the application. An application may have components that intercommunicate via IP and these components could wander from LPAR to LPAR. That would be two or even more: one to access the target component, and one for the component to access another component(s). IIRC, DB2 does this. You describe associating the existence of a VIPA with the application such that, when the application begins, the VIPA exists and, when the application ends, the VIPA no longer exists. Just as a matter of curiosity really, do you do this by means of the PORT statement BIND parameter - as John Giltner appears to - or do you use a job step which calls the MODDVIPA program or, possibly, some other automation based on the moddvipa command in order to introduce and remove the VIPA to and from the appropriate LPAR. >>>Even more simple. The applications do not BIND as far as we can see, so we use VIPADEFINE and VIPADELETE via canned OBEY files. These OBEY files are invoked via semi automated scripts or sometimes written, manual procedures. I could not get the MODVIPA process to work to suit me. And now I've thought of another question: Do you use the Automatic Recovery Manager (ARM) function in order to restart an application in another LPAR following a failure? To my mind dynamic VIPA and ARM tend to go together. >>Nope. That would be ideal, but, again, our applications do not support that. We have never had an LPAR failure, so we are not 100% sure this will work: the thought is that upon an LPAR failure, the VIPAs die right along with the operating system. The VIPADEFINEs would then be executed on the take over LPAR and we rock on. When the dead LPAR regains life, it comes up without the VIPAs active so there is no conflict. There was an issue with VIPAs and OMPROUTE OSPF dynamic routing. Ideally it should be possible to advertise a VIPA using a "host", single (the VIPA itself) address rather than a subnet range. When I examined setting this up in 2001, the last time I consulted on this topic, I seem to recall this ideal was not possible. Has anything changed or is it still necessary to assign, say, 4 addresses to each dynamic VIPA in order to advertise availability of individual dynamic VIPAs outside the LPAR? Of course, the waste may not really be a problem when assigning addresses from, say, network 10 in an intranet. >> Not an issue. We currently use only static routes. Not clear how the network folks deal with the wandering VIPAs. I am aware that there is a DNS in the mix somewhere. ---------------------------------------------------------------------- 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
