On 11/08/2005 02:46 PM, "John Franciscovich" <[EMAIL PROTECTED]> wrote:
"ALL dump space is allocated from spool. There is a DUMP operand on the
CP_OWNED system configuration file statement which allows you to reserve
all of the allocated spool (SPOL) space on particular volume(s) for
dumps."
Earlier this week I had recommended using CPFMTXA (using ICKDSF under the covers) to format dump space as "DUMP" rather than "SPOL".
I was wrong. John is right. (Duh!) I revoke my earlier misinformation, and apologize for passing on ancient folklore (see below). Allocate it as SPOL, but mark it as reserved as DUMP in 'SYSTEM CONFIG', for example:
...
CP_Owned Slot 1 VMSP01 OWN
CP_Owned Slot 2 VMSP02 OWN
CP_Owned Slot 3 RESERVED
CP_Owned Slot 4 VMDUMP DUMP
...
I'd have sworn in a court of law that I saw an allocation type of DUMP somewhere. And... checking the ICKDSF manual ("Device Support Facilities User's Guide and Reference Release 16 Refresh with Peer-to-Peer Copy" GC35-0033-22 -- is that a long title or what!?) it shows (p 14-7) under CPVOLUME Command - CKD:
TYPE((type of allocation,start,end)...)
Where TYPE is listed as any of: DRCT, DUMP (Dump space for System/370) <which is easy to interpret as overlooked, obsolete info>, OVRD, PAGE, PARM, PERM, SPOL, TDSK, TEMP.
Under "Restrictions" in the next box it clearly revokes types of DUMP, OVRD, and TEMP for VM/ESA and VM/XA. Our VMDUMP volume had probably been formatted that way for "a while now". Properly, the current version of the manual does not mention the "olde" allocation types.
Checking with CP QUERY ALLOC SPOOL (Q ALLOC DUMP is obviously not valid without type "DUMP") it shows files allocated on our VMDUMP even though we have no CP or VMDUMPs on SPOOL.
cp q alloc spool
EXTENT EXTENT TOTAL PAGES HIGH %
VOLID RDEV START END PAGES IN USE PAGE USED
------ ---- ------ ------ ------ ------ ------ ----
VMSP01 093A 1 3338 600840 136988 344246 22%
VMSP02 093B 1 3338 600840 106680 381801 17%
VMDUMP 0923 1 3338 600840 94594 420693 15%
------ ------ ----
SUMMARY 1803K 338262 18%
USABLE 1803K 338262 18%
Ready or not; T=0.01/0.01 15:35:32
q r all operatns
ORIGINID FILE CLASS RECORDS CPY HOLD DATE TIME NAME TYPE DIST
SYSTEM 0001 D SYS 00000000 001 NONE OPEN- SYS HCPDUMP SYSTEM
SYSTEM 0012 D SYS 00000000 001 NONE OPEN- SYS CPDUMP CPDUMP
Ready or not; T=0.01/0.01 15:35:35
Q:
So... now a fresh question for John. If I change our SYSTEM CONFIG to:
CP_Owned Slot 4 VMDUMP DUMP
and there are already normal SPOOL files on that volume, what happens?
Do I get nailed at the next IPL with some sort of WARM start failure?
Or will we just stop allocating fresh non-dump files to that volume, and gradually
see it clear up for CP's DUMP usage only?
And also for John... I have already updated my Seattle SHARE presentation to include this DUMP update.
Mike Walter
Hewitt Associates
The opinions expressed herein are mine alone, not my employer's.
| "John Franciscovich"
<[EMAIL PROTECTED]>
Sent by: "VM/ESA and z/VM Discussions" <[email protected]> 11/08/2005 02:46 PM
|
|
Re: Q alloc SPool Help BINGO!!!!!!! - now we are on to something!
>The size of your dump area, is determined by the memory locations that
>CP has "ever" used. For example, when CP needs 10 pages from the
>Dynamic Paging Area, if it never touched those pages before, you dump
>file expand by those 10 pages. When CP releases those pages, those
>pages are not, repeat "NOT" released from your dump file requirements.
>So, if the next time CP needs a few pages, if it uses the pages it used
>before, those pages have already been marked as pages to be written to
>the dump file, in case of an abend. However, if they are never befored
>allocated pages to CP, even if there has been freed pages before, your
>dump area will expand to include those pages in the dump in case of a CP
>abend.
As I've explained here several times, CP does increase the amount of
dump space allocated when it needs to, but not on a page by page basis.
Beginning in z/VM 4.4.0, the amount of dump space allocated is reduced
when appropriate.
This is how it works:
Before z/VM 4.4.0:
1) During CP initialization and whenever a SET DUMP DASD command is
issued, CP allocates dump space based on the number of CP pages
in use at that point in time. CP adds 12.5% to the number of
pages in use and allocates that many spool pages for dump.
2) Each time CP allocates a new page, the number of pages in use is
checked to see if it has reached the total number of spool pages
allocated for dump. If it has, CP releases the dump space it has
allocated, adds 12.5% to the current number of CP pages in use, and
re-allocates that many spool pages for dump.
Dump space allocation is increased as needed but never reduced
unless SET DUMP is issued.
In z/VM 4.4.0 and later:
1) During CP initialization and whenever a SET DUMP DASD command is
issued, CP allocates dump space based on the number of CP pages
in use at that point in time. CP adds 12.5% to the number of
pages in use and allocates that many spool pages for dump.
CP also computes and saves a threshold value which is 25% below the
number of pages in use.
2) Each time CP allocates a new page, the number of pages in use is
checked to see if it has reached the total number of spool pages
allocated for dump. If it has, releases the dump space it has
allocated, adds 12.5% to the current number of pages in use, and
re-allocates that many spool pages for dump. CP also re-computes -25%
threshold value.
If the number of CP pages in use is reduced to the point that it
reaches the -25% threshold value, CP releases the dump space it has
allocated, adds 12.5% to the current number of pages in use, and
re-allocates that many spool pages for dump. A new -25% threshold is
also computed based on the current number of pages in use.
>If your dump file is allocated from spool and spool is full and CP
>tries to allocate a "never before allocated to CP" page? It can't
>expand the dump dataset and CP abends.
>So, indirectly, if you don't have a "dump" area, equal in size to your
>main memory (up to 2 GB) in an area of type "dump" (not spol), you are
>subject to a CP abend when spool file fills.
NO!
ALL dump space is allocated from spool. There is a DUMP operand on the
CP_OWNED system configuration file statement which allows you to reserve
all of the allocated spool (SPOL) space on particular volume(s) for
dumps.
CP does NOT abend if there is not enough spool space available to
allocate a dump. It will simply turn dump off, and a message is sent to
the operator indicating that dump is off because there is not enough
space for it.
>Apparently the 2 GB max will still be the case with z/VM 5.2. CP will
>still allocate below the line. It is I/O that now can be moved above
>the line with z/VM 5.2.
Dumps will be larger in 5.2.0, and can be larger than 2 GB due to the
increased size of the frame table and other control structures. But it
will not be as large as the amount of storage you might have on your
system. The rule of thumb is to allow twice as much space for dumps in
5.2.0 than you did in 5.1.0.
John Franciscovich
z/VM Development
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.
