I'm pretty sure, like 99.5%, that you can see this error by running out and not just screwing up your space somehow. IBM could probably tell you for sure probably... Remember, by the time you issue the q alloc, the situation could have already come and gone.
You didn't say say now much real memory you have, but that one 40G guest should have you at somewhere 35-40 mod 3's. You're going to either have to add HW in the form of paging devices or more real memory. Or shrink your guests significantly (always something to be looked at over and over in the z/VM env.). Marcy "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation." ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 7:53 PM To: [email protected] Subject: Re: [IBMVM] Paging Hi I have searched high and low and cannot for the life of me see anything that would have caused the page errors. These packs are not being accessed by any other user of LPAR and from all indications no cylinders have been overwritten. These two packs were bran new and formatted for the first time with CPFMTXA as page volumes. I guess my question is should I put a DRAIN on them before something tries to use them again and once/if drained remove them and re-init them and add them back? I am assuming that I will continue to see the page errors if these page packs are still being used correct? To sum this all up the page slots that are in use in my case adds up to about 39% of all the pages in use will not be reclaimed or paged in by the Linux guest until either the guest is recycled or the LPAR is IPL'ed is this a correct assumption for the most part? Now I see why so many page data sets are required for this z/Linux environment, interesting!!!! Terry ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: [email protected] Subject: Re: Paging That tells me that you allocated them correctly. The question is whether DSF actually wrote CP-compatible blocks (which are different than what minidisks use) on every cylinder. That's one of the reasons why I always add paging areas in full packs, and always run DSF on them, even if they're brand new or already been formatted by Some Other OS. >From the other conversation, you may have ended up with a minidisk overlapping a paging area. In either case, you should reformat the disks in question next time you IPL and have the system down for any period (can't do it while it's up if pages have actually been written to the paging areas; CP doesn't really give you an easy way to force migration of pages off a pack if they are still referenced by something). Taking the problem volumes offline and bringing the system up to the point of having OPERATOR logged in but before AUTOLOG1 comes up would be one way to safely reformat them without going to standalone DSF. As Marcy said, though: you are very light on paging space for guests of the size you describe. You probably should wheedle some more paging packs from your storage guys. --d b On 2/10/09 5:23 PM, "Martin, Terry R. (CMS/CTR) (CTR)" <[email protected]> wrote: Hi Yes, I formatted them using CPFMTXA. The output from the format showed that 0 0 PERM and 1 END PAGE. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 [email protected] ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 2:56 PM To: [email protected] Subject: Re: Paging Did you format the new paging disks with DSF or CPFMTXA before you attached them to SYSTEM? If you didn't, then that's the cause of the problem. received the following error just before the guest came down: > > HCP415E Six continuous paging errors have occurred on DASD nnnn volume > > volser. > > This error occurred on the two page packs that I just added yesterday > (VP51A0 and VP51A1). I believe I followed the appropriate steps to > defining and starting the new page data sets.
