If the VTOC is in the wrong place, I wonder what is wrong with the rest
of the disk. That sounds like it was formatted for OS or VSE. I don't
know if there is any value in locating the VTOC in the middle for those
systems any more. That was done to help lessen the seek time back in the
day when a disk was a coherent unit instead of a collection of scattered
sectors.
 
If you ipl to free this disk, you can include it as a drained device in
your system config. Then you can fix or replace it and add it back in
the configuration via commands. Do not forget to take it out of the
drained devices list. 

Regards, 
Richard Schuh 

 

 


________________________________

        From: The IBM z/VM Operating System
[mailto:[EMAIL PROTECTED] On Behalf Of Howard Rifkind
        Sent: Wednesday, November 05, 2008 2:35 PM
        To: [email protected]
        Subject: Re: Removing a Paging Volume
        
        
        Thanks all for the info, much appreciated. 
        
        >>> Alan Altmark <[EMAIL PROTECTED]> 11/5/2008 4:39 PM >>>
        On Wednesday, 11/05/2008 at 04:04 EST, Bob Bates 
        <[EMAIL PROTECTED]> wrote:
        > Well you can drain (CP  DRAIN DASD rdev PAGE) it, but it might
never 
        come 
        > completely clean.  And since it is running at 71%, I'd wonder
about the 
        ability 
        > of  the other pack(s) to take up its load. You might want to
consider 
        adding 
        > some more page packs to the system if you can. 
        >  
        > Why is there a VTOC on a  paging volume?
        
        There's always a VTOC - it tell other systems that the disk has
no 
        available extents for allocation.  I'm trying to figure out how
the VTOC 
        got somewhere other than cyl 0!  If it's laying in the middle of
the pack 
        somewhere (result of mdisk) and that record isn't formatted as a
4K record 
        (labels are 80 bytes), there's going to be trouble if CP chooses
that 
        record to page to!  Though thinking about it some more, I think
CP will 
        simply mark that record as "in error" and skip it.
        
        Alan Altmark
        z/VM Development
        IBM Endicott
        
        
        
        

_____________
LEGAL NOTICE
Unless expressly stated otherwise, this message is confidential
and may be privileged. It is intended for the addressee(s) only.
Access to this E-mail by anyone else is unauthorized.
If you are not an addressee, any disclosure or copying of the
contents of this E-mail or any action taken (or not taken) in
reliance on it is unauthorized and may be unlawful. If you are not an
addressee, please inform the sender immediately, then delete this
message and empty from your trash.
        

Reply via email to