Re: Tons of joblogs when debugging RPG with embedded SQL

On 16-Oct-2015 00:12 -0500, CRPence wrote:

<<SNIP>>
Unfortunately the value of that MESSAGES_DEBUG QQPARM specification
for Debug Messages [AFaIK still only supports the values *YES and
*NO] and the value of *NO means only _do not forcibly log_ debug
messages irrespective the use of the debug. They really need to add
support for a new special-value such as *OVRDBG or *NODBG that
suggests to override the effect to _no "Query" Dbg Msg logging_ even
when Debug is active; or here where I suggested *SUPPRESS instead,
and link several prior discussions where I think a similar suggestion
was made alluding that those who want a change in function probably
should be asking for just that:
[http://archive.midrange.com/midrange-l/201309/msg00383.html]
Subject: SQLRPGLE in STRDBG creates *a lot* of QEZJOBLOG entries

FWiW: An option I found documented [purely by chance, per searching in a page for "S_D" instead of fully searching "MESSAGES_DEBUG"], what appears to be an alternate capability for /internal/ purposes, [so /unsupported/ for /external/ to the lab purposes, except when dev is asking for assistance to debug an issue], apparently to log\redirect the debug messages to a Stream File (STMF) instead of to the joblog.? INSERT [and\or UPDATE] the value for QQPARM='MESSAGES_DESTINATION' to have QQVALUE='*IFS'; apparently logged to a file in the /tmp/sqe directory. I did not verify that parameter is unlisted in the regular docs, nor if the OVERRIDE_QAQQINI stored procedure in QSYS2 is enabled for setting that parameter [do not recall if there is an add\insert capability vs only update]; probably that routine just defers any validity checking to the triggers on the temporary QAQQINI file. Anyhow, that tidbit was found in a TechNote document here:

[http://www.ibm.com/support/docview.wss?uid=nas8N1018843]
Reference #: N1018843 Historical Number: 462591814
"Debug Information for V5R2M0 and Above for SQE Using Run SQL Script from iSeries Navigator

Technote (troubleshooting)

Problem(Abstract)

Once you have identified the query that is causing a performance issue, you may try running the same query through Run SQL Scripts from iSerise Naigator to verify the performance issue is reproducable. If so, this document gives the steps on how to collect further debug information for use by the IBM i Global Support Center.
Resolving the problem

Use the following steps to collect information when debugging SQE performance or database issues using Run SQL Script from IBM iSeries Navigator:

Alternative Debug Method can be found in Knowledgebase document N1011355 . Document N1011355 provides instructions for setting up the same trace described in this Technote document, but via the CALL QQQOOOCACH interface.
In order to use document N1011355, knowledge of the query's identifier (called a QRO HASH) is required. If you do not know the QRO HASH of the query you are about to trace, continue using this document.

Step 1: Create the QAQQINI file ...
..."