Misused Resources

Performance problems are not necessarily caused by inefficient programming - users misusing the resources is an often seen problem. Here are just 2 frequently seen cases shown:

Very long response time

In the first example the standard "Job Performance Report" was sorted descending on the longest response time experienced.

The last column shown (Trans or JobQ Time) has for interactive jobs two values: The total transacction time, and the maximum response time experienced. The first user had a total of 283 transactions adding up to 1 hour 33 minutes, and the longest response time was 1 hour 22 minutes - indeed excessive.

But by placing the cursor on the job and using F10=Details (not shown here) we could see when this long response time occurred, and using F9 we could see how the call stack looked during that time. It appeared to be a very large Query, which the user of course was not supposed to run interactively.

 

Too many transactions

In the second example, the standard "Job Performance Report" was requested sorted descending by the highest number of transactions per interval. The result was astonishing: One user had managed 368 "transactions" within one 15 seconds data collection interval. This called for an investigation.

Using F10=Details showed us when this happended, and F9 could then be used to check the call stack for that interval. It showed that the CL-command WRKSYSACT had been active - the user had kept the finger on the F5=Refresh from a PC-keyboard with automatic repeat function. This was indeed misuse of resources!

If we would like to see a chart showing users with a (too) high number of transactions, we only need to position the cursor on the last user name which should be included and then hit F14. This will generate the input data needed for the bar chart overlaying below report example. As values for the chart GiAPA will automatically use the report sort criteria, which here was maximum number of transactions.