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
midrange.com
