Re: Trigger blocking -- RPG400-L

It seems the easiest thing to do would be to have a version of the program
that simply returns with LR off. Put it in a special library that you put
at the top of the library list when you need it.

Albert

On Thu, Aug 30, 2012 at 12:42 PM, Peter Connell <Peter.Connell@xxxxxxxxxx>wrote:

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