Re: *INLR -- RPG400-L

In CPF, OS/400 and IBM i, there was never any overhead to "reload PgmB into memory every time." WIth Single-Level Storage, all compiled *PGM objects, and all the other objects (*FILEs, *DTAARAs, etc.) are already "in memory" in the sense that they reside in single-level storage (on disk), and they only need to be page-faulted into real main main storage, that acts as a very large "cache" for the objects that are currently "in use."

There is some overhead for allocating static storage and initializing it, when each program first starts up. This allocation is part of "program activation" and is "per job."

Activation groups were added to OS/400 at V2R3, with the introduction of ILE. Prior to that, there was only the original program model (OPM) where all programs ran in what is now called the default activation group, aka. the "OPM compatibility mode."

For true ILE programs (that do not run in *DFTACTGRP), once a program is activated in an activation group, it ramains there, until end-of-job or until the activation group is disposed of (as can happen with "ACTGRP(*NEW)") via RCLACTGRP or at end of job.

This has little to do with setting *INLR *ON or *OFF in RPG. That is a carry over from OPM, where it still plays a part in the *DFTACTGRP.

So, what activation group(s) are specified for PgmA and PgmB? When they were created, were they compiled with DFTACTGRP(*YES), in other words, "OPM compatibility mode"?

One of the most expensive things you can do in OS/400 or IBM i is to OPEN a FILE. The "full open" (first time in a job) is most expensive, and subsequent opens of the same file, with SHARE(*YES) are somewhat less expensive, as multiple programs can "share" the ODP (open data path).

How many FILEs does PgmB OPEN?

You could improve performance by reducing the overhead of the file OPENs by changing PgmB from a stand-alone *PGM into a "subroutine" (procedure) within PgmA, and that way, you only open each of the files just once in the main job.

Another alternative is to make PgmB into a *SRVPGM with a single (in this case) procedure that does the work -- once the *SRVPGM is activated in an activation group, it remains activated until end of activation group or end of job (when all activation groups in the job are torn down).

Any time performane questions arise, your mileage may vary, and there are many factors to consider.

I hope this helps,

Mark S. Waterbury

On Wednesday, April 15, 2026 at 04:48:09 PM EDT, smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx> wrote:

If I have PgmA and it repeatedly calls PgmB, I know not setting on LR makes

the process faster because it doesn't have to reload PgmB into memory every

time.

The argument that we are having is related to PgmA submitting PgmB to enable

multi-thread processing. Does not setting on LR help in this case because

they are different jobs?

For example,

PgmA

    Do until shutdown

        Read Invoice Header File for unprocessed invoices

            If a new invoice is found

                Mark the invoice as In-Process

                Submit PgmB to process the invoice

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

--

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.

On Wednesday, April 15, 2026 at 04:48:09 PM EDT, smith5646midrange@xxxxxxxxx <smith5646midrange@xxxxxxxxx> wrote: