Re: Audit trail of file changes

2009/5/22 James Rich <james@xxxxxxxxxxx>:

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

Journals do need careful management.  If you are truly only ever going to
journal this one file and no others, or, if you do start journalling other
files then you will have NO concerns about commitment control, etc, then
you may wish to journal just this one file to it's own journal.  This will
allow you to customize the retention of that journal.  However if you want
to start using commitment control and this file may be part of a
commitment boundary then you may will probably have to have all the files
in said boundary in the same journal.

I honestly don't see us using commitment control.  I think that would
involve substantial rewriting of the applications.  All we need is a way
to show before and after contents of this single file in a way that is
provably correct.

Guess what our biggest library on our system is?

Same for us - our MIMIX receiver library is over 100Gb on a system
with only just over 1TB DASD. We only keep for eight days as we're at
around 75% disk usage.

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?

Jim

Where we need to keep hold of the audit trail we save it in the DSPJRN
*OUTFILE, and get rid of the journal receivers after 8 days. When you
do STRJRNPF you can specify to omit open & close of the file: STRJRNPF
FILE(MYFILE) JRN(MYJRN) IMAGES(*BOTH) OMTJRNE(*OPNCLO)

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?

The default length of the JOESD field in the DSPJRN *OUTFILE is 100.
If your record is longer then do DSPJRN ... ENTDTALEN(1088). The full
record is in the receiver regardless.

I create a file that has all the fields from the *OUTFILE, but without
JOESD. Instead I put the fields from the target file at the end of the
DDS. That way I can to a CPYF MBROPT(*ADD) FMTOPT(*NOCHK) from the
*OUTFILE to the new file and the data lines up. It's easy to query in
SQL or by RPG that way.

Regards, Martin