To your first question - these messages are specific to SQL. They are put into the job log when you merely use STRDBG, even without specifying a program. I assume it is the DB SQL processes that are checking whether the job is in debug, then sending the messages to the job log. It'd be easy enough to check an attribute of the debug session - then send the messages or not, as specified.
So if I were to think of a parameter on STRDBG, it'd be specific to SQL optimizer messages, since that is the only thing that adds these extra messages to the job log.
This would not be something for any generic feature - SQL optimizer only - and the parameter would something like INCLOPTMSG(*YES) or *NO.
It is not always wise to try to provide the design or implementation details when asking for a feature. So I would say, make the DCR or COMMON requirement somewhat general in this regard. IBM architects will need to figure out where the best/easiest/most appropriate place is for activating such a feature.
Back to STRDBG, it just seems the easiest place to manage this - maybe not in a theoretical model, but in daily usage. QAQQINI is just a lot more arcane, seems to me - hey, you even have to know about a special stored procedure! Command parameters are just SO much easier to deal with - one of the beauties of the original design of this interface.
Cheers
Vern
----- Original Message -----
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
