First, since CP should know at all times how much space of each category (PAGE, SPOL, etc.) is allocated, it should be able to immediately reject any request (LOGON, DEFINE STOR, etc.) where the amount of storage requested exceeds the amount of secondary storage configured.
Second, since CP "should" know at all times how much space of each category (PAGE, SPOL, etc.) is in use, it should be able to immediately reject any request (LOGON, DEFINE STOR, etc.) where the amount of storage requested exceeds the amount of secondary storage available. If this is not happening, I would argue that the situation should be APAR'able as a system integrity bug. Now, we can debate whether pages allocated, but not used, should be counted. Should such pages require secondary storage backing availability, or should secondary storage backing availability be required only when the page is used? Should this be a system configurable option? Should this be a virtual machine configurable option? John P. Baker -----Original Message----- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Lee Stewart Sent: Tuesday, September 15, 2009 4:56 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: VM lockup due to storage typo Gee, I guess we're in good company! ;-) It does seem to me that CP should be smart enough to look at a 175GB real storage, 4GB Xstor, and xx number of page packs and say not in our wildest dreams can we run an 8TB virtual guest... Or maybe at the point that the 8TB guest starts choking off all other activity and wildly filling page space.... Lee
