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



If the record remains locked after an update, and assuming there are no
errors in the code, it's likely commitment control is active. After the
lock, you need a commit.

Remember, this is what commitment control does: it ensures all database
activities in a (business) "transaction" or "unit of work", are completed.
This goes back to a set of database properties known as ACID,
where a well-designed database system handles transactions as...

(A) Atomic--the transaction is one unit of work. All the tables are
updated or none are--it succeeds completely or fails completely
(C) Consistent--the process alway updates the database in a manner that
maintains the correct state of the database.
(I) Isolated--what one job does to the database doesn't affect other jobs
(D) Durable--once the transaction is done/committed, it won't undo itself
if the system then fails.

In my transportation management system, a typical dispatch operation of a
truck with 100 shipments on it will generate about 105 inserts and 109
updates. A combination of commitment control and OVRDBF WAITRCD allows
smooth processing of 5,000-10,000 orders in an eight-hour period without
any record locking issues. While there may be waits for a lock to release,
the robust design makes such issues invisible to users, system operators,
and the VP of IT. When the occasional network failure happens, there are
no pieces to pick up--the entire transaction is reversed.

Commitment control takes a bit of learning but it's worth it, especially
when you have a 24x7x365 operation.

On Wed, Feb 23, 2022 at 6:57 AM Patrik Schindler <poc@xxxxxxxxxx> wrote:

Hello Joep & Charles,

Am 23.02.2022 um 15:06 schrieb Joep Beckeringh via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx>:

In 35 years of coding RPG I have never seen this happen; with or without
commitment control. Whenever we found a problem with a record being locked,
it always turned out to be an error in the code.

I suggest you remove the UNLOCKs and try to find out what really was the
problem.

Been there, done that. Have no idea. The lock is removed only after
another record is locked from

If you want to try yourself, source code is here:
https://github.com/PoC-dev/as400-sfltemplates-german

I signed on twice, started the program, and put up the edit screen on one
record. When trying to do the same with the second signon, with the same
record, I got a "record already locked" error. That's when I added the
UNLOCKs.

:wq! PoC



--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxxxxxxxxxx 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.