| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Channel trigger in XMITQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| exerk |
 Posted: Tue Jan 29, 2013 2:18 am Post subject: |
 |
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jcv wrote: |
| ...thousands of sender channel definitions mean thousands of xmitq definitions, which means clear advantage with respect to human effort if trigdata is not set... |
I'll concede that point on the premise that it applies only if you were having to define those channels in one shot - and even then I'd prefer to expend the human effort and populate the TRIGDATA attribute or use something like MQArchitect to automate it.
Real-world example: A site decided that it was more important for the business to know which 'channels' their messages were going through than it was for the WMQ Admins to manage the infrastructure. The channel names did not have the sending/receiving queue manager names within their string and the transmit queues carried the name of the sending/receiving application that used that channel - so that 'same' channel could be defined as a SDR in a number of queue managers - and the application names bore no relation to the 'channel' names. So, with no TRIGDATA in either example below:
EASY: XMITQ(QM2) -> SDR(QM1.QM2)
HARD: XMITQ(CR4PAPP1.SEND.TO.D1S4STER2) -> EOD.BATCH.GW01
So, you have messages on the XMITQ and no channel running, with EASY, to work out which channel should be running is simple, even with multiple channel problems; HARD you have to go and interrogate which channel has that XMITQ specified, and if you have multiple channel problems you have to interrogate each channel and it all adds to latency.
I know which I prefer...
_________________
It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
| Back to top |
|
 |
| lancelotlinc |
| Posted: Tue Jan 29, 2013 10:46 am Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| exerk wrote: |
| jcv wrote: |
| ...thousands of sender channel definitions mean thousands of xmitq definitions, which means clear advantage with respect to human effort if trigdata is not set... |
I'll concede that point on the premise that it applies only if you were having to define those channels in one shot - and even then I'd prefer to expend the human effort and populate the TRIGDATA attribute or use something like MQArchitect to automate it.
Real-world example: A site decided that it was more important for the business to know which 'channels' their messages were going through than it was for the WMQ Admins to manage the infrastructure. The channel names did not have the sending/receiving queue manager names within their string and the transmit queues carried the name of the sending/receiving application that used that channel - so that 'same' channel could be defined as a SDR in a number of queue managers - and the application names bore no relation to the 'channel' names. So, with no TRIGDATA in either example below:
EASY: XMITQ(QM2) -> SDR(QM1.QM2)
HARD: XMITQ(CR4PAPP1.SEND.TO.D1S4STER2) -> EOD.BATCH.GW01
So, you have messages on the XMITQ and no channel running, with EASY, to work out which channel should be running is simple, even with multiple channel problems; HARD you have to go and interrogate which channel has that XMITQ specified, and if you have multiple channel problems you have to interrogate each channel and it all adds to latency.
I know which I prefer... |
Scripting and automation make this puzzle a treat.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
| jcv |
| Posted: Wed Jan 30, 2013 2:56 pm Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| exerk wrote: |
| I'll concede that point on the premise that it applies only if you were having to define those channels in one shot - and even then I'd prefer to expend the human effort and populate the TRIGDATA attribute or use something like MQArchitect to automate it. |
I'd say it would be even more tiresome and annoying to issue just a few definitions occasionally, and do that for a thousand times, and setting trigdata contributes greatly to that feeling. And if one duplicates and modifies existing definitions there is a chance to forget to modify trigdata, depending on a tool, experience and haste.
| exerk wrote: |
Real-world example: A site decided that it was more important for the business to know which 'channels' their messages were going through than it was for the WMQ Admins to manage the infrastructure. The channel names did not have the sending/receiving queue manager names within their string and the transmit queues carried the name of the sending/receiving application that used that channel - so that 'same' channel could be defined as a SDR in a number of queue managers - and the application names bore no relation to the 'channel' names. So, with no TRIGDATA in either example below:
EASY: XMITQ(QM2) -> SDR(QM1.QM2)
HARD: XMITQ(CR4PAPP1.SEND.TO.D1S4STER2) -> EOD.BATCH.GW01
So, you have messages on the XMITQ and no channel running, with EASY, to work out which channel should be running is simple, even with multiple channel problems; HARD you have to go and interrogate which channel has that XMITQ specified, and if you have multiple channel problems you have to interrogate each channel and it all adds to latency.
I know which I prefer... |
Blank trigdata and multiple channel definitions should be mutually exclusive on the same xmitq, and one can prefer the latter over the former, but this has nothing to do with troubleshooting. In both cases there is a straightforward way to associate channel and xmitq in one to one relation, either by querying channel definitions for unique xmitq or by examining trigdata. And that does not depend on object naming, it can be role model for intuitiveness and self documentation or a total CR4PAPP1, it's irrelevant. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
