A variant of Mike's idea would be to specify by SYSTEM CONFIG parm a
"ceiling" beyond which SXS would not be allocated. You could then IPL a
system with a given amount of storage, and subsequently take some away,
down as far as the previously-set ceiling.
Mark Wheeler, 3M Company
Bill Holder
<[EMAIL PROTECTED]
OM> To
Sent by: The IBM [email protected]
z/VM Operating cc
System
<[EMAIL PROTECTED] Subject
ARK.EDU> Re: ADD VIRTUAL MEMORY DYNAMICALLY
08/07/2008 11:48
AM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
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 was
>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 storage
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 to
be
made a priority over other functions already being requested.
- Bill Holder, z/VM Development, IBM
