Skip to Main Content
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.

Status Not under consideration
Workspace IBM i
Categories BRMS
Created by Guest
Created on Sep 28, 2022

In addition to adopting authority to access data BRMS should swap user profiles too.

IBM i 7.5 killed some BRMS functions we were using by changing the *PUBLIC authority to data from *USE to *EXCLUDE. You may think this is a security enhancement but it isn't. Now instead of users only being able to see data we have to add QBRMS as a group or supplemental group which then allows them to update and delete data too. The reason we had to do this is outlined in case TS010745419. Basically when a user is using the BRMS network feature and it access data on a remote system it started failing at IBM i 7.5 because of the authority change outlined with: "The default for the BRMS shipped database is changing from *PUBLIC *USE authority to *PUBLIC *EXCLUDE." at https://www.ibm.com/docs/en/i/7.5?topic=programs-backup-recovery-media-services-5770-br1 I feel that if the programs not only used adopted authority but also used profile switching then they would still be accessing the data as QBRMS and we wouldn't have to assign the QBRMS group profile to uses thus giving them elevated access to the data outside of the BRMS programs.
Idea priority High
  • Guest
    Reply
    |
    Dec 13, 2022
    We appreciate the feedback on this idea. After consideration, the BRMS team does not intend to provide the requested solution to swap user profiles in addition to adopting authority at this time, so it is being closed.

    The BRMS change in 7.5 to limit access to the internal BRMS files was needed to improve controlled access to the information in these files and limit access to system administrator approved users. With the December 2022 PTF in 7.5 SI81688, the SETUSRBRM command implementation has been enhanced to provide additional authority for the supplied USER() parameter to allow remote operations from a previous release for the specified USER parameter which is the recommended setup for the 7.5 release.
  • Guest
    Reply
    |
    Nov 22, 2022
    The SETUSRBRM enhancement that has been proposed would manage an authorization list for the BRMS files. In the example you have provided, SETUSRBRM USER(DUMMY) USAGE(*OPERATOR), the user profile DUMMY would be given read access to the BRMS file which would allow the STRBALBRM command and other remote operations complete successfully. The errors you are seeing are file overrides on the BRMS DB files which would work successfully with the proposed implementation. Would this be acceptable?

    Reverting back to the previous release behavior is not an option and we feel the authorization list is safer and more appropriate than swapping profiles.
  • Guest
    Reply
    |
    Nov 22, 2022

    I do not see how SETUSRBRM helps. For example let's say you have two systems: GDISYS, GDIHQ. I have a user called DUMMY on both. It has the same password. DUMMY can signon to GDISYS and successfully do STRSQL: select * from gdihq.sysibm.sysdummy1

    I have ran the following on both systems: SETUSRBRM USER(DUMMY) USAGE(*OPERATOR)

    When the user DUMMY runs STRBALBRM they get:

    Database connection started over TCP/IP on target system GDIHQ job

    233396/QUSER/QRWTSRVR.

    DDM object @@QA1AAU in QTEMP uses remote object QUSRBRM/QA1AAU.

    Not authorized to file @@QA1AAU in library QTEMP.

    Cannot open DDM file @@QA1AAU in QTEMP.

    Object @@QA1AAU in QTEMP type *FILE deleted.

    File @@QA1AAU created in library QTEMP.

    DDM object @@QA1AAU in QTEMP uses remote object QUSRBRM/QA1AAU.

    Not authorized to file @@QA1AAU in library QTEMP.

    Cannot open DDM file @@QA1AAU in QTEMP.

    Object @@QA1AAU in QTEMP type *FILE deleted.

  • Guest
    Reply
    |
    Nov 22, 2022

    First of all I believe CEAC/CAAC are wrong in their thinking. They are under the impression that either everyone signs on as a special user like QBRMS or has multiple ID's with one being used for when that user uses BRMS and another one for their applications. I do not feel that documenting that users should go from only being able to update files from within applications and read them from everywhere (Pre 7.5) TO being either unable to access them completely or have unfettered access to update them (post 7.5) is acceptable.

  • Guest
    Reply
    |
    Nov 4, 2022
    The BRMS team needs more information to further assess your Request for Enhancement. The BRMS team agrees that the support for remote access was negatively impacted and challenged by changing the default BRMS shipped database file authority to *PUBLIC *EXCLUDE and that the product could be enhanced to handle this better. We would like to propose a different alternative than swapping profiles. The SETUSRBRM command which requires*SECADM authority and is required after installation of 7.5, can be enhanced to grant read access to the BRMS shipped database files for the individual user profile the system administrator chooses to set up
    with BRMS access.

    We would appreciate your feedback on whether this proposed solution would meet your needs. If yes, we would like to change the title of this Idea to better match the solution. Please let us know your thoughts on this alternate proposed solution.
  • Admin
    Sabine Jordan
    Reply
    |
    Oct 27, 2022

    The CEAC has reviewed this requirement and recommends that IBM not implement this request. This change in behavior is documented in the IBM i 7.5 Memo to Users. For the DDM setup - have a look at https://helpsystemswiki.atlassian.net/wiki/spaces/IWT/pages/239665215 - this should help in getting this setup correctly.

  • Admin
    Nancy Uthke-Schmucki
    Reply
    |
    Oct 11, 2022

    The CAAC has reviewed this requirement and recommends that IBM not implement this request. This change in behavior is documented in the IBM i 7.5 Memo to Users.


    Background: The COMMON Americas Advisory Council (CAAC) members have a broad range of experience in working with small and medium-sized IBM i customers. CAAC has a key role in working with IBM i development to help assess the value and impact of individual RFEs on the broader IBM i community, and has therefore reviewed your RFE.


    For more information about CAAC, see www.common.org/caac


    Nancy Uthke-Schmucki - CAAC Program Manager

  • Guest
    Reply
    |
    Sep 30, 2022
    The BRMS team will use this request as input to planning but no commitment is made or implied. This request will be updated in the future if IBM implements it. The BRMS team will use votes and comments from others in the community to help prioritize this request.