To bypass “last used date” is not much different from telling the system to give misleading audit info. A RTVQMQRY seems to me to be a legitimate usage of the query. Someone might have a good answer, but it might need to be implemented with care in any regulated environment.

Tom

Our documentation utility uses the command for analysis. Updating date last used is misleading. Other commands such as DSPOBJD doesn’t update the object as being used.
I use this command to identify files used in queries.

Other commands such as DSPOBJD doesn’t update the object as being used.

True, but DSPOBJD doesn’t quite access the object. It only accesses the description of the object (Display Object Description) which is a fairly minor part of a (compound) object. It’s kind of like the difference between a prototype or a *CMD definition and the procedure or command-processing program behind them.

RTVQMQRY goes inside of the object and provides output that technically needs to be tracked to verify whether or not it was executed.

I use this command to identify files used in queries.

Note that RTVQMQRY only identifies files that were used to create the queries. It doesn’t identify which files are actually used by the query at run-time. The files that are used may be specified when the query runs.

However, I understand what you mean. It is, of course, technically possible to set Last used date to be whatever you want. (Websense is effectively stopping me from finding useful links for you.) But every such procedure tends to bring even more difficult audit and control problems. Maybe I can link to one later.

The Change Object Description (QLICOBJD) API might provide a combination that lets you think up a workable counter to the behavior of RTVQMQRY. I haven’t figured one out for myself. You might retrieve Last used date before running RTVQMQRY, and use the API to store the date in the Source file date/time header field. Not very satisfying.

Tom