On Mon, 17 Jul 2006 11:53:39 EDT "(IBM Mainframe Discussion List)" <[EMAIL PROTECTED]> wrote:
:>In a message dated 7/17/2006 10:25:15 A.M. Central Daylight Time, :>[EMAIL PROTECTED] writes: :>>CPU timer, though MVS will change it when different work is dispatched. :>MVS will not dispatch other work in the scenario I described, since my code :>is disabled, so I could use the CPU timer unless it is also updated when a :>different LPAR is dispatched, which I do believe is the case (see below). :>>The CPU timer is documented to not decrement when the CPU is in a stopped :>>state, which would seem logically equivalent to not being dispatched on an :>>LPAR. :>That does not seem logically equivalent to me, although I could be wrong. :>The CPU is in a stopped state only when the operator stops it, or when some :>error causes the CPU to stop itself. Otherwise the CPU is always in the :>operating state (or load or check-stop, the only possible four mutually exlusive :>states of a CPU). The way I understand things, the hypervisor does not manage :>virtual CPUs, only virtual or logical partitions. When control is taken away :>from one LPAR and given to another, all CPUs involved continue in the :>operating state. If the hypervisor were to save the contents of the CPU timer for :>all CPUs used by an LPAR and then restore it the next time the interrupted :>LPAR is dispatched, then your theory would hold. I don't know if it works that :> way. The details of the hypervisor are not described in the Principles of :>Operation. The hypervisor would be required to swap the clock comparator and the CPU timer, since not doing that would cause incorrect charging and lost interrupts. For example, LPAR1 sets the clock comparator and LPAR2 is dispatched on the CPU when it hits. LPAR2 would get the external and LPAR1 would never see it. -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- 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
