Re: Log all PF changes?

Could be out of date...

I found the following:
http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_72/dbp/rbafoccusg.htm?lang=en

"You can open logical files for output under commitment control when
underlying physical files are journaled to different journals. " <snip>

"However, the checks for violations are deferred if a record change affects
underlying physical files that are journaled to the same journal. If the
record change affects underlying physical files that are not journaled to
the same journal, and it causes a duplicate key or referential constraint
violation, an error will occur during the input/output operation."


Doesn't seem to be a big a recommendation as I recall it being.


Charles



On Thu, Jan 7, 2016 at 10:43 AM, Justin Taylor <JUSTIN@xxxxxxxxxxxxx> wrote:

Yes, I put this table in its own journal. With about 200 transactions a
day, disk space shouldn't be a problem. Is that recommendation against
multiple journals current? All I can find is that it's allowed.

"How commitment control works"

http://www-01.ibm.com/support/knowledgecenter/ssw_ibm_i_71/rzakj/rzakjhowworks.htm?lang=en-us





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

If you're already journalling all (most) files, it seems improbable that
you can reasonably keep journal receivers around forever. I keep 90 days
where I'm at now; which takes about 4% of my disk space. Where I used to
be, we could only keep 7 days.

Unless you journal this one particular file to it's own journal. However,
when using commitment control, IBM strongly recommends (requires?) that all
files for a given commit cycle be journaled to the same journal. IIRC,
rollback doesn't work right when different journals are involved.

By harvesting the data, you can just keep the one files changes you need
to keep. You can also keep it in a an efficient manner.

For an audit log, off the top of my head..
SEQ#, TIMESTAMP, LIBRARY, TABLE, USER, PROGRAM, <xxx>, COLUMN_NAME,
ORIGINAL VALUE, NEW_VALUE

Lastly, if you're using the raw journal format for archival...consider how
you would deal with a new column being added to the table. Suddenly,
you're not dealing with the same format anymore.

The problem with rolling your own, IMHO, if you _HAVE_ to keep this
information, for legal reasons. Then it's on you to prove that your
solution meets the requirement. Whereas with a third party, it's on them
and they should already have that proven.



Charles




--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.