I am not sure about VIPA and don't know how to check if that is in use but I doubt it. The production lpar here is considered sacred and recently the test lpar started to require high availability so they carved out this relatively new lpar for our systems sandbox. Each lpar has it's own ip address if that helps. It's only the sandbox that I have been bouncing.
Ken Klein Sr. Systems Programmer Kentucky Farm Bureau Insurance - Louisville [email protected] 502-495-5000 x7011 -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Vernooij, CP - SPLXM Sent: Thursday, July 09, 2009 10:14 AM To: [email protected] Subject: Re: Sysplex timeout problems. Kenneth, AFAIK, you did not answer the question about (D)VIPA. Could it be that the connections from remotes to the Production LPAR that remained alive, were routed throught the LPAR that was reset? The situations are quite different depending on the answer to this question. Kees. "Klein, Kenneth" <[email protected]> wrote in message news:<53f9fd7ef019734593da99911fa2496102083...@sxch205.kfbdom1.kyfb.pri> ... > We have INTERVAL(85) and OPNOTIFY(87) and CLEANUP(15) so my question is > when the resources get frozen. The resources I am concerned about would > be the network, probably TCP/IP related, which cause the distributed > nodes to get timeouts. Is it when I issue the V,XCF,SYSTS1,OFFLINE or > R__,sysname=systs1 or when I click RESET - OK? And when does the > INTERVAL and OPNOTIFY period begin. Perhaps this site should set the > INTERVAL and OPNOTIFY to something like 30 and 35 to shorten the time > the resources are frozen. > > As far as weights are concerned, that calculation determines which lpars > remain in the sysplex if connectivity is disrupted. If A loses its > connection to B then will C continue sharing with A or B... > > I remember Gummibaeren, not seen in the states too often. > > > Ken Klein > Sr. Systems Programmer > Kentucky Farm Bureau Insurance - Louisville [email protected] > 502-495-5000 x7011 > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Barbara Nitz > Sent: Thursday, July 09, 2009 8:27 AM > To: [email protected] > Subject: Re: Sysplex timeout problems. > > This actually requires reading up on what the parms in the SFM policy do > :-( I know why we treat all our systems the same! A quick look makes me > guess that they intended to specify different weights to the lpars to > keep the production system alive and kill the test system, if necessary. > That is kinda confirmed by the PROMPT for the production system. > > To be honest, while I (intellectually) understand the different weights, > in reality the cases I have seen did not leave any choice but to remove > a system that was 'dead' and was specified in either the ixc402D or > IXC102A, so one might as well treat them all alike! > > EXSPAT: We don't have any such member in our parmlib concat, either. > Meaning that we take all the IBM defaults. Then you apparently also take > the IBM default, which I would consider good. > > As for the 'Suessigkeiten' - I am a fan of (virtual) gummibears! :-) > (Just ask my colleagues!) :-) > > Best regards, Barbara > > ---------------------------------------------------------------------- > 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 > > ---------------------------------------------------------------------- > 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 ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************************** ---------------------------------------------------------------------- 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 ---------------------------------------------------------------------- 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
