> I also cleaned up spool so both systems have roughly the same number of spool files. In the future, "roughly the same number of spool files" isn't he same as knowing the size of the spool files.
>From a Class D userid, 'CP Query RDR EXP' (and also for PUN, and PRT) will help provide the answer (via a little piping), since the EXP operand displays the number of 4K SPOOL pages occupied by each file. But finding the appropriate PTF is better still! Happy New Year, indeed! Mike Walter Hewitt Associates The opinions expressed herein are mine alone, not my employer's. "Marcy Cortes" <marcy.d.cor...@wellsfargo.com> Sent by: "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> 01/05/2010 03:27 PM Please respond to "The IBM z/VM Operating System" <IBMVM@LISTSERV.UARK.EDU> To IBMVM@LISTSERV.UARK.EDU cc Subject Re: Amount of CP dump space needed But isn't the spxtape use cleared up by "set dump off#set dump dasd" ? That just made it grow... Q RECORDING shows nothing pending retrieval. I also cleaned up spool so both systems have roughly the same number of spool files. 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 Tom Duerbusch Sent: Tuesday, January 05, 2010 11:44 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: [IBMVM] Amount of CP dump space needed There was a problem with spxtape which I thought was fixed by z/VM 5.4. But as we see it, on z/VM 5.2.... SPXTAPE tried to buffer as much as possible. As spxtape is a CP function, all of its buffers end up requiring slots on the CP Dump dataset. When spxtape finishes, there is no automatic way off reducing the amount of slots used, as an CP abend might happen a few seconds, minutes after spxtape ended and well, "what if it was the cause?". I take it that there are other "CP" functions that may end up buffering or using storage that requires slots in the CP DUMP area. Something like "Q RECORDING" and if nothing is servicing those records, CP is buffering them. Of course, the page tables and all that storage related stuff needs to be dumped in case of a CP abend, so the CP DUMP slots are allocated. So the memory size of the LPAR is a consideration, as well as the sum of the virtual sizes of all the machines that are logged on is also a consideration. Tom Duerbusch THD Consulting >>> Marcy Cortes <marcy.d.cor...@wellsfargo.com> 1/5/2010 1:09 PM >>> How is the amount of CP dump space calculated? We have a system that seems to be using at lot more than the others. Everything is pretty much identical across the LPARs HW wise (access to all the same devices, etc) and SW wise (z/VM 5.4 RSU 0902). Here's an example. System A: q dump DASD F1B0 dump unit CP IPL pages 1140129 Ready; T=0.01/0.01 13:02:40 System J: q dump DASD F00D dump unit CP IPL pages 169959 Ready; T=0.01/0.01 13:03:32 Both systems have 32G (28 central, 4 expanded). If anything System A has less memory usage (does not page with 10 linux ) and System J does (16 linux). I tried set dump off and then set dump DASD to see if that would change the numbers. The number on system A grew (from 1131137 to 1140129) while System J did not change. Why would be they be so radically different? 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." 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.
