× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Dan Rasch wrote:
I was monitoring a job that was not producing the results I expected, and found out there was an OPNQRYF that redefined my
world.

Is there a simple way to check for the existence of an OPNQRYF
in a job? I did not see it in the overrides.

Both TRCJOB and STRDBG enable a simple way to determine if an OPNQRYF was used [in a serviced process; with STRSRVJOB for another process]. The output from TRCJOB to either spool or database file can be reactively searched for the CPP [command processing program] for the OPNQRYF command; or command if *DATA is included in the trace. For an immediate notification of its use in a job being serviced and debugged [with STRDBG], the ADDBKP command [Add Breakpoint] can specify to break on statement '/1' of the CPP; that quoted slash-one indicates the debugger should stop on the first *instruction* of an OPM program object [syntax for instruction versus statement on the STMT() parameter].

FWiW the breakpoint could perform a notification by some means other than by the defaulted interactive "Display Breakpoint" panel. That is accomplished using the BKPPGM parameter on ADDBKP to specify that a user-defined breakpoint program should be invoked instead; see the help text for the parameter requirements of a breakpoint program.

When the debugged program is ILE versus OPM, or just as another option is to CHGOBJAUD to track *ALL activity on the CPP or the OPNQRYF *CMD command object. Then like with TRCJOB [reactively vs actively notified], after the job runs, review the output [but for example by DSPJRN of the QAUDJRN but with even more limited access than for debug activity] to see if an OPNQRYF was used in a particular job.

Unlike with only either query engine debug messages or auditing, trace and breakpoint can enable easily detecting from the flow or a stack, that the feature is invoked by\at the point pertinent for the application debug. That is, the breakpoint and trace enable context of the OPNQRYF invocation to be accessible whereas the relevance of any detected\logged OPNQRYF activity may not be intuitive from either of the joblog or auditing methods.

Regards, Chuck

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.