Re: STRSQL audit log -- is the 'journal' of the container of the data; no statement auditing

[CRPence <CRPbottle@xxxxxxxxx>]

  Journal the files.  The journal serves as the audit trail for the 
insert\update\delete of the data in the files.

  If there is a requirement to journal statements... I think that had 
been a requirement submitted a few times.  That is a hard sell since the 
journal provides the net effect, which would satisfy almost any audit. 
However for auditing of dynamic DML statements, one could use the DB 
Open Exit with the feature to retrieve the last\current SQL statement, 
possibly only in combination with a program stack review.  I would 
suggest avoiding that exercise, except in the most excessively strict 
audit environments; best to just defer to journaling.

  Submit a requirement for statement level auditing as an enhancement 
over command level auditing if that is perceived as necessary for the 
business.  Be sure to be clear on whether only dynamic or if embedded 
statements too, and if only DML or also DDL.  FWiW viewing the idea of 
logging the SQL as effectively logging HLL statements, the language 
being SQL, might seem a bit daft; be clear on what are the actual 
requirements to satisfy the business needs.

  I had envisioned at one time that shipping in QSYS, some *CMD objects 
like SQLUPDATE, SQLINSERT, & SQLDELETE, could enable command auditing 
for the equivalent dynamic statements.  Such commands invoked via the 
SQL runtime when the statement was prepared would cause any activated 
command auditing to occur.  And at the same time enable controlling the 
use of the statement due to either the user authority restrictions or 
command environment rules as controlled by the command invocation.

Regards, Chuck

Paul E. Fenstermacher wrote:
> Our auditors want us to maintain a log of activity around this command
> like we can do with DFU and DBU.  Anyone know a way to do this?  Thanks.