| Author |
Message
|
| famls |
 Posted: Tue Sep 24, 2002 4:09 am Post subject: Problem with remote queues and channels |
 |
|
Newbie
Joined: 24 Sep 2002
Posts: 4
|
Hi!
I'm new on MQSeries and I'm trying to create some remote queues on Solaris. From what I read it's necessary to create also some channels and transmission queues. I tried the following:
-- server1 --
# Channels
.define channel(server1.to.server2) chltype(sdr) conname(server2) trptype(tcp) xmitq(XMITQ.IN.QUEUE)
.define channel(server2.to.server1) chltype(rcvr) trptype(tcp)
# Remote queue
.define qlocal(XMITQ.IN.QUEUE) usage(xmitq)
.define qremote(IN.QUEUE) rname(IN.QUEUE) rqmname(server2) xmitq(XMITQ.IN.QUEUE)
#Local queue
.define qlocal(OUT.QUEUE)
-- server2 --
# Channels
.define channel(server2.to.server1) chltype(sdr) conname(server1) trptype(tcp) xmitq(XMITQ.OUT.QUEUE)
.define channel(server1.to.server2) chltype(rcvr) trptype(tcp)
# Remote queue
.define qlocal(XMITQ.OUT.QUEUE) usage(xmitq)
.define qremote(OUT.QUEUE) rname(OUT.QUEUE) rqmname(server1) xmitq(XMITQ.OUT.QUEUE)
#Local queue
.define qlocal(IN.QUEUE)
When I try to send a message using the remote queue nothing reaches the orher side.
Another problem I'm having is that I can't start the channel using the following command (executed on serve1 and the default queue manager):
runmqchl -c server1.to.server2
It's gives the following errors:
AMQ9519: Channel 'server1.to.server2' not found.
AMQ9999: Channel program ended abnormally.
But it existes. Running runmqsc I can see the channel definition.
Just one more question: how can I see if a channel is running?
Sorry for the long post.
Thanks in advanced.
Regards,
Fernando Silva |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Tue Sep 24, 2002 4:28 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
well i believe your issue with starting the channels is that you have case issue.
when defining channels unless you put the name in quotes 'server1.to.server2' the name will default to uppercase (real unix like )
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| famls |
| Posted: Tue Sep 24, 2002 8:01 am Post subject: |
|
|
Newbie
Joined: 24 Sep 2002
Posts: 4
|
Thanks about starting the channels.
Now I can start them up. I checked the status and they are running in both machines.
Now my problem is putting a message on a remote queue and receive it on the other side.
Besides starting up channels what more is needed?
I execute on server1:
amqsput IN.QUEUE
and I insert some lines... no error.
On server2 I execute:
amqsget IN.QUEUE
and no messages are available.
What am I doing wrong? Could it be from the configuration?
Thanks in advance.
Regards,
Fernando Silva |
|
| Back to top |
|
|
| mrlinux |
| Posted: Tue Sep 24, 2002 8:07 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
It's possible you have case issue there, all string definitions in MQSeries on unix platforms default to upper case unless quoted.
Of course on windows it uses whatever case you type in.
To me this seems reversed (WINDOWS typically ignores case and UNIX is the case sensitve one)
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| nando32 |
| Posted: Tue Oct 15, 2002 8:30 pm Post subject: |
|
|
Newbie
Joined: 01 Jul 2002
Posts: 9
Location: Sacramento California
|
Working with Unix I can tell you that it does not matter if you use upcase with IN the runmqsc command line. Try to ping the channel and see what you get back. Also try to ping the server from the operating system /usr/sbin/ping. I did not see the port in the conname, are if you are using the default port 1414 this will work. If you have changed ports you will need to add it in the conname (example CONNAME ('12.258.256.5(1415)') Your problem might be at the OS level, or a simple typing error.
_________________
Fernando Acosta
Barclays Global Investors |
|
| Back to top |
|
|
| bduncan |
| Posted: Tue Oct 15, 2002 8:53 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
| Quote: |
| Working with Unix I can tell you that it does not matter if you use upcase with IN the runmqsc command line. |
This is not correct. While most parts of runmqsc accept either case (they infact upcase everything you type, which is different than being case insensitive) there are some places where the case you use matters.
If you are defining a process and you're entering the actual command to be run, you must enclose it in single quotes or the whole string will be upcased, in which case your trigger may not work.
In fact, anything, even a queue can be defined in a case-sensitive context. To illustrate, try doing this in runmqsc:
"define ql(test)"
"define ql('test')"
"alter ql(test) maxdepth(123456)"
"dis ql(test)"
"dis ql('test')"
The first suprising thing is that the second define command doesn't fail. You now have, in fact, two different local queues. Changing the depth on one and then displaying the attributes of each proves this...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| nimconsult |
| Posted: Tue Oct 15, 2002 11:37 pm Post subject: |
|
|
Master
Joined: 22 May 2002
Posts: 268
Location: NIMCONSULT - Belgium
|
Fernando, you will either find your messages on the transmission queue of server 1 (XMITQ.IN.QUEUE), in which case you have a channel proble, or on the system dead-letter queue of server 2 (normally SYSTEM.DEAD.LETTER.QUEUE), in which case you read the queue content and find the exact reson of the problem in the dead-letter message header.
If you have not defined a dead-letter queue on server 2 I strongly recommend you to do so:
alter qmgr deadq(SYSTEM.DEAD.LETTER.QUEUE)
-
Nicolas
_________________
Nicolas Maréchal
Senior Architect - Partner
NIMCONSULT Software Architecture Services (Belgium)
http://www.nimconsult.be |
|
| Back to top |
|
|
| mgrabinski |
| Posted: Wed Oct 16, 2002 1:11 am Post subject: |
|
|
Master
Joined: 16 Oct 2001
Posts: 246
Location: Katowice, Poland
|
Fernando,
Is 'server2' a host name or a queue manager name or both? What's the actual spelling of your queue manager name (lower/upper case)?
_________________
Marcin Grabinski <>< |
|
| Back to top |
|
|
| TonyD |
| Posted: Wed Oct 16, 2002 2:27 pm Post subject: |
|
|
Knight
Joined: 15 May 2001
Posts: 540
Location: New Zealand
|
| I would strongly suggest that you redefine everything with UPPER-CASE names and then start off again. |
|
| Back to top |
|
|
| jc_squire |
| Posted: Mon Oct 21, 2002 3:13 pm Post subject: |
|
|
Centurion
Joined: 14 Apr 2002
Posts: 105
Location: New Zealand
|
u should also setup triggering on the xmitq so that the chl can be triggered if it has gone inactive
Also, have you checked the error logs?
Suggestion (observing case sensitivity ofcourse):
1. Stop the channel from server1.to.server2
2. using amqsput put a message to the R/Q def on server1
3. ensure that the curdepth attribute of the xmitq on server1 has incremented
4. start the chls and check the chl status
5. check the curdepth attribute of destination queue on server2
6. using amqsget get the message from the destination queue and verify the content.
This process will pinpoint where you have problems i.e. could be a number of issues here.
Good luck !!!
_________________
J C Squire
IBM Certified Specialist - MQSeries |
|
| Back to top |
|
|
|
|
