Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY IBM Mainframe Discussion List <[email protected]> wrote on 09/13/2007 01:09:35 PM:
> I don't understand this state either :-) > > That's why I'm asking this august group. > > What I'm hearing is the possibility of interesting hole in IBM code. > That is, you are not permitted to define more logical processors than > there are CP's. But you are permitted to remove CP's without first > putting offline. > > At point in time of definition, there were four CP's and four LP's were > defined. > > Now one CP quietly goes away. We are not -defining- anything, so that > rule is unbroken. But we did seemingly end up with four LP's running on > 3 CP's. > > Performance has been as expected. I have no indication of any problem > being caused by the 4/3 situation. > > Here is a clue: none of the other LPAR's had all four CP's defined. One > had three and the others only one each. So, the one with all four > defined still shows all four. The other LPARS show CP 3 as 'N' as > expected. > > My knee jerk would be to configure CP 3 offline, which is something I > guess I should have done before the upgrade. But, again, I'm worried > that something is broken and I might break it worse. And, I've never had > to do anything like this before. Backing down from a capacity on demand > upgrade does include a deactivate/reactivate sequence, but that is > spelled out in the instructions. > > One here is worried that we are actually still using the fourth CP, but > at full speed. When we next POR or IPL, we could take an unexpected > performance hit. > This is working as intended. You are not using the fourth physical CP. The removal of a physical CP will be blocked only if it would reduce the number of physicals below the number of currently online CPs in all active zones which use dedicated processors, plus at least one CP for the shared pool. LPAR will allow a zone which uses shared CPs and has more online processors than the number remaining in shared pool after removal to continue to run in this overcommitted state, but of course that is not optimal from a performance point of view, so we would recommend that you use the MVS CF CPU(x),OFFLINE command to reduce the number of online logical CPs in any zone so that it does not exceed the number of processors in the shared pool. One you do this, LPAR will not allow you to CF CPU(x),ONLINE to get back into an overcommited state. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY ---------------------------------------------------------------------- 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
