Hi Matthieu. I think it might be useful to think of a drmaa_job_template as a table of name-value pairs. You ~could~ implement this table as an array of names and an array of values, where the value of associated with attr_names[i] would be stored at attr_values[i]. Other implementations might be a hashTable or a linked list of: struct attr_s { struct attr_s *next; char *name; char *value; }; (For simplicity, I'm ignoring that there are string-valued attributes and stringVector valued attributes) Since the specification does not indicate an interface to obtain an array of attribute names associated with a specific job template, there isn't a particular benefit to implementing the table as two parallel arrays. Note, however, that the spec does indicate a drmaa_get_attribute_names interface to obtain the attribute names associated with the DRMAA implementation ... this is not on a per-template basis. You mentioned drmaa_get_next_attr_{name,value} functions ... I did not locate them in the drmaa C binding document. The end-user is not "condemned to use alternatively get_next_name and get_next_value functions to be certain he gets the proper value for the proper attribute name?" The drmaa_get_attribute routine accepts the attribute name and output the corresponding value from the template. You are correct that each successful call to drmaa_set_attribute(drmaa_job_template_t *jt, const char *name, const char *value, char *error_diagnosis, size_t error_diag_len); would modify an existing table entry, or add a new table entry. -Roger In a previous e-mail, Cargnelli, Matthieu wrote:

Hello,

Sorry for these questions that will probably look a little dumb, but I just can't figure it out. I hope this is the right place to ask these questions...

I'm trying to write a DRMAA C binding for Torque/OpenPBS. I've read the drmaa C binding documents and some of this mailing list archive, but couldn't find an answer.

I was defining a job_template structure containing the necessary strings, something like this: struct drmaa_job_template_s { char* drmaa_remote_command; char* drmaa_js_state; char* drmaa_wd; [...] };

But eventually I thought that it would rather be something like: struct drmaa_job_template_s { drmaa_attr_names_t* _attr_names; drmaa_attr_values_t* _attr_values; [...] }; that should be implemented (at least that would justify the opaque string vectors).

Could someone please shed some light on this matter please? I'm really unable to find that information anywhere.

Besides, what are we supposed to put in the opaque string vectors if the first case apply?

In both cases how are we supposed to make the relation between the attr_name vector and the attr_value vector? I suppose these actually contain pairs of value. But as they can only be accessed by drmaa_get_next_attr_name and drmaa_get_next_attr_ value functions, is the user condamned to use alternatively get_next_name and get_next_value functions to be certain he gets the proper value for the proper attribute name?

Finaly, that leads to the function: /* * Adds ('name', 'value') pair to list of attributes in job template 'jt'. * Only non-vector attributes may be passed. */ int drmaa_set_attribute(drmaa_job_template_t *jt, const char *name, const char *value, char *error_diagnosis, size_t error_diag_len);

If I'm correct, this function would add (or modify) one element to attr_name and one to attr_value string vectors... Or am I totally wrong about it ?

Sorry for such a bunch of questions.

Regards

Matthieu Cargnelli