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

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].