If you have auditing enabled and you audit for *SECCFG, you can review T/CP entries from the system audit journal. It’s also possible to have programming registered against the QIBM_QSY_CHG_PROFILE exit point to log uses of CHGUSRPRF. You might also audit *CMD usage and find T/CD entries that reference CHGUSRPRF, but those might not show info that you want if they’re from compiled CL programs.
Otherwise, it’s unlikely that anything was loged on your system. At least, nothing else useful comes to mind.
With 6.1, a DSPUSRPRF shows the date now of when a profile was change.
Creation date/time . . . . . . . . . . . . : 04/16/09 12:19:21
Change date/time . . . . . . . . . . . . . : 11/01/11 05:19:21
Last used date . . . . . . . . . . . . . . : 11/01/11
Restore date/time . . . . . . . . . . . . : 09/25/10 15:08:34
True, but that shows essentially any change, which might simply be that you created a new file and your profile was changed by the system to record the new ownership/authority. Those changes happen regularly while you’re logged on or while batch jobs run under your profile.
It can tend to mask changes from CHGUSRPRF. where someone added a special authority or made some other change of capabilities.
DSPOBJD OBJ(QSYS/XXXXXXXX) OBJTYPE(*USRPRF)
(Where XXXXXXXX is profile name)
Then option 5 Display full attributes
Again, no, that’s not it.
A simple test can show why the “object change date” is not sufficient for a *USRPRF object.
Start by running DSPOBJD for your own profile. Note the change date. Then create a simple 1-char data area in your current library or anywhere you can create and own a permanent object. Run the DSPOBJD command again and note if the “object change date” has changed.
If you wait a few minutes between creating and deleting objects, changes marked to the *USRPRF object should be more visible. Be sure to test with appropriate ownership/authority — assigning to group profiles for example will interfere.
Tom is absolutely correct in his answer. For our auditors we only have to report new users created and that is the creation date but if we had to report changes to a profile we sould have to use either of the options mentioned by Tom of either reviewing and tracking audit changes or write an exit point program to log the event somewhere.
Good job Tom