× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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).


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.