Comments on: User profile modified date in as 400

By: lovemyi

lovemyi — Thu, 03 Nov 2011 18:02:29 +0000

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

Lovemyi

By: tomliotta

tomliotta — Wed, 02 Nov 2011 19:49:24 +0000

thats it.

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

By: chenthil

chenthil — Wed, 02 Nov 2011 15:20:38 +0000

DSPOBJD OBJ(QSYS/XXXXXXXX) OBJTYPE(*USRPRF)

(Where XXXXXXXX is profile name)

Then option 5 Display full attributes
Page down

thats it.

By: tomliotta

tomliotta — Tue, 01 Nov 2011 22:06:46 +0000

With 6.1, a DSPUSRPRF shows the date now of when a profile was change.

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.

Tom

By: hmssl2k

hmssl2k — Tue, 01 Nov 2011 13:21:24 +0000

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

By: tomliotta

tomliotta — Mon, 31 Oct 2011 19:44:40 +0000

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.

Tom