Yeah, I know what it means. I was just not expecting the size reserved for the dump to *grow* when I did the SET DUMP DASD.
I have no intentions to allocate another SPOOL volume. We run only Linux guests and there's little demand for spool space. The other thing of interest is that since the last IPL the SPOOL space reserved for the DUMP has approximately doubled (as evidenced by it being split nearly equally between the 2 volumes before the SET DUMP DASD) and *none* of that doubling is attributable to SPXTAPE. Brian Nielsen On Fri, 13 Oct 2006 10:09:35 -0700, Schuh, Richard <[EMAIL PROTECTED]> wrot e: >If you have another pack that you can use, I would suggest formatting it , allocating it a SPOL pack, and designating it as a dump pack in your system config. That 91% that you see for Z52SP2 is mostly allocated for DUMP. You have, in effect, a 1-pack SPOOL system plus the DUMP files. Since contiguous pages are allocated for the dumps at ipl (unless DUMP is set OFF), you will always see the disparity between the 2 packs and all o f almost all of your normal spooling will be on the other, non-dump, pack. > >Regards, >Richard Schuh > > >> -----Original Message----- >> From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] >> Behalf Of Brian Nielsen >> Sent: Friday, October 13, 2006 9:56 AM >> To: IBMVM@LISTSERV.UARK.EDU >> Subject: Re: VM SPOOL question >> >> >> I decided to see what SET DUMP DASD would do on my system as far as >> reclaiming any DUMP space growth caused by SPXTAPE over time. >> Here is = >> >> what I got: >> >> q dump >> DASD dump space CP IPL >> RDEV PAGES >> ---- ----- >> 661F 278346 >> 6748 253074 >> Ready; T=0.01/0.01 10:37:25 >> set dump dasd >> DASD 661F dump unit CP IPL pages 546256 >> Ready; T=0.01/0.01 10:37:45 >> q alloc spool >> EXTENT EXTENT TOTAL PAGES HIGH % >> VOLID RDEV START END PAGES IN USE PAGE USED >> ------ ---- ---------- ---------- ------ ------ ------ ---- >> Z52SP1 6748 1 3338 600840 8516 585886 1% >> Z52SP2 661F 1 3338 600840 546813 555535 91% >> ------ ------ ---- >> SUMMARY 1174K 555329 46% >> USABLE 1174K 555329 46% >> Ready; T=0.01/0.01 10:39:04 >> >> >> As the Q DUMP shows, the dump used to be spread roughly >> evenly between my= >> >> 2 SPOOL packs. Now it's concentrated on one pack. Rats. >> >> It also *grew* in size from 531420 pages to 546256 pages. >> It's only 2.8%= >> >> larger, but it was unexpected. >> >> q cplevel >> z/VM Version 5 Release 2.0, service level 0501 (64-bit) >> Generated at 03/01/06 12:37:45 MDT >> IPL at 03/26/06 09:48:10 MDT >> >> Brian Nielsen >> >> >> On Fri, 13 Oct 2006 09:29:16 -0700, Schuh, Richard >> <[EMAIL PROTECTED]> wrot= >> e: >> >> >And at least the larger of the 2 will grow over time, >> depending on the = >> >> amount of space needed to include all pages devoted to CP. >> This has been = >> >> thoroughly discussed in this forum in the fairly recent past. >> SPXTAPE was= >> >> named as a big contributor to the growth. The only way to >> scale the dump = >> >> file back is to SET DUMP DASD. It is not necessary to SET >> DUMP OFF first,= >> >> the SET DUMP DASD causes the file to be reallocated. >> > >> >Regards, >> >Richard Schuh >> >======================== ========================= =======================
