[drmaa-wg] Another Argument for a DRMAA_ERRNO_UNSUPPORTED_ATTRIBUTE Error Code

[Daniel Templeton]

I believe the way we phrased it is that introspective languages, such as
the Java platform, will use explicit getters and setters. 
Non-introspective languages, like C, will use the general getter and
setter function from the original DRMAA spec.

Daniel

Roger Brobst wrote:

>========
>Regarding specifying unsupported attributes ...
>
>The C-lang and current IDL spec have provisions for
>handling both required and optional DRMAA attributes.
>
>The 3rd type of attribute, DRMS-specific, was intentionally
>not discussed in the C-lang binding spec because they do not
>impact the API.  From DRMAA's perspective they are simply
>attributes which are not named with the DRMAA_ prefix.
>
>Since the C-lang binding has the caller provide the
>attribute name and value, there is no linkage problem
>if the underlying implementation does not understand
>the DRMS-specific attribute.
>
>How does the current IDL spec support DRMS-specific attributes,
>keeping in mind that the end customer should be able to choose
>the DRMAA implementation leveraged by the ISV software ?
>Explicit getters/setters for each attribute would seem
>to be problematic (certainly from a linkage perspective).
>
>========
>Regarding the set of supported attributes changing ...
>
>I think the C-lang binding spec should document that the value
>output by drmaa_get_attribute_names (and 
>drmaa_get_vector_attribute_names) should be valid for the 
>lifetime of the drmaa session.
>
>
>-Roger
>
>
>In a previous e-mail, Peter Troeger wrote:
>  
>
>>>>I think you have correctly identified that the error codes
>>>>specified in the C-lang spec for drmaa_set_attribute() do
>>>>not adequately describe the situation when an attribute is
>>>>not supported.
>>>>
>>>>Should it ?
>>>>I did not locate any text in the spec which indicates that
>>>>it is an error to specify an unsupported (or unrecognized)
>>>>attribute.
>>>>On the other hand, I also did not locate any text which
>>>>indicates that unsupported attributes will be ignored.
>>>>
>>>>        
>>>>
>>>I think you just discovered a new tracker item. :)  It should be
>>>specified one way or the other.  Otherwise, DRMAA applications will not
>>>be portable across implementations.
>>>      
>>>
>>The current IDL spec seems to make a clear description:
>>
>>"In the job template there is a distinction between mandatory and 
>>optional attributes. A language binding implementation MUST provide 
>>implementations for all DRMAA attributes, both required and optional. 
>>The setter and getter implementations for optional attributes MUST throw
>>UnsupportedAttributeException in languages which support exceptions.  In 
>>languages which do not support exceptions, the optional attribute 
>>setters and getters MUST return some form of error.  The service 
>>provider implementation SHOULD then override the setters and getters for
>>supported optional attributes with methods that operate normally."
>>
>>and:
>>
>>"5.6.26 UnsupportedAttributeException: The given job template attribute 
>>is not supported by the current DRMAA implementation."
>>
>>In sum, it is specified to be an error if you use an unsupported 
>>attribute. If we have a new C-binding document, based on the IDL-spec, 
>>then everything should be fine !?
>>
>>    
>>
>>>>>(Caching the supported argument list doesn't help if
>>>>>the list can change during the lifetime of the DRMAA
>>>>>application, as is the case with SGE.)
>>>>>          
>>>>>
>>>... 
>>>You bring up an interesting point.  Should a job template be aware of
>>>such changes in the DRMS?  Right now, ours are.  I can easily see the
>>>point that a mutable job template is a moving target and could drive a
>>>developer nuts.  On the other hand, a job template may be very long
>>>lived.  We completely take away the control from the admin if we allow a
>>>job template to hold onto an environment that should no longer exist.
>>>
>>>Honestly, what makes sense to me at this moment is to specify the list
>>>of supported optional attributes as immutable for a given
>>>implementation.  In cases like ours, where our support of an attribute
>>>is dependent on the configuration of the DRMS, we should return
>>>something like DRMAA_ERRNO_DENIED_BY_DRM on job submission.  Thoughts?
>>>      
>>>
>> From the viewpoint of an application developer, I have a very bad 
>>feeling with this. I would never expect a change of the list of 
>>supported optional attributes, especially not during the runtime of my 
>>application. If the admin wants to do some reconfiguration, she is 
>>reponsible of considering still running applications. If you really 
>>think that this a useful feature at all, I would support the 
>>DRMAA_ERRNO_DENIED_BY_DRM suggestion. However, the spec really needs to 
>>make this explicit.
>>
>>Peter.
>>    
>>
>
>  
>

-- 
***************************************************
*        Daniel Templeton   ERGB01 x60220         *
*       Staff Engineer, Sun N1 Grid Engine        *
***************************************************
* "Roads? Where we're going we don't need roads." *
*                    -Dr. Emmett Brown            *
*                     Back to the Future (1985)   *
***************************************************