RE: Issue with ovrprtf/dltovr (is this an activation group issue) - ANOTHER RELATED PUZZLE

Hi Mok,

<snip>
I have a puzzle that bothered me for at least 7 years. Thank you in advance
for an explanation.

I have this puzzle for several years and I really want to get an answer.

I have a CLLE program created by CRTBNDCL where the DFTACTGRP is *YES.

This CL will have two overrides first before it calls a RPGLR program.

The RPFLE program is created by CRTBNDCL where the DFTACTGRP is *NO and the
ACTGRP is QILE which is the named activated group defaulted by the system.


The activation group of the CL should then be the OPM default activation
group *DFTACTGRP (is that correct?) while the activation group of the RPG is
QILE. Why the override is still working properly? (Since the CL has a
activation group different from that of the RPG, I don?t expect the override
work. But it does work.)
</snip>

I think Kevin gave the explanation in a previous post, but just to clarify:

There are two points to consider in an override - the override scope and the
open scope.

The default value for override scope is *ACTGRPDFN - you took this because
it is not used in your command (uless you changed the command defaults).

If the override scope is set to *ACTGRPDFN then the open scope is determined
by the ACTIVATION GROUP in which the program which issued the command is
running.

This means...

If your CL program was running in a named activation group - the overrides
would be al activation group level and they WOULD NOT affect the RPG program
which is running in another named activation group.

If your CL program was running in the default activation group - the
overrides would be at call level and they WOULD affect the RPG program which
is running in another named activation group because it is CALLED by the CL
program.

This problem (Not having an ILE version of QCMD when running batch jobs) has
bitten al lof us at one point or another - whether we knew it or not. All
those "weird problems when running in batch" we get. :-)

My last problem was when we had a CL which performed a lot of overrides
before calling a print program. Our group created a CL to perform all of our
standard overrides so we could replace the ad-hoc overrides we had
everywhere. A call to this override program replaced all overrides in our
print CL. We tested (interactively :-) ) and it worked like a charm (we were
running in a named activation group in interactive mode) but wneh we
submitted a job it was a disaster. Why? Because the override CL performed
all of the overrides and then returned to our main CL, which then calle our
print program. The overrides scope was correct but the OPEN scope bit us
because it was using *CALLLVL and our original program performed the
overrides and calle dour print program. All worked. Changing our design to
put the overrides in another program was not very clever. The solution was
easy - we recompiled our main program to run in a named activation group and
the open scope changed to activation group level.

Learn from our mistakes! :-)

HTH

Larry Ducie