The OVRDBF scope is the default, which is activation group, but according to the help, when running in the default activation group this is the same as call level.

It fails only occasionally.

I worked through the job log and the journal records again today. I can see from the journals where the records in the wrong file got updated and this matched the execution of the program in the job log. But at that point the OVRDBF should have been in effect and the other file should have been updated.

I still can't see any problem. Which is why I'm wondering if under the covers SQL is digging something out of the cache and re-using it incorrectly. But I admit that is a pretty long stretch.


On 5/26/2011 12:46 AM, Birgitta Hauser wrote:
What's the override scope of your override command?
Default? Default is Activation Group. If you are dealing with different
activation groups the override is only valid for the appropriate activation
Within an (program) the option *CALLLVL would be the best choice. With
*CALLLVL the override is valid for all sub-sequent call stack entries within
the call stack.
With override scope *JOB the override is valid for the whole job.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"

-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Sam_L
Gesendet: Thursday, 26. May 2011 02:00
An: midrange-l@xxxxxxxxxxxx
Betreff: Embedded SQL Ignoring OVRDBF

Has anyone experienced embedded SQL ignoring an OVRDBF and updating the
wrong file?

We have a CL program CLMAIN that contains conceptual code like this:


Program RPG_C is SQLRPGLE. It opens a cursor over A_FILE for UPDATE of
a couple of fields.

It iterates over the cursor conditionally doing “Update A_FILE set field
= value WHERE CURRENT OF …”. This should update A_FILEX because of the

<<Occasionally>> an execution of program RPG_C updates A_FILE instead of
updating A_FILEX. I have determined this by analyzing the journal
records. So far I have failed to recreate the situation in a test
environment--A_FILEX gets updated as expected.

I’m clutching at straws here, wondering if the SQL runtime is
occasionally missing the OVRDBF.

I don’t see how the OVRDBF could be removed, except by the DLTOVR at the
end of the program. The programs in CLMAIN run in the default
activation group so the OVRDBF is scoped to the call level. Some of the
programs use SQL, often with a mix of native IO. Some call CL programs
that may do overrides, but those overrides would be at a different call
level than CLMAIN and I can’t see how they could effect it.

CLMAIN is invoked from an RPG III menu program, probably via QCMDEXC.
CLMAIN can be run again and again from the menu, or may be executed
interspersed with execution of other menu programs.

We are on V6R1, but not up to date on PTFs.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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.