Re: MINI DISK Corruption

[Kris Buelens]

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