falls into the 'stupid check' category in my opinion. Reasons: 1. In a monoplex with plexcfg=monoplex I really do not want another system to IPL into that monoplex just like that. So maxsystem for this is deliberately set to 1. It is stupid to have to change the check parm for maxsystem to zero just to keep this check from tripping. 2. In a sysplex I have set maxsystem to exactly the number of systems that are in this sysplex. Unfortunately, the check is stupid enough so that I cannot even tell it that this is what I want (and I don't want room to spare), because zero (the lower limit for the maxsystem value) will never be less than zero, only equal to zero, that XCF doesn't test for. The check got deleted in our systems. 3. MAXSYSTEM/MAXGROUP/MAXMEMBER in our installation has been grossly overspecified everywhere. (9/110/51 with peaks of 1/18/3 in the monoplexes and 4/40/24 or 5/82/34). It will cost an IPL to decrease back into an acceptable range. And it was deemed unneccessary to risk sysplex IPLs on never before used CDSs when the timing for re-availability was crucial.
Oh, and this was what IBM told me when I complained before: This check incorporates 3 capacity checks: system, groups, members. The last two are relevant in a monplex. IBM in general can't assume that the system check is irrelevant. A monoplex can be the result of customer specification, software specification (such as GRS), or environmental conditions (like problems with ETR). I don't think we retain history to know why it was set, so the check cannot distinguish the cases. Best practice is to run a true sysplex. Monoplex is a restriction imposed by the first system to IPL into the plex. The CDS used for a monoplex could also be used for a true sysplex. So, best practices is that there be room to grow, even for a monoplex. If the customer knows that this system and CDS will only be used as a monoplex, then the parameters for the check could be updated to specify zero for the system capacity. Note the sentence "Best practice is to run a true sysplex." Makes more money for IBM? In addition, which installation just IPLs new systems into an existing sysplex? Or switches which sysplex a system belongs to? I think that the planning involved to add another system into an existing sysplex (or even the merging of two sysplexes) is far bigger than resizing the CDSs to accomodate one or two new systems (including the setxcf commands or the resizing of the signalling structures) Barbara Nitz -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ---------------------------------------------------------------------- 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
