Re: Embedded SQL Ignoring OVRDBF

On 29-May-2011 17:46 , Sam_L wrote:

<<SNIP>>

At the start of the failing program I’m going to put in an OPEN of
A_FILE and check using the file info DS that A_FILEX is really being
opened. If it isn’t I’ll do a DSPOVR and produce a DUMP in an attempt
to distinguish between a SQL problem and an OVRDBF problem. Per your
suggestion I’ll also review the SQL communication area and see if it
shows the file opened in the cursor—if it does I’ll probably switch
to checking that instead of doing an RPG open of the file. Or maybe
I'll check both.

Consider performing the WRKJOB OUTPUT(*PRINT) instead, or in addition. The DSPOVR output is very specific to what is requested on the parameters, and if not properly formed according to requirements of the program issuing the request, the desired data may not get logged.

Consider adding a program call to a CLP at the beginning of the program as well, and to another CLP at the end of the program. Each CLP would then call another CL program dynamically, ignoring the condition where that program does not exist; or a fully dynamic call from the RPG, with a monitor to ignore a failure on the call. Each program that is called both dynamically and with non-existence ignored can be modified easily, in order to change if or what data will be collected, allowing for the data-collection programs to be replaced even while the application may be in use.

Having two exits from the application program allows the first CLP to record information like a pre-change date\time which could be utilized in the second CLP; e.g. to issue a DSPJRN to ensure that the file has not been updated within processing of the application program from which the exits were invoked. With the specific search parameters available on DSPJRN, a request could be done for that specific job and that specific program irrespective of date\time [if that program by name, should never have updated the file], and done only in the second exit, then a CPF7062 escape would indicate the issue had not yet arisen whereas any output would be cause to stop the processing with a wait on an inquiry reply. Even if nothing were coded initially for those CLPs as exits, they would be available later while having made only the one scheduled change to the application program.

DSPJRN JRN(libnm/jrnnm) FILE((prodlib/A_FILE)) RCVRNG(*CURRENT) JOB(&JN/&JU/&JN) PGM(RPG_C) OUTPUT(*PRINT) /* Given the receiver range can be assumed to remain the currently active journal receiver since the first exit, then no error CPF7062 indicates that a program named RPG_C updated file A_FILE in the named job! */
monmsg cpf7062 exec(goto done)
notgood:
sndusrmsg msgrpy(&rpyval)
if (&rpyval *eq '*N') then(dlyjob 15)
if (&rpyval *ne 'secret answer') then(goto notgood)
done: return

I think I’ll also do some scanning for OVRSCOPE(*JOB) in programs
that could have run <before> CLMAIN, but I don’t think that has been
used much. A_FILEX is a temporary copy the file and updated only in
CLMAIN. A_FILE is the real file and is used in most code without any
override, so I’m not hopeful, but you never know. <<SNIP>>

I think my mention for concerns for *JOB scoped override must have been off the mark. I just did a quick test, and from the results seen, I infer I had incorrectly recalled the reverse effect. Seems that a *JOB scoped override is _later_ in the search order than a call-level scoped override.?

Regards, Chuck