Re: Starting out with sub-procedures

JT,

>That was pretty much my understanding, except I didn't think about QCMDEXC
>being at a different call lvl.  Would the OVR still not in place, if
>CALLLVL(*ACTGRP) was specified in the CLLE, AND *MODULE was compiled
>*CALLER??  (Not done a whole lotta CLLE.)

The activation group, and in fact ILE in general, has *nothing* to do with the
problem -- other than the fact a procedure call in ILE introduces another call
level.  The problem here is the call level, not the language or environment used
to get there.

Let's look at it another way, using standard CLP and RPG III to make the point.

In the classic method of using overrides, you have a CLP driver which issues the
OVRxxx commands followed by a CALL to a RPG OPM program.  The OVRxxx takes
effect at the current level, or higher.  It thus affects the RPG program.

At the end of the RPG program, IMHO it is good practice to use a DLTOVR.
However, even if you don't, when the CLP which issued the OVRxxx ends and comes
off the call stack, the OVRxxx commands automagically are deleted by the OS.

Now, let's throw another intermediate CLP in the equation:

  CLPa calls CLPb which issues the OVRxxx and ends, then CLPa calls RPG

Will the RPG program see the overrides issued by CLPb?  No, because the
overrides only last while CLPb or higher is in the call stack.  If CLPb had
called the RPG program it would work.  But with CLPb ending, and CLPa calling
the RPG program, the overrides have already disappeared.

This is true without regard to ILE -- it has always worked this way since CPF
version 1, AFAIK.

Now substitute QCMDEXC for CLPb, and in theory you'd expect the overrides should
disappear when QCMDEXC ends.  However, because that would make QCMDEXC
ineffective for issuing overrides, it has always used smoke and mirrors (or
something) to make the OVRxxx take effect one level up -- that is the caller --
instead of at the level of QCMDEXC itself.  This means a RPG program can issue
OVRxxx via QCMDEXC and have the RPG program affected by it.  If RPG called a CLP
program instead, and the CLP issued the OVRxxx, the overrides would disappear
when the CLP ended because that is the way overrides work.

Now look at from the ILE perspective.  By using a procedure wrapper, you've
introduced a new call level just like RPG OPM calling a CLP to issue OVRxxx in
the paragraph above.  So the issue is *not* whether the override is scoped to
the activation group, the call level, or the job.  Those can make (or break)
whether an OVRxxx will affect things at the same call leverl or higher.

However, it still has no effect on things *lower* in the call stack.  And that
is why a wrapper procedure doesn't work for overrides.  You'd need to perform
the same smoke and mirrors as QCMDEXC does -- whatever that is -- but for two
call levels instead of one.  I don't know how QCMDEXC does that, so I don't know
how you'd extend it to two levels.

Am I making more sense?

The problem is strictly the call level and the fact overrides implicitly end
when that level ends.  It has nothing to do with ILE except that a procedure is
a new call level -- just like a nested CLPb in the OPM example above.

>Also, if CALLLVL(*JOB) is specified, does that only apply to *DFTACTGRP?? 

No, it applies to the job.  BUT, like all overrides, it implicitly goes away
when the call level ends.

> I
>sure THOUGHT I tried that in a CL where RPGLE was in different ACTGRP, and
>it didn't work.  I think this is one-a my main problems with the complexity
>of Activation Groups in the first place, is I'm not precisely sure how
>overrides work.

Activation groups are over-rated, IMHO, although I do admit to using them in
some situations to intentionally limit the effect of overrides.  However, the
root of the problem which led to my post has nothing to do with ILE or
activation groups.  Or at least not directly; only indirectly by virtue of a
procedure being a new call level.

Or at least that is how I understand it...

Doug