Thinking about it a little further, I can see where you might have wanted the spec to say that, but I don't think it's clear. The spec says that all calls subsequent to a *successful* call get an error. In the case below, neither is successful until step three, and then it's arguable as to whether the second call is subsequent to the first call's success or not. Regardless, my point is that we need to make it clear in the spec, whatever we decide it should say. So, is there a reason why the spec is supposed to say that two concurrent calls can't both succeed? That sounds very limiting, and I completely fail to see the advantage. You can't tell me that it's for ease of implementation, after the weeks of work I put into implementing the PartialTimestamp class. Memory issues for large number of submitted job situations led us to specify reaping only once semantics. Hrabri Daniel