On further thought, perhaps I should be clearer. If you are saying that you
need to read the hostfile to display the cluster *before* the user actually
submits a job for execution, then fine - go ahead and call rds.query.
What I'm trying to communicate to you is that you need to call setup_job
whe
On 1/29/07 5:57 PM, "Greg Watson" wrote:
> Ralph,
>
> On Jan 29, 2007, at 11:10 AM, Ralph H Castain wrote:
>
>>
>>
>>
>> On 1/29/07 10:20 AM, "Greg Watson" wrote:
>>
>>>
>>> No, we have always called query() first, just after orte_init().
>>> Since query() has never required a job id b
Ralph,
On Jan 29, 2007, at 11:10 AM, Ralph H Castain wrote:
On 1/29/07 10:20 AM, "Greg Watson" wrote:
No, we have always called query() first, just after orte_init().
Since query() has never required a job id before, this used to work.
I think the call was required to kick the SOH into a
On 1/29/07 10:20 AM, "Greg Watson" wrote:
>
> On Jan 29, 2007, at 6:47 AM, Ralph H Castain wrote:
>
>>
>>
>>
>> On 1/27/07 9:37 AM, "Greg Watson" wrote:
>>
>>> There are two more interfaces that have changed:
>>>
>>> 1. orte_rds.query() now takes a job id, whereas in 1.2b1 it didn't
>>
On Jan 29, 2007, at 6:47 AM, Ralph H Castain wrote:
On 1/27/07 9:37 AM, "Greg Watson" wrote:
There are two more interfaces that have changed:
1. orte_rds.query() now takes a job id, whereas in 1.2b1 it didn't
take any arguments. I seem to remember that I call this to kick orted
into acti
On 1/27/07 9:37 AM, "Greg Watson" wrote:
> There are two more interfaces that have changed:
>
> 1. orte_rds.query() now takes a job id, whereas in 1.2b1 it didn't
> take any arguments. I seem to remember that I call this to kick orted
> into action, but I'm not sure of the implications of not
