Problems with file lock in Netsever

[Bob Larkin <blarkin@xxxxxx>]

We are experiencing weird problems with Netserver on a V4R2 machine. The
scenario is multiple NT desktops sending 1-4K files to a single share on
the AS/400. At the same time an NT server is polling the same directory
looking for files with a .RIP extension. If any are found, the NT server
will process them.

The NT desktop apps are VB programs. They create a file locally, then
use a FILECOPY dll to transfer the file to the Netserver share. Looking
at the process with a sniffer, the actual process at the IP level
appears as this:

1. PC starts FILECOPY
2. SMB request is passed to AS/400 to create and lock  file.
3. AS/400 responds with status OK, indicating the file structure has
been created. Lock is dropped.
3.  At this point, there is no lock on the empty file.
3A.
4. PC sends SMB request to open file and write data
6. AS/400 responds with OK status, file is once again locked.
7. PC transfers data, may take several frames. Lock is in place
throughout this phase.
8. AS/400 responds with status OK, and lock is released.
8A.
9. PC send SMB request to Get and Update File Information and locks file
again
10 AS/400 responds with status OK, releasing lock.

The problem occurs if the NT server attempts to read the file at point
3A or 8A. The NT server will get a lock. If the Desktop PC hits step 4
or 9 before the NT server releases the lock, the desktop PC's FILECOPY
will fail. The failure is shown in the sniffer trace as a file access
denied error, or a file sharing conflict.

At the same time, if the NT Server reads at step 3A, it will get a 0
byte (empty) file, so it will fail. If it reads at 8A, it will work.

I had the VB programmers change their code to write the file with a .TMP
extension from the Desktop PC. After the file was written, they now
rename the file to have a .RIP extension. This was done because the NT
server only reads files with a .RIP extension, although it is executing
DIR commands as a poll for files.

Anyway, in limited testing of this new flow, we are still getting file
sharing conflicts, during the rename operation. But we cannot see any
evidence of any process attempting to perform any function on the file.

sorry for the ramble, but has anyone else experienced similar problems?

Thanks,
Bob

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---