Re: Error: ZUI_50109: Ask the system administrator for *CHANGE object authority to library QUSRSYS, and *ALL object authority to file QUSRSYS/QATMHINSTC.

On 13-Feb-2014 04:30 -0800, rob@xxxxxxxxx wrote:

On 13-Feb-2014 04:19 -0800, rob@xxxxxxxxx wrote:

I am using the http://myibmi:2001//HTTPAdmin access to delete the
instance for IBM i Access for Web, IWADFT. Works on most lpars.
This one lpar is giving me Error: ZUI_50109: Ask the system
administrator for *CHANGE object authority to library QUSRSYS, and
*ALL object authority to file QUSRSYS/QATMHINSTC.
I am signed on as me, with all special authorities. So I am
thinking that IBM messed up on this one and didn't swap to the
appropriate profile while running under some IBM supplied user
profile. Is that on the right track? If so, what profile needs to
now have access to these objects? If not, what solution should I be
pursuing? Running on 7.1 of IBM i. Cume and groups were brought up
to date as of 12/13/2013.
Tried a google search, and a search at ibm.com, for ZUI_50109 to
no avail.

<<SNIP>> I suspect it is a false error. This is what I really think
the error is. It is not the authority. IBM "assumes" that if a
certain error occurs then it must be an authority issue. How did I
determine this? I tried to temporarily change the authority to *all
for public and I couldn't. Why? Because it was locked by Mimix! So
IBM couldn't update the file (because it was locked) and assumed it
was an authority issue. This is one definite difference between this
lpar and the numerous others I changed.

Seems probable IMO that your assessment is accurate; i.e. a poorly coded feature results in misleading messaging.

If the issue were legitimately per an authority failure [EACCES], then a T-AF audit log entry [when auditing configured to log those] normally would reveal the user for which the required authority was not available. While such an event can be avoided by OS code, if the effect is an error manifest for an Authority Failure, then the event for the T-AF must also be manifest.

Not being a MsgId from a Message File, the ability of the feature to communicate varied causes and recoveries may be limited. The messaging for the feature may default to offering [improperly] an "otherwise [as in, the ELSE of a CASE or SELECT logic]... we suppose it must be this authority condition" as the error. Whereas the better choice would be for the code to offer as an error condition "otherwise... because we had not coded explicitly for this failure, we are giving feedback that the errno is _&eValue and that the log file(s) in path _&pValue should be reviewed for more details; however re-invoking the failing operation with the -fullLogging option may be required, if those logs are not available for this invocation."

FWiW: The APAR symptom kwd for that error is apparently msgZUI_50109 much like for messages from a MsgF. The APARs typically will also have as the first keyword, HTTPSVR The latest PTF for HTTPSVR Web Admin GUI for which the PTF chain includes PTFs with messaging prefix ZUI_ appears to be SI51412: <www.ibm.com/support/docview.wss?uid=nas3025dc92a735da3b886257c68000076a0>