On Thu, 7 Aug 2008 11:48:24 -0500, Bill Holder <[EMAIL PROTECTED]> wrote :
>On Wed, 6 Aug 2008 16:25:27 -0700, Mike Harding <[EMAIL PROTECTED]> wrote: > > >... >> >>An alternative - which might even satisfy Mr. Schuh - could be to restrict >>"detachable" memory to that which has been dynamically added after CP w as >>iplled. I wouldn't think the SXS would extend into such, which would make >>it easier to clear. Of course it's been a while since I did much perusing >>of CP internals... >>--Mike >>======================== ========================= ======================== > >Yes, that simplifies it somewhat, wouldn't require pre-definition of the >detachable range, but it still means rewriting pretty much all of storag e >allocation to know certain areas are restricted and need to be managed >separately, and all allocation logic would need to be additionally >multi-pathed based on request type. Not a trivial undertaking by any means, >but feasible enough, I suppose, if enough customers were to ask for it t o be >made a priority over other functions already being requested. > >- Bill Holder, z/VM Development, IBM >======================== ========================= ======================= Did you see my post yesterday regarding XSTORE? I've included it below. Brian Nielsen On Wed, 6 Aug 2008 16:58:40 -0500, Brian Nielsen <[EMAIL PROTECTED]> wrote: >Perhaps I'm missing something, but doesn't XSTORE already meet those >criteria? If so, adding the new storage as XSTORE to the LPAR and later >removing said XSTORE from the LPAR is a much simpler task.
