Looking for VAXSET Software Engineering Tools for VMS 4.x

Antonio Carlini a.carlini at ntlworld.com
Mon May 10 06:54:37 CDT 2021


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.


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?

Are there any other options I should consider trying?


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.


Antonio


-- 
Antonio Carlini
antonio at acarlini.com



More information about the cctech mailing list