The increases recommended by the CF Sizer is marginal. Our structures in production are generously sized and we have lots of storage in the new CFs so that's not a concern. I will however lookout for messages as suggested.
Most of our structures are duplexed. Some like the structure for the IRLM lock are not. I have a note to investigate the product specific doc to understand this better. I also need to check on the performance of CF links as we're going to ICB links now. Thanks for the info. On Fri, Dec 18, 2015 at 12:42 PM, Skip Robinson <jo.skip.robin...@att.net> wrote: > In case you're curious, the parameters 'missing' from your old > definitions were added over the years since the advent of coupling > facility. The new parameters all have defaults such that they do not > actually require specification, but using them may give you better control > over structure sizes. Some additional points: > > -- At any time, the CF Sizer makes recommendations based on the latest > hardware with the latest microcode. Newer hardware or newer microcode > typically requires larger structures to accomplish the same work even with > no changes to the exploiters. > > -- In my experience, CF Sizer makes very generous recommendations. Memory > is cheaper now than ever, but watch out for gratuitous over allocation. > Especially on an external CF, you might be constrained. > > -- Several structures require that you input data to CF Sizer on how busy > you expect the structure to be. For most, this has less to do with the > number of sysplex members than the amount of data the structure has to > handle. This is seldom easy to determine. Make your best SWAG and monitor > the results. > > -- The worst case is when a structure is too small for the exploiter to > initialize. I have not seen this for some time; maybe the big exploiters > have been (re)designed to come up regardless. But watch for messages > indicating that a structure needed more than the specified minimum size at > the outset. > > -- A parameter you did not ask about is DUPLEX. Even if you have only one > box for CF use, I recommend two CF LPARs on that box with duplexing for > relevant structures. Better of course would be two boxes. The best thing > about sysplex is its ability to survive disruptions. Over the years we have > had two CEC failures. In both cases, the second CF allowed all applications > to resume with zero data recovery efforts. Note that some structures do not > require duplexing, notably GRS. If a host dies, so do all of its enqueues. > > > . > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > jo.skip.robin...@att.net > jo.skip.robin...@gmail.com > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of phil yogendran > Sent: Friday, December 18, 2015 07:39 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: [Bulk] Re: Coupling Facility Structure Re-sizing > > Thank you all for your replies. I will take your suggestions into > consideration going forward. We are in the process of upgrading from z10 - > > z12 -> z13 over the next few months. The CF upgrade is a part of this > project. The CFs are going from 2097/E10 and 2098/E12 to 2817/M15. > > I expect to see better structure response with these changes and will be > surprised to see anything otherwise. Will keep you posted. Thanks again. > > On Fri, Dec 18, 2015 at 8:16 AM, Richards, Robert B. < > robert.richa...@opm.gov> wrote: > > > The archives probably have it, but simply put and if IIRC, there was > > an old 9674 being used with z990s. Waiting on CF structure response > > was horrific as compared to the speed of the z990 processor response. > > > > -----Original Message----- > > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] > > On Behalf Of Elardus Engelbrecht > > Sent: Friday, December 18, 2015 7:55 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Coupling Facility Structure Re-sizing > > > > Richards, Robert B. wrote: > > > > >The last thing you want is for your CFs to be slower than the CPs. > > >BTDTGTS > > > > Ouch. Could you be kind to tell us about it? Are there any manuals > > stating that trouble? Any configuration changes to avoid? Or is it > > about the sizes or quantity of LPARs involved? > > > > TIA! > > > > Groete / Greetings > > Elardus Engelbrecht > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
