Re: checking a job for OPNQRYF

[CRPence <CRPbottle@xxxxxxxxx>]

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