issue: connecting with spring boot to ibmmq , working ibmmq on dockor version 9.1.5-r2
in online environment: connecting is enabled ,all is fine.
in offline environment channel name is not recognized, getting channel unknown error - 'MQRC_UNKNOWN_CHANNEL_NAME'
channel name DEV.ADMIN.SVRCONN
2 questions:
why offline is different and how it can be fixed?
connected to container with docker exec, how can i find the actual channel name of the queue manager.
Thanks.
To find the channel name:
shell into the container
set the environment by running
setmqenv
See https://www.ibm.com/docs/en/ibm-mq/latest?topic=reference-setmqenv-set-mq-environment
run runmqsc
In the runmqsc prompt run
display channel (*)
See https://www.ibm.com/docs/en/ibm-mq/latest?topic=reference-display-channel-display-channel-definition
Alternatively, you could just log into the MQ Console on https://localhost:9443/ibmmq/console
and list the system channels.
If you are using the IBM MQ Advanced for Developers image from icr.io/ibm-messaging/mq:latest then the channels DEV.APP.SVRCONN and DEV.ADMIN.SVRCONN will have been created for you. Apps will normally use DEV.APP.SVRCONN
If you have built the image locally based on instructions from https://github.com/ibm-messaging/mq-container/blob/master/docs/building.md then you need to have run make build-devserver. If you ran make build-advancedserver then the default DEV channels will not have been created.
Related
I've just installed the demo version of this but fail to connect to the default queue manager. The error in the logs shows me that configuration is not correct for the mq dlls
2022/09/29 17:12:49 MQCmdServer: isCmdServerRunning: Error: MQJE001: Completion Code '2', Reason '2495'.
2022/09/29 17:12:49 MQCmdServer: isCmdServerRunning: getCause()=com.ibm.mq.jmqi.JmqiException: CC=2;RC=2495;AMQ8568: The native JNI library 'mqjbnd64' was not found. For a client installation this is expected. [3=mqjbnd64]
I've tried everything I can to set the path and java.library.path correctly but it all fails. They appear in the visual edit logs as being set but it makes no difference to the outcome.
Visual edit log also tells me that it should have the mq jars in its install directory:
C:\Capitalware\MQVE3\com.ibm.mq.commonservices.jar;
but these are not there and are nowhere to be seen. So, I'm mystified as to what version of the client it's using and therefore what help I can give it. I'm wondering if it's using a different version of the client from the one I have installed and so the dll and mq java lib have a mismatch? Or, if it's using the client I have installed then how is it finding it - because it's not in the paths that I've got in the visual edit logs !
Any thoughts anyone? What can I do to investigate further?
thank you !
Background: There are 2 ways an MQ client application can connect to a queue manager:
(1) Bindings mode means that the MQ client application is connecting to a local (i.e. on the same server) queue manager
(2) Client mode means that the MQ client application will connect to a remote queue manager by specifying the hostname/IP address, port # and channel name
CC=2;RC=2495;AMQ8568: The native JNI library 'mqjbnd64' was not found. For a client installation this is expected. [3=mqjbnd64]
This error mean that you are trying to connect to a local queue manager (in bindings mode) but there is no local queue manager. MQ client library uses the 'mqjbnd64' DLL to handle the connection to the local queue manager. But clearly, the queue manager is remote to where MQ Visual Edit is running.
Go back to the Queue Manager Access Profile, click on the Remote icon, then fill in the channel name, hostname/IP address and port # of the remote queue manager, save the information then you should be able to the remote queue manager.
I'm running a Queue Manager on docker using the latest ibmcom/mq image, but I have an access denied when I try to connect to it from my windows using MQ Explorer.
I've disabled CHLAUTH in MQSC (runmqsc) using the command:
ALTER QMGR CHLAUTH(DISABLED)
I've disabled CONNAUTH using the commands:
ALTER QMGR CONNAUTH(' ')
REFRESH SECURITY TYPE(CONNAUTH)
I've removed the default CHLAUTH rules of the image
SET CHLAUTH(SYSTEM.ADMIN.SVRCONN) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)
SET CHLAUTH(SYSTEM.*) TYPE(ADDRESSMAP) ADDRESS(*) ACTION(REMOVE)
SET CHLAUTH(*) TYPE(BLOCKUSER) USERLIST(*MQADMIN) ACTION(REMOVE)
I've set a Listener and a channel, and added a queue to them
DEFINE LISTENER(LISTENER.TCP) TRPTYPE(TCP) PORT(30002) CONTROL(QMGR) REPLACE
START LISTENER(LISTENER.TCP)
DEFINE CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) TRPTYPE(TCP) REPLACE
DEFINE QLOCAL('MyQueue') REPLACE
When I try to connect to the Channel SYSTEM.DEF.SVRCONN from windows using MQ Explorer, I'm getting the error (AMQ4036). The error in /var/mqm/qmgrs/MyQueueManager/errors/AMQERR01.LOG into the docker container is:
----- cmqxrsrv.c : 2552 -------------------------------------------------------
02/06/20 10:18:13 - Process(1658.19) User(mqm) Program(amqrmppa)
Host(5652aa2322eb) Installation(Installation1)
VRMF(9.1.4.0) QMgr(MyQueueManager)
Time(2020-02-06T10:18:13.718Z)
ArithInsert1(2) ArithInsert2(2035)
CommentInsert1(myWindowsId)
AMQ9557E: Queue Manager User ID initialization failed for 'myWindowsId'.
EXPLANATION:
The call to initialize the User ID 'myWindowsId' failed with CompCode 2 and Reason
2035. If an MQCSP block was used, the User ID in the MQCSP block was ''. If a
userID flow was used, the User ID in the UID header was '' and any CHLAUTH
rules applied prior to user adoption were evaluated case-sensitively against
this value.
ACTION:
Correct the error and try again.
I want to used the queue manager for local development. Do you have any idea on how to disable the security for my windows user id to be able to connect with MQ Explorer and Application Server Weblogic ?
I am wondering why you need to disable security. If you have explorer running then the next step will be to add your queue manager in explorer. From the tutorial -
https://developer.ibm.com/tutorials/mq-macos-dev/
(I know it's for Mac, but the principal is the same for windows).
This will be:
Right click on ‘Queue managers’ in the MQ Explorer Navigator box, then ‘Add remote queue manager’. A pop up appears.
Add your queue manager name – if Docker – QM1, then click Next.
Add Host name or IP Address – if Docker – localhost.
Add Server connection channel – if Docker – DEV.ADMIN.SVRCONN, then click ‘Next’ twice
Tick ‘Enable user identification’, if Docker – default is admin. Leave ‘Prompt for password’ selected.
Click Finish, then add password for user – if Docker – passw0rd. Your queue manager should appear.
If you truly want to disable security and don't care anything about access to this queue manager, just do the following (in addition to all the turning off of security settings you have already done).
ALTER CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(SVRCONN) MCAUSER('user-id-in-mqm-group-on-docker')
The problem is that your 'myWindowsId' is not defined to the OS in your docker container. The above command asserts the user id specified in the MCAUSER field, and will ignore the user id flowed by the channel from your Windows box.
I would however, encourage you to try the earlier answer, and learn how to do enough in security to let yourself in rather than turning it all off.
This question was already answered by joshmc but I'm not understanding the answer after a lot of digging. And don't have enough points to post a comment, sorry.
C# MQ Connect get Error 2035 but Java MQ Connect works well
I only have access to the client and can't change the server, which belongs to a third-party. They require we post messages to their IBM MQ server over the internet for XML integration. We have some simple Java code working fine but can't get the same thing running in .NET because of the 2035 issue. We have a username and password. Trying to do both from the same Windows 10 desktop. Using the version 8 client libraries in both Java and .NET.
The answer Josh discussed was to run
ALTER CHL(ServerChannel) CHLTYPE(SVRCONN) MCAUSER('mq').
This looks like a server-side command or how do we run this on the client, ideally in C#?
The given command is an example of an MQSC command.
To invoke this from your client machine will only be possible if you have been given permissions to make administrative changes on the server from your client.
To try, set up an environment variable to indicate where the server is and what channel name to use:
set MQSERVER=CHANNEL-NAME/TCP/hostname(port)
Then use the runmqsc command as follows:-
runmqsc -c -u yourUserId
The runmqsc tool will prompt you for a password and then try to connect. If it is successful you can then type in the MQSC command. If the MQSC command fails you will have to get the owner of the queue manager to make the change for you.
I am testing a deployment of MQ 9.0.1 using Docker, and trying to administer this instance using the Web console. However I am receiving a warning when attaching widgets stating the "Queue manager unavailable".
Warning messages
In the console I can see my Queues are running and have created local queues and can run commands against them.
Also if I try to modify the Queue security records I get another error:
Failed to get authority recordsWMQWB0003E: The request could not be completed due to an internal web application server error.
Any thoughts or suggestions around this issue?
There is no definitive fix for MQ9.0.1 but upgrading to use MQ9.0.2 will resolve issues with hosting MQ Console on linux.
I encountered a really wired problem. I have successfully install Websphere MQ on my windows machine and want to create QManager and Queue to connect to a remote Qmanager server. I have already created a QManager as you can see in the picture below. However, when I tried to create a queue for this QManager, I could not find any expand button as the IBM tutorial mentioned.
I have already tried to create a queue with MQSC but when I run runmqsc in the command prompt with administrator user, it shows AMQ8135: Not Authorized error!
Check your error logs (AMQERR01.LOG) for an explanation of why AMQ8135 was returned to the client - for security reasons clients aren't given more information and so you have to go to the logs to get the detail.
I suspect the user you're running MQ Explorer and runmqsc as isn't in the 'mqm' group, or is otherwise not authorised to connect to the queue manager.
Run your IBM MQ Explorer as administrator and it will solve most of the issues.