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



the resolution was to set the activation group to *CALLER in all the
programs of the application.
Ahhhhrgh!! .. and then you run ILE programs in the default activation group
if they are called from an old OPM program!!!
I'd have a look at the STRCMTCMD and change the commitment level in this
command from *ACTGRP to *JOB!

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization ? Education ? Consulting on IBM i


"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)


-----Original Message-----
From: MIDRANGE-L <midrange-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Steve
Richter
Sent: Mittwoch, 23. Februar 2022 17:08
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: Record Lock under Commitment Control

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.

I had these same problems when first using commitment control

the resolution was to set the activation group to *CALLER in all the
programs of the application.

At first I had set all the programs to the same named activation group.
That worked OK. But SQL coded SQL procedures do not know about named
activation groups. The solution was ACTGRP(*CALLER) on all RPG programs.

-Steve



On Tue, Feb 22, 2022 at 11:44 AM Vinay Gavankar <vinaygav@xxxxxxxxx> wrote:

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://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

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

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.