Kris Buelens <[email protected]> wrote :- > You could use Q FILEPOOL CONFLICT to see wait conditions
> SFS guarantees read integrity, that is, if someone has a file in read, SFS keeps that image > of the file until the last reader closes it (this image is kept in shadow tables). > And -just tested- you can indeed ERASE the file while someone has it open. > The user reading it can just continue. > Maybe you can to stop using the lock files by using SFS CREATE LOCK commands Thanks, Kris, for your very helpful answer. Yes, the Q FILEPOOL CONFLICT is a good idea if I can catch it again. The last time it happened was at the weekend and I did not have any chance to investigate. Your information on the ERASE is great - that gives me a strategy (limited to one simple sub EXEC on the upload server (A) ) to overcome any potential conflicts. Yes, using the SFS standard locking mechanism would have been a good idea if I were starting from scratch but the code in Server B would need to be modified to deal with finding a lock in place. As it is, it will not start scanning the file if the code defined lock file is in place. I want to avoid any changes that are too widespread due to the sensitivity of the application (there are daily production logs). Thanks anyway. I now have a way to proceed. Colin Allinson VM Systems Support Amadeus Data Processing GmbH
