At 03:37 PM 23/06/2009, Craig Lalley wrote:
>--- On Tue, 6/23/09, Neil Armstrong <[log in to unmask]> wrote:

Craig,



> >
> > Funny I never received an enhancement request on this from
> > you!!!
>
>Now Neil, don't take it personal, you know I am not shy about asking 
>for things.  :-)

I wasn't taking it personally, the first version had a smiley, but I 
thought that customers wouldn't think I was serious about doing this. :)


>I always thought it was a management issue.  (To be very clear, I am 
>not management).

It is, but there is no longer many people to step up to the plate 
these days, so I feel our mandate for our products has become 
slightly wider in my opinion.


>If someone runs 20-30 SUPRTOOL jobs at one time, and half of those 
>are in the CQ, it's going to have an effect on performance.  Those 
>are VERY conservative numbers, BTW.  Don't get me going about the 10 
>years worth of archived data that is meaningless. (manifest and pick-lots).
>
>But if your open to it, I will start working on the details.  Let's 
>start with limiting it to 8 concurrent SUPRTOOL running at one 
>time.  The pause would be helpful for batch jobs, wouldn't the pause 
>also require CPU time?

Yep. But not as much as Suprtool / MPE file system stuff would take.


>Let the on-line run immediately and pause the jobs for say 60 
>seconds to look again.  I will double check the jobs to make sure 
>they are using the SUPRTOOL UDC.
>
>On a positive note, the nightly job processing took a huge leap 
>forward by adding "SET PREFETCH 0" in SUPRMGR.PUB.SYS.  Before the 
>addition, there would be about 30-50 jobs in queue in the 
>morning.  After the addition, the jobs are all complete by the start 
>of the business day.

Yep which is why I made it the default starting with Suprtool 5.1.The 
memory manager changed from 6.5 thru to 7.5 that Suprtool doing the 
prefetch was no longer of a benefit and possibly harmful on large 
memory systems.


>We could test the effects on the nightly or weekly job 
>processing.  The results would be quite interesting indeed.
>
>It's nice to know there are vendors out there that still believe in 
>the HP3000 platform and are willing to improve their product.
>
>The rest we can talk about offline.

You know where to find me. Either in my office or on my bike. :)

Neil





>Regards,
>
>-Craig
>
>* To join/leave the list, search archives, change list settings, *
>* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *