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



I documented the latest incarnation of the standard technique I have been using for many years here: https://www.itjungle.com/2015/03/03/fhg030315-story01/



On Feb 2, 2020, at 3:50 AM, Frank Kolmann <frank.kolmann@xxxxxxxxx> wrote:

I agree with Booth. Leaving records locked for a long time can cause you a host of problems.

Its been a long time since I have done coding. But I just had to but in on this point.
For interactive jobs where you are relying on a user to press the F9 update key, never lock the record on read.
Batch jobs in the main dont need to have competing lock logic, the system manages this for itself.


for example
. A user opens a record for update then goes to lunch. In the meantime another job crashes because it needs the record.
. Multiple jobs attempt to open records for update, and each are waiting for the other to complete,

It is simple to code logic that detects if a record has been updated (I had an update number field) If you dont have an update number you can have the whole record in a DS.
then, nicely ask the user to refresh the screen data with F5 because the record was changed. (If a change is detected)
In my experience this message rarely occurred and when it did happen the recovery was a simple, press F5 and try again. This was a much easier process to manage than to recover crashes.

I implemented a system standard on how updates had to be coded. Programmers disagreed with me and then received poor performance reviews which had other more personal consequences.
I had the code changed by a different programmer or changed it myself.


Am 31.01.2020 um 20:31 schrieb Booth Martin <booth@xxxxxxxxxxxx>
As to the locked record issue; at the very least, why add to the problem? Consider NOT locking on the read chain, rather wait until the update chain.

No. Someone else could update the record then and after UPDATE, the changes from before are gone.
Yes, I could compare field values for changes and try to merge them in a meaningful way. Or rely on the user to pick which values shall get overwritten. Way too much logic when a simple lock prevents this problem >from happening in the first place. I try to adhere to the KISS principle.

Regards Frank
--
This is the RPG programming on IBM i (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxxxxxxxx
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: https://amazon.midrange.com


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.