Re: 5250 and un-do

Sorry I use K.I.S.S. and that means that every logical file includes all
fields in the PF they are build upon
and btw, for what purpose would one change the address through a logical
file without any other information
that the PF key, it simply dosn't make sense so it is a theoretical
situation just designed to overcomplicate things.

On Tue, Dec 19, 2017 at 3:41 PM, Buck Calabro <kc2hiz@xxxxxxxxx> wrote:

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?

--
--buck

http://wiki.midrange.com
Your updates make it better!

--
This is the RPG programming on the IBM i (AS/400 and iSeries) (RPG400-L)
mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/rpg400-l.

Please contact support@xxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link: http://amzn.to/2dEadiD