Re: Track all records read from a table

The only reason to use a read trigger is for compliance purposes.

That being the case, a journal is a better choice from an auditing
standpoint.

Sure you could write to a log file that is journalled, but why not just
write to the journal.

I suspect that such entries should be sent to the system audit journal; as
the system layers on some extra security/restrictions to that object. But
IBM's docuentation say "The auditing journal QSYS/QAUDJRN is intended
solely for security auditing. Objects should not be journaled to the audit
journal. Commitment control should not use the audit journal. User entries
should not be sent to this journal using the Send Journal Entry (SNDJRNE)
command or the Send Journal Entry (QJOSJRNE) API."

However, John Earl has an example where he's logging security related stuff
to the audit journal.
http://www.securemyi.com/nl/articles/johnearl1.html

I also found a reference that discusses some code of Wayne Evans using
SNDJRNE to the audit journal.

Volume of entries might be a concern, but the volume would be the same
regardless of which journal they go to. The record keeping requirements
probably fit better with the audit journal.

Charles








On Wed, Mar 23, 2016 at 1:32 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

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