[DRMAA-WG] DRMAA2: Job Sub-State Discussion

Peter Tröger peter at troeger.eu
Wed Feb 18 12:05:06 CST 2009


Dear all,

this discussion thread is intended to finalize the job sub-state  
discussion from the last phone conference.

Quoting from the DRMAA2 Draft2:

"The jobStatus() method SHALL return the job status, together with an  
implementation specific sub state. This is intended to be a more  
detailed description of the current DRMAA job state, for example the  
specific kind of HOLD state (user-triggered, system-triggered). It   
MUST be allowed by the language binding to not retrieve this  
information (e.g. by passing a NULL value). Applications SHOULD NOT  
expect this information to be available in all cases."

Daniel T. did a great job in summarizing the current discussion  
status, which is about the data type for this sub-state information.

We have three alternatives: integer, string, or untyped struct /  
object pointer. All three constructs are expressible in IDL.

Strings require string comparison, which is only natural in scripting  
languages.
Integers might look inappropriate if the language supports native  
enumerations.

In all three cases, the returned information must be interpreted  
according to DRM-specific information (header file / type definition).  
This normally leads to a build dependency, e.g. in the form of DRM- 
specific string constants, numerical constants, or  type definitions.

In all three cases, moving a binary DRMAA application with sub-state  
usage to another DRM brings up a problem. With pointers, the  
application is likely to crash (ClassCastException, SEGFAULT). With  
integers, the application will perform wrong, since a wrong numerical  
match occurs. With a string, no match will occur in most cases, so the  
application will at least behave differently.

Last remark: For implementation-specific JT attributes, we have a  
lengthly discussion in the document of how to deal with DRM-specific  
data types (introspection, late binding). This can be counted as  
consistency argument for the object pointer approach.

/Peter.


More information about the drmaa-wg mailing list