RE: Track all records read from a table

Nathan, my thinking on using a journal for this is that would put all file activity on the same place. Reads, updates and deletes. If the question that is being asked is who did anything to this file having it all in one place makes sense. Also in my specific case an end user would never be asked to query the read log, that would only be taken by someone with security officer privileges. If the only question to be answered is who read a record and that end users needed to get at the data then a database makes more sense. I was also thinking that writing to a journal would be much faster than writing to a database.

Mike C
________________________________________
From: MIDRANGE-L [midrange-l-bounces@xxxxxxxxxxxx] on behalf of Nathan Andelin [nandelin@xxxxxxxxx]
Sent: Tuesday, March 22, 2016 5:17 PM
To: Midrange Systems Technical Discussion
Subject: Re: Track all records read from a table

Mark,

That assumption about backups firing READ triggers sounded fishy from the
beginning. Thanks for raising the question. Copy commands (CPYxxxxxxx) may
be different story. That would be good to test.

I don't get why anyone would transfer a read buffer to a journal, rather
than to a log file. Wouldn't that just make it harder for users to query?

Regarding trigger overhead, consider an RPG "read" opcode; Under the
covers, the RPG program makes procedure calls nested at least a couple
layers deep. Depending on how a read trigger is implemented, it may only
add microseconds.





On Tue, Mar 22, 2016 at 2:57 PM, Mark S Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Mike:

To my knowledge, there is no "issue" to do with "back-ups" when using
triggers.//IBM i (and OS/400) save and restore operate on the object as a
whole (the database *FILE) saving or restoring the entire "container" (data
space, etc.); so it does not operate at a record or row level, and so, NO__
triggers are ever "fired" during normal save or restore operations.

Vengoal Chang posted a program named "TRGREADJRN" on his web site here:

http://blog.xuite.net/vengoal/as400/61009651

The web page is in an Asian language but the ILE RPG IV source code is in
English. The TRGREADJRN program writes a journal entry to record details
of each "read" of the file the trigger is attached to.

Hope that helps,

Mark S. Waterbury

On 3/22/2016 4:12 PM, Mike Cunningham wrote:

Thanks to everyone who has added to this thread. The backup issue could
be a problem for me as the file I need to do this on is one of our largest
with 2.5M records. It gets backed up nightly so have 2.5M read triggers
fire could cause a problem. My trigger could ignore that job and not
journal (or data queue) that read but the trigger processing overhead
would still take place. I could also remove the trigger just before backup
starts and then put it back after backup ends but that's something I don't
like to do as it could lead to problems someday when adding it back fails
and the error is hidden deep in the backup joblog.

My other option is change code in the apps that read this data and
presents it do a user (all in-house source code) and have each app journal
the read.

And since I first asked this question nothing I do is going to meet the
need 100%. I remembered that we send the data I need to read journal off
to a could service that one of our offices use and the user can view the
data that needs tracked from that service. I have no way to monitor or
control access to the data once its sent.

Mike Cunningham

--
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.

--
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.