>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
SPXTAPE is not the only thing that increases the amount of dump space that is required. Dump space allocation is increased (and decreased) based on the number of CP pages in use at the time. It is normal for dump space to increase from the time you IPL; at IPL time, there isn't as much going on on your system, and therefore, not as many CP pages being used, as later on when more guests are active and running their workloads. CP uses "demand paging", meaning once a page is used by CP it is not "released" until it is needed for something else. So even though your system may not be busy right now, pages that were by used CP sometime in the past past are likely to still be allocated and included in the calculation of reserved dump space. Sometimes information in these pages is helpful when analyzing a dump to diagnose a problem. When you move to z/VM 5.2, the size of CP dumps (and the amount of reserved space allocated) will increase. There are guidelines in the z/VM CP Planning and Administration Guide for how much space to allow for dumps, but an initial rule of thumb is to plan for twice as much as you used previously. John Franciscovich z/VM Development
