"TISLER Zaromil" <[EMAIL PROTECTED]> wrote in message
news:<[EMAIL PROTECTED]>.
..
> 
> I made some testing to see what happens in a case of a CF failure or CF
and
> system(s) failure.
> 
> Our test parallel sysplex configuration:
> 
>   4 systems (S1 - S4) z/OS 1.6
>   2 coupling facilities (CF1 & CF2) CFLEVEL 14
>   SMF policy with ISOLATETIME(0) CONNFAIL(NO)
>   GRS STAR configuration (ISGLOCK in CF2)
> 
> I was said that loosing one or more systems and the ISGLOCK structure at
the
> same time could bring the whole sysplex down if we use SFM weight defaults
> of 1.
> Our ISGLOCK structure has a default REBUILDPERCENT (according to
> documentation it should be 1, but in the message IXC360I displayed as
> "REBUILD PERCENT: N/A")
> 
> Test scenario 1:
> 
>   - set SFM weight for S3 to 40 (that was supposed to be the minimal
weight
> for the important systems), other systems have weight = 1
>   - deactivate lpars S3, S4, and CF2 at the same time
> 

Zaromil,

I do not have direct answers to your questions, but we did the same sort of
tests when implementing the WMQI Broker in datasharing mode and found some
things that might be useful to you:

We also deactivated the z/OS and CF LPARS at the same time to simulate a
full machine outage. It gave some unexpected and unexplainable results and
only after thourough testing and evaluating we concluded that we did NOT
bring down the LPARs at really the same time.

I suppose you select the icons on the HMC and do a deactivate for them. We
concluded that our CF's were activated before the z/OS LPARS and in our
case, DB2 immediately started recovery for its lost structures. Shortly
after that, the z/OS LPAR was deactivated and on a restart the found
situation was not as we expected, because DB2 had already started recovery
and was interupted in that process.

We found out that we had to deactivate the z/OS LPAR first and had to
deactivate the CF LPAR within the XCF timeout value, to prevent other
systems in the sysplex from starting recovery actions. This really simulated
a full machine outage as expected.

Hopes this helps,
Kees.


**********************************************************************
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.
**********************************************************************

----------------------------------------------------------------------
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

Reply via email to