Re: Service entry point not working for User ID *ALL

On 19-Jan-2015 11:37 -0600, CRPence wrote:

On 19-Jan-2015 11:18 -0600, CRPence wrote:

<<SNIP>> 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 '*'
<<SNIP>>

Following this paragraph is a simple CLP source available to show
the effects of the API invocation using '*'; easily modified
[changing which is the commented line] to use the value '*ALL'
instead. The time taken for the request can be measured with the
wall-clock, and the effect of the authorization information being
returned for only one [unknown] user profile object should be
apparent from the dumped receiver variable; however if the
alphabetically first and last user profiles [perhaps those as
unauthorized and another authorized user profile] all have a
different group profile, then one might be able to infer which user
profile the information is being returned for [since from the API
docs, there can be only one] when the special value is used instead
of an actual\valid user profile name.

Ignore the above babbling about having different group profiles; I was confusing my thoughts about the output of the API, such that the testing I was thinking of, would be much more complicated than alluded. The *CURRENT user would need to have been authorized directly or via the [supplemental] group profile(s) to other UsrPrf object(s) to try to infer which one UsrPrf object for which the user's or the user's group's authority was retrieved. Distinct authorities could allow distinguishing which user profile object yielded the output.

I expect that the acceptance of both the '*' and '*ALL' values was an oversight that is [or perhaps _was_] a defect with the Retrieve User Authority To Object (QSYRUSRA) API. The accidental or purposeful rejection of either of those as a special value as input to that API [since some more recent release] may have given rise to the new effect whereby the debugger no longer appears to be tolerant of that input. An immediate error vs the apparent processing of the list of every user profile by the following API invocation would be telling in that regard; while the API may be more discerning with regard to the error condition, the debugger seems to diagnose any error from the API as the condition described by CPF0906.?

dcl &rcv *char 9999
dcl &rln *int 4 value(9999)
call qsyrusra parm( &rcv &rln 'USRA0100' +
'*CURRENT' '* QSYS ' +
/*'*CURRENT' '*ALL QSYS ' */ +
'*USRPRF' x'0000000000000000' )
dmpclpgm
/* dspsplf qppgmdmp splnbr(*last) */

Given the API allows input of an unresolved name [both the *CURLIB and *LIBL special values are allowed for the Qualified Object Name specification], the lack of that name being returned in the output is, although not a defect, surely an arguable deficiency of that API. Had that resolved object name been part of the returned information, then to which object the current user's [adopted] authority was retrieved, would be known; there would be no reason to try to divine what possible meaning from the conspicuously bogus input. I say "bogus" because the API documentation is clear [emphasis my own] that the "API returns a specific user's authority for *an object* to the caller."; the generic names of '*' or '*ALL' could not legitimately be claimed to represent "an object", nor could the API know or guess which one object from which the user's authority should be retrieved given a generic list of potentially many objects.