wise advice.

Would it be correct to assume that QAYPEPROCI contains the complete list of
all called programs?

Best regards
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno mar 14 apr 2026 alle ore 22:22 Dawn May <dawnmayican@xxxxxxxxxxx>
ha scritto:

As this post below notes by the example SELECT statement, STRTRC uses PEX
under the covers to collect the data (QSCNTRC PEX definition).
You can use WRKPEXDFN to see how this definition is set up. (No display
option, but the change option should show the parameter specifications).


Querying the PEX files directly is not for the inexperienced and IBM
doesn't document PEX files.
IBM also does not document the values for the various parameters on
ADDPEXDFN - they used to, but they haven’t for quite some time - I have
found some old documentation on the Internet Archive.


Rather than using SQL, consider using the PRTPEXRPT on the PEX collection
from the STRTRC. That will produce a spooled file, but it is vastly
condensed compared to the PRTTRC output.
Order by timestamp and you’ll see the program / procedure call flows. You
can also direct the output of PRTPEXRPT to an output file.

Note that with STRTRC, you get the actual flow of all programs/procedures
that are called.



If you just want to know what programs are used, but do not necessarily
care about the flow, there are additional options.

PEX *STASTICS can give statistical information about the programs called,
such as the number of invocations, inline and cumulative CPU usage, I/O
etc. This can be useful if the objective is to identify which programs are
using the most resources.

Be aware that PEX *STATS has quite a bit of overhead during data
collection if you have a lot of ILE programs, so use caution. It’s probably
ok to do in a test environment, but please don’t in production.


If the objective is to find which programs/procedures are using the most
CPU, you could use a PEX *TPROF collection. IBM has some documentation on
this here:
https://www.ibm.com/support/pages/node/685721
You can use PRTPEXPRT to review the data. Navigator for i, Investigate
Data as some support for Performance Explorer TPROF data.


Finally, IBM iDoctor has a PEX Analyzer component. It can be useful for
helping collect the PEX data as well as analysis. But if you’ve not used
it, it would probably be overwhelming.
It is a paid product, but IBM offers trial licenses (typically for 45
days).

Dawn



On Apr 13, 2026, at 1:56 PM, Marco Facchinetti <
marco.facchinetti@xxxxxxxxx> wrote:

Create a library (I.E. TRACELIB) to store the trace and then a small CL
like this one:


STRTRC SSNID(*GEN) JOB((*)) MAXSTG(100000) JOBTRCTYPE(*FLOW)

CALL PGM(MYLIB/MYPGM)

ENDTRC SSNID(*PRV) OPTION(*END)
DTALIB(TRACELIB) PRTTRC(*YES)

If the batch program is not too long (otherwise you can increase the value
in MAXSTG but there is a limit) you'll find a printout with everything the
batch program has done. Convert it to text and filter it, excluding
everything system-related from the calls (Library beginning with Q).

Alternatively you can use the files produced in the TRACELIB library but
you should consult the documentation, an example could be:

SELECT a.QRECN,
a.QTBTBT,
a.QTBHLL,
a.QTBCHL,
a.QTBEVM,
a.QTBCLL,
b.QPRPGN,
b.QPRPQL,
b.QPRTY,
b.QPRSTY,
b.QPRPMD,
b.QPRMNM,
b.QPRMQL,
b.QPRPNM,
b.QPRLNG,
b.QPRPSP,
b.QPRPTI,
b.QPRPFT,
b.QPRPTC,
c.QTITSP,
c.QTITIMN,
c.QTIECY
FROM tracelib/QAYPETBRKT AS a
JOIN tracelib/QAYPEPROCI AS b
ON a.qtbtbt = b.qprkey
AND SUBSTR(b.QPRPQL, 1, 1) NOT IN ('Q', ' ')
JOIN tracelib/QAYPETIDX AS c
ON a.qrecn = c.qrecn;

Not tested or guaranteed, it is definitely safer to use the spool file.

HTH

--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno lun 13 apr 2026 alle ore 19:25 gio.cot via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> ha scritto:

Hi Jim
Thanks for your reply
Be patient but what do you mean with "PEX trace " ??
Could you please show me an example for TRACE commands (STR - END ecce cc)
and how to read with SQL ??
Keep in mind i'm runnign V7R4
Thanks in advance
Gio

A PEX trace will get you the raw data, then use SQL to ferret out the
calls.
Used to do that quite a bit back in the day, but I’ve lost the SQL since
then


Jim Oberholtzer
Agile Technology Architects

On Apr 13, 2026, at 11:29 AM, David Gibbs via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

On Apr 13, 2026, at 10:56 AM, gio.cot <gio.cot@xxxxxxxxxxx> wrote:

Do you mean a list of programs that a specific program calls, the
current call stack, or something else?

I mean this : at the end of job, i would like for example to have a
list of all the call executed in that job ..
Thanks


I’m not aware of any way to do that kind of thing … there are API’s to
get the call stack.

You can use the DSPPGMREF command to see what programs are referenced.

There are also a number of utilities available that do static program
call analysis … like hawkeye, abstract/probe, & x-analysis.

david

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To
subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription
related questions.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.


--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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

This mailing list archive is Copyright 1997-2026 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.