RE: RE: Can an OPNQRYF be run inside an RPG program?

QCMDEXC is one of those funny programs that actually runs things like OVRDBF
commands one invocation up the call stack, so that it doesn't loose the
override upon return. It is a simply bit flip in the program template that
allows this to occur. 
Years ago we wrote a routine that allowed people to call a script (i.e., a
CL program) that ran nothing but OVRDBF commands and then return. Until
OS/400 V2R3, this was impossible to do outside of that routine.

Of course the OVRDBF command now has the OVRSCOPE parameter and while that
parameter does not do the identical task as that old routine we wrote, at
the end of the day you have an override that sticks upon return (if you
change the default).

But regardless of any of this, calling QCMDEXC to run a CL command is
virtually identically to running it in the caller's program.


-Bob Cozzi
www.RPGxTools.com
RPG xTools - Enjoy programming again.

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [mailto:rpg400-l-bounces@xxxxxxxxxxxx]
On Behalf Of qsrvbas@xxxxxxxxxxxx
Sent: Wednesday, October 12, 2005 8:51 PM
To: rpg400-l@xxxxxxxxxxxx
Subject: RE: RE: Can an OPNQRYF be run inside an RPG program?

rpg400-l-request@xxxxxxxxxxxx wrote:

>   1. RE: Can an OPNQRYF be run inside an RPG program? (Scott Klement)
>
>date: Mon, 10 Oct 2005 12:45:48 -0500 (CDT)
>
>> Maybe I'm over cautious, but I have been stung several times by OVRDBF
>> that didn't have the OVRSCOPE set to *JOB and the program running away
>> because the override was effective at that level.
>
>When the OVRDBF was run from within the SAME PROGRAM?!
>
>I can understand that when you're new to ILE you don't understand that 
>OVRDBF doesn't across activation group boundaries.  But if it's the SAME 
>PROGRAM, how could it possibly be in a different activation group?  How 
>can a program be in a different activation group than itself?

Late response, but I think there's an issue here that's causing confusion
and it should be cleared up.

The question that says "...the SAME PROGRAM" seems misleading. By
appearance, the OVRDBF is _not_ run in the same program; it's run in a
program that's one call-level deeper in the stack -- QCMDEXC (or QCAPCMD
or...). That leads to the appearance that the override might not be in
effect when QCMDEXC ends and returns back up the stack.

Further, QCMDEXC appears to be OPM rather than ILE since it's always been
used that way by many. (It's only 'appearance' because QCMDEXC was around
long before ILE and activation groups.) As such, there _can_ be an
expectation that it will run in the default activation group, possibly well
out of scope of the ILE program that calls it.

I saw a discussion of this once years ago. I simply took that discussion as
effectively fact since I never ran across anything that contradicted it and
it's always seemed to explain everything I saw when I used QCMDEXC to
execute an override.

In simple terms, it comes down to IBM writing QCMDEXC intelligently to act
the way we'd want it to. It's smart enough to know that overrides are to be
applied to the previous call level. Easy. End of explanation.

Now, I'm sure there's a much more detailed and satisfying explanation of
what actually happens; but I don't care. The practical fact is that it works
the way it works -- as if the override were executed directly within the
program that called QCMDEXC.

We simply don't have to care.

Tom Liotta