On 22 Jan 2013 11:28, Mark S Waterbury wrote:
This is VERY valuable information. How did you find this?
And, could you please identify the relevant PTF numbers for V5R4,
V6R1 and V7R1?
The information was visible as a change-notification in the IBM i 7.1
documentation for the database member open exit:
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xopendbf.htm
_i Open Database File Exit Program i_
"...
#Start of change
Normally any exit program data is ignored if it is specified when an
exit program is added for the Open Database File Exit Program exit.
However, if the exit program data length = 7 and the exit program data =
'*OBJAUD' is specified, the object audit attribute of each file will be
interrogated prior to calling the exit program. <<SNIP>>
#End of change
..."
Although I saw the above change when I first visited that doc to
reply to Richard, what exactly was meant by the text did not actually
/click/ in my mind, and I just ignored it. However when I read about
the topic again in the Redbooks document referred to in the following
message by Luis, I realized its relevance to the performance concern
expressed in a prior post in _this_ thread:
# Subject: IBM 7.1 Redbook with TRs 4 & 5 (Draft)
# From: Luis Rodriguez <luisro58@xxxxxxxxx>
# Date: Tue, 22 Jan 2013 09:26:56 -0430
http://archive.midrange.com/midrange-l/201301/msg01008.html
"For those of you using 7.1 (and for the rest of us who are just plain
curious...) , IBM has just published a draft Technical Overview Redbook
for 7.1, TRs 4 and 5. You can find the link here:
http://www.redbooks.ibm.com/redpieces/abstracts/sg247858.html?Open
"
A web search on the following tokens yielded some APARs:
database open exit "*objaud"
APAR SE49539 v6r1 IBM i 6.1 R610 SI44832 2122 /* c2122610 */
APAR SE49574 v5r4 R540 SI44836 2094 /* c2094540 */
Interestingly that search yielded even further refinement in the
support; I did not search for any cross reference to either v5r4 or
v7r1, for an equivalent to this change:
APAR SE53671 v6r1 IBM i 6.1 R610 SI48461 1000 /* no cumulative */
http://www.ibm.com/support/docview.wss?uid=nas25629fa833b4e0d8786257a9d003cb5f4
"...
_Problem Summary_
Allow greater flexibility for defining when the Open Database File Exit
Program is called.
_Problem Conclusion_
The Open Data Base File Exit Program is enhanced to support two new
values for the Exit Program Data - OBJAUD(*ALL) and OBJAUD(*CHANGE).
This allows greater flexibility for when the exit program is called.
These new values are used in conjunction with the object audit attribute:
If the exit program data length = 12 and the exit program data =
'OBJAUD(*ALL)', the exit program will be called only if at least one of
the files referenced in the open have an object audit value of:
*ALL
*USRPRF and user's object auditing value for job is *ALL (for more
information see the OBJAUD keyword on the CHGUSRAUD command)
If the exit program data length = 15 and the exit program data =
'OBJAUD(*CHANGE)', the exit program will be called only if at least one
of the files referenced in the open have an object audit value of:
*CHANGE
*USRPRF and user's object auditing value for job is *CHANGE (for more
information see the OBJAUD keyword on the CHGUSRAUD command)
Auditing does not actually have to be active for this to apply. The open
exit will be called for all the files referenced in the open. For
example, physical file T1 has an object audit attribute of *NONE and
physical file T2 has an object audit attribute of *CHANGE.
OBJAUD(*CHANGE) was specified in the exit program data. 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.
..."
Regards, Chuck
On 1/22/2013 2:19 PM, CRPence wrote:
The Database member open exit was enhanced with IBM i 7.1 <via
PTFs in v5r4+> to enable the capability to be invoked only when a
file in the list of files being opened is audited [according to the
object, irrespective the system-level object auditing being in
effect].
http://publib.boulder.ibm.com/infocenter/iseries/v7r1m0/topic/apis/xopendbf.htm
_i Open Database File Exit Program i_
"...
Normally any exit program data is ignored if it is specified when
an exit program is added for the Open Database File Exit Program
exit. However, if the exit program data length=7 and the exit
program data='*OBJAUD' is specified, the object audit attribute of
each file will be interrogated prior to calling the exit program.
In this case, if any of the files referenced in the open have an
object audit value of:
* *CHANGE
* *ALL
* *USRPRF and user's object auditing value for job is *CHANGE or
*ALL (See the OBJAUD keyword on the CHGUSRAUD command)
the open exit will be called for all the files referenced in the
open. Otherwise, the exit program will not be called. Note that
auditing does not actually have to be active for this to apply.
"
From a draft Redbooks document [from a recent post here in another
thread], an example invocation to establish the Program Data:
"... the exit was invoked for every full open. Depending on the
amount of resources available and the number of full opens per
second in a system, performance could be a concern. IBM i 7.1 added
the capability to have the exit program QIBM_DB_OPEN called only
when a full open occurs where at least one of the tables referenced
by the query has object auditing enabled. This capability was also
extended to previous versions V6.1 and V5R4.
Example 3-1 QIBM_DB_OPEN exit enhancement
ADDEXITPGM EXITPNT(QIBM_QDB_OPEN) FORMAT(DBOP0100) ... PGMDTA(*JOB *CALC
'*OBJAUD')"
The word "query" in the above text should probably say "open". The
section of doc is geared toward the use of the exit by 3rd party
suppliers, specifically to intercept SQL query activity; i.e.
narrow focus.
midrange.com
