Re: Track all records read from a table

And if you are on 7.2, you can query the journal via SQL

SELECT * FROM TABLE ( DISPLAY_JOURNAL( 'DBLIB', 'QSQJRN')) AS JNL

http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_72/rzajq/rzajqudfdisplayjournal.htm



Paul











From: Nathan Andelin <nandelin@xxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Date: 23/03/2016 18:32
Subject: Re: Track all records read from a table
Sent by: "MIDRANGE-L" <midrange-l-bounces@xxxxxxxxxxxx>

Nathan, my thinking on using a journal for this is that would put all

file

activity on the same place.

Okay, but wouldn't that be a disadvantage for you? Querying journals is
harder than databases.

Reads, updates and deletes.

My understanding is that only database changes are recorded when you start
journaling on database files - not reads. You'd still need a trigger to
"send" reads to journals, using a system API.

If the question that is being asked is who did anything to this file
having it all in one place makes sense.

Yes. But wouldn't it make more sense to record reads, inserts, updates,
and
deletes in a database for query purposes?

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.


I don't see how that might be relevant. Security officers have more
skills;
more tools?

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.

I haven't tested the performance. But my suspicion is that writing to a
log
file would perform better than using an API to send record images to to
journal.