We are have a IBM websphere MQ[v5.2] on AIX platform and my machine is windows 7 pro which has MQ client v7.5.
I tried to connect to server remotely but i received a Authorization error message. This is because my local user account does have rights to connect to queue manager remotely.
So,i created a new user account in my system with some name as on server which has rights to put/get message and now i am able to connect in client mode[Websphere MQ v7.5].
I don't know whether it is actually connecting to server but it is not giving me authorization error message so i took it as success. But the issue is, when I tried to put message into queue from cmd using amqsputc Queue_name mqm the queue is opening and taking a message. But when i tried to get the message using command amqsgetc queue_name mqm it says "NO MORE MESSAGE".
What could be the issue?
Screen shot:
The fact the amqsputc doesnt give an error, and the fact the amqsgetc runs through to success implies the functionality is working. However, it finds nothing on the queue which makes me very suspicious that you have an application listening on that queue, which will consume the message as it arrives and hence before your amqsgetc. Check DISPLAY QSTATUS in runmqsc for IPPROCS on the queue - is it 0 when amqsgetc isnt running?
Related
I trying to connect RFHUTIL from my laptop to remote MQ server but its show error
09.43.47 Open for temporary reply queue failed rc=2035
Error getting queue names
Below are from Queue Manager Error Log:
2/26/2021 02:43:44 - Process(2716.35) User(MUSR_MQADMIN) Program(amqzlaa0.exe)
Host(MCP-50-50-1-5) Installation(Installation1)
VRMF(9.1.0.7) QMgr(mq)
Time(2021-02-26T01:43:44.367Z)
RemoteHost(50.50.1.2)
CommentInsert1(g525097#mcp-50-50-1-5)
CommentInsert2(SYSTEM.DEFAULT.MODEL.QUEUE)
CommentInsert3(get)
AMQ8077W: Entity 'g525097#mcp-50-50-1-5' has insufficient authority to access
object 'SYSTEM.DEFAULT.MODEL.QUEUE'.
EXPLANATION:
The specified entity is not authorized to access the required object. The
following requested permissions are unauthorized: get
ACTION:
Ensure that the correct level of authority has been set for this entity against
the required object, or ensure that the entity is a member of a privileged
group.
Are you using any SYSTEM.*.SVRCONN channels? Because CHLAUTH rules (on the queue manager) can be blocking you.
RFHUTILC uses your Windows UserId for authentication (MQ v8.0 or higher) and authorization for MQ objects (i.e. queue manager, channels, queues, etc.)
Did your MQAdmin give your UserId, or group which your UserId is in, permission to access the queue manager and the queues?
From the error message you have provided in your question, you need to run the following MQSC command (that is a command issued using the runmqsc tool). If you don't have full authority over this queue manager then I suggest you ask your MQ administrator to run this command. If you do have full authority over this queue manager then make sure you are running the runmqsc tool with the same user id that your started the queue manager with, and that you are running it on the machine where the queue manager resides.
SET AUTHREC PROFILE('SYSTEM.DEFAULT.MODEL.QUEUE') OBJTYPE(QUEUE) GROUP(the-group-that-user-id-g525097-is-in) AUTHADD(GET)
If it still fails after you do this, please post the new error message because it will likely need other permissions and the error message, while similar, will be different.
Try to run this command on queue manager and then try to access
ALTER QMGR CHLAUTH(DISABLED)
When I start the Messaging queue It shows:
Windows could not start the IBM MQ (Installation1) service on local
computer.
Error 1053: The service did not respond to the start or control
request in a timely fashion.
From the queue manager when I create with this code:
Command: "C:\DATA\TEMP\SoftwareInstallation\bin\crtmqm" -sa test
The following error occurs:
AMQ7257S: The MQ service for installation 'Installation1'
(C:\DATA\TEMP\SoftwareInstallation) must be running.
exitvalue = 74
The second error your are getting is because, unless the IBM MQ service is running, nothing related to it works. As far as the issue with the service not coming up is concerned it is to do with the windows account through which you are trying to start the service.
You can refer the below link to find a fix,
https://support.microsoft.com/en-in/help/886695/you-receive-an-error-1053-the-service-did-not-respond-to-the-start-or
I create a queue manager like QMTEST in IBM WebSphere MQ Explorer. I want to connect to a remote queue manager (remote ip address). I followed these steps:
add remote Queue manager
Queue manager name: QMTEST [Next]
Host Name or ip Address: X.X.X.X(remote ip) [Finish]
But I couldn't connect. I got this error message 'Could not establish connection to the queue manager-reason 2538.(AMQ4059)'. What can I do?
The four digit number in your error message is an MQRC (MQ Reason Code). This number gives you more information about what went wrong. You can look it up in Knowledge Center.
MQRC_HOST_NOT_AVAILABLE (2538)
There is a list of possible things that could cause this error. My guess is it is likely to be the first one, you have not started a listener on the queue manager, since you do not mention doing that in your question details.
You should also read the following link which is some basic details on how to connect to a remote queue manager. You appear to have the MQ Explorer side sorted, but perhaps not the queue manager side.
Setting up the server using the command line
Please ensure the listener is running on the remote queue manager side. The default MQ listener port is 1414. If the listener is running then check the queue manager error logs for any connection errors from the MQ explorer.
Are you sure the qmgr and its listener are running and that you have a SYSTEM.ADMIN.SVRCONN channel? That is the server-connection channel used for remote administration of a queue manager. This technote may be helpful.
Is this on a modern Windows or Linux server? If so, did you open the port (i.e. 1414) in the firewall?
Sometimes when we create a Queue manager remote administration objects are not created that's why we get such errors because it is unable to find these objects. To create them right click on the queue Manager, Select Remote Administration objects and create them and start the listener.
I experienced this same error and the queue was configured correctly.
I was using Eclipse and switched to the MQ Explorer setup available from IBM web page.
After that, I was totally able to see the queues and everything I was supposed to see.
I am trying to put a message into Websphere MQ queue from an Orchestration which is deployed on Cast Iron Live. I have used secure connector since the orchestation is deployed on Cast Iron. When I am trying to execute the flow, it fails and the message is not placed in MQ queue. The below are the errors:
Error while trying to call remote operation execute on Secure Connector for activity
com.approuter.module.mq.activity.MqPut and Secure Connector LocalSecureConnector,
error is Unable to put message on queue null. MQ returned error code 2538.
Unable to put message on queue null. MQ returned error code 2538.
Fault Name : Mq.Put.OperationActivityId : 163
Message: Unable to put message on queue null. MQ returned error code 2538.
Activity Name:Put MessageFault Time: 2015-07-15T05:40:29.711Z
Can someone please help me resolve this. Please let me know if any further details are required.
Here are the details:
Cast Iron flow is deployed on Cast Iron Cloud i.e Cast Iron Live
MQ is running on-premise
The port I am trying to connect is 1414.
Have a secure connector running on the machine where MQ is installed.
MQ version is 8.
In Cast Iron flow, I am using an MQ connector, by giving the hostname where MQ is running, port: 1414, Channel Name : SYSTEM.DEF.SVRCONN and username as mqm. Tired using my log on username, by adding it to mqm group. But this also dosent seem to work.
The return code is instructive:
2538 0x000009ea MQRC_HOST_NOT_AVAILABLE
This indicates that Cast Iron is attempting to contact MQ using a client connection and not finding a listener at the host/port that it is using.
There are a couple of possibilities here but not enough info to say which it might be. I'll explain and provide some diagnostics you can try.
The 2538 indicates an attempt to contact the QMgr has failed. This might be that, for example, the QMgr isn't listening on the configured port (1414) or that the MQ listener is not running.
The error code says the queue name is "null". The question doesn't specify which queue name the connector is configured with but presumably it's been configured with some queue name. This error code suggests the Secure Connector on the MQ server side doesn't have its configuration installed.
The Cast Iron docs advise connecting with an ID in the mqm group but do not mention that on any MQ version 7.1 or higher this is guaranteed to fail unless special provisions are made to allow the admin connection. It may be that it's actually failing for an authorization error and the connector not reporting the correct error.
If it is as simple as the listener not running, that's easy enough to fix. Just start it and make sure it's on 1414 as expected.
Next, ensure that the Secure Connector has the configuration that was created using the Cast Iron admin panel. You need to understand why the error code says the queue name is null.
Now enable Authorization Events and Channel Events in the QMgr and try to connect again. The connector on the MQ server should connect when started and if successful you can see this by looking at the MQ channel status. However, if unsuccessful, you can tell by looking at the event messages or the MQ error logs. Both of these will show authorization failures and connection attempts, if the connection has made it that far.
The reason I'm expecting 2035 Authorization Error failures is that any QMgr from v7.1 and up will by default allow an administrative connection on any channel. This is configured in the default set of CHLAUTH rules. The intent is that the MQ admin would have to explicitly provision admin access by adding one or more new CHLAUTH rules.
For reasons of security SYSTEM.DEF.* and SYSTEM.AUTO.* channels should never be used for legitimate connections. The Best Practice is to define a new SVRCONN, for example one named CAST.IRON.SVRCONN and then define a CHLAUTH rule to allow the administrative connection.
For example:
DEFINE CHL(CAST.IRON.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(ADDRESSMAP) +
ADDRESS('127.0.0.1') +
USERSRC(MAP) MCAUSER('mqm') +
ACTION(REPLACE)
SET CHLAUTH('CAST.IRON.SVRCONN') TYPE(BLOCKUSER) +
USERLIST('*NOBODY') +
WARN(NO) ACTION(REPLACE)
The first statement defines the new channel.
The next one allows the connections from 127.0.0.1 which is where the Secure Connector lives. (Presumably you installed the internal Secure Connection on the same server as MQ, yes?) Ideally the connector would use TLS on the channel and instead of IP filtering the CHLAUTH rule would filter based on the certificate Distinguished Name. This rule is not nearly so slective and allows anyone on the local host to be an MQ administrator by using this channel.
The last statement overrides the default CHLAUTH rule which blocks *MQADMIN with a new rule that blocks *NOBODY but just for that channel.
I am quite new to MQ FTE and having issues to getting it work. Basically, I want to setup a simple environment between two queue managers that I can use to transfer files. Here is what i did:
One the first machine, I set up a queue manager and called it CMQ. Create a local queue called RECEIVED.MESSAGES and a remote queue SENT.MESSAGES. Also created a transmission queue.
Defined a transmission channels needed to communicate with the second queue manager.
One the second queue manager (SMQ), repeated the same process for creating local and remote queues, channels etc.
At this point, if I can both send and receive messages between the two Queue managers.
Next, on the first machine running queue manager CMQ, I carried out the following:
ran fteSetupCoordinate specifying the queue manager, host, port and channel SYSTEM.ADMIN.CONN
ran fteSetupCommand with the same details and specified host, port, channel (SYSTEM.ADMIN.CONN)
Ran the mqsc scipt file generated by fteSetupCoordinate.
Ran fteCreateAgent with QMgrName as CMQ, host, port and channel as SYSTEM.ADMIN.CONN
This is where the problem starts. The fteCreateAgent command end up with a message saying Agent was created successfully but could not registered with CMQ. The exact error is:
"BFGMQ1007I: The coordination queue manager cannot be contacted or has refused a connection attempt.
The WebSphere MQ reason code was 2058. The agent's presence will not be published.
I've tried every possible solution in forums and IBM's site including the troubleshooting found on this link:
But nothing works. As a result, the agent is never seen in MQ explorer. I also do not see the agent when I issue ftListAgent ..
Any ideas guys? Is there something I'm missing?
Thanks in advance
Get to know the mqrc command. It is your friend.
mqrc 2058
2058 0x0000080a MQRC_Q_MGR_NAME_ERROR
The error code you are getting back indicates that a connection was made to a QMgr but that it wasn't the one that was expected. That means either you have a typo in the QMgr name when you ran fteCreateAgent or you pointed the agent to the wrong QMgr.