Thanks for your comment. You really found one of the crucial issues with API support for job suspention. This feature 
always demands some support from either the application or the operating system. We wanted this feature in the API, even
 if the underlying system does not really supports it.

We ended up with the argumentation that DRMAA is a pure API specification, with a state model reflected in the API 
functions. Therefore, as long as the API interface behaviour confirms to the DRMAA state transition model, it is not 
important how the implementation fulfills this promise. The resume operation in the Condor vanilla universe restarts the
 job, but also ensures that the job is running again when the call returns. This fulfills the API promise, meaning that 
the job has to return to running state after the resume call. 

There are scenarios from the Condor guys telling that this behaviour is quite ok. The application catches the 
cancellation signal, and performs its own checkpointing before terminating. After the restart, it detects the own 
checkpointing state and recover by itself. This leads to the expected behaviour, even though the operating system, the 
cluster system and the DRMAA implementation performed a job cancellation.