ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » General IBM MQ Support » runmqsc on another Qmgr

Post new topic  Reply to topic
 runmqsc on another Qmgr « View previous topic :: View next topic » 
Author Message
KIT_INC
PostPosted: Wed Apr 24, 2019 11:19 am    Post subject: runmqsc on another Qmgr Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Wed Apr 24, 2019 4:22 pm    Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
hughson
PostPosted: Wed Apr 24, 2019 4:43 pm    Post subject: Reply with quote

Padawan

Joined: 09 May 2013
Posts: 1914
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
View user's profile Send private message Visit poster's website
KIT_INC
PostPosted: Fri Apr 26, 2019 3:06 pm    Post subject: Reply with quote

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
View user's profile Send private message
exerk
PostPosted: Sat Apr 27, 2019 12:06 am    Post subject: Reply with quote

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
View user's profile Send private message
PaulClarke
PostPosted: Sat Apr 27, 2019 2:28 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » General IBM MQ Support » runmqsc on another Qmgr
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.