× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.