RE: Trigger blocking

Been there. None of these options will work because CHGPFTRG will fail with CPF3202 (in use).
This is because online services have always resulted in the files always being open for IO, even before triggers were ever implemented on these files.

Peter


-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of CRPence
Sent: Thursday, 30 August 2012 10:33 p.m.
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: Trigger blocking

On 29 Aug 2012 16:42, Rory Hewitt wrote:

<<SNIP>> 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).
<<SNIP>>

If that claim about the Change Physical File Trigger command is accurate [about the exclusive lock no longer being a requirement; i.e.
no CPF3202 F/QDBTRIG2 T/QDBCHGTR, as was still the case in v5r3 and IIRC still in v5r4; I saw nothing in the docs nor anywhere else to confirm any change], then the trigger could be disabled before the file is opened in the job and then enabled again after the file is opened [given the change can still be effected while the file is open in the job; i.e.
no CPF3220]. Given the batch job was designed to open the file and keep that file open, then the trigger would not be activated for its I/O requests because whether the trigger is active is established upon open and thus is an attribute of the ODP. But all opens during that [even very brief] period of time while the trigger was disabled, would similarly lack triggered I/O requests.

Even if the exclusive allocation is [still] required to effect CHGPFTRG, the same means as noted above, still could be utilized.
However, the batch job would need to have established an exclusive lock on the file for the window of time that the changes would be made to *DISABLED and then *ENABLED, with the open request(s) between the two.
Unfortunately a database *FILE [effectively] can not be locked exclusively. The ALCOBJ locks a member with the specified lock state [the *FILE object is only locked with *SHRRD], so a multi-member [or only just capable] file would have to have all members locked, yet a locked member does not even prevent adding a new member... so depending on how the file is used, a semaphore [or something] could be required to fully ensure no other job was allowed to open any member of the file while the series of actions [the trigger being disabled, the file opened, and the trigger being re-enabled] were being performed, to be sure all other openers would have the trigger activated for their open requests.

--
Regards, Chuck
--
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