This portal is to open public enhancement requests against IBM Z Software products. 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).
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:
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 an idea.
Get feedback from the IBM team and other customers to refine your idea.
Follow the idea through the IBM Ideas process.
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.
See this idea on ideas.ibm.com
Currently Alert 1115 does only allow customization for a) the amount of violations and a.1) specific users being revoked exceeding the limit via option 'Customize alert selection list'. I would suggest there second option to allow excludes for a whole RACF class (and/or profile subset - pattern).
For example we are using RRSF to synch few but not all commands between the nodes. While executing one command in an RRSF plex having 9 target nodes and the synch is prevented results in 9 violations for one command (which is expected and totally acceptable). The magnitude multiplies with the amount of commands executed which can lead to large numbers. As all of those violations are expected as we do not want to synch the commands we receive them as the only filter is the amount of violations, regardless of the RACF class. To no loose any alert, we just have to ignore those for RRSFDATA class.
As the alert does not allow further filtering, we have to perform a 1:1 copy of the Alert and add the RACF class exclude statement (for RRSFDATA) on our own. Hence the benefit of an update Alert 1115 would be to get rid of the own copy and extension of the alert.
This will reduce our work to review each zSecure Alert PTF if there is an alteration on the default shipped 1115 alert which needs to be incorporated into our copy (with the class exclusion).
Idea priority | High |
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.
Excluding a list of resource classes isn't hard. Hardcoding RRSFDATA seems like a bad idea.
The RRSFDATA resource class has multiple types of profiles: pwsynch, explicit command direction, automatic command direction, etc.
Excluding the entire resource class seems like a bad decision (e.g. no alerts on people trying to explicitly direct commands to a certain node). Customer situation seems to be that they are suffering from AUTODIRECT access violations. These are typically resulting from non-intentional actions by end-users. The AUTODIRECT profiles are management type of profiles. They are defined on the local/source system. If they were authorisation type profiles, they would have been defined on the remote/target systems. So, there are lots of violations for this "side effect" of legitimate user actions. But, if you're expecting such violations, why do you even activate violation auditing for these resources? It would be more logical to activate success auditing, and ignore the violations.
Now the question is: how does this RFE prioritize (how much work for us, impact on other customers, complexity of using the user interface).
Considering the above, it seems to me that the RFE is not the best way to resolve the issue. It addresses a symptom without looking at the underlying issues. After the customer realizes this, they might abandon this approach, leaving us with an unused "solution".