Rory,
There are always concurrent apps that must not be blocked so option 1 is not possible.
I've already described the mechanism I use instead of option 2.
What I'm really asking is if IBM have since exposed a method to the user domain that can set some switch that they may already deploy within the system domain.
Peter
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Rory Hewitt
Sent: Thursday, 30 August 2012 11:42 a.m.
To: RPG programming on the IBM i / System i
Subject: Re: Trigger blocking
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
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing list To post a message email: RPG400-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/rpg400-l.
#####################################################################################
This correspondence is for the named person's use only. It may contain confidential
or legally privileged information, or both. No confidentiality or privilege is waived
or lost by any mistransmission. If you receive this correspondence in error, please
immediately delete it from your system and notify the sender. You must not disclose,
copy or rely on any part of this correspondence if you are not the intended recipient.
Any views expressed in this message are those of the individual sender, except where
the sender expressly, and with authority, states them to be the views of Veda.
If you need assistance, please contact Veda on either :-
Australia 1300-762-207 or New Zealand +64 9 367 6200
midrange.com
