Shouldn't the controller be using the DEC STD 144 bad sector replacement table in the last sector to transparently remap bad sectors such that, to the user, the -DC packs appear error free? If this were done each RL02 image should appear error-free in logical block address space as the hidden remapping of bad sectors on -DC drives would not be seen by the user (or O/S). All the other proposed ways of handling -DC bad sectors have serious compatibility issues. Don On 4/6/2015 3:54 PM, Christopher Parish wrote:

On 06/04/2015 23:54, Christopher Parish wrote: Very good! I want one :-) DEC does it by having the driver software remap sectors. Eh? Use the existing bad block table which is on an RL01 or RL02, as on many other DEC disks. Return an error. Unless it's a block that's already in the bad block table at the end of the disk, in which case return the content of the remapped block, of course. If you don't do that, you'll break things in DEC OSs. There are several ways to detect or handle bad blocks in RT-11. I suspect you're thinking of INIT/BAD or more likely DIR/BAD, or possibly BACKUP or FORMAT. INIT is is the monitor command to create an RT-11 filesystem on a disk; the /BAD option (full name BADBLOCKS, can be shortened to as little as /BA) tells it to scan the disk and report any bad blocks it finds. With no other options, it creates directory entries for files called FILE.BAD covering those blocks. INIT/BAD:RETAIN keeps any FILE.BAD it finds, and in most versions doesn't actually scan. This is really meant for devices that don't have a DEC standard bad block table (like floppies). Alternatively INIT/BAD/REPLACE doesn't write FILE.BAD but instead updates the bad block table at the end of the disk; /REPLACE overwrites the table, whereas REPLACE:RETAIN adds to it. Note that the DL(X) drivers in RT-11, as in other DEC OSs, know about the bad block table. But of course you wouldn't use INIT just before making a backup ;-) And it wouldn't work if your controller lies and returns zeros for bad blocks; that would be a very bad idea and will cause things to fail badly. The SQUEEZE command compresses a disk by shuffling up all the files (except FILE.BAD) to be contiguous (RT-11 always writes individual files as contiguous blocks on disk but gaps between files can arise as things are deleted or rewritten). It honours the bad block table (and/or FILE.BAD), as do other disk utilities, because the drivers do that. If your driver doesn't, it'll fail. If you just want to quickly scan a disk for errors, a common way is to do COPY/DEV/IGN DLx: NL: which does a block for block copy of the entire disk to the NULL device, reporting errors but not stopping on them (/COPY/DEVICE/IGNORE). It's common to do that just after formatting a disk, but before INIT, for example if you're working with a non-RT-11 filesystem. BTW, for other COPY operations, it ignores FILE.BAD files, for obvious reasons, unless you specifically include them. You were probably thinking of the DIR command. /BAD is also an option to DIR; it can tell also you which files are affected by bad blocks. It scans the entire disk for bad blocks, and even works on non-RT-11 disks. If it finds any, it will report the block number in octal and decimal, and tell you if it's "Replaced" or "Replaceable" - ie if it's already in the bad block table - but it won't change the table for you. The full syntax is DIRECTORY/BADBLOCKS[/FILES][/START:n][/END:n]. /FILES will tell you what files are affected, assuming it's an RT-11 filesystem; /START and /END allow you specify a range rather than the whole disk. There's also a /WAIT option that pauses to let you change disks before scanning. BACKUP (or BUP) scans the target disk for bad blocks before copying a saveset to it (and stops if it finds any). You can't FORMAT an RL01 or RL02, but you can FORMAT/VERIFY:ONLY one. That writes patterns over the surface to test it, much more thoroughly than DIR/BAD, INIT/BAD, COPY/DEV or BACKUP. -- Pete Pete Turnbull