To be able to increase memory temporarily to get past a period of unusually high demand. As has been pointed out in the thread, TPF shops invariably have to reserve several GB of memory for native test systems that are seldom used. If that storage could be added temporarily, it could be a real benefit. The problem is, it takes LPAR deactivation/activation to remove it once added. So it is possible to borrow the memory without taking an outage; however, the same is not true of returning it.
Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of HARROP, Roy > Sent: Thursday, August 07, 2008 1:19 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: FW: ADD VIRTUAL MEMORY DYNAMICALLY > > Am I missing something here? The subject matter is "Add > Virtual Memory > Dynamically", which has got to be a function worth having - > but why would anyone want to remove it? > > Surely it's akin to being able to add packs for paging - and > you can't take them away (cue for a song?). > > This may be half a loaf, but even if it were just one slice, > it's got to be a good feature. The forum thread did make > interesting reading though... > > Regards, > > Roy Harrop > ----------------------------------- > > > -----Original Message----- > From: Mike Harding [mailto:[EMAIL PROTECTED] > Sent: 07 August 2008 00:25 > Subject: Re: ADD VIRTUAL MEMORY DYNAMICALLY > > The IBM z/VM Operating System <IBMVM@LISTSERV.UARK.EDU> wrote on > 08/06/2008 03:40:56 PM: > > > On Wed, Aug 6, 2008 at 11:48 PM, Bill Holder <[EMAIL PROTECTED]> > wrote: > > > > > Just to emphasize the point - the fact that most of CP's > storage is > now > > > mapped into virtual(the System Execution Space) is really > irrelevant > > to the > > > question of detaching memory. Although that mapping is indeed > the"default" > > > > I did not mean to make it sound easy. Being able to page it > would be a > > much harder one that being able to move it. At least we > don't need to > > walk all control blocks for pointers to the blocks in the > page that we > > moved. But you still need everyone out of the way when you move it > > (unless that is an atomic operation). > > -Rob > > 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 > ----------------------------------------- > *******************************************************************If > you are not the intended recipient, please notify our Help > Desk at Email [EMAIL PROTECTED] immediately. You should > not copy or use this email or attachment(s) for any purpose > nor disclose their contents to any other person. NATS > computer systems may be monitored and communications carried > on them recorded, to secure the effective operation of the > system and for other lawful purposes. Please note that > neither NATS nor the sender accepts any responsibility for > viruses or any losses caused as a result of viruses and it is > your responsibility to scan or otherwise check this email and > any attachments. NATS means NATS (En Route) plc (company > number: 4129273), NATS (Services) Ltd (company number > 4129270), NATSNAV Ltd (company number: 4164590) or NATS Ltd > (company number 3155567) or NATS Holdings Ltd (company number > 4138218). All companies are registered in England and their > registered office is at 5th Floor, Brettenham House South, > Lancaster Place, London, WC2E 7EN. > ********************************************************************** > >
