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 of 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 >
