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 IndexGeneral IBM MQ SupportIssuing RUNMQSC on a remote queue manager

Post new topicReply to topic
Issuing RUNMQSC on a remote queue manager View previous topic :: View next topic
Author Message
vicks_mq
PostPosted: Sat May 11, 2019 6:48 am Post subject: Issuing RUNMQSC on a remote queue manager Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

I want to issue Runmqsc commands on our remote MQ appliance Queue manager and the below article mentions how we can do it.
https://www.ibm.com/support/knowledgecenter/SSFKSJ_9.1.0/com.ibm.mq.adm.doc/q021190_.htm

But, I also found another article where it says you can run "Runmqsc -c", so I am wondering what is the difference between these 2 methods?


https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.adm.doc/q083460_.htm

Modifies the runmqsc command to connect to a queue manager by using a client connection. The client channel definitions used to connect to the queue manager are located using the following environment variables in this order of precedence: MQSERVER , MQCHLLIB , and MQCHLTAB .
This option requires the client to be installed. If it is not installed an error message reporting the missing client libraries is issued.


Does both the methods of issuing runmqsc to remote queue manager works?

I tried "runmqsc -c" from my end but we don't have have client libraries installed so I got the error.
Loading of client module '/opt/mqm/lib64/libmqiz_r.so' failed.

Just wondering if the 1st method works or not.
Back to top
View user's profile Send private message
exerk
PostPosted: Sat May 11, 2019 8:30 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6106

The first proxies the command(s) from one queue manager to another, via whatever channels connect the queue managers, and the results of the command(s) are routed back to the queue manager from which you initiated the command(s). I suspect, but I'm no expert mind you, that the first method should work. I base that on the assumption that IBM would likely not have included it if it didn't work - unless someone at Hursley has a wicked sense of humour and put it in the doc just so someone could have a go and fail miserably.

The second instantiates a direct connection to the queue manager you wish to run the command(s) against, and as you don't have MQ Client installed it failed - strange that, but the clue was in the documentation (which was quite explicit about what was required, and what would happen if those requirements were not met).
_________________
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
vicks_mq
PostPosted: Sat May 11, 2019 11:00 am Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

exerk wrote:
The first proxies the command(s) from one queue manager to another, via whatever channels connect the queue managers, and the results of the command(s) are routed back to the queue manager from which you initiated the command(s). I suspect, but I'm no expert mind you, that the first method should work. I base that on the assumption that IBM would likely not have included it if it didn't work - unless someone at Hursley has a wicked sense of humour and put it in the doc just so someone could have a go and fail miserably.

The second instantiates a direct connection to the queue manager you wish to run the command(s) against, and as you don't have MQ Client installed it failed - strange that, but the clue was in the documentation (which was quite explicit about what was required, and what would happen if those requirements were not met).


Hi Exerk, the reason for failing of second method is obvious, my question was why the IBM advertise the 1st method, whenever I google about how to administor remote queue managers , it directs me to 1st method.

I want to try second method but before I take permission from our UNIX team and raise a change request for installation of client libraries, I just want to be sure that second method will work.
Back to top
View user's profile Send private message
exerk
PostPosted: Sat May 11, 2019 11:20 am Post subject: Reply with quote

Jedi Council

Joined: 02 Nov 2006
Posts: 6106

vicks_mq wrote:
Hi Exerk, the reason for failing of second method is obvious, my question was why the IBM advertise the 1st method, whenever I google about how to administor remote queue managers , it directs me to 1st method...

I'm not IBM so I can't answer that question. I can, however, surmise that as queue managers within large organisations tend to interconnect (I can't think of many stand-alone queue managers being used by large organisations, except for those used by developers perhaps), that at least one would be used as an 'administrative interface', therefore 'method 1' would be far more likely to be used.

vicks_mq wrote:
...I want to try second method but before I take permission from our UNIX team and raise a change request for installation of client libraries, I just want to be sure that second method will work.

You can take it as read that it will as again, it's unlikely that IBM have put it in for a laugh.

As I stated in a previous reply to your AMQ7077: not authorized to perform the "crtmqm" post - if your organisation won't let you have admin rights, get VMWare Player (or similar) installed and use VMs to play around with all stuff MQ-related. Or get them to give you a sand-box to play in.
_________________
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
bruce2359
PostPosted: Sat May 11, 2019 11:25 am Post subject: Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 8501
Location: US: west coast, almost. Otherwise, enroute.

IBM offers several solutions. You have options. IBM cant know your requirements. Your browser may seem to offer one over the other.

Each method requires a network connection from/to the qmgr to be administered. Both work. Ive used both. My clients have used both.

The oldest method has been around for many decades, and does not require the MQ client on either platform. One less piece of software to maintain if all you intend is remote admin.

This and many other topics are covered in IBMs Basic System Administration courses, which include hands-on lab exercises.
_________________
There are two types of people in this world:
1) Those that can extrapolate from incomplete data
Back to top
View user's profile Send private message
hughson
PostPosted: Sun May 12, 2019 7:46 am Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1256
Location: Bay of Plenty, New Zealand

vicks_mq wrote:
My question was why the IBM advertise the 1st method, whenever I google about how to administor remote queue managers , it directs me to 1st method.

