| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Channel trigger in XMITQ |
« View previous topic :: View next topic » |
| Author |
Message
|
| jcv |
 Posted: Tue Jan 22, 2013 10:03 am Post subject: |
 |
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| ... I meant for sender channels, because they seem to open xmitq in exclusive mode. Maybe cluster senders in latest version do make use in shared mode. I haven't studied it much yet. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Tue Jan 22, 2013 10:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jcv wrote: |
| ... I meant for sender channels, because they seem to open xmitq in exclusive mode. Maybe cluster senders in latest version do make use in shared mode. I haven't studied it much yet. |
This is working as designed.
The only channels that can use the same XMITQ at the same time are cluster channels.
This is a *good* thing. |
|
| Back to top |
|
|
| jcv |
| Posted: Tue Jan 22, 2013 10:11 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| Yes, they have always opened it in shared mode (obviously), only before there was only one xmitq per cluster, and now it's not. Hence, the question is relevant only for sender channels. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Tue Jan 22, 2013 10:15 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| jcv wrote: |
| Yes, they have always opened it in shared mode (obviously), only before there was only one xmitq per cluster, and now it's not. Hence, the question is relevant only for sender channels. |
Which question?
- What method is best to use to trigger a sender channel?
- do sender channels allow you to share an XMITQ?
The answer to the #1 is "the one that fits best with your policies and procedures". And the general consensus is that you should mention the channel name on the XMITQ so you know, when trying to troubleshoot the xmitq, which channel is causing the problem.
The answer to the second one is no. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jan 22, 2013 1:09 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
| jcv wrote: |
| Hence, the question is relevant only for sender channels. |
And Server channels too.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jan 22, 2013 9:10 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20763
Location: LI,NY
|
| mqjeff wrote: |
Which question?
- What method is best to use to trigger a sender channel?
- do sender channels allow you to share an XMITQ?
The answer to the second one is no. |
Let me be a little bit more descriptive there.
The answer to the second one is yes in very particular cases.
You can share the XMITQ between multiple channels on condition that:
- Only one of the channels sharing the xmitq can be active at a time
- you put the channel name in the trigdata of the xmitq for a triggered channel
You would only use this setup in a very limited number of scenarios, and it mainly comes to play where you have multiple MQ routes to a target. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Jan 22, 2013 9:55 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
2. I presumed this to mean concurrently active sender channels sharing the same xmitq, not sequentially active.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jcv |
| Posted: Thu Jan 24, 2013 9:16 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| PeterPotkay wrote: |
| If I'm dealing with a cranky XMITQ its easier to see which channel its associated with by looking at the XMITQ definition versus listing all the SNDR and SVR channels and starting to look at their definitions one...by one...by one...by one..until I find that match. |
Respectfully, I don't think that argument stands up. Xmitq usage will tell you that directly, if I understand at all what's your point here. One can also use dis chl with where clause, or whatever filter capabilities of admin tool, and exploit the fact that xmitq is unique attribute among sender channel definitions. Or server channels which I tend to forget because I don't use them.
>>But I think its always better to explicitly set something versus relying on defaults and relying on one's recollection of what those defaults are: Syncpoints, port #s, persistence, priority, expiry, channel to xmitq relationships, etc.<<
If that was true, people would not invent defaults. Besides that, I wouldn't describe blank trigdata as using default. To me, more accurate description would be single source of truth, data normalization, and similar concepts.
>>The answer to the #1 is "the one that fits best with your policies and procedures". <<
That's true for sites which are clever enough to prescribe strictly such technicalities in their standards, policies or procedures. I think main obstacle for blank trigdata to reach such documents is MQ specialist being unaware of such possibility.
>>And the general consensus is that you should mention the channel name on the XMITQ so you know, when trying to troubleshoot the xmitq, which channel is causing the problem.<<
Not as general as you think since I don't see what you mean by that. The sheer fact that they provided that option reinforces me in belief I was lucky to acquire its usage.
multiple sdr chls+same xmitq=not of much interest to me, from now on, taking into account fjb_saper's explanation to whom I thank for that.
I shouldn't have mentioned cluster channels since these are out of scope of this discussion about trigdata, for obvious reasons. |
|
| Back to top |
|
|
| exerk |
| Posted: Thu Jan 24, 2013 2:29 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jcv wrote: |
| ...That's true for sites which are clever enough to prescribe strictly such technicalities in their standards, policies or procedures. I think main obstacle for blank trigdata to reach such documents is MQ specialist being unaware of such possibility... |
Oh I'm fully aware of it and have worked at a site that used blank TRIGDATA, but when I'm preparing standards docs I always explicitly state that the attribute it to be filled with the channel name. The site I worked at that didn't was in the process of slowly going around back-filling the attribute because they found that generally when channels didn't trigger and the cause could not be positively determined, the issue went away when TRIGDATA was filled.
_________________
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 |
|
|
| jcv |
| Posted: Fri Jan 25, 2013 2:21 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
I didn't mean to say that you were not aware. For some time I wasn't, until, well, I discovered it. Wouldn't it be better to be persistent with PMR instead of giving up of such a nice feature.
With respect to xmitq usage, it is obviously of no help if channel is not able to open xmitq, and xmitq doesn't have to be strictly unique attribute among all channel definitions, but one can definitely narrow down search enough, so that it is not neccessary to check all definitions one by one as Peter suggested. At least if I understood him well what he said. |
|
| Back to top |
|
|
| jcv |
| Posted: Fri Jan 25, 2013 4:24 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 25, 2013 6:23 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
Size matters. A small WMQ environment (only a few channels), I find myself indifferent to whether the xmitq is explicitly named.
But in a large organization (hundreds or thousands of channels), I'm wholeheartedly in favor of self-documenting object definitions, and where possible (and easy) reducing needless cpu cycles.
One of my clients has a long history with mq, and has xmitqs with names that do not self-document (are not the same name as the down-stream qmgr), have long names, have names with many zeros and O's, and underscores. Some of the object names are imposed on them by external forces. This violates the keep-it-simple rule.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| jcv |
| Posted: Mon Jan 28, 2013 10:03 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| exerk, if you were the one who opened that PMR and reported that defect, and still decided to avoid this option because you think/know they didn't fix it completely, then I shouldn't have posted this link. I didn't mean to say by that that you were not aware of that fix, I wasn't, until a few days ago. Or are you telling me that you adjust your standards taking into account past defects, their potential for regression, and such things? |
|
| Back to top |
|
|
| exerk |
| Posted: Mon Jan 28, 2013 1:58 pm Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| jcv wrote: |
| exerk, if you were the one who opened that PMR and reported that defect, and still decided to avoid this option because you think/know they didn't fix it completely, then I shouldn't have posted this link. I didn't mean to say by that that you were not aware of that fix, I wasn't, until a few days ago. |
I didn't, so don't worry about it...I stand with bruce2359 on "...in a large organization (hundreds or thousands of channels), I'm wholeheartedly in favor of self-documenting object definitions, and where possible (and easy) reducing needless cpu cycles...".
| jcv wrote: |
| Or are you telling me that you adjust your standards taking into account past defects, their potential for regression, and such things? |
I adjust my standards based on a number of things because a standards document is a living document - when FixPacks appear that introduce new functionality (or as in rare case, remove existing functionality), or new versions are released, and experience increases, standards documents should be revisited and revised - anything removed from the existing standard should be moved to the appendix labeled 'Legacy' until such time all installations containing that 'legacy' are updated to the new standard, or gracefully retired - and definitely on a bi-annual basis regardless. But of course that's just my opinion, and I'm sure there are other equally valid views that would rebut my view (mostly from management, whom tend to think it a monumental waste of time - until it comes back to bite them later).
And by way of example, one installation I worked at still insists on the use a process object to trigger channels because it's in the standards doc, irrespective of the fact that the whole of the doc pretty much stopped being valid at MQSeries V5.2. I'll bet they still use inetd to control listeners too 
_________________
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 |
|
|
| jcv |
| Posted: Tue Jan 29, 2013 12:46 am Post subject: |
|
|
Chevalier
Joined: 07 May 2007
Posts: 411
Location: Zagreb
|
| That's O.K., but, if I neglect fjb_saper's explanation about multiple MQ routes to targets for a moment, thousands of sender channel definitions mean thousands of xmitq definitions, which means clear advantage with respect to human effort if trigdata is not set. That's kinda asking a bit what your computer can do for you, not only what you can do for your computer. Obviously, it cannot do much if its power is waisted mindlessly, but the point is that maybe this is not the case here. |
|
| 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
|
|
|
|
