On 05-Mar-2015 10:06 -0600, Charles Wilt wrote:
Been looking into a issue and thought I had a handle on it.
Till I realized for certain records, I don't see an update entry in
the journal as I expected.
Back to the code...after spending a an hour or so looking. I really
can't see how the UPDATE wouldn't have have been hit.
Then it hits me, for a few records, none of the values in the fields
of the file would have actually changed between READ and UPDATE.
IIRC, RPG by design won't actually do an update unless the buffer's
changed.
On 05-Mar-2015 11:15 -0600, Charles Wilt wrote:
...I realized it probably should have been "RPG (or the DB)"...
In other words:
read myfile;
wFld1 = fFld1;
wFld2 = fFld2;
fFld1 = wFld1;
fFld2 = wFld2;
update myfileR;
Wouldn't actually update the record in myfile.
Can anyone confirm that I'm not misremembering?
None of the HLL [e.g. RPG] run-time, the DM, nor even the OS DB could
appropriately dismiss an UPDATE operation that was coded in the HLL,
based solely on an equivalence determined between the /buffer/ before
the update and the /buffer/ after the changes applied to the buffer.
While the programmer has the option of coding a bypass of the UPDATE
within their program, the onus is on the programmer to decide whether
that [in]action is proper, in accordance with the definitions of their
application and database; notably the business rules, which esp. if
defined in the database, may depend on the program *not* coding to
avoid\omit the presumed-redundant request.
FWiW the interface to the UPDATE, via the DM, does not provide any
storage [to the HLL] for both a pre-update copy of the record and the
actual record within the provide buffer-storage. There is only one copy
of the record that is made available via the buffer provided by the DM.
The changes to the /record/ in the HLL are applied directly to that
buffer, and then the UPDATE operation uses the data in that buffer to
pass down to the database.
Any interface from the HLL down to the DB that might choose to make a
pre-update copy of the record in order to attempt such a comparison and
avoid the UPDATE if equivalent, would be a flawed interface. That is
because the DataBase is the arbiter of the I\O. Interfaces above the DB
would not easily be able to predict that the effect from the UPDATE
without any /perceived/ data changes, might actually effect physical
data changes, irrespective their [possibly false] conclusion such a
request would be redundant. Again, the programmer\application could
/know/ that coding the bypass was acceptable, but the HLL itself must
not presume the operation can be bypassed solely due to apparent redundancy.
At least some of the following may result in an effect whereby
physical changes will be visible, despite apparent equivalence of
pre-update and post-update buffers as compared immediately prior to the
UPDATE; the last item is presumably a means to ensure that even for an
apparent-equivalence scenario, the UPDATE should effect a change to the
physical data:
• [instead of] triggers
• with check option
• fieldproc
• row change timestamp
The lack of a journal entry being deposited for an UPDATE [that was
passed from the HLL via the DM to the OS DB and then down to the LIC DB]
is the domain of the LIC Journal feature:
<
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rzaki/rzakihowwrks.htm>
_How journal management works_
"...
_Journal receivers_
The system writes entries to an object called a journal receiver.
...
... If the updated physical file image after the update is the same as
the image before the update, and if the file has no variable length
fields, then journal entries are not deposited for that update. If the
updated data area image after the update is the same as the image before
the update, then journal entries are not deposited for that update. If
the attribute that was requested to be changed was already that value,
then journal entries are not deposited for that change.
..."
midrange.com
