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
