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.
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?
On 1/24/2014 1:21 PM, Gerald Kern wrote:
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
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>>