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

[CRPence <CRPbottle@xxxxxxxxx>]

  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>>