Auditing use of important OS commands - DLTLIB, DLTOBJ etc

[G.Gaunt]

Comment, I set system value QAUDCTL(*AUDLVL) once, then set each programmer user profile once with "CHGUSRAUD USRPRF(name) AUDLVL(*CREATE *DELETE)". Every morning I run "DSPJRN QAUDJRN FROMTIME(mmddyy) USRPRF(name) ENTTYP(CO DO)" for each programmer, to see everyone's activity from yesterday.

[gary.shipp@s3t.co.uk]

Thats interesting, not something I've heard of before. I'll have a play and see what it gives me. I presume you just have scheduled CLP's that do the DSPJRN for each programmer user profile?

[m_baramova@hotmail.com]

We are using QAUDLVL (*AUTFAIL *SAVRST *DELETE *OBJMGT *SECURITY *SERVICE *SYSMGT) with QAUDCTL(*AUDLVL). Every night is running CL which is creating PF (Similar way, like Gene Gaunt suggested). Several queries are using this file to produce useful reports (DO journal entry - Deleted objects; AF - Authority failure; PW - Password & User not correct...). For powerful users we made "personal" audit using CHGUSRAUD AUDVL(*JOBDTA *SECURITY *SERVICE *SPLFDTA *SYSMGT). Works perfect.

[gary.shipp@s3t.co.uk]

Thank you for the extremely useful advice on this topic. One final question for you is once I am satisified with the reports produced over the information recorded in the journal, how do I clear the journal? I can't find any way to clear a journal or remove journal entries. TIA

[J.Pluta]

The point of a journal is that you shouldn't be able to alter the contents. Clearing or removing entries is sort of against the spirit of what a journal does. Okay, next issue: a "journal" (object type *JRN) doesn't really have entries; the journal is sort of the "valve" through which entries flow, headed towards a "journal receiver" (object type *JRNRCV). Instead of removing entries, you can "detach" a journal receiver, and attach a new one. Take a look at the CHGJRN command, which will allow you to detach the current receiver(s) and generate new ones. At this point you can delete the old ones (although it is customary to backup them up to a permanent medium first). Joe

[gary.shipp@s3t.co.uk]

The only reason I was thinking about clearing/removing journaled entries was to recover storage, my reasoning being that once the entries have been reported and/or archived in some way, there is no need to retain the journaled information any longer. My intention was to DSPJRN to an outfile as part of our nightly procedure and then report over the outfile. However, I guess you're suggesting that it would be more economical storage wise to retain the data permenantly in the journal/receiver rather than elsewhere. In terms of auditing changes, which was the original purpose of this project, I suppose retaining data going back to the year dot would be preferable, I just didn't want my ops manager shouting at me cause all his disk space was being gobbled up!

[J.Pluta]

You could conceivably set up a file that has only the information you want audited. This would most likely save disk space. You could then, on a regular basis (say nightly), move the journal entries to that file. About once a week or so, you could detach the journal receiver and attach a new one, and save the old receiver for historical purposes. The biggest problem with this approach is that the file you store this information in is easily accessible to anyone with enough authority, and so it isn't particularly secure. In practice, journals are far more tamper-proof. Joe

[gary.shipp@s3t.co.uk]

Having been caught out a couple of times recently, I am considering writing simple bespoke version of certain commands to log the usage details. So for example, the simplified logic for the new DLTLIB would be along the lines of;[*] Bespoke prompt for library name[*] Pass parms from command to DLTLIBCL.[*] Record user/date/time/library to audit file.[*] QSYS/DLTLIB LIB(Library name) Are there any obvious flaws or better approaches other people have implemented? My biggest concern is making sure my bespoke prompt performs the same validation as the original QSYS command. I look forward to your comments.

[gary.shipp@s3t.co.uk]

Fair point. At the end of the day, I suppose it depends whether or not it becomes an issue. I think I'll just wait and see. At least there are solutions available if it comes to it. Thanks again.