Change "app name" when connecting to IBM MQ? - ibm-mq

Question

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.

Answer 1

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:
Linux process name size limit: Thread name longer than 15 chars?
Solaris process name size limit: psinfo_t solaris does not contain full process name in its field
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.

Answer 2

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.)

Answer 3

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.