Message Image  

MQSIDC Collector……why do we ask for it in support?

 View Only
Fri July 10, 2020 11:16 AM

Published on November 22, 2017 / Updated on November 22, 2017

Previously I wrote a blog about collecting the mqsidc file for support:

Running mqsidc for IBM Integration Bus Support

This is a continuation of that to explain why we ask for it and what we look for.

Please note that with each new iteration of the product, the collector may collect additional data. This detail is from IIB 10.0.0.10.
Also note that the files could be extremely large as the stderr/stdout/console.txt files can contain a lot of information. Especially if there are very many Integration Servers.

The MQSIDC collector

The MQSIDC collector is a simple tool that will collect data about your Broker/Integration node with a command line interface. This information includes, but is not limited to:

  1. Broker names and fixpack levels
 
  2. MQ Version

  3. iFixes installed

  4. Execution Group Details

  5. Error logs (syslog, Event Viewer, stderr/stdout, console.txt)

  6. Basic system information
 
  7. odbc files and locations

  8. Environment Variables

  9. Abend files, javacores, heap dumps, snap traces

Once the collector has been run, you will have a zipped file containing a great deal of information.

Under this collector, you will have 2 directories
 
  • autodpzip which contains information about the collector tool including logs. This will only be needed if the collector fails

  • WMB_Broker_Problem, which is the data collected
Under WMB_Broker_Problem there are also 2 directories
 
  • Broker which is the detailed broker collector
 
  • common which are more generic details.

The Common Directory


Under the common directory, you will see the following details:


**All of the files collected should be able to be reviewed with a text editor. In some cases they may be too large, but all are in simple text format.

1. common_error_directory_listing.txt will give you a quick view of what files are located in workspace/common/errors directory. These
 files include abends, javacores, heap dumps, snap traces. You cannot review these files from here, but this does let you know what
 exists in that location.

2. dspmqver.txt displays the current MQ version running with the Integration Node. This will allow us to verify that the environment
 is on a supported configuration

3. env.txt is a list of the current environment variables on the system
4. java_version.txt The java version being run:

5. mqsiListOuptut.txt is a list of the brokers running (and stopped) along with their queue managers:


6. mqsiServiceOutput.txt shows the fixpack level of the broker along with any iFixes installed (if applicable).


If there were any iFixes applied they would be indicated with the following at the bottom of the file:

7. operatingSystemDetails.txt, Operating System information

8. On Unix Operating systems, you will also most likely see files for odbc.ini and odbcinst.ini.
 These are located by how they are referenced in the environment variables ODCBINI and ODBCSYSINI.
 If you are having database connectivity issues, this is the first place to look. Please make sure there are no extra characters such as
 white spaces or carriage returns, as these can cause unexpected results. Also if making changes to the odbc* files, please make sure you are changing the ones indicated in the collector.


The Broker Directory

The Broker Directory contains much more detailed information. Some of these are more important to us than others, but here is basic information and what to review.

1. mqsiAgentJVMSettings will allow us to see some of the attributes of the Broker Agent JVM, including min and max heap size:
       
2. mqsiAllReportableEntity.txt will show us all of the configurable services which have been set up on the broker
3. mqsiAuthorizationMode.txt will allow us to review what authorization mode is configured on the Integration Node and if
 admin security is enabled.
4. mqsiDeployInfoOutput.txt will show all of the artifacts that are deployed to every Integration Server on the Integration Node
5. mqsiBrokerRegistry.txt allows us to view the actual broker Registry:


6. mqsicvpOutput.txt runs the broker wide mqsicvp check, which is a simple test tool to make sure the broker meets the minimum
 requirements, and can access the databases.
7. mqsiExecutionGrouptsOutput.txt will display the attributes of the EGs defined on the broker, such as Execution Group names and
 UUIDs.
8. mqsifileauthdetails will show the details of the file authorizations
9. mqsiHTTPConnectorProperties.txt and mqsiHTTPSConnectorProperties.txt display all of the properties defined on the HTTP and
 HTTPS connector. This is very useful for SSL debugging.
10. mqsilistBroker.txt displays the EGs running on the broker:

11. mqsilistBrokerOutput.txt gives further detail on the Integration Servers that are on the Integration Node:

12. mqsiReportBrokerOutput.txt contains a great deal of information about the broker:


            
  • Last mqsistart path will let us know at what fixpack level the broker was started

  • Work path will show the current workpath location

  • Any lil or exit paths are displayed

  • Operation mode (advanced, express, etc)

  • Fixpack capability Level. This actually can make a difference if there is a new functionality introduced in a new fixpack. For example, using LDAP Authentication for the WebUI was introduced in IIB 10.0.0.4. If you were running with IIB 10.0.0.7,
 but the fixpack capability level was set to 10.0.0.1, you still cannot use this functionality.

  • If admin security is enabled or disabled.

  • The shared workpath (if applicable)

  • If the broker is being started as an MQ service.

  • The httpListener port

  • The default CCSID of the broker

13. mqsiResourceStats.txt will display if resource statistics are enabled
14. mqsiTraceSettings.txt will display if there is either a user or service trace running against the broker
15. mqsiWebadminHTTPConnector.txt and mqsiWebadminHTTPSConnector.txt will give information on the WebAdmin configuration
16. mqsiWebadminServer.txt will show how the WebAdmin server configured and if LDAP is configured.
17. mqsiWebusers.txt will show the users who have been defined as web users
18. mqsiWorkPathDirListing.txt gives a recursive listing of all the directories included in the workpath.
19. processList.txt will show all of the processes running on the Integration Node

The “Broker name” directory

Under this directory, there are 2 additional directories (BrokerLogs and common)

Broker Logs contains the stderr/stdout files for the broker, any execution groups (by UUID), and the http listener (on Windows), stderr/stout are combined into a file called ‘console.txt’

These are the error logs and can contain a great deal of information as well as being the collecting area for many user specified
 traces (GC trace, JSSE trace,etc.) If the stdout file is growing exponentially, there is a very good chance that a trace is running. You will
 also find java out of memory errors in these error logs.


The common directory contains the errors and profiles directories.


The common directory will contain any abend files java cores, heaps and snap traces. On a Unix system, if a kill -3 is run the files
 are collected here:

The profile directory contains any user specific profiles set on the broker. These would either be set with a file ending in .sh (Unix)
 or .cmd (Windows)
            

1 comment on"MQSIDC Collector……why do we ask for it in support?"

  1. Allen Schmutzler November 30, 2017

    Thanks Daniel.. I posted this comment, too, on your original article/blog. Is there some way to provide the inputs/parameters to the mqsidc command w/o the interactive prompts.


#MQSIDC
#Support
#IntegrationBus(IIB)