QIBM_DB_OPEN exit program object auditing control

A variety of techniques are used today by users and third party software products to add security controls over and above the security functions built into IBM i. One primary mechanism used to provide this added capability has been to get control via a variety of exit points and to parse the SQL statements. SQL parsing, however, is not only complicated, but continually changing as new SQL functionality is added.

Several releases ago, a single open data base exit was implemented in IBM i to relieve user and third party software from having to parse SQL statements by providing a list of the files referenced in the SQL statement. While this exit solved the parsing problem, the exit was invoked for every full open so performance was a concern.

The QIBM_DB_OPEN exit program has been enhanced to allow users to control which files will cause the exit program to be called, which can significantly reduce the overhead of using the exit.

Here is the basic information and examples:

-- This command will register an exit point program (in this example called MJATST/OPENEXIT2).

-- The PGMDTA value indicates you only want the open exit invoked if at least one file in the open has its object auditing set

ADDEXITPGM EXITPNT(QIBM_QDB_OPEN) FORMAT(DBOP0100) PGMNBR(7) PGM(MJATST/OPENEXIT2) THDSAFE(*YES) TEXT('MJA') REPLACE(*NO) PGMDTA(*JOB *CALC '*OBJAUD')

-- For example.

-- The first three CHGUSRAUD command examples indicate that object auditing is specified for this object.

-- The last command example indicates that object auditing is only active if the user profiles object auditing is specified.

CHGUSRAUD USRPRF(MJA) OBJAUD(*CHANGE)

CHGOBJAUD OBJ(MJATST/T1) OBJTYPE(*FILE) OBJAUD(*CHANGE)

CHGOBJAUD OBJ(MJATST/T1) OBJTYPE(*FILE) OBJAUD(*ALL)

CHGOBJAUD OBJ(MJATST/T1) OBJTYPE(*FILE) OBJAUD(*USRPRF);

-- The open exit will be called for ALL files that are specified in a query or open if ANY of the files have specified object auditing.

-- For example, assume you two physical files, T1 has an object audit attribute of *NONE and T2 has an object audit attribute of *CHANGE.

-- An open of T1 will not call the exit. An open of T2 will call the exit. A join query that includes both T1 and T2, will call the open exit for both T1 and T2, not just T2. It was simply too much work to track each and every table as we were building up the list that would be passed to the exit point.

-- For performance reasons the open exit information is cached today. Once a QIBM_DB_OPEN exit point is added or removed, only new jobs will pick up the change.

Refer to the IBM i Knowledge Center documentation for addition details: Open Database File Exit Program