Hi, We still have some comments on DRMAA specs: 1. The IDL version says that drmaa_wait(SESSION_ANY) should wait only on those jobs that were in the session up until the drmaa_wait call. The latest DRMAA 1.0 spec (June, 2007) doesn't mention it. I remember quite long discussion [1] where Daniel argued that this waiting semantics prevents some useful use cases. As I don't see any clear consensus in that discussion, am I right assuming that the IDL version has the final agreed semantics? 2. I remember asking questions about DRMAA semantics concerning the behaviour of drmaa_job_ps on finished (drmaa_wait'ed) jobs [2]. In the latest DRMAA 1.0 spec, in 3.1.2 it says: "Succesfull drmaa_wait() and drmaa_synchronize(), with dispose = true parameter, calls will make job id's invalid by reaping the job run usage data.". I think this is the only hint in the spec on what might happen to drmaa_job_ps on disposed jobs. In [2] Peter suggested adding something more clear but I can't seen anything like that in current docs. OK, so I firstly assume that the term "job run usage data" doesn't mean that only the "rsuage" structure used in drmaa_wait is disposed, but the whole jobid is from now on considered invalid, so that drmaa_job_ps returns INVALID_JOB. This term, especially with the next point 3.1.3 talking about "run usage data" with other meaning, is a bit confusing. But assuming I was right in the previous paragraph, how is one supposed to implement drmaa_job_ps which supports jobids from other sessions (or jobs submitted not using DRMAA at all)? When I call drmaa_wait, it disposes the job, so drmaa_job_ps now returns INVALID_JOB, but If I ask for the status in another session, it will return it happily. Is this how it's supposed to work? [1] http://www.ogf.org/pipermail/drmaa-wg/2006-June/000505.htm [2] http://www.ogf.org/pipermail/drmaa-wg/2006-May/000453.html -- Piotr Domagalski