>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?

What about having a timer in the EXE COM along with a HeartBeat method that resets it, something along this lines (not real code, just for illustrations purposes):

* Your EXE COM class:

define class myClass as Session OLEPUBLIC && Or whatever is your definition
	add object myTimer as Timer with Interval = 60000, Enabled = .f. && a minute
	
	procedure HeartBeat() as VOID
		this.myTimer.Reset()
		return null
	endproc
	
	procedure myTimer.Timer() as VOID
		this.Enabled = .f.
		quit && or something more graceful :)
	endproc
	
	** Your Procedure, which also enables the timer
enddefine

Then in your main program, assuming you have a loop of some kind going on, or a timer, you call HeartBeat() with a much higher frequency than the COM EXE's timer interval. The timer can be other than the foxpro timer if you think it might not work properly (Long time ago I used ccrpTimers for a COM DLL, but I think for an EXE the foxpro timer should work, right?