Re: SQL Commitment Control and CPF5032

[Steve Richter <stephenrichter@xxxxxxxxx>]

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