Re: SQL Commitment Control and CPF5032

the legacy program does not use commitment control? I would guess you
have to commit all changes before calling that program.

in general, whenever I have a problem with commitment control it is because
all programs are not running in the same activation group.

-Steve



On Fri, Mar 6, 2020 at 5:07 AM Paul Bailey <PabloMotte+Midrange@xxxxxxxxx>
wrote:

I am creating a new SQLRPGLE program, and this program uses SQL for all
file select/insert/updates, but right in the middle I need to call a
20-year-old RPG program that does a few required RPG updates to one or more
rows already amended by the calling program. The older program can not be
changed.

The new program was working perfectly, but there turned out to be some rare
situations where the data changes had to be backed out so I added some SQL
commit and rollback lines in appropriate places. Now the called RPG program
fails every time with CPF5032 (record locked to this job).

What is the best way to get the entire unit of work from the new and old
programs to be accepted, or rolled back in the case of an error? Do I need
to re-implement the older program, or is there a setting that will allow it
to update the locked rows?


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