If his VM has consumed all of the page area and gone into the spool area, couldn't he do         Q ALLOC  PAGE and see how much
page are is being used?



John Hall <[EMAIL PROTECTED]>
Sent by: VM/ESA and z/VM Discussions <[email protected]>

11/05/2005 01:37 PM
Please respond to VM/ESA and z/VM Discussions

       
        To:        [email protected]
        cc:        
        Subject:        Re: Q ALLOC SPOOL ????



On 11/5/05, Randy Dray <[EMAIL PROTECTED]> wrote:
> Hello List,
>
> I issued a Q ALLOC SPOOL at vm console logged on as
> MAINT.
>
> q alloc spool
>            EXTENT EXTENT  TOTAL  PAGES   HIGH    %
> VOLID  RDEV  START    END  PAGES IN USE   PAGE USED
> ------ ---- ------ ------ ------ ------ ------ ----
> 440RES 0600     79    256  32040  26765  31680  83%
>                          ------ ------        ----
> SUMMARY                    32040  26765         83%
> USABLE                     32040  26765         83%
>
> Its used states 83%.
>
> I q rdr all and got abunch of files.
>
> Backed them up and then purged them off.
>
> I did the same for PRT files.  Purged them all off.
>
> DID NOT have any pun files.
>
>
> QUESTION:  MY q alloc spool still hasn't moved off
> 83%.
>
> I thought that % used would have dropped to almost
> nothing.
>
<Snip>

Yes, I'd have expected that as well...until I really got to thinking
about how spool is used.

Here is the output from an almost native z/VM 4.4.0 system here:
cp q alloc spool
           EXTENT EXTENT  TOTAL  PAGES   HIGH    %
VOLID  RDEV  START    END  PAGES IN USE   PAGE USED
------ ---- ------ ------ ------ ------ ------ ----
440RES 043B     79    256  32040  17491  25600  54%
440W02 043D   2456   3338 158940  15518  15998   9%
                         ------ ------        ----
SUMMARY                   190980  33009         17%
USABLE                    190980  33009         17%

This system has almost no PUN, PRT, or RDR files, and should have the
standard set of system spool files (NSS, IMG).  I think that the spool
space on 440W02 might have been added by us after the installation.

What I can take from this, however, is that this system has about
33,000 pages in use, which is comparable to your count of 26,765.

The z/VM Spool area is used for many things.  As we've all discussed,
RDR, PRT, and PUN files live there.  You'll also find: NSS, TRF, and
IMG.  Additionally, you'll find that CP likes to allocate a dump area
in spool in case of a system abend.  The last item that can consume
spool is a full paging area.  When z/VM fills the existing PAGE space
and needs more paging space, it will use SPOOL.  You might have a
consumption of spool for page.

My first guess is Dump...On a whim, I disabled the z/VM dump with a CP
SET DUMP OFF, and my pages in use dropped to 8000.  Note that this is
a test system, so I'm more comfortable with doing this.  I wouldn't
disable it on my production system, because I'd hate to hit an error
and not be able to get a dump.  I'd be willing to bet that the vast
majority of the in use spool is due to the CP Dump area.

Try: "CP QUERY DUMP".  That will show you how many pages are allocated
for dump space.  You'll probably find that the "rdev" in the QUERY
DUMP matches the rdev that your spool is allocated on.  That will be a
quick check that the consumption is for DUMP.  If 26765 - <number of
pages allocated for dump> is around 8000, then I'd say Dump is
definately the culprit.

If it's dump, it's hard to suggest what to do about this situation, as
your needs/requirements might not be the same as ours.  You might
consider:
- Disabling dump (bad if you hit a problem and need a dump to resolve it)
- Allocate more spool space *Recommended*, but a bit more difficult to
accomplish.  You might consider waiting until after your z/VM class to
tackle this, but if that's months away, you probably won't want to
wait.

Of course, if it's not the dump area, then you'll want to keep digging
for the cuprit.

John
--
John Hall   (+1) 727-397-6373      Safe Software, Inc.
JohnHall (at) SafeSoftware.Com  http://www.SafeSoftware.Com
JohnBeachFL (at) gmail.com


Reply via email to