Re: override scope in a procedure

Hi, Jim:

I suspect you are seeing this behavior because your program is running in the default activation group (in "OPM compatibility mode").

Did you compile this RPG IV program with the CRTBNDRPG command, or option 14 in PDM? If so, DFTACTGRP(*YES) is the default. Or, perhaps you compiled this program and bound it with ACTGRP(*CALLER) and then it was called from another program that was already running in the default activation group?

This is important because you did not specify OVRSCOPE on the OVRDBF command, so it defaults to OVRSCOPE(*ACTGRPDFN) -- see the help text for this parameter value:

*ACTGRPDFN The scope of the override is determined by the activation group of the program that calls this command. When the activation group is the default activation group, the scope equals the call level of the
calling program. When the activation group is not the default activation group, the scope equals the activation group of the calling program.
Notice that overrides with OVRSCOPE(*ACTGRPDFN) behave differently when running in the default activation group than when running in an ILE activation group.

Hope that helps.

Mark S. Waterbury

> JDHorn@xxxxxxxxxxxxxx wrote:

Hi Scott
Thanks for the reply.
We have a long conversion process, still getting some stuff out of the 36
environment, that needs to coexist until we are done.
Sorry, I guess I'm not sure of the difference between using a procedure in
the existing program (not in a service program) and a prototype.
when I create a program like this
D qqcmdexc PR 1A D qqcommand 512A options(*varsize) const D /free qqcmd = 'OVRPRTF' + ' FILE(' + %TRIM(XXPRTF) + ')' + ' OUTQ(MIS_SYS/MONRDAR)' + ' USRDTA(ARADD)'; success = qqcmdexc(qqcmd) - does not work /end-free -call report program-
P qqcmdexc B D qqcmdexc PI 1 D qqcommand 512A options(*varsize)
const D D SUCCESS S 1 D qcommand S 512 /free SUCCESS=
'Y'; qcommand = qqcommand
; qcommandl =
%len(%trim(qcommand)); /end-free C MONITOR C call 'QCMDEXC' C parm qcommand C parm qcommandl 15
5 C ON-ERROR C EVAL SUCCESS=
'N' C ENDMON C C RETURN SUCCESS P qqcmdexc E the override only exists while procedure qqcmdexec is running. When I
leave the procedure, the override disappears. (I am running this in debug
and using dspovr to see the overrides).
When the program looks like this.
/free qqcmd = 'OVRPRTF' + ' FILE(' + %TRIM(XXPRTF) + ')' + ' OUTQ(MIS_SYS/MONRDAR)' + ' USRDTA(ARADD)'; exsr xcallqcmd; /end-free -call report program-
C XCALLQCMD BEGSR
C eval QQcmdl = %len(%trim(QQcmd))
C call 'QCMDEXC' C parm QQcmd 512 C parm QQcmdl 15
5 C ENDSR The override exists after the subrouting is finished processing.
Since we are not using different activation groups for functional purposes
within a job, we have tried scope(*job) also. This works most of the
time, but sometimes leaves an override that wasn't being expected (Qsysprt
being a good example). I am concerned that the whole system being
originally designed with the concept of calllvl scoping, we could run into
unforseen consequences when we implement program changes and the new
programs wind up being called from older, non ile, programs.
Thanks again
Jim
----------------------------------------------------------------------

message: 1
date: Thu, 09 Oct 2008 22:12:50 -0500
from: Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>
subject: Re: override scope in a procedure

JDHorn@xxxxxxxxxxxxxx wrote:
> I am trying to write a procedure or service program call to execute
> override printer file commands.

A procedure *or* service program? Did you mean to say a procedure *in*
a service program?

> It seems that in either case the scope of the call level is greater
than
> the call level of the program that called it.

Yes. That's the way procedures work, each call to a procedure creates a
new call level.

> Is there a way, other than using creating a string and calling
qcmdexc
> using Call/Parm to get the override to be at the same level as the
calling
> program?

You don't have to use call/parm -- you can (and should!!) use a prototype.

But, if your override logic is complex enough to warrant calling a
procedure (not just a prototype) then you might consider using
OVRSCOPE(*ACTGRPDFN) and running your program and override subprocedure
in the same ILE (non-default) activation group.

You see... the call-level only matters when you use OVRSCOPE(*CALLLVL)
or when you run your override from the DFTACTGRP. When using proper ILE
activation groups with *ACTGRPDFN the override applies to the entire
activation group, regardless of call stack level.

That's one of many ways that activation groups make life better.

This email is intended only for the person or entity
to which it is addressed and may contain information
that is privileged, confidential or otherwise protected
from disclosure. If you are not the named addressee
or an employee or agent responsible for delivering
this message to the named addressee, you are not
authorized to read, print, retain copy, and disseminate
this message or any part of it. If you have received this
message in error please notify us immediately by email,
discard any paper copies and delete all electronic files
of this message.