Skip to Main Content

This is an IBM Automation portal for Integration 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 (

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 ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM. - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Future consideration
Created by Guest
Created on Jul 6, 2022

.NET standalone client login/tracing in .NET Standard is a regression compared to .NET Framework

- On .NET Framework tracing and loging was configured on a file in the filesystem. For .NET Standard, enabling tracing/loging requires setting environment variables. This is incovenient in many scenarios, in example companies where development teams doesn't have access to set those environment variables and requires to get another department involved to enable/disable tracing/logging. Also, on servers running several applications that use the IBM MQ Client, using separate files prevents problems of tracing being enabled on unwanted applications.

- With .NET Framework tracing could be enabled and disabled immediately by modifying the config file. With .NET Standard a restart of the process using the IBM MQ Standalone client is needed to take into account the changes on the environment variables, making this far more inconvenient. Let's think in example in an application that have a problem that is random and hard to reproduce: in the past as soon as the problem was detected you could enable the tracing, but now if you want to catch this you have to start tracing from the start of the application; given the size of the trace files this is very impractical.

- Documentation should be improved, in example in this page: it says:

"In addition to the environment variable MQDOTNET_TRACE_ON used to enable trace on IBM MQ .NET Standard, other environment variables including MQERRORPATH, MQLOGLEVEL, MQSERVER, and so on, that are used for IBM MQ classes for .NET Framework, can be used for IBM MQ classes for .NET Standard as well. These variables work in the same way for both IBM MQ classes for .NET Standard and IBM MQ classes for .NET Framework."

But I can't find any documentation at all about MQLOGLEVEL, MQERRORPATH,... This variables should be well documented somewhere. Better documentation of all tracing and login options and capabilities is need so we can analyze problems the faster and more efficient way possible (and also open less PMRs to IBM :) )

Idea priority Medium
  • Admin
    Mark Taylor
    Sep 28, 2022

    This is something we would like to deliver in a future version of the .Net classes