× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.