A most useful mechanism (and much ignored) for controlling and communicating with PHANTOMS: LOCK n
e.g. A Phantom process starts up and sets (for example) "LOCK 1" to say it is running. If the lock attempt fails then the PHANTOM process is already running and it terminates. A controlling process wants to check if the PHANTOM is running - it tries to set "LOCK 1" and if successful releases the lock and knows that it is not running. If the lock IS set then the PHANTOM is running. When the controlling process wished to shut the PHANTOM down then it sets "LOCK 2" and goes into a loop (with limits and SLEEP2) and waits for LOCK 1 to be released: As part of its normal cycle the PHANTOM checks "LOCK 2" at intervals. If the lock is gained then it is released (no action). If LOCK 2 is set however then the PHANTOM unsets LOCK 1 and self-terminates normally under full control (no kills / logoffs etc). The controlling process detects the clearing of LOCK 1 (by trying to set it in its watching loop) and unsets LOCK1 and LOCK 2 - end (happy bunnies). If the PHANTOM does not terminate within a set period then you may choose to escalate to a force logout or try again..... ____________________ They same technique can be used for driving communications or application events, and if you have a LOT of processes so that the number of LOCKs available is insufficient then you can allocate pairs of locks dynamically (i.e. not hard-coded in the programs) from the pool available (default 1 -> 64). Just so long as the number of locks in use at any one time does not exceed the maximum number of locks available. Works Neat (if I say so myself) Well tried and tested (over 12 years running to my knowledge). Regards JayJay ------- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
