In [log in to unmask], [log in to unmask], <[log in to unmask]> writes: > How is the father suspending itself in the beginning? Are you > explicitly specifying the SUSP mask or relying on the default? Suspend(2); > Is the son checking bits 29:2 for the suspension condition? Maybe the > father isn't awaiting re-activation from the son??? Yeah. I Getprocinfo on the father in the son process, print out nasty messages if it's NOT suspended, then call activate, print out nasty messages if CC<>, THEN getprocinfo on father AGAIN to make sure it says it's now awake... > I had a problem like this (MPE/V) a _long_ time ago, and honestly I > don't remember what was causing it (other than stupidity, that is) but > I seem to recall that I wasn't explicitly telling everyone where to > look for re-activation. One of the things that makes me think it's a bug, is that I noticed already that from MPE/iX 4.0->5.0 when I called suspend(2) the Getprocinfo flags were WRONG (they showed 3 as I recall - waiting on either father or son). I had code which checked processes before activating them to make sure they were waiting on a Son to activate them (just in case), and that code all got blown out of the water on 5.0. (I'm cc'ing this to the list as well) For background; the father has MANY son processes hanging off of it. The father does a display before and after calling suspend(2) - I get the before display but not the after. Not every time, but often enough to be REALLY annoying. The son process also displays that it called Activate(0), got a CCE, and even calls Getprocinfo to make sure the father is now activated. (Which is really confusing, unless the father<->son pointers somehow got misdirected to some other process?) or the process' status is updated but its never really awakened...? I'm open for suggestions... -Chris Bartram 3k Associates