Today I got all tests of the DRMAA test suite running. Therefore the current version of Condor DRMAA in CVS can be declared as ’somehow stable’. I am really happy about this major milestone, and must remark that this would never being possible without Nicholas Geib, who wrote 90% of the code before me. Unfortunately he is not reachabl at the moment, but I hope he reads the DRMAA / Condor mailing lists. I do my best to promote this stuff wherever I can.

Funny thing is that I never believed to get enough input for the GFD-E document from this implementation work. The situation now is the complete opposite – I will not be able to handle every detail in the report. If you want to have a good standard, implement it. More than once.

The only thing now left is support for “hostname:filename” style job template parameters. Condor supports file staging, but only for files that are situated on the submission host. Until now I see no generic way (beside Condor-G) to implement this DRMAA feature on-top-of Condor. Anyway I am wondering why this became a mandatory DRMAA feature in the past. Hopefully the group can agree about some solution.

The test suite has now capabilities to check �drmaa_wtermsig� support, which is new. It is not possible to build a portable check for �drmaa_wcoredump�, since your environmental setting decides if core dump files are created (check ulimit -a, change with ulimit -c).

I must leave also a comment about the programming strategy for software tools on-top-of Condor. In general there are two possible ways: Parse the log files, or parse the output of Condor tools. There is no official documentation of the Condor daemon protocols, so you always come out with such an ugly solution. The library does both things, since you are not able to fetch all you need to know from one source. For example, the log file on submission host does not contain information about jobs submitted in hold mode. On the other side, sometimes the job information after a state change (e.g. after condor_release) is updated later condor_q than in the log file. Since DRMAA-suspend and DRMAA-hold are both implemented with Condor-hold, you also need to consider internal state to interpret the Condor state the right way.