Re: Record Lock under Commitment Control -- MIDRANGE-L

When I design maintenance programs for files with rows having high activity
(like orders entered yesterday), I add a screen timeout. This generally
solves the problem of a user wandering off when a row is held in update
mode. The ILE RPG program declares *CHG-level commit, so when the
screen times out with a 01331 return code, I roll back the transaction
(which unlocks the record) and return to the prompt screen. Other programs
can read the row being updated if it's locked but they see what's in the
database and not what the user is doing.

When the record is held during the editing process, it's using "pessimistic
locking". "Optimistic locking" occurs when the lock exists only when the
changes are committed to the database; this approach generally requires
much more effort to implement because the update program has to determine
if a change (from another process) to the data occurred while the data was
being edited. The application logic to track dependencies between columns
can add another level of complication to a program.

When updating multiple tables, be sensitive to the potential for the
"deadly embrace". My approach has been to grab the master.header record
first in update mode, even if I don't need to update it; this acts as a
semaphore to other update programs. If you grab a detail record to update
first in some programs and the header in others, you're begging for a
problem. Record wait timeouts will address the issue but they're messy and
IMO bad practice.

For batch programs, I add long wait times with OVRDBF. If the interactive
programs time out in a minute or two, most batch programs won't be affected.

Some levels of commitment control will prevent read-only access as well.

One approach to reduce the impact of record locking is to design a
well-normalized database. Example: don't put your sales history figures in
the customer master; put them in history files keyed by account number and
date.

On Tue, Feb 22, 2022 at 10:56 AM Matt Olson via MIDRANGE-L <
midrange-l@xxxxxxxxxxxxxxxxxx> wrote:

We have this issue with Green Screens holding a lock on a record that a
person is currently editing. Causes havoc with our other systems. If
someone goes into update mode on a screen, then leaves their desk the
record is locked the whole time.

-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of
Vinay Gavankar
Sent: Tuesday, February 22, 2022 10:44 AM
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Record Lock under Commitment Control

CAUTION: This email originated from outside of the ARRT. Do not click
links or open attachments unless you recognize the sender and know the
content is safe.

Hi,

I have a job running under Commitment Control with Lock Level of *CHG and
Scope of *JOB.

Program A (RPGLE), which is in the call stack, opens a file with Commit,
reads and updates a record in the file. Another Program B (RPGLE), which
comes later in the call stack, also opens that file with Commit, but when
it tries to read the same record, finds it locked.

I found this under IBMs Commit Lock Level documentation:
Within the same job, a program can change a record that has already been
changed within the current transaction as long as the record is accessed
again using the same commitment definition. When using the job-level
commitment definition, the access to the changed record can be made from a
program running within any activation group that is using the job-level
commitment definition.

I am new to using commitment control. I understand that the record will be
kept locked until the transaction is committed, but I was thinking that
another program in the same job opening the file under Commit should be
able to access it. Can someone please provide some insight into this.
TIA
--
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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.midrange.com%2Fmailman%2Flistinfo%2Fmidrange-l&data=04%7C01%7Cmatt.olson%40arrt.org%7C599ee7622d144549fabd08d9f6228b27%7C51c99a9cbb9a4dc7ac91464d50cc8d1f%7C1%7C0%7C637811450499682988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=OfbNNzXlMtczUQv%2FH73qolmZvEXzyGnN9OAUGY0XomU%3D&reserved=0
or email: MIDRANGE-L-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives at
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.midrange.com%2Fmidrange-l&data=04%7C01%7Cmatt.olson%40arrt.org%7C599ee7622d144549fabd08d9f6228b27%7C51c99a9cbb9a4dc7ac91464d50cc8d1f%7C1%7C0%7C637811450499682988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=QdmP2kjPHDP0nbNqK5fHCeLeJu6ZYyoQeek7A2qHu1A%3D&reserved=0
.

Please contact support@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

Help support midrange.com by shopping at amazon.com with our affiliate
link:
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Famazon.midrange.com%2F&data=04%7C01%7Cmatt.olson%40arrt.org%7C599ee7622d144549fabd08d9f6228b27%7C51c99a9cbb9a4dc7ac91464d50cc8d1f%7C1%7C0%7C637811450499682988%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=J92uLCCh5EGxYStmAAmUIUpH1k02pGSezKVdX4Cx9y0%3D&reserved=0
--
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