On 19-Jan-2015 01:03 -0600, Thomas Raddatz wrote:
<<SNIP>> I am pretty sure that SBREAK nn USER *ALL worked in the past
and that it is broken now. User *ALL is not documented as far as I
can see. But SBREAK on a green screen seems to accept *ALL because:
a) it is accepted by the debugger in contrast to an non-existing
user profile
b) it takes longer to execute SBREAK nn USER *ALL than
SBREAK nn USER profile
I tried that SBREAK [using green-screen debug] on a v5r3 system with
thousands of user profiles, and the wait is very conspicuous. During
that wait, the job is running the Librarian: List Object (QLILIST)
program invoked by the Security: Retrieve User Authority To Object
(QSYRUSRA) API invoked by the Debugger: (CheckAut) routine from the
Debugger: (isUserAuthorized) routine initiated from the Debugger
(RPG_SBreak_Statement_2) procedure; in my case, until the debugger
eventually\finally issued an error msg CPF0609 "Not allowed to use
specified user profile.", almost as if just one specific [not generic]
user profile had been named.
Possibly it seemed, the Debugger was effectively listing every
*USRPRF object to which the minimally required authority is available to
my user profile requesting the SBreak; in my case, there will be _none_
to which I am authorized, except myself, so the messaging seemed a bit
obtuse for not choosing to [or not being able to] distinguish between
unauthorized to all, to some, or to myself... if indeed the special
value(s) *ALL [and *] intend to imply activating the SEP breakpoint for
/any user profile/ on the system.
Yet the stack seemed unchanging [I have no ability to trace], so the
effect seemed to be that the API was invoking the List-Object, yet the
API implies nothing about the ability to specify a Generic* name nor
Special-Value; neither the lone asterisk nor the value *ALL are documented.
<
http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_72/apis/qsyrusra.htm>
So I tested myself by invoking the API directly with the '*' and saw
the _same stack_ I noted above; except of course, the API being called
by my program rather than the debugger. Possibly then, the SEP
breakpoint will not establish for *ALL users whenever authority is
lacking to any one *USRPRF object; one would expect then, that the API
call from CheckAut would be bypassed, if the requesting user has the
*ALLOBJ Special Authority.? However that seems daft, as there is no
indication nor apparent capability of the API to return information for
more than one object.? Is the API possibly returning information about
the last user profile, or the last user profile to which the requesting
user has some authority; hard to know, without knowing what was the
LI-List Object request was, such as whether an authority mask was passed-in.
So anyhow... The same two things, a) and b) can be said about the
lone asterisk as a special value. Of course, that a value is accepted
and takes longer to process, is not necessarily a clear indication of
the effect; the logical assumption by a reader, is that /in the past/
the breaking for the SEP was verified to occur irrespective of user
profile name, having been tested minimally to include a user other than
the UsrPrf requesting the SBREAK which is the default UsrPrf when no
USER was specified.? The reply by Matt seems to suggest success in that
regard, yet the reply by Jon seemed to suggest not; we do not know of
course, what was [the extent of] their test.
In case my asides seems a mere misdirect, the implication is that
perhaps trying * instead of *ALL might have a different effect at the
GUI debugger, regardless the same apparent effect on the green screen
for both special values. Regardless, I am still unaware what the true
effect is [for use of asterisk or *ALL] beyond the extra time required
to apparently extract the authority of every user profile object [and I
presume for the *CURRENT user] before activating the SEP breakpoint;
i.e. whether that SEP breakpoint is established irrespective the
invoking user profile, I can not test, and that effect seems a tenuous
possibility given the aforementioned.
<<SNIP>>
midrange.com
