.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: https://www.ibm.com/docs/en/ibm-mq/9.2?topic=net-installing-mq-classes-standard 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 :) )