[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ptp-dev] Questions related to batch job submission
|
On Jun 20, 2007, at 8:40 AM, Dave Wootton wrote:
Greg
We weren't planning to reimplement any LL function in PTP. A LL
user would
submit a multi-step job as a single command file containing the
specification statements to define the multi-step job. Our
implementation
for PTP would follow that model.
The question we had was related to the 'jobid' that the proxy fills
in in
each new job event it sends to the front end. There's a comment in
proxy_event.c that states that new jobs created in response to a
submit
command must fill in jobid with the jobid passed to the proxy in
the job
command. This works fine when the job command file specifies a
single job
step since when we query LL to get the job info, we only have a
single new
job event.
In the case of a multi-step job, there will be a single submit
command,
but when LL processes the job submission, it can result in multiple
new
jobs, where the number cannot be determined by parsing the command
file
(only LL knows the correct number of steps after it has parsed the
command
file as part of the submit process).
In the case of a multi-step job, as we generate new job events for
each
job step of the just submitted job, what do we use for the jobid in
each
event? It seems like we would generate the first event using the jobid
from the submit command and -1 for the jobid of the remainder of
the new
job events, but we're not sure that's right.
Sorry, I misunderstood your question.
The RM keeps track of each job submission, and compares the job
submission ID attribute against any new job event that it receives.
When it finds a new job event with matching job submission ID
attribute it completes the submission, then throws away the ID. If
the RM receives a new job event without a job submission ID attribute
(or one that has already been completed), then it simply adds the job
to the model.
The upshot of this is that you need return the job submission ID
attribute on a single new job event in order to complete the submit
command. You can then send unsolicited new job events with this same
job submission ID attribute and they will just be added to the model.
In fact, I suggest you do this since the job submission ID attribute
could then be used to show which jobs belong to the multi-step job in
the UI. Since both LSF and LL have these multi-step jobs, this would
be a nice feature to have.
Also, we have figured out how to recognize new jobs as they are
initially
submitted, so we are able to provide an immediate indication to the
user
that the job was submitted.
Cool.
Greg
