Defined a new accounting table to track DQ activity, and used the UIDxx breakdown as specified in the DBA Guide:
DATABASE TABLE NAME: A15
CONDITIONAL EXPRESSION:
UID01 EQ 'DQ '
DATABASE KEY NAME: A15KY
DATADICTIONARY KEY NAME: A15KY
STARTING AT OFFSET 00000 FOR A LENGTH OF 006 WITH DD NAME OF DATE
STARTING AT OFFSET 00006 FOR A LENGTH OF 008 WITH DD NAME OF JNAME
STARTING AT OFFSET 00014 FOR A LENGTH OF 003 WITH DD NAME OF UID01
STARTING AT OFFSET 00017 FOR A LENGTH OF 008 WITH DD NAME OF UID04
STARTING AT OFFSET 00025 FOR A LENGTH OF 015 WITH DD NAME OF UID12
STARTING AT OFFSET 00040 FOR A LENGTH OF 001 WITH DD NAME OF UID31
ELEMENT NAMES USED:
DATE STARTING AT OFFSET 00000 FOR A LENGTH OF 006 WITH DD NAME OF DATE
EXCPS STARTING AT OFFSET 00045 FOR A LENGTH OF 004 WITH DD NAME OF EXCPS
JNAME STARTING AT OFFSET 00006 FOR A LENGTH OF 008 WITH DD NAME OF JNAME
REQS STARTING AT OFFSET 00041 FOR A LENGTH OF 004 WITH DD NAME OF REQS
UID01 STARTING AT OFFSET 00014 FOR A LENGTH OF 003 WITH DD NAME OF UID01
UID04 STARTING AT OFFSET 00017 FOR A LENGTH OF 008 WITH DD NAME OF UID04
UID12 STARTING AT OFFSET 00025 FOR A LENGTH OF 015 WITH DD NAME OF UID12
UID31 STARTING AT OFFSET 00040 FOR A LENGTH OF 001 WITH DD NAME OF UID31
There is a problem with inconsistent values for some of the columns in rows generated by accounting:
-the UID04 column does not contain the user id as you may hope. Sometimes it is spaces, sometimes low-values
-for a batch DQBATCH, the contents are inconsistent: sometimes it is spaces, sometimes low-values
-submitted DQBATCH is generating some batch rows (UID31 = X'01') with the query name filled in, but sometimes with spaces, some with low-values ... three different key values for the accounting table
For a query execution you will have the value "DQ" in the first two bytes of the User Information Block (UIB)
The 8 characters of the UID04 field come from the user’s definition panel from a field called "ACCOUNTING CODE". If users have a value there, it will be reflected in the UID04 field. If a site wants these values to be unique, then every user would have to be given a unique and identifiable accounting code; that value would then show up in the UID04 field.
Also if you eliminate bases 02, 03, 15 and 005, it will narrow down the entries that reflect internal processing by the DataQuery product, but will not eliminate them all. You will stil continue to see accounting lines representing inqmu commands, and commits log commands. The bases mentioned above are for DD, DQ, SQL, and the accounting base.
Adding some conditional expression statements to bypass base 2,3,5,15 requests to the accounting table may or may not significantly reduce the output produced in the accounting tables; this depends on the utilization within your environment. It will probably reduce the number of actual rows accumulated within each unique 'key value', but not in the number of key values.
In addition to these steps, you can include the accounting column TNAME to your accounting table, then test the value in that column and eliminate any accounting rows with blank table names. This will allow you to see more clearly the statistics for user table access, which are the values most sites are interested in.