Re: override scope in a procedure

that's because the override exists only in the called procedure when the
procedure returns to the calling procedure (main or otherwise) that call
stack entry is removed and thus the override is gone since it occurs at
the call stack level.

Thanks,
Tommy Holden


From:
JDHorn@xxxxxxxxxxxxxx
To:
rpg400-l@xxxxxxxxxxxx
Date:
10/10/2008 09:02 AM
Subject:
override scope in a procedure
Sent by:
rpg400-l-bounces@xxxxxxxxxxxx



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.