RE: *INLR

A trigger program should always run in the *CALLER Activation group.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser
Modernization – Education – Consulting on IBM i
Database and Software Architect
IBM Champion since 2020

"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)
"Learning is experience … everything else is only information!" (Albert Einstein)


-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxxxxxxxx> On Behalf Of Marco Facchinetti
Sent: Friday, 17 April 2026 16:34
To: RPG programming on IBM i <rpg400-l@xxxxxxxxxxxxxxxxxx>
Subject: Re: *INLR

Agreed, *NEW is the wrong solution on transaction files while on common master data files that receive a few hundred updates per day it is not a problem and costs 0 Euro.

In the specific case of these triggers, the best solution was probably to have different programs based on the event on the record, in fact the recursion occurs when an update "triggers" an automatic write to the same file.

However, out of 350 RPGLE-type trigger programs, only three use the *NEW attribute, so I don't think I'm at risk.

I'll definitely have to consider eliminating the cycle from those three programs, but I think two problems could arise:
1 - Those who aren't used to those types of programs can easily make mistakes (30 years of habit is hard to undo).
2 - How do they behave with respect to the call stack? Our trigger programs make many decisions based on which programs are active at the time of the call.

Best regards
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno ven 17 apr 2026 alle ore 16:11 Charles Wilt < charles.wilt@xxxxxxxxx> ha scritto:

*NEW is a horrible idea for trigger (or recursive) programs...
*CALLER is the best practice for trigger programs

Why would you need a recursive trigger program?

And assuming you built it before we got linear main programs in ILE
RPG, which can be recursive.
Then a better solution would have been an ILE CL entry point using
CALLPRC to an ILE RPG subprocedure.

Charles

On Thu, Apr 16, 2026 at 6:03 PM Marco Facchinetti <
marco.facchinetti@xxxxxxxxx> wrote:

Agreed but with sbmjob you have both: init job + groups creation.

Untill now we used *New only for triggers programs (recursive).

Best regards
--
Marco Facchinetti

Mr S.r.l.

Tel. 035 962885
Cel. 393 9620498

Skype: facchinettimarco


Il giorno gio 16 apr 2026 alle ore 23:30 Charles Wilt <
charles.wilt@xxxxxxxxx> ha scritto:

On Thu, Apr 16, 2026 at 2:34 PM Marco Facchinetti <
marco.facchinetti@xxxxxxxxx> wrote:

If PgmB was designed to run in batch and isn't a program of a
few

hundred

lines, I wouldn't dare hope that everything will work just by

activating

LR

on exit. You should be sure it doesn't call other programs or
use

service

programs.
If you can guarantee this, you could save yourself the cost of a
new

job

with every invoice by modifying PgmB with ACTGRP(*NEW).

OP please don't. Calling a PGMB that uses ACTGRP(*NEW) in a loop
is

going

to hurt.
Not quite as bad as submitting PGMB to batch, but still, never a
good

idea.

If you've ever had IBM perform a performance analysis on your
system,

one

of the key things they report on is activation group creation and
destruction.
Why? Because it's resource intensive, requiring CPU and IO and
also

drives

up DB full opens.

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

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