IBM Power Ideas Portal


This portal is to open public enhancement requests against IBM Power Systems products, including IBM i. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (https://ideas.ibm.com).


Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas

  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.


Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal (https://www.ibm.com/ideas) - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal (https://ideas.ibm.com) - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

ideasibm@us.ibm.com - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Add a new idea Subscribe
Status Future consideration
Workspace IBM i
Categories Security
Created by Guest
Created on May 26, 2023

RELATED IDEAS

Correct the QSYLOBJP API Documentation

Today, the QSYLOBJP API documentation states that it creates: a list of objects that adopt an object owner's authority

In the classic way of thinking, this would be program/srvpgm objects that have USRPRF(*OWNER) set a creation time. However what is being produces is a list of objects that have the ADOPT(*YES) attribute regardless of the USRPRF setting.

In this context, that object's user profile parameter may be *USER or *OWNER.

The documentation for ADOPT(*YES) states that it Specifies whether program adopted authority from previous programs in the call stack will be used as a source of authority when this program is running.

I have programs with USRPRF(*USER) and ADOPT(*YES) and they appear in the list of objects generated by the QSYLOBJP API, along with USRPRF(*OWNER) ADOPT(*YES) objects.


Wouldn't it be more accurate to state that the API returns a list of objects that are Owned by the specified User Profile and have the Adopt Authority attribute set to *YES?


Idea priority Low
  • Guest
    Reply
    |     Aug 9, 2023
    To clarify what the two attributes on the program or service program mean:

    USRPRF(*OWNER) (User profile = *OWNER): This value means that the program/service program adopts the owner?s authority. When the program/service program is called, it will be running with the authority of the current user plus the authority of the owner of the program/service program. These are the objects that are returned from the DSPPGMADP command and QSYLOBJP API.
    USRPRF(*USER) (User profile = *USER): This value means that this program/service program does not adopt the owner?s authority.


    USEADPAUT(*YES) (Use adopted authority = *YES): This value means that if there are any programs/service programs in the program stack ahead of this program/service program that adopt authority (have ?User profile = *OWNER), that adopted authority will be used by this program/service program. It does not indicate that this program/service adopts the owner?s authority. The majority of programs/service programs will have this value for the attribute.

    USEADPAUT(*NO) (Use adopted authority = *NO): This value means that if there are any programs/service programs in the stack ahead of this program/service program, that adopted authority will not be used by this program/service program. It does not indicate that this program/service does not adopt the owner?s authority.

    We will look at making changes to the documentation for the DSPPGMADP command and QSYLOBJP API to indicate that the adopt authority is tied to the User profile (USRPRF) attribute.

    IBM Power Systems Development
  • Guest
    Reply
    |     Aug 9, 2023

    I am simply stating that the documentation should be enhanced/clarified so that it is similar to the wording of the DSPPGMADP CL command and clarify that USEADPAUT(*YES) object are returned regardless of whether USRPRF(*OWNER) or USRPRF(*USER) is also specified. So perhaps the "prior program stack" phrase needs to be included.

    Why the request? Because USEADPAUT is only available on CHGPGM/CHGSRVPGM and not the various CRTxxx object commands. Therefore USRPRF(*OWNER) implies Adopt. If USEADPAUT or a simpler ADOPT parameter were available on the CRTxxx commands, then this clearification would not be necessary. Just trying to educate those reading the API docs vs assuming they will hunt down the true meaning of "Programs that Adopt".

  • Guest
    Reply
    |     Aug 8, 2023
    The QSYLOBJP API should only be returning the objects that have ?User profile = *OWNER?. The objects returned from the that API should be the same that are shown on the Display Program Adopt (DSPPGMADP) command. If the objects returned from QSYLOBJP are different than the objects returned from DSPPGMADP, then that would be a defect that should be reported. Is it possible that the QSYLOBJA (List Objects a User is Authorized to, Owns, or Is Primary Group of) API is being used instead of the QSYLOBJP API?

    IBM Power Systems Development

By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.