| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| runmqsc on another Qmgr |
« View previous topic :: View next topic » |
| Author |
Message
|
| KIT_INC |
 Posted: Wed Apr 24, 2019 11:19 am Post subject: runmqsc on another Qmgr |
 |
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
I have 2 V9 Qmgrs (QM1,QM2) in a cluster. All production work are fine. So as far as I can tell, there is no communication issue between them.
I did a runmqsc -w 30 -m QM1 QM2
Starting MQSC for queue manager QM2
:
DIS QMGR
1 : DIS QMGR
AMQ8416: MQSC timed out waiting for a response from the command server.
I have check the cmd server and the Qs on QM2 (see below) with no luck. There is also nothing in the error logs. Just need some help on where I go from here.
On QM2
runmqsc QM2
DISPLAY QMSTATUS CMDSERV
15 : DISPLAY QMSTATUS CMDSERV
AMQ8705: Display Queue Manager Status Details.
QMNAME(QM2) STATUS(RUNNING)
CMDSERV(RUNNING)
The command server is running.
I turned on MONQ for SYSTEM.ADMIN.COMMAND.QUEUE, I can see the LPUT time and LGET time change when I did the "dis qmgr " on QM1.
runmqsc QM2
DIS QS(SYSTEM.ADMIN.COMMAND.QUEUE)
16 : DIS QS(SYSTEM.ADMIN.COMMAND.QUEUE)
AMQ8450: Display queue status details.
QUEUE(SYSTEM.ADMIN.COMMAND.QUEUE) TYPE(QUEUE)
CURDEPTH(0) IPPROCS(1)
LGETDATE(2019-04-24) LGETTIME(14.53.19)
LPUTDATE(2019-04-24) LPUTTIME(14.53.19)
MEDIALOG( ) MONQ(HIGH)
MSGAGE(0) OPPROCS(2)
QTIME(0, 0) UNCOM(NO)
I checked AMQERR01.LOG on both QM1
and QM2. Nothing interesting.
Any suggestion ? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Apr 24, 2019 4:22 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9486
Location: US: west coast, almost. Otherwise, enroute.
|
-w WaitTime
Run the MQSC commands on another queue manager. You must have the required channel and transmission queues set up for this.
You need to have an xmitq with the same name as the downstream qmgr you want to administer, along with the usual SDR-RCVR channel defs to move the command pcf-wrapped messages down the network.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| hughson |
| Posted: Wed Apr 24, 2019 4:43 pm Post subject: |
|
|
Padawan
Joined: 09 May 2013
Posts: 1967
Location: Bay of Plenty, New Zealand
|
| bruce2359 wrote: |
| You need to have an xmitq with the same name as the downstream qmgr you want to administer, along with the usual SDR-RCVR channel defs to move the command pcf-wrapped messages down the network. |
This is not true. Clustering channels and XmitQs will work as well.
You just need to be able to resolve a put to Queue: SYSTEM.ADMIN.COMMAND.QUEUE on QMgr: somewhere-else
Having an XmitQ with the same name as the downstream queue manager is one way, but clustering is an equally valid way.
To see why your messages to/from the command server are not being routed correctly, ensure you have a DLQ defined on all participating queue managers (in this case QM1 and QM2) and ensure all the channels are running (i.e. not retrying). Check whether any messages appear on the DLQ and read what the header says the problem is.
Cheers,
Morag
_________________
Morag Hughson @MoragHughson
IBM MQ Technical Education Specialist
Get your IBM MQ training here!
MQGem Software |
|
| Back to top |
|
|
| KIT_INC |
| Posted: Fri Apr 26, 2019 3:06 pm Post subject: |
|
|
Knight
Joined: 25 Aug 2006
Posts: 589
|
| As I mentioned in my post, these Qmgrs are in a production cluster that works. The channels between them are all running. Since I saw the LPUT and LGET time changed, QM2 command server must has taken the message for processing. Unfortunately it is production environment that the MQ trace may result in large amount of data. So I want to get some suggestion before taking the trace which hopefully can tell me what QM2 did with the commands received. |
|
| Back to top |
|
|
| exerk |
| Posted: Sat Apr 27, 2019 12:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
Do you have MCAUSER populated on the CLUSRCVR channels, with a limited-authority user? Are you using CHLAUTH rules to map to a limited-authority user?
_________________
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 |
|
|
| PaulClarke |
| Posted: Sat Apr 27, 2019 2:28 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Not sure why you are mentioning that you can't switch on trace. No one suggested that you switch on trace. Morag suggested that you ensure that both Queue Managers have a Dead Letter Queue. That way if a channel or command server has a problem processing a message then it will put the message to the DLQ with a reason explaining why. My money is on authority. Are you sure the userid coming from the source Queue Manager will be recognised and allowed by the target Queue Manager. Anyway, look in those DLQs and there's a fair chance you'll see what is wrong.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
