×
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.
On 20-May-2016 13:49 -0500, CRPence wrote:
<<SNIP>> If UPDDELINS(*NO) on registration is not what can be
used or is not functional for the desired effect <<SNIP>>
Poking around a bit, apparently there was an enhancement in DP4 v8.1
[per a snippet I found on the web, a "What's New" in the announcements]
that enables the UPDATE to remain an UPDATE at the target versus being
implemented as a paired DELETE\INSERT; i.e. perhaps despite intention to
have the "UPDDELINS(*NO) on registration", that specification was either
disallowed or did not give the desirable effect of allowing the update
trigger to fire at the target system(s).
"What's New in Replication for iSeries
DB2 DataPropagator for iSeries, V8.1 made a major overhaul in its
architecture with the purpose of providing the following improvements:
...
• New option for replicating changes to target-key columns: In V7.1, you
could ensure that changes to key columns were replicated properly to
your target tables by registering your source table to capture updates
as delete/insert pairs. This option works fine except that more CD rows
are generated as a result. In V8.1, you have a new option to address
this problem. When you define a subscription set member, you can specify
whether the Apply program should use the before- image values or the
after-image values when it builds the WHERE clause using the primary-key
columns in its predicates. The use of the before- image value allows you
to avoid the conversion of an update to an insert. If you choose to use
this option instead, your registration should specify the before-image
columns as well.
..."
As I interpret that, seems the Add DPR Registration (ADDDPRREG) must
specify *BOTH for Record Images (IMAGE) [and the file journaled that
way] *and* keeping the [defaulted] *NO specification for the Update
Using Delete/Insert (UPDDELINS). I can only presume that, prior to the
aforementioned enhancement, that the effect for UPDDELINS was either
forcibly changed to *YES despite the opposite specification [and
hopefully a diagnostic\warning was logged], or that the registration
failed [with an exception] when the value *NO was defaulted or specified.
FWiW: Please note that the Program number 5761-DP4 Program name DB2®
DataPropagator for i, V8.1 was withdrawn from marketing last year and
software service is discontinued at the end of this month; "The
replacement product is IBM InfoSphere® Data Replication (5725-E30),
which is available for ordering through the Passport Advantage® (PPA)
system."
[
http://www.ibm.com/common/ssi/printableversion.wss?docURL=/common/ssi/rep_ca/2/899/ENUSLP15-0192/index.html]
midrange.com
