Kris Buelens wrote:
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
I must agree with Kris. I have filled many disks to 100% over the past
30+ years and have never seen that cause corruption. His solution is the
only way, short of reformatting and restoring from a good backup, to
solve the problem.
