Re: Interactive Response Time

[David.X.Kahn@xxxxxxx]

Richard wrote:

> I would start by setting the system value(s) relating to machine pool
> size, max active and a few others.  If you look in the work management
> manual there used to be a section on performance tuning, whereby pool
> sizes, faulting rates, and paging are explained.  You can really speed
> the system up by properly allocating memory in your subsystem
descriptions.

All good advice but hopeless in addressing the core issue, which is a
requirement that is as meaningless as it is ridiculous. Tuning up the
system is not going to prevent the odd long response time. It's as if the
CEO had decided that no company owned car should ever be involved in an
accident. You could ensure that the cars were serviced to schedule and shod
with the best tyres, that governors were fitted to prevent them going over
50 m.p.h. and all the drivers sent on advanced courses and given annual
medical checks. Your safety record might improve but occasionally there
would still be accidents. On the 400 you could have a background task that
cancels all jobs that have been waiting more than 25 seconds for a
response. It would achieve the stated goal (except when it itself failed)
but is probably not what the CEO had in mind.

I think Phil's approach of developing meaningful statistics and setting
tough but realistic goals is the only way to go. Make sure the CEO signs
off on the plan though.

Another point to consider is how you are going to measure response time. Is
it the response time shown in the AS/400 performance tools or that
experienced by the user on the network? These can vary widely.

Dave...
               _________  ,___o
             __________   _\ <;_
           ___________   (_)/ (_)       http://www.twickenhamcc.co.uk
=======================================================
The opinions expressed in this communication are my own and do not
necessarily reflect those of my employer.