(Un)Locking shared DOS application

[Frans Stekelenburg]

Hi,

for some time now I'm trying to create the best environment/solve a
sharing conflict around a DOS application (Clippered dBase I suscpect)
that one of our clients is using and distributing over about 20 Sun
450's on a shared service 'servershare'.

On every Sun there are multiple Windows 95 clients connected to diverse
shares amongst which this 'servershare'.
On this share they have a DOS application, which they insist on using it
in a multi user mode- although the thing itself (probably/obviously)
lacks multi-usage capabilities.
It's actually a 'data-retrieval' application, it's used to lookup data
that comes from one of it's other files that is distributed and
refreshed daily. Nothing get's written, except printer output files and
at the end the config file.


At the beginning the share was already configured with 'locking = no' to
avoid others from not beeing able to start the batch file and other
files that are needed for the whole app.
But since this was not sufficient for the multiusage of the application
we had to go as far as defining 'share modes = no', thus the share modes
that are disabled by this option are DENY_DOS, DENY_ALL,  DENY_READ,
DENY_WRITE, DENY_NONE and DENY_FCB.

That made the application usable in a multi-user environment.
But major downside  of this is that for just this application the WHOLE
SHARE is now in the unwanted modus of having no locking whatsoever going
on....



The next problem now is that for untraceble reasons, the majority of
users complaint that most of the time if they want to print from the
application that they can not, and some message appears that they can't
write/access the directory where the print files are written.
Now of the about 20 servers I have two without any complaints, and of
the rest most users do complaint of these problems occurring.

Since a lot of branches have are connected through an ISDN connection to
one of the 20 main locations, I figured that maybe because of some time
out problem they loose print or share connections. (The Helpdesk HAS
informed me that often they see the mappings 'red-crossed' but when they
'click' them, they disappear and all is functioning fine.)



Right now I'm at working on a work around to isolate the application
into a separete share, with the needed settings, and to lift the lack of
locking of the main share. So 'locking=no' 'fake oplocks=yes' 'share
modes=no' are one this separate share for the application.
Since they all share the same files, I went further by making the new
share 'book', a 'virtual environment' of the application.
Instead of mapping it directly to the Unix location, I dynamically
create a (temp) directory and in there  two directories like in the base
of the application. Then I SYMLINK all the (necessary) files from the
BASE into this VIRT directory, and only copy the config file (is
written).
This because I was hoping/guessing that instead of locks getting set on
the MAIN files, they are set on the links...
But no, I still need to set 'share modes=no' to avoid a locking problem
on the new share/drive.


So I'd like to know two and a half things, beside if anybody else has
experience in sharing apps like this:

- Is the locking as I had to use, as designed- or are there better ways
to do this?

- Is there a know problem with Windows 95 clients and printing/mapping
problems, especially over slower lines?
   Are there maybe tunable time out options?

and the applepie question: Might there be another better way to make
this application shared (without copying 30MB 20 times)...?



I could use all the help on this one!

Environment:
- Samba version 1.9.18p10 (+ LDAP 'hack')
- Sun Solaris 2.6
- Windows 95 clients, some from LAN, majority through ISDN WAN locations



Kind regards,

Frans Stekelenburg