Re: RUNNING DMPOBJ on a *QRYDFN shows file names not used in file selection?

If the Run Query (RUNQRY) modifies the definitional portion of the *QRYDFN object, then there is a rather large problem. The run-time should only ever make copies of any required definitional information into memory for its run-time purposes, and then release\dispose-of storage; never having written to any storage in the permanent *QRYDFN object. As originally designed, not even the updated access plan is written back into the *QRYDFN; probably still not.

It would be interesting to see the actual DMPOBJ output from which the conclusion was made that "the dump shows a file being used that clearly isn't" defined. And what was done to have "examined the query" to find there was "only one file used in the file selection", along with what was presented in the file selection list, also would be interesting.

Regards, Chuck

On 24-Jan-2014 12:28 -0800, Vernon Hamberg wrote:

Does running RUNQRY and specifying a file or files different from the
one(s) you used to define the *QRYDFN - does that cause this effect?
<<SNIP>>

On 1/24/2014 1:21 PM, Gerald Kern wrote:

<<SNIP>>

To search the queries we issue a DMPOBJ OBJ(YOURLIB/YOURQRY)
OBJTYPE(*QRYDFN) command which produces a spool file that we can
then copy to a data file and scan the data file for the file
name(s).

So we ran this utility last night it reported a file name being
used by a query, but when we examined the query we found there was
only one file used in the file selection, and that file didn't have
any dependent logicals on that physical.

So we are kind of stumped as to why the dump shows a file being
used that clearly isn't. Could this dump data be residual from
perhaps an earlier use where maybe the file name seen in the dump
was used in this query? <<SNIP>>