Re: Not authorized to STRDBG on Production, so can't use VisualExplain

I failed to note that I was running V5R3; sorry, I just _assume_ that when no release is stated, that one of either V5R3 or V5R4 is being used. I meant that the explain runs/displays, and I am simply not presented with any optimizer/debug messages in that separate tabbed window.

Of course probably no matter how a feature is replaced by an effective Trojan Horse, it is probably not a good idea, even if it can function. The more appropriate approach is to ask [by a design change request] for an enabler, perhaps via the QAUTPROF being granted *USE authority to STRDBG and that user running the start debug by adopted authority -- like is done for some other database function under iNav. I find it is odd that QCMDEXC is used instead of a specific stored procedure in the first place. Regardless... Although the request would be a qualified call, if that SQL qualified CALL is to a registered external procedure by name only, rather than an object, for example QSYS2.QCMDEXC, that can be replaced to redirect the call to another program which adds logic to make a decision to adopt or fail. If the call is directly to the QSYS.QCMDEXC *PGM object, then that object could be replaced, but as alluded, it probably would not be allowed on the production system. Although I may suggest it is possible, that is not a suggestion to effect it. :-)

However the STRDBG command itself is IMO, not really that harmful; well, not if developers can have *JOBCTL anyway. This is because debug of a specific program requires *CHANGE authority to the program. Thus the developers should be unable to start debug on any of the production programs, thus unable to cause harm by debugging those specific programs. Yet they would have authority to enable debug to both activate the optimizer debug feature at the server irrespective if via iNav, and to debug any CLP they might create.

The use of *LIBL/cmdname versus either QSYS/cmdname, *SYSTEM/cmdname, or *NLVLIBL/cmdname is an effective requirement for operating system code. Without proper qualification, then a Trojan Horse can activate without actual placement into the feature library. Although it may seem advantageous to take advantage of something like that, being able to might suggest that it is also more open to attack. It is generally not considered imperative to properly qualify for QSYS objects, because the ability to CHGSYSLIBL is restricted; I disagree. Nonetheless, it is poor coding, even if only because an eventual /correction/ to properly qualify the command, breaks legitimate attempts to /take advantage/ of the current unqualified coding. So when such advantage is taken, that is of an implementation detail, not of the actual design -- aka: working as coded, not as designed. Similarly command defaults are taken advantage of, and similarly the effective requirement is that all parameters must be specified; most notably at least, for those with possibly conflicting parameters, especially where values are mutually exclusive between parameters offering defaults. Of course exceptions may exist whereby the feature explicitly codes by design to a library search list or to unspecified parameters, but those cases should be intuitive and hopefully also documented [so coding an application to the expectations can be expected to function into the future].

Regards, Chuck