[Info-vax] analyze/disk errors

[tadamsmar]

On Thursday, December 5, 2013 1:45:58 PM UTC-5, hb wrote:
> On 12/05/2013 05:16 PM, tadamsmar wrote:
> 
> > ANAL/DISK gave me a this warning ANALDISK-W-MAPAREA on BADBLK.SYS and some other files.
> 
> 
> 
> I don't know what analyze/disk is checking and what makes it issue such
> 
> a "warning". If the map area is invalid or even corrupted as
> 
> help/message states, then you usually can not get away with copying the
> 
> file contents: the map area describes the disk blocks containing the
> 
> file data.

That's not what the VMS documentation says.  This thread is interesting in that I have never once got advice here that just flat out contradicts the documentation and yet it keeps happening in this thread.  Also I did what the documentation said to do and nothing happened that contradicted the documentation.

>Ask your friend backup to restore the "some other files".

Not sure what you mean. I restored all the files on the disk.
> 
> 
> 
> > ... So I tried to do copy it.  Copying worked on the other files, but I got an error when I tried to copy BADBLK.SYS....
> 
> 
> 
> Besides any map area problem, that's expected or the "nature" of
> 
> BADBLK.SYS: it contains/maps all the disk blocks which are not
> 
> guaranteed to be read. Mapping is done on the disk cluster base, so
> 
> there may be some good and some bad blocks. As far as I know, todays
> 
> disks do bad block replacement so, as long as that works, there should
> 
> not be real bad disk blocks in that file. But BADBLK.SYS may contain
> 
> "the end" of the disk. Consider a disk with 1000 blocks and a cluster
> 
> size of 3. Then BADBLK.SYS contains/maps one cluster, that is three disk
> 
> blocks starting at logical block number (zero based) 999. That's all
> 
> normal (no ANALDISK-W-MAPAREA) and expected as well as an error when
> 
> trying to copy such a BADBLK.SYS.
> 
> 
> 
> > So I made an image backup and restored the image from that backup and that cleared up the warning on BADBLK.SYS.
> 
> 
> 
> Because an image backup only contains the file header of the BADBLK.SYS
> 
> and a new BADBLK.SYS is created by backup when it restores the image
> 
> backup and implicitly initializes the disk (or by an explicit init
> 
> command if the restore is done with the /noinitialize).
> 
> 
> 
> And now, for fun, try to copy BADBLK.SYS to NLA0:. Any error?

Here's what I get on the system in question:

$  copy dsa0:[000000]badblk.sys nla0:
%COPY-E-READERR, error reading DSA0:[000000]BADBLK.SYS;1
-RMS-F-RER, file read error
-SYSTEM-F-ILLBLKNUM, illegal logical block number
%COPY-W-NOTCMPLT, DSA0:[000000]BADBLK.SYS;1 not completely copied

But don't get too excited, I did some more experiments.

But if I pop a disk out of shadow set DSA0: and I try it I get:

$  copy dka100:[000000]badblk.sys nla0:

in other words, it works for the popped out disk and it's the same file.

Also, I have 4 other system with shadowed disks and they all give that
same error when I try to copy dsa0:[000000]badblk.sys

Not sure what role badblk.sys has in a shadowset if any, but it's certainly not the same role is plays on a non-shadow set disk.