<br><br>
<div class="gmail_quote">On Feb 2, 2008 10:57 AM, Glen Beane &lt;<a href="mailto:glen.beane@gmail.com">glen.beane@gmail.com</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><br><br>
<div class="gmail_quote">
<div>
<div></div>
<div class="Wj3C7c">On Feb 2, 2008 4:36 AM, Garrick Staples &lt;<a href="mailto:garrick@usc.edu" target="_blank">garrick@usc.edu</a>&gt; wrote:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div>On Sat, Feb 02, 2008 at 02:45:51AM -0500, Glen Beane alleged:<br></div>
<div>
<div></div>
<div>&gt; I&#39;ve just checked in some changes into trunk that increase the PBS_JOBBASE<br>&gt; constant from 11 to 61. &nbsp;This allows for 64 char .JB and .SC files on<br>&gt; pbs_server/pbs_mom<br>&gt;<br>&gt; the previous 14 char limit was too small when you combine large job sequence<br>
&gt; nubmers and large job arrays - we just couldn&#39;t hash those 11 characters<br>&gt; enough to make the neessary number of unique file names.<br>&gt;<br>&gt; This should help the job arrays scale much better.<br>&gt;<br>
&gt; .JB files with the old size for their jobbase array are automatically<br>&gt; upgraded when pbs_server starts<br>&gt; we used a similar auto upgrader from 2.1.x to 2.2.0. &nbsp;the only down side is<br>&gt; if you upgrade to 2.3.x you wouldn&#39;t be able to recover your jobs if you<br>
&gt; downgrade back to 2.2.x (they will be renamed as .BD files I think)<br><br><br></div></div>If we changed:<br>&nbsp;if (version == 0x00020200)<br>&nbsp; &nbsp;{<br>&nbsp; &nbsp;return &nbsp;upgrade_2_2_X(pj, fds);<br>&nbsp; &nbsp;}<br>&nbsp;else<br>&nbsp; &nbsp;{<br>&nbsp; &nbsp;return upgrade_2_1_X(pj, fds);<br>
&nbsp; &nbsp;}<br>&nbsp;}<br><br>To something like:<br>&nbsp;switch (version) {<br>&nbsp; &nbsp;0x00020100: upgrade_2_1_X(pj, fds);<br>&nbsp; &nbsp;0x00020200: upgrade_2_2_X(pj, fds);<br>&nbsp; &nbsp;default:<br>&nbsp;}<br>&nbsp;return;<br><br>Then we could get upgrades from any point in the past to the current struct?<br>
</blockquote></div></div>
<div>this would work:</div>
<div>&nbsp;switch (version) { 
<div class="Ih2E3d"><br>&nbsp;&nbsp;&nbsp;0x00020200: upgrade_2_2_X(pj, fds);</div></div>
<div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; break;<br>&nbsp;&nbsp;&nbsp;default:&nbsp; upgrade_2_1_X(pj, fds);<br>&nbsp;}<br>&nbsp;return;</div>
<div>&nbsp;</div>
<div>there is no version 00020100 - there was no version number in the ji_qs struct at that point.</div>
<div>&nbsp;</div>
<div>upgrade_2_1_X upgrades anything from 2.1.X and earlier (I chose version numbers that couldn&#39;t match the first int in the old ji_qs struct without a version) to the new 00020300 version.</div>
<div>&nbsp;</div>
<div>upgrade_2_2_X goes from 00020200 to 00020300</div>
<div>&nbsp;</div>
<div>you don&#39;t need to call both upgrade funcs<br></div>
<div>&nbsp;</div>
<div>&nbsp;</div></div></blockquote></div>
<div>&nbsp;</div>
<div>by the way,&nbsp; I did test upgrading 2.1-fixes -&gt; trunk and 2.2-fixes -&gt; trunk<br></div>