Run MQSC Command via SYSTEM.ADMIN.COMMAND.EVENT - ibm-mq

I have connected remotely to a QMgr via MQ Explorer on Windows. The MQ server version is 7.5.0.1. I can put messages in SYSTEM.ADMIN.COMMAND.EVENT from MQ Explorer successfully and when I dump SYSTEM.ADMIN.COMMAND.EVENT, I can see my messages. As long as I know, I should be able to run PCF commands and MQSC commands via this channel. So, I put DISPLAY QMGR ALL message inside this queue and I can successfully see this message on MQ Server. My question is how can I run this message remotely via this channel? Thanks.
IBM Doc indicates that I should be able to receive the command result in SYSTEM.MQSC.REPLY.QUEUE. But I can not browse this queue from client MQ Explorer. The queue type for this queue is Model.

Couple of problems here.
First, you are using the wrong queue. The command server listens on SYSTEM.ADMIN.COMMAND.QUEUE. The queue to which you are sending messages, SYSTEM.ADMIN.COMMAND.EVENT is the queue to which the QMgr puts event messages after executing commands, provided of course that command events are enabled.
The second problem, as Jason mentions, is that the runmqsc processor takes human-readable script and converts it into commands the QMgr can understand. Passing textual commands directly to the command server won't work.
Typically we do what you want by passing the commands to runmqsc directly such as...
echo DISPLAY QMGR ALL | runmqsc MYQMGRNAME
If you require the ability to do this as a client, then you want to either download SupportPac MO72, or head over to MQ Gem and pick up a copy of MQSCX. Either of these will accept the command above on a local queue manager, and both can also be supplied with MQ Channel params and connect to a remote QMgr.
In addition to this basic functionality, the MQSCX product also has its own internal script parsing and execution. Suppose, for instance, that you want to do something depending on the command level of the QMgr.
Using runmqsc you could issue the command above, filter the resulting 2-column output through grep, awk, or similar, then capture the final output into a variable. You might need to do this multiple times to capture multiple values, invoking a new runmqsc each time and parsing the output in your script. You must then generate the string for the actual command you wanted to run when you started all this, and pass it to another invocation of runmqsc.
Alternatively, MQSCX lets you issue the DISPLAY command, then reference the resulting values directly by name. For example, you can pass MQSCX a couple lines of script telling it to inquire on the QMgr and then take a conditional action based on the command version, all without ever having to drop back into shell, bat or Perl script.
Full disclosure, I do not work for or get a commission from MQ Gem. I just don't like to beat my head against the wall writing 100 lines of code where 2 will do. If you do any amount of MQSC scripting, the ROI on MQSCX is measured in minutes. And it happens to be 100% on-topic as an answer to this question.

The command server doesnt process textual messages, it processes PCF messages. You need to build a message in PCF format and it can be processed. See http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.adm.doc/q019980_.htm
Ideally you would use real PCF format but there is a PCF format where you can send MQSC commands ('escaped' PCF - see here http://www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.ref.adm.doc/q087230_.htm?lang=en)

Related

How to find the date of creation or first use of each channel in MQ Explorer?

We have have 5 channels in our IBM MQ Explorer for the App.To.REG queue manager.
I want to find the date of creation or first use of each channel.
I have tried both display channel and display chstatus command but it didn't gave the required details.
You will need an MQ Configuration and/or Monitoring tool for that type of information. Also, you will need to turn on the queue manager's Configuration Events. The DIS CHL() command will only give you the last altered date & time.

how to automate the back out queue clearance in WMQ?

in production support i have to delete every day messages from 100 of queues from different queue managers in WMQ (WMQ IBM) manually. can it be automated such that by running a script message in back out queue should be deleted .?
my requirements :
1. by giving queue name i should be able to delete message from queue and date should be the selecting criteria.
There is quite an exhaustive list of possible solutions here:
http://www.capitalware.com/rl_blog/?p=1616
You should take a look at the options with the Java or C program, by modifying the program you can implement your 2nd requirement to delete messages sent on a given date.
my requirements : 1. by giving queue name i should be able to delete
message from queue and date should be the selecting criteria.
If you need to delete messages older than a particular date then the blog posting will not help. You will need to use a program like MQ Batch Toolkit.
i.e. To delete messages older 2 days then you would issue:
mqbt ClearQByTime -p MQA1 -q TEST.Q1 -d 2
If you need to run it on a daily basis then put the command into the scheduler on the server.

Websphere Message broker multi-instance message flow

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.

How do I suppress the boilerplate 'WASX7209I: Connected to process...' from the wsadmin command?

I have a wsadmin script that needs to produce a very specific output format that will be consumed by a third-party monitoring tool. I've written my Jython script to produce the correct output except that wsadmin always seems to spit out this boilerplate at the beginning:
WASX7209I: Connected to process "dmgr" on node [node] using SOAP connector; The type of process is: DeploymentManager
Is there a way to suppress this output or will I need to do some post processing to strip off this superfluous info?
I'm not aware of any way to suppress that output from being generated. I think you're going to have to strip it out post execution if your consuming system can't handle it...

WebSphere MQ FTE Agent Directory does not exist?

When I tried to start an FTE agent in the command prompt , it displays the error message as "An internal error has occurred. Unable to complete the command because the agent directory does not exist".
What would be the reason for this? It was working fine until yesterday. And is there any way to start an agent in MQ FTE itself? I use fteStartAgent in command prompt each time to start an agent.
Kindly advise me on this....
There are a few possible reasons for this. It is possible that the default properties were changed and now point to an invalid location. This usually happens when the different components are installed and you select to provide the connection details again rather than to reuse the existing configuration.
Another possibility is that the default properties have been changed to point to a different Coordination QMgr. Sometimes people want to run Prod and Dev agents on the same host and set up connectivity to more than one Coordination QMgr. The result is that the default properties can point to only one at a time and so some agent directories are found while others are not. The trick to making this work is to use the -P option to select the proper Coordination QMgr.

Resources