I agree about  'caused by concurrent R/W', and the steps to fix...
but on the DMSDKD1307T, I've seen a case...
http://www-1.ibm.com/support/docview.wss?uid=isg1VM61782
Probably not related... a long time ago, yes...
Gregg
 "No plan survives execution"


                                                                           
             Kris Buelens                                                  
             <[EMAIL PROTECTED]                                             
             ibm.com>                                                   To 
             Sent by: VM/ESA           [email protected]           
             and z/VM                                                   cc 
             Discussions                                                   
             <[EMAIL PROTECTED]                                     Subject 
             .UARK.EDU>                Re: MINI DISK Corruption            
                                                                           
                                                                           
             12/31/2005 05:48                                              
                                                                           
                                                                           
             Please respond to                                             
              VM/ESA and z/VM                                              
                Discussions                                                
             <[EMAIL PROTECTED]                                             
                .UARK.EDU>                                                 
                                                                           
                                                                           





Most readers missed the real issue: DMSDKD1307T error  This means the
minidisk is corrupted and must be repaired.  In my long VM history, all
corrupted minidisks were caused by concurrenbt R/W access, not by some CMS
bug that appears when a disk gets100% full.

Using DDR can't help at all: it will copy the error over to the target
minidisk.

One must save the good files one by one and then reformat the corrupted
minidisk.  Using a Tdisk as temporaly place isn't very good: if VM would
bounce (or a power outage, or ...) your Tdisk gets lost.  Better thus is
using some other permanent minidisk or an SFS directory, or use SENDFILE
to store them in the spool.

COPYFILE * * sourcefm = = targetfm (OLDDATE
will break when it reaches a broken file.  Better is thus using FILELIST
and EXECUTE
 - FILELIST * * sourcefm
 - EXECUTE * COPYFILE / = = targetfm (OLDDATE
 or EXECUTE * SENDFILE / TO * (NOLOG
Then when CMS abends due to the broken file, re-IPL CMS,
- find the last file that was copied fine
- restart FILELIST and go to the last file that copied OK
  e.g. with this locate command:  /lastgoodFn lastgoodFt/
- skip this good file and the bad one by entering  +2
- start copying: EXECUTE * COPYFILE ....  or EXECUTE * SENDFILE ...
If you have many broken files, it is a long process...

If you use a second minidisk or SFS directory, you could get my COMPARE
package from VM's download lib at
   http://www.vm.ibm.com/download/packages/
it contains a COMPMDSK XEDIT macro to compare the contents of two
minidisks/directories:
- FILELIST * * sourcefm
- COMPMDSK targetfm
Then it is easy to find which files are missing/different..

Kris,
IBM Belgium, VM customer support

Reply via email to