<br><br><div class="gmail_quote">On Fri, Apr 29, 2011 at 1:58 PM, John Rosenquist <span dir="ltr">&lt;<a href="mailto:jrosenquist@adaptivecomputing.com">jrosenquist@adaptivecomputing.com</a>&gt;</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>
&gt; I&#39;ve been looking at the job submission code and ran across something I find a bit puzzling.<br>
&gt;<br>
&gt; When creating a new job id, the number is pulled sequentially from<br>
&gt; server.sv_qs.sv_jobidnumber<br>
&gt; This is used in creating the job id. (i.e. system_name.#)<br>
&gt;<br>
&gt; Then the system is checked for a duplicate job name.<br>
&gt; If a duplicate name is found in the old or new jobs, the job is thrown out of the system.<br>
&gt;<br>
&gt; As the numeric portion of the id is defined by torque, is there a reason that we don&#39;t simply choose the next sequential number and check if it&#39;s available? (And so on until we find a valid ID to use)<br>
&gt;<br>
</div>To be more specific, I&#39;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 &quot;next_job_number&quot; is set in qmgr to a value &lt;= a job ID that is currently in use.  In that case I don&#39;t see the harm in just skipping over that number.<br>
</div></div>