| Author |
Message
|
| Vin |
 Posted: Fri May 10, 2002 6:44 pm Post subject: |
 |
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| I tried to trigger a channel using the initiation queue as system.channel.initq. The channel is not getting triggered.I set up the transmission queue to have the attribute initq as system.channel.initq. Is there something wrong I'm doing? Not getting a clue as to what's wrong? Thanks. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Sat May 11, 2002 10:27 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
|
| Back to top |
|
|
| Vin |
| Posted: Tue May 14, 2002 8:36 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| My channel Initiator is running but the queue is not trigerred somehow? All the messages are landing on the transmission Queue. I ran the channel Initiator using runmqchi -m queueManagerName -q SYSTEM.CHANNEL.INITQ. What could be wrong, really weird. Thanks. |
|
| Back to top |
|
|
| amurugan |
| Posted: Tue May 14, 2002 9:37 pm Post subject: |
|
|
Voyager
Joined: 10 Sep 2001
Posts: 75
Location: india
|
hi ,
check out whether the initq is running . if not try to start it . Also make sure the channel initiator is running . Verify the remote q definitions. kindly check whether the remote queue maanager is running and the channel listener of the remote queue manager is running. Above all check whether do u have network connectivity to the remote MQseries server and whether is it behind a firewall or not .
cheers,
Murugan |
|
| Back to top |
|
|
| Vin |
| Posted: Wed May 15, 2002 8:24 am Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| I did set this correct since I'm able to send/recieve messages from the two machines. I started the channel initiator using the runmqchi -m queueManagerName -q SYSTEM.CHANNEL.INITQ. I did not understand what you meant by start the INITQ? Is this something which I have to do before running the channel Initiator? My transmission channel is set to trigger type FIRST and trigerring is enabled. The Queue SYSTEM.CHANNEL.INITQ exists. Thanks. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed May 15, 2002 9:56 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Vin,
I think he was referring to starting the channel initiator (runmqchi) on the SYSTEM.CHANNEL.INITQ, which you've already done. Here's my question, have you looked at the depth of the SYSTEM.CHANNEL.INITQ?
The real test would be to stop the channel initiator program, and then attempt to send some messages (with the corresponding channels already running, of course). If the queue objects are setup properly, you should see some messages stack up on the SYSTEM.CHANNEL.INITQ, since there is nothing there to process them. If you don't see any messages, this probably means your transmission queue isn't configured properly. I noticed that you mentioned having set "trigger type FIRST and trigerring is enabled" on the transmission queue. But I didn't notice you mention anywhere that you set the INITQ attribute for the transmission queue to "SYSTEM.CHANNEL.INITQ". If you don't have this set, nothing will happen, even though you set triggering.
Of course, if you do see messages stacking up on the SYSTEM.CHANNEL.INITQ, then you need to start the channel initiator program and see if it picks them up. If it picks them up and the channel isn't starting, you probably have a configuration problem. If it doesn't even pick up the messages, then you've likely got a permission problem of some kind...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Vin |
| Posted: Wed May 15, 2002 10:22 am Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
Brandon,
Here is my transmission queue definition. I set the initq attribute to SYSTEM.CHANNEL.INITQ. Do I need to restart the QueueManager after I change the transmission queue definition? Thanks.
DESCR( ) PROCESS( )
BOQNAME( ) INITQ(SYSTEM.CHANNEL.INITQ)
TRIGDATA(PROSERVCHANNEL) CLUSTER( )
CLUSNL( ) QUEUE(proserv.queue.manager)
CRDATE(2002-04-24) CRTIME(14.13.23)
ALTDATE(2002-05-14) ALTTIME(10.12.19)
GET(ENABLED) PUT(ENABLED)
DEFPRTY(0) DEFPSIST(NO)
MAXDEPTH(5000) MAXMSGL(4194304)
BOTHRESH(0) SHARE
DEFSOPT(SHARED) HARDENBO
MSGDLVSQ(PRIORITY) RETINTVL(999999999)
USAGE(XMITQ) TRIGGER
TRIGTYPE(FIRST) TRIGDPTH(1)
TRIGMPRI(0) QDEPTHHI(80)
QDEPTHLO(20) QDPMAXEV(ENABLED)
QDPHIEV(DISABLED) QDPLOEV(DISABLED)
QSVCINT(999999999) QSVCIEV(NONE)
DISTL(YES) DEFTYPE(PREDEFINED)
TYPE(QLOCAL) SCOPE(QMGR)
DEFBIND(OPEN) IPPROCS(1)
OPPROCS(1) CURDEPTH(0) |
|
| Back to top |
|
|
| Vin |
| Posted: Wed May 15, 2002 2:13 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
| My problem is that the messages are not being delivered to the SYSTEM.CHANNEL.INITQ. All my messages are landing on the transmission queue. I don't have a clue as to what I'm setting wrong that the messages are not being delivered to the initiatio queue which in my case is SYSTEM.CHANNEL.INITQ. I'm really stuck up with this. Appreciate all the help. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed May 15, 2002 2:40 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Vin,
Remember, it's not your messages which are supposed to go to the system.channel.initq. Your messages will remain on the transmission queue, but a trigger message will be created automatically by the queue manager anytime the trigger conditions are met. In your case, it will happen when the first message lands on the transmission queue. This trigger message will be placed on the system.channel.initq with the expectation that the channel initiator will be listening and pick it up. Now, here are some things you need to do:
1) Make sure the channel initiator (runmqchi) isn't running. Now go into runmqsc, and type DIS QL(SYSTEM.CHANNEL.INITQ). Look at the IPPROCS and OPPROCS attributes. These should both be zero.
2) Start the channel initiator (runmqchi). Note, you don't need to specify system.channel.initq. It will assume this by default. So just enter "runmqchi -m queuemanager_name" Now go back into runmqsc and look at SYSTEM.CHANNEL.INITQ again. Now, OPPROCS should say 1. (It might be IPPROCS, I always get the two mixed up  ) Now, if they both still show zero, it means the channel initiator isn't actually watching the SYSTEM.CHANNEL.INITQ
3) Stop the channel initiator again. Now make sure the transmission queue is empty. If the depth is greater than zero, you need to get enable the queue and then clear it manually. Also make sure the channel that is associated with this transmission queue is inactive. In other words, if it's already running, we won't be able to test the trigger mechanism. If it's running though, don't issue STOP CHANNEL. Just wait until the DISCINT interval is exceeded (in which case the channel goes inactive automatically) or alter the channel and give it a shorter DISCINT interval. Once these conditions have been satisfied, now have your application put a message to the remote queue definition which uses this transmission queue. In runmqsc, you should see the depth of the transmission queue go from zero to some value. Similarly, you should see the depth of the SYSTEM.CHANNEL.INITQ go from zero to 1. This message is the trigger message. If you now start the channel initiator program, it should remove this message from the initation queue and start the channel.
Please do these tasks and if your results deviate from what I said here, repsond with exactly what happened. We should be able to determine the root cause from that information...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| Vin |
| Posted: Wed May 15, 2002 3:44 pm Post subject: |
|
|
Master
Joined: 25 Mar 2002
Posts: 212
Location: India
|
Brandon,
Thanks very much for the reply.The good news is, that worked. I have a couple of questions though. I was trying to start a stopped channel, that is a channel which is in a STOPPED STATE. Is this possible at all? I think that's the main reason why I was not getting a trigger messages. The IPPROCS is what indicates an open queue count right? (It changed to 1 when I issued the runmqchi command). Also when I sent a message to my local definition of remote queue, I noticed that the transmission queue had a depth of 1 but the SYSTEM.CHANNEL.INITQ had a count of 3? After I issued the runmqchi command the count of both the queues changed to 0. I wonder what those extra messages on that initiation queue were? Thanks once agian for your time. |
|
| Back to top |
|
|
| bduncan |
| Posted: Wed May 15, 2002 9:00 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Vin,
If I'm not mistaken (and someone jump in here if I'm wrong) any channel you have manually stopped, such that it is in the "STOPPED" state (as oppossed to simply being inactive) it won't be started automatically by the channel initiator. I think this is because the queue manager assumes that since the channel was stopped by human intervention, it will wait until it has been started again by human intervention.
IPPROCS and OPPROCS act together to give you an idea of how many applications have issued MQOPEN calls against the queue in question. Since you can only open a queue for input or output (but not both) the same application will never be counted as both an IPPROC and an OPPROC. The fact that IPPROCS went to 1 when you started the channel initiator means that runmqchi was able to successfully issue an MQOPEN call against the SYSTEM.CHANNEL.INITQ.
As for the additional messages on the initiation queue, there are a few reasons why you may have seen more than you expected. A trigger message is generated everytime the trigger conditions for a queue have been met. In this case, the trigger was on your transmission queue, and the condition was when the depth went from 0 to 1. So, those messages may have been present from your earlier tests (I don't believe trigger messages have an expiry, and even if they did expire, they'd still show up in the queue depth until some application comes along and interacts with the queue) and so there may have already been 2 messages on the SYSTEM.CHANNEL.INITQ. Another reason could be that your trigger interval is low. This value (specified as an attribute of the queue manager, use DIS QMGR to view it) tells the queue manager how long to wait before retriggering a queue if nobody has come along and acted on the previous trigger messages. There's a few more obscure reasons, but you really don't need to worry about it. In the case of the channel initiator, the worse that will happen is that a START CHANNEL command will be issued on a channel that is already running, which does no harm...
Glad to hear you got it working 
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Thu May 16, 2002 4:29 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Brandon, apps can open a queue for both input and output at the same time.
As far as keeping IPROCS/OPROCS straight in my head, I use this silly little memory trick. Open a queue to take messages Into a program = Iprocs (I=I). Open a queue to shoot messages Out of a program (and Onto the queue = Oprocs (O=O). 
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
