Hal, This response has been due for nearly a month. I needed to be sure about the PPT SYST attribute before responding - see the SYST thread - and then I got waylaid with other stuff - sorry.
If you had two machines (Central Electronic Complexes (CECs) is the formal language I believe), couldn't LPARs on one be the backup for LPARs on another in a parallel sysplex? Maybe that'll feature in your "hot takeover". In other words I'm looking at the hierarchy of failure situations: 1. application 2. operating system 3. LPAR 4. machine You said you suffered from 1 (your IPL solution also covers 2) and 4 but never 3. Here I'm mentioning that dynamic VIPA can help you with 4 even if a fast IPL covers 1, 2 and 3. I guess it depends on your application but I would expect that, in many/most cases, restarting an application on another LPAR waiting with a live operating system was faster than IPLing. I've taken the simple view that one application has one IP address. Your use of the word "application" seems to consider composite "applications" with internal client-server relationships where components might be split onto different LPARs. > The applications do not BIND as far as we can see, ... I think I'm right in saying there is always a "BIND". Certainly for "server" programs[1], that is those programs where the initial contact is from the communicating partner, there must be a known IP address (and port) which the "client" making the connection (TCP)/initiating the transaction (UDP) specifies in the initial packet. Setting up this IP address and port is achieved by the bind() call. [1] For "client" programs using the connect() call, there is an implicit bind() call made "within" the connect() call. Because there is always a bind() call and because the server program will always specify INADDR_ANY, that is 0.0.0.0 - let us stick to traditional IP V4 for now, as the IP address (except when there is some customization for a specific address - which need not be specified), the PORT statement BIND parameter can always be used to specify a dynamic VIPA so that the VIPA becomes active with the program and becomes inactive with the program. Have I misunderstood something here concerning the lack of "BIND"? This is important since I wouldn't want anyone reading this to get confused over something so basic and vital for the use of dynamic VIPA. Maybe there is an issue with the only, as far as I know, alternative for server programming with is the PASCAL API. It may be that the PORT statement BIND parameter doesn't work with the PASCAL API. It's good that your automated VIPADEFINE and VIPADELETE work for you. An OBEY solution looks a bit complicated compared to the "official" way to "move" a VIPA associated with an application rather than associated with the LPAR itself. This is one of the following: a. You can ensure that the associated VIPA is "active" when the application is running by making the VIPA the value of the BIND parameter of the PORT statement for the server application. The VIPA would be defined using a VIPARANGE statement (VIPARANGE BIND in D TCPIP,,NETSTAT,VIPADYN messages) b. Alternatively, you can ensure that the associated VIPA is "active" when the application is running by adding a job step at the beginning of the server application procedure which "activates" the VIPA. The job step would contain the MODDVIPA program with "-c" specifying the VIPA. A job step should also be added at the end containing the MODDVIPA program with "-d" specifying the VIPA. This VIPA would also be defined using a VIPARANGE statement. (VIPARANGE IOCTL in D TCPIP,,NETSTAT,VIPADYN messages) c. An alternative to b is to have the application running on more that one LPAR and use your automation simply to issue the appropriate MODDVIPA command - or run a MODDVIPA procedure with suitable parameters. OSPF picks up on a VIPA being added to the HOME list and advertises the VIPA. As discussed in a spin-off topic in this thread you can ensure that the VIPA is advertised all by itself to the "backbone" router - in a typical network design - by use of the Advertise_VIPA_Route=HOME_ONLY parameter of the generic VIPA OSPF_Interface statement. (As is made clear in the spin-off conversation, I haven't actually tried this since the parameter is too new - but I proposed it based on a clear hole in OMPROUTE support, a hole now apparently filled.) If you wish I can send you my report which attempts to describe VIPAs - at the time of writing 2001. I detect you may have preferred to use MODDVIPA. With the aid of this report - written out of frustration with the official descriptions, so much good stuff so poorly described - you may find more comfortable ways to "activate" and "deactivate" your VIPAs. Since you regret that your applications do not support ARM, I guess you are operating a parallel sysplex. It is not actually necessary that an application incorporates support for ARM to be able to benefit from it. At the time I was examining the possibilities of dynamic VIPAs, it was quite a mystery to me that the ARM API was supplied but not some simple utilities so that it could be used by applications that did not imbed the ARM function. (This is in contrast to MODDVIPA where all of an API (the ioctl() call), a command and an utility are supplied.) As a result of asking about the PPT SYST attribute, I have been informed that an utility ARMWRAP had indeed been created as part of a redbook (or redpaper) project either back in 2000 or 2002 - it's not quite clear when. Back in 2001, in order to verify the suitability of ARM for use with dynamic VIPA, I created an ARM REGISTER utility and an ARM DEREGISTER utility. These were actually quite simple little assembler programs and, reading the notes I left for using these programs, I see that the reason the utilities can be simple is that the complicated stuff is contained in the ARM policy. The reason I delayed this response is that I wanted to be sure that I could talk about removing the PPT SYST attribute without leading anyone into difficulties. (See the "SYST" topic thread.) It appears that SYST can be removed as long as you add TIME=1440 (or NOLIMIT) to the EXEC statement for the PPT (SCHEDxx) PGMNAME entry. If you need to use the ARMWRAP utility (or the MODDVIPA utility) in an existing procedure, you will need to add a job step *before* the existing step and a job step *after* the existing step. This breaks one of the SYST rules, hence the need to remove it. I can assure you that ARM works. If you call up www.ibm.com and enter ARMWRAP in the Search field, you will get the ARM redpaper as the first "hit". (The "Additional Material" link takes you where you can download the ARMWRAP program.) How to "wrap" your existing program with the ARMWRAP utility is explained in probably as much detail as you need in 6 pages. VIPAs die only if OSPF in your routers says they are dead. I guess that's what you meant :-) - but you don't use OSPF you have static routes so who kills the routing entries pointing to the "dead" LPAR or, better expressed, "moves" the routing entries to point to the "live" LPAR? Where DNS can help in failure situations is in providing multiple destination addresses for a particular name. Thus a well-written client program can try the next address in the list in the structure returned by the gethostbyname() call if there is a failure on the current address it is trying. You don't need VIPAs for this - although the addresses which are tried may well be static VIPAs. Chris Mason ----- Original Message ----- From: "Hal Merritt" <[EMAIL PROTECTED]> Newsgroups: bit.listserv.ibm-main To: <[email protected]> Sent: Thursday, 23 February, 2006 5:45 PM Subject: Re: TCP/IP over Cisco router CIP > 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
