× 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.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

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.