Looking for VAXSET Software Engineering Tools for VMS 4.x
Malte Dehling
mdehling at gmail.com
Wed May 12 07:52:26 CDT 2021
(I had accidentally sent my reply below only to Antonio. I'm resending
it to the list.)
> On 10/05/2021 10:05, Malte Dehling wrote:
> > Thanks a lot, Antonio, these are very valuable to have!
> I've only checked a couple of them under SIMH, so it would be helpful to
> know if I need to check my workflow or not.
> > I think uploading them to archive.org would be a good long-term
> > solution. I can take care of it if you don't have an account.
>
> Please do. Thanks.
Will do. I'll let you know.
> In other news, I polished the MAR-1989 CONOLD, which looked very bad, to
> start with. Amazingly it buffed up quite nicely and then read surprisingly
> well:
>
> [
>
> $ ddrescue -r5 -v /dev/sr1 CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.iso
> CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.map
> GNU ddrescue 1.23
> About to copy 205199 kBytes from '/dev/sr1' to
> 'CDROM-AG-NC67A-RE-1989-03-VMS-CONOLD.iso'
> Starting positions: infile = 0 B, outfile = 0 B
> Copy block size: 128 sectors Initial skip size: 128 sectors
> Sector size: 512 Bytes
>
> Press Ctrl-C to interrupt
> ipos: 205198 kB, non-trimmed: 0 B, current rate: 0 B/s
> opos: 205198 kB, non-scraped: 0 B, average rate: 637 kB/s
> non-tried: 0 B, bad-sector: 2048 B, error rate: 170 B/s
> rescued: 205197 kB, bad areas: 1, run time: 5m 22s
> pct rescued: 99.99%, read errors: 25, remaining time: n/a
> time since last successful read: 2m 1s
> Finished
> ]
>
>
> So I went ahead and tried the CONDIST from MAY-1989. That too now can be
> read, although it is proving a somewhat tougher nut to crack:
>
> [
>
> $ ddrescue -r5 -v /dev/sr1 CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.iso
> CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.map
> GNU ddrescue 1.23
> About to copy 623247 kBytes from '/dev/sr1' to
> 'CDROM-AG-MN36D-RE-1989-05-VMS-CONDIST.iso'
> Starting positions: infile = 0 B, outfile = 0 B
> Copy block size: 128 sectors Initial skip size: 128 sectors
> Sector size: 512 Bytes
>
> Press Ctrl-C to interrupt
> ipos: 5919 kB, non-trimmed: 0 B, current rate: 0 B/s
> opos: 5919 kB, non-scraped: 11127 kB, average rate: 14694 B/s
> non-tried: 0 B, bad-sector: 2843 kB, error rate: 85 B/s
> rescued: 609276 kB, bad areas: 445, run time: 11h 31m 2s
> pct rescued: 97.75%, read errors: 5884, remaining time: 5d 23h 43m
> time since last successful read: 2m 45s
> Scraping failed blocks... (forwards) ]
>
>
> On the plus side, that's 97.75% more data than I had before :-) but the
> "remaining time" looks like it could be the rest of the week (it varies
> quite a bit).
>
>
> I think, from reading the manual, that I can use CTRL-C and restart this
> again later and it will pick up where it left off using the map file. Is
> this right?
Very nice, this worked much better than I had expected! And you're
right, you can simply CTRL-C and restart ddrescue with the same command
(i.e., with the iso and map file; different options should work.) I would
make a copy of the files before restarting, just in case.
> Are there any other options I should consider trying?
Can you try with "-b 2048 -d" for direct disc access and maybe once more
with "-R" for reverse?
> Another thought is that perhaps a shade more polishing might help. If I
> polish the CDROM a little more and then resume the ddrescue, I think I won't
> be any worse off than I am now, i.e. all existing data will still be there
> and all I'll be risking is data that maybe would have eventually read before
> but now may not read at all. Is that right? Successful reads are now ~20m
> apart, so I suspect that the remaining data will be quite difficult to
> recover.
After trying the various options on the disk in its current state, I see
no harm in trying this approach. With the map file, ddrescue should
never overwrite already-read data. Again, I would make a copy to be
safe.
Cheers,
Malte
--
Malte Dehling
<mdehling at gmail.com>
More information about the cctalk
mailing list