Correct - it should read "3) ALLOCATE 0-0 PERM and 1-END PAGE." Good thing email doesn't execute!
Scott R Wandschneider Senior Systems Programmer|| Infocrossing, a Wipro Company || 11707 Miracle Hills Drive, Omaha, NE, 68154-4457|| ': 402.963.8905 || Ë:847.849.7223 || :: [EMAIL PROTECTED] **Think Green - Please print responsibly** -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Rob van der Heij Sent: Friday, November 14, 2008 1:19 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Risk of Adding a Paging Volume On Thu, Nov 13, 2008 at 11:10 PM, Wandschneider, Scott <[EMAIL PROTECTED]> wrote: > The only I/O Errors that we are seeing are on one of the paging volumes, > BDCPG2: > I have already done the following in preparation: > 1) ATTach 1D67 to MAINT > 2) CPFMTZA FORMAT 0-end on a new volume, BDCPG3. > 3) ALLOCATE 0-0 PAGE and 1-END PAGE. I suppose you meant to allocate cylinder 0 as PERM rather PAGE (only problem there is that people may assume it is bad). But it looks good in that you format the entire volume, so makes me wonder about the PG2 volume. Like what are you going to do with that once it is not being used anymore by VM ? What can you do to the volume to make I/O errors go away? What I tried to point out is that real I/O errors are handled by the DASD subsystem. It could be that some major hardware problems do result in the device passing errors to the host, but that would probably impact all logical volumes on that particular rank. I would strongly recommend you take the EREP data to a hardware CE to look at the sense codes. Since you only had two paging volumes, the bad volume was hit a lot as well. I recall from earlier discussion that even when CP failed to write the block, it still marks it as in-use (in the old days to avoid writing again in that same spot). So it may be that once you have shutdown all guests that have pages out on disk, there still remains pages allocated. Rob
