Re: Trigger blocking

[Rory Hewitt <rory.hewitt@xxxxxxxxx>]

Peter,

So you might have two jobs accessing the same file *at the same time*, and
you only want one to fire the trigger?

That's not possible.

However, you have two options:

1. If the batch jobs will run when no other jobs are accessing the file,
you could (manually or programmatically) turn off the trigger by using the
CHGPFTRG command and specifying STATE(*DISABLED). You don't need exclusive
file access to use the CHGPFTRG command (unlike the ADDPFTRG and RMVPFTRG
commands).

2. Have a control data area in e.g. QGPL which contains the qualified name
of the job which is allowed to not log the file access. when the trigger is
first fired, it loads the value of the data area (using the QWCRDTAA API)
into a global variable. On every call, it simply checks that variable and
compares it to the current job (from the PSDS). If they are the same, it
returns immediately, without logging. This will likely add *some* overhead
to the trigger program.

I suspect that you have already implemented #2 - if so, you've almost
certainly hit on the only usable option.

Rory

On Wed, Aug 29, 2012 at 1:12 PM, Peter Connell <Peter.Connell@xxxxxxxxxx>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