issue facing while loading the messages in to mq channel, recieving an error like below pasted
MQOPEN ended with reason code 2001
unable to open queue for output
how can i resolve this above issue,kindly can any one please advice on the same
The return code resolves as follows:
C:\>mqrc 2001
2001 0x000007d1 MQRC_ALIAS_BASE_Q_TYPE_ERROR
The Infocenter page for this return code provides the following explanation:
2001 (07D1) (RC2001): MQRC_ALIAS_BASE_Q_TYPE_ERROR
Explanation
An MQOPEN or MQPUT1 call was issued specifying an alias queue as the destination, but the BaseQName in the alias queue definition resolves to a queue that is not a local queue, a local definition of a remote queue, or a cluster queue. Completion Code
*MQCC_FAILED Programmer response*
Correct the queue definitions.
In other words, the queue your app is opening is an alias queue. If you are opening for input and the base queue is not a local queue, this error results. If you are opening for output and the base queue is not a local queue, a local definition of a remote queue, or a cluster queue you also get this error.
What is not mentioned in the error code above is that if the alias queue points directly to a transmit queue you also get this error. In that case what you need is a QRemote and not an alias.
Related
I have a KafkaConsumer which consumes messages, does some processing and then a KafkaProducer sends message to another topic. I am currently manually committing the offset using Acknowledge.acknowledge() when KafkaProducer successfully sends message to another topic, but I do not call Acknowledge.acknowledge() when message fails to send. I have set ackMode to AckMode.MANUAL_IMMEDIATE
However when I do not commit the offset manually, KafkaConsumer should pick the same record that failed to process (i.e failed to send to another topic) but even on failure the offset is incremented and the next record is processed. Can anyone tell me why this is happening? And how can I achieve this by process the failed records, business people mentioned like don't want create the kafka topic/DB for store the error records and reprocess it. Ihave only option to store the error data in file only for store, reprocess and publish to the destination kafka topic. Could some one help me to resolve this issue?
i try to use solace with spring boot.
here is a demo application and the log its create:
https://github.com/GreenRover/solace_spring_multiconnection/blob/master/problem.log
I wonder about this error (INFO) message
c.s.jcsmp.impl.SessionModeSupport .... - Error Response (400) - Already Exists
Is it normal to get this message or goes something wrong?
This message indicates that a queue fails to be created because a queue with the same name already exists.
This is expected since your sample code tries to create a queue with the same name more than once. It is ok to ignore this message.
However, if you want to avoid the message, the application has to make sure that only one queue is created with the name.
MQ file system got 100% used in one of our queue managers and we found that our system.cluster.transmit queue is occupied the full space so I have deleted the q file.so file system issue got resolved.Now I was trying to delete the transmit local queue using delete qlocal command so I need to create the queue again as my queue got damaged but when I am trying to delete the queue I am getting MQ object is in use and I checked the handles to kill it but it says MQ object got damaged so please help me to how to delete the queue now.
If you are running linear logging you can recreate the damaged object, but in this case that would fill the file system. Instead, temporarily define a new QMgr and then get a copy of its file for the same queue and drop it into the directory where you deleted the file.
As a side note, you might also want to start a new question asking how to delete the messages in the XMitQ without blowing away the file.
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)
When trying to start a queue manager I get a AMQ7017 Log not available message. I have checked, the LogPath for the queue manager in the mqs.ini file is correct. When the problem started I checked and there were two log files in the log folder for the manager: S000000 and S0000002. I simply copied the first one and renamed the copy to S000001 (with the correct number of zeroes). Still the same error.
How can I fix this issue?
I hope its not a production qmgr. Few options below.
You can restore the missing log file from backup and try to start.
Create a qmgr of the same name (in another machine) with the same qm.ini. Basically the log setting should be the same as this qmgr. Copy the log files from that machine to this qmgr and try to start the qmgr. If it starts, the qmgr might recover the persistent messages from the queue files. This is not recommended by IBM, but works in some situations. If its a non-production qmgr, this is the best way.
recreate the qmgr