[drmaa-wg] reason for job abort : Tracker 309

Daniel Templeton Dan.Templeton at Sun.COM
Tue Feb 8 11:20:22 CST 2005


The opaque data approach has two big advantages: 1) It makes future 
changes easy, and 2) That's how the OO, Java, and .Net bindings do it.

Daniel

Andreas Haas wrote:

> On Tue, 8 Feb 2005, Roger Brobst wrote:
> 
> 
>>As described in
>>   http://forge.gridforum.org/tracker/?aid=309
>>it would be useful for drmaa to provide a mechanism
>>that an application can use to determine why a job
>>was aborted.
>>
>>The existing proposal is to add a string output argument
>>to drmaa_wait() that provides text information in
>>case drmaa_wifaborted()==true
>>
>>My counter-proposal is to introduce a new function
>>that can be called after drmaa_wifaborted()==true
>>to obtain the reason the job was aborted.
>>(Similar to how drmaa_wexitstatus() can be called
>> after dramm_wifexited()==true to obtain the
>> actual exit status)
>>
>>int drmaa_wabortreason(
>>    char* abort_reason,         /*OUT*/
>>    size_t abort_reason_len,    /*IN*/
>>    int stat,                   /*IN*/
>>    char* error_diagnosis,	/*OUT*/
>>    size_t error_diag_len       /*IN*/
>>    )
>>
>>We should discuss what the function should output
>>if the drmaa implementation does not have any
>>information about why the job was aborted.
> 
> 
> I agree this would fix the #309 problem. I doubt however
> it is possible to extract 'char* abort_reason' from
> a 'int stat'...
> 
> I think we need to introduce a new opaque datatype that is
> to be returned by drmaa_wait(). The new datatype would have
> to serve as a wrapper for stat, rusage and abort_reason and
> drmaa_wif* functions would simply operate on the new data
> type instead of 'stat'.
> 
> Regards,
> Andreas
> 





More information about the drmaa-wg mailing list