RE: Auditing users with elevated privileges.

I opened up a ticket with IBM. Apparently it is documented that *USRPRF objects are immune to many of the stuff of object auditing. They specifically listed DSPUSRPRF for one. I'll give IBM the benefit of the doubt here that they have valid reasons, like a lot of performance hit or some such thing. That, and they gave me an acceptable alternative.
CHGUSRAUD USRPRF(DUMMY) OBJAUD(*ALL) AUDLVL(*JOBDTA *NETSCK)
Tried:
- 5250
- ftp
- NetServer
And it caught them all
SELECT journal_code, journal_entry_type, "CURRENT_USER", "JOB_NAME", "JOB_USER", "JOB_NUMBER", PROGRAM_NAME,
PROGRAM_LIBRARY, PATH_NAME, OBJECT, OBJECT_TYPE, REMOTE_ADDRESS, REMOTE_PORT, ENTRY_TIMESTAMP
FROM TABLE (QSYS2.Display_Journal(
JOURNAL_LIBRARY => 'QSYS',
JOURNAL_NAME => 'QAUDJRN',
STARTING_RECEIVER_LIBRARY => 'QGPL',
STARTING_RECEIVER_NAME => '*CURCHAIN',
STARTING_TIMESTAMP => CURRENT TIMESTAMP - 20 minutes
)) X
WHERE
(OBJECT_TYPE = '*USRPRF' and OBJECT = 'DUMMY QSYS')
or "CURRENT_USER"='DUMMY' or "JOB_USER"='DUMMY';

I rearranged the columns to stick with pertinent data
CURRENT_USER, JOB_NAME, JOB_USER, REMOTE_ADDRESS
ROB ROBHQ1 ROB 10.10.9.30
DUMMY QPADEV0004 DUMMY 10.10.6.128
DUMMY QPADEV0004 DUMMY 10.10.6.128
DUMMY QTFTP00037 QTCP 10.10.6.128
DUMMY QTFTP00037 QTCP 10.10.6.128
DUMMY QTFTP00037 QTCP 10.10.6.128
DUMMY QTFTP00037 QTCP 10.10.6.128
DUMMY QZLSFILE QPGMR -
DUMMY QZLSFILE QPGMR 10.10.6.128

Rob Berendt