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