RE: Track all records read from a table

Transferring the read buffer to a journal will satisfy many auditors since a
journal entry cannot be changed once it's written, whereas a log file would
be changeable. Once the auditor has verified the proper behavior of the
read trigger, then they can certify that the contents of the journal are
accurate. Additionally since a journal can be changed on a periodic basis
(daily or weekly) it's easy to set it up to zero in on specific records when
needed for forensics, and the journal receivers themselves don't get too
big. Furthermore it's easy to archive the receivers to tape for extended
storage.

Nathan, I agree with your comment about a log file being easier, but copying
a journal into a physical table is not that hard either so I guess it's just
an extra step.

I'm also dubious about save operations having any effect on a read trigger.
We would have heard many a horror story already if that's a problem.

--
Jim Oberholtzer
Agile Technology Architects


-----Original Message-----
From: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of
Nathan Andelin
Sent: Tuesday, March 22, 2016 4:18 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.