I can't find that first quote in the 7.3 ref, so maybe that's been improved.
Unless explicitly stated, I wouldn't apply anything in the LUW docs to IBM i.
-----Original Message-----
From: Mark S Waterbury [mailto:mark.s.waterbury@xxxxxxxxxxxxx]
Sent: Thursday, December 21, 2017 9:08 AM
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: 5250 and un-do -- ROW CHANGE TOKEN warning
Justin,
Relying on DB2 "ROW CHANGE TOKEN" if the table does not have a ROW CHANGE TIMESTAMP column is risky, as there exists the possibility of "false negatives." The IBM i DB2 for i 7.2 documentation does not explain this very clearly, it says only:
The ROW CHANGE TOKEN expression can be used for both tables that
have a row change timestamp and tables that do not. It represents a
modification point for a row. If a table has a row change timestamp,
it is derived from the timestamp. If a table does not have a row
change timestamp, it is based on an internal modification time that
is not row based, so is not as accurate as for a table that has a
row change timestamp.
The DB2 for LUW documentation says this:
Granularity of row change tokens and false negatives
...
*
The table does not have a row change timestamp column: a ROW
CHANGE TOKEN expression returns a BIGINT value that is shared by
all rows located on the same page. If one row on a page is
updated, the row change token is changed for all rows on the
same page. This means an update can fail when changes are made
to other rows, a property referred to as a "false negative."
* The table has a row change timestamp column: a ROW CHANGE TOKEN
expression returns a BIGINT derived from the timestamp value in
the column. In this case, false negatives may occur but are more
infrequent. If the table is reorganized or redistributed, false
negatives can occur if the row is moved and an application uses
the RID_BIT() value.
Draw your own conclusions. Henrik's technique is simple and time-tested and "proven" over the years. (For example, the LANSA product uses a variation of this technique for all FILEs defined as "maintained by LANSA.")
(You could just use a ROW CHANGE TIMESTAMP column directly in your applications to detect changes to the row by another user or job.)
Hope this helps,
Mark S. Waterbury
On 12/21/2017 9:34 AM, Justin Taylor wrote:
Henrik, you have a legacy system that's been proven in production for many years, and you don't want to change it. I can see that. What I can't see is people encouraging users to ignore IBM supplied tools and to reinvent the wheel on their own.
Db2 will give you a row token on read (no table changes required). If the token matches when you do your update, you're guaranteed that the row hasn't changed in the interim.
-----Original Message-----
From: Henrik Rützou [mailto:hr@xxxxxxxxxxxx]
Sent: Wednesday, December 20, 2017 2:07 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
<rpg400-l@xxxxxxxxxxxx>
Subject: Re: 5250 and un-do
If you really want to know it, it's and old habbit that goes back to 1977 - and if it isn't broken, works well and suits the purpose - why try to fix it?
And even in 2017, where timestaming isn't enough any more (no ns
support) - it still works ;-)
midrange.com
