I found there is a problem with some database program. When trying
to debug it, I noticed it calls DOS function 5c00 (lock), 59xx (get
extended error info), and then 4200 (seek) and 3fxx (read) in spite
there was an error. I traced it carefully, and found:
on 5c00 DOS returns error code 21h (C set) - OK
on 59xx DOS returns error code 0Ah, and strange extended info
- like memory failure rather than lock blocked occured
the application checks the error code and assumes locking is not
supported (or whatever we can assume - it is not told, but it
needs error code 21h to recognize "lock blocked" and retry).
This was with DosEmu 0.98.8. Then I installed the 1.001 binary,
and found the behavior did not change - the bug is still present.
Dos version used under DosEmu: MS-DOS 6.22.
I tried also DRDOS 7.03 (this which is free), when the lock was
blocked it returned some strange value in AX and _no carry_ - an
application would recognize it as "no error".
The same sequence on MS-DOS 6.22 with Novell client returns
AX=21h when the lock is blocked, and extended error checking
returns AX=21h (lock violation), BH=2 (class: temporary situation
- file or record lock), BL=2 (suggested action: delayed retry),
CL=3 (locus: network related), which all seems to be reasonable.
This is correct behavior, and I would like to see same on DosEmu.
The bug causes the database application cannot be used on many
stations simultaneously since record locking does not work, and
data integrity is not protected in any way.
Jerzy Tarasiuk
