<br><br><div class="gmail_quote">On Fri, Apr 29, 2011 at 1:58 PM, John Rosenquist <span dir="ltr"><<a href="mailto:jrosenquist@adaptivecomputing.com">jrosenquist@adaptivecomputing.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 04/29/2011 10:26 AM, John Rosenquist wrote:<br>
> I've been looking at the job submission code and ran across something I find a bit puzzling.<br>
><br>
> When creating a new job id, the number is pulled sequentially from<br>
> server.sv_qs.sv_jobidnumber<br>
> This is used in creating the job id. (i.e. system_name.#)<br>
><br>
> Then the system is checked for a duplicate job name.<br>
> If a duplicate name is found in the old or new jobs, the job is thrown out of the system.<br>
><br>
> As the numeric portion of the id is defined by torque, is there a reason that we don't simply choose the next sequential number and check if it's available? (And so on until we find a valid ID to use)<br>
><br>
</div>To be more specific, I'm not including the condition where the job is from another server. This is just referring to jobs initially created in the req_quejob function.<br>
<div><div></div><div class="h5"><br><br></div></div></blockquote><div><br>if the job is originating on the same server, then the only case there would be a job ID conflict as far as I know is if the "next_job_number" is set in qmgr to a value <= a job ID that is currently in use. In that case I don't see the harm in just skipping over that number.<br>
</div></div>