We have this data scientist.  She runs some intense sql queries to query data but not update.  She may occasionally create a view.

I run this statement

SELECT ENTRY_TIMESTAMP, USER_PROFILE_NAME, QUALIFIED_JOB_NAME, REMOTE_ADDRESS, OBJECT_LIBRARY, OBJECT_NAME, OBJECT_TYPE, PATH_NAME, IFS_OBJECT_NAME, AF.*
-- *
 FROM TABLE(
  SYSTOOLS.AUDIT_JOURNAL_AF(
    STARTING_TIMESTAMP => CURRENT TIMESTAMP - 3 days
  )) AF
order by ENTRY_TIMESTAMP desc
;

And I see that she is getting an entry on the *CMD ADDPFTRG within job QZDASOINIT under user QUSER_NC (obviously 7.6).  Happened 7/15 10:59.

I dumped the plan cache for anything dealing with her in that time period to an Excel spreadsheet.  I searched the spreadsheet for TRIG, TRG and there are no hits.

I'm under the assumption that, in theory, she's not really running ADDPFTRG but perhaps something else which runs ADDPFTRG under the covers.  For example the SQL statement equivalent of ADDPFTRG.  Either way the plan cache search should have found that.

All the statements begin with either SELECT or WITH

Any further suggestions?

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------

I suggest you use authority Collection on the user profile. you will then see the precise reason of the failure, plus all the objects involved in the transaction (mainly the programs called before running ADDPFTRG). 

------------------------------
Guy Marmorat
Security Expert for IBM i - Resiliane
------------------------------

Robert ciao, maybe look into the "CD" audit, it will show the the command to give you at least some context, in any case a command like ADDPFTRG is worth auditing given the impact...

Have you perhaps installed any automated "data capture" solution, that maybe after some object creation automatically try to put itself in the loop (i.e. via triggers)? Just one hypothesis...

------------------------------
--ft
------------------------------

I'm guessing I probably need to run this first, eh?

CHGOBJAUD OBJ(QSYS/ADDPFTRG) OBJTYPE(*CMD) OBJAUD(*ALL)

I don't believe she's added any data capture solution.  Budget is really tight lately (unless, of course, it has "AI" in the title).

------------------------------
Robert Berendt IBMChampion
Business Systems Analyst, Lead
Dekko
Fort Wayne
------------------------------

Original Message:
Sent: 07/20/26 05:29 AM
From: ac
Subject: Authority Failure on ADDPFTRG

Robert ciao, maybe look into the "CD" audit, it will show the the command to give you at least some context, in any case a command like ADDPFTRG is worth auditing given the impact...

Have you perhaps installed any automated "data capture" solution, that maybe after some object creation automatically try to put itself in the loop (i.e. via triggers)? Just one hypothesis...

------------------------------
--ft
------------------------------

Hi Rob,

FYI, the SQL Plan Cache will only show tracks for operations that involved the SQL query engine: queries or DML operations that have some querying aspect to them (e.g. DELETE with a WHERE clause). Adding a trigger, whether through CL commands or SQL commands, is not something that goes through the query engine and so will not show up in the plan cache.

Instead, what you want is to collect a database monitor. This will capture any trigger creation that was initiated through SQL. However, it won't capture ADDPFTRG commands, so you'll need one of the other solutions offered in this thread for that.

Hope that helps!

------------------------------
Tim Clark
Db2 for IBM i / SQL Optimizer
------------------------------

Hi Rob

Not sure which OS version you're running, but I did come across some information in PTF cover letters and Memo to Users for i7.5.  Here they are; Fix Information: FI0133404, Add Physical File Trigger (ADDPFTRG) CL command *PUBLIC authority - IBM Documentation

I hope this helps.

Regards,

AL

------------------------------
Allen Hlavacek
------------------------------