CPM3 random read bug

[retrogear]

I did work decades ago bringing up CPM 3 on an Epson QX-10. In recent years I purchased that computer once again and now am looking at my work.
I am amazed how far I had gotten. It seems very solid. I had detailed notes on paper which had been discarded so was taxing my memory about what had been done.
In my searches online I have come across references to a random read bug. This paragraph was actually from a thread I started back in 2013 on comp.os.cpm:

What would be useful is a permanent fix for the DRI CP/M 3 random-read bug - which
DRI was informed about but never addressed (?). An RSX that works around the bug
can be found in CPM3BUG.LBR
http://archives.scovetta.com/pub/walnut-creek/BEEHIVE/TESERACT/TESS-047.ZIP
Text explaining when/why the bug occurs is included with ZPM3 - but sadly no detail
as to how they fixed it.
A simple executable which tests whether you have the random-read bug is here:
http://dxforth.webhop.org/rrbug.zip

The links have since gone dead. I would like to have a program that would test if that bug is present. I know there were several y2k patches but I don't care about those,
I can live in the past I would like to see if the RSX mentioned would attach to my system and fix it. I actually have a Walnut Creek cdrom disk.

Larry G

 

[GeoffB17]

I don't know if I ever heard about this bug, however I've been using CP/M 3 on Amstrad PCW machines for a long time and never noticed anything.

However, you refer to 'CP/M 3', but I understand that there was actually a version 3 (i.e., I assume, version 3.0) but there is also a version 3.1 which I believe is the version supplied with the Amstrad machines. Is it possible that 3.1 does in fact 'fix' the bug you refer to?

Geoff

 

[JohnElliott]

Your first link is on the Walnut Creek CP/M CDROM, of which copies can be found online -- for example, there seems to be a link to tess-047.zip at http://cpmarchives.classiccmp.org/cpm/Software/WalnutCD/index_dirHTML.html

Reading the description of the bug, it is triggered only in a fairly narrow set of circumstances: when there are two successive reads to records that haven't been written. These should both fail, but the second one wrongly reports that it succeeded. So it's quite possible to have used CP/M 3 for a long time, and if you didn't use a program that had that particular access pattern you might well not have noticed the bug.

 

[retrogear]

The version call 12 returns 31h and I see the string embedded in cpm3.sys is 'COPYRIGHT (C) 1982, DIGITAL RESEARCH 151282'. Would that be v3.1 ?
Anyway that's why I would like a test. Thanks John, that;s a nice index. I downloaded CPM3BUG.LBR and just browsing with a hex editor it looks like it has rrbug.mqc and RRF.MQC now if I can remember how to de-lib and unsqueeze ...

Larry G

 

[retrogear]

Well I tried the random read test RRBUG.COM reading the test file on my cpm3 with occasional error codes even after applying the RRFIX.COM RSX. I got the same results with MML CPM+ so nothing proven yet.

EDIT: I tried it on simh emulator running CPM 3 with the same errors

Larry G

 

[durgadas311]

...
Reading the description of the bug, it is triggered only in a fairly narrow set of circumstances: when there are two successive reads to records that haven't been written. These should both fail, but the second one wrongly reports that it succeeded. So it's quite possible to have used CP/M 3 for a long time, and if you didn't use a program that had that particular access pattern you might well not have noticed the bug.

This sounds vaguely familiar, as if I might have heard a discussion of this at a Digital Research Training/Conference session. But, I don't have any independent memory of the details.

This description though does not sound like anything a "normal" random access file program would do. Typically, a program accessing a file randomly will only read records that it knows exist. and if a read did return an error, it would not continue trying to read (and probably not even continue execution). I think that is why Digital Research chose not to fix it - coupled with that fact that CP/M 3 was the end of their 8-bit offerings and they did not want to do an update for this sort of thing (and I'm guessing the fix was not something that could be easily patched).