| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| keepalive, HBint, discint, etc. etc. |
« View previous topic :: View next topic » |
| Author |
Message
|
| George Carey |
 Posted: Sat Dec 18, 2010 10:13 am Post subject: last 2 items |
 |
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Yes, the last two items you reference on current and active channels are more what I was looking for ... putting together this excerpt as well as with your substates table for current channel excerpt ... I gather:
Stopped channel is NOT an inactive channel . (I was not clear on this !)
Stopped is a 'current' state of a channel and inactive is a non-current state (or non-state ?) for a channel !
So when a SDR/RCVR channel shows in MQExplorer red down arrow(inactive)
due to disconnect interval there is no channel status table entry for this channel !?
| Quote: |
| Substates of a current can be Stopped, Starting, Retrying, Active. (a channel status table entry exists for this channel. |
Seems counter-intuitive ... since where is it getting the inactive state/status from ? (I know from the SAVED area where ever that is!)
I will have to experiment with dis chs(abc) current or saved or short
I almost always just did dis chs(abc) ...
Diverting a bit from MaxChannels and MaxActiveChannels usage ... on second thought maybe not .
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Sun Dec 19, 2010 1:01 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Seems counter-intuitive ... since where is it getting the inactive state/status from ? (I know from the SAVED area where ever that is!) |
Since v5, in a scratchpad object.
A scratchpad object is an internal object for use by WMQ internals. One scratchad object is created for each channel that has transferred at least one batch of messages. Channel info written to the scratchpad object is also written to the log, and thus is recoverable following channel failure or qmgr restart.
_________________
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 |
|
|
| George Carey |
| Posted: Mon Dec 20, 2010 2:09 pm Post subject: short status |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
Out of curiosity did a couple quick searches on this 'scratchpad object', but did not find anything specifically, is it public info or just as you say some WMQ internals?
Also, doing some dis chs command usage I see current and saved are valid dis chs command parameters but SHORT is z/OS only, there is a SHORTRTS parameter but not the same thing.
I now recall why I never used more than the plain old dis chs(*) syntax ... as it covered the 80-20 % rule well or more like 99-1 % rule and the niceties were thought to be rarely needed complexity noise. But I ended up not being clear on some keep concepts.
Anywhoo ... now I feel re-armed with enough info to properly experiment with the relevant parameters that manage channel connection behavior and have a chance of understanding the interrelation effects ... we'll see !
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 20, 2010 3:40 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
... is it public info or just as you say some WMQ internals?
|
It's an internal object that enjoys some anonymity.
At v5 (and forward) the internal object replaced the SYSTEM.CHANNEL.SYNCQ for synchronization and channel status info for every channel that has transferred at least one batch of messages.[/quote]
_________________
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 |
|
|
| SAFraser |
| Posted: Tue Dec 21, 2010 5:01 am Post subject: |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
|
| Back to top |
|
|
| George Carey |
| Posted: Tue Dec 21, 2010 9:27 am Post subject: reinventing the wheel |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
I knew somebody must have clarified this for themselves before:
I am copying your conclusions here again ... from back in 2007!
From SAFaser:
| Quote: |
- MaxChannels limits all channels for which there is an entry in the channel status table.
- MaxActiveChannels limits only channels with a running status.
- In the absence of a MaxChannels entry, the default of 100 applies regardless of whether there is a MaxActiveChannels entry.
i.e., MaxActiveChannels does not become the default for MaxChannels.
- Whatever is the most restrictive parameter will apply.
i.e., if the limit for MaxChannels is reached but the MaxActiveChannels is not, the connection will be refused. If the limit for MaxActiveChannels is reached but the MaxChannels is not, the connection will be refused.
and
- In the absence of an affirmatively set MaxActiveChannels parameter, it will assume the value set for MaxChannels.
My(SAFaser's) takeaway from this is: Each parameter is still used, each operates independently, and each operates at the default of 100 unless set otherwise.
|
I have only two additional comments:
1.) It sounds like a bit of work to get the channel state permutations. Care to describe your test suite and procedure.
2.) Is there some reason IBM could not have just had this succinct explanatory paragraph in their documentation !?
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 21, 2010 9:37 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Is there some reason IBM could not have just had this succinct explanatory paragraph in their documentation !? |
Wow. Where to go with this rhetorical question...
If I'm not mistaken, I believe we arrived at this same question regarding the current depth of a queue.
_________________
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 |
|
|
| mqjeff |
| Posted: Tue Dec 21, 2010 9:44 am Post subject: Re: reinventing the wheel |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| George Carey wrote: |
| 2.) Is there some reason IBM could not have just had this succinct explanatory paragraph in their documentation !? |
Undocumented behavior is subject to change without notice. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 21, 2010 9:47 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Undocumented behavior is subject to change without notice. |
And, 'subject to change without notice' is a documented behavior.
_________________
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 |
|
|
| George Carey |
| Posted: Tue Dec 21, 2010 9:52 am Post subject: rhetorical ? |
|
|
Knight
Joined: 29 Jan 2007
Posts: 500
Location: DC
|
It is not 100% rhetorical ... it is a question of why does IBM seem to systemically avoid concise explanations.
... Thinking a moment it may be because conciseness is expensive ... a terse yet complete and correct(i.e. concise) explanation is often hard to do ...
a terse in-complete (and often incorrect) explanation is cheap and easy ... (e.g. bumper stickers.)
So if you are still part of the IBM systemic process maybe you can fix it ... so not completely rhetorical.
Finally, give me a link again to the queue depth discussion ... I forget what that was !
_________________
"Truth is ... grasping the virtually unconditioned",
Bernard F. Lonergan S.J.
(from book titled "Insight" subtitled "A Study of Human Understanding") |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Dec 21, 2010 10:17 am Post subject: Re: rhetorical ? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| George Carey wrote: |
| It is not 100% rhetorical ... it is a question of why does IBM seem to systemically avoid concise explanations. |
Well I'm not going to offer an opinion. In writing. In public. 
| George Carey wrote: |
| So if you are still part of the IBM systemic process maybe you can fix it ... so not completely rhetorical. |
Irrespective of who in this forum is and is not part of the IBM system, the Feedback button on the InfoCenter page & your account rep most certainly are. You pay a lot of money of this software, this gives you the right to point out any areas you are unhappy with or even to raise a PMR entitled "Tell me exactly how this channel stuff works".
The more people complain about the documentation, the more likely it is to be changed (notice I don't say corrected - no future reader should walk away from this thread thinking the InfoCenter is wrong).
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 21, 2010 10:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Dec 21, 2010 10:43 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9475
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| "Tell me exactly how this channel stuff works". |
This is a substantially different question from "Tell me how this channel stuff works." Exactly, being the key word here.
IBM has documented in the Intercommunications manual how a channel is supposed to (designed to) behave. Exactly how it works, and why, is proprietary. This is an appropriate level of abstraction. Appropriate, but for us, confusing and frustrating.
At v5, scratchpad objects replaced the SYSTEM.CHANNEL.SYNCQ. Internal use of the SYSTEM.CHANNEL.SYNCQ is/was the proprietary, and not well documented. The use of scratchpad objects is not well documented, either.
Out of curiosity, some us decomposed the syncq, and then depended on its internal structure remaining constant. Like the CCDT, IBM didn't and doesn't guarantee that internals will remain constant.
_________________
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 |
|
|
| Vitor |
| Posted: Tue Dec 21, 2010 10:47 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| bruce2359 wrote: |
| Quote: |
| "Tell me exactly how this channel stuff works". |
This is a substantially different question from "Tell me how this channel stuff works." Exactly, being the key word here. |
And I never said you'd get a straight answer from the PMR. Just that you could raise one. At what point the customer's right to an answer crosses the line into IBM's intelectual property is not something I want to get into, and I suspect varies on a case by case basis.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| SAFraser |
| Posted: Tue Dec 21, 2010 10:48 am Post subject: Re: reinventing the wheel |
|
|
Shaman
Joined: 22 Oct 2003
Posts: 742
Location: Austin, Texas, USA
|
| George Carey wrote: |
1.) It sounds like a bit of work to get the channel state permutations. Care to describe your test suite and procedure.
|
George, You are very kind!
Nothing as sophisticated as an actual test suite; we don't even have a test server to call our own. We do have a queue manager for the MQ Team's unit testing (on a shared server, not ideal of course) and it was there that I did the work. I simply wrote out all the possible combinations of the two parameters, guessed at the expected outcome, then recorded what happened.
I cannot recollect what prompted me to spend time on this, but it must have been some looming catastrophe involving system resources and svrconn channel counts.
Shirley |
|
| 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
|
|
|
|
