As long as your paging rates are in the low single digits, there should be no issue. My opinion is to leave it offline to z/OS. It takes CPU cycles to manage that storage (although at 8GB, probably not too many).
I believe z/VM has some similar issues with excess storage. Bottom line (IMO) is use what you need and leave the rest offline and unallocated for growth. P.S. Backstore (page slots) are only indirectly related to storage allocation. It depends on the usage of the storage allocation as too how many page slots are required. <snip> We run 4 LPARs - production z/OS and z/VM and test z/OS and z/VM. Right now we're running with about the same LPAR storage allocations that we had before, and see very little paging on any of our LPARs. The one exception is when we run an image of our production z/OS system under our test z/VM system for Disaster Recovery testing. Then we see lots of paging. . . . Since we're not paging on those systems, would we get any benefit from allocating additional storage to them? Or would we just be spending DASD space (because the backing store for paging would have to be bigger to accommodate the additional storage) for no benefit? </snip> ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
