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.
Declined after 4 years waiting for reasonable feedback. Disappointing…
This enhancement request was not able to be implemented at this time.
After almost two years waiting: Can you please either decline or accept this RFE?
Due to processing by IBM, this request was reassigned to have the following updated attributes:
Brand - Servers and Systems Software
Product family - Development Tooling
Product - IBM Fault Analyzer
For recording keeping, the previous attributes were:
Brand - WebSphere
Product family - Enterprise Tooling
Product - IBM Fault Analyzer
In all three scenarios, FA should detect that the abending Job/CICS-task is connected to MQ (like it does for connections to DB2 and IMS/DBCTL). From this detected connection to MQ FA should infer all open queue handles and the names of the underlying queue with the open options used.
FA should extract information from the last MQ-Call issued: Depending of the the particular API-Call (MQOPEN, MQPUT, MQGET) it should try to identify the program, which issued the call (R14) and format the parameters used: Of course Compcode, Reasoncode (missing in IDISRP05!), MQPMO, MQGMO, Messagedesciptor, address of messagebuffer, messagelength.
This requirement applies to all three scenarios.
We are evaluating the request to extend Fault Analyzer support to cover MQ reporting when the abending program is not an MQ program, but a subprogram called by the abending program may have been an MQ program.
For this evaluation, we would like to consider the broader question of what MQ support/reporting customers would like to see in Fault Analyzer? Can we please have customer feedback on what they believe would be helpful in terms of Fault Analyzer reporting in the event of an abend in:
a. an MQ program where the abend is in an MQI call (see thlqual.SIDIDOC1(IDISRP05) for current reporting)
b. an MQ program where the abend is not in an MQI call
c. a non-MQ program that calls an MQ subprogram running in the same LE enclave
(where "MQ program" is defined as any program that issues MQI calls)?
Thanks in advance for any feedback the customer can provide to help us with this evaluation.