Ian wrote:
> Hi All,
> just added two more processors to a machine, so doubling
> processing capacity.
>
> The run time for dayend processing has not changed though.
>
> The subsystem dayend is run in, has plenty of main storage
> allocated to it.
>
> In fact it's on calc and as dayend no users on system.
>
> Can anyone point me at what to look at, to see why no
> improvement in run time?
>
> Kind Regards
>
> Ian

Is the dayend single threaded i.e. one jobq or one job running programs
sequentially? If so, you won't benefit...

On Apr 21, 5:52 am, Ian wrote:
> Hi All,
> just added two more processors to a machine, so doubling
> processing capacity.
>
> The run time for dayend processing has not changed though.

It's hard to answer without significant insight into the processes but
there are many factors that affect job throughput and processing
capability is only one. If your jobs are very disk IO dependent for
instance, adding processors won't make a great deal of difference.
Analysing performance data should give a greater insight into the
bottleneck.

Nothing can correct poor DB design, bad code, or ill planned security.

--
Doug


"Ian" wrote in message
news:c72996c2-9a14-4076-bc8e-17c0526ced29@f63g2000hsf.googlegroups.com...
> Hi All,
> just added two more processors to a machine, so doubling
> processing capacity.
>
> The run time for dayend processing has not changed though.
>
> The subsystem dayend is run in, has plenty of main storage
> allocated to it.
>
> In fact it's on calc and as dayend no users on system.
>
> Can anyone point me at what to look at, to see why no
> improvement in run time?
>
> Kind Regards
>
> Ian

On Apr 20, 7:43*pm, gb wrote:
> Ian wrote:
> > Hi All,
> > * * * * just added two more processors to a machine, so doubling
> > processing capacity.
>
> > * * * * The run time for dayend processing has not changed though.
>
> > * * * * The subsystem dayend is run in, has plenty of main storage
> > allocated to it.
>
> > * * * * In fact it's on calc and as dayend no users on system.
>
> > * * * * Can anyone point me at what to look at, to see why no
> > improvement in run time?
>
> > Kind Regards
>
> > Ian
>
> Is the dayend single threaded i.e. one jobq or one job running programs
> sequentially? If so, you won't benefit...- Hide quoted text -
>
> - Show quoted text -

The dayend is single threaded.

On a development box did the same thing and dayend time halved.

Was not expecting improvement to be so drastic but was hoping for
something.

Thanks for input.

Kind Regards

Ian

Have you ensured that the processors have been enabled for your
partition and that the correct entitlements have been entered?

"Doug" wrote in message
news:480be423$0$9523$4c368faf@roadrunner.com...
> Nothing can correct poor DB design, bad code, or ill planned security.
>
> --
> Doug
>
>
> "Ian" wrote in message
> news:c72996c2-9a14-4076-bc8e-17c0526ced29@f63g2000hsf.googlegroups.com...
>> Hi All,
>> just added two more processors to a machine, so doubling
>> processing capacity.
>>
>> The run time for dayend processing has not changed though.
>>
>> The subsystem dayend is run in, has plenty of main storage
>> allocated to it.
>>
>> In fact it's on calc and as dayend no users on system.
>>
>> Can anyone point me at what to look at, to see why no
>> improvement in run time?
>>
>> Kind Regards
>>
>> Ian
>
>

On Apr 20, 12:52 pm, Ian wrote:
> Hi All,
> just added two more processors to a machine, so doubling
> processing capacity.
>
> The run time for dayend processing has not changed though.
>
> The subsystem dayend is run in, has plenty of main storage
> allocated to it.
>
> In fact it's on calc and as dayend no users on system.
>
> Can anyone point me at what to look at, to see why no
> improvement in run time?
>
> Kind Regards
>
> Ian

Ian, Look at the collection services file QAPMJOBWT, at V5R3 this
file contains 16 wait buckets, 16 fields for each wait time and 16
fields for each wait count. A description of each bucket can be found
in the file QAPMJOBWTD. You can query these files by job and see
exactly where your job(s) are spending a majority of their run time.
This will help you understand where the wait time is and why adding
the additional processors did not help. IBM also has another product
called iDoctor for iSeries Job Watcher that allows you to get even
more granular than what Collection Services goes. Job Watcher at V5R3
and higher maps these waits into a total of 32 different wait buckets
and 199 wait enums within these buckets. So you can really get a very
good view of the job(s) run/wait signature and where you need to focus
your analysis.
It was also mentioned in previous posts that CPU is only resource
where your job(s) could be spending time. I would also like to point
out that by just adding processors without upgrading the memory could
cause an imbalance and move the resource contention to memory.

Additional information on QAPMJOBWT can be found by searching info
center:
http://publib.boulder.ibm.com/infoce...v5r3/index.jsp
Additional information on Job Watcher can be found on the IBM iDoctor
website:
https://www-912.ibm.com/i_dir/iDoctor.nsf

If you still have problems or questions I would suggest opening a
software problem with your software service provider.

Regards,
Tom