|
If F9 is used from the “Job Performance Summary” report with the cursor positioned on a job having used many resources, a report like the following appears. It shows for each HotSpot (date/time shown leftmost) amongst others the last 5 programs / modules in the call stack.
Most interesting is probably the pink line in the bottom, showing percentages for how often each program was active at a sample collection. Here we can see that QDBPUT (= unblocked writes) was found in 30 % of the cases, and QWCCCHVC in 25 %. But what is QWCCCHVS? Put the cursor on the name and hit F4, and the object text appears on the message line !
Some lines tell that call stack wasn’t available – this happens when the job works “below MI level”, typically when SQL or query is running. But the job function shows us for these lines that the query is building an index (spelling potential savings by creating a permanent index suitable for the query or SQL).
If we hit F14, data is generated to show the pink line totals in graphical form.
Looking at the program code, the data area updates (QWCCCHVC) appeared to be changes to the “Local Data Area” – the programmer thought that this would not cause writes to the disk. GiAPA could document that this assumption was wrong – around 25 % optimization was possible here just by using a core-resident User Space in stead of the LDA.
Furthermore we detected that we could force blocking when writing the output file, so QDBPUTM (M for multiple) would replace QDBPUT. All in all we could save around 3/4 of the elapsed run time documented here.
To get an analysis telling how often the different call stacks were found we put an * in the top of the above report and hit Enter. The result follows here:
We see that the call stack showed QWCCCHVS 30 times. Since QWCCCHVC is listed only once, it is always called by the same program. To see how the entire stack looks like, we position the cursor and hit F11 to get the next report shown:
Our program PAY381R did the data area updates in statement 43. GiAPA does not tell you “Change statement 43 from xxxxx to yyyyy” – but it sure shows exactly which statements within which programs use the resources. Programmers should have no difficulty in realizing that if that statement could be replaced by something more efficient, then ….
If the job is multi-threaded (typically JAVA), then call stack is not shown right away: We first have to select the thread for which we want to see the stack.
Thread 16 used by far the most resources, so we select that thread with a C for chronological, resulting in a report similar to what we saw above:
If we would like to see the results from the pink line as a bar chart, we hit F14 to prepare the data and request the chart from the GiAPA menu option 27.
(Programs being used less than 2 % is shown as group *OTHER.)
|
