In our application we are maintaining queue manager names in the configuration file which are stored in database. At any time, only one queue manager name can be specified in the configuration file.
To support application fail over, it is required to connect to another queue manager with a different name.
It makes no sense to duplicate all configuration files due to different queue manager name. Is there any way at MQ level (alias may be) to refer with the same queue manager in the configuration file, but if the DR location is active it should connect to new queue manager.
As JoshMc said, use a blank or star for the queue manager name. After the connection, the application can use the getName method to retrieve the name of the queue manager.
MQQueueManager qMgr = new MQQueueManager(" ", mqht);
System.out.println("QMgr="+qMgr.getName());
Note: mqht is a Hashtable with the connection parameters.
Related
I have installed the docker version of IBM MQ based on the following link
https://developer.ibm.com/tutorials/mq-connect-app-queue-manager-containers/
Then I created new topic with the following specs:
Name: PROD.TEST
Topic string: dev/test/
Then from C# client I am using dev/test/ to create subscriber to the created topic:
destination = sessionWMQ.CreateTopic(env.Conn.topic_name); subscriber
= sessionWMQ.CreateConsumer(destination);
For some reason if the Topic name doesn't start with DEV. the second line throws the following exception:
XMSException caught: IBM.XMS.IllegalStateException: Failed to
subscribe to topic dev/test/ using MQSUB. There may have been a
problem creating the subscription due to it being used by another
message consumer. Make sure any message consumers using this
subscription are closed before trying to create a new subscription
under the same name.
Linked Exception : CompCode: 2, Reason: 2035
To get you started quickly, container image of MQ's developer edition pre-authorises a user called "app" to be able to connect to the queue manager and access a set of predefined queues and topics. These are the DEV.* queues and the "dev/" branch of the topic tree through the DEV.BASE.TOPIC definition. This is explained here
You can then build on this by adding queues and topics and granting access to these as you require.
To do this with MQ's CLI (runmqsc) you would use the SET AUTHREC command. Or to use the web interface you would click on the configuration of the new topic and select the security tab. You'll need to grant publish or subscribe authority depending on what the application wants to do.
Obviously, this just gets you going, as you move forward you'll want to review the security requirements and decide how to configure MQ to provide this.
I am looking for a command to change the message broker message flow instance in the run time. I know it is quite easy with MB explorer. But I am more interested towards the server side mqsi command. Ours is a AIX env with message broker 8 installed.
The number of instances a message flow has on the execution group is configured in the BAR file, before deployment.
If you want to change the number of additional instances you will need to redeploy your flow.
You can use the mqsiapplybaroverride command to change the configuration of the flow in the BAR file, and the mqsideploy command to redeploy the BAR.
As of IIB v9 you can control the number of instances dynamically at runtime by assigning a workload management policy.
See the description here:
http://www-01.ibm.com/support/knowledgecenter/SSMKHH_9.0.0/com.ibm.etools.mft.doc/bn34262_.htm
Once you have assigned a policy you can change it using the mqsichangepolicy command specifying an xml policy document that has a different number of instances.
Alternatively you can use the web ui to change it directly on the running broker.
When trying to start a queue manager I get a AMQ7017 Log not available message. I have checked, the LogPath for the queue manager in the mqs.ini file is correct. When the problem started I checked and there were two log files in the log folder for the manager: S000000 and S0000002. I simply copied the first one and renamed the copy to S000001 (with the correct number of zeroes). Still the same error.
How can I fix this issue?
I hope its not a production qmgr. Few options below.
You can restore the missing log file from backup and try to start.
Create a qmgr of the same name (in another machine) with the same qm.ini. Basically the log setting should be the same as this qmgr. Copy the log files from that machine to this qmgr and try to start the qmgr. If it starts, the qmgr might recover the persistent messages from the queue files. This is not recommended by IBM, but works in some situations. If its a non-production qmgr, this is the best way.
recreate the qmgr
Once one has a coordination queue manager in the "Managed File Transfer" folder of the IBM MQ Explorer (with the FTE add-on of course), how is it that one adds additional Coordination Queue managers? I don't see an "Add Coordiation Qmgr" option from the Managed File Transfer folder ... ?
You have to create a coordination queue manager using fteSetupCoordination command from command line.
fteSetupCoordination.cmd -coordinationQMgr QM_COORD2 -coordinationQMgrHost localhost -coordinationQMgrPort 3099 -coordinationQMgrChannel MQSVRCHN
This command will create a .mqsc file under config directory. That mqsc file must be run against the new coordination queue manager. For example:
runmqsc QM_COORD2 < C:\MQFTE\IBM\WMQFTE\config\QM_COORD2\QM_COORD2.mqsc
Start MQ Explorer, you will see QM_COORD2 as another coordination queue manager under Managed File Transfer node. Note that there can be only one coordination queue manager active at any point. Hence QM_COORD2 queue manager will be shown as inactive. You will need to disconnect the active coordination queue manager and then make the QM_COORD2 active. To make it active, just right click on the QM_COORD2 and click on Connect short menu.
And so following the resolution of a PMR, we find that my implementation of the FTE plugin for MQ explorer at v 7.0.1.2, was such that it precluded the detection of additional coordination queue managers. I deployed the v7.5 version, and EVERYTHING works fine now. Case closed.
i'm working on qmgr migration from 6.0 to 7.0, but i got problem when restoring V6.0 queue manager from 7.0 on windows. After re-installing MQ 6.0, i copied back the previous backup QMGR data and log, and then tried to start up that QMGR, for instance TEST01. However, that command strmqm TEST01 returns with no such QMGR existed.
The restore procedure i refer to is from infor center below
http://publib.boulder.ibm.com/infocenter/wmqv7/v7r0/index.jsp
and i backup and restore MQGR data and log through as below:
Backup
copy C:\Program Files (x86)\IBM\WebSphere MQ\Qmgrs\TEST01 under another path
copy C:\Program Files (x86)\IBM\WebSphere MQ\log\TEST01 under another path
Restore
copy above backup folder back to target path
So according to above operation, did i miss anything or do something wrong?
UPDATE:
This issue has been fixed. I forgot backing up the configuration information from the registry and restored it then. That's why MQ cannot recognize my QMGR at the very beginning.
Additionally, I've got another question here:
how to transfer configuration information from the registry to the mqs.ini file?
You are far better off not to migrate QMgrs but rather to create new ones at the new version. Although IBM has always provided an upgrade path, the implementation of certain functionality differs from version to version. For example, on Windows the registry settings in V6 are no longer used in V7.1 and higher. The requirement to upgrade usually comes from the belief that replacing the QMgr somehow loses something.
In fact, this is rarely the case. There is also nothing special about a QMgr that well-designed client applications would need to know its name. The host, port and channel uniquely identify a QMgr for a client application. If the app specifies the QMgr's name and it does not match, the connection fails. But the app can specify a blank QMgr name and the connection will succeed. The QMgr's name is automatically filled into the Reply-To QMgr field so requests are properly handled. The only thing that needs to know the name is a QRemote (which can be repointed) or a local app using bindings mode connection.
That said, to answer your question just performing the upgrade to V7.1 or V7.5 will move the QMgr's settings to the ini file.
this issue has been fixed. i forgot backing up the configuration information from the registry and restored it then. that's why MQ cannot recognize my QMGR at the very beginning.