Re: ILE, Activation groups, and files staying open.

Gerald,

The basic problem is that you need to know more about ILE (and particularly scoping) when mixing ILE and OPM.

By using *CALLER a lot you are possibly causing "real" ILE programs to run in the default Activation Group.

Changing command default to *CALLER is probably not a good idea.

You can usually avoid scoping problems by the simple expedient of changing OVR scope to *JOB.

I suggest you read our "7 Deadly Sins" article and see how many you are committing. I'm proud to say (and a little sad at the same time) that this article is now used as IBM's primary resource reference for Activation Group and ILE problems! If nothing else it will tell you _why_ some things are not a good idea. You can find it here; https://authory.com/JonParisAndSusanGantner/The-Seven-Deadly-Sins-of-ILE <https://authory.com/JonParisAndSusanGantner/The-Seven-Deadly-Sins-of-ILE>


Jon Paris

On Jun 2, 2021, at 5:59 PM, Gerald Magnuson <gmagqcy.midrange@xxxxxxxxx> wrote:

yes, 1/3 of our programs (not in the above list) are OPM.
if I refine my statement from "remove *DFTACTGRP from the environment" to:
in my _ILE_ programs that are currently *DFTACTGRP, should I change them?

Most of my confusion is trying to understand the effect of _ALL_ the
different scenarios
ILE *DFTACTGRP calls OPM calls ILE *CALLER
ILE NamedGrp calls ILE *CALLER
etc...






On Wed, Jun 2, 2021 at 4:31 PM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

"Prescription without proper diagnosis is malpractice." -- Just saying
...

Does your shop have any OPM *PGMs (CLP, RPG/400, etc.) in use? OPM
(original program model) programs MUST and WILL ALWAYS run in the default
activation group. (Perhaps IBM should have named it the "*OPM" activation
group.)

Hence, there is no way to effectively totally "... remove *DFTACTGRP from
the environment ..."

On Wednesday, June 2, 2021, 05:20:46 PM EDT, Gerald Magnuson <

gmagqcy.midrange@xxxxxxxxx> wrote:

this is jumping ahead but...
is the real proper "fix" to remove *DFTACTGRP from the environment?

and if so,
1) what will break as we do this?
2) will just putting all programs in our named activation group KNAPACTGRP
the proper place?
3) shall we also move QILE to the KNAPACTGRP?


On Wed, Jun 2, 2021 at 3:40 PM Gerald Magnuson <gmagqcy.midrange@xxxxxxxxx

wrote:

I ran a SQL that lists out a count of ILE programs by activation group:
*DFTACTGRP 2212 programs
*CALLER 1398 programs
QILE 567 programs
KNAPACTGRP 18 programs
CALLER 2 programs

our menusystem programs are created with the KNAPACTGRP activation group,

also:
looking back in our post release upgrade CHANGE COMMAND DEFAULTS program,
we are setting the default on CRTBNDRPG ACTGRP(*CALLER) ..... :(
not sure why, but possibly to get overrides to function properly.



On Wed, Jun 2, 2021 at 3:27 PM Gerald Magnuson <

gmagqcy.midrange@xxxxxxxxx>

wrote:

This program had DFTACTGRP(*NO) ACTGRP('PRMPOLOG') // the program
name was the actgrp name...

now, this program does many CALLS (prototype calls), and I would guess
that some of those may indeed be *CALLER or *DFTACTGRP,
and looking upstream, there may be programs calling this prompt handling
program that are *CALLER or *DFTACTGRP.

I just did a scan on our RPG programs, and I do have 46 programs that
have DFTACTGRP(*NO) ACTGRP(*CALLER)



On Wed, Jun 2, 2021 at 3:17 PM Mark Waterbury <
mark.s.waterbury@xxxxxxxxxxxxx> wrote:

Gerald,

With "ILE" the old saying "A little knowledge is a dangerous thing"
comes to mind.

What is specified for ACTGRP when the "free standing" programs are
created ... was it
ACTGRP(*CALLER)? If it is *CALLER they can get activated into many
different activation groups, probably NOT what you intended ...

What was specified for DFTACTGRP? *YES or *NO?

*INLR does not necessarily do what you think it does, depending on
answers to the above. If DFTACTGRP(*NO) was specified, and
ACTGRP(*CALLER) was specified, then *INLR is probably almost "useless."

A "quick fix" might be to create a new named activation group,
ACTGRP(FREESTND), and ensure all the "free-standing" programs are

created

with that activation group specified. That way, they should all stay

there,

rather than getting copies activated all over the place.

Worst case is when ACTGRP(*CALLER) programs get invoked in the
*DFTACTGRP... then you have much bigger problems to deal with!

Hope that helps,

Mark S. Waterbury








On Wednesday, June 2, 2021, 04:00:42 PM EDT, Gerald Magnuson <
gmagqcy.midrange@xxxxxxxxx> wrote:





the prompt programs are free standing rpgle programs. they seton LR
before each return statement, and at the bottom of the main line.



On Wed, Jun 2, 2021 at 2:56 PM Jon Paris <jon.paris@xxxxxxxxxxxxxx>
wrote:

I'd need to know more about the actual call sequence to be able to

offer

any real suggestions. Also are you using free-standing programs as

the

helpers in that separate AG or are these Service Program routines. If
programs do they set on LR or ... ??


Jon Paris

On Jun 2, 2021, at 3:06 PM, Gerald Magnuson <

gmagqcy.midrange@xxxxxxxxx>

wrote:

we have several "generic prompt/select" programs ("F4 programs")

that

are

called to allow a user to select a value, and return it back to

it's

calling program. Currently it is in its own activation group (don't

know

why)

looking at a users job, which has been running for several hours,

they

have

260 open data paths, and the same file is listed as being open many

times

in the same activation group, (and in different activation groups

as

well).

we only have 3 or so named activation groups, along with *CALLER,

QILE,

and *DFTACTGRP in our environment. However, looking at the Display

Open

Files screen, I see files open from one activation group, then

another,

then another, then back to the first, then another, etc.

Questions (sorry, I am just not understanding ILE...):
As we enter these prompt programs, exit, and later return to them,
shouldn't the opens be reused, and not opened again?
Is this a symptom of us having a mix of named, QILE, *CALLER, and
*DFTACTGRP programs?
Would I not have as many open data paths if we had most ALL of our

programs

compiled as the same activation group?
--
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.

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

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

Help support midrange.com by shopping at amazon.com with our

affiliate

link: https://amazon.midrange.com

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

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
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.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

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

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com
--
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.

Help support midrange.com by shopping at amazon.com with our affiliate
link: https://amazon.midrange.com

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

Help support midrange.com by shopping at amazon.com with our affiliate link: https://amazon.midrange.com