|
Lisa, > Can someone explain why you would do the OVRDBF with QCMDEXC in the RPG, > rather than in the CLLE that he already has? I always do it in the CLLE > (with NAG QILE) ... what's the advantage of doing in the RPG (other than > being more visible, I guess ... that has bit me a couple times!) This issue arises because of the scoping rules applied to file overrides. Scoping is controlled by the OVRSCOPE parameter of the OVRDBF command, and offers three possible values: *ACTGRPDFN *CALLLVL *JOB *ACTGRPDFN is the default, and the one that's bitten you in the past. That's because it tells the system to set the scope of your override differently, based upon whether or not you're running in the default activation group. When running in a named AG, your override is scoped to all programs running within the same activation group. However, when running within the DAG, it's actually scoped to the call level from where it was issued. So, in the example given previously, the override was out of scope as soon as control was returned from the CLLE procedure that issued it, because the call level was the call stack entry of the CL procedure itself. The use of QCMDEXE is recommended because it allows you to get around that little problem. When an override is issued through this API, the call level is the call stack entry of the procedure which invoked QCMDEXE - not the API itself. Thus, it results in the behaviour that you originally expected. Regards, John Taylor
As an Amazon Associate we earn from qualifying purchases.
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.