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.
Medium - any improvement on error diagnosis is welcome
High as DEBUG is not always set to ON
We would make this our number 2. Getting specific data for issues without flooding Netlog would allow faster resolution of issues.
This is our number 2 ranked item for Batch 11.
Detailed information for debug and RCA is critical for us.
Medium - improving on getting error information and not flooding the netlog is important
High. DEBUG option not always set to ON
High, we don't generally run with DEBUG on for the same reason.
High, normally we don't run with DEBUG on. So it would be very useful that if something fails, a proper FFDC is available.
High - for sure improve the FFDC, at now DEBUG ON isn't the solution
Medium - Just as GDPS performs a non-disruptive state save when it thinks necessary, an automatic collection of required data for analysis would be also very good and very welcome.
GDPS should be able to provide the necessary documentation like Debug, Dump, Trace, etc. automatically
LBG
Priority HIGH.
I think most of us have this wish for some time. Improve the FFDC (somehow!) so we aren't forced to run with DEBUG ON all the time, or recreate with DEBUG ON.
Medium priority
High:
If something crucial to GDPS processing fails, a proper FFDC would be desirable.
FI example from case TS003010896:
On November 14, 2019, the migration from GDPS/PPRC V3.14 to GDPS Metro V4.1 failed at FI as the mirroring status remained NOK even though all pairs were full duplex. Even with DEBUG ON we could not find the root cause and had to fallback to V3.14. No meaningful SDF alert was written, device pair status was an undocumented "DUP(Y)".
Only after a couple of days and a CQUERY-GTF-trace the root cause was found by GDPS L3, resulting in new GDPS APAR PH19615 on November 25, 2019.
There is lots of information being inserted into the netlog and in time of issues the easy it is to identify a problem the quick problems can be addressed and avoided.
It would be nice if certain things were placed into it's own searchable solutions. Such as using a TAG to be able to search in CANZLOG or to have a separate service such as the Work Items in SA that are logged to the Log Stream.
As we begin to look at further exploitation of GDPS this data is going to be vital
Medium - We see the same problem. The DEBUG options floods the Netview log and makes it more or less unusable unless you can filter data with some tools. More granular debug options could help here.