1

I'm working on an application that connects to IBM MQ 8.0 using the C API, calling the MQCONNX function. I run several instances of this application at the same time, and when I open MQ Explorer to list application connections for the queue manager, I see an entry for each connection. However, the entries all have the same "app name" (the name of the executable), making it difficult to distinguish which instances are or are not connected.

Is it possible to change the value that ends up being displayed as the "app name" in MQ Explorer? I'd like to pass an instance identifier from my application, but looking through the documentation for MQCONNX none of the options seem to apply.

legoscia
  • 39,593
  • 22
  • 116
  • 167
  • You did not mention which OS your client application was running on, but I did I added another work around for Linux to set the process name in your program, I did find some similar answers for Windows and Solaris, so this may work for you as well if you are using a different OS. – JoshMc Nov 02 '17 at 01:05

3 Answers3

4

In the IBM MQ v8.0 Knowledge Center page "DISPLAY CONN" under APPLTAG it shows how MQ determines the value. You did not state what OS your client app is running on, the information for Unix and Windows is:

  • UNIX process
    Note

  • On HP-UX if the process name exceeds 14 characters, only the first 14 characters are shown.

  • On Linux and Solaris, if the process name exceeds 15 characters, only the first 15 characters are shown.

  • On AIX®, if the process name exceeds 28 characters, only the first 28 characters are shown.

  • Windows process
    Note
    This consists of the full program path and executable file name. If it is more than 28 characters long, only the last 28 characters are shown.


As mentioned by @Attila Repasi you can change the ApplName in the MQMD of each message using Set All Context, this does not impact the "app name" displayed in MQ Explorer.


One work around I thought of if you are running on Unix is to create separate symlinks to your program each with different names. If you then run each copy using the different symlink names, this should then reflect as the "app name" displayed by MQ Explorer.


A second work around that I tested on Linux that works without the need for symlinks is setting the process name in your program. I first tried to write over the argv[0], but I found while this changes the process name in a ps output it does not change the APPLTAG value that MQ displays. The working way that I found in Linux is below, this must be called prior to MQCONN.

char *process_name = "samplename\0";
prctl(PR_SET_NAME,process_name,NULL,NULL,NULL);

@Fusspawn's answer to "How to name a thread in Linux? [duplicate]" helped with the above syntax.


Note while testing this on Unix operating system MQI clients I found that on Linux and Solaris that the process name is limited to 15 characters by the OS. Only on AIX was RAPPLTAG able to display a full 28 characters. Windows MQI clients are also able to display the full 28 characters. The IBM Knowledge center only says that HP-UX is limited to 14 characters but indicates that on other Unix platforms it is limited to 28 characters, this appears to be incorrect with Linux and Solaris having a 15 character limit.

Helpful answers:

UPDATE: The IBM KC page has been updated based on the feedback I provided, it now states the correct process name limits for Linux and Solaris.


In the interest of providing information to people who may be using IBM MQ classes for Java API the "DISPLAY CONN" page in the Knowledge Center does NOT note that a IBM MQ classes for Java API client can set this value. This is noted on IBM MQ Knowledge Center page "Setting up the IBM MQ environment for IBM MQ classes for Java" under Identifying a connection to the queue manager by setting an application name. This has only been available since v7.5.

Application names are limited to 28 characters and longer names are truncated to fit. If an application name is not specified, a default is provided. The default name is based on the invoking (main) class, but if this information is not available, the text WebSphere MQ Client for Java is used.

...

To set an application name in the properties hash table that is passed to the MQQueueManager constructor, add the name to the properties hash table with a key of MQConstants.APPNAME_PROPERTY.


IBM MQ classes for JMS API client can also set this value. This is noted on IBM MQ Knowledge Center page "Properties of IBM MQ classes for JMS objects > APPLICATIONNAME". This has only been available since v7.5.

Applicable Objects

ConnectionFactory, QueueConnectionFactory, TopicConnectionFactory, XAConnectionFactory, XAQueueConnectionFactory, XATopicConnectionFactory

JMS administration tool long name: APPLICATIONNAME

JMS administration tool short name: APPNAME

Programmatic access

Setters/getters

  • MQConnectionFactory.setAppName()
  • MQConnectionFactory.getAppName()

Values

Any valid string that is no longer than 28 characters. Longer names are adjusted to fit by removing leading package names, if necessary. For example, if the invoking class is com.example.MainApp, the full name is used, but if the invoking class is com.example.dictionaryAndThesaurus.multilingual.mainApp, the name multilingual.mainApp is used, because it is the longest combination of class name and rightmost package name that fits into the available length.

If the class name itself is more than 28 characters long, it is truncated to fit. For example, com.example.mainApplicationForSecondTestCase becomes mainApplicationForSecondTest.

Community
  • 1
  • 1
JoshMc
  • 10,239
  • 2
  • 19
  • 38
1

You can change the application name on messages you send, using the MQOO_SET_ALL_CONTEXT and MQPMO_SET_ALL_CONTEXT options.

But I don't think you can change the application name displayed on the channel status.

However you could run different instances of your application under different OS users. The user name is also displayed among the status information, which could be used for your purpose if you don't override the MCA user id. (Or you could do something similar by using SSL connections, and using the SSL cert information displayed to distinguish your app instances.)

Attila Repasi
  • 1,803
  • 10
  • 11
1

While I agree with Attila that you "could" use the MQOO_SET_ALL_CONTEXT and MQPMO_SET_ALL_CONTEXT options, I strongly suggest you not do it.

If you do use those options then you need to understand the consequences. The following MQMD fields of each message will be left blank and/or null and it is up to the application to populate them:

  • AccountingToken
  • ApplIdentityData
  • ApplOriginData
  • PutApplType
  • PutApplName
  • PutDate
  • PutTime
  • UserIdentifier

So, how much effort are you going to go through to see something in MQ Explorer which is pointless otherwise?

Also, to use those options, the UserId (or group) requires "+set" MQ OAM permission for the queue it is opening.

Roger
  • 7,062
  • 13
  • 20
  • Correction: `+set` permission allows an application to perform `MQSET` call on the queue. For `MQOO_SET_ALL_CONTEXT` the permission require `+setall` on both the `qmgr` and the queue. – JoshMc Mar 07 '17 at 23:43