Once upon a time (before IBM MQ V8 was released) there was only the "via method" and the "client connection" method did not exist (unless you downloaded Paul's MO03 client mqsc support Pac). When Paul left IBM, the very handy client connectivity feature was added to runmqsc. There will be 20+ years of information writers linking to the original method and only ~5 years of the client connection method existing, which I think probably explains why you come across the old method more often than the new one.

vicks_mq wrote:
I want to try second method but before I take permission from our UNIX team and raise a change request for installation of client libraries, I just want to be sure that second method will work.

Both methods work. I use client connectivity more often than via mode, but I did use via mode the other day as a result of writing this blog post:

IBM MQ Little Gem #41: Going "Via"

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
vicks_mq
PostPosted: Sun May 12, 2019 1:25 pm Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

hughson wrote:
vicks_mq wrote:
My question was why the IBM advertise the 1st method, whenever I google about how to administor remote queue managers , it directs me to 1st method.

Once upon a time (before IBM MQ V8 was released) there was only the "via method" and the "client connection" method did not exist (unless you downloaded Paul's MO03 client mqsc support Pac). When Paul left IBM, the very handy client connectivity feature was added to runmqsc. There will be 20+ years of information writers linking to the original method and only ~5 years of the client connection method existing, which I think probably explains why you come across the old method more often than the new one.

vicks_mq wrote:
I want to try second method but before I take permission from our UNIX team and raise a change request for installation of client libraries, I just want to be sure that second method will work.

Both methods work. I use client connectivity more often than via mode, but I did use via mode the other day as a result of writing this blog post:

IBM MQ Little Gem #41: Going "Via"

Hi Morag, got it.

Cheers,
Morag
Back to top
View user's profile Send private message
vicks_mq
PostPosted: Thu Aug 22, 2019 12:14 pm Post subject: Reply with quote

Disciple

Joined: 03 Oct 2017
Posts: 162

Morag
Quote:
Once upon a time (before IBM MQ V8 was released) there was only the "via method" and the "client connection" method did not exist (unless you downloaded Paul's MO03 client mqsc support Pac). When Paul left IBM, the very handy client connectivity feature was added to runmqsc. There will be 20+ years of information writers linking to the original method and only ~5 years of the client connection method existing, which I think probably explains why you come across the old method more often than the new one.

Morag


I used this 1st method and tried to do RUNMQSC on a remote Z/OS queue manager and I hit the error.
echo "dis QSTATUS(ABC.QUEUE)" | runmqsc -w 10 -m LINUXQMGR ZOSQMGR

AMQ8101: WebSphere MQ error (BBB) has occurred.

I believe it has something to do with this document where it says Z/OS commands can only be issued with certain resources

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.adm.doc/q085120_.htm

Quote:
The z/OS console or equivalent
The initialization input data sets CSQINP1, CSQINP2, CSQINPT and CSQINPX
The CSQUTIL batch utility
Suitably authorized applications, sending commands as messages to the SYSTEM.COMMAND.INPUT queue
Back to top
View user's profile Send private message
hughson
PostPosted: Thu Aug 22, 2019 2:58 pm Post subject: Reply with quote

Grand Master

Joined: 09 May 2013
Posts: 1256
Location: Bay of Plenty, New Zealand

vicks_mq wrote:
I used this 1st method and tried to do RUNMQSC on a remote Z/OS queue manager and I hit the error.
echo "dis QSTATUS(ABC.QUEUE)" | runmqsc -w 10 -m LINUXQMGR ZOSQMGR

AMQ8101: WebSphere MQ error (BBB) has occurred.


This error is reported in hex. To see what it means type the following into a distributed platform command line:-
Code:
mqrc 0x00000BBB

This will tell you that this error code means MQRCCF_CFH_VERSION_ERROR

The one difference between z/OS and Distributed with PCF commands, is that z/OS requires V3, whereas distributed can use V1. The problem here is that you have not told the runmqsc command that you are talking to a z/OS queue manager. To do so add the -x flag to the command, e.g.
Code:
echo "dis QSTATUS(ABC.QUEUE)" | runmqsc -x -w 10 -m LINUXQMGR ZOSQMGR


vicks_mq wrote:
I believe it has something to do with this document where it says Z/OS commands can only be issued with certain resources

https://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.ref.adm.doc/q085120_.htm

Quote:
The z/OS console or equivalent
The initialization input data sets CSQINP1, CSQINP2, CSQINPT and CSQINPX
The CSQUTIL batch utility
Suitably authorized applications, sending commands as messages to the SYSTEM.COMMAND.INPUT queue

Not in this case. DISPLAY QSTATUS can be issued via the Run Time Server which is what you are using, so you're all good.

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
fjb_saper
PostPosted: Thu Aug 22, 2019 8:55 pm Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20111
Location: LI,NY

I have used the second method. Best is to use a channel table and the mqccred client side exit for authentication. Otherwise the first row in your runmqsc file will need to contain the password...

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
HubertKleinmanns
PostPosted: Thu Aug 22, 2019 9:44 pm Post subject: Reply with quote

Yatiri

Joined: 24 Feb 2004
Posts: 698
Location: Germany

hughson wrote:
Once upon a time (before IBM MQ V8 was released) there was only the "via method" and the "client connection" method did not exist (unless you downloaded Paul's MO03 client mqsc support Pac).


Hi Morag,

I think it was MO72 (runmqsc client). MO03 was an also famous SupportPac (qload), which is now part of MQ too (as "dmpmqmsg") .

I used both and I loved them .

Hi vicks_mq,

another thing you have to consider about are network/firewall issues. The client connection needs a direct network access to the QMgr. Maybe you would need some firewall changes or have to set up SSL tunnels or whatever. Every MQ administrator needs his/her own firewall rules/SSL tunnels.

For the remote QMgr access you need only access to some other (admin) QMgr, which has acccess to your target QMgr. This admin QMgr could have two network interfaces or a access through a firewall and so would be a central gateway for all MQ administrators. Of course for special plattforms you need some kind of switch ("-x" for z/OS, a special user for Windows, ...).
_________________
Regards
Hubert
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:
Post new topicReply to topic Page 1 of 1

MQSeries.net Forum IndexGeneral IBM MQ SupportIssuing RUNMQSC on a remote queue manager
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.