Paging in a Mixed Environment
If we have an environment that consists of both IFL and regular CPUs, where does the overhead for I/O done by Linux running on an IFL happen? Are CCW translation and the handling of I/O interrupts handled by the IFLs, CPUs, or both? If both, how about the overhead incurred by something running on regular CPUs? Regards, Richard Schuh
Re: Paging Dave Jones
Dave's not here, man:-) On 10/05/2010 12:34 PM, Michael Coffin wrote: > Sorry List - DJ please send me an email when you receive this, my emails to > you are bouncing. Thanks. -Mike :) > > -- Dave Jones V/Soft Software www.vsoft-software.com Houston, TX 281.578.7544
Paging Dave Jones
Sorry List - DJ please send me an email when you receive this, my emails to you are bouncing. Thanks. -Mike :)
Re: 3390-3 DASD Paging devices still needed?
Dear Kris, Thank you very much. This is what I was wondering if z/VM would use PAV b ut is doesn't. Thank you very much. Kind regards, Florian On Mon, 21 Jun 2010 15:15:38 +0200, Kris Buelens wrote: >I wouldn't say paging is specially optimized for 3390-3. But, simple >example, if you'd need 9GB of paging space, >- with 3390/3 you have 3 access paths, CP can do 3 paging operations >concurrently >- with 3390/9 there is only one access path, hence only 1 paging operati on >PAV -that assigns more than one address to a given volume- will not >halp as CP doesn't se PAV on paging volumes. > >So, for high paging rates, the more volumes the better. > >Kris Buelens > >2010/6/21, Florian Bilek : >> Dear all, >> >> We are intending to migrate from a DS8100 to a new DS8700 and consider to >> quit with 3390-3 DASD addresses during this migration. >> >> I remember that there was always the saying that paging devices should >> reside on 3390-3 since the paging code was specially optimized for tho se >> devices, I wanted to verify if this is still valid for z/VM 5.4 and 6. 1. In >> that case we would still need a range of 3390 devices. >> >> What would be your recommendation? >> >> Thank you very much in advance for your feedback. >> >> -- >> Best regards >> >> Florian >> > > >-- >Kris Buelens, >IBM Belgium, VM customer support > =
Re: 3390-3 DASD Paging devices still needed?
I wouldn't say paging is specially optimized for 3390-3. But, simple example, if you'd need 9GB of paging space, - with 3390/3 you have 3 access paths, CP can do 3 paging operations concurrently - with 3390/9 there is only one access path, hence only 1 paging operation PAV -that assigns more than one address to a given volume- will not halp as CP doesn't se PAV on paging volumes. So, for high paging rates, the more volumes the better. Kris Buelens 2010/6/21, Florian Bilek : > Dear all, > > We are intending to migrate from a DS8100 to a new DS8700 and consider to > quit with 3390-3 DASD addresses during this migration. > > I remember that there was always the saying that paging devices should > reside on 3390-3 since the paging code was specially optimized for those > devices, I wanted to verify if this is still valid for z/VM 5.4 and 6.1. In > that case we would still need a range of 3390 devices. > > What would be your recommendation? > > Thank you very much in advance for your feedback. > > -- > Best regards > > Florian > -- Kris Buelens, IBM Belgium, VM customer support
3390-3 DASD Paging devices still needed?
Dear all, We are intending to migrate from a DS8100 to a new DS8700 and consider to quit with 3390-3 DASD addresses during this migration. I remember that there was always the saying that paging devices should reside on 3390-3 since the paging code was specially optimized for those devices, I wanted to verify if this is still valid for z/VM 5.4 and 6.1. In that case we would still need a range of 3390 devices. What would be your recommendation? Thank you very much in advance for your feedback. -- Best regards Florian
Re: 3390-9's for paging
Hello Dennis, We did go from 3390-3 to 3390-9. Difference is that the 3390-3 disk had other stuff on it than the paging function. I have a separate 3390-9 for paging and another 3390-9 for spooling. Went from EMC ESCON to DS6800 with FICON. Everything was just better. No paging or any other issues. Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Tuesday, December 01, 2009 3:31 PM To: IBMVM@LISTSERV.UARK.EDU Subject: 3390-9's for paging Our storage architect is trying to get us to use 3390-9's instead of 3390-3's for paging. I know that z/VM doesn't use PAV or HyperPAV for paging, and that more devices means more concurrent I/O's. Has anyone actually tried changing from 3390-3's to one-third as many 3390-9's? If you have, was there a measurable difference in performance? Dennis "I always remind people from outside our state that there's plenty of room for all Alaska's animals -- right next to the mashed potatoes." -- Sarah Palin
Re: 3390-9's for paging
Kris, Thanks, but this is for a new workload. The z/VM system is up, but there's nothing running on it, yet. We're planning on a 3:1 ratio of logical/physical memory. Dennis "I always remind people from outside our state that there's plenty of room for all Alaska's animals -- right next to the mashed potatoes." -- Sarah Palin From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Kris Buelens Sent: Tuesday, December 01, 2009 12:58 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] 3390-9's for paging Just have a look at how busy your current page packs are today. Then we can predict something. (eg if you hardly ever page, you will not notice a difference) 2009/12/1 O'Brien, Dennis L mailto:dennis.l.o%27br...@bankofamerica.com> > Our storage architect is trying to get us to use 3390-9's instead of 3390-3's for paging. I know that z/VM doesn't use PAV or HyperPAV for paging, and that more devices means more concurrent I/O's. Has anyone actually tried changing from 3390-3's to one-third as many 3390-9's? If you have, was there a measurable difference in performance? Dennis "I always remind people from outside our state that there's plenty of room for all Alaska's animals -- right next to the mashed potatoes." -- Sarah Palin -- Kris Buelens, IBM Belgium, VM customer support
Re: 3390-9's for paging
Just have a look at how busy your current page packs are today. Then we can predict something. (eg if you hardly ever page, you will not notice a difference) 2009/12/1 O'Brien, Dennis L > > Our storage architect is trying to get us to use 3390-9's instead of > 3390-3's for paging. I know that z/VM doesn't use PAV or HyperPAV for > paging, and that more devices means more concurrent I/O's. Has anyone > actually tried changing from 3390-3's to one-third as many 3390-9's? If you > have, was there a measurable difference in performance? > >Dennis > > "I always remind people from outside our state that there's plenty of room > for all Alaska's animals -- right next to the mashed potatoes." -- Sarah > Palin > -- Kris Buelens, IBM Belgium, VM customer support
Re: 3390-9's for paging
We went from -3s to -9s, but not to 1/3 as many. We converted because we (a) ran out of page space, and (b) needed to fit within the limits for the CP_Owned list. We actually went to more -9s than the number of -3s that we were using. Since then, we have not had as great a load on the system as we did when we ran out of space, so comparing current performance to that max load would not be meaningful. And it will get even less meaningful when we migrate to a z10 next year. That said, we have had no paging bottleneck and we have not filled our page space since the conversion, so the performance must be better :-) That is anecdotal rather than being based on measurements, so neither Barton nor Bit would be interested. Come to think of it, I am not very interested, either. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L > Sent: Tuesday, December 01, 2009 12:32 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: 3390-9's for paging > > Our storage architect is trying to get us to use 3390-9's > instead of 3390-3's for paging. I know that z/VM doesn't use > PAV or HyperPAV for paging, and that more devices means more > concurrent I/O's. Has anyone actually tried changing from > 3390-3's to one-third as many 3390-9's? If you have, was > there a measurable difference in performance? > > Dennis > > "I always remind people from outside our state that there's > plenty of room for all Alaska's animals -- right next to the > mashed potatoes." -- Sarah Palin >
3390-9's for paging
Our storage architect is trying to get us to use 3390-9's instead of 3390-3's for paging. I know that z/VM doesn't use PAV or HyperPAV for paging, and that more devices means more concurrent I/O's. Has anyone actually tried changing from 3390-3's to one-third as many 3390-9's? If you have, was there a measurable difference in performance? Dennis "I always remind people from outside our state that there's plenty of room for all Alaska's animals -- right next to the mashed potatoes." -- Sarah Palin
Re: Dynamically removing paging volumes
I have successfully "drained" a page volume in the past, but as stated earlier it can take a long time to complete. Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: scott.wandschnei...@infocrossing.com **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Bill Holder Sent: Wednesday, March 04, 2009 10:26 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Dynamically removing paging volumes On Tue, 3 Mar 2009 19:39:12 +0100, Kris Buelens = wrote: >Since z/VM V5, the CP nucleus itself no longer has pageable parts. > While it's true that CP no longer pages out any parts of the nucleus itself, there are CP owned pageable structures that may be paged out on the target volume. The bulk of these are pageable PGMBKs (normal user private space PGMBKs, containing the page tables that represent user storage), but there are some other pageable structures that are not tied to users, so even if all users were logged off, there's no guarantee that paging use on the drained volume would drop to zero. = - Bill Holder, z/VM Development, IBM Endicott Confidentiality Note: This e-mail, including any attachment to it, may contain material that is confidential, proprietary, privileged and/or "Protected Health Information," within the meaning of the regulations under the Health Insurance Portability & Accountability Act as amended. If it is not clear that you are the intended recipient, you are hereby notified that you have received this transmittal in error, and any review, dissemination, distribution or copying of this e-mail, including any attachment to it, is strictly prohibited. If you have received this e-mail in error, please immediately return it to the sender and delete it from your system. Thank you.
Re: Dynamically removing paging volumes
On Tue, 3 Mar 2009 19:39:12 +0100, Kris Buelens wrote: >Since z/VM V5, the CP nucleus itself no longer has pageable parts. > While it's true that CP no longer pages out any parts of the nucleus itself, there are CP owned pageable structures that may be paged out on the target volume. The bulk of these are pageable PGMBKs (normal user private space PGMBKs, containing the page tables that represent user storage), but there are some other pageable structures that are not tied to users, so even if all users were logged off, there's no guarantee that paging use on the drained volume would drop to zero. - Bill Holder, z/VM Development, IBM Endicott
Re: Dynamically removing paging volumes
Since z/VM V5, the CP nucleus itself no longer has pageable parts. 2009/3/3 Romanowski, John (OFT) > even if you logoff every userid that had some pages on rdev, CP itself may > have paged part of itself to rdev and so rdev never fully drains empty. As > long as you have sufficient other paging areas online, it won't hurt to try. > > > -Original Message- > > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > > Behalf Of Tyler Koyl > > Sent: Tuesday, March 03, 2009 11:50 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Dynamically removing paging volumes > > > > Lots of info on dynamically adding paging volumes but not much of > > dynamically > > removing paging volumes (Possible?). Before I try this I thought I > > would get > > some expert opinions. The way I figure it from reading some manuals it > > could go > > as follows: > > > > CP DRAIN rdev PAGE > > ...wait for drain to complete. > > CP DETACH rdev SYSTEM > > CP DEFINE CPOWNED slot RESERVE > > > > On the right track? Is this going to cause crazy system work and a > > phone call > > from my linux guest clients asking what have I done? > > > > Thanks, > > > > Tyler Koyl > > Viterra Inc. > > > > > > > > > > > > > > > > > > > > This e-mail and any attachment(s) are confidential and may be > > privileged. > > If you are not the intended recipient please notify me immediately by > > return > > e-mail, > > delete this e-mail and do not copy, use or disclose it. > > > This e-mail, including any attachments, may be confidential, privileged or > otherwise legally protected. It is intended only for the addressee. If you > received this e-mail in error or from someone who was not authorized to send > it to you, do not disseminate, copy or otherwise use this e-mail or its > attachments. Please notify the sender immediately by reply e-mail and > delete the e-mail from your system. > -- Kris Buelens, IBM Belgium, VM customer support
Re: Dynamically removing paging volumes
That is the right track. You could change the volser of the pack if you desire at any time. Note: the "...wait for drain to complete." Could take as long as the next IPL. You may update the System Configuration file when you do the DEFINE CPOWNED slot. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tyler Koyl Sent: Tuesday, March 03, 2009 9:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Dynamically removing paging volumes Lots of info on dynamically adding paging volumes but not much of dynamically removing paging volumes (Possible?). Before I try this I thought I would get some expert opinions. The way I figure it from reading some manuals it could go as follows: CP DRAIN rdev PAGE ...wait for drain to complete. CP DETACH rdev SYSTEM CP DEFINE CPOWNED slot RESERVE On the right track? Is this going to cause crazy system work and a phone call from my linux guest clients asking what have I done? Thanks, Tyler Koyl Viterra Inc. This e-mail and any attachment(s) are confidential and may be privileged. If you are not the intended recipient please notify me immediately by return e-mail, delete this e-mail and do not copy, use or disclose it.
Re: Dynamically removing paging volumes
Thanks!. I will simply adjust the system config and wait patiently for the next service window. Tyler "Schuh, Richard" Sent by: The IBMTo z/VM Operating IBMVM@LISTSERV.UARK.EDU System cc Subject Re: Dynamically removing paging volumes 03/03/2009 11:09 AM Please respond to The IBM z/VM Operating System Do not forget to update the CP_Owned list in SYSTEM CONFIG. That said, it is highly unlikely that the device will actually drain during operation. You could simply update SYSTEM CONFIG and wait until the next IPL or schedule one. That will accomplish the removal of the volume without all of the other hassle. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Tyler Koyl > Sent: Tuesday, March 03, 2009 8:50 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Dynamically removing paging volumes > > Lots of info on dynamically adding paging volumes but not > much of dynamically removing paging volumes (Possible?). > Before I try this I thought I would get some expert opinions. > The way I figure it from reading some manuals it could go as follows: > > CP DRAIN rdev PAGE > ...wait for drain to complete. > CP DETACH rdev SYSTEM > CP DEFINE CPOWNED slot RESERVE > > On the right track? Is this going to cause crazy system work > and a phone call from my linux guest clients asking what have I done? > > Thanks, > > Tyler Koyl > Viterra Inc. > > > > > > > > > > This e-mail and any attachment(s) are confidential and may be > privileged. > If you are not the intended recipient please notify me > immediately by return e-mail, delete this e-mail and do not > copy, use or disclose it. > This e-mail and any attachment(s) are confidential and may be privileged. If you are not the intended recipient please notify me immediately by return e-mail, delete this e-mail and do not copy, use or disclose it.
Re: Dynamically removing paging volumes
even if you logoff every userid that had some pages on rdev, CP itself may have paged part of itself to rdev and so rdev never fully drains empty. As long as you have sufficient other paging areas online, it won't hurt to try. > -Original Message- > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On > Behalf Of Tyler Koyl > Sent: Tuesday, March 03, 2009 11:50 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Dynamically removing paging volumes > > Lots of info on dynamically adding paging volumes but not much of > dynamically > removing paging volumes (Possible?). Before I try this I thought I > would get > some expert opinions. The way I figure it from reading some manuals it > could go > as follows: > > CP DRAIN rdev PAGE > ...wait for drain to complete. > CP DETACH rdev SYSTEM > CP DEFINE CPOWNED slot RESERVE > > On the right track? Is this going to cause crazy system work and a > phone call > from my linux guest clients asking what have I done? > > Thanks, > > Tyler Koyl > Viterra Inc. > > > > > > > > > > This e-mail and any attachment(s) are confidential and may be > privileged. > If you are not the intended recipient please notify me immediately by > return > e-mail, > delete this e-mail and do not copy, use or disclose it. This e-mail, including any attachments, may be confidential, privileged or otherwise legally protected. It is intended only for the addressee. If you received this e-mail in error or from someone who was not authorized to send it to you, do not disseminate, copy or otherwise use this e-mail or its attachments. Please notify the sender immediately by reply e-mail and delete the e-mail from your system.
Re: Dynamically removing paging volumes
Do not forget to update the CP_Owned list in SYSTEM CONFIG. That said, it is highly unlikely that the device will actually drain during operation. You could simply update SYSTEM CONFIG and wait until the next IPL or schedule one. That will accomplish the removal of the volume without all of the other hassle. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:ib...@listserv.uark.edu] On Behalf Of Tyler Koyl > Sent: Tuesday, March 03, 2009 8:50 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Dynamically removing paging volumes > > Lots of info on dynamically adding paging volumes but not > much of dynamically removing paging volumes (Possible?). > Before I try this I thought I would get some expert opinions. > The way I figure it from reading some manuals it could go as follows: > > CP DRAIN rdev PAGE > ...wait for drain to complete. > CP DETACH rdev SYSTEM > CP DEFINE CPOWNED slot RESERVE > > On the right track? Is this going to cause crazy system work > and a phone call from my linux guest clients asking what have I done? > > Thanks, > > Tyler Koyl > Viterra Inc. > > > > > > > > > > This e-mail and any attachment(s) are confidential and may be > privileged. > If you are not the intended recipient please notify me > immediately by return e-mail, delete this e-mail and do not > copy, use or disclose it. >
Dynamically removing paging volumes
Lots of info on dynamically adding paging volumes but not much of dynamically removing paging volumes (Possible?). Before I try this I thought I would get some expert opinions. The way I figure it from reading some manuals it could go as follows: CP DRAIN rdev PAGE ...wait for drain to complete. CP DETACH rdev SYSTEM CP DEFINE CPOWNED slot RESERVE On the right track? Is this going to cause crazy system work and a phone call from my linux guest clients asking what have I done? Thanks, Tyler Koyl Viterra Inc. This e-mail and any attachment(s) are confidential and may be privileged. If you are not the intended recipient please notify me immediately by return e-mail, delete this e-mail and do not copy, use or disclose it.
Re: Paging
On Wed, 11 Feb 2009 14:07:18 -0500, Martin, Terry R. (CMS/CTR) (CTR) wrote: ... >Does this sound like a logical explanation? ... Yes, I think that's the explanation. Unless the previous format of the remaining cylinders just coincidentally happened to be compatible, it's n ot likely that any pages got written out successfully to those volumes. The one exception might be that one volume that Dave Jones noticed had cylind er 0 allocated as page - if that was formatted the same way, the system might've successfully paged out up to 180 pages to it (one cylinder's worth). I'm actually somewhat surprised you didn't run into one of the other problems I mentioned (FRF002, PGT004, SXP004) with that much unformatted paging space. - Bill Holder, z/VM Development, IBM Endicott
Re: Paging
On 2/11/09 2:07 PM, "Martin, Terry R. (CMS/CTR) (CTR)" wrote: Hi Thanks to all for your thoughtful input. I think I see the issue now and it does appear to be a formatting problem. When I formatted the pack using CPFMTXA I did the following: When I was prompted to do the following I replied 0 0: I believe it should have been 0 END. Ding ding ding! Yep, that's EXACTLY it.
Re: Paging
Hi
Thanks to all for your thoughtful input.
I think I see the issue now and it does appear to be a formatting
problem. When I formatted the pack using CPFMTXA I did the following:
When I was prompted to do the following I replied 0 0: I believe it
should have been 0 END. I noticed when I did 0 0 I did not see each
cylinder being formatted but when I tested it out on another pack using
0 END I saw that it was actually going through and formatting of the
cylinders. I am actually surprised that it was able to write any pages
out to these volumes.
Does this sound like a logical explanation?
ENTER THE CYLINDER RANGE TO BE FORMATTED ON DISK 5058 OR QUIT:
0 0
I then did the following:
ENTER ALLOCATION DATA
TYPE CYLINDERS
.
perm 0 0
HCPCCF0380E INVALID CYLINDER TYPE - ''
REENTER: TYPE AND CYLINDERS OR 'END'
page 1 end
CONSOLE
ICK031E DEFINE OUTPUT DEVICE: FN FT FM, "CONSOLE", OR "PRINTER"
CONSOLE
ICKDSF - CMS/XA/ESA DEVICE SUPPORT FACILITIES 17.0TIME:
11:17:12
02/11/09 PAGE 1
ENTER INPUT COMMAND:
CPVOL ALLOC MODE(ESA) UNIT(5058) VFY(PP5058) -
ENTER INPUT COMMAND:
TYPE((PERM,0,0) -
ENTER INPUT COMMAND:
(PAGE,1,10016))
ICK00700I DEVICE INFORMATION FOR 5058 IS CURRENTLY AS FOLLOWS:
PHYSICAL DEVICE = 3390
STORAGE CONTROLLER = 3990
STORAGE CONTROL DESCRIPTOR = E9
DEVICE DESCRIPTOR = 0C
ADDITIONAL DEVICE INFORMATION = 48001F3C
TRKS/CYL = 15, # PRIMARY CYLS = 10017
ICK04000I DEVICE IS IN SIMPLEX STATE
ICK00091I 5058 NED=002107.900.IBM.75.000R5471
ICK091I 5058 NED=002107.900.IBM.75.000R5471
ICK03020I CPVOL WILL PROCESS 5058 FOR VM/ESA MODE
ICK03090I VOLUME SERIAL = PP5058
ICK03024I DEVICE IS CURRENTLY FORMATTED WITHOUT FILLER RECORDS
ICK003D REPLY U TO ALTER VOLUME 5058 CONTENTS, ELSE T
U
ICK03000I CPVOL REPORT FOR 5058 FOLLOWS:
CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
TYPE START ENDTOTAL
- ----
PERM 0 0 1
PAGE 1 10016 10016
ICK1I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
11:17:5602/11/09
ENTER INPUT COMMAND:
END
ICK2I ICKDSF PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS & z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
terry.mar...@cms.hhs.gov
-Original Message-
From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On
Behalf Of Bill Holder
Sent: Wednesday, February 11, 2009 1:18 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Paging
Just a few general comments:
Paging space becoming full and paging errors are two different problems
t
hat
manifest differently (though the latter can certainly contribute to the
former). Inadequate paging space will not lead to paging errors being
reported.
If paging space becomes full, paging will overflow to spool space, and
messages 401 (90% full) and 400 (100% full) will have been issued for
pag
ing
space. If spool space also becomes full, those messages will also be
iss
ued
for spool space, and a PGT004 hard abend will likely result.
If paging errors occur, there should be EREP messages. Message 0415
("Si
x
continuous paging errors...") will only be issued if 6 paging IO
requests
in
a row to a single volume all result in failures. This is really not
like
ly
to be a hardware problem with modern highly cached virtual storage DASD
systems like Shark and such. These errors almost always occur on write
requests, as one slot is found to be "bad" (unusable), and the algorithm
bumps to the next available s
Re: Paging
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 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of O'Brien, Dennis L Sent: Wednesday, February 11, 2009 12:28 PM To: IBMVM@LISTSERV.UARK.EDU 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 DrainVolidVP51A0 PAGE DrainVolidVP51A1 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:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Tuesday, February 10, 2009 20:33 To: IBMVM@LISTSERV.UARK.EDU 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)" [terry.mar...@cms.hhs.gov] Sent: 02/10/2009 10:53 PM EST To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: IBMVM@LISTSERV.UARK.EDU 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 AUTOL
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 DrainVolidVP51A0 PAGE DrainVolidVP51A1 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:ib...@listserv.uark.edu] On Behalf Of Mike Walter Sent: Tuesday, February 10, 2009 20:33 To: IBMVM@LISTSERV.UARK.EDU 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)" [terry.mar...@cms.hhs.gov] Sent: 02/10/2009 10:53 PM EST To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: IBMVM@LISTSERV.UARK.EDU 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)" wrote: Hi Yes, I formatted them using CPFMTXA. The output from the format showed that 0 0 PERM and 1 END PAGE.
Re: Paging
On Wed, Feb 11, 2009 at 7:56 PM, Bill Holder wrote: > My statements were (are) generally not based on assumptions, but rather on > how the code actually works. I don't need measurements to explain how the Most certainly Bill. I was catching up with the thread and incorrectly put my comments on your post cutting away the wrong section. I was aiming at the unfounded assumptions about CMM and CMMA in this area. I do realize your comments are based on knowing the code, which should be enough (apart from some surprises when we learn what Linux does). My apologies if I spoiled your afternoon. I owe you a very adult beverage next time we meet. -Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Paging
On Wed, 11 Feb 2009 19:02:14 +0100, Rob van der Heij wrote: ...(deleted for brevity)... It's certainly a fair point that a complete picture is formed only with b oth actual measurements of "real world" representative workloads as well as t he more theoretical knowledge of how the code actually works internally. As the development team leader and design owner of the portion of CP involve d, I was speaking primarily from the latter perspective, I hope that was generally understood. I believe that what I stated was correct, however: although CP certainly does not "hold on" to old paging slots as tenacious ly as some folks believe, Linux is by no means obligated to inform CP every time it discards or remaps page contents, which limits CP's ability to fr ee the old paging slots. There's a lot of "it depends" in there, between th e code algorithms and the observed behaviors. My statements were (are) generally not based on assumptions, but rather o n how the code actually works. I don't need measurements to explain how th e code works. Of course, for any real world workload, how the design manifests in terms of externally visible behaviors is definitely the sort of "your mileage may vary" case where the measuring approach of course has immense value. - Bill Holder, z/VM Development, IBM Endicott
Re: Paging
> In my experience, such paging errors are overwhelmingly caused by lack of > (or improper) formatting, with minidisk overlays being a distant second, and > actual disk hardware problems a very far distant third. > > - Bill Holder, z/VM Development, IBM Endicott ICKDSF EXAMINE will show exactly which cylinders aren't properly formatted, if that's indeed the problem. As suggested previously, the volume should be DRAINed and then the unformatted cylinders detected by EXAMINE can be (very carefully!) formatted using the appropriate CPVOL FORMAT RANGE(x,y) commands without taking down your system. Or, for the faint of heart, flag the offending volume DRAINed in SYSTEM CONFIG, re-IPL, format it, and turn it back on. I also make a point to copy ICKSADSF MODULE to my CF1 disk so it's available for this and other purposes in a stand-alone environment. Mark Wheeler 3M Company
Re: Paging
On Wed, Feb 11, 2009 at 6:11 PM, Bill Holder wrote: > That's not necessarily true. When a Linux task completes, Linux does not > necessarily inform CP that the link between Linux virtual and Linux real is > broken and that any saved contents of the Linux real page can be discarded. Yes, I believe it is rather risky to make such statements only based on reading the glossies and filling in the blanks. It works better to do measurements to confirm the assumptions. For the average Linux server, most of the virtual machine is "LRU managed memory" (either page cache, JVM heap, DB buffers, SGA, etc). Once you start paging in z/VM, then *all* that memory will ultimately land on z/VM paging space. This is why we say that typically for each GB of Linux virtual memory and in-use swap VDISK, you must add 2 GB of z/VM paging space. Only exception is when you don't page ever in z/VM (only very few shops can afford that). And in some cases it can even be worse. Because the paging cleanup in z/VM is not immediate, it may take a while before the slot is freed. We've even seen a virtual machine take twice as much pages on DASD than it has paged out... > Even with CMM or CMMA enabled, Linux is not obligated to inform CP of every > page transition, and even when it does, CP may not "notice" a page is in a > state where old contents (backed on CP paging DASD) can be discarded before > Linux reuses it for some new mapping. As I stated above, you need measurements to confirm assumptions before you share them. Since there is no instrumentation for CMMA, I am reluctant to comment :-) But when my guess is as good as yours, I think it is very likely that for Linux "LRU managed memory" CP would not have a clue when the page went through a cycle of in-use, free, in-use. So CP will continue to hold onto the previously paged out content (until we page it out again). Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Paging
Just a few general comments:
Paging space becoming full and paging errors are two different problems t
hat
manifest differently (though the latter can certainly contribute to the
former). Inadequate paging space will not lead to paging errors being
reported.
If paging space becomes full, paging will overflow to spool space, and
messages 401 (90% full) and 400 (100% full) will have been issued for pag
ing
space. If spool space also becomes full, those messages will also be iss
ued
for spool space, and a PGT004 hard abend will likely result.
If paging errors occur, there should be EREP messages. Message 0415 ("Si
x
continuous paging errors...") will only be issued if 6 paging IO requests
in
a row to a single volume all result in failures. This is really not like
ly
to be a hardware problem with modern highly cached virtual storage DASD
systems like Shark and such. These errors almost always occur on write
requests, as one slot is found to be "bad" (unusable), and the algorithm
bumps to the next available slot and tries it in turn. As others have
mentioned, it's almost always because a contiguous region of paging space
was either never formatted completely, or have since been overlaid by
something else (such as a minidisk). If a large enough area of paging sp
ace
is not correctly formatted, this can result in a PGT004 or FRF002 (or les
s
likely, SXP004) hard abend outage as CP finds no usable paging space to
write to, and storage starts filling up with queued 0415 and EREP message
s.
In my experience, such paging errors are overwhelmingly caused by lack of
(or improper) formatting, with minidisk overlays being a distant second,
and
actual disk hardware problems a very far distant third.
- Bill Holder, z/VM Development, IBM Endicott
Re: Paging
On Tue, 10 Feb 2009 15:25:58 -0600, Dave Jones wrote: >Hi, Terry. > >Martin, Terry R. (CMS/CTR) (CTR) wrote: >> Hi >> >[snp] >> >> >> q alloc page >> EXTENT EXTENT TOTAL PAGES HIGH% >> VOLID RDEV STARTEND 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% >> -- -- >> SUMMARY4694K 2049K 43% >> USABLE 4694K 2049K 43% >> >You have noticed, I hope, that for volume VP5109, the paging area starts on cylinder 0, >and not cylinder 1? Generally, I prefer to leave cylinder 0 for CP's exclusive use. > > >-- >DJ > >V/Soft > z/VM and mainframe Linux expertise, training, > consulting, and software development >www.vsoft-software.com > = Having cylinder 0 allocated for paging space is not a problem (as long as it's properly formatted). The only reason we recommend not to do it is t o avoid any confusion for the one instance where cylinder 0 would be a prob lem (and that is tdisk). Having cylinder 0 allocated for paging is not contributing to any of the observed symptoms (if it was properly formatte d first). - Bill Holder, z/VM Development, IBM Endicott
Re: Paging
On Tue, 10 Feb 2009 13:21:35 -0600, Marcy Cortes wrote: > >We've seen this messages on a new system that we build that didn't have >enough page space (yet). >You probably need some more paging volumes - add up the sum of all the >virtual machines and multiple by 2 and add *at least* that much space, >more if you are using vdisk for swap.Try to keep the % full to less >than 40. (that rule of thumb may vary depending on who you ask). > >Issue Q SRM and let us know what you have for those settings. > >Marcy I believe the current "rule of thumb" recommendation is to add up all of the sizes of the virtual machines which will be logged on at once, then add i n all the sizes of all of the vdisks which will be defined by logged on use rs, double that, and paging DASD space should be at least that large. The po int is not only to ensure there's enough paging space to hold the entire workload, but to also leave enough "breathing room" in terms of contiguou s available sets of paging slots (think entire tracks or more) to allow the block paging algorithms to work effeciently. - Bill Holder, z/VM Development, IBM Endicott
Re: Paging
Some responses point by point, inline:
On Tue, 10 Feb 2009 16:15:35 +0100, Kris Buelens
wrote:
>As for the selection of "good old data" to be thrown out by CP:
>- Linux can tell CP that it no longer needs certain storage pages
>using a diagnose code. If it does ???
This would be Diagnose 10, the "release" function, as used by CMM (aka
CMM1), and other so-called "balooning" mods/drivers. If Linux releases a
range of pages using Diagnose 10, the paging space backing slots are free
.
>- CRM 2 is a Linux/CP co-operative feature by which CP would know what
>kind of data resides in which Linux pages. For example: if CP knows a
>page is used to cache disk data, it doesn't need to page it out, Linux
>can read it back in from its disks.
This would be CMMA, aka CMM2. When Linux puts a page in any non-stable
state, CP has the "opportunity" to see that state and revert the page to
the
"logically zeros" state, which would trigger an asynchronous discard of a
ny
paging slot holding the old contents. Of course, CP would have to happen
to
"look" at the page in just the right window to make that transition (and
depending on which non-stable state Linux is using, CP might have to hono
r
the Linux change ("dirty") bit and preserve the contents and revert the p
age
to stable state).
>- Apart from that, CP's selection of candidates to page out from
>central storage is not as clever is in z/OS: it only uses the last
>reference bit. That is why a z/VM installation would be configured
>with some amount of expanded storage, because there is a timestamp for
>each expanded storage page that allows CP to select old pages for
>pageout.
>
>--
>Kris Buelens,
>IBM Belgium, VM customer support
Not exactly true - CP's page selection criteria does not rely simply on t
he
most recent reference state. Our reference pattern management scheme is
actually quite a bit more sophisticated than the ones previously and
currently used by z/OS in that we maintain a user local approximate LRU
ordering of user pages based on user reference patterns over time, via th
e
User Frame Owned list of FRMTEs chained out of the VMDBK, and the Reorder
process. It's the ordering of the page frames represented on this list,
as
much as it is the most recent reference state (all compared to other fact
ors
such as demand, working set, RESERVED settings, locked pages, etc.), that
drive page selection criteria (and actually, in recent releases, we have
reference bit management that is actually several generations of referenc
e
bit history "deep" - for example, "referenced now AND referenced previous
ly"
have priority over either "referenced now but not referenced previously"
and
"not referenced now but referenced previously" pages).
More than anyone ever wanted to know, I'm sure. ;-)
- Bill Holder, z/VM Development, IBM Endicott
Re: Paging
On Tue, 10 Feb 2009 09:46:12 -0600, Brian Nielsen wrote: >To answer your question #2: Once a guest has a slot on a CP paging devic e >it will be there essentially for the life of the guest, barring somethin g >like a DEF STOR. It doesn't look like the CMMA stuff extends to freeing >paging slots when a guest discards pages. > >Brian Nielsen > This isn't typically true, either. If a page on DASD is brought back in to storage (either because it was referenced by the guest, or part of a pagi ng block where any page in the block was referenced by the guest), the old paging slot from which the page was read will typically be released (free d). The only cases where the old slot would be retained is if the page was never brought in again, or where it was brought in as a non-faulted page as part of a paging block, and then never again referenced or changed (relatively unlikely). CMMA action causing a page to revert to the logically zeros state would also typically release any paging slot associated with the old page contents. There will typically be some numb er of pages, however, that are referenced only at guest startup or perhaps a t very infrequent guest state transitions, and such pages will tend to rema in "in place" on paging space for long periods of time. - Bill Holder, z/VM Development, IBM Endicott
Re: Paging
On Tue, 10 Feb 2009 09:04:51 -0500, Martin, Terry R. (CMS/CTR) (CTR) wrote: ... > 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. > ... That's not necessarily true. When a Linux task completes, Linux does not necessarily inform CP that the link between Linux virtual and Linux real is broken and that any saved contents of the Linux real page can be discarde d. Even with CMM or CMMA enabled, Linux is not obligated to inform CP of ev ery page transition, and even when it does, CP may not "notice" a page is in a state where old contents (backed on CP paging DASD) can be discarded befo re Linux reuses it for some new mapping.
Re: Paging
Hi Marcy, Thanks. On this particular LPAR I have 71GB of real memory. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Tuesday, February 10, 2009 11:36 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging 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:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 7:53 PM To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: IBMVM@LISTSERV.UARK.EDU 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)" 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 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 2:56 PM To: IBMVM@LISTSERV.UARK.EDU 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
Paging
Were there any EREP messages? Any report of where the "bad" spot on DASD might be? It could be instructive to examine the track in question, if it can be identified. Richard Corak
Re: Paging
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:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 7:53 PM To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: IBMVM@LISTSERV.UARK.EDU 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)" 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 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 2:56 PM To: IBMVM@LISTSERV.UARK.EDU 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 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.
Re: 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 - Original Message - From: "Martin, Terry R. (CMS/CTR) (CTR)" [terry.mar...@cms.hhs.gov] Sent: 02/10/2009 10:53 PM EST To: IBMVM@LISTSERV.UARK.EDU 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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: IBMVM@LISTSERV.UARK.EDU 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)" 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 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 2:56 PM To: IBMVM@LISTSERV.UARK.EDU 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 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. Th
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:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 7:04 PM To: IBMVM@LISTSERV.UARK.EDU 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)" 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 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 2:56 PM To: IBMVM@LISTSERV.UARK.EDU 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 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.
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)" 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 > terry.mar...@cms.hhs.gov > > > From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf > Of David Boyes > Sent: Tuesday, February 10, 2009 2:56 PM > To: IBMVM@LISTSERV.UARK.EDU > 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 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. >
Re: Paging
Yes! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Dave Jones Sent: Tuesday, February 10, 2009 4:26 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging Hi, Terry. Martin, Terry R. (CMS/CTR) (CTR) wrote: > Hi > [snp] > > > q alloc page > EXTENT EXTENT TOTAL PAGES HIGH% > VOLID RDEV STARTEND 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% > -- -- > SUMMARY4694K 2049K 43% > USABLE 4694K 2049K 43% > You have noticed, I hope, that for volume VP5109, the paging area starts on cylinder 0, and not cylinder 1? Generally, I prefer to leave cylinder 0 for CP's exclusive use. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Paging
Thanks Marcy. I am in the process of doing that now. I am also going back to see what might have happened to the pack based advice I have received from all of you! Which I thanks everyone for!! Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Tuesday, February 10, 2009 4:38 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging Hello Terry, You may indeed not have formatted all the pages on the new ones or accidentally gotten some stuff on it. Like I said, we didn't think we had made that mistake when we got the HCP415E error (course it wasn't me - so no guarantees there ;). If my math is right, your 8 mod 3's is about 18G. Unless you have more memory than you know what to do with (and you don't because you are paging), you shouldn't be bringing any 40G guests until you add more. You will crash. If not immediately, as soon as they start using all the memory (and linux does use every bit of it). Add them all up, figure out what you really need. Shrink oversized ones too. 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." -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 11:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Paging Hi Marcy, Her is the output from Q SRM: q srm IABIAS : INTENSITY=90%; DURATION=2 LDUBUF : Q1=100% Q2=75% Q3=60% STORBUF: Q1=300% Q2=250% Q3=200% DSPBUF : Q1=32767 Q2=32767 Q3=32767 DISPATCHING MINOR TIMESLICE = 5 MS MAXWSS : LIMIT=% .. : PAGES=99 XSTORE : 0% So the page error on VP51A0 and VP51A1 does not mean that there is actually a real error just that there is not enough PAGE space? I would think it would have had to fill up all the page space including the two I mention before it shows as not having enough page space. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Tuesday, February 10, 2009 2:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging We've seen this messages on a new system that we build that didn't have enough page space (yet). You probably need some more paging volumes - add up the sum of all the virtual machines and multiple by 2 and add *at least* that much space, more if you are using vdisk for swap.Try to keep the % full to less than 40. (that rule of thumb may vary depending on who you ask). Issue Q SRM and let us know what you have for those settings. 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." -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Paging 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 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 STARTEND PAGES IN USE PAGE USED --
Re: Paging
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 terry.mar...@cms.hhs.gov From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of David Boyes Sent: Tuesday, February 10, 2009 2:56 PM To: IBMVM@LISTSERV.UARK.EDU 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 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.
Re: Paging
Hi, Terry. Martin, Terry R. (CMS/CTR) (CTR) wrote: Hi [snp] q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND 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% -- -- SUMMARY4694K 2049K 43% USABLE 4694K 2049K 43% You have noticed, I hope, that for volume VP5109, the paging area starts on cylinder 0, and not cylinder 1? Generally, I prefer to leave cylinder 0 for CP's exclusive use. -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Paging
Hello Terry, You may indeed not have formatted all the pages on the new ones or accidentally gotten some stuff on it. Like I said, we didn't think we had made that mistake when we got the HCP415E error (course it wasn't me - so no guarantees there ;). If my math is right, your 8 mod 3's is about 18G. Unless you have more memory than you know what to do with (and you don't because you are paging), you shouldn't be bringing any 40G guests until you add more. You will crash. If not immediately, as soon as they start using all the memory (and linux does use every bit of it). Add them all up, figure out what you really need. Shrink oversized ones too. 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." -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 11:27 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Paging Hi Marcy, Her is the output from Q SRM: q srm IABIAS : INTENSITY=90%; DURATION=2 LDUBUF : Q1=100% Q2=75% Q3=60% STORBUF: Q1=300% Q2=250% Q3=200% DSPBUF : Q1=32767 Q2=32767 Q3=32767 DISPATCHING MINOR TIMESLICE = 5 MS MAXWSS : LIMIT=% .. : PAGES=99 XSTORE : 0% So the page error on VP51A0 and VP51A1 does not mean that there is actually a real error just that there is not enough PAGE space? I would think it would have had to fill up all the page space including the two I mention before it shows as not having enough page space. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Tuesday, February 10, 2009 2:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging We've seen this messages on a new system that we build that didn't have enough page space (yet). You probably need some more paging volumes - add up the sum of all the virtual machines and multiple by 2 and add *at least* that much space, more if you are using vdisk for swap.Try to keep the % full to less than 40. (that rule of thumb may vary depending on who you ask). Issue Q SRM and let us know what you have for those settings. 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." -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Paging 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 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 STARTEND 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%
Re: Paging
The IBM z/VM Operating System wrote on 02/10/2009 01:38:07 PM: > I would suspect that the entire PAGE extent on the volume was not > formatted before attaching it to the system. > > Brian Nielsen > Run ICKDSF EXAMINE on the suspect volume(s) to confirm. Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- "I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go." Rachel Joy Scott
Re: Paging
Hi Marcy, Her is the output from Q SRM: q srm IABIAS : INTENSITY=90%; DURATION=2 LDUBUF : Q1=100% Q2=75% Q3=60% STORBUF: Q1=300% Q2=250% Q3=200% DSPBUF : Q1=32767 Q2=32767 Q3=32767 DISPATCHING MINOR TIMESLICE = 5 MS MAXWSS : LIMIT=% .. : PAGES=99 XSTORE : 0% So the page error on VP51A0 and VP51A1 does not mean that there is actually a real error just that there is not enough PAGE space? I would think it would have had to fill up all the page space including the two I mention before it shows as not having enough page space. Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Marcy Cortes Sent: Tuesday, February 10, 2009 2:22 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging We've seen this messages on a new system that we build that didn't have enough page space (yet). You probably need some more paging volumes - add up the sum of all the virtual machines and multiple by 2 and add *at least* that much space, more if you are using vdisk for swap.Try to keep the % full to less than 40. (that rule of thumb may vary depending on who you ask). Issue Q SRM and let us know what you have for those settings. 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." -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Paging 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 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 STARTEND 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% -- -- SUMMARY4694K 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 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Tuesday, February 10, 2009 11:45 AM To: IBMVM@LISTSERV.UARK.EDU 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=0013 R
Re: Paging
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. 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 Sent by: "The IBM z/VM Operating System" 02/10/2009 01:38 PM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU 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) 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 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 STARTEND 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% > -- -- >SUMMARY4694K 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 >terry.mar...@cms.hhs.gov > >-Original Message- >From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On >Behalf Of Tom Duerbusch >Sent: Tuesday, February 10, 2009 11:45 AM >To: IBMVM@LISTSERV.UARK.EDU >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=0013 RESVD=00 00 >NPREF=6334 PREF= READS=00167708 WRITES=00143507 >< >XSTORE=16 READS=109416 WRITES=243855 MIGRATES=134423 >CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 >RDR=00 PRT=000469 PCH=00 > >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 ar
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 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.
Re: Paging
If you got paging errors, the first thing I would look at is if you did the proper format/allocate of the page volumes correctly. Q ALLOC shows that you have done the allocate part starting from cylinder 1 to the end of the volume. It also shows that 12% was used, so most of the volume had to be formatted correctly. The easy was of corrupting a paging or spooling volume is to lay a minidisk on top of it. Try the following command: q system 3628 DASD 3628 ATTACHED CPVOL 521PG1 DASD MDISKS NOT FOUND If a mdisk was found, that is most likely your problem. However, this only shows a minidisk that is currently linked. Someone (normally you), could have had a minidisk on this volume, then did the cpfmtxa to format/allocate the volume, then release the minidisk, which will update the minidisk and destroy one or two pages of formatted CP areas. Then map your user direct to see if anyone has a mdisk associated with that volume. It seems like, someone wrote, about a year ago, a rexx exec that will scan the CP areas and look for improperly formatted pages. Perhaps someone's memory will be jogged and the "collective" will point you to the exec. Also, when dealing with LPARs, watch out for another LPAR accessing the volume in write mode. Tom Duerbusch THD Consulting >>> "Martin, Terry R. (CMS/CTR) (CTR)" 2/10/2009 >>> 12:58 PM >>> 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 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 STARTEND 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% -- -- SUMMARY4694K 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 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Tuesday, February 10, 2009 11:45 AM To: IBMVM@LISTSERV.UARK.EDU 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=0013 RESVD= NPREF=6334 PREF= READS=00167708 WRITES=00143507 < XSTORE=16 READS=109416 WRITES=243855 MIGRATES=134423 CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 RDR=00 PRT=000469 PCH=00 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 machin
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) 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 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 STARTEND 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% > -- -- >SUMMARY4694K 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 >terry.mar...@cms.hhs.gov > >-Original Message- >From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On >Behalf Of Tom Duerbusch >Sent: Tuesday, February 10, 2009 11:45 AM >To: IBMVM@LISTSERV.UARK.EDU >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=0013 RESVD=00 00 >NPREF=6334 PREF= READS=00167708 WRITES=00143507 >< >XSTORE=16 READS=109416 WRITES=243855 MIGRATES=134423 >CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 >RDR=00 PRT=000469 PCH=00 > >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)" >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 > >terry.ma...@cms.hhs.gov > > > = ===
Re: Paging
We've seen this messages on a new system that we build that didn't have enough page space (yet). You probably need some more paging volumes - add up the sum of all the virtual machines and multiple by 2 and add *at least* that much space, more if you are using vdisk for swap.Try to keep the % full to less than 40. (that rule of thumb may vary depending on who you ask). Issue Q SRM and let us know what you have for those settings. 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." -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Martin, Terry R. (CMS/CTR) (CTR) Sent: Tuesday, February 10, 2009 10:58 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Paging 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 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 STARTEND 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% -- -- SUMMARY4694K 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 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Tuesday, February 10, 2009 11:45 AM To: IBMVM@LISTSERV.UARK.EDU 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=0013 RESVD= NPREF=6334 PREF= READS=00167708 WRITES=00143507 < XSTORE=16 READS=109416 WRITES=243855 MIGRATES=134423 CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 RDR=00 PRT=000469 PCH=00 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)" 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 m
Re: Paging
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 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 STARTEND 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% -- -- SUMMARY4694K 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 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Tuesday, February 10, 2009 11:45 AM To: IBMVM@LISTSERV.UARK.EDU 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=0013 RESVD= NPREF=6334 PREF= READS=00167708 WRITES=00143507 < XSTORE=16 READS=109416 WRITES=243855 MIGRATES=134423 CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 RDR=00 PRT=000469 PCH=00 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)" 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 terry.ma...@cms.hhs.gov
Re: Paging
SGA 25 and PGA 19 Thank You, Terry Martin Lockheed Martin - Information Technology z/OS & z/VM Systems - Performance and Tuning Cell - 443 632-4191 Work - 410 786-0386 terry.mar...@cms.hhs.gov -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Rich Smrcina Sent: Tuesday, February 10, 2009 9:30 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging A performance monitor will tell you this. But, a 40GB Oracle guest? What is the SGA/PGA size? Martin, Terry R. (CMS/CTR) (CTR) wrote: > 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// > > //terry.ma...@cms.hhs.gov <mailto:terry.ma...@cms.hhs.gov>// > > > -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
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=0013 RESVD= NPREF=6334 PREF= READS=00167708 WRITES=00143507 < XSTORE=16 READS=109416 WRITES=243855 MIGRATES=134423 CPU 00: CTIME=96:56 VTIME=017:43 TTIME=064:50 IO=961712 RDR=00 PRT=000469 PCH=00 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)" 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 terry.ma...@cms.hhs.gov
Re: Paging
Hi, Terry. z/VM is built to do "a lot of paging":-) Are you having a performance problem of some sort that you suspect might be related to paging? Or are the paging rates larger than you feel comfortable with? You did specify any actual numbers, but it's not unusual for a large z/VM system to page at several thousand pages a second. Any good VM performance monitor (Velocity, PerfKit) can tell you which guests are paging and by how much. You'll need one of those if you suspect that you do indeed have a performance problem related to paging. If you are interested in seeing which specific Linux process, running inside a Linux virtual machine, is causing the paging, you're going to have to use some tools that understand how Linux manages it's virtual memory, and that's another issue. CP can make very effective use of expanded storage as a page cache area. You do have some of the memory in the z/VM LPAR defined as expanded storage, right? Kris Buelens wrote: As for the selection of "good old data" to be thrown out by CP: - Linux can tell CP that it no longer needs certain storage pages using a diagnose code. If it does ??? - CRM 2 is a Linux/CP co-operative feature by which CP would know what kind of data resides in which Linux pages. For example: if CP knows a page is used to cache disk data, it doesn't need to page it out, Linux can read it back in from its disks. - Apart from that, CP's selection of candidates to page out from central storage is not as clever is in z/OS: it only uses the last reference bit. That is why a z/VM installation would be configured with some amount of expanded storage, because there is a timestamp for each expanded storage page that allows CP to select old pages for pageout. 2009/2/10 Barton Robinson : In ESALPS, ESAUSPG shows by user. ESAUCD2 shows if you have extra cache or buffer. If you can send your reports, we will analyze it at no charge. Martin, Terry R. (CMS/CTR) (CTR) wrote: 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// //terry.ma...@cms.hhs.gov <mailto:terry.ma...@cms.hhs.gov>// -- DJ V/Soft z/VM and mainframe Linux expertise, training, consulting, and software development www.vsoft-software.com
Re: Paging
As for the selection of "good old data" to be thrown out by CP: - Linux can tell CP that it no longer needs certain storage pages using a diagnose code. If it does ??? - CRM 2 is a Linux/CP co-operative feature by which CP would know what kind of data resides in which Linux pages. For example: if CP knows a page is used to cache disk data, it doesn't need to page it out, Linux can read it back in from its disks. - Apart from that, CP's selection of candidates to page out from central storage is not as clever is in z/OS: it only uses the last reference bit. That is why a z/VM installation would be configured with some amount of expanded storage, because there is a timestamp for each expanded storage page that allows CP to select old pages for pageout. 2009/2/10 Barton Robinson : > In ESALPS, ESAUSPG shows by user. ESAUCD2 shows if you have extra cache or > buffer. If you can send your reports, we will analyze it at no charge. > > Martin, Terry R. (CMS/CTR) (CTR) wrote: >> >> 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// >> >> //terry.ma...@cms.hhs.gov <mailto:terry.ma...@cms.hhs.gov>// >> >> > -- Kris Buelens, IBM Belgium, VM customer support
Re: Paging
To answer your question #2: Once a guest has a slot on a CP paging device it will be there essentially for the life of the guest, barring something like a DEF STOR. It doesn't look like the CMMA stuff extends to freeing paging slots when a guest discards pages. Brian Nielsen On Tue, 10 Feb 2009 09:04:51 -0500, Martin, Terry R. (CMS/CTR) (CTR) wrote: >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 > >terry.ma...@cms.hhs.gov
Re: Paging
In ESALPS, ESAUSPG shows by user. ESAUCD2 shows if you have extra cache or buffer. If you can send your reports, we will analyze it at no charge. Martin, Terry R. (CMS/CTR) (CTR) wrote: 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// //terry.ma...@cms.hhs.gov <mailto:terry.ma...@cms.hhs.gov>//
Re: Paging
A performance monitor will tell you this. But, a 40GB Oracle guest? What is the SGA/PGA size? Martin, Terry R. (CMS/CTR) (CTR) wrote: 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// //terry.ma...@cms.hhs.gov <mailto:terry.ma...@cms.hhs.gov>// -- Rich Smrcina VM Assist, Inc. Phone: 414-491-6001 Ans Service: 360-715-2467 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Paging
Perfkit -- User paging menu can show you who is doing the majority of the paging, who is most active, who owns the most in xstore/dasd. As far as tracking the pages with 'old' data, etc -- I'm not sure of a way to do this. I believe you can end up with a lot of pages that don't go away when using VDISK, for example, so it could be interesting to track it. Scott On Tue, Feb 10, 2009 at 7:04 AM, Martin, Terry R. (CMS/CTR) (CTR) < terry.mar...@cms.hhs.gov> wrote: > 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* > > *terry.ma...@cms.hhs.gov* > > >
Paging
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 terry.ma...@cms.hhs.gov
Re: Paging subsystem
We are on DS8100, so we created a bunch of 3390-1s for paging. Bob. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: Wednesday, December 10, 2008 11:01 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Paging subsystem IF you end up paging heavily, THEN you want many volumes AND you want the volumes on separate RAID arrays as possible. After that...my guess is if you have, say, 4-6 mod-3s per array, it might be time to move to less mod-9s. But if you are really in that much paging, add more memory. On a z10 it is much less expensive. On the other boxes, look at the used market. Of course if you have sufficient disk space to waste, use mod-9s and add more when they are 10-15% full. (Some shops make stupid IMHO rules like everything must be mod-9s, but there are a limited number of addresses in the dasd subsystem, and disk drives can be very large). Tom Duerbusch THD Consulting >>> "Bauer, Bobby (NIH/CIT) [E]" <[EMAIL PROTECTED]> 12/10/2008 10:09 >>> AM >>> I got a great Christmas present! 8G dedicated to our new z/VM and zLinux pilot and new ficon attached DASD (9990V) to replace the escon DASD. The new DASD has both mod3 and mod9. As an old MVS dinosaur I'd create many different paging volumes on smaller disk (mod3) but there is some pressure to use the mod9's. It is a pilot so I have no idea what our load is going to look like. Obviously my mileage may vary but what is in use out there? Any thoughts, good or bad, about a mod9 for paging other than the possibility of contention? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474 This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: Paging subsystem
IF you end up paging heavily, THEN you want many volumes AND you want the volumes on separate RAID arrays as possible. After that...my guess is if you have, say, 4-6 mod-3s per array, it might be time to move to less mod-9s. But if you are really in that much paging, add more memory. On a z10 it is much less expensive. On the other boxes, look at the used market. Of course if you have sufficient disk space to waste, use mod-9s and add more when they are 10-15% full. (Some shops make stupid IMHO rules like everything must be mod-9s, but there are a limited number of addresses in the dasd subsystem, and disk drives can be very large). Tom Duerbusch THD Consulting >>> "Bauer, Bobby (NIH/CIT) [E]" <[EMAIL PROTECTED]> 12/10/2008 10:09 AM >>> I got a great Christmas present! 8G dedicated to our new z/VM and zLinux pilot and new ficon attached DASD (9990V) to replace the escon DASD. The new DASD has both mod3 and mod9. As an old MVS dinosaur I'd create many different paging volumes on smaller disk (mod3) but there is some pressure to use the mod9's. It is a pilot so I have no idea what our load is going to look like. Obviously my mileage may vary but what is in use out there? Any thoughts, good or bad, about a mod9 for paging other than the possibility of contention? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Re: Paging subsystem
VM Paging volumes should be WHOLE thingies, whatever it is on, us the who le thing. I would go for multiple MOD3 volumes with some spares to add later if/whe n you need them. Use MOD9s for real data volumes. /Tom Kern On Wed, 10 Dec 2008 11:09:56 -0500, Bauer, Bobby (NIH/CIT) [E] <[EMAIL PROTECTED]> wrote: >I got a great Christmas present! 8G dedicated to our new z/VM and zLinux pilot and new ficon attached DASD (9990V) to replace the escon DASD. The new DASD has both mod3 and mod9. >As an old MVS dinosaur I'd create many different paging volumes on small er disk (mod3) but there is some pressure to use the mod9's. It is a pilot s o I have no idea what our load is going to look like. Obviously my mileage ma y vary but what is in use out there? Any thoughts, good or bad, about a mod 9 for paging other than the possibility of contention? > >Thanks > >Bobby Bauer >Center for Information Technology >National Institutes of Health >Bethesda, MD 20892-5628 >301-594-7474 > = ===
Re: Paging subsystem
q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- 530PAG 095E 1 3338 600840 0 0 0% -- -- SUMMARY 600840 0 0% USABLE600840 0 0% Ready; T=0.01/0.01 11:14:03 Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Bauer, Bobby (NIH/CIT) [E] Sent: Wednesday, December 10, 2008 11:10 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Paging subsystem I got a great Christmas present! 8G dedicated to our new z/VM and zLinux pilot and new ficon attached DASD (9990V) to replace the escon DASD. The new DASD has both mod3 and mod9. As an old MVS dinosaur I'd create many different paging volumes on smaller disk (mod3) but there is some pressure to use the mod9's. It is a pilot so I have no idea what our load is going to look like. Obviously my mileage may vary but what is in use out there? Any thoughts, good or bad, about a mod9 for paging other than the possibility of contention? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Paging subsystem
I got a great Christmas present! 8G dedicated to our new z/VM and zLinux pilot and new ficon attached DASD (9990V) to replace the escon DASD. The new DASD has both mod3 and mod9. As an old MVS dinosaur I'd create many different paging volumes on smaller disk (mod3) but there is some pressure to use the mod9's. It is a pilot so I have no idea what our load is going to look like. Obviously my mileage may vary but what is in use out there? Any thoughts, good or bad, about a mod9 for paging other than the possibility of contention? Thanks Bobby Bauer Center for Information Technology National Institutes of Health Bethesda, MD 20892-5628 301-594-7474
Re: FW: Risk of Adding a Paging Volume
On Friday, 11/14/2008 at 09:54 EST, "A. Harry Williams" <[EMAIL PROTECTED]> wrote: > Well technically, the VOL1 has a CCHHR to the VTOC. It doesn't have to be > on 0/0. See z/OS DFSMS: Using Data Sets SC27-7410 Appendix A. > > Something worthwhile understanding, and can be displayed easily with DDR. > (Hey, it's gotta be useful for something) You're right, of course. In my attempt to define a CPVOL, I left out the actual standard. I meant that on a CPVOL, the VOL1 label *always* points you to 0/0/5, but that architecturally the VOL1 label can point anywhere. We saw this last week or the week before where someone posted that the VTOC was in the middle of the volume. That can happen only when the volume is formatted with ICKDSF INIT instead of ICKDSF CPVOL (as is done by CPFMTXA). For good reason since, in z/OS, you need to be able to move the VTOC around as it contains entries for the datasets resident thereon. With an unknown number of datasets, the size of the VTOC in unpredictable. With VM there are no datasets and no free space, so the VTOC can remain constant. (Can someone please bring me some water and a clean dust mask? All this digging and excavation is hot and thirsty work...) Alan Altmark z/VM Development IBM Endicott
Re: FW: Risk of Adding a Paging Volume
I started this thread because I wanted to get the List's thought/opinion on the
risk. I felt it was low to none and higher on not doing it. Oh well it is all
behind me now I was "allowed" to do it this weekend and guess what, it took
less than 2 minutes ('cause I can't type) and it was successful. Anyway good
discussions and THANK YOU to all who contributed.
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Schuh, Richard
Sent: Monday, November 17, 2008 10:34 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: FW: Risk of Adding a Paging Volume
True, and it usually is elsewhere on disks formatted for other operating
systems. For a long while, the TPF disks used to have the last tracks on the
disk contain the VTOC. There were F1 DSCBs for each extent containing
like-sized records. I was speaking in terms of a CP format disk. And as
someone, Alan I believe, pointed out, my memory was a bit fuzzy. The allocation
map precedes the VTOC on them.
Regards,
Richard Schuh
>
> Well technically, the VOL1 has a CCHHR to the VTOC. It doesn't have
> to be on 0/0. See z/OS DFSMS: Using Data Sets SC27-7410 Appendix A.
>
Re: FW: Risk of Adding a Paging Volume
True, and it usually is elsewhere on disks formatted for other operating systems. For a long while, the TPF disks used to have the last tracks on the disk contain the VTOC. There were F1 DSCBs for each extent containing like-sized records. I was speaking in terms of a CP format disk. And as someone, Alan I believe, pointed out, my memory was a bit fuzzy. The allocation map precedes the VTOC on them. Regards, Richard Schuh > > Well technically, the VOL1 has a CCHHR to the VTOC. It > doesn't have to be on 0/0. See z/OS DFSMS: Using Data Sets > SC27-7410 Appendix A. >
Re: FW: Risk of Adding a Paging Volume
On Fri, 14 Nov 2008 18:12:45 -0500 Alan Altmark said: >On Friday, 11/14/2008 at 01:07 EST, "Schuh, Richard" <[EMAIL PROTECTED]> >wrote: >> Actually, it is record 3 that contains the volume label. It and records >> 1, and 2 are 80 byte records. > >Technically, the VOL1 label standard permits the label to exceed 80 >characters, up to the record length, but CPVOLs only use 80 bytes. > >> 1 and 2 are the IPL1 and IPL2 records if >> the volume can be IPLed. Records 4 and 5 are the VTOC that is written to >> prevent other systems from corrupting the volume. > >[Notation below is "cylinder/head(track)/record".] > >0/0/4 contains the allocation map. It is able to go there because the >label (0/0/3) points to the record (on 0/0) that contains the VTOC. CPVOLs >(i.e. CPFMTXA) place the VTOC on 0/0/5. Well technically, the VOL1 has a CCHHR to the VTOC. It doesn't have to be on 0/0. See z/OS DFSMS: Using Data Sets SC27-7410 Appendix A. Something worthwhile understanding, and can be displayed easily with DDR. (Hey, it's gotta be useful for something) > >The VTOC contains two extents: >1. The extent of the VTOC itself. This is where it gets clever. The >label says it starts at 0/0/5, but VTOCs are measured in *tracks*, not >*records*. For CPVOLs, the VTOC consumes all of cyl 0, track 0. This >protects all the records on track 0 from the depredations of z/OS >(assuming it was so inclined). > >2. The list of available extents. Being oh so clever again, the list is >empty. > >If anyone wants to read more about VTOCs, and DSCBs, go look at the z/OS >DFSMSdfp Advanced Services book, chapter 1. > >> The system has, for a long time, protected the first records of cylinder >> 0, maybe all of 0/0/0, and used the rest of the cylinder for paging or >> spooling if cylinder 0 is so allocated. > >Note that this protection does not extend to T-disk. If you allocate cyl >0 as TDSK, CP will happily (for the moment) hand real cyl 0 to a guest. So >the rule is "don't do that". We plan to fix it in a future release. > >Alan Altmark >z/VM Development >IBM Endicott
Re: FW: Risk of Adding a Paging Volume
You could call it a documentation error of omission and fix it that way :) It would be (a) easier, and (b) backward compatible. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Alan Altmark > Sent: Friday, November 14, 2008 3:13 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FW: Risk of Adding a Paging Volume > > On Friday, 11/14/2008 at 01:07 EST, "Schuh, Richard" <[EMAIL PROTECTED]> > wrote: > > Actually, it is record 3 that contains the volume label. It and > > records 1, and 2 are 80 byte records. > > Technically, the VOL1 label standard permits the label to > exceed 80 characters, up to the record length, but CPVOLs > only use 80 bytes. > > > 1 and 2 are the IPL1 and IPL2 records if the volume can be IPLed. > > Records 4 and 5 are the VTOC that is written to prevent > other systems > > from corrupting the volume. > > [Notation below is "cylinder/head(track)/record".] > > 0/0/4 contains the allocation map. It is able to go there > because the label (0/0/3) points to the record (on 0/0) that > contains the VTOC. CPVOLs (i.e. CPFMTXA) place the VTOC on 0/0/5. > > The VTOC contains two extents: > 1. The extent of the VTOC itself. This is where it gets > clever. The label says it starts at 0/0/5, but VTOCs are > measured in *tracks*, not *records*. For CPVOLs, the VTOC > consumes all of cyl 0, track 0. This protects all the > records on track 0 from the depredations of z/OS (assuming it > was so inclined). > > 2. The list of available extents. Being oh so clever again, > the list is empty. > > If anyone wants to read more about VTOCs, and DSCBs, go look > at the z/OS DFSMSdfp Advanced Services book, chapter 1. > > > The system has, for a long time, protected the first records of > > cylinder 0, maybe all of 0/0/0, and used the rest of the > cylinder for > > paging or spooling if cylinder 0 is so allocated. > > Note that this protection does not extend to T-disk. If you > allocate cyl 0 as TDSK, CP will happily (for the moment) hand > real cyl 0 to a guest. So the rule is "don't do that". We > plan to fix it in a future release. > > Alan Altmark > z/VM Development > IBM Endicott >
Re: FW: Risk of Adding a Paging Volume
On Friday, 11/14/2008 at 01:07 EST, "Schuh, Richard" <[EMAIL PROTECTED]> wrote: > Actually, it is record 3 that contains the volume label. It and records > 1, and 2 are 80 byte records. Technically, the VOL1 label standard permits the label to exceed 80 characters, up to the record length, but CPVOLs only use 80 bytes. > 1 and 2 are the IPL1 and IPL2 records if > the volume can be IPLed. Records 4 and 5 are the VTOC that is written to > prevent other systems from corrupting the volume. [Notation below is "cylinder/head(track)/record".] 0/0/4 contains the allocation map. It is able to go there because the label (0/0/3) points to the record (on 0/0) that contains the VTOC. CPVOLs (i.e. CPFMTXA) place the VTOC on 0/0/5. The VTOC contains two extents: 1. The extent of the VTOC itself. This is where it gets clever. The label says it starts at 0/0/5, but VTOCs are measured in *tracks*, not *records*. For CPVOLs, the VTOC consumes all of cyl 0, track 0. This protects all the records on track 0 from the depredations of z/OS (assuming it was so inclined). 2. The list of available extents. Being oh so clever again, the list is empty. If anyone wants to read more about VTOCs, and DSCBs, go look at the z/OS DFSMSdfp Advanced Services book, chapter 1. > The system has, for a long time, protected the first records of cylinder > 0, maybe all of 0/0/0, and used the rest of the cylinder for paging or > spooling if cylinder 0 is so allocated. Note that this protection does not extend to T-disk. If you allocate cyl 0 as TDSK, CP will happily (for the moment) hand real cyl 0 to a guest. So the rule is "don't do that". We plan to fix it in a future release. Alan Altmark z/VM Development IBM Endicott
Re: Risk of Adding a Paging Volume
On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > The only I/O Errors that we are seeing are on one of the paging volumes When CP gets a paging I/O error writing to a particular record (99.% of the time because it isn't formatted or some z/OS system writes a VTOC in the middle of the volume), he'll remember it is bad and move on to another record. If he gets 6 in a row, the operator gets a message. If that keeps up, you could get a CP abend because CP is queueing those messages for the operator! An excellent reason to keep your critical volumes (page, spool) away from other systems. z/OS has no need to see a CP paging pack in its I/O config. Only certain errors are recorded by EREP: Channel data checks, channel control checks, interface control checks, and any unit check where the error recovery procedure contained in the SENSE data says "generate an EREP record". A normal I/O error such as is encountered when the disk isn't formatted isn't [likely to be] a hardware problem. Alan Altmark z/VM Development IBM Endicott
Re: FW: Risk of Adding a Paging Volume
Did I say it was? I merely pointed out that there would not have been any error, other than offending your sensibility :), had cylinder 0 been included as specified in the original post. I also called attention to the fact that the similes offered were superstitions, and not real risks or threats. (I would not walk under an occupied ladder, however. That could be dangerous.) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter > Sent: Friday, November 14, 2008 11:18 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FW: Risk of Adding a Paging Volume > > Richard, > > Is one single cylinder really that much real estate any more > in the era of > mod27+ DASD? > Do you believe what Alan Altmark tells us from the holy mount > in Endicott? > > -- > Date: Tue, 8 Jan 2008 13:01:51 -0500 > Reply-To: The IBM z/VM Operating System > Sender: The IBM z/VM Operating System > From: Alan Altmark <[EMAIL PROTECTED]> > Subject: Re: z/VM 5.2 Absurd System shutdown - PJBR > Content-type: text/plain; charset=US-ASCII > > On Tuesday, 01/08/2008 at 11:54 EST, David Boyes > <[EMAIL PROTECTED]> > wrote: > > The cyl 0 vs 1 discussion is just a safety measure; CP is usually > > smart enough not to shoot itself in the head by paging onto > the volume > > label & allocation bitmap that tells it where it paged stuff...8-) > > The paging subsystem will page to cyl 0, but it knows to > avoid the label and tracks that have "other CP administrative > data" on them. In the interest of avoiding problems, > however, don't ALLOCATE cyl 0 as anything other than PERM. > It's just not worth the risk. > > "Cylinder zero is PERM and belongs to CP." I tell you three times. > > Alan Altmark > z/VM Development > IBM Endicott > -- > > Note: THREE (3) times no less! Anyone hear a cock crowing? > > Yes, CP's "special parts" of cylinder zero are currently > "protected" -- even from page and SPOOL activity. But is one > solitary cylinder per pack so important for page per SPOOL > space that you care to risk some future code change (or > erroneous PTF code change) that un-protects the CP > allocation-map, or the dummy (full-pack) VTOC? I just don't > find even that small risk worth the small risk. One cylinder > is inconsequential (unless it's CP's "special areas"!). > > Who knows, maybe with the direction towards 'Live Guest > Migration' (a much better choice than dead guest migration!), > maybe IBM has other plans for cylinder zero? I'll stick with > always allocating cylinder zero as PERM (a simple solution > for my simple mind), and suggesting such as a z/VM "best practice". > > But "go ahead, make my day" ... allocate *your* shop's > cylinder zeroes as page or SPOOL space as you see fit. If > that ever causes a problem (unlikely as it may be), expect to > hear my haunting strains of "I told you so!". ;-) > > Don't make me search for Alan's post again! :-) But just in > case, for future searches, arguments: CPFMTXA FORMAT ALLOC > BITMAP PAGE CYL 0 CYL0 Cylinder 0 best practices > > Mike Walter > Hewitt Associates > Any opinions expressed herein are mine alone and do not > necessarily represent the opinions or policies of Hewitt Associates. > > > > > > "Schuh, Richard" <[EMAIL PROTECTED]> > > Sent by: "The IBM z/VM Operating System" > 11/14/2008 11:39 AM > Please respond to > "The IBM z/VM Operating System" > > > > To > IBMVM@LISTSERV.UARK.EDU > cc > > Subject > Re: FW: Risk of Adding a Paging Volume > > > > > > > Neither one of those ever caused me any harm, either. It > looks like you are relegating Mike's "best practices" > statement to the realm of superstition. > > Regards, > Richard Schuh > > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack > > Sent: Friday, November 14, 2008 8:38 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: FW: Risk of Adding a Paging Volume > > > > For the same reason that you don't walk under a ladder, carrying a > > black cat in the dark of the moon. > > Jim > > > > > > > > > > > The information contained in this e-mail and any accompanying > documents may contain information that i
Re: FW: Risk of Adding a Paging Volume
Richard, Is one single cylinder really that much real estate any more in the era of mod27+ DASD? Do you believe what Alan Altmark tells us from the holy mount in Endicott? -- Date: Tue, 8 Jan 2008 13:01:51 -0500 Reply-To: The IBM z/VM Operating System Sender: The IBM z/VM Operating System From: Alan Altmark <[EMAIL PROTECTED]> Subject: Re: z/VM 5.2 Absurd System shutdown - PJBR Content-type: text/plain; charset=US-ASCII On Tuesday, 01/08/2008 at 11:54 EST, David Boyes <[EMAIL PROTECTED]> wrote: > The cyl 0 vs 1 discussion is just a safety measure; CP is usually smart > enough not to shoot itself in the head by paging onto the volume label & > allocation bitmap that tells it where it paged stuff...8-) The paging subsystem will page to cyl 0, but it knows to avoid the label and tracks that have "other CP administrative data" on them. In the interest of avoiding problems, however, don't ALLOCATE cyl 0 as anything other than PERM. It's just not worth the risk. "Cylinder zero is PERM and belongs to CP." I tell you three times. Alan Altmark z/VM Development IBM Endicott -- Note: THREE (3) times no less! Anyone hear a cock crowing? Yes, CP's "special parts" of cylinder zero are currently "protected" -- even from page and SPOOL activity. But is one solitary cylinder per pack so important for page per SPOOL space that you care to risk some future code change (or erroneous PTF code change) that un-protects the CP allocation-map, or the dummy (full-pack) VTOC? I just don't find even that small risk worth the small risk. One cylinder is inconsequential (unless it's CP's "special areas"!). Who knows, maybe with the direction towards 'Live Guest Migration' (a much better choice than dead guest migration!), maybe IBM has other plans for cylinder zero? I'll stick with always allocating cylinder zero as PERM (a simple solution for my simple mind), and suggesting such as a z/VM "best practice". But "go ahead, make my day" ... allocate *your* shop's cylinder zeroes as page or SPOOL space as you see fit. If that ever causes a problem (unlikely as it may be), expect to hear my haunting strains of "I told you so!". ;-) Don't make me search for Alan's post again! :-) But just in case, for future searches, arguments: CPFMTXA FORMAT ALLOC BITMAP PAGE CYL 0 CYL0 Cylinder 0 best practices Mike Walter Hewitt Associates Any opinions expressed herein are mine alone and do not necessarily represent the opinions or policies of Hewitt Associates. "Schuh, Richard" <[EMAIL PROTECTED]> Sent by: "The IBM z/VM Operating System" 11/14/2008 11:39 AM Please respond to "The IBM z/VM Operating System" To IBMVM@LISTSERV.UARK.EDU cc Subject Re: FW: Risk of Adding a Paging Volume Neither one of those ever caused me any harm, either. It looks like you are relegating Mike's "best practices" statement to the realm of superstition. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack > Sent: Friday, November 14, 2008 8:38 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FW: Risk of Adding a Paging Volume > > For the same reason that you don't walk under a ladder, > carrying a black cat in the dark of the moon. > Jim > > 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.
Re: FW: Risk of Adding a Paging Volume
Actually, it is record 3 that contains the volume label. It and records 1, and 2 are 80 byte records. 1 and 2 are the IPL1 and IPL2 records if the volume can be IPLed. Records 4 and 5 are the VTOC that is written to prevent other systems from corrupting the volume. These records are, IIRC, 96 bytes with a 44 byte Key field. If the volume has actual IPL records instead of dummies, the next record is likely to be the one that is read by the IPL channel program. There may be more than one such record. The first record read it the first page of the IPL program. It contains the low memory stuff such as the IPL PSW and addresses of the First Level Interrupt Handlers for the IPL program. The system has, for a long time, protected the first records of cylinder 0, maybe all of 0/0/0, and used the rest of the cylinder for paging or spooling if cylinder 0 is so allocated. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch > Sent: Friday, November 14, 2008 8:58 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FW: Risk of Adding a Paging Volume > > The first 3 pages of cylinder zero of a CP volume, have > specific, non-page, applications. > > Obviously, page 0, contains the volume label. Page 1 and 2 > have the CP Allocation map (the map that shows what each > cylinder can be used for...temp, page, spol, perm, etc). > > It use to be, I don't know if it is the case now, that the > paging subsystem, used all pages of the cylinder marked as > PAGE. If it used page 0 or 1, there went your volume header > and page allocation map. No big deal as these are stored in > memory on a running system. But once you IPL, and CP tried > to read these pages. > > Back in the 2314 days, we sweated every cylinder. Now, we > only sweat on a pack basis. > > Just lay off cylinder 0 on any volume that isn't just > attached to a guest. > > Tom Duerbusch > THD Consulting > > >>> Edward M Martin <[EMAIL PROTECTED]> 11/14/2008 9:56 AM >>> > Hello Everyone, > > Just been following this thread. Could some one > explain why Cylinder 0 should not be defined as page? > > Ed Martin > Aultman Health Foundation > 330-588-4723 > ext 40441 > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter > Sent: Friday, November 14, 2008 9:50 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > No matter. No harm would be done CPFMTZA wouldn't execute anyway. > ;-) > > Besides, cyl 0 as PAGE would not cause a failure, it's just > not "best practices". > > Mike Walter > Hewitt Associates >
Re: FW: Risk of Adding a Paging Volume
Neither one of those ever caused me any harm, either. It looks like you are relegating Mike's "best practices" statement to the realm of superstition. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Jim Bohnsack > Sent: Friday, November 14, 2008 8:38 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: FW: Risk of Adding a Paging Volume > > For the same reason that you don't walk under a ladder, > carrying a black cat in the dark of the moon. > Jim > >
Re: Risk of Adding a Paging Volume
If e-mail had executed, your system would still have run :) Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott > Sent: Friday, November 14, 2008 6:31 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > Correct - it should read "3) ALLOCATE 0-0 PERM and 1-END PAGE." > > Good thing email doesn't execute! > > Scott R Wandschneider > > Senior Systems Programmer|| Infocrossing, a Wipro Company || > 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': > 402.963.8905 || Ë:847.849.7223 || :: > [EMAIL PROTECTED] **Think Green - Please > print responsibly** > > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Friday, November 14, 2008 1:19 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott > <[EMAIL PROTECTED]> wrote: > > The only I/O Errors that we are seeing are on one of the > paging volumes, BDCPG2: > > > I have already done the following in preparation: > >1) ATTach 1D67 to MAINT > >2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. > >3) ALLOCATE 0-0 PAGE and 1-END PAGE. > > I suppose you meant to allocate cylinder 0 as PERM rather > PAGE (only problem there is that people may assume it is > bad). But it looks good in that you format the entire > volume, so makes me wonder about the PG2 volume. Like what > are you going to do with that once it is not being used > anymore by VM ? What can you do to the volume to make I/O > errors go away? What I tried to point out is that real I/O > errors are handled by the DASD subsystem. It could be that > some major hardware problems do result in the device passing > errors to the host, but that would probably impact all > logical volumes on that particular rank. > > I would strongly recommend you take the EREP data to a > hardware CE to look at the sense codes. > > Since you only had two paging volumes, the bad volume was hit > a lot as well. I recall from earlier discussion that even > when CP failed to write the block, it still marks it as > in-use (in the old days to avoid writing again in that same > spot). So it may be that once you have shutdown all guests > that have pages out on disk, there still remains pages allocated. > > Rob >
Re: FW: Risk of Adding a Paging Volume
The first 3 pages of cylinder zero of a CP volume, have specific, non-page, applications. Obviously, page 0, contains the volume label. Page 1 and 2 have the CP Allocation map (the map that shows what each cylinder can be used for...temp, page, spol, perm, etc). It use to be, I don't know if it is the case now, that the paging subsystem, used all pages of the cylinder marked as PAGE. If it used page 0 or 1, there went your volume header and page allocation map. No big deal as these are stored in memory on a running system. But once you IPL, and CP tried to read these pages. Back in the 2314 days, we sweated every cylinder. Now, we only sweat on a pack basis. Just lay off cylinder 0 on any volume that isn't just attached to a guest. Tom Duerbusch THD Consulting >>> Edward M Martin <[EMAIL PROTECTED]> 11/14/2008 9:56 AM >>> Hello Everyone, Just been following this thread. Could some one explain why Cylinder 0 should not be defined as page? Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Friday, November 14, 2008 9:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume No matter. No harm would be done CPFMTZA wouldn't execute anyway. ;-) Besides, cyl 0 as PAGE would not cause a failure, it's just not "best practices". Mike Walter Hewitt Associates
Re: FW: Risk of Adding a Paging Volume
For the same reason that you don't walk under a ladder, carrying a black cat in the dark of the moon. Jim Edward M Martin wrote: Hello Everyone, Just been following this thread. Could some one explain why=20 Cylinder 0 should not be defined as page? Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Friday, November 14, 2008 9:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume No matter. No harm would be done CPFMTZA wouldn't execute anyway. ;-) Besides, cyl 0 as PAGE would not cause a failure, it's just not "best practices". Mike Walter Hewitt Associates -- Jim Bohnsack Cornell University (972) 596-6377 home/office (972) 342-5823 cell [EMAIL PROTECTED]
Re: Risk of Adding a Paging Volume
If it is a problem of incorrect formatting, it may not show up in EREP. That might be considered a software (channel program) error. Look at EREP but do not be surprised if nothing has been reported. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij > Sent: Thursday, November 13, 2008 11:19 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott > <[EMAIL PROTECTED]> wrote: > > The only I/O Errors that we are seeing are on one of the > paging volumes, BDCPG2: > > > I have already done the following in preparation: > >1) ATTach 1D67 to MAINT > >2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. > >3) ALLOCATE 0-0 PAGE and 1-END PAGE. > > I suppose you meant to allocate cylinder 0 as PERM rather > PAGE (only problem there is that people may assume it is > bad). But it looks good in that you format the entire > volume, so makes me wonder about the PG2 volume. Like what > are you going to do with that once it is not being used > anymore by VM ? What can you do to the volume to make I/O > errors go away? What I tried to point out is that real I/O > errors are handled by the DASD subsystem. It could be that > some major hardware problems do result in the device passing > errors to the host, but that would probably impact all > logical volumes on that particular rank. > > I would strongly recommend you take the EREP data to a > hardware CE to look at the sense codes. > > Since you only had two paging volumes, the bad volume was hit > a lot as well. I recall from earlier discussion that even > when CP failed to write the block, it still marks it as > in-use (in the old days to avoid writing again in that same > spot). So it may be that once you have shutdown all guests > that have pages out on disk, there still remains pages allocated. > > Rob >
FW: Risk of Adding a Paging Volume
Hello Everyone, Just been following this thread. Could some one explain why Cylinder 0 should not be defined as page? Ed Martin Aultman Health Foundation 330-588-4723 ext 40441 -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mike Walter Sent: Friday, November 14, 2008 9:50 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume No matter. No harm would be done CPFMTZA wouldn't execute anyway. ;-) Besides, cyl 0 as PAGE would not cause a failure, it's just not "best practices". Mike Walter Hewitt Associates
Re: Risk of Adding a Paging Volume
No matter. No harm would be done CPFMTZA wouldn't execute anyway. ;-) Besides, cyl 0 as PAGE would not cause a failure, it's just not "best practices". Mike Walter Hewitt Associates - Original Message - From: "Wandschneider, Scott" [EMAIL PROTECTED] Sent: 11/14/2008 07:31 AM MST To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Correct - it should read "3) ALLOCATE 0-0 PERM and 1-END PAGE." Good thing email doesn't execute! Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, November 14, 2008 1:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > The only I/O Errors that we are seeing are on one of the paging volumes, > BDCPG2: > I have already done the following in preparation: >1) ATTach 1D67 to MAINT >2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. >3) ALLOCATE 0-0 PAGE and 1-END PAGE. I suppose you meant to allocate cylinder 0 as PERM rather PAGE (only problem there is that people may assume it is bad). But it looks good in that you format the entire volume, so makes me wonder about the PG2 volume. Like what are you going to do with that once it is not being used anymore by VM ? What can you do to the volume to make I/O errors go away? What I tried to point out is that real I/O errors are handled by the DASD subsystem. It could be that some major hardware problems do result in the device passing errors to the host, but that would probably impact all logical volumes on that particular rank. I would strongly recommend you take the EREP data to a hardware CE to look at the sense codes. Since you only had two paging volumes, the bad volume was hit a lot as well. I recall from earlier discussion that even when CP failed to write the block, it still marks it as in-use (in the old days to avoid writing again in that same spot). So it may be that once you have shutdown all guests that have pages out on disk, there still remains pages allocated. Rob 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.
Re: Risk of Adding a Paging Volume
Correct - it should read "3) ALLOCATE 0-0 PERM and 1-END PAGE." Good thing email doesn't execute! Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, November 14, 2008 1:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > The only I/O Errors that we are seeing are on one of the paging volumes, > BDCPG2: > I have already done the following in preparation: >1) ATTach 1D67 to MAINT >2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. >3) ALLOCATE 0-0 PAGE and 1-END PAGE. I suppose you meant to allocate cylinder 0 as PERM rather PAGE (only problem there is that people may assume it is bad). But it looks good in that you format the entire volume, so makes me wonder about the PG2 volume. Like what are you going to do with that once it is not being used anymore by VM ? What can you do to the volume to make I/O errors go away? What I tried to point out is that real I/O errors are handled by the DASD subsystem. It could be that some major hardware problems do result in the device passing errors to the host, but that would probably impact all logical volumes on that particular rank. I would strongly recommend you take the EREP data to a hardware CE to look at the sense codes. Since you only had two paging volumes, the bad volume was hit a lot as well. I recall from earlier discussion that even when CP failed to write the block, it still marks it as in-use (in the old days to avoid writing again in that same spot). So it may be that once you have shutdown all guests that have pages out on disk, there still remains pages allocated. Rob
Re: Risk of Adding a Paging Volume
On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > The only I/O Errors that we are seeing are on one of the paging volumes, > BDCPG2: > I have already done the following in preparation: >1) ATTach 1D67 to MAINT >2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. >3) ALLOCATE 0-0 PAGE and 1-END PAGE. I suppose you meant to allocate cylinder 0 as PERM rather PAGE (only problem there is that people may assume it is bad). But it looks good in that you format the entire volume, so makes me wonder about the PG2 volume. Like what are you going to do with that once it is not being used anymore by VM ? What can you do to the volume to make I/O errors go away? What I tried to point out is that real I/O errors are handled by the DASD subsystem. It could be that some major hardware problems do result in the device passing errors to the host, but that would probably impact all logical volumes on that particular rank. I would strongly recommend you take the EREP data to a hardware CE to look at the sense codes. Since you only had two paging volumes, the bad volume was hit a lot as well. I recall from earlier discussion that even when CP failed to write the block, it still marks it as in-use (in the old days to avoid writing again in that same spot). So it may be that once you have shutdown all guests that have pages out on disk, there still remains pages allocated. Rob
Re: Risk of Adding a Paging Volume
The only I/O Errors that we are seeing are on one of the paging volumes, BDCPG2: q alloc page EXTENT EXTENT TOTAL PAGES HIGH% VOLID RDEV STARTEND PAGES IN USE PAGE USED -- -- -- -- -- -- BDCRES 1D60257390 24120 18848 24120 78% BDCPG1 1D64 1170 2169 18 125162 18 69% BDCPG2 1D65 1 3338 600840 121703 198393 20% <== I/O Errors -- -- SUMMARY 804960 265713 33% USABLE804960 265713 33% Ready; T=0.01/0.01 13:58:34 I have already done the following in preparation: 1) ATTach 1D67 to MAINT 2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. 3) ALLOCATE 0-0 PAGE and 1-END PAGE. Next Steps are: 4) CP Define cpowned slot 07 BDCPG3 <== Next available slot 5) DETach 1D67 from MAINT 6) ATTach 1D67 to system 7) CP Start DASD 1D67 page 8) CP Drain volid bdcpg2 all Modify the SYTEM CONFIG file as: CP_Owned Slot 6 BDCPG2 <== Existing Drain VOLID BDCPG2 ALL <== New CP_OWNED SLOT 7 BDCPG3 <== New Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Thursday, November 13, 2008 3:52 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume On Thu, Nov 13, 2008 at 8:36 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > Thanks Dennis. > > Maybe with all the response I will get approval or not :) One more from the peanut gallery... we don't get "I/O problems" on DASD these days. That used to be in the old days where we still had platters with rust that rotate... ;-) If you really have I/O problems then it would probably affect the entire DASD subsystem, so you have also other things to worry about (maybe someone on MVS using your volumes for something else?) It may also be that the page volume was not correctly formatted and CP complains and makes you *think* there are I/O problems on the device. In that case it may be an incorrect operating procedure and your new volume may be also bad. The page pack needs to be formatted completely with ICKDSF - not just the first cylinder, as some (MVS) storage admin folks are used to. Depending on what was there in the past, it may work for part of the volume. If Q ALLOC shows you only a small number of pages in-use on that volume (about the same as the number of errors you had) then that would be my guess. Rob
Re: Risk of Adding a Paging Volume
On Thu, Nov 13, 2008 at 8:36 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > Thanks Dennis. > > Maybe with all the response I will get approval or not :) One more from the peanut gallery... we don't get "I/O problems" on DASD these days. That used to be in the old days where we still had platters with rust that rotate... ;-) If you really have I/O problems then it would probably affect the entire DASD subsystem, so you have also other things to worry about (maybe someone on MVS using your volumes for something else?) It may also be that the page volume was not correctly formatted and CP complains and makes you *think* there are I/O problems on the device. In that case it may be an incorrect operating procedure and your new volume may be also bad. The page pack needs to be formatted completely with ICKDSF - not just the first cylinder, as some (MVS) storage admin folks are used to. Depending on what was there in the past, it may work for part of the volume. If Q ALLOC shows you only a small number of pages in-use on that volume (about the same as the number of errors you had) then that would be my guess. Rob
Re: Risk of Adding a Paging Volume
Thanks Dennis. Maybe with all the response I will get approval or not :) Thanks everybody! Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of O'Brien, Dennis L Sent: Thursday, November 13, 2008 1:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume Adding a page volume is low risk. Just make sure you format the new volume with CPFMTXA first. Whether you add a new volume or not, you should drain the volume with errors, and make sure it's drained in SYSTEM CONFIG, too. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:09 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Risk of Adding a Paging Volume Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > Sent: Thursday, November 13, 2008 11:02 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > If you have spare volumes, format some as quickly as possible, add > them t= o the system and DRAIN the problem volume, take it out of the > configuration= > > files and after the next IPL, test that volume, reformat that volume, > tes= t it again, etc. > > /Tom Kern > > On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott > <[EMAIL PROTECTED]> wrote: > > > I am receiving I/O Errors on one of my PAGE Volumes. What would be > considered the risk of adding a new PAGE volume (CP Format, > etc.) and draining the problem volume. Management is saying wait > until we can IPL = the system and say it's ok. > > > >What does the list think? > > > > > >Scott R Wandschneider >
Re: Risk of Adding a Paging Volume
Thank you Richard. Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume The only risk is that not draining the problem volume. Any existing page in the problem error could cause a virtual machine or CP abend. The risk of not draining it is increasingly larger as the disk continues to be used. Draining and adding do work. I just added 10 disks to my paging farm. That was all the free slots that I had, or I would have added more. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott > Sent: Thursday, November 13, 2008 11:09 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > Yes, but what would you consider the *risk* of dynamically adding a > volume and setting the problem one to DRAIN? > > > Scott R Wandschneider > > Senior Systems Programmer|| Infocrossing, a Wipro Company || > 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': > 402.963.8905 || Ë:847.849.7223 || :: > [EMAIL PROTECTED] **Think Green - Please print > responsibly** > > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Thursday, November 13, 2008 1:04 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > You need to list it as a draining volume in SYSTEM CONFIG before the > shutdown and IPL. > > Regards, > Richard Schuh > > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > > Sent: Thursday, November 13, 2008 11:02 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: Risk of Adding a Paging Volume > > > > If you have spare volumes, format some as quickly as possible, add > > them t= o the system and DRAIN the problem volume, take it > out of the > > configuration= > > > > files and after the next IPL, test that volume, reformat > that volume, > > tes= t it again, etc. > > > > /Tom Kern > > > > On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott > > <[EMAIL PROTECTED]> wrote: > > > > > I am receiving I/O Errors on one of my PAGE Volumes. > What would be > > considered the risk of adding a new PAGE volume (CP Format, > > etc.) and draining the problem volume. Management is saying wait > > until we can IPL = the system and say it's ok. > > > > > >What does the list think? > > > > > > > > >Scott R Wandschneider > > >
Re: Risk of Adding a Paging Volume
Thanks Peter
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, November 13, 2008 1:28 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Adding additional volume(s) and waiting for the next IPL I would rate as low
risk. Continuing to run as you are, with the volume experiencing errors active,
I would rate high risk.
Peter
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Wandschneider, Scott
Sent: November 13, 2008 14:20
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
I have the process and have done this before. What I am asking is what the
list would consider the *RISK*? Low, Medium, or High?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark
Wheeler
Sent: Thursday, November 13, 2008 1:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Scott,
First thing I would do is drain the volume, then run ICKDSF against it with
"CPVOL EXAM" command to determine if it is formatted correctly. You may want to
ensure it doesn't come online after the next IPL, so either update SYSTEM
CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This
will let you properly format the page area on the volume after the next IPL.
Whether you add an additional page volume now depends on how much page space
you have available (and I/O rates to the remaining paging volumes).
Best regards,
Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com
--
"I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of the same. People will never
know how far a little kindness can go." Rachel Joy Scott
"Wandschneider,
Scott"
cc
Sent by: The IBM
z/VM OperatingSubject
SystemRisk of Adding a Paging Volume
<[EMAIL PROTECTED]
ARK.EDU>
11/13/2008 12:58
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
I am receiving I/O Errors on one of my PAGE Volumes. What would be considered
the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem
volume. Management is saying wait until we can IPL the system and say it's ok.
What does the list think?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 ||
:: [EMAIL PROTECTED] **Think Green - Please print
responsibly**
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review retransmission dissemination or other use of or taking any action in
reliance upon this information by persons or entities other than the
Re: Risk of Adding a Paging Volume
The only risk is that not draining the problem volume. Any existing page in the problem error could cause a virtual machine or CP abend. The risk of not draining it is increasingly larger as the disk continues to be used. Draining and adding do work. I just added 10 disks to my paging farm. That was all the free slots that I had, or I would have added more. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott > Sent: Thursday, November 13, 2008 11:09 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > Yes, but what would you consider the *risk* of dynamically > adding a volume and setting the problem one to DRAIN? > > > Scott R Wandschneider > > Senior Systems Programmer|| Infocrossing, a Wipro Company || > 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': > 402.963.8905 || Ë:847.849.7223 || :: > [EMAIL PROTECTED] **Think Green - Please > print responsibly** > > > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard > Sent: Thursday, November 13, 2008 1:04 PM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > You need to list it as a draining volume in SYSTEM CONFIG > before the shutdown and IPL. > > Regards, > Richard Schuh > > > > > -Original Message- > > From: The IBM z/VM Operating System > > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > > Sent: Thursday, November 13, 2008 11:02 AM > > To: IBMVM@LISTSERV.UARK.EDU > > Subject: Re: Risk of Adding a Paging Volume > > > > If you have spare volumes, format some as quickly as possible, add > > them t= o the system and DRAIN the problem volume, take it > out of the > > configuration= > > > > files and after the next IPL, test that volume, reformat > that volume, > > tes= t it again, etc. > > > > /Tom Kern > > > > On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott > > <[EMAIL PROTECTED]> wrote: > > > > > I am receiving I/O Errors on one of my PAGE Volumes. > What would be > > considered the risk of adding a new PAGE volume (CP Format, > > etc.) and draining the problem volume. Management is saying wait > > until we can IPL = the system and say it's ok. > > > > > >What does the list think? > > > > > > > > >Scott R Wandschneider > > >
Re: Risk of Adding a Paging Volume
Adding a page volume is low risk. Just make sure you format the new volume with CPFMTXA first. Whether you add a new volume or not, you should drain the volume with errors, and make sure it's drained in SYSTEM CONFIG, too. Dennis Bitterly clinging to my guns. -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Wandschneider, Scott Sent: Thursday, November 13, 2008 11:09 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Risk of Adding a Paging Volume Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > Sent: Thursday, November 13, 2008 11:02 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > If you have spare volumes, format some as quickly as possible, add > them t= o the system and DRAIN the problem volume, take it out of the > configuration= > > files and after the next IPL, test that volume, reformat that volume, > tes= t it again, etc. > > /Tom Kern > > On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott > <[EMAIL PROTECTED]> wrote: > > > I am receiving I/O Errors on one of my PAGE Volumes. What would be > considered the risk of adding a new PAGE volume (CP Format, > etc.) and draining the problem volume. Management is saying wait > until we can IPL = the system and say it's ok. > > > >What does the list think? > > > > > >Scott R Wandschneider >
Re: Risk of Adding a Paging Volume
Thank you Marcy.
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Marcy Cortes
Sent: Thursday, November 13, 2008 1:23 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Low. We add paging volumes all the time to running systems.
Lower than a paging volume with errors for sure.
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."
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Wandschneider, Scott
Sent: Thursday, November 13, 2008 11:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Risk of Adding a Paging Volume
I have the process and have done this before. What I am asking is what the
list would consider the *RISK*? Low, Medium, or High?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark
Wheeler
Sent: Thursday, November 13, 2008 1:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Scott,
First thing I would do is drain the volume, then run ICKDSF against it with
"CPVOL EXAM" command to determine if it is formatted correctly. You may want to
ensure it doesn't come online after the next IPL, so either update SYSTEM
CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This
will let you properly format the page area on the volume after the next IPL.
Whether you add an additional page volume now depends on how much page space
you have available (and I/O rates to the remaining paging volumes).
Best regards,
Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com
--
"I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of the same. People will never
know how far a little kindness can go." Rachel Joy Scott
"Wandschneider,
Scott"
cc
Sent by: The IBM
z/VM OperatingSubject
SystemRisk of Adding a Paging Volume
<[EMAIL PROTECTED]
ARK.EDU>
11/13/2008 12:58
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
I am receiving I/O Errors on one of my PAGE Volumes. What would be considered
the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem
volume. Management is saying wait until we can IPL the system and say it's ok.
What does the list think?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 ||
:: [EMAIL PROTECTED] **Think Green - Please print
responsibly**
Re: Risk of Adding a Paging Volume
Adding additional volume(s) and waiting for the next IPL I would rate as low
risk. Continuing to run as you are, with the volume experiencing errors active,
I would rate high risk.
Peter
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Wandschneider, Scott
Sent: November 13, 2008 14:20
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
I have the process and have done this before. What I am asking is what the
list would consider the *RISK*? Low, Medium, or High?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark
Wheeler
Sent: Thursday, November 13, 2008 1:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Scott,
First thing I would do is drain the volume, then run ICKDSF against it with
"CPVOL EXAM" command to determine if it is formatted correctly. You may want to
ensure it doesn't come online after the next IPL, so either update SYSTEM
CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This
will let you properly format the page area on the volume after the next IPL.
Whether you add an additional page volume now depends on how much page space
you have available (and I/O rates to the remaining paging volumes).
Best regards,
Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com
--
"I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of the same. People will never
know how far a little kindness can go." Rachel Joy Scott
"Wandschneider,
Scott"
cc
Sent by: The IBM
z/VM OperatingSubject
SystemRisk of Adding a Paging Volume
<[EMAIL PROTECTED]
ARK.EDU>
11/13/2008 12:58
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
I am receiving I/O Errors on one of my PAGE Volumes. What would be considered
the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem
volume. Management is saying wait until we can IPL the system and say it's ok.
What does the list think?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 ||
:: [EMAIL PROTECTED] **Think Green - Please print
responsibly**
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review retransmission dissemination or other use of or taking any action in
reliance upon this information by persons or entities other than the intended
recipient or delegate is strictly prohibited. If you received this in error
please contact the sender and delete the material from any computer. The
integrity and security of this message cannot be guaranteed on the Internet.
The sender accepts no liability for the content of this e-mail or for the
consequences of any actions taken on the basis of information provided. The
recipient should check this e-mail and any attachments for the presence of
viruses. The sender accepts no
Re: Risk of Adding a Paging Volume
Low. We add paging volumes all the time to running systems.
Lower than a paging volume with errors for sure.
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."
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of
Wandschneider, Scott
Sent: Thursday, November 13, 2008 11:20 AM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: [IBMVM] Risk of Adding a Paging Volume
I have the process and have done this before. What I am asking is what the
list would consider the *RISK*? Low, Medium, or High?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark
Wheeler
Sent: Thursday, November 13, 2008 1:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Scott,
First thing I would do is drain the volume, then run ICKDSF against it with
"CPVOL EXAM" command to determine if it is formatted correctly. You may want to
ensure it doesn't come online after the next IPL, so either update SYSTEM
CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This
will let you properly format the page area on the volume after the next IPL.
Whether you add an additional page volume now depends on how much page space
you have available (and I/O rates to the remaining paging volumes).
Best regards,
Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com
--
"I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of the same. People will never
know how far a little kindness can go." Rachel Joy Scott
"Wandschneider,
Scott"
cc
Sent by: The IBM
z/VM OperatingSubject
SystemRisk of Adding a Paging Volume
<[EMAIL PROTECTED]
ARK.EDU>
11/13/2008 12:58
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
I am receiving I/O Errors on one of my PAGE Volumes. What would be considered
the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem
volume. Management is saying wait until we can IPL the system and say it's ok.
What does the list think?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 ||
:: [EMAIL PROTECTED] **Think Green - Please print
responsibly**
Re: Risk of Adding a Paging Volume
I have the process and have done this before. What I am asking is what the
list would consider the *RISK*? Low, Medium, or High?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || ::
[EMAIL PROTECTED] **Think Green - Please print responsibly**
-Original Message-
From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Mark
Wheeler
Sent: Thursday, November 13, 2008 1:09 PM
To: IBMVM@LISTSERV.UARK.EDU
Subject: Re: Risk of Adding a Paging Volume
Scott,
First thing I would do is drain the volume, then run ICKDSF against it with
"CPVOL EXAM" command to determine if it is formatted correctly. You may want to
ensure it doesn't come online after the next IPL, so either update SYSTEM
CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This
will let you properly format the page area on the volume after the next IPL.
Whether you add an additional page volume now depends on how much page space
you have available (and I/O rates to the remaining paging volumes).
Best regards,
Mark L. Wheeler
IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144
Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com
--
"I have this theory that if one person can go out of their way to show
compassion then it will start a chain reaction of the same. People will never
know how far a little kindness can go." Rachel Joy Scott
"Wandschneider,
Scott"
cc
Sent by: The IBM
z/VM OperatingSubject
SystemRisk of Adding a Paging Volume
<[EMAIL PROTECTED]
ARK.EDU>
11/13/2008 12:58
PM
Please respond to
The IBM z/VM
Operating System
<[EMAIL PROTECTED]
ARK.EDU>
I am receiving I/O Errors on one of my PAGE Volumes. What would be considered
the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem
volume. Management is saying wait until we can IPL the system and say it's ok.
What does the list think?
Scott R Wandschneider
Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle
Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 ||
:: [EMAIL PROTECTED] **Think Green - Please print
responsibly**
Re: Risk of Adding a Paging Volume
Scott, First thing I would do is drain the volume, then run ICKDSF against it with "CPVOL EXAM" command to determine if it is formatted correctly. You may want to ensure it doesn't come online after the next IPL, so either update SYSTEM CONFIG to mark it as DRAINED, or clip the volser so it can't be found. This will let you properly format the page area on the volume after the next IPL. Whether you add an additional page volume now depends on how much page space you have available (and I/O rates to the remaining paging volumes). Best regards, Mark L. Wheeler IT Infrastructure, 3M Center B224-4N-20, St Paul MN 55144 Tel: (651) 733-4355, Fax: (651) 736-7689 mlwheeler at mmm.com -- "I have this theory that if one person can go out of their way to show compassion then it will start a chain reaction of the same. People will never know how far a little kindness can go." Rachel Joy Scott "Wandschneider, Scott" cc Sent by: The IBM z/VM OperatingSubject System Risk of Adding a Paging Volume <[EMAIL PROTECTED] ARK.EDU> 11/13/2008 12:58 PM Please respond to The IBM z/VM Operating System <[EMAIL PROTECTED] ARK.EDU> I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL the system and say it's ok. What does the list think? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly**
Re: Risk of Adding a Paging Volume
Yes, but what would you consider the *risk* of dynamically adding a volume and setting the problem one to DRAIN? Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Schuh, Richard Sent: Thursday, November 13, 2008 1:04 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume You need to list it as a draining volume in SYSTEM CONFIG before the shutdown and IPL. Regards, Richard Schuh > -Original Message- > From: The IBM z/VM Operating System > [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern > Sent: Thursday, November 13, 2008 11:02 AM > To: IBMVM@LISTSERV.UARK.EDU > Subject: Re: Risk of Adding a Paging Volume > > If you have spare volumes, format some as quickly as possible, add > them t= o the system and DRAIN the problem volume, take it out of the > configuration= > > files and after the next IPL, test that volume, reformat that volume, > tes= t it again, etc. > > /Tom Kern > > On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott > <[EMAIL PROTECTED]> wrote: > > > I am receiving I/O Errors on one of my PAGE Volumes. What would be > considered the risk of adding a new PAGE volume (CP Format, > etc.) and draining the problem volume. Management is saying wait > until we can IPL = the system and say it's ok. > > > >What does the list think? > > > > > >Scott R Wandschneider >
Re: Risk of Adding a Paging Volume
I have the process - What I am asking is; what would be considered the risk of doing this to a production running system? Management is playing hardball. Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -Original Message- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Kern Sent: Thursday, November 13, 2008 1:02 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume If you have spare volumes, format some as quickly as possible, add them t= o the system and DRAIN the problem volume, take it out of the configuration= files and after the next IPL, test that volume, reformat that volume, tes= t it again, etc. /Tom Kern On Thu, 13 Nov 2008 11:57:51 -0700, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > I am receiving I/O Errors on one of my PAGE Volumes. What would be considered the risk of adding a new PAGE volume (CP Format, etc.) and draining the problem volume. Management is saying wait until we can IPL = the system and say it's ok. > >What does the list think? > > >Scott R Wandschneider
