We are using MS-DOS 6.22 running under DOSEMU 0.98.8 on Red Hat Linux 6.1 (kernel version 2.2.12-20). The PC is an Intel Pentium 233MHz with 64 MB RAM. DOSEMU boots MS-DOS from a native msdos partition on a linux machine (Server1). We use DOSEMU to run a DOS accounting database application written in Clipper (which is a dBase III compiler/IDE). The Clipper executable also resides on the linux msdos partition on Server1. We use the DOSEMU program lredir.exe to create a network drive 'D:'. The network drive 'D:' points to a SAMBA share '/mnt/remote_D' mounted on the linux filesystem tree of Server1. The SAMBA share is mounted from another linux machine (Server2) on the network which hosts the database files needed by the Clipper executable residing on Server1. The database files are located in a native msdos (actually a vfat) partition on Server2. The database files on Server2 are accessed by other copies of the Clipper application running in DOS sessions on Windows 95/98 workstations on the network. Many users are reading and writing to the shared database files residing on Server2. Each separate copy of the Clipper application uses the DOS program share.exe to control file sharing of the common database files. Remote users telnet to Server1, start a DOSEMU session and launch the Clipper application. They read, write, lock and unlock the shared database files residing on Server2. These same database files are being read, written, locked and unlocked by other copies of the same Clipper application running on the Windows workstations. The Clipper executables running on the Windows workstations perform their file operations correctly... there are no problems or conflicts. However, when the telnet users of the Clipper application connect to the database files under DOSEMU, there is a problem. The copies of the Clipper application running under DOSEMU do not seem to recognize that another copy of the Clipper application has incremented a counter in a database file: the results are duplications of batch/transaction identifiers. We end up having two batches with the same transaction identifier, and the contents of one batch get overwritten (in part) by the second batch with the same identifier. We think this might be a bug in how DOSEMU passes file sharing requests from 'real' DOS (or from share.exe). Is there a patch or fix for this? Can you help us at all? Any assistance you can provide would be most appreciated. Thank you in advance for any help you may be able to offer. Greg LaBossiere Xview Solutions Inc. Information technology consultants Computing Innovations for eBusiness mailto:[EMAIL PROTECTED] http://xview.com
