Then we turned off oplocks and level2oplocks and found peace.
But sometimes the system until freeze in one station and this freeze others stations too.
When clipper system is closed in the first freezed station, the others return to normality.
This sounds like a locking issue. What locking related options do you have set in smb.conf?
Also consider the possibility of a network hardware issue (bad network card, bad cabling, bad hub). Test performance using a tool like a 'flood ping' on your Linux server to some of the problem clients. As root, run 'ping -f x.x.x.x' and see what percentage of packets (if any) are dropped after you let it run a little while. Press Ctrl-C to stop the test....
I use dBASE files that are several hundreds of MB's in size (total size of almost 1GB in about 8 dBASE tables). Application performance is acceptable on both 10BaseT and 100BaseTX LAN segments - although you can notice a difference on the 100Mbps segments certainly.
Locking options I use are:
locking = yes
strict locking = yes
share modes = yes
Note that you can turn off oplocks for JUST the DBF/MDX/NDX files using the 'veto oplock files' option in your smb.conf, on a per-share basis. For example:
[sharename]
veto oplock files = /*.DBF/*.dbf/*.MDX/*.mdx/
The softhouse that was developer clipper system say:
�
*�linux and samba is the problem
> he don't know nothing about linux
He is wrong on that point - I've been using Samba for dBASE file storage since 1994....
*�network bandwidth is the problem [100 and�10 Mbit/s]
> maybe ...
That depends on what type operations you are doing. I have seen decent performance on 10BaseT LAN segments for indexed lookups on DBF files that were 200-300MB in size. Writes can take longer though, as when you append a record, the index update may require rewriting the index file on the server.
* server is the problem [ Compaq ML330G2 : PIII 1GHz, 256, 18GB SCSI, 100Mbit/s�only file server for 33 clients ]
> I don't believe in this ...
The server is not an issue, as long as its disk performance is able to sustain the network bandwidth. CPU is usually not a factor. I have a dual PII-400 and a Pentium 100MHz still in active operation as Samba servers.....
�
Our major DBF has 65MB and the major NSX has 18MB.
I think that is big and the problem is it, �but system developer say that isn't.
It is big, but not too big. It really depends on how the application is written, and how it updates the data tables and indexes....
�
I don't want to come back to NT4, where the clipper system too crash.
�
Resume: Where I can find information about samba and clipper systems ?
Good luck - there will not be too much info. We migrated most of our DOS based clipper applications to C++ applications for DOS and Windows years ago..... Even in that environment, not too much developer support is available these days.
Good luck with your problem.
--
Jim Morris ([EMAIL PROTECTED])
