RE: Log all PF changes?

We currently run journaling, and receivers that are both detached and saved are deleted daily.

Viewing what changed would be via an app that I would write.

I can see issues with HA, but I don't see HA ever happening here so I'm not too concerned. I don't see off-hand how keeping receivers would adversely affect commitment control however.

What are the advantages of harvesting the journal data and storing it in DB2 or the IFS, space?



-----Original Message-----
From: Charles Wilt [mailto:charles.wilt@xxxxxxxxx]
Sent: Wednesday, January 06, 2016 3:23 PM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Subject: Re: Log all PF changes?

Just a word of advice...

If you don't currently use journalling, and you want to start journally for just this one file...

Then sure, it would make for a quick and easy solution.

However, some things to think about
- How do you intend to display the journal entries? DSPJRN in an of itself is not very pretty. The table's data is just one big blob. It gets even more complex when you have nullable fields and/or MINENTDTA() of other than *NONE.
- If you ever need journalling for something else such as commitment control or HA, then you're going to have problems keeping receivers around forever.

IMHO, planning on keeping journal receivers around forever is not a good idea.

Consider instead a program that harvests the journal entries and stores them someplace.
You may be able to start with the CMPJRNIMG command as laid out here:
http://www.securemyi.com/nl/articles/databaseaudit.html

Personally, if I really _HAVE_ to (for legal reasons) have a record of changes forever; then I'd be looking at a third party compliance tool.
http://www.helpsystems.com/powertech/products/datathread
http://www.cosynsoftware.com/index.asp?CID=product&PID=CAT
http://townsendsecurity.com/products/file-integrity-monitoring-advanced-tools
http://www.razlee.com/products/security/ap-journal/ap-journal_regulation_compliance_o.php

I'm sure there's more...

Charles