Problem finding useful information in the UIDxx fields of the accounting tables.

Products

• Datacom
• DATACOM - AD
• CIS
• COMMON SERVICES FOR Z/OS
• 90S SERVICES
• DATABASE MANAGEMENT SOLUTIONS FOR DB2 FOR Z/OS
• COMMON PRODUCT SERVICES COMPONENT
• Common Services
• CA ECOMETER SERVER COMPONENT FOC
• Easytrieve Report Generator for Common Services
• INFOCAI MAINTENANCE
• IPC
• UNICENTER JCLCHECK COMMON COMPONENT
• Mainframe VM Product Manager
• CHORUS SOFTWARE MANAGER
• CA ON DEMAND PORTAL
• CA Service Desk Manager - Unified Self Service
• PAM CLIENT FOR LINUX ON MAINFRAME
• MAINFRAME CONNECTOR FOR LINUX ON MAINFRAME
• GRAPHICAL MANAGEMENT INTERFACE
• WEB ADMINISTRATOR FOR TOP SECRET
• Xpertware

Issue/Introduction

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  

Environment

Release:
Component: DB

Resolution

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.