Answer Wiki:
Hi,
Have a look at object monitoring in the system audit journal - QAUDJRN. The system values QAUDLVL and QAUDCTL controls this as well.
Best of luck
JohnDavid
===========================================================
Along with object auditing (CHGOBJAUD), you can also use user auditing (CHGUSRAUD). User auditing can include AUDLVL(*CMD) to track commands issued by the user. Other than combining database journaling with object auditing, I'm not aware of any useful way of tracking which users did what to or with which files. Those are the system methods provided for tracking, so there's no reason not to use them.
As for LMTCPB(*YES) and menu control, they are practically worthless. Ignore them.
Tom
To see all answers submitted to the Answer Wiki: View Answer History.
Is your major problem not so much as who is using the command as much as who CAN use the command. The two commands you list are limited to programmers and QSECOFR on our system.
All users arrive on our iSeries through defined menus and their user profiles have LMTCPB(*YES) so even if they can get to a command line all they can use is the DSPJOB and SIGNOFF commands.
As far as finding out who might be using the commands, UPDDTA creates a temporary program named QDZTD00001 in QTEMP. If you have a file journalled this will show up as the program of record on any DB changes to the file.
For STRSQL it is not so straight forward. The program it logs as the update program is the last program in the job stack. For instance a user has a startup program of INITPGM and executes an STRSQL from a command line after signing on. When they update a record the journal shows the update program as INITPGM. As long as you recognize this program as other than a normal application program that is doing legitimate updates then this might suffice.