Re: Allow repeated change.

[CRPence <CRPbottle@xxxxxxxxx>]

Alan Campin wrote:
> Can someone give me a better explanation of Allow Repeated Change
> on the ADDPFTRG command.
>
> The docs don't really seem to say anything. They say allow
> repeated change but don't describe what a repeated change means.
>
> Allow Repeated Change (ALWREPCHG)
>
> Specifies whether repeated changes to a record within a trigger
> are allowed.
>
>  *NO  Repeated changes to a record within a trigger are not
> allowed.
>  *YES Repeated changes to a record within a trigger are
> allowed.

  The Allow Repeated Change first enables changing the new row 
image in a *BEFORE [insert or update] trigger program.  IIRC the 
Allow Repeated Change also refers at least in part, to whether 
another trigger [in sequence or recurse] is allowed to also change 
the new row image; i.e. repeatedly the row image may be changed, 
versus only changed by *this* trigger, such that changes to the row 
image\buffer in a ALWREPCHG(*NO) trigger will not be applied to the 
inserted or updated row.  I believe it also means that an UPDAT [or 
equivalent, a language-specific feature for an UPDATE] can perform 
against the row [for which the triggered I/O has already effected 
allocation under isolation] without a record lock error; i.e. with 
recursion for *BEFORE, or in an *AFTER trigger.

  I made some code changes in QDBUDR [update code path] to make the 
two settings function correctly, to keep LIC DB and the OS DB in 
sync, as I recall across triggers with changing settings.  But sadly 
I do not recall the details.  I am not too sure if\what was the PTF 
[cover letter] that might explain some details.  Thinking more on 
that, I may have had to defer the changes awaiting more LIC and\or 
Commitment Control [QTN*] changes, so if the PTF was completed by 
someone else, any description of what the PTF effected may be 
lacking.  The following PTF seems somewhat like what I recall making 
changes for:
http://www-01.ibm.com/support/docview.wss?uid=nas3b8095689156314888625735a0057def2

  In an SQL trigger the behavior is Allow=*Yes with no ability to 
change.

  There is a Redbooks document which gives some description [10.7.3 
& 11.4.5] for ALWREPCHG(*YES), beyond what is given in the quoted 
help text; perhaps clarifies what I allude above:
http://www.redbooks.ibm.com/abstracts/sg246503.html?Open

Regards, Chuck