| Author |
Message
|
| Jeeva |
 Posted: Thu Feb 17, 2005 7:23 am Post subject: More than one channel exit for one channel |
 |
|
Novice
Joined: 16 Feb 2005
Posts: 12
Location: India
|
Hi,
Here is the scenario..
I have one channel exit runing on my Gateway Queue manager which connects with the Soruce Application.
Now i need to configure one more channel exit to the same channel but executing for specific queues. Is there any way to configure more than one channel exit to one channel.
If yes, Can I set the priority or some rules for each channel exits?
Please post your replies.
Thanks in Advance
Jeeeva |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Feb 17, 2005 7:31 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Have you read the documentation on channel exits?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Jeeva |
| Posted: Thu Feb 17, 2005 8:22 am Post subject: |
|
|
Novice
Joined: 16 Feb 2005
Posts: 12
Location: India
|
Hi Jeff,
I read the documentation but somehow missed to notice that "list of programs can be run in an succession".
Anyway many thanks.
Jeeeva |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Feb 17, 2005 8:39 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| http://publibfp.boulder.ibm.com/epubs/html/csqzae09/csqzae097c.htm#HDRDUP0006 wrote: |
Multiple send exits
You can specify a list of send and receive exit programs to be run in succession. WebSphere MQ maintains a total for the space reserved by all of the send exits. This total space must leave at least 1 KB for message data in the transmission buffer.
The following example shows how space is allocated for three send exits, called in succession:
1. When called for initialization:
* Send exit A reserves 1 KB.
* Send exit B reserves 2 KB.
* Send exit C reserves 3 KB.
2. The maximum transmission size is 32 KB and the user data is 5 KB long.
3. Exit A is called with 5 KB of data; up to 27 KB are available, because 5KB is reserved for exits B and C. Exit A adds 1KB, the amount it reserved.
4. Exit B is called with 6 KB of data; up to 29 KB are available, because 3KB is reserved for exit C. Exit B adds 1KB, less than the 2KB it reserved.
5. Exit C is called with 7 KB of data; up to 32 KB are available. Exit C adds 10K, more than the 3KB it reserved. This is valid, because the total amount of data, 17 KB, is less than the 32KB maximum. |
I think it's the System Administration guide that details how to specify more than one exit in a particular queue manager property.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Thu Feb 17, 2005 2:28 pm Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Did not know that... now that I do, I would still not go that route.
if certain functionality is different even when from the same application
I would define a new channel with it's own properties and functionality.
I am just not very fond of hidden complexities, so KISS is my paradigm...
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 18, 2005 5:03 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| MichaelDag wrote: |
Did not know that... now that I do, I would still not go that route.
if certain functionality is different even when from the same application
I would define a new channel with it's own properties and functionality.
I am just not very fond of hidden complexities, so KISS is my paradigm... |
And yet... exit chaining can increase simplicity and increase visibility. If I need function A, B, anc C performed on one channel, and A and B on a second, and A and C on another... if I write three exits and chain them... I can immediately tell what is being done when stuff goes through which channel. And the code for A, B and C are are smaller and simpler - and easier to maintain.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Feb 18, 2005 5:10 am Post subject: |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
| jefflowrey wrote: |
And yet... exit chaining can increase simplicity and increase visibility. If I need function A, B, anc C performed on one channel, and A and B on a second, and A and C on another... if I write three exits and chain them... I can immediately tell what is being done when stuff goes through which channel. And the code for A, B and C are are smaller and simpler - and easier to maintain. |
I challenge you to explain this in more detail!
I understand you as the writer of the code can tell what's going on underneath, but what about the poor admin guy? 
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 18, 2005 5:21 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
[quote="MichaelDag"]I challenge you to explain this in more detail!
I understand you as the writer of the code can tell what's going on underneath, but what about the poor admin guy? [/quote
I meant exactly the poor admin guy can immediately tell. He can look at the channel definition, and see that Exit A is invoked first followed by Exit B or C, or all three. And he can be told that exit A is the "encrypt", and exit B is the "compress", and exit C is the "mangle" function.
If I write one exit that has the logic of encrypt and mangle (exit R), and one that has the encrypt and compress(exit S), and one that has encrypt compress and then mangle (Exit T)... all the admin guy knows is that one channel has Exit R, one has Exit S and one has Exit T. If someone says that they then need a channel that will compress and mangle but not encrypt... the developer has to write more code. And if the encrypt function needs to change... all three exits need to change.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Michael Dag |
| Posted: Fri Feb 18, 2005 5:47 am Post subject: Re: More than one channel exit for one channel |
|
|
Jedi Knight
Joined: 13 Jun 2002
Posts: 2607
Location: The Netherlands (Amsterdam)
|
Jeff,
when using these examples I 'get' the 'simplicity' and would have to agree, but what about the situation asked for:
| Jeeva wrote: |
| Now i need to configure one more channel exit to the same channel but executing for specific queues. |
somewhere in the exit for Queue A and B mangling is done underneath and for Queue C and D not...
is that more transparant and easier to understand then setting up different channels for A,B and C,D?
_________________
Michael
MQSystems Facebook page |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Feb 18, 2005 6:32 am Post subject: Re: More than one channel exit for one channel |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| MichaelDag wrote: |
what about the situation asked for:
| Jeeva wrote: |
| Now i need to configure one more channel exit to the same channel but executing for specific queues. |
somewhere in the exit for Queue A and B mangling is done underneath and for Queue C and D not...
is that more transparant and easier to understand then setting up different channels for A,B and C,D? |
Depends on how the choice of which queue is done... And in fact, regardless, that level of queue specificity may still require different channels.
What's the rule, again? Make it as simple as it has to be, and no simpler?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
