CURLER
asked on
CLIENT32 v2.5 DOS WINDOW FILE LOCKING
Netware 3.12 server, WIN 95 and DOS 6.22 workstations all running an Acucobol DOS Accounting application. WIN 95 stations DOS window freezes randomly but 6.22 stations run well. In tracing the problem I stumbled on NTEST386 that is a Clipper test module that can be set up to share a file from all stations. Diagnostics showed that file locking parameters go into orbit on the Win 95 stations. This might be a clue because at other sites with fewer clients and smaller files the errors do not occur. Locking was an issue before but Acucobol delivered a runtime update.
The network seems stable over the last couple of years with no file damage or abends at all. We have both a 10 Mb segment and 100 Mb segment and note that there are fewer freeeze ups under Win 95 on 100 Mb. NTEST386 running on only one win 95 station runs into file locks - presumably its own. I have contacted the author but he is 'on the road' until next week.
We could switch to Btrieve to get away from client locking but want to try other options first.
Any and all help will be appreciated.
The network seems stable over the last couple of years with no file damage or abends at all. We have both a 10 Mb segment and 100 Mb segment and note that there are fewer freeeze ups under Win 95 on 100 Mb. NTEST386 running on only one win 95 station runs into file locks - presumably its own. I have contacted the author but he is 'on the road' until next week.
We could switch to Btrieve to get away from client locking but want to try other options first.
Any and all help will be appreciated.
G'Day Curler,
Do you mind clarifying a few points for us.
This may sound silly, but are the files flagged shareable ?
You mentioned diagnostics and file locking parameters on the Win95 workstations. Which diagnostics and which parameters ? Are you talking about file locks on the server ?
What do you mean by 'NTEST386 that is a Clipper test module that can be set up to share a file from all stations'? What the hell is NTEST386? Are you sharing files from Win95 workstations using MS peer to peer networking ?
We recently moved a Btrieve based accounting system to Btrieve v7.0 and its pretty impressive when compared with earlier versions of Btrieve. If the client has the bucks and the application has the upgrade path then why wait ? The client will end up with a faster, more reliable system that can be backed up while their using it and you'll improve your skill set. Check out www.pervasive-sw.com for info on Btrieve 7.0, which is a component of Pervasive SQL.
Do you mind clarifying a few points for us.
This may sound silly, but are the files flagged shareable ?
You mentioned diagnostics and file locking parameters on the Win95 workstations. Which diagnostics and which parameters ? Are you talking about file locks on the server ?
What do you mean by 'NTEST386 that is a Clipper test module that can be set up to share a file from all stations'? What the hell is NTEST386? Are you sharing files from Win95 workstations using MS peer to peer networking ?
We recently moved a Btrieve based accounting system to Btrieve v7.0 and its pretty impressive when compared with earlier versions of Btrieve. If the client has the bucks and the application has the upgrade path then why wait ? The client will end up with a faster, more reliable system that can be backed up while their using it and you'll improve your skill set. Check out www.pervasive-sw.com for info on Btrieve 7.0, which is a component of Pervasive SQL.
There is a known bug in certain versions of Client32 (V2.11 and lower) that involves file locking. We had random "cross locks" on our cc:Mail system until we upgraded the client32.
You should also examine the NET.CFG and insure that TRUE COMMIT ON is set. This param tells the server not to "preacknowledge" write operations. This will slow down operations slightly, but increases data reliability.
M
You should also examine the NET.CFG and insure that TRUE COMMIT ON is set. This param tells the server not to "preacknowledge" write operations. This will slow down operations slightly, but increases data reliability.
M
ASKER
This is Client32 version 2.5 as patched and we have Cache Writes Off and File Cache Level set to 1. I will have to check True Commits but I have tried most options of most parameters - the
possibilities are too many. Are they all needed?
NTEST386 is a test program I downloaded that is designed to let multiple workstations share the same file located on the server. The file is created by NTEST386 and deleted when the last station running the module stops the execution of it. At the workstation it shows how often retries are required because records are locked. I don't have the source but it must be created shareable.
I don't agree that it is a clipper problem when the DOS stations report the occasional retry but the Windows 95 stations seem to be always retrying. I had several DOS and several Windows 95 stations running at the same time and recorded the diagnostic messages from the screen. If Windows 95 is trying to emulate DOS 6.22 it is not doing a very good job in this case. Where it causes us trouble is the default of 400 retries within the Acucobol runtime.
I have contacted the program's author and hope to get some more details from him early next week.
No server file corruption occurs other than the user counter in the file header does not get decremented by a graceful close.
possibilities are too many. Are they all needed?
NTEST386 is a test program I downloaded that is designed to let multiple workstations share the same file located on the server. The file is created by NTEST386 and deleted when the last station running the module stops the execution of it. At the workstation it shows how often retries are required because records are locked. I don't have the source but it must be created shareable.
I don't agree that it is a clipper problem when the DOS stations report the occasional retry but the Windows 95 stations seem to be always retrying. I had several DOS and several Windows 95 stations running at the same time and recorded the diagnostic messages from the screen. If Windows 95 is trying to emulate DOS 6.22 it is not doing a very good job in this case. Where it causes us trouble is the default of 400 retries within the Acucobol runtime.
I have contacted the program's author and hope to get some more details from him early next week.
No server file corruption occurs other than the user counter in the file header does not get decremented by a graceful close.
This may help in your case as it fixed a similar problem with running a 16bit Borland Delphi application on a 95 machine.
Start Control Panel and go into
SYSTEM | PERFORMANCE | FILE SYSTEM | TROUBLESHOOTING
Now check the box 'Disable New File Sharing & Locking Semantics', and you will have to reboot. Make sure you do this for EVERY Win 95 machine.
See what happens.
Start Control Panel and go into
SYSTEM | PERFORMANCE | FILE SYSTEM | TROUBLESHOOTING
Now check the box 'Disable New File Sharing & Locking Semantics', and you will have to reboot. Make sure you do this for EVERY Win 95 machine.
See what happens.
How's your troubleshooting going Curler ?
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Seems that this is a Clipper problem
Issue has been reported to Novell, but solution currently not available