Re: 5250 and un-do

On 12/18/2017 3:12 PM, Booth Martin wrote:

if my process changes FieldB and during that process another process has
changed FieldA then using a record-updated counter has no relevance.  My
update to FieldB is still appropriate.

Henrik has good advice regarding making the database more normalised.
It /is/ good advice, but that doesn't really address the primary
conceptual difficulty implementing an undo function in RPG: Unit Record
I/O. Let's assume for the sake of discussion that FIELDA and FIELDB are
ADDRESS and CITY, and thus are both natural attributes of CUSTOMER.

For just a moment, imagine a hypothetical design where you've build a
dozen, a hundred logical files; each one nothing more than the key and
one field. So there's ADDRESSLF, CITYLF and so on. Now, when you
update ADDRESS, you do so through the LF, and there are no stale CITY
contents to accidentally get updated along with ADDRESS.

I know, you're already saying that's way too much work. But once you've
seen that it is possible to design one architecture where the 'stale
record' problem simply doesn't exist, you are free to consider other
possible architectures.

One possibility is keyword:value. Imagine queuing up your changes not
by trying to store an array of records, but by storing keyword:value
sets. If the user changes ADDRESS from 123 Main St to 1325 Congress St,
then you could store the following in your 'transaction' array:

ADDRESS:123 Main St:1325 Congress St

You could use dynamic SQL to ultimately execute the database update
because SQL can do

UPDATE CUSTOMER SET ADDRESS = '1325 Congress St';

...and not disturb CITY, which a different process (address
standardisation) might be changing from Rotterdam to Schenectady for
this customer's address.

The point of this post isn't to propose THE answer, but to propose that
our limiting factor toward 'progress' (whatever that may be) is Unit
Record I/O.

I'm quite certain that the immediate reaction by many is going to be
'the performance will be terrible!' I would suggest that without a
more... concrete model to work with, such a conclusion would be
premature. If we're talking about a spreadsheet-like application where
there are a few hundred of these undo-able changes, will the performance
difference really be all that noticeable to the end user?