Re: Audit trail of file changes

On Fri, May 22, 2009 at 1:09 PM, James Rich <james@xxxxxxxxxxx> wrote:

On Fri, 22 May 2009, rob@xxxxxxxxx wrote:

Guess what our biggest library on our system is?

This does concern me.  At first I thought they only wanted to keep the
trail for a period of about a month.  Now I found out they want to keep it
indefinitely.  I noticed that the journal holds a lot more than just
updates, adds, and deletes;  it also tracks every open, close, and backup.
I don't really need that second class of information.  Is there a way to
either purge unwanted data or only log updates?

STRJRNPF <xxxxx> OMIT(*OPNCLO).

Also look at CRTJRN RCVSIZOPT() and MINENTDTA() parms.

Another thing that has me a little confused is that the record length of
the file I'm journaling is 1088 but the field in the journal that I
believe holds the changed data is only 100.  How can it possibly hold the
before and after images when the field is so much smaller that the record?

CRTJRN MINENTDTA(*FILE or *FLDBODY) perhaps? Note that according to
the online help, *FILE is not useful for auditing.

But I'd bet you're confused. How have you determined that the the
field holding the changed data is only 100 bytes? DSPJRN
OUTPUT(*OUTFILE) perhaps? If so, the defaults on DSPJRN only output
100 bytes. You'll need to change the ENTDTALEN() parm to get all the
data out.

HTH,
Charles