Another good idea to limit overhead from the trigger is to have the
trigger just capture the information about the record, etc that you want
captured and toss it into a data queue and just end. Then, you can create
a second program that runs in batch that just monitors the data queue and
reacts when an entry is posted. This transfers all of the extra
processing to a process that is not in-line with the main process. I've
used this very effectively when dealing with information passed through an
exit point.
Rich Loeber
Kisco Information Systems
http://www.kisco.com
--------------------------------------------------------------------------
Charles Wilt wrote:
Just because there's a recommendation that something not be used if
possible, doesn't mean that the something doesn't exist for a reason
or that it's always possible to avoid using the something.
In the case of READ triggers, as Chuck mentions they were added
specifically to support the requirement you have.
So a READ trigger is going to be the best answer to track who read
what records (assuming you need that level of detail).
However, as Alan alludes to, there's a right way and a wrong way to do this.
The wrong way is to have the encrypted CC# in your CustomerMaster
file, thus causing every read on the customer master file by every
program/query to fire the trigger. Not only would the performance be
horrid, but the shear quantity of logs will overwhelm you.
The right way is to have a separate CreditCardMaster. The
CustomerMaster file would contain a foreign key into the
CreditCardMaster file. This way only the program(s) that need the CC#
will access the file, and only accesses to the CC# will be logged.
HTH,
Charles
On Thu, Apr 2, 2009 at 5:29 PM, Eftimios Pantzopoulos
<Mike.Pantzopoulos@xxxxxxxxxx> wrote:
_______________________________________________________________________________________
Note: This e-mail is subject to the disclaimer contained at the bottom of this message.
_______________________________________________________________________________________
The company I'm working for has asked me whether it's possible to track all accesses to a file which contains an (encrypted) credit card number.
From my research I've discovered that there is a READ trigger on the iSeries DB2 but it is highly recommended that it not be used, which I can understand.
I've also come across a reference to a DB2 audit function, but unfortunately, only for the LUW version of DB2 (
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/t0011540.htm)
. I went searching for the function in iSeries DB2 and couldn't find it. Can anyone tell me if it exists, where any good documentation for it is, or if not, any alternatives to tracking access to important data. Perhaps there are better techniques using normal iSeries authority?
_______________________________________________________________________________________
The information transmitted in this message and its attachments (if any) is intended
only for the person or entity to which it is addressed.
The message may contain confidential and/or privileged material. Any review,
retransmission, dissemination or other use of, or taking of any action in reliance
upon this information, by persons or entities other than the intended recipient is
prohibited.
If you have received this in error, please contact the sender and delete this e-mail
and associated material from any computer.
The intended recipient of this e-mail may only use, reproduce, disclose or distribute
the information contained in this e-mail and any attached files, with the permission
of the sender.
This message has been scanned for viruses with Symantec Scan Engine and cleared by
MailMarshal.
_______________________________________________________________________________________
--
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.
midrange.com
