RE: Starting out with sub-procedures

Doug,

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

This is not the way that I understood it.  I thought that a
CALLLVL(*JOB) override existed until deleted, or the job ends.  

I wrote a one line CL that issues an override and then exits.  When
OVRSCOPE(*JOB) is specified the override is still visible from DSPJOB
#15 after the program exits.  When I do that command without specifying
OVRSCOPE (which then is implicitly *CALLLVL because I am running in an
OPM CLP) the override is not visible after program completion. Am I
missing something?

                        
Andy Holmer
1095 Nimitzview Drive
Suite 403
Cincinnati, OH 45230
(513) 232-9100
f-(513) 232-9249


-----Original Message-----
From: Douglas Handy [mailto:dhandy1@xxxxxxxxxxxxx] 
Sent: Sunday, October 26, 2003 6:07 PM
To: RPG programming on the AS400 / iSeries
Subject: 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.


> 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
_______________________________________________
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.