On 20-Jan-2015 02:43 -0600, Thomas Raddatz wrote:
I am impressed about the effort you put into the "SBREAK *ALL"
problem.
I like to assist where I can, and that is mostly with the OS. I do
not even have access to the software that is the subject-matter of this
forum, so I am unable to offer much help in that regard.
My initial curiosity was for the specification of *ALL, that I did
not know was supported, and for which I also can find no documentation
to imply the value ever was supported. That the [lack of effect] was an
apparent regression per "does not work any longer" further piqued my
curiosity; given I have access only to v5r3, I can [only] look at what
might have happened in the past releases.
That said, I am still not clear what that quote implies, as neither
that quote nor "is broken now" reveal to me anything about what is the
unexpected effect being experienced. Perhaps that the value can not be
entered or is rejected by a message in the GUI debugger, or that
although the value is accepted the service entry point fails to break in
any [non-debug] job irrespective the user profile executing the statement?
The followup with the additional comment that "it takes longer to
execute SBREAK nn USER *ALL than SBREAK nn USER profile" further
intrigued me, because I was left wondering what the debugger code [as
part of the OS] would be doing, other than testing for both *SERVICE and
*ALLOBJ Special Authorities; a test that should be near instantaneous.
I gave up analyzing the problem and I wait for our new 7.1
boxes. Unfortunately it is 7.1 and not 7.2 as announced first.
Another avenue other than a PMR [for which procedurally a process had
been in place that requires a response from IBM], a _comment_ can be
submitted about the documentation. For example in the
<
http://www.ibm.com/support/knowledgecenter/api/content/ssw_ibm_i_71/rbam6/dbpgm.htm>
Debug Commands page, a comment could be posted that the SBREAK has no
syntax diagram, and suggesting that although a syntax diagram is shown
for the effective equivalent feature via the
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_71/apis/QTESBMDC.htm>
Submit Debug Command (QteSubmitDebugCommand) API documentation of the
_SBreak Statement_, that the definitions of the accepted values of
asterisk and special-value *ALL for the _userid_ parameter are not
included; values that when entered in the green-screen debugger are
accepted values, but there is nothing documented about what should be
the effect for having specified USER *ALL or USER * for the user
identifier. Arguably everything that is unsupported can not be
documented, but when the feature accepts /Special-Values/ without any
error but either no or incorrect function, then they *should* document
either that the values are unsupported or what the effect should be for
each allowed value that is something other than a valid user profile name.
Because the person in charge of the documentation is very unlikely to
be able to properly respond to the docs comment [because the issue is
not purely the documentation, but about how the code should function
according to the (lack of) documentation], they will almost assuredly
consult the development staff [debug component TE] to properly address
the user-comment that was submitted. Making the comment in one of the
currently supported IBM i KnowledgeCenter releases is appropriate, but
because I can not test\verify what I am talking about, legitimately I
can only comment on the old v5r3 docs. As an unsupported release, the
process in place to ensure feedback from user-comments against IBM
documentation may not hold true, nor would I expect the development to
ever respond if there were comments made there. While one could infer
that the reply by Edmund offering what "our debugger folks" replied is
sufficient, this forum is not an official IBM channel, whereas the PMR,
APAR, TechNotes, and the documentation are quite official; so while
Edmund suggested a PMR, that is just one possible action.
Yesterday I had the idea to intercept the call to QSYRUSRA with a
simple proxy program in a library before QSYS. But of course that
does not work, because the debugger calls QSYRUSRA in QSYS.
The OS invokes the program via address [stored in the System Entry
Point Table (SEPT), IIRC, named QINSEPT], done in part to prevent just
such /Trojan-Horse/ effects. To be clear, the use of a qualified-name
by the OS is not what prevents using the system library list. That can
even be verified by renaming the API or moving the program object from
QSYS; the proper API will still be invoked. Even after replacing that
*PGM object with your own [after MOV or RNM] would leave the OS still
calling the old renamed or moved object. However the invocation would
fail with an exception if the program object had been deleted instead;
an action for which possibly an effective or actual OS reload could be
required to recover because deleting system object(s) can be detrimental.
Then I traced the job but that did not help me either.
Because the trace is just CALL flow and trace-data, the ability to
glean useful information depends greatly on the implementation; esp. per
work being done in OPM with internal calls that are not visible in the
trace, as contrasted with calling external programs or ILE procedure
calls which are visible in a trace. However with my followup that
offered a CLP as a re-create for the long wait using *ALL [or just
asterisk *] as input to the API, my allusion to the potential value of
any tracing of the SBreak request was since effectively mooted.
At the end I will check SBREAK *ALL with 7.1
Just curious, was the following alternative syntax attempted [or
effectively the same but with the GUI], to test if the effect is any
different than when using SBREAK nn USER *ALL; different with regard to
having activated the service breakpoint irrespective of user profile name?:
SBREAK nn USER *
and in case it does not work, I consider to open a PMR. I do not have
a need to use SBREAK *ALL often, but sometimes it was nice to have.
The only logical inference is that the effects for having requested
the SBREAK nn USER *ALL was that all [non-debug] jobs activating the
statement-nn would have triggered the breakpoint irrespective the user
profile name of the job. For lack of anyone explicitly describing the
intended [per undocumented] effects, I think clarification of what
"SBREAK nn USER *ALL worked in the past" implies, was\is worth noting;
hopefully I have accurately portrayed already, the expectation and
[although just repeating myself, also having described] what was
happening in the past.
For those who are interested, here is the job trace, strip down to
QSYRUSRA:
<<SNIP>>
Notably, that trace showed two invocations of the API, consecutive
statements from the CheckAut processing; the first nearly instantaneous,
and the second taking a perceptible amount of time, so presumably the
latter is an invocation using the Special Value *ALL. Because the
QSYRUSRA API quite clearly seems unable to support that special value,
any output with that input is suspect and probably legitimately a case
of GIGO.
As I understand: firstly, the debug component should not be passing
that special value to the API, and secondly, the API should diagnose the
input [of either special value] as an error. Although I quite decidedly
imply those are both defects, that is in no way a statement being made
by me about the potential for or any expectations with regard to, the
service breakpoint being capable of being activated irrespective of user
profile name. What I do intend to suggest is that if those are defects
and they are properly addressed\corrected, and that the support for *ALL
is intended by the debugger, then the delay for the unnecessary
processing of [the listing in QLILIST of] every user profile object
could be eliminated; in conjunction, the docs should be appropriately
updated to reflect the available support or restriction(s) on special
value(s).
midrange.com
