As a matter of fact, we have not been borrowing storage. We have had to bite the bullet and throw iron at the problem. Our current size was calculated to tide us over for 3 years. The memory used by the other LPARs sits idle until they are activated. I can see the possibility of our not making it the full 3 years with our current memory - the z/TPF machines are larger than the estimates. The use of the normally idle memory would probably suffice to get us to that point, so we may have to resort to borrowing memory from idle LPARs and taking the disruptions. That or a push to get off-budget funding for an early upgrade.
There is no such thing as half a loaf. Either we disrupt operation or we don't. It doesn't matter whether it is 1 time or 10 (Decimal). For example, suppose we schedule two disruptions four hours apart - one to give memory to another LPAR and the second to re-incorporate it into the VM LPAR. That will cause a work outage somewhere around the globe and the four hours will be seen as unproductive time - they will not want to start something that might not finish before the disruptions. Another problem is the scheduling of long-running tests. They cannot be started if they will be disrupted by LPAR deactivation. So we have the problem of trying to schedule long running tests, some as long as 72 hours, around the times that native LPARs are scheduled. This can lead to some unacceptable delays to one or the other. Thus the ferrous solution because there is no way to borrow memory and give it back without disruption. Regards, Richard Schuh > -----Original Message----- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Tuesday, August 05, 2008 11:24 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Some IBM Announcements for z/OS, z/VM, z/VSE > (Aug 5, 2008) > > On Tuesday, 08/05/2008 at 12:39 EDT, "Schuh, Richard" > <[EMAIL PROTECTED]> > wrote: > > I was interested in the ability to add memory to an LPAR because we > > have > > 2 LPARs that are used infrequently and it would be nice to > add their > > storage to VM. .... The new capability is absolutely useless to us. > > Nice boilerplate to show in sales pitches to management, > perhaps, but > > no practical value here. Our VM is as close to > > 24 X 365.25 as we can make it. Taking it down to reconfigure the > > storage is unacceptable. > > Is not half a loaf better than none? Now you can add memory > without taking an outage. If you've been taking outages to > add/delete memory, you've cut the number in half. > > Everyone likes the idea of being able to remove the memory, > but waiting until we can do it (an extremely complex and > expensive task) to deliver the "add" support was uniformly > met with boos and hisses when we polled customers. > > Alan Altmark > z/VM Development > IBM Endicott >
