""Mark Zelden"" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > On Wed, 2 Aug 2006 14:15:40 +0200, Vernooy, C.P. - SPLXM > <[EMAIL PROTECTED]> wrote: > > > > > >We are investigating the performance differences of the various MIM > >Control File configurations. We are fully Ficon and combine four z/OS > >1.6 Systems from two Sysplexes in the Mimplex, so our options are: > >Dasdonly, CTCDasd and CTConly. > > > >Does anybody have information about performance and allowable load of > >these three configurations? > > > > 1st = CTCONLY > 2nd = CTCDASD > 3rd = DASDONLY ** (see note below) > > CTCDASD is the same performance as CTCONLY (since it uses CTCs) > except when a system joins the MIMplex. Then the VCF (virtual > control file) temporarily migrates back to DASD during that > process. > > CTCONLY is of course better with FICON than ESCON. That is what we > use here since we share tape and dasd across sysplex boundries. > > ** DASDONLY is also what is used when putting the control file in > a coupling facility. This is the best configuration of all and is > comparable to GRS STAR. Of course you can only do this if your > MIMplex = parallel sysplex. > > I am not sure what you mean by "allowable load".
Mark and Ted, Thanks for the info. I was wondering if and why CTConly is faster than Dasdonly. We use Ficon and ESS and have no I/O queing and 100% cache hit ratio for the control file. In the Dasdonly configuration each system has to waitfor-read-writeback the control file, in a CTConly each system, except the Master, must request-update-sendback the controlfile, in both cases on Ficon speed. The Master will of course benefit from owning the VCF, but do the clients benefit substantially from CTC mode? With "allowable load" I refer to the MII activity rate that will not impact performance. I remember we removed SYSIGGV2 from converting to global enq when the Dasd control file was still on Escon chached disk, because this amount of activity in MIM was noticable in the system performance. The CA doc seems outdated. It mentions 3088's and Escon but no Ficon and the reported cycletimes seem rather high to me for current hardware: 6 msec cycletime for CTC and XCF, our Dasd cycletime is 3 - 4 msec. Maybe Norman can trigger some updates on this matter? 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
