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.