Thanks Dennis!
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 O'Brien, Dennis L Sent: Wednesday, February 11, 2009 12:28 PM To: [email protected] Subject: Re: Paging Terry, You should definitely DRAIN the volume until you can fix it. The CP DRAIN command will take care of that until you IPL Instead of linking the volume and changing the label so that the volume won't be used after IPL, I find it easier to drain the volume in SYSTEM CONFIG. Add the lines Drain Volid VP51A0 PAGE Drain Volid VP51A1 PAGE to SYSTEM CONFIG. After you IPL and re-format the volumes with CPFMTXA, take those lines out and CP START the volumes. There's nothing wrong with Mike's method. I just think mine is easier. Use whichever you like. Dennis O'Brien 39,585 ________________________________ From: The IBM z/VM Operating System [mailto:[email protected]] On Behalf Of Mike Walter Sent: Tuesday, February 10, 2009 20:33 To: [email protected] Subject: Re: [IBMVM] Paging If there are no overlapsn then all I can think of is a real hardware error (unlikely, right?), or the repeated warnings about not having formatted EVERY CP-allocated cylinder (usually the first or last cylinder in an allocation). Yes, DRAIN the volume. CP won't right new pages to it. If you CP RESET or IPL virtual servers with pages on it, they will not be paged in. You can even allocate a minidisk on cylinder zero (personally, I'd allocate the full pack), link to that mdisk R/W, run CPFMTXA on.it ONLY to re-label it to some temporary volser (e.g. vmxx01). Since it is already online, CP won't see the label change untl the next time it comes online. Since a page volume with allocated cylinders can't be taken offline on a running system, it won't be used by the system at the next IPL. Let the system come up (presuming that by then it will have more page volumes), and you can run CPFMTXA on it at your leisure. Be 100% certain at that to format the whole volume from cyl 0 to end, and then alloc Cyl 0 as perm and 1 to end as page, also re-labeling it as it's desired page volser. Spool the console START and save it so you have proof later. You can then dynamically bring it online and CP START it for paging. Mike Walter Hewitt Associates ________________________________ From: "Martin, Terry R. (CMS/CTR) (CTR)" [[email protected]] Sent: 02/10/2009 10:53 PM EST To: [email protected] Subject: Re: 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. ________________________________ The information contained in this e-mail and any accompanying documents may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient of this message, or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message, including any attachments. Any dissemination, distribution or other use of the contents of this message by anyone other than the intended recipient is strictly prohibited. All messages sent to and from this e-mail address may be monitored as permitted by applicable law and regulations to ensure compliance with our internal policies and to protect our business. E-mails are not secure and cannot be guaranteed to be error free as they can be intercepted, amended, lost or destroyed, or contain viruses. You are deemed to have accepted these risks if you communicate with us by e-mail.
