On 09 Sep 2013 14:34, Vern Hamberg wrote:
This might almost be a nice option on the STRDBG command,
But the SQL [and Query Engine] Debug Messages are specific to the
Query and SQL features. If there was a /debug component/ feature that
would be invoked by the other components [e.g. by QQ:Query and SQ:SQL],
as is the case for the trace facility, then I could see that command as
the source of the activation [and CHGDBG to modify the setting].
But as an option added to STRDBG, would that essentially be asking
any generic feature that checks if debug is active, to then inhibit
their logging based on some debug attribute.? If the debug
component\feature externalized such an option, would the parameter be an
Off\On [e.g. DBGMSG(*YES|*NO)], or maybe a logging level [e.g.
DBGMSG(*NONE|1:99|*MAX), or perhaps a multi-element list to offer which
components should have their debug messages logged [and would the list
be just OS components or some user-defined as well]?
IMO the feature that owns the logging really should be asked\informed
to log or not to log; each such feature already should be doing that
anyhow, so making a flag available additionally from the debug feature
would seem to confuse the issue.
instead of requiring some entry in the QAQQINI, which is relatively
less simple to manage for things like this.
Of course there is the Override_QAQQINI stored procedure to override
the Query INI options instead of choosing a Query Options Library
(QRYOPTLIB) of the Change Query Attributes (CHGQRYA).
http://pic.dhe.ibm.com/infocenter/iseries/v7r1m0/topic/rzajq/qryoptf.htm
_i QAQQINI file override support i_
"If you find working with the QAQQINI query options file cumbersome,
consider using the qsys2.override_qaqqini() procedure. Instead of
creating, managing, and using a QAQQINI *FILE object directly, this
procedure can be called to work with a temporary version of the INI
file. It uses user-specified options and values. The support relies upon
the QTEMP library, so any changes affect only the job which calls the
procedure.
...
Example Usage
..."
So that would make a nice requirement to submit - you'll want to say
what benefit it gives you, like what you've described here in this
post.
I still think the MESSAGES_DEBUG feature of the QAQQINI which exists
to enable and activate the Query Debug Messages irrespective of Debug
feature being activated, is the most appropriate implementation for any
change in function. There is apparently no capability to *deactivate*
the Query\SQL Debug Messages irrespective of Debug feature being
activated. AFaIK currently the values supported are *DEFAULT, *NO, and
*YES [the "default" is *NO]. Either the QQVAL of *NO could change to
mean "no logging irrespective of debug being active" or more likely...
to maintain consistently with past function and what I believe is a
consistency with *DEFAULT matching to exactly one of the non-default
supported values, a new value such as *SUPPRESS could be added to mean
"no logging of debug messages irrespective of the debug feature being
active in the job".
I [perhaps incorrectly] recalled that the precursor to the CHGQRYA,
the FRCQRYI, already had the capability to turn-off the query debug
messaging even while debug was active, but I do not have the command
[and help text] to review if that was the case. In a past message IIRC
I suggested if anyone has that [service only] command, that they could look.
midrange.com
