Skip to Main Content
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
  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 GDPS
Created by Guest
Created on Oct 14, 2019

Improve FFDC for GDPS

In the case TS002648540, the log and trace data from GDPS did not provide enough details to track down the root cause of the problem. We could not always have the DEBUG ON in GDPS to capture additional message all the time and this will cause flooding of debug data in the netlog which turns it unusable for customer during normal operations.

Idea priority Medium
  • Guest
    Reply
    |
    Feb 18, 2023
    After giving the request a comprehensive review, we have determined that although we agree that the proposed enhancement is desirable, we cannot include it as a candidate in an upcoming release because it cannot be delivered within our planning cycle. We will focus on improving FFDC.
  • Guest
    Reply
    |
    Jan 28, 2020

    Medium - any improvement on error diagnosis is welcome

  • Guest
    Reply
    |
    Jan 14, 2020

    High as DEBUG is not always set to ON

  • Guest
    Reply
    |
    Jan 14, 2020

    We would make this our number 2. Getting specific data for issues without flooding Netlog would allow faster resolution of issues.

  • Guest
    Reply
    |
    Jan 8, 2020

    This is our number 2 ranked item for Batch 11.

    Detailed information for debug and RCA is critical for us.

  • Guest
    Reply
    |
    Jan 8, 2020

    Medium - improving on getting error information and not flooding the netlog is important

  • Guest
    Reply
    |
    Jan 7, 2020

    High. DEBUG option not always set to ON

  • Guest
    Reply
    |
    Jan 7, 2020

    High, we don't generally run with DEBUG on for the same reason.

  • Guest
    Reply
    |
    Dec 19, 2019

    High, normally we don't run with DEBUG on. So it would be very useful that if something fails, a proper FFDC is available.

  • Guest
    Reply
    |
    Dec 10, 2019

    High - for sure improve the FFDC, at now DEBUG ON isn't the solution

  • Guest
    Reply
    |
    Dec 9, 2019

    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.

  • Guest
    Reply
    |
    Dec 6, 2019

    GDPS should be able to provide the necessary documentation like Debug, Dump, Trace, etc. automatically

  • Guest
    Reply
    |
    Dec 6, 2019

    LBG
    Priority HIGH.

  • Guest
    Reply
    |
    Dec 2, 2019

    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

  • Guest
    Reply
    |
    Dec 2, 2019

    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.

  • Guest
    Reply
    |
    Dec 2, 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

  • Guest
    Reply
    |
    Dec 2, 2019

    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.