| Author |
Message
|
| Xavier |
 Posted: Fri Dec 14, 2007 6:52 am Post subject: Remote Ip/port/channel OK but CCDT can't work. 4043 [SOLVED] |
 |
|
Newbie
Joined: 14 Dec 2007
Posts: 6
|
Hello,
I do have a problem when I try to connect remotely using AMQCLCHL.TAB : error AMQ4043.
It works fine with QueueManager name, host (ip), port and channel. I can get/send message with the Websphere MQ Explorator :
But I got the error when I load a copy of the AMQCLCHL.TAB from the server (/qmrgs/xxx/@ipcc/) and use the QueueManager name :
Error is : AMQ4043
"Queue manager not available for connection. Ensure that the queue manager is running. If the queue manager is running on another computer, ensure it is configured to accept remote connections."
Why could it be working with ip/port/channel and not with the CCDT ? Is there something in particular to do with the generation of the file AMQCLCHL.TAB on the server's GUI ?
PS: MQCHLLIB and MQCHLTAB are properly set.
Last edited by Xavier on Fri Dec 21, 2007 7:57 am; edited 2 times in total |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Dec 14, 2007 6:55 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Have you double checked the definition of SVRCONN / CLNTCONN on the queue manager? Especially check you've quoted the port number if you're not using 1414.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Xavier |
| Posted: Fri Dec 14, 2007 7:36 am Post subject: |
|
|
Newbie
Joined: 14 Dec 2007
Posts: 6
|
I tried to check with a msdos window:
>runmqsc myqueuemanagername
>DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(SVRCONN)
It replied : already existing.
>end
Then I did :
>runmqsc myqueuemanagername
>DIS CHL(*) CHLTYPE(CLNTCONN) ALL
>DEFINE CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('pc998(1414)')
>DEFINE CHANNEL(default) CHLTYPE(CLNTCONN) CONNAME('pc998(1414)')
>end
It updated my *.tab file, and I still have the AMQ4043 error.
I'm using the port 1414 and v6.0 of WebSphere MQ. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Dec 14, 2007 7:56 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
If the MQSERVER is set, it will override the CCDT variables.
How do you know what is inside the CCDT? The only way to know for sure is to use the MO72 support pack to query the CCDT definitions.
Note that in V6, the only way to reliable control the contents of the CCDT is to never modify it in anyway outside the PCF messages (MQ Explorer) or runmqsc.
And now that I see your post, you are missing the QMGR name on the CLNTCONN def.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 14, 2007 7:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
There's no QMNAME defined on the CLNTCONN, so if you quote the name in the connection info no tab entry will match. Try connecting to a queue manager called ' '. Or define another CLNTCONN with the queue manager's name in it.
You'll find details of how these names are resolved in the Clients manual. I (for this reason and others) steer clear of using the SYSTEM objects and always define my own client connections, dead letter queues and so forth. If nothing else, it means you don't have to have "show SYSTEM" switched on in Explorer and hence less irrelevent (in normal circumstances) material is shown.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Xavier |
| Posted: Fri Dec 14, 2007 8:50 am Post subject: |
|
|
Newbie
Joined: 14 Dec 2007
Posts: 6
|
| JosephGramig wrote: |
| If the MQSERVER is set, it will override the CCDT variables. |
It's not set.
| JosephGramig wrote: |
| How do you know what is inside the CCDT? The only way to know for sure is to use the MO72 support pack to query the CCDT definitions. |
Except the result of "DIS CHL(*) CHLTYPE(CLNTCONN)", I don't know what's inside.
So I did another attempt with the QMNAME :
>runmqsc myqueuemanagername
>ALTER CHANNEL(SYSTEM.ADMIN.SVRCONN) CHLTYPE(CLNTCONN) CONNAME('pc998(1414)') QMNAME(myqueuemanagername) TRPTYPE(TCP)
>ALTER CHANNEL(default) CHLTYPE(CLNTCONN) CONNAME('pc998(1414)') QMNAME(myqueuemanagername) TRPTYPE(TCP)
>end
And I still have the error. Do I have to restart Websphere server everytime I run "runmqsc" commands ? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 14, 2007 8:53 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Try
| Code: |
telnet pc998 1414
ctrl+]
quit |
If this works you should be able to connect 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Xavier |
| Posted: Fri Dec 14, 2007 8:58 am Post subject: |
|
|
Newbie
Joined: 14 Dec 2007
Posts: 6
|
| There is no such problem coz' It works fine with QueueManager name, host (ip), port and channel configuration, it also works fine with the MQSERVER var and a C# application. |
|
| Back to top |
|
|
| JosephGramig |
| Posted: Fri Dec 14, 2007 9:36 am Post subject: |
|
|
Grand Master
Joined: 09 Feb 2006
Posts: 1244
Location: Gold Coast of Florida, USA
|
ok,
What you have done is provide two entries for the QMGR named 'myqueuemanagername' and the channel named 'default' will always be tried first be cause it is lexically the first channel name.
If you do not have a matching SVRCONN at that QMGR with precisely the same name, you will have this problem.
I recommend you only have one CLNTCONN entry per QMGR for the CCDT you want to use with MQ Explorer.
Let me strongly recommend that you use MO72 Support Pack to manage those CCDT files. If you choose to use any other method, the only use runmqsc and keep all your scripts.
_________________
Joseph
Administrator - IBM WebSphere MQ (WMQ) V6.0, IBM WebSphere Message Broker (WMB) V6.1 & V6.0
Solution Designer - WMQ V6.0
Solution Developer - WMB V6.1 & V6.0, WMQ V5.3 |
|
| Back to top |
|
|
| Xavier |
| Posted: Thu Dec 20, 2007 4:39 am Post subject: |
|
|
Newbie
Joined: 14 Dec 2007
Posts: 6
|
I did another attempt in following this process :
| Code: |
[b]The second method is to define a channel table (AMQCLCHL.TAB) on the server and export that file to the client. [/b]
1. Create a SVRCONN channel on the server,
2. Create a CLNTCONN channel also on the server (with the same name).
3. From the server, copy the AMQCLCHL.TAB file (found in the
\qmgrs\QUEUEMANAGERNAME\@ipcc directory) to the client.
4. On the client, define the following two environment variables:
set MQCHLLIB= \path where you copied AMQCLCHL.TAB
set MQCHLTAB=AMQCLCHL.TAB |
Firstly I tried with the Websphere Explorator :
I created a new QueueManager named QM_pc.
I added a queue named "S_pc", then a server channel named "default".
I added a client connexion also named "default" with the right host/port in TCP.
This time I have a AMQ4059 (Could not establish a connection to the queue manager) with the AMQCLCHL.TAB generated file. But it works with the host/port method (MQSERVER=ChannelName/TCP/ConnectionName(port)).
I must do something wrong in my chanels and as a reuslt I have a AMQCLCHL.TAB that doesn't work. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Dec 20, 2007 12:55 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Change the clnt chl definition:
| Quote: |
| I added a client connexion also named "default" with the right host/port in TCP. |
and add the qmgrname to it. (note it need not be the qmgrname, this is a place holder)
Make sure the case of channel name match.
Connect to '*qmgrname' check that case matches your definition. You noticed that there is a * at the start that is not in the definition. This tells the client to ignore the fact that the qmgr you are connecting to does not have that name...
Enjoy and read the manuals on client connection and connection resolution with a CCDT
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Xavier |
| Posted: Fri Dec 21, 2007 7:56 am Post subject: |
|
|
Newbie
Joined: 14 Dec 2007
Posts: 6
|
Thank you all.
I learned a lot of stuff. It works fine right now.
To solve my problem I just re-created the channel in mode "Server connexion channel" instead of "Server channel". (The words may be disordered I have a French version). |
|
| Back to top |
|
|
|
|
