IBM Z Software
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).
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.
- A shop lead developer downloads IDz.
- They unzip the package, but don't launch.
- They place this this local Property group file into a directory in IDz, lets say it's under <unzip location>\idz\customFiles\myPropGroup.xml.
- Lead developer zips IDz back up for shop distribution
- Developers unzip their IDz, and upon loading up a new workspace, that myPropGroup.xml gets loaded up in their client automatically.
Would that fit your needs?
That is a good point as some companies may want that flexibility. In our shop though, this is a problem. Our developers don't want to concern themselves with configuring IDz at all. They don't have the expertise and would like everything preconfigured. The way we've designed our repos, the copybooks, macros, etc. are always in the same folders so a standard local profile works perfect for us and the developers. As we're pushing out new releases of IDZ (which seems to be very often), they are getting new workspaces, and this is something that needs to be manually configured each time. I understand they can just reimport the settings, but they just want to code and not be bothered with continually configuring their settings. We are trying to remove all barriers so they can start from scratch and hit the ground running. We've recently started using VSCode as well and the zapp.yml allows us this capability and the developers love it.VSCode just discovers their resources since the definitions are predefined for everyone in the yml. In IDZ, they've accepted just not finding copybooks so they aren't getting the full value of the product.
To serve both types of customers, what do you think about making a global local group that can be pulled down that developers can use and still give the flexibility of keeping their own local property group. This way customers like us can just use the global and other customers can pull down a global but developers can still create their own property groups that never get saved to push to client.
Push-to-client enables centralized configuration management by distributing settings from the host to client workspaces. Remote property groups are managed by the host and can be centrally controlled. In contrast, Local property groups are user-owned and highly customizable. Pushing them from the host risks overwriting personalized configurations that should remain under individual control.
If the desire is to share a local property groups, one can manually export them from their workspace and have others import them as needed.