IBM Z Hardware and Operating Systems Ideas Portal
This is the public portal for all IBM Z Hardware and Operating System related offerings. 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
Post an idea.
Get feedback from the IBM team and other customers to refine your idea.
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.
However, how is learning the existence of a CSI through z/OSMF Software Management different from learning the existence of a cataloged CSI data set using ISPF option 3.4? Is ISPF option 3.4 (Data set list) also a security exposure?
^^If this is sarcasm, it's not appreciated. We realize that everything seen through Software Management can indeed be found in ISPF 3.4 and that RACF will protect assets. What we're pointing out is that a potential threat would have to know naming schemes and explicitly search to find this information, versus logon to z/OSMF and have it handed to them on a silver platter, and if security lets them, view into all the defined datasets associated to it, the FMID's, etc, etc. Making this association to ISPF 3.4 is comparing apples to oranges. This gui lets them click into instances that finds out much more information, quicker, and easier that ISPF 3.4. We're trying to make a point of why let the user's see instances that they don't or shouldn't have access to? Why make the user filter through 100's of instances that don't pertain to them, and let z/OSMF config and/or security calls just not show what they don't already have access to anyways?
We'll attempt to use the filter and categories options to see how this works for us, but as more and more users adopt this, it could get very clunky to filter through tons and tons of instances that a user doesn't care about and shouldn't know about, or easily be able to obtain this information from the defined instances. We would hope, and turned in this RFE for a more robust security and/or config options for Software Management.
Thank you for the feedback. We are hoping you can provide some clarification regarding the perceived security vulnerability. It is true on the Software Instance list page of Software Management a user may learn the existence of many CSI data sets. However, how is learning the existence of a CSI through z/OSMF Software Management different from learning the existence of a cataloged CSI data set using ISPF option 3.4? Is ISPF option 3.4 (Data set list) also a security exposure?
As for "hiding" certain software instances from view on the list page, the Filter capability available on all z/OSMF table columns is exactly intended to allow a user to determine which software instances should be displayed and which should be hidden. The display can be filtered using any column value, such as the CSI, the userid that added the software instance, or any number of Categories you might define. In fact, Categories in Software Management are a powerful mechanism to help you organize and filter software instances. Consider defining category values that identify software SRELs, vendor, geography, software life cycle, business unit, etc. For example, consider categories such as Db2, IMS, z/OS, IBM, Broadcom, East Coast, Bloomington, Test, Production, Accounts Receivable, etc. No matter the specified value, a user can Filter the display to include or hide software instances based on Category.
We hope the Filter capability is sufficient to shrink the number of software instances in a display to a list of those most interesting to a particular user. If this is not sufficient, please let us know specifically how it can be improved. Thank you.