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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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.