TomLiotta   15455 pts.  |   Nov 21 2009  12:07AM GMT

It probably depends on how much and what kind of performance tuning has been done previously to your system. How many memory pools do you currently run with during a normal day’s workload? And how many jobs would be actively running in *BASE on average under normal workload? (Including TCP/IP servers, host servers and everything else.)

Those questions are only meaningful in order to get a feeling for how far any previous performance tuning might have been done.

Tom

Philpl1jb   25660 pts.  |   Nov 21 2009  11:30AM GMT

I don’t believe there is a limit to the number of connections.
I think tom is referring to the performance when you start doing stuff though all those connections.
Phil

TomLiotta   15455 pts.  |   Nov 27 2009  7:30AM GMT

I think tom is referring to the performance when you start doing stuff though all those connections.

Yes, that’s part of it. Mostly, performance analysis comes down to interpretation of measurements. Interpretation involves a set of assumptions that may or may not be true. The ‘truth’ values can be set correctly by some initial actions that are based on understanding what various performance measurements mean.

The fundamental starting point is with the initial system from IBM. It comes with a bunch of default values, all of which may be changed to adapt the system to a company’s needs. Most are never changed even though they should be. IBM assigns default values that allow the system to handle essentially any kind of workload. But it’s impossible to have a large set of default values that will all work well. “Working” isn’t the equal of “working well”.

Further, the default settings effectively make meaningful performance measurements impossible. They also make some performance features of the system ineffective. The QPFRADJ system value, for example, is largely useless as long as most work management attributes remain at their default settings.

In short, if the system hasn’t been prepared for performance measurements, then measurements will be meaningless at best and actually misleading in many cases.

Various changes can be made to SQL statements to make them work better. Other changes can be made to the database structures to make SQL statements work better.

But there are many changes that can be made to the system itself to make the entire system work better, including measurements. If the system itself is tuned and it can give precise info about how it’s running, extra stuff like tweaking SQL statements becomes almost obvious.

Tom