Re: Log all PF changes?

[Charles Wilt <charles.wilt@xxxxxxxxx>]

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.