Hi
Thanks to all for your thoughtful input.
I think I see the issue now and it does appear to be a formatting
problem. When I formatted the pack using CPFMTXA I did the following:
When I was prompted to do the following I replied 0 0: I believe it
should have been 0 END. I noticed when I did 0 0 I did not see each
cylinder being formatted but when I tested it out on another pack using
0 END I saw that it was actually going through and formatting of the
cylinders. I am actually surprised that it was able to write any pages
out to these volumes.
Does this sound like a logical explanation?
ENTER THE CYLINDER RANGE TO BE FORMATTED ON DISK 5058 OR QUIT:
0 0
I then did the following:
ENTER ALLOCATION DATA
TYPE CYLINDERS
.................
perm 0 0
HCPCCF0380E INVALID CYLINDER TYPE - ''
REENTER: TYPE AND CYLINDERS OR 'END'
page 1 end
CONSOLE
ICK031E DEFINE OUTPUT DEVICE: FN FT FM, "CONSOLE", OR "PRINTER"
CONSOLE
ICKDSF - CMS/XA/ESA DEVICE SUPPORT FACILITIES 17.0 TIME:
11:17:12
02/11/09 PAGE 1
ENTER INPUT COMMAND:
CPVOL ALLOC MODE(ESA) UNIT(5058) VFY(PP5058) -
ENTER INPUT COMMAND:
TYPE((PERM,0,0) -
ENTER INPUT COMMAND:
(PAGE,1,10016))
ICK00700I DEVICE INFORMATION FOR 5058 IS CURRENTLY AS FOLLOWS:
PHYSICAL DEVICE = 3390
STORAGE CONTROLLER = 3990
STORAGE CONTROL DESCRIPTOR = E9
DEVICE DESCRIPTOR = 0C
ADDITIONAL DEVICE INFORMATION = 48001F3C
TRKS/CYL = 15, # PRIMARY CYLS = 10017
ICK04000I DEVICE IS IN SIMPLEX STATE
ICK00091I 5058 NED=002107.900.IBM.75.0000000R5471
ICK091I 5058 NED=002107.900.IBM.75.0000000R5471
ICK03020I CPVOL WILL PROCESS 5058 FOR VM/ESA MODE
ICK03090I VOLUME SERIAL = PP5058
ICK03024I DEVICE IS CURRENTLY FORMATTED WITHOUT FILLER RECORDS
ICK003D REPLY U TO ALTER VOLUME 5058 CONTENTS, ELSE T
U
ICK03000I CPVOL REPORT FOR 5058 FOLLOWS:
CYLINDER ALLOCATION CURRENTLY IS AS FOLLOWS:
TYPE START END TOTAL
---- ----- --- -----
PERM 0 0 1
PAGE 1 10016 10016
ICK00001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0
11:17:56 02/11/09
ENTER INPUT COMMAND:
END
ICK00002I ICKDSF PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0
Thank You,
Terry Martin
Lockheed Martin - Information Technology
z/OS & z/VM Systems - Performance and Tuning
Cell - 443 632-4191
Work - 410 786-0386
[email protected]
-----Original Message-----
From: The IBM z/VM Operating System [mailto:[email protected]] On
Behalf Of Bill Holder
Sent: Wednesday, February 11, 2009 1:18 PM
To: [email protected]
Subject: Re: Paging
Just a few general comments:
Paging space becoming full and paging errors are two different problems
t
hat
manifest differently (though the latter can certainly contribute to the
former). Inadequate paging space will not lead to paging errors being
reported.
If paging space becomes full, paging will overflow to spool space, and
messages 401 (90% full) and 400 (100% full) will have been issued for
pag
ing
space. If spool space also becomes full, those messages will also be
iss
ued
for spool space, and a PGT004 hard abend will likely result.
If paging errors occur, there should be EREP messages. Message 0415
("Si
x
continuous paging errors...") will only be issued if 6 paging IO
requests
in
a row to a single volume all result in failures. This is really not
like
ly
to be a hardware problem with modern highly cached virtual storage DASD
systems like Shark and such. These errors almost always occur on write
requests, as one slot is found to be "bad" (unusable), and the algorithm
bumps to the next available slot and tries it in turn. As others have
mentioned, it's almost always because a contiguous region of paging
space
was either never formatted completely, or have since been overlaid by
something else (such as a minidisk). If a large enough area of paging
sp
ace
is not correctly formatted, this can result in a PGT004 or FRF002 (or
les
s
likely, SXP004) hard abend outage as CP finds no usable paging space to
write to, and storage starts filling up with queued 0415 and EREP
message
s.
In my experience, such paging errors are overwhelmingly caused by lack
of
(or improper) formatting, with minidisk overlays being a distant second,
and
actual disk hardware problems a very far distant third.
- Bill Holder, z/VM Development, IBM Endicott
