×
The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.
On 25 May 2012 10:38, David Gibbs wrote:
Any hints on how to analyze a job trace?
I've got a case where two jobs, that are doing the same thing on two
different systems, have a very significant performance variance.
On a 6.1 system the job runs rather fast ... on a 5.4 system it runs
quite slowly.
I think I know where the performance issue is ... but I need to
narrow it down.
I have a copy of the QAPTTRCJ file on my system ... but figuring out
what data is important is proving difficult.
Using job trace for performance issues is not generally a great
choice, and probably at times even less valuable on different releases.
As I recall, there is other tooling specific to performance; e.g.
Performance Explorer (PEX). For database queries there are the Database
Monitor, VE, index adviser, etc.
When using the Trace Job feature, I would tend to use the spooled
trace output rather than the database file output, to review the flow
and elapsed time in a formatted presentation. What I would do is find
matching processing in the flows of both scenarioos, then correlate
timings across each similar /phase/ of processing. If one phase appears
to be the source of the majority of time [from the slower scenario],
then I would try to further breakdown that phase in both scenarios,
possibly down to the individual programs and each of their timings in
both scenarios; still trying to identify one primary culprit for the
majority of the additional time, as shown by correlation of timings for
the same phase\program of processing in the two scenarios. In my
experience there is rarely just one specific part of the processing at
fault, so often such reviews are mostly fruitless endeavors.
FWiW: In trying to explain to people about the traces, I think the
biggest inhibitor in their understanding of the trace comes from a lack
of knowing what many of the OS\LPP "components" [and specific programs]
are and do, and even when knowing, failing to trust intuition about the
way the code should function, to infer better what is implied by the
presented flow [even if based upon a "guess"]. The features which use
procedure names generally make reading the flow easier; i.e. something
like seeing a procedure named AddMemberForCreateDBF would be clearer in
review, than making that inference from QDBCRTME appearing as a CALL
from QDBCRTFI.
Regards, Chuck
midrange.com
