Re: Is there an easy way to find out what LPAR you are in?

The DSPSRVAGT is apparently not part of the OS, and thus it seems also not documented in the Security Reference:
http://publib.boulder.ibm.com/infocenter/iseries/v6r1m0/topic/rzarl/sc415302.pdf

The documentation for the LPP that provides that command should suggest *SERVICE authority is required, and should probably note that additionally either the special authority *ALLOBJ or some other "specific private and\or special authorities" may be required to use the individual commands\features [e.g. those that implement menu options], or even to use a particular [special] value specified for a command parameter. Although the *SECADM might be required for some individual requests [e.g. for granting the capability to a user to view the service agent information], I would guess that the more typical requirement that is not met would be for lack of the *IOSYSCFG special authority.

An example of documentation like what I would expect, is from the following PDF "Chapter 5. Set up and Configure Hardware Problem Reporting":
http://publib.boulder.ibm.com/isrvagt/pdfs/52ESAUser.pdf

"A user profile (other than QSECOFR) with *SECOFR authority with *ALLOBJ, *SECADM and *IOSYSCFG special authorities. A user without *ALLOBJ authority would need to have specific authority to the objects accessed by Electronic Service Agent. See Appendix A. Authority Requirements for the specific authorities required."

The "Chapter 7. View Electronic Service Agent System Information" suggests:

"You can authorize users to access this information by providing valid IBM Registration user IDs. You must have all object (*ALLOBJ) authority and security administrator (*SECADM) special authority. To authorize users to view server information, do this:"

Together, those two documentation references would not make the requirements entirely obvious to me. That is, it is not obvious to me, whether like with *ALLOBJ, the *SECADM might be optional; e.g. when doing something other than when authorizing "users to access this information". For lack of a section describing exceptions for *SECADM or *IOSYSCFG, like there is for *ALLOBJ, perhaps they deemed the former two special authorities are best just always required rather than trying to document specifically where they would be required.?

Regards, Chuck

rob@xxxxxxxxx wrote:

Of course, you have to have the authority to
get into that <ed: GO SERVICE, option 6> command, as coworkers have shown me.

User needs *ALLOBJ and *SECADM. Tried *ALLOBJ and *SERVICE; that didn't work. Just some silly thought that *SERVICE authority
seemed a natural fit for the SERVICE menu. Apparently IBM is
under the belief that *SECADM is needed to do SERVICE.


Message . . . . : Not authorized to object SERVICE in QSYS. Cause . . . . . : You do not have the correct authority for
object SERVICE in library QSYS type *MENU.

And once they got past that...
Not authorized to command DSPSRVAGT in library QSYS.

This is what option 6 runs: DSPSRVAGT TYPE(*SRVREGINF)

So you could skip giving them authority to the SERVICE menu and
adopt authority to that command. Hopefully a "DSP" command
doesn't pucker up some security officers frown.

Object . . . . . . . : DSPSRVAGT
Library . . . . . : QSYS Object type . . . . : *CMD Object secured by authorization list . . : *NONE

Object User Group Authority
*PUBLIC *EXCLUDE QSRVAGT *ALL QSRV *USE
And after you get through that hurdle...
Not authorized to program QS9DSP1 in QSYS.
Not authorized to service program QS9UTIL in QSYS.
Not authorized to service program QSJSRVAGT in QSYS. Not authorized to service program QSJUTIL in QSYS. ...
...
...