Re: Re STRSQL auditing

[thomas@xxxxxxxxxxx]

Mandy:

On Thu, 01 November 2001, mandy.shaw@Notability.com wrote:

> Thanks Bill and Rob. The customer is journalling the files already & knows
> he could get accountability that way, but he would really prefer to know
> what the SQL commands issued were. Is anyone able to confirm whether the
> exit points Rob suggests would be picked up by STRSQL (since this doesn't
> use the database server I am a bit doubtful, to be honest).

The simplest way to get started with this is to investigate the Database 
Monitor with STRDBMON. Try this sequence:

 ÝÝ>  strdbmon outfile(qtemp/mon) type(*detail)
 ÝÝ>  strsql
.
. run some SQL and exit STRSQL
.
 ÝÝ>  enddbmon
 ÝÝ>  strsql
 ÝÝ>  select QQ1000 from qtemp/mon
            where QQRID Ð1000

By wrapping the first STRSQL between the start/end DB monitor commands, you 
turn on logging into QTEMP/MON for that single interactive SQL session. In the 
second SQL session, you'll see the SQL statements from the first session.

You could make STRSQL available for the customer by creating a trivial CL 
program that forces the DB monitor to run while STRSQL is active and then 
removing direct access to the STRSQL command. The wrapper CL would extract any 
desired info from the session logfile and place in a permanent logfile.

The DB monitor can be activated in a number ways, including for every job in 
the system rather than for a specific job. See the OS/400 DB2 for AS/400 
Database Programming manual for details.

(Of course, if you prefer, I believe you can contact the company I work for and 
we'll sell you a tool for this.)

Tom Liotta

--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788
Fax  253-872-7904
http://www.400Security.com


___________________________________________________
The ALL NEW CS2000 from CompuServe
 Better!  Faster! More Powerful!
 250 FREE hours! Sign-on Now!
 http://www.compuserve.com/trycsrv/cs2000/webmail/