>>>I have a VFP app that calls a separate EXE COM server. The purpose of the COM server is to obtain and hold an FLOCK() on a production DBF or DBC file.
>>>
>>>Because it is in a separate process (and it must be a separate process, an in-process DLL COM server doesn't work), there is a possibility it could continue to run and hold an FLOCK() on a production table or DBC in the event of the main app crashing in the wrong place. Since the main app runs unattended 24/7, that would be a Very Bad Thing.
>>>
>>>I was thinking of including some sort of watchdog timer/deadman switch in the COM EXE, so it will commit suicide if the parent app doesn't exist or respond (?) within some reasonable amount of time.
>>>
>>>Ideas, anyone?
>>
>>I don't know if that helps you in your situation, but in a similar situation I did the following:
>>The main application creates a file every x minutes on a certain location. The called application that depends on the main application checks if that file exists, and if so, it evaluates the datetime of the create time of that file. If that file is older than a few minutes, the application knows that the crucial app is non-responsive or is not running at all and takes proper action.
>
>I too have used a disk file as a semaphore for non-COM interprocess communication. I'm wondering if, with COM available, there is another technique that is easier or more elegant.

I don't see a disk file solution as non-elegant, as long as it works. It's a matter of taste I think, but at the end what counts is how reliable the solution will be in practice.