Re: Trigger blocking

Hi, Peter:

Perhaps you could do something like the following, in the batch programs (applications) that need to be "exempt" from these "read" triggers:

_Assumption:_ this is truly a "read-only" batch (report) application -- this database file or table is _not_ updated for the duration of the batch job

*#1.* issue RMVLIBLE QTEMP

*#2.* issue ADDLIBLE QTEMP *FIRST

*#3.* issue:
CRTDUPOBJ OBJ(filename) FROMLIB(datalib) OBJTYPE(*FILE) TOLIB(QTEMP) DATA(*YES) TRG(*NO)

*#4.* issue CRTDUPOBJ for any LF(s) over the PF needed by this batch job

*#5.* run the batch report -- since QTEMP is at the top of the *LIBL, this batch job should use _this_ copy of the database file that has /no triggers/ (thanks to TRG(*NO) on CRTDUPOBJ).

*#6.* when the job ends, QTEMP gets cleaned up automatically, so you are "done"

Let me know what you think...

/This "works" because CRTDUPOBJ with DATA(*YES) does not invoke any triggers on the "from" file (or the "to" file)./

All the best,

Mark S. Waterbury

> On 8/29/2012 4:12 PM, Peter Connell wrote:

Several years ago I implemented a read trigger that is applied to certain files. Specifically, those files where any fields contain data covered by legislative constraints.
The regulations mandate an entry in a log whenever the data is accessed, primarily as a record of the user and the reason for access.
The read trigger is designed to perform as efficiently as possible despite being called frequently, e.g. when a large file is read from start to end, and was implemented without any significant degradation on system performance.

However, there are times when large batch jobs may be exempt from the regulations. As there was no known way to dynamically prevent a trigger from firing, the trigger is designed to abort immediately where there is an exemption.
I would be interested to know if, at V7R1 there may now be a way to essentially override a trigger during a specific application while at the same time remaining operative for other applications.

Peter