| Author |
Message
|
| balaraju |
 Posted: Mon Apr 10, 2017 9:09 pm Post subject: dmpmqcfg remote queue manager timing out |
 |
|
Apprentice
Joined: 06 Feb 2017
Posts: 29
|
Hi,
We are trying to take a dump of remote queue manager objects from one of our local queue managers. Below is the executed command
dmpmqcfg -m localqmgr -r remoteqmgr > remotedump.txt
Error : MQSC timed out waiting for a response from the command server.
The transmission queues are defined with the queue manager names on both the ends. localqmgr has a xmitq with remoteqmgr name and viceversa... The channels are running.
Please let me know what else to be taken care to make this working. Any system channels/queues to be enabled? |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Apr 11, 2017 3:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Is the command server on the other machine running?
What errors are you seeing on the other queue manager?
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Apr 11, 2017 3:57 am Post subject: Re: dmpmqcfg remote queue manager timing out |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| balaraju wrote: |
| Error : MQSC timed out waiting for a response from the command server. |
You're sure the command server is running? Your other posts indicate a preference for not having that operational by default.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| balaraju |
| Posted: Tue Apr 11, 2017 4:10 am Post subject: |
|
|
Apprentice
Joined: 06 Feb 2017
Posts: 29
|
| we resolved it now. changed the defpsist on both the xmitqs to NO and then it started working. Able to take a dump of remote qmgrs from local |
|
| Back to top |
|
|
| balaraju |
| Posted: Thu Apr 13, 2017 4:35 am Post subject: |
|
|
Apprentice
Joined: 06 Feb 2017
Posts: 29
|
| Looks like updating persistence as no is not a desired option when the same xmitq is being used for real transactions.... anymore thoughts on this? |
|
| Back to top |
|
|
| exerk |
| Posted: Fri Apr 14, 2017 12:25 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| balaraju wrote: |
| Looks like updating persistence as no is not a desired option when the same xmitq is being used for real transactions.... anymore thoughts on this? |
Have the apps explicitly make their messages persistent (if for a valid business reason) ? Have the QREMOTE definitions set to persistent (see previous comment) ?
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 14, 2017 4:17 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| exerk wrote: |
| balaraju wrote: |
| Looks like updating persistence as no is not a desired option when the same xmitq is being used for real transactions.... anymore thoughts on this? |
Have the apps explicitly make their messages persistent (if for a valid business reason) ? Have the QREMOTE definitions set to persistent (see previous comment) ? |
If your messages are persistent, you need to define a reply-to queue as the default reply-to will not work with persistent messages 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Apr 14, 2017 5:22 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fjb_saper wrote: |
| exerk wrote: |
| balaraju wrote: |
| Looks like updating persistence as no is not a desired option when the same xmitq is being used for real transactions.... anymore thoughts on this? |
Have the apps explicitly make their messages persistent (if for a valid business reason) ? Have the QREMOTE definitions set to persistent (see previous comment) ? |
If your messages are persistent, you need to define a reply-to queue as the default reply-to will not work with persistent messages |
Why does anyone think that dmpmqcfg will create persistent messages? It clearly takes persistence as queue def
It doesn't make any sense that the command server on the other end needs persistent messages, nor that the xmitq and local channels would need persistent messages.
I suspect that the proper routing from each qmgr is not set up... It's probably very useful to have a qmgr alias on each side...
or just use dmpmqcfg in a client mode.
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Apr 14, 2017 10:33 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| mqjeff wrote: |
Why does anyone think that dmpmqcfg will create persistent messages? It clearly takes persistence as queue def
It doesn't make any sense that the command server on the other end needs persistent messages, nor that the xmitq and local channels would need persistent messages.
I suspect that the proper routing from each qmgr is not set up... It's probably very useful to have a qmgr alias on each side...
or just use dmpmqcfg in a client mode. |
That's because of this entry from the OP
| balaraju wrote: |
we resolved it now. changed the defpsist on both the xmitqs to NO and then it started working. Able to take a dump of remote qmgrs from local |
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat Apr 15, 2017 3:23 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
If the remote queue manager is producing dmpmqcfg reply messages that are persistent, but the local queue manager that you are connected to creates a temporary dynamic reply queue those persistent reply messages are not going to be accepted by the temp dynamic reply queue.
You either need a permanent dynamic reply queue on THIS end, or you need THAT end to produce non persistent reply messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 17, 2017 3:29 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
dmpmqcfg talks to the command server.
The command server shouldn't be producing persistent messages, unless something has changed... Possibly if it receives a persistent message, it will send a persistent reply... ?
But in that case, the issue is going to be the sender channel, or the xmitq on the "local" qmgr...
Not sure why either of those would have defpsist(true)...
_________________
chmod -R ugo-wx / |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Apr 17, 2017 4:55 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
https://www.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.adm.doc/q022310_.htm
| Quote: |
| The command server sends the reply messages with the same persistence as the command message it received. |
If the remote queue manager is producing dmpmqcfg reply messages that are persistent, but the local queue manager that you are connected to creates a temporary dynamic reply queue those persistent reply messages are not going to be accepted by the temp dynamic reply queue.
You either need a permanent dynamic reply queue on THIS end, or you need THAT end to produce non persistent reply messages.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| balaraju |
| Posted: Tue Apr 18, 2017 2:17 am Post subject: |
|
|
Apprentice
Joined: 06 Feb 2017
Posts: 29
|
We tried the below syntax
dmpmqcfg -m MYQMGR -c "DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(CLNTCONN)
CONNAME('myhost.mycorp.com(1414)')", where MYQMGR is the remote queue manager for which we need to take a dump in local server. This worked
But this is stripping the auth settings and the size of dump taken with dmpmqcfg local and the remote is varying.... |
|
| Back to top |
|
|
| donbirno |
| Posted: Sat Jan 26, 2019 10:59 am Post subject: Supply ID with dmpmqcfg |
|
|
Novice
Joined: 01 Nov 2013
Posts: 13
|
| Is there anyway we can supply mqm ID with this command, like we connect in MQ explorer. |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Jan 26, 2019 1:32 pm Post subject: Re: Supply ID with dmpmqcfg |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| donbirno wrote: |
| Is there anyway we can supply mqm ID with this command, like we connect in MQ explorer. |
Assuming that you are using MQ Client, script it and use the mqccred exit on the client end. You will need to do all the necessary work with CHLAUTH to over-ride (safely!) the privileged ID restrictions. Alternatively (and preferably in my view), use a service account with all the only-absolutely-necessary authorities.
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
|
|
|
