Hi, I just wanted to chime in and confirm that CP will indeed mark a page (or spool) record for which a write attempt failed as allocated and "permanently in use", so after it's failed (after a few retries), CP will
never attempt to write to or read from it again for the life of the IPL. - Bill Holder, z/VM Development, IBM On Fri, 4 Jan 2008 14:03:33 +0100, Rob van der Heij <[EMAIL PROTECTED]> w rote: >On Jan 4, 2008 1:32 PM, David Boyes <[EMAIL PROTECTED]> wrote: > >> Did you recently add some page space to the system, or possibly >> overlapped some of your paging or spool space with a minidisk? This >> message can be caused by forgetting to format the page space with >> ICKDSF, or if you've accidentally overlaid part of your paging or spoo l >> space with a minidisk, CP will complain about that (CMS or Linux >> formatted space makes CP sad). > >I seem to recall that CP records a slot as in-use even when it failed >to write out the page. So the fact that so many slots locks are >already in-use on the device probably does not imply there were any >usable pages there... >In the distant past one never had to add page packs because the load >of VM was getting less and the machine were getting bigger. All we had >to do was add user disks for this decreasing workload ;-) (hint: no, >the work was not getting less, the machines were getting faster). So >VM storage administrators (or often z/OS storage folks with a cheat >sheet) learned that for VM it was enough to format allocate cylinder 0 >and go for it (because DIRMAINT and otherwise CMS) would format the >mini disks anyway. But not for CP owned volumes, as pointed out by >others. > >I believe DIRMAINT already blocks CP areas from allocation these days, >even when you don't do $PAGE$ and $SPOL$ userids. But for those shops >without, wibni CP would prevent lesser gods from completing a LINK to >a device that lives on a CP area? (except for parm disks, I guess) > >Rob >======================== ========================= ========================
