I'll second Brian's motion. Once long ago, distant in the mists of time, I formatted a new page 3390-3 volume from cylinder 1 *for* 3338 cylinders, instead of *for* 3339 cylinders. Yet I allocated it as PERM 0 END. 3338 was the highest cylinder number, but was not a proper total number of cylinders (does not include cylinder zero).
One moment's lack of attention caused Monday morning system crashes (with that same error message) for weeks until the problem was figured out. We IPLed every Sunday night, and finally tried to page out to that DASD slot around the same time every Monday morning. <sigh> Good learning experience, but not good for that year's salary merit increase. :-( Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. Brian Nielsen <[email protected]> Sent by: "The IBM z/VM Operating System" <[email protected]> 02/10/2009 01:38 PM Please respond to "The IBM z/VM Operating System" <[email protected]> To [email protected] cc Subject Re: Paging I would suspect that the entire PAGE extent on the volume was not formatted before attaching it to the system. Brian Nielsen On Tue, 10 Feb 2009 13:58:27 -0500, Martin, Terry R. (CMS/CTR) (CTR) <[email protected]> wrote: >Hi > >Thanks for the information. I did find another problem related to my >paging. I was having issues with my QREP guests, could not start up the >APPLY process for the application, slow logging on, etc. This is on the >LPAR that I mentioned that was doing the paging. I decided to restart >the z/Linux guest. When I issued the stop from the Operator console I >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. > > >q alloc page > EXTENT EXTENT TOTAL PAGES HIGH % >VOLID RDEV START END PAGES IN USE PAGE USED >------ ---- ---------- ---------- ------ ------ ------ ---- >530PAG 5104 1 3338 600840 301180 594838 50% >VP517A 517A 1 3338 600840 338482 600840 56% >VP517B 517B 1 3338 600840 334685 600838 55% >VP5198 5198 1 3338 600840 337162 600839 56% >VP5199 5199 1 3338 600840 333914 600840 55% >VP5109 5109 0 3338 601020 301240 598846 50% >VP51A0 51A0 1 3338 600840 75804 76125 12% >VP51A1 51A1 1 3338 600840 76068 76734 12% > ------ ------ ---- >SUMMARY 4694K 2049K 43% >USABLE 4694K 2049K 43% > >If you notice there is no error being displayed next to the entry of the >Q ALLOC PAGE display? > >Since I saw no other cause for the strange behavior of the Linux guest I >am assuming that the page error was causing this. Any ideas what might >have happened with the page and any recommendations. I have not had any >problems since the restart of the guest but I am wondering if the paging >errors are still there on these packs. > > >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] > >-----Original Message----- >From: The IBM z/VM Operating System [mailto:[email protected]] On >Behalf Of Tom Duerbusch >Sent: Tuesday, February 10, 2009 11:45 AM >To: [email protected] >Subject: Re: Paging > >If you don't have a product, and you want to find out who is actively >paging: > >Do an IND USER userid for each machine: > >ind user linux69 >USERID=LINUX69 MACH=ESA STOR=160M VIRT=V XSTORE=NONE >IPLSYS=DEV 0150 DEVNUM=00014 >PAGES: RES=00035557 WS=00040960 LOCKEDREAL=00000013 RESVD=000000 00 >NPREF=00006334 PREF=00000000 READS=00167708 WRITES=00143507 ><======== >XSTORE=000016 READS=109416 WRITES=243855 MIGRATES=134423 >CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 > RDR=000000 PRT=000469 PCH=000000 > >Look at the READS and WRITES on the 4th line. That is total page reads >and writes. >Put this in a REXX exec, and do a delta after, say 60 seconds. The one >that is changing the most, is the one that is paging the most. > >But I don't know what good that information would do. Paging isn't due >a single virtual machine, but rather the sum of the working set size of >all machines vs available storage. Chances are, the largest guest >machine will page the most as it has the most pages to keep in storage. > > >Tom Duerbusch >THD Consulting > > >>>> "Martin, Terry R. (CMS/CTR) (CTR)" <[email protected]> >2/10/2009 8:04 AM >>> >Hi > > > >I seem to be doing a lot of paging currently on my z/VM 5.3 system I am >running multiple Linux guests including a large Oracle guest (40 GB >memory size). How can I find out 1) who is doing the majority of the >paging and along with that 2) I believe that some of the paging slots >are old data in other words the pages are not going away after a task is >complete how can I research this. The Linux guests have not been >recycled but I thought if they had allocated the slots that after a task >within the Linux guest completed that the slots would be reclaimed. Any >thoughts on all of this would be appreciated. > > > >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] > > >======================== ========================= ======================= 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.
