Re: *INLR

In the end it does not really matter how the program is ended, what matters is are the files closed then opened again time after time. Also destroying an activation group and recreating it is a significant performance killer. It might be this sysem has sufficent horsepower to power through it, but it will eventually catch up.

This is precisely the use case that was pointed out earlier where the program should simply encode a data queue message and allow a data queue handler to run the required updates. Even if there needs to be communication back to the originator that can be done with a data queue as well. Much faster and scaleable to whatever size is needed.

That entire program sequence needs an upgrade to technology we’ve been using since the V4 days…...

Jim Oberholtzer
Agile Technology Architects
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> on behalf of Javier Sanchez <javiersanchezbarquero@xxxxxxxxx>
Date: Thursday, April 16, 2026 at 8:24 AM
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: *INLR

What happens if I'd rather use the Standard C API "exit()" within the RPG
program?

JS

El mié, 15 abr 2026 a las 17:40, Barbara Morris (<bmorris@xxxxxxxxxx>)
escribió:

On 2026-04-15 4:48 p.m.,
smith5646midrange@xxxxxxxxx wrote:

...
PgmB
Process invoice based on invoice number received
Mark invoice as Processed
** Note: no *INLR logic here
Return

VS

Process invoice based on invoice number received
Mark invoice as Processed
*inlr = *on
Return

If PgmB is the only thing that runs in a submitted job, the only
difference with ending LR-on or LR-off is the timing of when the files
are closed.

Setting on LR within the program means that files get closed explicitly
by RPG. Returning with LR off means that files get closed by the system
when the activation group ends (due to the job ending).

I don't know which is faster, but my guess is that the difference
(either way) is tiny compared to the cost of starting the new job and
doing the actual work of the program.

--
Barbara

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related
questions.

--
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@xxxxxxxxxxxxxxxxxxxx for any subscription related questions.