Charles,
The quote "is broken now" means, that I can key in any value of an existing user profile or '*' or '*ALL'. RDi 9.1.1 as well as the green screen debugger accepts each value. Only for non-existing user profiles I get back error message CPF0609 (RDi) and CPF9801 (RPG call to QSYRUSRA) and CPF0609 (green screen STRDBG) .
I used your CL (and later I transformed it to RPG to better see the return values of USRA0100) to see what the API returns for '*'', '*ALL', my own user profile and a user profile of a colleague.
Guess what? Since I have *ALLOBJ, the API always returns the very same values.
I like the idea of submitting a comment regarding to the documentation of SBREAK. I am going to set a mark for me to do that once we updated our boxes to v7.
Thank you for your explanation of how the OS invokes programs. I did not yet know about that or I just forgot it. It might have be mentioned in "Inside the AS/400".
For what I can see, 'SBREAK 63 USER *' and 'SBREAK 63 USER *ALL' works the same. And yes, SBREAK nn USER * or USER *ALL should make all non-debug jobs to stop at statement nn. That is what I expect it to do.
any output with that input is suspect and probably legitimately a case of GIGO.
Most like it is GIGO, but then I wonder what I dreamt in the past. Too bad that we cannot get a playback of the past.
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.
Correct. That is the easiest way to avoid confusion and an important rule of programming. Check your input parameters.
Regards,
Thomas.
-----Ursprüngliche Nachricht-----
Von: WDSCI-L [mailto:wdsci-l-bounces@xxxxxxxxxxxx] Im Auftrag von CRPence
Gesendet: Mittwoch, 21. Januar 2015 20:02
An: wdsci-l@xxxxxxxxxxxx
Betreff: Re: [WDSCI-L] Service entry point not working for User ID *ALL
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).
--
Regards, Chuck
--
This is the Rational Developer for IBM i / Websphere Development Studio Client for System i & iSeries (WDSCI-L) mailing list To post a message email: WDSCI-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/wdsci-l
or email: WDSCI-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives at
http://archive.midrange.com/wdsci-l.
--
IMPORTANT NOTICE:
This email is confidential, may be legally privileged, and is for the intended recipient only. Access, disclosure, copying, distribution, or reliance on any of it by anyone else is prohibited and may be a criminal offence. Please delete if obtained in error and email confirmation to the sender.
midrange.com
