| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Role of Channels and Triggers |
« View previous topic :: View next topic » |
| Author |
Message
|
| NigelD |
 Posted: Wed Oct 31, 2007 5:52 am Post subject: Role of Channels and Triggers |
 |
|
Newbie
Joined: 31 Oct 2007
Posts: 3
|
I've been trawling manuals and these forums for hours now, but three things are still unclear to me.
(1) Queues and Channels are owned by a queue manager. So when messages are placed onto a queue, how does the queue manager know which channel to use to route the message to its destination? I'd expect the channel to be associated with the queue, not the queue manager.
(2) If I am want to MQPUT a message on a queue on one system, and have it available for MQGET on another in a DISTRIBUTED environment (i.e. both queues have a queue manager) do I define both queues as LOCAL, and link them with a channel? The concept of remote queues does not seem to apply here as both systems queues are managed by their own queue managers.
(3) When a message arrives on the target systems queue, and triggering is specified, and a further Initiation queue (within the same queue manager) specified, is the Procedure name on the Target queue used to specify the procedure that gets called when messages arrive there? Or is it the procedure name of the Initiation queue? In either case, does the procedure need to MQGET from the target queue itself, or can it receive the message as a parameter?
Sorry for the number of questions, but if I'm pointed in the right direction, I'm sure these areas will start to make sense! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Oct 31, 2007 5:58 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
|
| Back to top |
|
|
| NigelD |
| Posted: Wed Oct 31, 2007 6:30 am Post subject: |
|
|
Newbie
Joined: 31 Oct 2007
Posts: 3
|
Thanks for the reference, but Dieter Wackerow's document was my starting point - I read it 3 hours ago!
Unfortunately, it's written predominantly from a Windows perspective, and I'm looking to implement on an i-Series.
The closest it comes to answering my first point is that it appears (extrapolating from pages 21 - 23) that in defining a Channel, you link it to an XmitQ, and in defining a sending queue, you also link to the same XmitQ: therefore you are essentially linking a sending queue to a channel which points at a remote System and queue. Correct?
In regard to point 2, the document states twice that Remote queues are not associated with a queue manager, but on the i-Series, you can only access queues, INCLUDING *RMT type queues via their queue manager.
Finally, the document does not answer the third point. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 31, 2007 6:35 am Post subject: |
|
|
Guest
|
| I'd suggest (re-)reading the first few chapters of the MQ Intercommunications manual. It covers the basics of distributed queuing; and should answer these questions and others. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 31, 2007 6:41 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Triggering generally works like this:
1) A message appears on a queue, and this event is the last thing necessary to satisfy the conditions for triggering that queue
2) The queue manager creates a new message that goes on the INITQ. This message is built from the process definition of the triggered queue.
3) The trigger monitor retrieves this message from the INITQ, and uses the message to invoke the specified process.
4) The process/procedure is invoked, and passed the information from the trigger message as a parameter.
Everything that happens after the procedure/process is started - including whether it does anything with the message on the triggered queue - is defined solely by the process/procedure itself. The trigger queue is not otherwise opened by anything, the message that caused the trigger event is not otherwise opened or read by anything.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Oct 31, 2007 6:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| NigelD wrote: |
The closest it comes to answering my first point is that it appears (extrapolating from pages 21 - 23) that in defining a Channel, you link it to an XmitQ, and in defining a sending queue, you also link to the same XmitQ: therefore you are essentially linking a sending queue to a channel which points at a remote System and queue. Correct?
|
Except that many sending queues (more formally called remote queues) can use a single xmitq / channel combination and the remote queue does not need to quote an xmitq; provided there is a queue named for the remote queue manager then it will all sort itself out under the covers.
There are good reasons why you'd want this kind of automatic resolution, and equally good reasons why you wouldn't. Search the forum for many debates on this matter! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| NigelD |
| Posted: Wed Oct 31, 2007 6:54 am Post subject: |
|
|
Newbie
Joined: 31 Oct 2007
Posts: 3
|
Bruce, pages 21 - 23 also cover the theory of distributed queuing.
However, the problem though is the transition from the documented theory of M.Q. and the practicalities of implementation. You are clearly coming from a Windows-based implementation where the command set is very different to that available on the i-Series. In practical terms, the generic DEFINE statement is replaced by CRTMQM, CRTMQMQ and CRTMQMCHL commands, all with quite different parameter sets to the DEFINE command, so I need input from someone familiar with these problems, rather than the broad assertion that reading a Windows-centric primer prepares you for the intricasies of i-Series deployment. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 31, 2007 7:01 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Right, so the Primer is just intended to get you started.
The actual documentation is what you'll use for most situations - in your case, probably mostly you'll look at the iSeries specific guides.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| tleichen |
| Posted: Wed Oct 31, 2007 8:29 am Post subject: |
|
|
Yatiri
Joined: 11 Apr 2005
Posts: 663
Location: Center of the USA
|
| NigelD wrote: |
| ... You are clearly coming from a Windows-based implementation where the command set is very different to that available on the i-Series. In practical terms, the generic DEFINE statement is replaced by CRTMQM, CRTMQMQ and CRTMQMCHL commands, all with quite different parameter sets to the DEFINE command, so I need input from someone familiar with these problems, rather than the broad assertion that reading a Windows-centric primer prepares you for the intricasies of i-Series deployment. |
Not necessarily. These commands are standard on just about ALL MQSeries platforms except iSeries.
I'm not trained on iSeries, but that is my understanding. I once new the reason why those commands had to be different on that platform, but I've since forgotten it. Anyway, as Jeff said, if you use the aforementioned manuals, you should do fine. 
_________________
IBM Certified MQSeries Specialist
IBM Certified MQSeries Developer |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Oct 31, 2007 8:38 am Post subject: |
|
|
Guest
|
MQ architecture is consistent on all platforms - a queue is a queue; a qmgr is a qmgr.
The difference here is the administrative interface - Windows GUI, UNIX and Windows command line commands, z/OS and iSeries panel-based. The admin interfaces are usually for what are casually refered to as one-time events - like crtmqm, strmqm, etc..
Consistent on all platforms is the script commands for managing objects. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Oct 31, 2007 9:30 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| bruce2359 wrote: |
| Consistent on all platforms is the script commands for managing objects. |
To be a bit more specific here, while also agreeing with bruce2359... The MQSC Script Language is consistent on all platforms, although the parameters of some objects are different on different platforms.
In v6, the PCF command interface is also consistent on all platforms - with the same object specific platform differences.
In addition, and this is one of the very important things about MQ - the programming API is the same on all platforms. I can write a C program once, and compile it to run on any platform, and it will work as well on each as it does on one.
I can write a Java program, or a C++ program, and the same holds true. .NET programs are a little harder to run on zSeries, though.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
